Web14: ปัญหาด้านความปลอดภัยในโปรโตคอล HTTP

บทความนี้นำเสนอปัญหาด้านความปลอดภัยบางประการในโปรโตคอล HTTPซึ่งยกมาจากเอกสารสองฉบับ RFC 7230 และ RFC 7231 ตัวอย่างในบทความเกี่ยวกับข้อผิดพลาดเฉพาะได้รับการอ้างอิงจาก OWASP

1. ความเสี่ยงจากปัจจัยระดับกลาง

HTTP อนุญาตให้ใช้ตัวกลางเพื่อตอบสนองต่อคำขอผ่านชุดการเชื่อมต่อ มีองค์ประกอบตัวกลางทั่วไปสามประการ: พร็อกซี เกตเวย์ และทันเนล

คำขอหรือการตอบกลับจะต้องผ่านจุด A, B และ C พวกเขาสามารถเข้าถึงข้อมูลที่ละเอียดอ่อนที่ถูกส่ง เช่น ข้อมูลส่วนบุคคลของผู้ใช้หรือองค์กร การที่คนกลางขาดความสนใจในเรื่องความปลอดภัยและความเป็นส่วนตัว อาจนำไปสู่การโจมตีที่หลากหลาย

นักพัฒนาระบบและนักพัฒนาควรพิจารณาปัจจัยด้านความเป็นส่วนตัวและความปลอดภัยในระหว่างการออกแบบระบบ การเขียนโค้ด และกระบวนการปรับใช้

ผู้ใช้จำเป็นต้องตระหนักถึงอันตรายของการใช้พร็อกซีหรือเกตเวย์ที่ไม่น่าเชื่อถือ

2. การแยกการตอบสนอง

การแยกการตอบสนอง (หรือที่เรียกว่าการฉีด CRLF) เป็นเทคนิคการหาประโยชน์จากเว็บยอดนิยม ผู้โจมตีส่งข้อมูลที่เข้ารหัสในพารามิเตอร์คำขอบางตัว ซึ่งจากนั้นจะถูกถอดรหัสและทำซ้ำในบางฟิลด์ของส่วนหัวการตอบกลับ

หากข้อมูลนี้เป็นสัญลักษณ์ที่แสดงถึงจุดสิ้นสุดของการตอบสนอง และเริ่มการตอบสนองในภายหลัง การตอบสนองดั้งเดิมจะถูกแบ่งออกเป็นสองส่วน และเนื้อหาของการตอบสนองครั้งที่สองจะถูกควบคุมโดยผู้โจมตี ผู้โจมตีสามารถสร้างคำขออื่นภายในการเชื่อมต่อถาวรเดียวกัน และหลอกให้ผู้รับ (รวมถึงคนกลาง) เชื่อว่าการตอบสนองครั้งที่สองนี้เป็นการตอบสนองต่อคำขอที่สอง

3. ขอลักลอบขนของ

การลักลอบขนคำขอเป็นเทคนิคที่ใช้ประโยชน์จากความแตกต่างในการประมวลผลคำขอตามเซิร์ฟเวอร์ประเภทต่างๆ เพื่อซ่อนคำขอที่ดูเหมือนจะไม่เป็นอันตรายซึ่งต่อท้ายคำขอดั้งเดิม

ลองพิจารณาตัวอย่างต่อไปนี้:

สมมติว่าคำขอ POST มีช่อง "ความยาวเนื้อหา" สองช่องในส่วนหัวที่มีค่าต่างกันสองค่า เซิร์ฟเวอร์บางแห่งจะปฏิเสธคำขอนี้ (IIS และ Apache) แต่เซิร์ฟเวอร์อื่นจะไม่ทำเช่นนั้น ตัวอย่างเช่น SunONE W/S 6.1 จะใช้ฟิลด์ Content-length ก่อน ในขณะที่ sunONE Proxy 3.6 จะใช้ฟิลด์ Content-length เป็นอันดับสอง

สมมติว่า SITE เป็น DNS ของ SunONE W/S ซึ่งอยู่ด้านหลัง SunONE Proxy จะมีไฟล์ Poison.html อยู่บน SunONE W/S ต่อไปนี้เป็นวิธีใช้ประโยชน์จาก HTTP Request Suggling โดยพิจารณาจากความไม่สอดคล้องกันในการประมวลผลระหว่างเซิร์ฟเวอร์สองเครื่อง:

[โปรดทราบว่าแต่ละบรรทัดลงท้ายด้วย CRLF (“”) ยกเว้นบรรทัดที่ 10]

ลองพิจารณาว่าจะเกิดอะไรขึ้นเมื่อมีการส่งคำขอไปยัง W/S ผ่านทางพร็อกซีเซิร์ฟเวอร์ ขั้นแรก พร็อกซีจะวิเคราะห์คำขอจากบรรทัดที่ 1 ถึง 7 (สีน้ำเงิน) และพบฟิลด์ความยาวเนื้อหาสองฟิลด์ ตามที่กล่าวไว้ข้างต้น ระบบจะเพิกเฉยต่อฟิลด์แรกและเข้าใจว่าเนื้อหาคำขอมีความยาว 44 ไบต์ ดังนั้นจึงถือว่าข้อมูลจากบรรทัดที่ 8 ถึง 10 เป็นเนื้อหาคำขอแรก (ตั้งแต่บรรทัดที่ 8 ถึง 10 ข้อมูลจะมีความยาว 44 ไบต์พอดี) พร็อกซีจะวิเคราะห์บรรทัดที่ 11 ถึง 14 (สีแดง) เป็นคำขอที่สองของลูกค้า

ตอนนี้เรามาดูกันว่า W/S ตีความข้อมูลข้างต้นอย่างไร เมื่อมันถูกส่งต่อจากพร็อกซี ต่างจากพร็อกซี W/S จะใช้ฟิลด์ Content-Length แรกและตีความดังนี้: คำขอแรกไม่มีเนื้อหา และคำขอที่สองเริ่มจากบรรทัด 8 (โปรดทราบว่า W/S จะแยกวิเคราะห์จากบรรทัด 11 เป็นต้นไปเป็นค่า ของสนามบลา)

ต่อไปเรามาดูกันว่าการตอบสนองจะถูกส่งกลับไปยังไคลเอนต์อย่างไร คำขอที่ W/S เข้าใจคือ “POST /foobar.html” (จากบรรทัดที่ 1) และ “GET /poison.html” (จากบรรทัดที่ 8) ดังนั้นจะส่งการตอบกลับไคลเอนต์ 2 พร้อมเนื้อหาของหน้า foobar html และ Poison.html พร็อกซีเข้าใจว่าการตอบกลับ 2 รายการนี้สอดคล้องกับ 2 คำขอ: "POST /foobar.html" (จากบรรทัด 1) และ "GET /page_to_poison.html" (บรรทัด 11) พร็อกซีจะแคชเนื้อหาของเพจ Poison.html ที่สอดคล้องกับ URL “page_to_poison.html” (การวางพิษแคช) จากนั้น เมื่อลูกค้าร้องขอ "page_to_poison.html" ก็จะได้รับเนื้อหาของเพจ Poison.html

4. การโจมตีตามเส้นทางของไฟล์

เว็บเซิร์ฟเวอร์มักใช้ระบบไฟล์ภายในเครื่องเพื่อจัดการการแมปชื่อไฟล์ใน URI กับทรัพยากรจริงบนเซิร์ฟเวอร์ ระบบไฟล์ส่วนใหญ่ไม่ได้ออกแบบมาเพื่อป้องกันเส้นทางไฟล์ที่เป็นอันตราย ดังนั้นเซิร์ฟเวอร์จึงต้องหลีกเลี่ยงการเข้าถึงไฟล์ระบบที่สำคัญ

ตัวอย่างเช่น UNIX, Microsoft Windows และระบบปฏิบัติการอื่นๆ อีกหลายระบบใช้ “..” เป็นองค์ประกอบเส้นทางเพื่อแสดงไดเร็กทอรีที่อยู่เหนือไฟล์/ไดเร็กทอรีปัจจุบันหนึ่งระดับ หากไม่มีการควบคุมและการอนุญาตอินพุตที่เหมาะสม คุณจะสามารถเข้าถึงไฟล์/โฟลเดอร์ที่ละเอียดอ่อนของระบบได้โดยการป้อนเส้นทางที่ชี้ไปยังไฟล์/โฟลเดอร์เหล่านี้

5. ประเภทของการโจมตี: การแทรกคำสั่ง, การแทรกโค้ด, การแทรกคำถาม

[เว็บเซิร์ฟเวอร์มักจะใช้พารามิเตอร์ใน URI เป็นอินพุตเพื่อดำเนินการคำสั่งระบบและการสืบค้นฐานข้อมูล อย่างไรก็ตาม ข้อมูลที่ได้รับในคำขอไม่สามารถเชื่อถือได้เสมอไป ผู้โจมตีสามารถสร้างและแก้ไขส่วนประกอบในคำขอ (เช่น วิธีการ ฟิลด์ในส่วนหัว เนื้อหา...) เพื่อดำเนินการคำสั่งของระบบ สอบถามฐานข้อมูล...

ตัวอย่างเช่น SQL Injection เป็นการโจมตีทั่วไปที่เว็บเซิร์ฟเวอร์ได้รับพารามิเตอร์ใน URI ที่เป็นส่วนหนึ่งของแบบสอบถาม SQL ดังนั้นผู้โจมตีสามารถหลอกให้เว็บเซิร์ฟเวอร์ดำเนินการสืบค้น SQL ที่ผิดกฎหมายเพื่อขโมยหรือทำลายฐานข้อมูล
โดยทั่วไป ข้อมูลที่ส่งโดยผู้ใช้ไม่ควรถูกนำมาใช้โดยตรงเพื่อดำเนินการบนเซิร์ฟเวอร์ ข้อมูลเหล่านี้จำเป็นต้องผ่านตัวกรอง ซึ่งกำหนดว่าสิ่งใดถูกต้องและสิ่งใดไม่ถูกต้อง ดังนั้นจึงกำจัดข้อมูลที่ไม่ต้องการออกไป

6. การเปิดเผยข้อมูลส่วนบุคคล

ลูกค้ามักจะมีข้อมูลส่วนบุคคลจำนวนมาก รวมถึงข้อมูลที่ผู้ใช้ให้ไว้เพื่อโต้ตอบกับเซิร์ฟเวอร์ (เช่น ชื่อผู้ใช้ รหัสผ่าน ตำแหน่ง ที่อยู่อีเมล ฯลฯ) และข้อมูลเกี่ยวกับกิจกรรมการท่องเว็บของผู้ใช้ (ประวัติ บุ๊กมาร์ก ฯลฯ) เมื่อดำเนินการควรให้ความสนใจในการป้องกันจุดที่สามารถเปิดเผยข้อมูลส่วนตัวนี้ได้

7. การเปิดเผยข้อมูลที่ละเอียดอ่อนใน URI

ตามการออกแบบแล้ว URI มีไว้เพื่อแชร์กับผู้ใช้ทุกคน และไม่รับประกันว่าจะปลอดภัย URI มักจะแสดงในซอร์สโค้ดของเว็บไซต์ และจัดเก็บไว้ในบุ๊กมาร์กโดยไม่มีกลไกการป้องกัน ดังนั้นจะไม่ปลอดภัยหาก URI มีข้อมูลที่ละเอียดอ่อน ข้อมูลส่วนบุคคล ฯลฯ

หลีกเลี่ยงการใช้วิธี GET เพื่อส่งข้อมูลส่วนบุคคลไปยังเซิร์ฟเวอร์ เนื่องจากจะถูกแสดงใน URI ใช้วิธีการ POST แทน

8. การเปิดเผยข้อมูลซอฟต์แวร์ที่ใช้

ช่อง User-Agent, Via, Server ในส่วนหัวมักจะให้ข้อมูลเกี่ยวกับซอฟต์แวร์ที่ผู้ส่งใช้ ตามทฤษฎีแล้ว นั่นทำให้ผู้โจมตีสามารถใช้ประโยชน์จากช่องโหว่ที่ทราบในซอฟต์แวร์เหล่านี้ได้ง่ายขึ้น