รายละเอียดของการโจมตีครั้งใหม่บนไซต์ที่ใช้โมเดลส่วนหน้า-ส่วนหลัง เช่น ไซต์ที่ทำงานผ่านเครือข่ายการจัดส่งเนื้อหา โหลดบาลานเซอร์ หรือพรอกซี การโจมตีช่วยให้สามารถแทรกเข้าไปในเนื้อหาของคำขออื่นๆ ที่ประมวลผลในเธรดเดียวกันระหว่างส่วนหน้าและส่วนหลังได้โดยการส่งคำขอบางอย่าง วิธีการที่นำเสนอนี้ใช้ในการจัดระเบียบการโจมตีได้สำเร็จซึ่งทำให้สามารถสกัดกั้นพารามิเตอร์การตรวจสอบสิทธิ์ของผู้ใช้บริการ PayPal ซึ่งจ่ายเงินให้นักวิจัยประมาณ 40 ดอลลาร์โดยเป็นส่วนหนึ่งของโปรแกรมเพื่อแจ้งเกี่ยวกับการมีอยู่ของช่องโหว่ที่ไม่ได้รับการติดตั้ง การโจมตีนี้ยังใช้ได้กับไซต์ที่ใช้เครือข่ายการจัดส่งเนื้อหาของ Akamai อีกด้วย
ปมของปัญหาคือส่วนหน้าและส่วนหลังมักจะให้การสนับสนุนโปรโตคอล HTTP ในระดับที่แตกต่างกัน แต่ในขณะเดียวกันก็รวมคำขอจากผู้ใช้ที่แตกต่างกันไว้ในช่องทางทั่วไป ในการเชื่อมต่อคำขอรับฟรอนต์เอนด์และคำขอประมวลผลแบ็กเอนด์ การเชื่อมต่อ TCP ที่มีอายุยาวนานจะถูกสร้างขึ้น โดยคำขอของผู้ใช้จะถูกส่งผ่าน ส่งไปตามสายโซ่ทีละรายการ โดยแยกจากกันโดยใช้โปรโตคอล HTTP หากต้องการแยกคำขอ ส่วนหัว "Content-Length" (กำหนดขนาดรวมของข้อมูลในคำขอ) และ ""(อนุญาตให้คุณถ่ายโอนข้อมูลเป็นส่วนๆ โดยระบุบล็อกที่มีขนาดต่างกันในรูปแบบ "{size}\r\n{block}\r\n{size}\r\n{block}\r\n0")
ปัญหาจะเกิดขึ้นหากส่วนหน้ารองรับเฉพาะ “Content-Length” แต่ละเว้น “Transfer-Encoding: chunked” (เช่น Akamai CDN ทำสิ่งนี้) หรือในทางกลับกัน หาก Transfer-Encoding: chunked ได้รับการสนับสนุนทั้งสองด้าน คุณลักษณะการใช้งานของตัวแยกวิเคราะห์ส่วนหัว HTTP สามารถใช้สำหรับการโจมตีได้ (เช่น เมื่อส่วนหน้าละเว้นบรรทัด เช่น “Transfer-Encoding: xchunked”, “Transfer-Encoding: chunked” ”, “การเข้ารหัสการถ่ายโอน” :[tab]chunked", "X: X[\n]การเข้ารหัสการถ่ายโอน: chunked", "การเข้ารหัสการถ่ายโอน[\n]: chunked" หรือ "การเข้ารหัสการถ่ายโอน : chunked" และ แบ็กเอนด์ประมวลผลได้สำเร็จ)
ในกรณีนี้ ผู้โจมตีสามารถส่งคำขอที่มีทั้งส่วนหัว "Content-Length" และ "Transfer-Encoding: chunked" แต่ขนาดใน "Content-Length" ไม่ตรงกับขนาดของห่วงโซ่ที่เป็นกลุ่ม ซึ่ง มีค่าน้อยกว่ามูลค่าจริง หากส่วนหน้าประมวลผลและส่งต่อคำขอตาม "Content-Length" และแบ็กเอนด์รอให้บล็อกเสร็จสมบูรณ์ตาม "Transfer-Encoding: chunked" จากนั้นจุดสิ้นสุดของข้อมูลตาม "Transfer-Encoding: chunked" จะ ถูกกำหนดไว้ล่วงหน้าและส่วนท้ายที่เหลือของคำขอที่ผู้โจมตีจะอยู่ที่จุดเริ่มต้นของคำขอถัดไป เช่น ผู้โจมตีจะสามารถแนบข้อมูลที่กำหนดเองไว้ที่จุดเริ่มต้นของคำขอของบุคคลอื่นที่ส่งต่อไป
หากต้องการระบุปัญหาในการใช้ชุดค่าผสมฟรอนต์เอนด์-แบ็กเอนด์ที่ใช้ คุณสามารถส่งคำขอเช่นนี้ผ่านทางฟรอนต์เอนด์:
โพสต์ /เกี่ยวกับ HTTP/1.1
โฮสต์: example.com
การเข้ารหัสการถ่ายโอน: chunked
เนื้อหาความยาว: ฮิต
1
Z
Q
ปัญหาจะเกิดขึ้นหากแบ็กเอนด์ไม่ประมวลผลคำขอทันทีและรอการมาถึงของบล็อกขอบเขตศูนย์สุดท้ายของข้อมูลที่เป็นกลุ่ม เพื่อการตรวจสอบที่สมบูรณ์ยิ่งขึ้น ยูทิลิตี้พิเศษที่ทดสอบวิธีการที่เป็นไปได้ในการซ่อนส่วนหัว "Transfer-Encoding: chunked" จากส่วนหน้า
การโจมตีจริงขึ้นอยู่กับความสามารถของไซต์ที่ถูกโจมตี ตัวอย่างเช่น เมื่อโจมตีแอปพลิเคชันเว็บ Trello คุณสามารถแทนที่จุดเริ่มต้นของคำขอได้ (ข้อมูลทดแทนเช่น “PUT /1/members/1234... x=x&csrf =1234&username=testzzz&bio=cake”) และส่งข้อความรวมถึงคำขอดั้งเดิมของผู้ใช้บุคคลที่สามและคุกกี้การรับรองความถูกต้องที่ระบุในนั้น สำหรับการโจมตีบน saas-app.com พบว่ามีความเป็นไปได้ที่จะแทนที่โค้ด JavaScript ในการตอบกลับโดยการแทนที่โค้ดดังกล่าวในพารามิเตอร์คำขอตัวใดตัวหนึ่ง สำหรับการโจมตี redhat.com มีการใช้ตัวจัดการภายในเพื่อเปลี่ยนเส้นทางไปยังเว็บไซต์ของผู้โจมตี (คำขอในรูปแบบ “POST /search?dest=../assets/idx?redir=//[ป้องกันอีเมล]/HTTP/1.1").
การใช้วิธีการสำหรับเครือข่ายการจัดส่งเนื้อหาทำให้สามารถแทนที่ไซต์ที่ร้องขอได้โดยการแทนที่ส่วนหัว "โฮสต์:" การโจมตีนี้ยังสามารถใช้เพื่อทำลายเนื้อหาของระบบแคชเนื้อหาและแยกข้อมูลที่เป็นความลับที่แคชไว้ จุดสุดยอดของวิธีนี้คือการจัดระเบียบการโจมตี PayPal ซึ่งทำให้สามารถสกัดกั้นรหัสผ่านที่ผู้ใช้ส่งมาระหว่างการตรวจสอบสิทธิ์ (คำขอ iframe ได้รับการแก้ไขเพื่อรัน JavaScript ในบริบทของหน้า paypal.com/us/gifts สำหรับ ซึ่งไม่ได้ใช้ CSP (นโยบายการรักษาความปลอดภัยของเนื้อหา)
ที่น่าสนใจคือในปี 2005 มี เทคนิคการปลอมแปลงคำขอที่คล้ายกันโดยพื้นฐานซึ่งช่วยให้คุณสามารถปลอมแปลงข้อมูลในพร็อกซีแคช (Tomcat, squid, mod_proxy) หรือเลี่ยงผ่านการบล็อกไฟร์วอลล์โดยระบุคำขอ "GET" หรือ "POST" หลายคำขอภายในเซสชัน HTTP เดียว
ที่มา: opennet.ru