วันศุกร์ที่ 6 เมษายน พ.ศ. 2555
การโจมตี XSS ตอนที่ 1
การโจมตี XSS ตอนที่ 1
จากที่ทาง www.datasafehouse.net ซึ่งเป็นบริการเสริมสร้างความปลอดภัยให้กับเว็บไซต์ได้เปิดเผยสถิติเกี่ยว กับเว็บไซต์ในประเทศไทยที่มีความเสี่ยงต่อการโจมตีมีถึง 41 เว็บ (รายละเอียด) ส่วนใหญ่แล้วเป็นช่องโหว่เว็บที่เกิดจากเทคนิคที่เรียกว่า XSS
Cross-site scripting (XSS) คือช่องโหว่ในคอมพิวเตอร์ชนิดหนึ่งที่มักพบในเว็บแอพพลิเคชั่นซึ่งยอมให้
ผู้ใช้เว็บที่มีเจตนาร้ายสามารถส่งโค้ดคำสั่งเข้าไปในหน้าเว็บที่ผู้ใช้เว็บคนอื่น ๆ เปิดดู ตัวอย่างของโค้ดดังกล่าวได้แก่
โค้ด HTML และสคริปต์ฝั่งไคลเอ็นท์ ผู้โจมตีสามารถใช้ช่องโหว่ cross-site scripting เพื่อหลบหลีกมาตรการ
ควบคุมการเข้าถึง เช่น same origin policy เมื่อไม่นานมานี้ช่องโหว่ประเภทนี้ถูกใช้เพื่อสร้างการโจมตีฟิชชิ่งและช่อง
โหว่เบราว์เซอร์อันทรงพลัง แต่เดิม Cross-site script ใช้ตัวย่อว่า CSS อย่างไรก็ตามตัวย่อนี้ไม่เป็นที่นิยมอีกต่อไป
ความเป็นมาการโจมตี XSS
เมื่อ เน็ตสเคปเผยแพร่ภาษาจาวาสคริปต์เป็นครั้งแรก พวกเขาตระหนักถึงความเสี่ยงด้านความปลอดภัยของการยอมให้เว็บเซิร์ฟเวอร์ สามารถส่งโค้ดที่สามารถเอ็กซิคิวท์ได้มายังเบราว์เซอร์ (ถึงแม้จะเพียงแต่ใน sandbox ของเบราว์เซอร์ก็ตาม) ปัญหาหลักในกรณีนี้เกิดขึ้นเมื่อผู้ใช้เปิดมากกว่าหนึ่งหน้าต่างในคราว เดียวกัน ในบางครั้งสคริปต์จากหน้าหนึ่งควรได้รับอนุญาตให้สามารถเข้าถึงข้อมูลในอีก หน้าหนึ่งหรือออบเจคท์หนึ่งได้ นอกจากนั้นแล้วควรปฏิเสธอย่างเข้มงวด เนื่องจากเว็บไซต์ที่มีเจตนาร้ายอาจพยายามขโมยข้อมูลข่าวสารที่เป็นความลับ โดยใช้วิธีนี้ ด้วยเหตุผลนี้จึงมีการเผยแพร่การใช้ same-origin policy โดยพื้นฐานแล้วนโยบายนี้ยอมให้มีการปฏิสัมพันธ์กันระหว่างออบเจคท์และ หน้าต่าง ๆ ตราบใดที่ออบเจคท์เหล่านี้มาจากโดเมนและโปรโตคอลเดียวกัน ด้วยวิธีนี้เว็บเพจมุ่งร้ายไม่สามารถเข้าถึงข้อมูลความลับที่อยู่ในในอีก หน้าต่างหนึ่งของเบราว์เซอร์ผ่านทางจาวาสคริปต์ได้
ตั้งแต่นั้นมา ได้มีการนำนโยบายควบคุมการเข้าถึงต่าง ๆ มาใช้กับเบราว์เซอร์และภาษาฝั่งไคลเอ็นท์ตัวอื่น ๆ เพื่อป้องกันผู้ใช้จากเว็บไซต์ที่มีเจตนาร้าย โดยทั่วไปช่องโหว่ cross-site scripting มักจะถูกมองว่าเป็นช่องโหว่ที่ยอมให้ผู้โจมตีสามารถหลบหลีกกลไกป้องกันเหล่า นี้ได้ โดยการค้นวิธีการที่ชาญฉลาดในการส่งสคริปต์มุ่งร้ายเข้าไปในหน้าเว็บของ โดเมนอื่น ๆ ผู้โจมตีสามารถยกระดับการเข้าถึงเนื้อหาของเว็บที่เป็นความลับ คุกกี้ และออบเจคท์อื่น ๆ หลากหลาย
ในปัจจุบันมีช่องโหว่ XSS ที่รู้จักกันอยู่สามชนิด (จะเรียกว่า ชนิด 0, ชนิด 1, และ ชนิด 2 เพื่อใช้ในการอธิบายแต่ชื่อเหล่านี้ไม่ได้เป็นชื่อมาตรฐานที่ใช้กัน ถ้าเป็นไปได้ก็จะกล่าวถึงชื่อเรียกอื่น ๆ ด้วย)
ชนิด 0
รูปแบบช่องโหว่ XSS ชนิดนี้เรียกว่า DOM-based หรือ Local cross-site scripting และมันไม่ได้เป็นช่องโหว่ใหม่แต่อย่างใด รายงานเรื่อง DOM-Based cross-site scripting สามารถอธิบายลักษณะพิเศษของมันได้เป็นอย่างดี ช่องโหว่ cross-site scripting ชนิด 0 ปัญหาเกิดขึ้นภายในสคริปต์ฝั่งไคลเอ็นท์ของหน้าเว็บในตัวมันเอง และไม่ได้มีการแปลงข้อมูลข่าวสารนี้โดยใช้ HTML entity ซึ่งทำให้เป็นไปได้อย่างมากที่จะทำเกิดช่องโหว่ XSS เนื่องจากข้อมูลที่เขียนนี้จะถูกตีความใหม่โดยเบราว์เซอร์เป็นโค้ดเอชทีเอ็ม แอล ซึ่งอาจฝังสคริปต์ฝั่งไคลเอ็นท์เพิ่มเข้ามาได้
ในทางปฏิบัติ การโจมตีช่องโหว่เหล่านี้คล้ายกับการโจมตีช่องโหว่ชนิด 1 (อ่านข้างล่าง) ยกเว้นในสถานการณ์หนึ่งที่สำคัญมาก เนื่องจากวิธีที่ Internet Explorer ปฏิบัติกับออบเจคท์ที่อยู่ใน ?local zone? (ตัวอย่างเช่นในฮาร์ดไดรฟ์ของไคลเอ็นท์) ช่องโหว่ XSS ชนิดนี้ที่เกิดในหน้าเว็บที่เก็บอยู่ในระบบของผู้ใช้ อาจมีผลให้เกิดช่องโหว่ที่ทำให้สามารถเอ็กซิคิวท์โค้ดที่ต้องการจากระยะไกล ได้ ตัวอย่างเช่น ถ้าผู้โจมตีมีเว็บไซต์มุ่งร้ายที่มีลิงค์ไปยังหน้าเว็บที่มีช่องโหว่ในระบบ ของไคลเอ็นท์เอง ผู้โจมตีอาจสามารถส่งสคริปต์หนึ่งและทำให้มันทำงานโดยใช้สิทธิ์เดียวกับเบรา ว์เซอร์ ของผู้ใช้ในระบบของพวกเขา วิธีนี้หลบหลีกระบบ sandbox ในฝั่งไคลเอ็นท์ทั้งหมด ไม่เพียงแต่ข้อจำกัดในการ
ทำงานข้ามโดเมน ซึ่งโดยปกติมักจะถูกหลบหลีกโดยใช้ช่องโหว่ XSS เท่านั้น
ชนิด 1
ช่องโหว่ cross-site scripting ชนิดนี้ยังมีชื่อเรียกว่า non-persistent หรือ reflected เป็นช่องโหว่ชนิดที่พบบ่อยที่สุดในปัจจุบัน ช่องโหว่ชนิดนี้เกิดขึ้นเมื่อสคริปต์ฝั่งเซิร์ฟเวอร์ใช้ข้อมูลที่ส่งมาโดย เว็บไคลเอ็นท์ทันที เพื่อสร้างหน้าเว็บที่เป็นผลลัพธ์สำหรับผู้ใช้คนนั้น ถ้ามีข้อมูลที่ส่งมาจากผู้ใช้ที่ไม่ได้ตรวจสอบความถูกต้องอยู่ในหน้าผลลัพธ์ นั้นโดยปราศจากแปลงข้อมูลเป็นรหัสเอชทีเอ็มแอล ทำให้ผู้โจมตีสามารถส่งโค้ดฝั่งไคลเอ็นท์เข้ามาในหน้าที่สร้างแบบไดนามิคดัง กล่าวได้ ตัวอย่างที่ดีคือช่องโหว่ในระบบค้นหาของไซต์ ถ้าผู้ใช้ค้นหาสายอักขระหนึ่งที่ประกอบด้วยอักขระเอชทีเอ็มแอลแบบพิเศษ มักจะทำให้สายอักขระที่ค้นหาแสดงขึ้นมาใหม่ในหน้าผลลัพธ์ เพื่อแสดงให้เห็นถึงสิ่งที่ค้นหา หรืออย่างน้อยแสดงคำที่ค้นหาใน text box เพื่อให้ง่ายในการแก้ไข ถ้าไม่ได้มีการเปลี่ยนแปลงข้อมูลคำที่ค้นหาทั้งหมดให้เป็น HTML entity จะทำให้มีช่องโหว่ XSS เกิดขึ้น
เมื่อมีการค้นพบช่องโหว่นี้ครั้งแรก ดูเหมือนมันจะไม่เป็นปัญหาร้ายแรงเนื่องจากมีเพียงแต่ผู้ใช้เท่านั้นที่สามา รถส่งโค้ดเข้าไปในหน้าเว็บของพวกเขาได้ อย่างไรก็ตามโดยการอาศัยเทคนิค social engineering เพียงเล็กน้อย ผู้โจมตีสามารถหลอกล่อให้ผู้ใช้เปิดเว็บมุ่งร้ายซึ่งจะส่งโค้ดเข้าไปยังหน้า แสดงผลลัพธ์ ทำให้ผู้โจมตีสามารถเข้าถึงเนื้อหาของหน้าเว็บนั้นได้อย่างไม่จำกัด เนื่องจากปัญหาในการใช้เทคนิค social engineering บางประการในกรณีนี้ (และในกรณีของช่องโหว่ชนิด 0 เช่นเดียวกัน) โปรแกรมเมอร์หลาย ๆ คนมองข้ามความสำคัญของช่องโหว่เหล่านี้ เนื่องจากคิดว่ามันไม่สำคัญมากนัก ความเข้าใจผิดนี้บางครั้งยังเหมารวมไปถึงช่องโหว่ XSS โดยทั่วไปด้วย (ถึงแม้ว่านี่เป็นเพียงช่องโหว่ XSS ชนิดหนึ่งเท่านั้น) และยังมีความเห็นที่ไม่ลงรอยกันเกี่ยวกับความสำคัญของช่องโหว่ cross-site scripting อยู่
บ่อยครั้งด้วย
ชนิด 2
ช่องโหว่ cross-site scripting ชนิดนี้ยังมีชื่อเรียกว่า stored หรือ persistent หรือ second-order มันยอมให้มีการโจมตีหลาย ๆ อย่างที่ทรงพลัง ช่องโหว่ชนิด 2 เกิดขึ้นเมื่อผู้ใช้เว็บส่งข้อมูลไปยังเว็บแอพพลิเคชั่น ในตอนแรกจะมีการเก็บข้อมูลนั้นอย่างต่อเนื่องในเซิร์ฟเวอร์ (ในฐานข้อมูล ระบบไฟล์ หรือที่อื่น ๆ) ต่อมาจึงแสดงให้ผู้ใช้เห็นในหน้าเว็บโดยไม่ได้แปลงข้อมูลโดยใช้ HTML entity ตัวอย่างที่ดีของช่องโหว่ประเภทนี้ได้แก่ message boards ซึ่งผู้ใช้จะได้รับอนุญาตให้สามารถโพสต์ข้อความในแบบเอชทีเอ็มแอลเพื่อให้ ผู้ใช้คนอื่น ๆ อ่าน
ช่องโหว่เหล่านี้มีความสำคัญมากกว่าช่องโหว่ชนิดอื่นเนื่องจากผู้โจมตีสา มารถส่งโค้ดสคริปต์ไปแค่ครั้งเดียว ซึ่งอาจมีผลกระทบกับผู้ใช้อื่น ๆ จำนวนมากโดยใช้เทคนิค social engineering เพียงเล็กน้อยเท่านั้น หรือเว็บแอพพลิเคชั่นที่อาจถูกโจมตีโดยไวรัสที่อาศัยช่องโหว่ cross-site scripting
วิธีในการส่งโค้ดอาจมีได้มากมายหลากหลาย และผู้โจมตีอาจไม่จำเป็นต้องใช้เว็บแอพพลิเคชั่นเพื่อโจมตีช่องโหว่ดังกล่าว ข้อมูลใด ๆ ก็ตามที่เว็บแอพพลิเคชั่นได้รับมา (ทางอีเมล ล็อก เป็นต้น) ที่ผู้โจมตีสามารถควบคุมได้ จะต้องแปลงข้อมูลก่อนที่จะแสดงผลใหม่ในหน้าที่แสดงแบบไดนามิค มิฉะนั้นแล้วช่องโหว่ XSS ชนิดนี้ก็จะเกิดขึ้นได้
ที่มา ทีมงาน SRAN Dev
ข้อมูลจาก ruk-com.in.th
สมัครสมาชิก:
ส่งความคิดเห็น (Atom)
ไม่มีความคิดเห็น:
แสดงความคิดเห็น