ACIS Article

เรียนรู้วิธีการเจาะระบบ Web Application ทั้ง 10 วิธี ของแฮกเกอร์ และวิธีการป้องกันอย่างได้ผล (ตอนจบ) Top 10 Web Application Hacking and How to Protect from Hackers Part II
by A.Pinya Hom-anek, GCFW, CISSP, CISA
ACIS Professional Team
E-mail:

จากบทความในตอนที่แล้ว เราได้เรียนรู้วิธีการเจาะระบบผ่านทะลุ Firewall ทาง Port TCP 80 (http) และ TCP 443 (https) ทั้ง 5 วิธีแล้ว สำหรับวิธีที่ 6 ถึง 10 มีรายละเอียดดังนี้

6. Injection Flaws

หมายถึง แฮกเกอร์สามารถที่จะแทรก Malicious Code หรือ คำสั่งที่แฮกเกอร์ใช้ในการเจาะระบบส่งผ่าน Web Application ไปยังระบบภายนอกที่เราเชื่อมต่ออยู่ เช่น ระบบฐานข้อมูล SQL โดยวิธี SQL Injection หรือ เรียก External Program ผ่าน shell command ของระบบปฎิบัติการ เป็นต้น

ส่วนใหญ่แล้วแฮกเกอร์จะใช้วิธีนี้ในช่วงการทำ Authentication หรือการ Login เข้าระบบผ่านทาง Web Application เช่น Web Site บางแห่งชอบใช้ "/admin" ในการเข้าสู่หน้า Admin ของ ระบบ ซึ่งเป็นช่องโหว่ให้แฮกเกอร์สามารถเดาได้เลยว่า เราใช้ http://www.mycompany.com/admin ในการเข้าไปจัดการบริหาร Web Site ดังนั้นเราจึงควรเปลี่ยนเป็นคำอื่นที่ไม่ใช่ "/admin" ก็จะช่วยได้มาก

วิธีการทำ SQL injection ก็คือ แฮกเกอร์จะใส่ชื่อ username อะไรก็ได้แต่ password สำหรับการทำ SQL injection จะใส่เป็น Logic Statement ยกตัวอย่างเช่น ' or '1' = '1 หรือ " or "1"= "1

ถ้า Web Application ของเราไม่มีการเขียน Input Validation ดัก password แปลกๆ แบบนี้ แฮกเกอร์ก็สามารถที่จะ bypass ระบบ Authentication ของเราและ Login เข้าสู่ระบบเราโดยไม่ต้องรู้ username และ password ของเรามาก่อนเลย

วิธีการเจาะระบบด้วย SQL injection ยังมีอีกหลายแบบจากที่ยกตัวอย่างมา ซึ่งแฮกเกอร์รุ่นใหม่สามารถเรียนรู้ได้ทางอินเทอร์เน็ตและวิธีการทำก็ไม่ยาก อย่างที่ยกตัวอย่างมาแล้ว

วิธีการป้องกัน

นักพัฒนาระบบ (Web Application Developer) ควรจะระมัดระวัง input string ที่มาจากทางฝั่ง Client (Web Browser) และไม่ควรใช้วิธีติดต่อกับระบบภายนอกโดยไม่จำเป็น

ควรมีการ "กรอง" ข้อมูลขาเข้าที่มาจาก Web Browser ผ่านมาทางผู้ใช้ Client อย่างละเอียด และ ทำการ "กรอง" ข้อมูลที่มีลักษณะที่เป็น SQL injection statement ออกไปเสียก่อนที่จะส่งให้กับระบบฐานข้อมูล SQL ต่อไป

การใช้ Stored Procedure หรือ Trigger ก็เป็นทางออกหนึ่งในการเขียนโปรแกรมสั่งงานไปยังระบบฐานข้อมูล SQL ซึ่งมีความปลอดภัยมากกว่าการใช้ "Dynamic SQL Statement " กับฐานข้อมูล SQL ตรงๆ

7. Improper Error Handling

หมายถึง มีการจัดการกับ Error message ไม่ดีพอ เวลาที่มีผู้ใช้ Web Application หรืออาจจะเป็นแฮกเกอร์ลองพิมพ์ Bad HTTP Request เข้ามาแต่ Web Server หรือ Web Application ของเราไม่มีข้อมูล จึงแสดง Error message ออกมาทางหน้า Browser ซึ่งข้อมูลที่แสดงออกมาทำให้แฮกเกอร์สามารถใช้เป็นประโยชน์ ในการนำไปเดาเพื่อหาข้อมูลเพิ่มเติมจากระบบ Web Application ของเราได้ เนื่องจากเมื่อการทำงานของ Web application หลุดไปจากปกติ ระบบมักจะแสดงค่า Error Message ออกมาแสดงถึงชื่อ user ที่ใช้ในการเข้าถึงฐานข้อมูล, แสดง File System Path หรือ Sub Directory Name ที่ชี้ไปยังไฟล์ฐานข้อมูล ตลอดจนทำให้แฮกเกอร์รู้ว่าเราใช้ระบบอะไรเป็นฐานข้อมูลเช่น ใช้ MySQL เป็นต้น

วิธีการแก้ปัญหา

ควรมีการกำหนดนโยบายการจัดการกับ Error message ให้กับระบบ โดยทำหน้า Error message ที่เตรียมไว้รับเวลามี Bad HTTP Request แปลกๆ เข้ามายัง Web Application ของเราโดยหน้า Error message ที่ดีไม่ควรจะบอกให้ผู้ใช้รู้ถึงข้อมูลระบบบางอย่างที่ผู้ใช้ทั่วไปไม่ควรรู้และถ้าผู้ใช้คนนั้นเป็นแฮกเกอร์ซึ่งย่อมมีความรู้มากกว่าผู้ใช้ธรรมดา การเห็นข้อมูล Error message ก็อาจนำไปใช้เป็นประโยชน์สำหรับแฮกเกอร์ได้

8. Insecure Storage

หมายถึง การเก็บรหัสผ่าน (password), เบอร์บัตรเครดิตลูกค้า หรือ ข้อมูลลับของลูกค้า ไว้อย่างไม่มีความปลอดภัยเพียงพอ ส่วนใหญ่จะเก็บแบบมีการเข้ารหัส (Encryption) ไว้ในฐานข้อมูลหรือ เก็บลงในไฟล์ที่อยู่ใน Web server และคิดว่าเมื่อเข้ารหัสแล้วแฮกเกอร์คงไม่สามารถอ่านออก แต่ สิ่งที่เราคิดนับว่าเป็นการประเมินแฮกเกอร์ต่ำเกินไป เนื่องจากอาจเกิดข้อผิดพลาดในการเข้ารหัส เช่น การเข้ารหัสนั้นใช้ Algorithm ที่อ่อนเกินไป ทำให้แฮกเกอร์แกะได้ง่ายๆ หรือมีการเก็บกุญแจ (key) หรือ รหัสลับ (Secret password) ไว้เป็นไฟล์แบบง่ายๆ ที่แฮกเกอร์ สามารถเข้าถึงได้ หรือ สามารถถอดรหัสได้โดยใช้เวลาไม่มากนัก

วิธีการแก้ไข

ควรมีการเข้ารหัสไฟล์ โดยใช้ Encryption Algorithm ที่ค่อนข้างซับซ้อนพอสมควร หรือแทนที่จะเก็บรหัสผ่านที่เข้ารหัสไว้ ให้หันมาเก็บค่า Message Digest หรือ ค่า "HASH" ของรหัสผ่านทาง โดยใช้ Algorithm SHA-1 เป็นต้น

การเก็บกุญแจ (key), ใบรับรอง ดิจิตัล (Digital Certificate) หรือ ลายมือชื่อดิจิตัล (Digital Signature) ควรเก็บไว้อย่างปลอดภัย เช่น เก็บไว้ใน Token หรือ Smart Card ก็จะปลอดภัยกว่าการเก็บไว้เป็นไฟล์ในฮาร์ดดิสค์ เป็นต้น (ถ้าเก็บเป็นไฟล์ก็ควรทำการเข้ารหัสไว้ทุกครั้ง)

9. Denial of Service

หมายถึงระบบ Web Application หรือ Web Server ของเรา อาจหยุดทำงานได้เมื่อเจอกับ Bad HTTP Request แปลกๆ หรือ มีการเรียกเข้ามาอย่างต่อเนื่องจำนวนมาก ทำให้เกิดการจราจรหนาแน่นบน Web Server ของเรา โดยปกติ Web Server จะจัดการกับ Concurrent session ได้จำนวนหนึ่ง ถ้ามี HTTP Request เข้ามาเกินค่าที่ Web Server จะสามารถรับได้ ก็จะเกิด Error ขึ้น ทำให้ผู้ใช้ไม่สามารถเข้า Web Site เราได้ นอกจากนี้ อาจจะทำให้เครื่องเกิด CPU Overload หรือ Out of Memory ก็เป็นรูปแบบหนึ่งของ Denial of Service เช่นกัน กล่าวโดยรวมก็คือ ทำให้ระบบของเรามีปัญหาเรื่อง "Availability"

วิธีการแก้ไข การป้องกัน DoS หรือ DDoS Attack นั้นไม่ง่าย และ ส่วนใหญ่ ไม่สามารถป้องกันได้ 100% การติดตั้ง Hardware IPS (Intrusion Prevention System) เป็นอีกทางเลือกหนึ่ง แต่ก็มีค่าใช้จ่ายค่อนข้างสูง หากต้องการประหยัดงบประมาณก็ควรต้อง ทำการ "Hardening" ระบบให้เรียบร้อย เช่น Network OS ที่ใช้อยู่ก็ควรจะลง Patch อย่างสม่ำเสมอ, Web Server ก็เช่นเดียวกัน เพราะมีช่องโหว่ เกิดขึ้นเป็นประจำ ตลอดจนปรับแต่งค่า Parameter บางค่าของ Network OS เพื่อให้รองรับกับการโจมตีแบบ DoS /DDoS Attack

10. Insecure Configuration Management

หมายถึง เป็นปัญหาที่เกิดขึ้นจากผู้ดูแลระบบ หรือ ผู้ติดตั้ง Web Server มักจะติดตั้งในลักษณะ "Default Configuration" ซึ่งยังคงมีช่องโหว่มากมาย หรือบางครั้งก็ไม่ได้ทำการ Update Patch ระบบให้ครบถ้วนจนถึง Patch ล่าสุด

ปัญหาที่เจอบ่อยๆ ก็คือมีการกำหนดสิทธิในการเข้าถึงไฟล์ต่างๆ ใน Web Server ไม่ดีพอทำให้มีไฟล์หลุดออกมาให้ผู้ใช้เข้าถึงได้ เช่น แสดงออกมาในลักษณะ "Directory Browsing" ตลอดจนค่า default ต่างๆ ไม่ว่าจะเป็น Default Username และ Default Password ก็มักจะถูกทิ้งไว้โดยไม่ได้เปลี่ยนอยู่เป็นประจำ

วิธีการแก้ปัญหา

ให้ทำการแก้ไขค่า "Default" ต่างๆ ทันทีที่ติดตั้งระบบเสร็จ และทำการ Patch ระบบให้จถึง Patch ล่าสุด และ ตาม Patch อย่างสม่ำเสมอ เรียกว่า ทำการ "Hardening" ระบบนั่นเอง Services ใดที่ไม่ได้ใช้ก็ไม่ต้องเปิดบริการ เราควรตรวจสอบสิทธิ File and Subdirectory Permission ในระบบว่าตั้งไว้ถูกต้อง และ ปลอดภัยหรือไม่ ตลอดจนเปิดระบบ Web Server log file เพื่อที่จะได้สามารถตรวจสอบ (Audit) HTTP Request ที่ส่งมายัง Web Server ได้ โดยดูจาก Web Server log file ที่เราได้เปิดไว้ และ เราควรหมั่นติดตามข่าวสารเรื่องช่องโหว่ (Vulnerability) ใหม่ๆ อย่างสม่ำเสมอ และ มีการตรวจวิเคราะห์ Web Server log file, Network log file, Firewal log file และ IDS/IPS log file เป็นระยะๆ

จะเห็นได้ว่าแฮกเกอร์ในปัจจุบันสามารถเจาะระบบเราโดยผ่านทะลุ Firewall ได้อย่างง่ายดาย เพราะ เรามีความจำเป็นต้องเปิดให้บริการ Web Server ในทุกองค์กร ดังนั้นการตรวจสอบเรื่องของ Web Application Source Code และ Web Server Configuration จึงเป็นทางออกสำหรับการแก้ไขปัญหาทางด้านความปลอดภัยของระบบให้รอดพันจากเหล่าไวรัสและแฮกเกอร์ซึ่งนับวันจะเพิ่มจำนวนและเพิ่มความสามารถขึ้นเป็นทวีคูณ.

จาก : หนังสือ eWeek Thailand
ปักษ์หลัง เดือนมิถุนายน 2547
Update Information : 17 มิถุนายน 2547