Linux, Programming, Security

เจาะระบบ Web App PHP/MySQL และการป้องกัน

ชี้แจง

บทความนี้มีจุดประสงค์เพื่อนำเสนอให้เห็นช่องโหว่เรื่องความปลอดภัยของระบบ Web Application ที่ใช้ PHP/MySQL โดยจำเป็นต้องสาธิตขั้นตอนการเจาะระบบ เพื่อให้เห็นถึงจุดอ่อนและจะได้ทราบแนวทางป้องกัน ไม่ได้มีจุดประสงค์ชี้นำในการกระทำผิด ผู้ที่ใช้ความรู้ในทางที่ผิดต้องรับผิดชอบต่อการกระทำของตนเอง

… เข้าเรื่อง

โดยทั่วไปแล้ว ระบบ Web Application ที่เขียนขึ้นมาไม่ดี มักจะมีช่องโหว่ให้ผู้ไม่หวังดีเข้ามาโจมตีระบบ ไม่ว่าจะเป็นการทำ SQL Injection, XSS, Buffer Overflow หรือเทคนิคอื่นๆ ซึ่งถ้าสังเกตจากข่าวการโจมตีเว็บไซต์ส่วนใหญ่ก็มักจะโดนในรูปแบบนี้ มาดูกันดีกว่าว่าปัญหาแต่ละแบบคืออะไร โจมตีอย่างไร และป้องกันอย่างไร

1. SQL Injection

คือการแทรกคำสั่ง SQL เข้าไปในส่วนของการสั่ง Query ของโปรแกรม เพื่อให้โปรแกรมทำงานผิดพลาดหรือทำงานนอกเหนือไปจากสิ่งที่ผู้เขียนโปรแกรมกำหนด

สมมุติหน้าจอ Login ของเว็บไซต์หนึ่งมีช่องให้ผู้ใช้กรอก Username และ Password ดังรูป

เมื่อผู้ใช้คลิกปุ่ม Login ก็จะส่งข้อมูลจาก Form ไปที่หน้าสำหรับตรวจสอบค่าที่รับเข้ามา โดยมีส่วนของโค้ดในการตรวจสอบคร่าวๆ ดังนี้

$username = $_GET[‘username’];
$password = $_GET[‘password’];

$query = “SELECT * FROM users WHERE username=’$username’ AND password=’$password’;”;
$result = mysql_query($query) or die(mysql_error());

if ($result && mysql_num_rows($result) == 1) {
// Login Successful
echo “Welcome ” . $username;
} else {
//Login failed
echo ‘Uername and/or password incorrect.’;
}

การทำงานของโค้ดข้างบนนี้ก็คือ เอาค่า $username และ $password ที่ได้รับ เข้ามาเป็นเงื่อนไขของคำสั่ง Query เช่น ถ้า $username เป็น abc และ $password เป็น 1234 คำสั่ง Query ที่ได้จะเป็นดังนี้

SELECT * FROM users WHERE username=’abc’ AND password=’1234′;

ซึ่งโปรแกรมก็จะไปตรวจสอบในฐานข้อมูล ว่ามี username และ password นี้อยู่จริงหรือเปล่า ถ้ามีก็จะ SELECT ค่าใน row นั้นมา และผู้ใช้ก็จะสามารถ Login เข้าสู่ระบบได้เพราะใส่ username และ password ถูกต้อง แต่ถ้าไม่สามารถ SELECT ค่าได้ หมายความว่าผู้ใช้ใส่ username หรือ password ไม่ถูกต้อง ก็จะไม่อนุญาตให้เข้าสู่ระบบ

ตัวอย่างการโจมตี

ในการเจาะระบบ ทำได้โดยการใส่ค่า input ที่เป็นคำสั่ง SQL เพื่อให้เข้าไปเปลี่ยนการทำงานของคำสั่ง Query ตัวอย่างเช่น ใส่ค่า $username เป็น abc’ or ‘1’=’1 จะได้คำสั่ง Query ดังนี้

SELECT * FROM users WHERE username=’abc’ or ‘1’ = ‘1’ AND password=”;

ซึ่งผลที่ได้จากการใส่คำสั่งนี้คือ สามารถผ่านเข้าสู่ระบบได้โดยใช้ username ชื่อ abc โดยไม่จำเป็นต้องใส่หรือรู้ password เลย เนื่องจากว่าการใส่คำสั่ง or ‘1’=’1′ จะเป็นการทำให้เงื่อนไข username เป็นจริง และจะ Select เอาค่า row ในตารางออกมาได้

นอกจากการใส่คำสั่งเพื่อข้ามการตรวจสอบ username, password ได้แล้ว การทำ SQL Injection ยังสามารถแทรกคำสั่ง SQL อันตรายๆ ได้อีกด้วย เช่น DROP TABLE, DELETE, … ฯลฯ

การป้องกัน

ก่อนจะเอา input ที่ผู้ใช้ป้อน เข้ามามาเป็นส่วนหนึ่งของเงื่อนไขคำสั่ง Query ต้องมีการตรวจสอบค่าที่รับเข้ามาว่ามี Escape Character หรือเปล่า Escape Character ก็คืออักขระพิเศษในภาษา SQL ที่สงวนไว้สำหรับการเรียกฐานข้อมูล เช่น เครื่องหมาย ‘ (single quote) ใน MySQL โดยเมื่อ MySQL พบตัว Escape Character ก็จะถือว่าจบส่วนของคำสั่งนี้ และจะทำคำสั่งที่อยู่ถัดไป

ใน PHP มีฟังก์ชันที่ชื่อว่า mysql_real_escape_string() เพื่อเอาไว้กรอง Escape Character ของ MySQL เช่น เมื่อผู้ใช้ป้อนค่า $username เข้ามาเป็น abc’ or ‘1’=’1 แล้วเราเรียกใช้ฟังก์ชัน $username = mysql_real_escape_string($username) จะได้ค่า $username เป็น abc\’ or \’1\’=\’1 ซึ่งก็คือการเอาเครื่องหมาย \ ไปใส่ไว้ก่อนหน้าเครื่องหมาย ‘ นั่นเอง

ข้อมูลเพิ่มเติม

http://en.wikipedia.org/wiki/SQL_injection
http://www.unixwiz.net/techtips/sql-injection.html
http://www.securiteam.com/securityreviews/5DP0N1P76E.html

2. Cross Site Scripting (XSS)

คือการแทรกสคริปต์หรือแท็ก HTML ลงไปในหน้าเว็บ โดยปกติแล้วเทคนิคนี้มักจะพบได้ในระบบเว็บที่อนุญาตให้ผู้ใช้โพสต์ข้อความเข้ามา แล้วแสดงผลข้อความที่ผู้ใช้โพสต์ขึ้นมาบนหน้าเว็บ เช่น Guestbook, Webboard โดยตัวอย่างนี้จะสมมุติระบบ Guestbook มีช่อง Input ให้กรอก Name และ Message จากนั้นเมื่อคลิกปุ่ม Sign Guestbook จะไปทำคำสั่ง Query ดังนี้

$query = “INSERT INTO guestbook VALUES (‘$name’,’$message’);”;

จากนั้นส่วนหน้าเว็บที่แสดงผล Guestbook ก็จะเอาข้อความจากฐานข้อมูลมาแสดง

ตัวอย่างการโจมตี

ลองใส่โค้ด JavaScript ลงใน Guestbook ดังรูป

เมื่อคลิกปุ่ม Sign Guestbook ระบบก็จะเอาข้อความที่โพสต์ไว้มาใส่เป็นส่วนหนึ่งของหน้าเว็บ ทำให้ขึ้น Popup Message ขึ้นมา

การโจมตีแบบ XSS นอกจากจะสามารถฝังสคริปต์ในหน้าเว็บได้แล้ว ยังสามารถฝังองค์ประกอบ HTML อื่นๆ ได้หมด เช่น Iframe

การป้องกัน

เอาข้อความที่รับเข้ามา มาเข้าฟังก์ชัน htmlspecialchars() เพื่อแปลง HTML Tag ให้เป็นตัวอักษรธรรมดา เช่น ใช้คำสั่ง $message = htmlspecialchars($message); ซึ่งผลลัพธ์ที่ได้จะเป็นดังรูป

จากรูป จะพบว่า < ถูกเปลี่ยนเป็น &lt; และ > ถูกเปลี่ยนเป็น &gt;

ข้อมูลเพิ่มเติม

http://en.wikipedia.org/wiki/Cross-site_scripting
http://www.cgisecurity.com/xss-faq.html
http://ha.ckers.org/xss.html
http://www.pantip.com/tech/developer/topic/DW3001981/DW3001981.html

3. Cross Site Request Forgery (CSRF)

คือการใช้เทคนิค Social Engineer เพื่อหลอกให้เหยื่อคลิกลิงก์ที่มี Request บางอย่าง ซึ่ง Request ที่ว่านี้ จะทำงานได้ก็ต่อเมื่อผู้ใช้คนนั้น Login เข้าสู่ระบบเรียบร้อยแล้ว เช่น เปลี่ยน emain, เปลี่ยน password, ฯลฯ โดยปกติแล้ว เมื่อผู้ใช้ Login ผ่าน และเข้าสู่ระบบเรียบร้อยแล้ว โปรแกรมส่วนใหญ่จะใช้การสร้าง SESSION หรือเก็บ Cookie เพื่อยืนยันตัวผู้ใช้ การส่ง Request อะไรซักอย่าง ในขณะที่ผู้ใช้กำลัง Login อยู่ ก็เหมือนกับว่าผู้ใช้เป็นคนส่ง Request นั้นไปเอง

ตัวอย่างการโจมตี

สมมุติเว็บไซต์ธนาคารแห่งหนึ่ง ผู้ใช้จะสามารถโอนเงินได้ก็ต่อเมื่อ Login เข้าระบบแล้ว และการโอนเงินต้องส่ง Request ไปที่ Server ดังนี้

http://bank.com/transfer.do?acc=BOB&amount=100

ในตัวอย่างนี้ คือการโอนเงินไปที่บัญชีของ BOB เป็นจำนวน 100

ถ้า Maria ต้องการหลอก Alice ให้โอนเงินมาให้ตัวเอง ก็ต้องหลอกให้ Alice ส่ง Request มาที่ Server ดังนี้

http://bank.com/transfer.do?acct=MARIA&amount=100000

ซึ่งโดยปกติแล้ว ถ้าในตอนที่ส่ง Request นั้น Alice ไม่ได้เข้าสู่ระบบอยู่ การโอนเงินก็จะไม่สามารถทำได้ ดังนั้น Maria ก็อาจจะส่ง E-Mail หลอกๆ ไปหา Alice โดยหวังว่าในตอนที่คลิกลิงก์นี้ Alice น่าจะกำลัง Login เข้าระบบธนาคารอยู่

<a href=”http://bank.com/transfer.do?acct=MARIA&amount=100000″>View my Pictures!</a>

ซึ่งถ้าในตอนนั้น Alice กำลังเข้าระบบธนาคารอยู่ และคลิกที่ลิงก์นี้เข้าจริงๆ ก็เท่ากับว่า Alice โอนเงินไปให้ Maria ไปเลย 10000

ถ้า Alice คลิกที่ลิงก์นี้ อาจจะไปเจอกับหน้าเว็บของธนาคาร ที่ขึ้นข้อความบอกว่า “โอนเงินเรียบร้อยแล้ว” Alice จะรู้ว่าถูกหลอกให้โอนเงิน ทำให้แผนแตกได้ ดังนั้น Maria ก็อาจจะส่ง E-Mail ที่มีโค้ดข้างล่างนี้

<img src=”http://bank.com/transfer.do?acct=MARIA&amount=100000&#8243; alt=”” width=”1″ height=”1″ border=”0″ />

ซึ่งในโค้ดนี้ ก็คือการแทรกรูปภาพปลอมๆ เข้าไปในเมล ซึ่งเมื่อ Alice โหลดรูปภาพนี้ขึ้นมาดู ก็จะเป็นการส่ง Request ไปที่ Server บอกให้โอนเงิน โดยที่ Alice จะไม่เห็นข้อความบอกว่าโอนเงินเรียบร้อยแล้ว

การป้องกัน

ถ้าจะป้องกัน CSRF การเช็คแค่ HTTP Referer header นั้นป้องกันไม่ได้ เพราะ header สามารถถูกปลอมแปลงได้ เช่น ใช้ cURL หรือแม้กระทั่งการกำหนดให้ Request ที่เข้ามาเป็น POST อย่างเดียวก็ไม่สามารถป้องกันได้ เพราะถูกปลอมแปลงได้เช่นกัน ในการป้องกันที่ดีควรจะใช้การทำ Challenge/Response ในส่วน Request ที่สำคัญๆ

ข้อมูลเพิ่มเติม

http://en.wikipedia.org/wiki/Cross-site_request_forgery
https://www.owasp.org/index.php/Cross-Site_Request_Forgery
http://www.cgisecurity.com/csrf-faq.html

4. Brute Force

การเจาะระบบโดยวิธี Brute Force เป็นการทดลอง Login โดยเดา Username หรือ Password แล้วส่งคำขอ Login ไปเรื่อยๆ จนกว่าจะสามารถเข้าสู่ระบบได้ ซึ่งการโจมตีสามารถทำได้ 2 แบบ คือ ใช้ฐานข้อมูล Password จาก Password Dictionary และทดลองสุ่ม Password ทุกตัวที่เป็นไปได้ (Brute Force) หรือจะใช้ทำวิธี Dictionary attack กับ Brute force attack คู่กันไปเลยก็ได้

ตัวอย่างการโจมตี

ใช้โปรแกรมสำหรับเจาะระบบ Login เช่น Hydra

การป้องกัน

ป้องกันการเดารหัสผ่าน เช่น กำหนดว่าถ้ามีการ Login ผิดเกินจำนวนครั้งที่กำหนด Account นั้นจะถูกระงั้บการใช้บริการ หรือถ้าทำไม่ได้ ก็ใช้วิธี Delay Login เช่น ถ้าใส่รหัสผิด ต้องรออีก 10 วินาทีถึงจะสามารถ Login ใหม่ได้ ซึ่งวิธีที่ 2 นี้สามารถลดความสามารถในการเดา Password ของโปรแกรมได้มาก เช่น ถ้าไม่ป้องกันเลย ใน 1 นาทีสามารถเดาได้ 1,000 รหัสผ่าน แต่ถ้าทำ Delay Login ไว้ 10 วินาที เวลา 1 นาทีก็สามารถเดาได้แค่ 6 รหัสผ่าน

ข้อมูลเพิ่มเติม

https://www.owasp.org/index.php/Testing_for_Brute_Force_%28OWASP-AT-004%29
http://www.symantec.com/connect/articles/password-crackers-ensuring-security-your-password
http://www.sillychicken.co.nz/Security/how-to-brute-force-http-forms-in-windows.html

5. File Upload

ในระบบที่อนุญาตให้ผู้ใช้ Upload File จำเป็นต้องมีการตรวจสอบไฟล์ที่รับเข้ามา ก่อนที่จะเอาไฟล์นั้นไปใช้ต่อ การตรวจสอบแค่ extension ของไฟล์อาจจะไม่เพียงพอ เพราะ hacker สามารถแทรกโค้ดมากับไฟล์หรือส่งไฟล์อันตรายๆเข้ามาในระบบได้

ตัวอย่างการโจมตี

ในระบบ Unix ผู้ใช้สามารถตั้งชื่อไฟล์แบบนี้ได้ <script>alert(‘xxx’)</script>.jpg ซึ่งถ้ามีเว็บไซต์ที่อนุญาตให้ Upload File แล้วแสดงรายชื่อไฟล์ที่ upload ออกมาทางหน้าเว็บ ก็สามารถถูกโจมตีด้วยวิธี XSS ได้

การป้องกัน

กำหนดไว้เลยว่าไฟล์ที่ผู้ใช้ Upload มานั้น ตรงกับที่อนุญาตให้ Upload หรือเปล่า ซึ่งอาจต้องมีการตรวจสอบหลายๆ ชั้น ไม่ว่าจะเป็น ตรวจสอบขนาดไฟล์,ชื่อไฟล์,ตรวจสอบ Content,กำหนดสิทธิ์ของไดเรคทอรี่ที่เก็บไฟล์ ว่าให้สามารถ Read และ Write ได้อย่างเดียว ไม่สามารถ Execute ได้ รวมถึงการสแกนไวรัสไฟล์ที่อัพโหลดเข้ามาด้วย ถ้าทำได้

ข้อมูลเพิ่มเติม

https://www.owasp.org/index.php/Unrestricted_File_Upload
http://blogs.securiteam.com/index.php/archives/1268
http://www.acunetix.com/websitesecurity/upload-forms-threat.htm

ลองของจริง

สำหรับผู้ที่อยากลองเจาะระบบ Web Application ที่มีช่องโหว่ สามารถดาวนโหลดโปรแกรมที่ชื่อ Damn Vulnerable Web App มาลองเล่นได้ ซึ่งโปรแกรมนี้จะจำลองระบบที่มีช่องโหว่มาให้ ไม่ว่าจะเป็น SQL Injection, XSS สามารถดาวน์โหลดได้จาก http://www.dvwa.co.uk/ ซึ่งนอกจากจะฝึกเจาะระบบได้แล้ว โปรแกรมนี้ยังมีตัวอย่าง Source Code ให้ศึกษาด้วย

ปล. ขอเตือนอีกรอบว่าบทความนี้มีจุดประสงค์เพื่อการศึกษาเท่านั้น ใครไปลองเจาะระบบของจริงก็ต้องรับผิดชอบเอาเองนะครับ

Advertisements

10 thoughts on “เจาะระบบ Web App PHP/MySQL และการป้องกัน

  1. เพิ่มให้นิดนึง
    Password ที่เก็บอยู่ในฐานข้อมูล ควรทำการ encrypt เอาไว้ด้วย โดยใช้พวกฟังก์ชันที่หาย้อนกลับไม่ได้ เช่น hash เมื่อทำการ login ก็นำ password ที่ผู้ใช้กรอกมาทำ hash เหมือนกัน แล้วค่อยเช็คกับ password ที่เก็บในฐานข้อมูลอีกที

    อย่าให้เหมือนโซนี่หล่ะ โดนแฮกแล้วพบว่าไม่ได้ encrypt password ผู้ใช้

  2. ขอบคุณสำหรับความรู้ครับ ปกติผมใ้ช้ WordPress โดยปกติจะไม่ใช้ username ยอดนิยม เช่น admin และ ตั้ง limit การ login ผิดไว้ 3 ครั้ง ไว้เสมอ ก้องป้องกันได้ในระดับนึงครับ

  3. ขอบคุณมากครับ เป็นบทความที่มีประโยชน์มาก ๆ โดยเฉพาะ ตัวอย่าง script ที่มีมาให้ใน DVWA สามารถนำมาประยุกต์ใช้งานได้จริง

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s