หลังๆ มีข่าวเรื่องเว็ปโดนแฮก กันบ่อยมากทั้งต่างประเทศ และในไทยเราเอง เลยอยากจะแชร์ปัญหาด้าน Security ของ Web ที่เจอกันบ่อยๆ ให้ได้รู้กันไว้ จะได้ไม่เขียนเว็ปแบบส่งๆกัน (รับผิดชอบสังคมหน่อย) สิ่งที่ผมเขียนต่อไปนี้ถ้าใครตาม link ไปหรือนำไปคิดต่อยอดก็จะได้ประโยชน์มากมาย แต่ถ้าใครเอาไปใช้ในทางมิชอบก็ของแช่งไว้ล่วงหน้าเลยขอให้โดนจับ (ฮา... สาธุ้)
ก่อนอื่นก็มาดูสถิติกันก่อน ว่าการโจมตีผ่านเว็ป (ขอย้ำว่าผ่านเว็ปเท่านั้น) มีอะไรบ้างที่โดนกันบ่อยๆ ลองตามดูที่เว็ปนี้ได้ (Open Web Application Security Project) มีทั้งวิธีการ Attack และวิธีการป้องกันพร้อมเลย
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
สาเหตุที่มักจะทำให้เว็ปเป็นเป้าหมายหลักในการโจมตี
1. เป็นบริการที่เข้าถึงได้จากทุกที่ และสามารถเข้าถึงผ่าน Firewall ได้ (เพราะปกติเค้าไม่ block กัน)
2. เทคนิคใหม่ๆ ที่นำมาใช้เช่น AJAX, Java Scipt Framework ทำให้เกิดช่องโหว่ใหม่ๆ เพิ่มขึ้น
3. ความไม่ใส่ใจของนักพัฒนาเอง เช่นการจัดการกับ Exception, การ validate input ในฝั่ง Server
4. ความไม่ใส่ใจของ Host Owner ที่มองว่าเว็ปของตัวเองไม่ได้มีข้อมูลอะไร ใครจะแฮกไปคงไม่ได้อะไร
5. ความชะล่าใจ ว่า service หรือ url ของเราไม่สามารถเข้าถึงได้โดยคนอื่น
ทีนี้ลองมาดูการ Attack Web ยอดฮิตกันว่ามีอะไรบ้าง
SQL Injection , Script Injection
เกิดจากการไม่ตรวจสอบ input ที่รับเข้ามา หรือยอมรับ tag <script> หรือพวก <img src=""> เข้ามาในระบบของเราที่มีการจัดเก็บลงฐานข้อมูล และมีการแสดงผลออกมาในภายหลัง ตัวอย่าง
http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/ (ลองกันเองนะ แต่รับรองว่าได้ผลครับ)
ความอันตรายคือ ตั้งแต่การ bypass login ... การถูกฝัง script แปลกปลอมเข้ามาในระบบ จนถึงการลบฐานข้อมูล หรือเปลี่ยนสิทธิของ admin user
การป้องกัน เปลี่ยนมาใช้ prepared statement หรือพวก O/R Mapping อย่าง Hibernate, JPA แทนซึ่งพวกนี้จะมีการ filter input ที่รับเข้ามาอยู่แล้ว รวมถึงการใช้ Servlet Filter ในการ filter input ในการกรองข้อมูล (http://www.oracle.com/technetwork/java/filters-137243.html)
Force Browsing
เกิดจากการปล่อยให้บาง folder ไม่มีไฟล์ index หรือไม่มีการป้องกัน folder ในระดับสิทธิที่แตกต่างกัน สำหรับคนที่ชอบหา ebook ฟรี หรือพวก courseware ฟรี คงเคยหาผ่าน google กันแล้ว
อันตรายคือ attacker สามารถเดา path ที่นิยมตั้งกัน เช่น /admin , /install, /test, /log ... หรือแม้แต่การเดา URL parameter ทำให้สามารถเข้าถึงข้อมูลที่ระดับความสำคัญสูง (โดยเฉพาะพวกเว็ป CMS ที่มีให้ โหลด source ไปวิเคราะห์ได้)
การป้องกันคือ ให้สร้าง Security Filter และมีการตรวจสอบ session ของผู้ใช้ ว่ามีสิทธิในการเข้าถึง folder เหล่านั้นโดยตรงได้หรือไม่ ถ้าเป็นตระกูล Apache ก็สามารถ set ไฟล์ .htaccess ได้ และทุก folder ควรมีไฟล์ index.html เพื่อป้องกันการแสดง list ไฟล์โดยอัตโนมัติ (บาง webserver จะ set default ได้)
Bruteforce Password , Dictionary Attack
เกิดจากการที่ระบบไม่มี password policy ที่ดีพอ ยอมให้ user สามารถตั้งรหัสผ่านอย่างง่ายได้ ทำให้ attacker สามารถใช้ tools เช่น Brutus ในการยิง pattern ของ password เพื่อหารหัสผ่านของ user ใดๆ ได้
อันตรายคือถ้าระบบของเราไม่ได้มีพวก IDS (Intrusion Detection System) สำหรับตรวจจับ หรือไม่มีการ block รูปแบบการโจมตีในลักษณะ DoS (Denie Of Service) ก็จะสามารถถูกแกะรหัสผ่านของ admin ได้ (เค้าไม่ค่อยเอาของ user กัน ยิงทั้งทีต้อง root หรือ admin ไปเลย ไม่เสียเวลา)
การป้องกัน ในระดับ Programming คือ ควรเพิ่มกลไกในการตรวจสอบเช่น ถ้ามีการใส่รหัสผิดเกิน 3 ครั้ง ให้ล๊อก user นั้นไว้ ... การกำหนด passoword policy ว่าไม่ให้ตังรหัสสั้นกว่า 8 หลัก และต้องไม่อยู่ใน dictionary ของ hacker ... การเพิ่ม delay ของการ login หลังการใส่ password ผิด (ส่วนมาก delay ไว้ 30 นาที) ... การเพิ่มกลไกป้องกันการยิงโดย bot เช่น two factor login (ใช้พวก token) หรือการใช้ Capchar เข้ามาช่วย
Cross Site Script (XSS)
เกิดจากการที่ระบบไม่ได้ป้องกัน Script Injection โดยปล่อยให้สามารถฉีด tag script ที่สามารถส่งข้อมูลกลับไปยัง server ของ attacker ได้ เช่น password, keylog , sessionID ซึ่งเป้าหมายส่วนใหญ่จะเป็นเว็ปที่สามารถ post ข้อมูลลงไปได้ เช่น guestbook, webboard, forum ลองค้นใน google ดูนะใช้ keyword "XSS cheat sheet" มีของให้เล่นเพียบ
อันตรายที่เกิดขึ้น ตั้งแต่การถูกขโมยข้อมูล การถูก Phising หลอกให้กรอกข้อมูลสำคัญ การถูกขโมย session (กรณีที่คุณมีระดับสิทธิเป็น admin ละงานเข้าเลย)
การป้องกันคือ ให้ block การ input พวก tag <script> โดยอาจใช้วิธีง่ายๆเช่นการ replace เครื่องหมาย "<" ด้วย < และ ">" ด้วย > ก่อนที่จะเก็บลงฐานข้อมูล หรือเขียนเป็น Filter ก็ได้
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
** ที่สำคัญ Host owner ต้องคอยตรวจสอบ content ของตัวเองบ่อยๆว่ามีถูกฝัง XSS รึเปล่า
Cross Site Request Forgery (CSRF)
เกิดจาก การทำงานในลักษณะคล้ายๆ XSS แต่แทนที่จะส่งข้อมูลกลับไปที่ attacker site กลับเป็นการ submit form โดยตัว user เอง ตัวนี้ค่อนข้างใหม่ในไทย และโดนกันไปเยอะ ประเภทเปิดหน้าเว็ปธุรกรรม แล้วเปิดอีกแท๊ปไปดูข่าว (หน้าที่ถูกวาง CSRF) พอคลิ๊กกลับมาอีกทีกลายเป็นว่าเงินถูกโอนไปแล้ว ... เทคนิคที่ใช้ค่อนข้างอยู่ในระดับสูงคือ attacker จะสมัครสมาชิกเว็ปเป้าหมายเพื่อวิเคราะห์ Form ที่ใช้ในการทำธุรกรรมก่อน แล้วมาเขียน script ในการจำลอง input ที่จะ submit ข้อมูลที่ต้องการไปยัง site นั้นๆ ได้ เช่นเป้าหมายหลักอย่าง E-Banking พวกทำธุรกรรม online
อันตรายคือ เงินของคุณอาจถูกโอนเข้าบัญชีอื่น คุณอาจจะส่งเมล์หรือข้อความไปด่าเจ้านายคุณ โดยที่คุณไม่ได้เป็นคนส่ง คุณอาจจะเป็นคน post ข้อความที่เป็นภัยกับตัวคุณเองโดยไม่ได้ทำเอง
การป้องกันในฐานะนักพัฒนาคือการ เพิ่ม token ให้กับ Form เพื่อให้มีการสร้างรหัส token ใหม่ทุกครั้งเมื่อเรียกใช้งาน Form หรือใช้พวก Capchar มาช่วยทำให้การยิงด้วย script ทำไม่ได้เนื่องจากรหัสของเราเปลี่ยนไปเรื่อยๆ ส่วนของ user ก็พยายามอย่าเปิดเว็ปด้วย Tab (ตอนนี้มันถือว่าอยู่ session เดียวกัน) ถ้ายังอยู่ในหน้าธุรกรรมสำคัญหรือควร logout ก่อน
จริงๆ ยังมีอีกเยอะ และรายละเอียดอีกเยอะ หวังว่าคงจุดประกายให้ web dev ทั้งหลายเริ่มหันมารับผิดชอบสิ่งที่ตัวเองทำกันบ้าง ไม่ใช่โทษแต่ server หรือ user อย่างเดียว
ของฝาก เครื่องมือแนะนำ สำหรับทดสอบเว็ปของเรา
- Vega Scanner ตัวนี้ของดี และเป็นของฟรีด้วย แถมยังแนะนำวิธีแก้ไขโดย link ไปที่ OWASP.org
- FireFox + Plug-in เช่น Firebug, Cookie Manager, Tamper, XSS Me, SQL Inject Me, HackBar
**หาไม่ยากลองค้นดูใน Google เองละกัน
การเป็นคนเก่ง กับเป็นคนดีนั้นต่างกัน ...เพราะคนดีจะรับผิดชอบสิ่งที่เค้าสร้าง ไม่ทำให้คนอื่นเดือดร้อน
Aj.Bee
ได้ความรู้มากๆเลยครับอาจารย์ บูชาๆ
ตอบลบ