SQL Injection กับความเชื่อผิดๆ

พอดีวันนี้ไปค้นเจอบทความเก่าๆที่เคยเขียนไว้สมัยเป็น Consult ด้านความปลอดภัย ซึ่งก็ประมาณปีกว่าๆละ แต่รู้สึกว่าบทความนี้ก็ยังคงใช้ได้อยู่ในปัจจุบัน เลยนำมาสรุปสั้นๆให้เข้าใจง่ายๆกันครับ เป็นบทความเกี่ยวกับ SQL Injection หรือ SQLi ซึ่งเป็นรูปแบบการโจมตีฐานข้อมูลประเภทหนึ่งซึ่งเป็นที่โด่งดังและรุนแรงมาก ประมาณว่าใครไม่รู้จักนี่เช๊ย เชย แล่ะตัวเธอว์ มาเริ่มกันเลยครับ

SQL Injection คืออะไร ??

SQL Injection เป็นเทคนิคที่ใช้ประโยชน์จากส่งคำสั่ง SQL ผ่านทางเว็บแอพพลิเคชันเพื่อไปโจมตีระบบฐานข้อมูลหลังบ้าน โดยอาศัยช่องโหว่ของการใส่ข้อมูล input ของผู้ใช้ที่สามารถตรวจสอบรูปแบบการโจมตีได้อย่างจำกัด แฮ็คเกอร์รู้ดีว่านักเขียนโปรแกรมจะนำข้อมูลที่ผู้ใช้ input ลงไป ไปใช้เป็นส่วนหนึ่งของคำสั่ง SQL เพื่อส่งไปยังระบบฐานข้อมูล จึงได้แอบฝังคำสั่ง SQL บางอย่างลงไปใน input เหล่านั้นด้วย ส่งผลให้แฮ็คเกอร์สามารถดึงข้อมูลหรือเปลี่ยนแปลงแก้ไขข้อมูลในระบบฐานข้อมูลตามคำสั่ง SQL ที่แอบฝังลงไปได้ทันที ยกตัวอย่างง่ายๆที่พบเห็นบ่อยๆ คือ “OR 1=1” ที่นิยมใช้เพื่อบายพาสการพิสูจน์ตัวตน ปกติแล้วหน้าพิสูจน์ตัวตนจะมีช่องให้ใส่ชื่อผู้ใช้และรหัสผ่าน ซึ่งนักเขียนโปรแกรมก็จะนำข้อมูลที่ผู้ใช้กรอกลงไป ไปตรวจสอบกับระบบฐานข้อมูลโดยใช้คำสั่ง

SELECT * FROM authen_db WHERE username=‘suthee’ and password=‘12345678’;

เพื่อเช็คดูว่าในฐานข้อมูลการพิสูจน์ตัวตน (authen_db) มีชื่อผู้ใช้และรหัสผ่านตรงตามที่ผู้ใช้กรอกลงไปหรือไม่ ซึ่งเมื่อแฮ็คเกอร์รู้ว่าต้องมีการนำข้อมูลที่ผู้ใช้กรอกลงไป (ในที่นี้คือ suthee และ 12345678) ส่งไปยังระบบฐานข้อมูลโดยตรง จึงได้แอบฝังคำสั่ง SQL ลงไปเพื่อหลีกเลี่ยงการตรวจสอบ คือ การใส่ชื่อผู้ใช้เป็น “admin” และรหัสผ่านเป็น “‘ OR ‘1’=‘1” ส่งผลให้คำสั่ง SQL ที่ใช้ตรวจสอบเพื่อพิสูจน์ตัวตนก็จะกลายเป็น

SELECT * FROM authen_db WHERE username=‘admin’ and password=‘’ OR ‘1’=‘1’;

ผลลัพธ์ที่ได้ คือ แฮ็คเกอร์สามารถลงชื่อเข้าใช้เป็น “admin” ได้ทันที เนื่องจากด้านหลังมีนิพจน์ OR 1=1 ทำให้คำสั่ง SQL ดังกล่าวเป็นจริงเสมอ นอกจากการบายพาสการพิสูจน์ตัวตนแล้ว SQL Injection ยังสามารถดึงข้อมูล, เปลี่ยนแปลงแก้ไข, ลบข้อมูล หรือทำลายฐานข้อมูลทั้งหมด ขึ้นอยู่กับคำสั่ง SQL ที่แอบฝังลงไปได้เช่นกัน

ความเชื่อผิดๆเกี่ยวกับ SQL Injection

ทั้งๆที่ปัญหา SQL Injection มีทางออกให้แล้วเป็นเวลามากกว่า 10 ปี โดยการใช้เว็บแอพพลิเคชันไฟร์วอลล์และการตรวจสอบโค้ดอย่างรอบคอบ อย่างไรก็ตาม เรายังคงพบว่าการรั่วไหลของข้อมูลส่วนใสญ่ โดยเฉพาะบัตรเครดิต ยังคงเกิดจาก SQL Injection อยู่ดี เนื่องมาจาก

• ความเข้าใจผิดของทีมรักษาความปลอดภัยที่คิดว่าอุปกรณ์ IPS โดยทั่วไป รวมทั้ง Next Generation Firewall/IPS สามารถป้องกันการโจมตีแบบ SQL Injection ได้ เนื่องจากอุปกรณ์เหล่านี้เน้นไปที่การตรวจจับการโจมตีตามรูปแบบที่มีอยู่ในฐานข้อมูล (Signature-based) เป็นหลัก ซึ่งเป็นไปไม่ได้ที่จะตรวจจับ SQL Injection ที่สามารถระบุคำสั่ง SQL ได้อย่างหลากหลาย รวมทั้งคำสั่งที่ฝังลงไปก็เป็นเพียงแค่ข้อความภาษาอังกฤษทั่วไปที่ผู้ใช้กรอกลงไปเท่านั้น
• ประโยคเด็ดที่ว่า “บริษัทเราเป็นบริษัทเล็กๆ ไม่ตกเป็นเป้าหมายหรอกน่า” ก็เป็นแนวคิดที่ผิดอย่างมาก ไม่ว่าจะเป็นข้อมูลบัตรเครดิตของบริษัทขนาดใหญ่ หรือขนาดเล็กก็มีค่าเท่ากันในสายตาของแฮ็คเกอร์ แถมบริษัทเล็กๆนี่ระบความปลอดภัยไม่สูงมากนี่แล่ะ คือเหยื่ออันโอชะโดยแท้จริง

รู้อย่างนี้แล้ว ก็อย่าหวังพึ่งดวงหรืออุปกรณ์ Firewall/IPS มากจนเกินไปนะครับ ทีมงาน TechTalkThai แนะนำว่า บริษัทไหนที่ใช้เว็บแอพพลิเคชันเป็นหนึ่งในระบบสำคัญในการทำธุรกิจ ก็ควรต้องพิจารณาถึงความปลอดภัยของเว็บไซต์ด้วย ถึงแม้ว่าอาจจะยังไม่มีงบประมาณเพียงพอในการติดตั้งอุปกรณ์เว็บแอพพลิเคชันไฟร์วอลล์ อย่างน้อยการเขียนโค้ดตรวจสอบข้อมูล input จากผู้ใช้งานก็สามารถช่วยกรอง SQL Injection รวมไปถึง XSS ได้ในระดับหนึ่ง สำหรับท่านที่สนใจโซลูชันเว็บแอพพลิเคชันไฟร์วอลล์ ปัจจุบันมีหลากหลายยี่ห้อในตลาดให้เลือกสรร ไม่ว่าจะเป็น Fortinet, SonicWall, Barracuda แต่ที่เป็นที่นิยมและได้รับการยอมรับอย่างมากในเขตภูมิภาค Asia Pacific คงหนีไม่พ้น Imperva และ F5 Networks ครับ