10 วิธี เจาะระบบ Web Application Hacking ของ Hacker

10 วิธี เจาะระบบ Web Application Hacking ของ Hacker

ทุกวันนี้ คงไม่มีบริษัทใดที่ไม่มี Website เป็นของตัวเอง บางบริษัทอาจจะเช่า Web Hosting อยู่ หรือ บางบริษัทอาจมี Web Site เป็นของตนเองอยู่ในระบบเครือข่ายของบริษัท โดยมีการต่อเชื่อมเครือข่ายของบริษัทด้วย Frame Relay, ADSL หรือ Leased Line เข้ากับระบบเครือข่ายของ ISP ซึ่งส่วนใหญ่ก็จะมีการจัดซื้อ Firewall มาใช้ป้องกันระบบเครือข่ายภายในของบริษัท กับ ระบบอินเทอร์เน็ตจาก ISP และ มีการเปิดให้คนภายนอกสามารถเข้ามาเยี่ยมชม Web Site ได้ โดยเปิด Port TCP 80 (http) และ Port TCP 443 (https) ในกรณีที่ใช้โปรโตคอล SSL ในการเข้ารหัสข้อมูลเพื่อเพิ่มความปลอดภัยมากยิ่งขึ้น
ปัญหาก็คือ ในเมื่อทุกบริษัทต้องเปิดทางให้มีการเข้าชม Web Site ทั้งแบบ Plain text traffic (Port 80) และแบบ Encrypted text traffic (port 443) ทำให้แฮกเกอร์สามารถจู่โจม Web Site ของเราโดยไม่ต้องเจาะผ่าน Firewall เนื่องจากเป็น Port ที่ Firewall มีความจำเป็นต้องเปิดใช้อยู่แล้ว ในโลกของ E-Commerce มีอัตราการใช้งาน Web Server ที่เพิ่มขึ้นทุกวัน (ดูข้อมูลจากwww.netcraft.com) และ จากข้อมูลของ UNCTAD (http://www.unctad.org) พบว่า Web Server ทั่วโลก มีทั้งแบบที่เข้ารหัสด้วย SSL แล้ว และ แบบไม่เข้ารหัสด้วย SSL ก็ยังคงมีใช้กันอยู่ ในเมื่อแฮกเกอร์มองเห็นช่องที่เรามีความจำเป็นต้องเปิดใช้งานผ่านทาง Web Server และ Web Application แฮกเกอร์ในปัจจุบันจึงใช้วิธีที่เรียกว่า ?Web Application Hacking? ในการเจาะเข้าสู่ระบบขององค์กรต่างๆ ทั่วโลก ขณะนี้มีการจู่โจมระบบโดยกลุ่มแฮกเกอร์ที่ต้องการทำสถิติ ในการเจาะ Web Site ดูรายละเอียดได้ที่ http://www.zone-h.org ดังนั้น ผู้ที่มี Web Site อยู่ และ โดยเฉพาะผู้ที่ต้องการหันมาทำธุรกิจในลักษณะของ E-commerce ซึ่งต้องมี Web Site ที่ใช้ Web server ที่เชื่อถือได้ และมีการเขียน Web application โดยคำนึงถึงเรื่อง ?Security? เป็นหลัก จึงมีความจำเป็นอย่างยิ่งที่ต้องเรียนรู้ช่องโหว่ (Vulnerability) ของ Web application ที่แฮกเกอร์ชอบใช้ในการเจาะระบบ Web application ของเราซึ่งรวบรวมได้ทั้งหมด 10 วิธีด้วยกัน (Top 10 Web Application Hacking) ตลอดจนเรียนรู้วิธีการป้องกันที่ถูกต้อง เพื่อที่จะไม่ให้ตกเป็นเหยื่อของเหล่าแฮกเกอร์ที่จ้องคอยเจาะระบบเราอยู่ ผ่านทาง Web Site ที่ยังไงเราก็ต้องเปิดให้เข้าถึง และ ยังมี Virus Worm ตัวใหม่ๆ ที่เขียนขึ้นเพื่อจู่โจม Port 80 (HTTP)และ Port 443 (SSL) โดยเฉพาะอีกด้วย รายละเอียดของ Top 10 Web Application Hacking มี 10 วิธี ดังนี้

1.Unvalidated Input

หมาย ถึง การที่ข้อมูลจากฝั่ง client ที่ส่วนใหญ่แล้ว จะมาจาก Internet Explorer (IE) Browser ไม่ได้รับการตรวจสอบก่อนถูกส่งมาประมวลผลโดย Web Application ที่ทำงานอยู่บน Web Server ทำให้แฮกเกอร์สามารถดักแก้ไขข้อมูลในฝั่ง clientก่อน ที่จะถูกส่งมา ยังฝั่ง server โดยใช้โปรแกรมที่สามารถดักข้อมูลได้ เช่น โปรแกรม Achilles เป็นต้น ดังนั้น ถ้าเรารับข้อมูลจากฝั่ง client โดยไม่ระมัดระวัง หรือ คิดว่าเป็นข้อมูลที่เราเป็นคนกำหนดเอง เช่น เทคนิคการใช้ Hidden Field หรือ Form Field ตลอดจนใช้ข้อมูลจาก Cookies เราอาจจะโดนแฮกเกอร์แก้ไขข้อมูลฝั่ง client ด้วย โปรแกรมดังกล่าวแล้วส่งกลับมาฝั่ง server ในรูปแบบที่แฮกเกอร์ต้องการ และมีผลกระทบกับการทำงานของ Web Application ในฝั่ง web server

วิธีการป้องกัน
เรา ควรจะตรวจสอบข้อมูลที่รับมาจากทั้ง 2 ฝั่ง คือ ข้อมูลที่รับมาจาก client ผ่านทาง Browser และข้อมูลที่รับมาประมวลผลที่ web server โดยตรวจสอบที่ web server อีกครั้งก่อนนำไปประมวลผลด้วย Web application เราควรมีการฝึกอบรม Web Programmer ของเราให้ระมัดระวังในการรับ input จากฝั่ง client ตลอดจนมีการ Review Source code ไม่ว่าจะเขียนด้วย ASP, PHP หรือ JSP Script ก่อนที่จะนำไปใช้งานในระบบจริง ถ้ามีงบประมาณด้านรักษาความปลอดภัย ก็แนะนำให้ใช้ application level firewall หรือ Host-Based IDS/IPS ที่สามารถมองเห็น Malicious content และป้องกันในระดับ application layer

2. Broken Access Control

หมาย ถึง มีการป้องกันระบบไม่ดีพอเกี่ยวกับการกำหนดสิทธิของผู้ใช้ (Permission) ที่สามารถจะ Log-in /Log-on เข้าระบบ Web application ได้ ซึ่งผลที่ตามมาก็คือ ผู้ที่ไม่มีสิทธิเข้าระบบ (Unauthorized User) สามารถเข้าถึงข้อมูลที่เราต้องการป้องกันไว้ไม่ให้ Unauthorized User เข้ามาดูได้ เช่น เข้ามาดูไฟล์ข้อมูลบัตรเครดิตลูกค้าที่เก็บอยู่ใน Web Server หรือ เข้าถึงไฟล์ข้อมูลในลักษณะ ฏDirectory Browsing โดยเห็นไฟล์ทั้งหมดที่อยู่ใน web Server ของเรา ปัญหานี้เกิดจากการกำหนด File Permission ไม่ดีพอ และ อาจเกิดจากปัญหาที่เรียกว่า "Path
Traversal" หมายถึง แฮกเกอร์จะลองสุ่มพิมพ์ path หรือ sub directory ลงไปในช่อง URL เช่น http://www.abc.com/../../customer.mdb เป็นต้น นอกจากนี้อาจเกิดจากปัญหาการ cache ข้อมูลในฝั่ง client ทำให้ข้อมูลที่ค้างอยู่ cache ถูกแฮกเกอร์เรียกกลับมาดูใหม่ได้ โดยไม่ต้อง Log-in เข้าระบบก่อน

วิธีการป้องกัน
พยายามอย่าใช้ User ID ที่ง่ายเกินไป และ Default User ID ที่ง่ายต่อการเดา โดยเฉพาะ User ID ที่เป็นค่า default ควรลบทิ้งให้หมด สำหรับปัญหา Directory Browsing หรือ Path Traversal นั้น ควรมีการ set file system permission ให้รัดกุม เพื่อป้องกัน ช่องโหว่ที่อาจถูกโจมตี และ ปิด file permission ใน sub directory ต่างๆ ที่ไม่ได้ใช้ และ ไม่มีความจำเป็นต้องให้คนภายนอกเข้า เพื่อป้องกันแฮกเกอร์สุ่มพิมพ์ path เข้ามาดึงข้อมูลได้ และควรมีการตรวจสอบ Web Server log file และ IDS/IPS log file เป็นระยะๆ ว่ามี Intrusion หรือ Error แปลกๆ
หรือไม่

3. Broken Authentication and Session Management

หมาย ถึง ระบบ Authentication ที่เราใช้อยู่ในการเข้าถึง Web Application ของเรานั้นไม่แข็งแกร่งเพียงพอ เช่น การตั้ง Password ง่ายเกินไป, มีการเก็บ Password ไว้ในฝั่ง Client โดยเก็บเป็นไฟล์ Cookie ที่เข้ารหัสแบบไม่ซับซ้อนทำให้แฮกเกอร์เดาได้ง่าย หรือใช้ชื่อ User ที่ง่ายเกินไป เช่น User Admin เป็นต้น บางทีก็ใช้ Path ที่ง่ายต่อการเดาได้ เช่น www.abc.com/admin หมายถึง การเข้าถึงหน้า admin ของระบบ แฮกเกอร์สามารถใช้โปรแกรมประเภท Dictionary Attack หรือ Brute Force Attack ในการลองเดาสุ่ม Password ของระบบ Web Application ของเรา ตลอดจนใช้โปรแกรมประเภท Password Sniffer ดักจับ Password ที่อยู่ในรูปแบบ Plain Text หรือ บางทีแฮกเกอร์ก็ใช้วิธีง่ายๆ ในการขโมย Password เรา โดยแกล้งปลอมตัวเป็นเรา แล้วแกล้งลืม Password (Forgot Password) ระบบก็จะถามคำถามกลับมา ซึ่งถ้าคำถามนั้นง่ายเกินไป แฮกเกอร์ก็จะเดาคำตอบได้ไม่ยากนัก ทำให้แฮกเกอร์ได้ Password เราไปในที่สุด

วิธีการป้องกัน
ที่ สำคัญที่สุด คือการตั้งชื่อ User Name และ Password ควรจะมีความซับซ้อน ไม่สามารถเดาได้ง่าย มีความยาวไม่ต่ำกว่า 8 ตัวอักษร และมีข้อกำหนดในการใช้ Password (Password Policy) ว่าควรมีการเปลี่ยน Password เป็นระยะๆ ตลอดจนให้มีการกำหนด Account Lockout เช่น ถ้า Logon ผิดเกิน 3 ครั้ง ก็ให้ Lock Account นั้นไปเลยเป็นต้น การเก็บ Password ไว้ในฝั่ง Client นั้น ค่อนข้างที่จะอันตราย ถ้ามีความจำเป็นต้องเก็บในฝั่ง Client จริงๆ ก็ควรมีการเข้ารหัสที่ซับซ้อน (Hashed or Encrypted) ไม่สามารถถอดได้ง่ายๆ การ Login เข้าระบบควร
ผ่านทาง https protocol คือ มีการใช้ SSL เข้ามาร่วมด้วย เพื่อเข้ารหัส Username และ Password ให้ปลอดภัยจากพวกโปรแกรม Password Sniffing ถ้ามีงบประมาณควรใช้ Two-Factor Authentication เช่น ระบบ One Time Password ก็จะช่วยให้ปลอดภัยมากขึ้น การใช้ SSL ควรใช้ Digital Certificate ที่ได้รับการ Sign อย่างถูกต้องโดย CA (Certificate Authority) ถ้าเราใช้ CA แบบ Self Signed จะทำให้เกิดปัญหา Man in the Middle Attack (MIM) ทำให้แฮกเกอร์สามารถเจาะข้อมูลเราได้แม้ว่าเราจะใช้ SSL แล้วก็ตาม (ข้อมูลเพิ่มเติมที่เกี่ยวข้องกับ SSL Hacking ดูที่ acisonline.net)

4. Cross Site Scripting (XSS) Flaws

หมาย ถึง แฮกเกอร์สามารถใช้ Web Application ของเรา เช่น ระบบ Web Board ในการฝัง Malicious Script แฝงไว้ใน Web Board แทนที่จะใส่ข้อมูลตามปกติ เมื่อมีคนเข้า Refresh หน้า Web Board ก็จะทำให้ Malicious Script ที่ฝังไว้นั้นทำงานโดยอัตโนมัติ ตามความต้องการของแฮกเกอร์ หรือ อีกวิธีหนึ่ง แฮกเกอร์จะส่ง e-mail ไปหลอกให้เป้าหมาย Click ไปที่ URL Link ที่แฮกเกอร์ได้เตรียมไว้ใน e-mail เมื่อเป้าหมาย Click ไปที่ Link นั้น ก็จะไปสั่ง Run Malicious Script ที่อยู่ในตำแหน่งที่แฮกเกอร์ทำดักรอไว้ วิธีการหลอกแบบนี้ในวงการเรียกว่า
"PHISHING" ซึ่งโดนกันไปแล้วหลายองค์กร เช่น Citibank, eBay เป็นต้น (ข้อมูลเพิ่มเติมดูได้ที่ acisonline.net)

วิธีการป้องกัน
อย่าง แรกเลยต้องมีการให้ข้อมูลกับผู้ใช้คอมพิวเตอร์ทั่วไป ที่ใช้ e-mail และ web browser กันเป็นประจำให้ระมัดระวัง URL Link แปลกๆ หรือ e-mail แปลกๆ ที่เข้ามาในระบบก่อนจะ Click ควรจะดูให้รอบคอบก่อน เรียกว่า เป็นการทำ "Security Awareness Training" ให้กับ User ซึ่งควรจะทำทุกปี ปีละ 2-3 ครั้ง เพื่อให้รู้ทันกลเม็ดของแฮกเกอร์ และไวรัสที่ชอบส่ง e-mail มาหลอกอยู่เป็นประจำ สำหรับในฝั่งของผู้ดูและระบบ เช่น Web Master ก็ควรจะแก้ไข source codeใน Web Board ของตนให้ฉลาดพอที่จะแยกแยะออกว่ากำลังรับข้อมูลปกติ หรือรับข้อมูลที่
เป็น Malicious Script ซึ่งจะสังเกตได้ไม่ยาก เพราะ Script มักจะมีเครื่องหมาย "< > ( ) # & " ให้ Web Master ทำการ "กรอง" เครื่องหมายเหล่านี้ก่อนที่จะนำข้อมูลไปประมวลผลโดย Web application ต่อไป

5. Buffer Overflow

หมาย ถึง ในฝั่งของ Client และ Server ไม่ว่าจะเป็น IE Browser และ IIS Web Server หรือ Netscape Browser และ Apache Web Server ที่เราใช้กันอยู่เป็นประจำ ล้วนมีช่องโหว่ (Vulnerability) หรือ Bug ที่อยู่ในโปรแกรม เมื่อแฮกเกอร์สามารถค้นพบ Bug ดังกล่าว แฮกเกอร์ก็จะฉวยโอกาสเขียนโปรแกรมเจาะระบบที่เราเรียกว่า "Exploit" ในการเจาะผ่านช่องโหว่ที่ถูกค้นพบ ซึ่งช่วงหลังๆ แม้แต่ SSL Modules ทั้ง IIS และ Apache web server ก็ล้วนมีช่องโหว่ให้แฮกเกอร์เจาะผ่านทาง Buffer Overflow ทั้งสิ้น

วิธีป้องกัน
จะเห็นว่าปัญหานี้มาจาก ผู้ผลิตไม่ใช่ปัญหาการเขียนโปรแกรม Web application ดังนั้นเราต้องคอยหมั่นติดตามข่าวสาร New Vulnerability และ คอยลง Patch ให้กับระบบของเราอย่างสม่ำเสมอ และลง ให้ทันท่วงทีก่อนที่จะมี exploit ใหม่ๆ ออกมาให้แฮกเกอร์ใช้การเจาะระบบของเรา สำหรับ Top 10 Web Application Hacking อีก 5 ข้อ ที่เหลือผมขอกล่าวดังในฉบับต่อไปนะครับ

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 จึงเป็นทางออกสำหรับการแก้ไขปัญหาทางด้านความปลอดภัยของระบบให้รอดพันจาก เหล่าไวรัสและแฮกเกอร์ซึ่งนับวันจะเพิ่มจำนวนและเพิ่มความสามารถขึ้นเป็นทวีคูณ

239

Re: 10 วิธี เจาะระบบ Web Application Hacking ของ Hacker

ในการทดสอบ Application ที่เราพัฒนานั้นนอกจากเราจะต้องทำการทดสอบ bug ของ Application แล้ว ถ้าหาก Application นั้นมีส่วนที่เกี่ยวข้องกับระบบการเงิน เราอาจจะต้องมีการทดสอบด้าน security ด้วยซึ่งการทดสอบ security นี้ไม่ว่าจะเป็น Windows Application (หรือบางคนจะเรียกว่า Desktop Application) หรือ Web Application นั้นจะมีลักษณะการทดสอบที่คล้ายๆกันเพียงการทดสอบ Web Application นั้นอาจจะมีเรื่องที่ยุ่งยากหรือจุกจิกกว่ากันเยอะ ซึ่งการทดสอบหลักๆจะแบ่งออกเป็น 7 หัวข้อหลักๆดังนี้

URL & Parameter Manipulation

เป็น การ check ว่าในการส่ง parameter แบบ get ที่ส่งผ่าน URL หรือส่งผ่าน Hidden field นั้นมีข้อมูลที่สำคัญส่งมากับ URL parameter หรือไม่เพราะว่าอาจจะเป็นจุดบอดที่สามารถให้บรรดาเหล่า Hacker นั้นใช่จุดบอดเหล่านี้สาวเข้าไปถึงข้อมูลสำคัญของเราได้
ซึ่งถ้าหากว่าจำ เป็นจริงๆที่จะต้องทำการส่งผ่าน URL parameter หรือ hidden field จริงๆก็ควรที่จะทำการ encrypt ข้อมูลที่ส่งผ่าน URL parameter หรือ hidden field เพื่อเพิ่มความปลอดภัยแต่ว่าถ้าเลี่ยงได้ก็ควรไปใช้ Session ในการเก็บข้อมูลเหล่านี้แทน
ข้อแนะนำเกี่ยวกับการ encrypt data เนื่องจาก algorithm ในการ encrypt data มีมากมายก็จริงแต่ algorithm ส่วนใหญ่มักจะมีคนแก้ได้แล้วเป็นส่วนมากดังนั้นในการหา algorithm encrypt data มาใช้ในงานที่ serious จริงๆ ควรที่จะหา encrypt data ที่มี salted hash techniques โดยสามารถเพิ่มความปลอดภัยของข้อมูลได้มากขึ้นเป็นร้อยเป็นพันเท่าครับ โดยการใส่ keyword เข้าไปผสมลงใน data ก่อนจะผ่านกรรมวิธีการ encrypt data เพื่อให้แก้ไขได้ยากยิ่งขึ้นซึ่งเราเรียก keyword ที่เราไปผสม data นี้ว่า salt (ซึ่งเป็นตัวเดียวกันกับคำว่า เกลือ ครับ ก็เหมือนเวลาที่เรากินอาหารแล้วอยากให้อาหารอร่อยขึ้นเราก็เหยาะเกลือลงไป แต่ในที่นี้เพื่อที่จะทำให้การถอด data ยากขึ้น) โดยถ้าสนใจอยากลองเล่นก็ลองไปดูตัวอย่างและวิธีการในเวบนี้ครับ http://www.securitydocs.com/library/3439 หรือถ้าต้องการดูอย่างมุมมองกว้างๆก็แนะนำเวบนี้เลย http://www.developerfusion.co.uk/show/4679/1/%20
หรือ จะเป็นอีกวิธีคือเก็บข้อมูลที่เป็น URL Parameter ทั้งหมดลงไปใน hidden field ทั้งหมดจากนั้นก็ใส่ script ป้องกันการ view source ลงไปในหน้า page นั้น (เช่นที่เราเห็นกันบ่อยคือกันห้าม click ขวา) เพื่อป้องกันการรู้ชื่อ parameter ของ hidden field ในหน้านั้นๆ แต่ขอบอกว่าวิธีนี้ไม่ค่อยจะใช้ได้ผลสักเท่าไร เพราะว่าถ้าหากผู้ใช้ไปปิดความสามารถในการ run javascript ที่ browser แล้วก็ไม่สามารถกันได้อยู่ดี และ script ส่วนใหญ่จะไม่รองรับทุก browser ด้วยครับคือบางครั้งกัน IE กับ firefox ได้แต่อาจจะกัน Opera ไม่ได้ถ้าคนเขียนไม่ได้เขียนรองรับทุก OS

สรุป ถ้าจะกันปัญหาทางด้าน URL & Parameter Manipulation มีสองวิธีที่แก้ได้แน่นอนคือ เก็บข้อมูลที่เป็นความลับใส่ session หรืออีกวิธีก็ทำการ encrypt data เพื่อป้องกันไม่ให้แก้ข้อมูลออกได้ง่ายๆ

SQL Injection

เป็น การใส่คำสั่ง sql เพื่อรันให้ทำงาน โดยกรอกเข้าไปในช่องของ text box เพื่อทำอะไรบางอย่าง เช่น สามารถ login เข้าไป, หรือ รันคำสั่งเพื่อ drop table เป็นต้น ปัญหาแบบนี้จะเจอบ่อยครับในกรณีที่ programmer เขียน SQL ที่ใช้ใน program แบบไม่ได้ดักจับ escape characters บางตัว เช่น double quote (“), single quote (‘) เป็นต้น ซึ่งการที่เราไม่ได้ดักจับหรือจัดการ escape characters นั้นอาจจะทำให้เกิดผลดังตัวอย่างด้านล่างดังนี้

String sql = “select * from user where password = ‘” + password + ”’ ”;

ซึ่ง variable ที่ชื่อว่า password นั้นเป็นตัวรับค่าข้อมูลมาจาก user สมมติว่า user คนนั้นกรอกค่าลงไปดังนี้

Pwd12345’ or ‘1’=’1

ซึ่งหากลองแทน variable password ลงใน variable sql ดูผลที่ได้ก็จะเป็นดังนี้

select * from user where password = ‘Pwd12345’ or ‘1’=’1’

ซึ่ง ถึงแม้ว่า password จะผิดแต่ว่า user ก็สามารถ login เข้าไปเพราะว่า or ‘1’=’1’ มันเป็นจริงเสมอนอกจาก SQL Injection จะเกิดขึ้นกับคำสั่ง SQL แล้วบางครั้งการเรียกใช้ store procedure ก็เกิด SQL Injection เหมือนกันถ้าหากว่าไม่ได้ระมัดระวังเรื่อง escape characters

วิธี ป้องกัน ในบาง DB นั้นมี security ที่รองรับการป้องกัน SQL Injection อยู่แล้วเช่น MySQL ที่เพิ่งเริ่มมีใน version 5.0 โดยต้องใช้ method ชื่อ real_escape_chars() เพื่อช่วยในการจัดการเกี่ยวกับ escape characters หรือในบางภาษาก็มีการจัดการ escape characters ใน SQL ให้เรา เช่น ภาษา Java ซึ่งในภาษา Java นั้นก็จะมี Prepare Statement ที่ช่วยจัดการในเรื่องของการทำ Query แต่สำหรับภาษาไหนหรือ DB ตัวไหนที่ไม่ได้รองรับการป้องกัน SQL Injection ก็ควรที่จะต้องเขียน program ในส่วนที่จัดการ escape characters กันเอาเองซึ่งผมก็มีตัวอย่าง code ของ Java มาให้ดู

http://pastebin.com/f30a7a3be

ที่ ผมให้ตัวอย่างมาให้ที่เป็นในกรณีของ Java นั้นไม่ได้หมายความว่าให้ใช้ตัวนี้แทน prepare statement นะครับยกตัวอย่างเพื่อเป็นแนวทางการเขียนเพื่อนำไปดัก Escape Characters ในภาษาอื่นครับ แต่ว่าการดัก Escape Characters นั้นส่วนใหญ่จะดักกันตรงที่เครื่องหมาย double quote (“), single quote (‘) และ semicolon (มากกว่าครับส่วนที่เหลือถ้าอยากจะดักเพิ่มก็แล้วแต่ความเหมาะสมครับ เช่น ใน MS SQL นั้นมี “--” แทน comment ซึ่งเราควรที่จะดักเพิ่ม เป็นต้น ซึ่งนอกจากวิธีที่ผมได้กล่าวมาแล้วนั้นยังมี trick เล็กๆน้อยๆอีกครับ คือการกำหนดสิทธิ user ให้มี role ตามที่ได้ใช้จริงๆเท่านั้นเพื่อป้องกันว่า เช่น บางครั้งการเขียน program เราอาจจะฝั่ง business process ใน store procedure ของฝั่ง DB ก็ได้ ซึ่งบางทีใน store procedure นั้นอาจจะมี business process ที่ต้องไปรัน command ของ OS ได้ ดังนั้น store procedure นั้นควรที่จะมอบสิทธิให้กับ user ที่ใช้จริงๆเท่านั้น เพราะว่าในตอนทดลองเราอาจจะขี้เกียจมานั่งกำหนดสิทธิให้สิทธิทุกอย่างหมดเลย ดังนั้นก่อนนำเข้าสู้ระบบนำไปใช้จริงก็อย่าลืมกำหนดสิทธิใหม่ด้วยครับ
ปล. Code ด้านบนนั้นที่จริงใช้ Regular Expression น่าจะดีกว่าครับในการตรวจจับแต่ว่าผมไม่เคยลองเล่น Regular Expression ของ Java ซักทีเคยเล่นแต่ javascript ครับใครที่เคยเล่นแล้วช่วยแนะนำผ่าน comment ได้ครับ

Cross-site scripting (XSS)

เป็น ใส่ script บางอย่างเข้าไปในเว็บ เช่น อาจจะใส่ javascript เข้าไปในช่อง text box ดังนี้ <script>alert(“Hello World -Popup”)</script> เพื่อสร้าง popup window แต่ว่าบางครั้ง hacker อาจจะนำ script บางอย่างเข้าไปเพื่อหวังผลบางอย่าง เช่น ดึงข้อมูล cookie ออกมาจาก client site โดยใช้ javascript, vbscript หรือภาษา script อื่นๆ

วิธีแก้ไข ใช้ วิธีการ Convert HTML Tags ซึ่งผู้ที่กรอกเข้ามาถ้าหากมีส่วนหนึ่งส่วนใดให้แปลงตามรูปแบบในตารางด้าน ล่างนี้ก่อนค่อยนำเข้า database

ซึ่ง วิธีนี้ข้อเสียเราต้องมานั่งเขียน program เพื่อแปลง code เองซึ่งค่อยข้างจะยุ่งยากนิดนึงแต่ก็อาจมีทางเลือกอีกในการกัน XSS คือใช้ Lightweight Markup Language หลายคนคงงงอาจจะยังไม่รู้แต่ถ้าผมบอกว่าตัวอย่างของ Lightweight Markup Language (LML) ที่เราได้เห็นนั้นก็คือ BB code นั้นเองซึ่งของ Java นี้ที่ผมลองหาดูก็ไปเจอตัวนี้เข้า PLink Textile ครับ น่าสนใจดีลองไปดูตัวอย่างตาม url นี้ครับ http://hobix.com/textile/ แต่วิธีนี้ค่อนข้างที่จะยุ่งยากครับเหมาะสำหรับช่องที่มีการกรอกข้อมูลยาวๆ อย่างเช่นกระทู้ใน webboard ครับ แต่วิธีแก้ง่ายๆที่แนะนำคือ ให้ ใช้ JSTL แทน JSP scriptlets เข้ามาช่วยในการแสดงผลลงในหน้า web คือใช้ <c:out> แทน <%= %> ครับเพราะว่าจะกันไว้ให้อยู่แล้วครับ Code Convert HTML Tags (ไว้เป็นแนวทางสำหรับภาษาอื่นครับแต่ว่ามันเป็น source ของ java นะครับ ที่ผมลองเขียนเอง) เข้าไปโหลดได้ที่นี่ครับ

http://pastebin.com/f7249386c

จาก ตัวอย่าง Code ด้านบนนั้นที่จริงใน Apache นั้นมี Opensource ที่รองรับ Convert HTML Tags อยู่ครับชื่อว่า class StringEscapeUtils อยู่ใน package Apache Commons

ซึ่ง จะทำให้เราไม่ต้องมาเขียน code ให้เหนื่อย (อันที่จริงผมลองค้นหาใน apache commons แล้วนะแต่ว่าตอนแรกไม่เจอเลยต้องมานั่งเขียนเองเพิ่งมาเจอที่หลัง) โดยใช้ method escapeHtml() มันก็จะจัดการให้เราโดยที่เราไม่ต้องไปเขียน code เองแล้วก็อย่างที่บอกไปด้านบนครับมันมี method escapeSql() ที่ไว้ใช้แก้ SQL Injection ด้วย เหอะๆๆ เพิ่งไปเจอครับตอนแรกที่ผมลองค้นดูนึกว่ามันแยกเป็น class แต่ว่าที่จริงมันเอาไปรวมอยู่ใน class เดียวกันแล้วแบ่งแยกเป็น method ครับ