การป้องกันช่องโหว่ XSS
ในปัจจุบันการป้องกันช่องโหว่ cross-site scripting อาศัยการแปลงข้อมูลตัวอักขระพิเศษของภาษาเอชทีเอ็มแอลทุกตัวที่เป็นไปได้ว่าอาจเป็นข้อมูลมุ่งร้าย โดยทำก่อนที่เว็บแอพพลิเคชั่น (หรือสคริปต์ฝั่งไคลเอ็นท์) จะแสดงผล และภาษาโปรแกรมมิ่งหลาย ๆ ตัวมีฟังก์ชั่นหรือไลบรารีที่ช่วยในการการแปลงข้อมูลนี้ (ในบริบทนี้ยังเรียกด้วยว่า quoting หรือ escaping)
ตัวอย่างของการทำ quoting แสดงตัวอย่างข้างล่างนี้ จากภายในอินเตอร์พรีเตอร์ของ Python เอง
<script>alert(’xss’);</script>
จากตัวอย่างข้างบนนี้ คำสั่ง print ในบรรทัดแรกได้สร้างสคริปต์ฝั่งไคลเอ็นท์ที่สามารถเอ็กซิคิวท์ได้ แต่ในคำสั่งที่สองแสดงผลเป็นสายอักขระหนึ่งซึ่งเป็นรูปแบบที่ได้เปลี่ยนแปลงข้อมูลเอชทีเอ็มแอลจากเดิมแล้ว รูปแบบอักขระเหล่านี้จะปรากฏเป็นตัวอักขระจริงในเบราว์เซอร์ แทนที่จะเป็นความหมายพิเศษแบบคำสั่งเอชทีเอ็มแอล วิธีนี้ช่วยป้องกันไม่ให้สามารถใส่สคริปต์ใด ๆ เข้าไปในหน้าแสดงผลเอชทีเอ็มแอลได้ นอกจากนี้ยังป้องกันไม่ให้ผู้ใช้สามารถป้อนข้อมูลในรูปแบบเอชทีเอ็มแอลมุ่งร้ายเข้าไปอีกด้วย
ปัญหาพื้นฐานเกี่ยวกับการหลีกเลี่ยงช่องโหว่ XSS คือสถานการณ์มีความแตกต่างกัน ในสถานการณ์หนึ่งความต้องการและปัญหาก็เปลี่ยนแปลงไป ตัวอย่างเช่น เมื่อข้อมูลที่รับจากผู้ใช้ส่งมายัง src attribute ของไฮเปอร์ลิงค์ cgi.escape() ก็ไม่เพียงพอสำหรับการป้องกัน เช่น จะมีการเพิ่มรูปหนึ่งเข้าไปในหน้าเว็บที่แสดงรูปต่าง ๆ ในรูปแบบเช่นนี้
ผู้โจมตีสามารถใส่ “doesntexist.jpg’ onerror=’alert(document.cookie)” เข้าไปในอีเว้นท์ซึ่งจะทำงานเมื่อเบราว์เซอร์ ไม่สามารถโหลดไฟล์ “doesntexist.jpg” และเอ็กซิคิวท์โค้ดดังกล่าว
ถ้ามีใครคนหนึ่งได้ใช้ฟังก์ชั่นอย่างเช่น cgi.escape() (ซึ่งมาพร้อมกับ Python) อีกคนหนึ่งก็จะพยายามเปลี่ยนอักขระทั้งหมดยกเว้นอักขระที่รู้กันดีอยู่แล้วว่าปลอดภัยทั้งหมดให้เป็น HTML entity ที่มีค่าเท่ากัน เบราว์เซอร์ใช้อัลกอริทึมในการวิเคราะห์คำในภาษาเอชทีเอ็มแอลที่ซับซ้อน (และมักจะมีข้อผิดพลาด) ดังนั้นจึงยากที่จะทำนายได้ว่าอักขระตัวใดที่จะเป็นอักขระพิเศษ โดยเฉพาะการสนับสนุนชุดอักขระ Unicode ของเบราว์เซอร์ ซึ่งอาจทำให้แอพพลิเคชั่นหนึ่งถูกโจมตีโดยช่องโหว่ XSS ได้ ถ้าอัลกอริทึมที่ใช้ในการแปลงข้อมูลเอชทีเอ็มแอลตรวจสอบเฉพาะอักขระที่อาจจะมีอันตรายเท่านั้น
จากที่กล่าวไว้ข้างต้น ผลลัพธ์ที่ไม่ดีที่ตามมาจากการแก้ไขช่องโหว่นี้คือ ผู้ใช้ไม่สามารถฝังโค้ดเอชทีเอ็มแอลที่ไม่มีเจตนาร้ายลงไปในหน้าเว็บต่าง ๆ ได้ เนื่องจากมาตรฐานเอชทีเอ็มแอลไม่มีกลไกในการปิดการทำงานของสคริปต์ฝั่งไคลเอ็นท์ในส่วนต่าง ๆ ของหน้าเว็บโดยเฉพาะได้ ดังนั้นจึงยากที่จะกำจัดสคริปต์ออกจากโค้ดเอชทีเอ็มแอลได้อย่างน่าเชื่อถือ วิธีการที่น่าเชื่อถือมากที่สุดสำหรับเว็บแอพพลิเคชั่นคือการวิเคราะห์คำในโค้ดเอชทีเอ็มแอล ขจัดคำสั่งเอชทีเอ็มแอลและอะทริบิวท์ที่ไม่อยู่ในรายการคำสั่งที่ปลอดภัย จากนั้นจึงแสดงผลเอชทีเอ็มแอลที่ถูกต้องออกมา
การป้องกันช่องโหว่ในรูปแบบอื่น ๆ
วิธีที่ง่ายที่สุดในการกำจัดช่องโหว่ XSS คือการแปลงข้อมูลเอชทีเอ็มแอล (HTML quote) ของอักขระพิเศษทั้งหมดที่ได้รับมาจากผู้ใช้ จึงสามารถป้องกันไม่ให้ถูกตีความเป็นโค้ดเอชทีเอ็มแอล โชคไม่ดีที่ผู้ใช้เว็บแอพพลิเคชั่นมากมายหลายชนิด (โดยทั่วไปได้แก่ฟอรั่มและเว็บเมล) ต้องการใช้ฟีเจอร์บางตัวที่เอชทีเอ็มแอลมี มีเว็บแอพพลิเคชั่นบางตัวซึ่งพยายามค้นหาโค้ดเอชทีเอ็มแอลมุ่งร้ายและพยายามทำให้มันไม่มีพิษภัย ไม่ว่าโดยการกำจัดหรือแปลงข้อมูล อัลกอริทึมเหล่านี้มักจบด้วยการมีความซับซ้อนอย่างเหลือเชื่อ ด้วยเหตุผลนี้จึงทำให้แทบเป็นไปไม่ได้ที่ทำให้แน่ใจได้ว่าโค้ดมุ่งร้ายถูกกำจัดไปหมดแล้ว เนื่องจากได้มีการทำให้จาวาสคริปต์รวมเข้ากับรูปแบบของเอชทีเอ็มแอล
อย่างเหนียวแน่น นอกเหนือจากข้อเท็จจริงที่ว่าเบราว์เซอร์และเทคโนโลยีของเว็บยังคงอยู่ภายใต้การพัฒนาอย่างหนักหน่วง ในการกำจัดการใส่โค้ดมุ่งร้ายในบางกรณี อัลกอริทึมในฝั่งเซิร์ฟเวอร์จะต้องปฏิเสธโค้ดเอชทีเอ็มแอลที่ผิดรูปแบบ หรือเข้าใจถึงวิธีการตีความโค้ดเอชทีเอ็มแอลที่ผิดรูปแบบของเบราว์เซอร์ทุกตัว หรือแก้ไขโค้ดเอชทีเอ็มแอลดังกล่าวเป็นรูปแบบที่ถูกต้องโดยใช้เทคนิคต่าง ๆ ในลักษณะเดียวกับเทคนิคที่เรียกว่า HTML Tidy
นอกจากการกลั่นกรองเนื้อหาแล้ว ยังมีการใช้วิธีการอื่น ๆ กันโดยทั่วไปอีกด้วย ตัวอย่างหนึ่งคือการรักษาความปลอดภัยของคุกกี้ เว็บแอพพลิเคชั่นหลายตัวอาศัยเซสชั่นคุกกี้สำหรับการรับรองตัวผู้ใช้ในระหว่าง HTTP request และเนื่องจากสคริปต์ฝั่งไคลเอ็นท์มักจะสามารถเข้าถึงคุกกี้เหล่านี้ได้ ผู้โจมตีมักจะสร้างโค้ดโจมตีช่องโหว่ XSS แบบง่าย ๆ เพื่อขโมยคุกกี้เหล่านี้ ในการกำจัดภัยคุกคามนี้เว็บแอพพลิเคชั่นหลายตัวจะจำกัดเซสชั่นคุกกี้ไว้กับหมายเลขไอพีของผู้ใช้ที่ล็อกอินเข้ามา และอนุญาตให้ไอพีนั้นสามารถใช้คุกกี้นั้นได้ วิธีนี้มีประสิทธิภาพในสถานการณ์ส่วนใหญ่ (ถ้าผู้โจมตีมุ่งเป้าที่คุกกี้เพียงอย่างเดียว) แต่มันใช้ไม่ได้ผลอย่างเห็นได้ชัดในสถานการณ์ที่ผู้โจมตีใช้งานข้างหลัง
เครือข่ายแบบ NAT หรือใช้พร็อกซีเดียวกัน Internet Explorer มีฟีเจอร์หนึ่งที่เรียกว่า HTTP Only flag ซึ่งอนุญาตให้เว็บเซิร์ฟเวอร์สามารถกำหนดคุกกี้ที่สคริปต์ฝั่งไคลเอ็นท์ไม่สามารถเรียกใช้งานได้ ถึงแม้ว่าดูเหมือนมันจะเป็นฟีเจอร์ที่มีประโยชน์ แต่มันไม่ได้ป้องกันการใช้ช่องโหว่ XSS เพื่อขโมยรหัสผ่านหรือการโจมตีแบบ cross-site request forgery ได้
อีกวิธีหนึ่งในการป้องกันคือการตรวจสอบข้อมูลที่ส่งมาจากแหล่งข้อมูลที่อาจประสงค์ร้าย วิธีการนี้เป็นหลักการสำคัญในการพัฒนาแอพพลิเคชั่น (แม้จะไม่เกี่ยวข้องกับการพัฒนาเว็บก็ตาม) และโดยทั่วไปแล้วมีประโยชน์มาก ตัวอย่างเช่น ถ้ามีฟอร์มที่รับข้อมูลจากบางฟีลด์ซึ่งควรจะเป็นหมายเลขโทรศัพท์ การทำงานของฝั่งเซิร์ฟเวอร์สามารถกำจัดอักขระทั้งหมดที่ไม่ใช่ตัวเลข วงเล็บและเครื่องหมายขีดคั่น ทำให้ผลที่ได้ออกมาไม่ประกอบด้วยสคริปต์ (บังเอิญที่สามารถใช้วิธีนี้เพื่อป้องกันการโจมตีที่ส่งโค้ดแบบอื่น ๆ เช่น SQL injection ไม่ให้สามารถทำได้สำเร็จได้ด้วย) ถึงแม้ว่ามันจะมีประสิทธิภาพในการใช้ป้องกันข้อมูลที่ป้อนเข้ามาหลาย ๆ ชนิด มีหลายครั้งที่เมื่อแอพพลิเคชั่นหนึ่งจำเป็นต้องรับอักขระเอชทีเอ็มแอลแบบพิเศษ อย่างเช่น ‘<’ และ ‘>’ ในสถานการณ์เหล่านี้ การแปลงข้อมูลเป็น HTML entity เป็นเพียงทางเลือกเดียวเท่านั้น
โดยสรุป มีการออกแบบเว็บแอพพลิเคชั่นบางตัวเพื่อทำงานโดยปราศจากสคริปต์ฝั่งไคลเอ็นท์ ซึ่งอนุญาตให้ผู้ใช้สามารถเลือกที่จะปิดการทำงานของสคริปต์ในเว็บเบราว์เซอร์ก่อนที่จะใช้แอพพลิเคชั่นได้ ด้วยวิธีการนี้ ถึงแม้จะมีสคริปต์ฝั่งไคลเอ็นท์มุ่งร้ายที่ไม่ได้แปลงข้อมูลอยู่ในหน้าเว็บก็ตาม ผู้ใช้ก็จะไม่ถูกโจมตีจากช่องโหว่ XSS แต่อย่างใด แต่โชคไม่ดีที่ยังอาจสามารถโหลดเนื้อหาภายนอกเข้ามาในหน้าเว็บผ่านทางคำสั่งเช่น หรือ <span class=”mceItemObject” > ซึ่งมักจะเพียงพอในการหลอกล่อผู้ใช้ได้</p> <p>มีเบราว์เซอร์หลายตัวที่สามารถกำหนดให้ปิดการทำงานของสคริปต์ฝั่งไคลเอ็นท์แบบรายโดเมนได้ วิธีนี้มักจะทำให้เกิดความผิดพลาด โดยผู้ใช้มักจะบล็อกเฉพาะเว็บไซต์มุ่งร้ายหลังจากค้นพบแล้วว่ามันมีเจตนาร้าย ซึ่งแน่นอนว่าสายเกินไป ดังนั้นจึงควรกำหนดค่าเริ่มต้นให้บล็อกทั้งหมดจากนั้นจึงอนุญาตให้ผู้ใช้เปิดใช้เป็นรายโดเมน เป็นวิธีการเดียวที่จะช่วยเพิ่มความสะดวกให้กับระบบดังกล่าว สามารถทำเช่นนี้ใน Opera ได้อย่างง่าย ๆ โดยการใช้ Site Specific Preferences สำหรับ Firefox สามารถใช้ extension ที่ชื่อว่า NoScript </p> <p>ข้อเสียสำคัญของวิธีการนี้คือผู้ใช้ส่วนใหญ่ไม่รู้จักมาตรการดังกล่าว และถ้าการกำหนดค่าความปลอดภัยนี้ถูกปิดการทำงานตั้งแต่เริ่มต้น จะทำให้พวกเขาไม่รู้วิธีรักษาความปลอดภัยเบราว์เซอร์สำหรับแอพพลิเคชั่นเหล่านี้ ข้อเสียอีกอย่างหนึ่งคือ มีไซต์จำนวนมากที่ไม่สามารถทำงานได้โดยปราศจากสคริปต์ฝั่งไคลเอ็นท์ ดังนั้นจึงเป็นการบังคับให้ผู้ใช้ต้องปิดระบบป้องกันสำหรับไซต์นั้นและเปิดช่องให้ระบบของพวกเขาถูกโจมตีได้
เรียบเรียงโดย SRAN Dev
รูปที่แสดงผลในเว็บนำมาจาก http://www.jboss.org/community/docs/DOC-13239
ข้อมูลจาก http://www.xssed.com/xssinfo
