การลักลอบส่งคำขอ HTTP ( HRS ) เป็นช่องโหว่ด้านความปลอดภัยของ โปรโตคอล HTTPที่ใช้ประโยชน์จากความไม่สอดคล้องกันระหว่างการตีความContent-LengthและTransfer-Encodingส่วนหัวระหว่าง การใช้งาน เซิร์ฟเวอร์ HTTPในห่วงโซ่เซิร์ฟเวอร์พร็อกซี HTTP ^{[ 1 ] [ 2 ]} HRS ถูกค้นพบครั้งแรกในปี 2548 โดย Linhart และคณะ^{[ 3 ]}

ส่วนหัว Transfer-Encoding ทำงานโดยการกำหนดคำสั่งเกี่ยวกับวิธีการตีความเนื้อหาของคำขอ HTTPโดยคำสั่งทั่วไปและจำเป็นสำหรับการโจมตีนี้คือการเข้ารหัสการถ่ายโอนแบบแบ่งส่วน^{[ 4 ]}เมื่อมีส่วนหัว Transfer-Encoding ส่วนหัว Content-Length จะถูกละเว้น^{[ 4 ]} ส่วนหัว Content-Length ทำงานในลักษณะเดียวกันแต่มีไวยากรณ์ ที่แตกต่างกัน โดยระบุขนาดเป็นไบต์ของเนื้อหาเป็นค่าในส่วนหัวเอง^{[ 5 ]}ช่องโหว่เกิดขึ้นเมื่อส่วนหัวทั้งสองนี้รวมอยู่ในคำขอ HTTP ที่เป็นอันตราย ซึ่งจะข้ามฟังก์ชันความปลอดภัยที่ออกแบบมาเพื่อป้องกันการสอบถาม HTTP ที่เป็นอันตรายต่อเซิร์ฟเวอร์โดยทำให้ เซิร์ฟเวอร์ ส่วนหน้าหรือส่วนหลังตีความคำขอไม่ถูกต้อง^{[ 6 ]}

ในการลักลอบส่งคำขอ HTTP ประเภทนี้ ฝั่งหน้าจะประมวลผลคำขอโดยใช้ส่วนหัว Content-Length ในขณะที่ฝั่งหลังจะประมวลผลคำขอโดยใช้ส่วนหัว Transfer-Encoding ^{[ 2 ]}การโจมตีจะดำเนินการโดยส่วนแรกของคำขอประกาศ chunk ที่มีความยาวเป็นศูนย์^{[ 6 ]}เซิร์ฟเวอร์ฝั่งหน้าเมื่อเห็นเช่นนี้จะอ่านเฉพาะส่วนแรกของคำขอและส่งส่วนที่สองไปยังเซิร์ฟเวอร์ฝั่งหลังโดยไม่ตั้งใจ^{[ 6 ]}เมื่อส่งผ่านไปยังเซิร์ฟเวอร์ฝั่งหลังแล้ว จะถูกถือว่าเป็นคำขอถัดไปและประมวลผล โดยดำเนินการตามคำขอที่ซ่อนไว้ของผู้โจมตี^{[ 6 ]}

ในการลักลอบส่งคำขอ HTTP ประเภทนี้ ส่วนหน้าจะประมวลผลคำขอโดยใช้ส่วนหัว Transfer-Encoding ในขณะที่ส่วนหลังจะประมวลผลคำขอโดยใช้ส่วนหัว Content-Length ^{[ 2 ]}ในการโจมตีนี้ แฮ็กเกอร์จะประกาศความยาวที่ถูกต้องของส่วนแรกซึ่งมีคำขอที่เป็นอันตรายอยู่ จากนั้นจะประกาศส่วนที่สองที่มีความยาวเป็น 0 ^{[ 6 ]}เมื่อเซิร์ฟเวอร์ส่วนหน้าเห็นส่วนที่สองที่มีความยาวเป็น 0 มันจะเชื่อว่าคำขอเสร็จสมบูรณ์และส่งต่อไปยังเซิร์ฟเวอร์ส่วนหลัง^{[ 6 ]}อย่างไรก็ตาม เซิร์ฟเวอร์ส่วนหลังจะประมวลผลคำขอโดยใช้ส่วนหัว Content-Length และเป็นผลให้คำขอที่เป็นอันตรายที่เหลืออยู่ในส่วนแรกไม่ได้รับการประมวลผลจนกว่าจะถูกมองว่าเป็นจุดเริ่มต้นของคำขอถัดไปในลำดับและดำเนินการ^{[ 2 ]}

ในการลักลอบส่งคำขอ HTTP ประเภทนี้ ทั้งฝั่ง front-end และ back-end จะประมวลผลคำขอโดยใช้ส่วนหัว Transfer-Encoding แต่ส่วนหัวนั้นสามารถถูกทำให้คลุมเครือได้ (เช่น โดยการจัดรูปแบบช่องว่างที่ไม่เป็นมาตรฐานหรือส่วนหัวที่ซ้ำกัน) ซึ่งทำให้เซิร์ฟเวอร์หนึ่งเพิกเฉยต่อส่วนหัวนั้น แต่เซิร์ฟเวอร์อื่นไม่เพิกเฉย^{[ 2 ]}การทำให้ส่วนหัวคลุมเครืออาจอยู่ในรูปแบบของการเพิ่มอักขระที่ไม่ถูกต้อง เช่น Transfer-Encoding: xchunked หรืออักขระขึ้นบรรทัดใหม่ที่ไม่ปกติระหว่าง 'Transfer-Encoding' และ ': chunked' ^{[ 6 ]}หากเซิร์ฟเวอร์ front-end หรือ back-end เซิร์ฟเวอร์ใดเซิร์ฟเวอร์หนึ่งยังคงประมวลผลคำขอ HTTP ที่ถูกทำให้คลุมเครือเหล่านี้ การโจมตีที่เหลือจะคล้ายกับวิธีการทำงานของการโจมตี CL.TE หรือ TE.CL ^{[ 6 ]}

วิธีป้องกันการโจมตีเหล่านี้ที่ดีที่สุดคือ หากเซิร์ฟเวอร์ฝั่ง frontend และ backend ตีความคำขอ HTTP ในลักษณะเดียวกัน อย่างไรก็ตาม โดยปกติแล้ววิธีนี้ทำได้ยาก เนื่องจากload balancerรองรับเซิร์ฟเวอร์ฝั่ง backend ที่ทำงานบนแพลตฟอร์มที่แตกต่างกัน โดยใช้ซอฟต์แวร์ที่แตกต่างกัน^{[ 6 ]}การโจมตีรูปแบบต่างๆ ส่วนใหญ่สามารถป้องกันได้โดยใช้HTTP/2เนื่องจากใช้วิธีการที่แตกต่างกันในการกำหนดความยาวของคำขอ อีกวิธีหนึ่งในการหลีกเลี่ยงการโจมตีคือให้เซิร์ฟเวอร์ฝั่ง frontend ปรับมาตรฐานคำขอ HTTP ก่อนส่งไปยังเซิร์ฟเวอร์ฝั่ง backend เพื่อให้แน่ใจว่าคำขอเหล่านั้นได้รับการตีความในลักษณะเดียวกัน^{[ 2 ]}การกำหนดค่าไฟร์วอลล์แอปพลิเคชันเว็บเป็นอีกวิธีที่ดีในการป้องกันการโจมตี HRS เนื่องจากไฟร์วอลล์หลายตัวมีเทคโนโลยีที่ระบุความพยายามในการโจมตีและบล็อกหรือกรองคำขอขาเข้าที่น่าสงสัย^{[ 6 ]}

Grenfeldt et al. (2021) พบว่าเว็บเซิร์ฟเวอร์ฝั่ง front-end ส่วนใหญ่ (เช่น พร็อกซีเซิร์ฟเวอร์) มีคุณสมบัติการแยกวิเคราะห์เพื่อป้องกันการโจมตี HRS ที่รู้จักทั้งหมดบนเว็บเซิร์ฟเวอร์ฝั่ง back-end ในทางปฏิบัติ^{[ 7 ]} Huang et al. (2022) เสนอวิธีการใช้Flaskเพื่อนำคุณสมบัติการแยกวิเคราะห์ที่เหมาะสมมาใช้เพื่อป้องกันการโจมตี HRS จากโปรแกรมฝั่ง front-end หรือเว็บเซิร์ฟเวอร์^{[ 8 ]}