detalls d'un nou atac a llocs que utilitzen un model front-end-back-end, com els que s'executen a través de xarxes de lliurament de contingut, equilibradors de càrrega o servidors intermediaris. L'atac permet, mitjançant l'enviament de determinades sol·licituds, ficar-se en el contingut d'altres peticions processades en el mateix fil entre el frontend i el backend. El mètode proposat es va utilitzar amb èxit per organitzar un atac que va permetre interceptar els paràmetres d'autenticació dels usuaris del servei PayPal, que va pagar als investigadors uns 40 mil dòlars com a part d'un programa per informar sobre la presència de vulnerabilitats sense pegats. L'atac també s'aplica als llocs que utilitzen la xarxa de lliurament de contingut d'Akamai.
El quid del problema és que les interfícies i els backend sovint ofereixen diferents nivells de suport per al protocol HTTP, però al mateix temps encapsulen les sol·licituds de diferents usuaris en un canal comú. Per connectar les peticions de recepció del frontend i les de processament del backend, s'estableix una connexió TCP de llarga durada, a través de la qual es transmeten les peticions d'usuari, transmeses al llarg de la cadena una darrere l'altra, separades mitjançant el protocol HTTP. Per separar les sol·licituds, les capçaleres "Content-Length" (determina la mida total de les dades de la sol·licitud) i ""(permet transferir dades per parts, especificant blocs de diferents mides en el format "{mida}\r\n{bloc}\r\n{mida}\r\n{bloc}\r\n0").
El problema sorgeix si la interfície només admet "Longitud de contingut" però ignora "Codificació de transferència: fragmentat" (per exemple, Akamai CDN ho va fer) o viceversa. Si Transfer-Encoding: chunked és compatible amb les dues cares, les característiques d'implementació dels analitzadors de capçaleres HTTP es poden utilitzar per a un atac (per exemple, quan la portada ignora línies com "Transfer-Encoding: xchunked", "Transfer-Encoding: chunked". ”, "Codificació de transferència":[pestanya] fragmentada", "X: X[\n]Codificació de transferència: fragmentada", "Codificació de transferència[\n]: fragmentada" o "Codificació de transferència: fragmentada" i el backend els processa correctament).
En aquest cas, un atacant pot enviar una sol·licitud que contingui tant les capçaleres "Content-Length" com "Transfer-Encoding: chunked", però la mida de "Content-Length" no es correspon amb la mida de la cadena fragmentada, que és menor que el valor real. Si la interfície processa i reenvia la sol·licitud segons "Content-Length" i el backend espera que el bloc es completi en funció de "Transfer-Encoding: chunked", aleshores el final de les dades basat en "Transfer-Encoding: chunked" es determinarà abans i la cua restant de la sol·licitud apareixerà l'atacant al començament de la següent sol·licitud, és a dir. l'atacant podrà adjuntar dades arbitràries al començament de la sol·licitud d'una altra persona transmesa a continuació.
Per determinar el problema en la combinació interfície-backend utilitzada, podeu enviar una sol·licitud com aquesta a través de la interfície:
POST /sobre HTTP/1.1
Amfitrió: example.com
Codificació de transferència: fragmentat
Content-Length: 4
1
Z
Q
El problema és present si el backend no processa immediatament la sol·licitud i espera l'arribada del bloc de límit zero final de dades fragmentades. Per a una comprovació més completa una utilitat especial que també prova possibles mètodes per amagar la capçalera "Transfer-Encoding: chunked" de la interfície.
La realització d'un atac real depèn de les capacitats del lloc atacat, per exemple, quan s'ataca l'aplicació web de Trello, podeu substituir l'inici de la sol·licitud (substituir dades com “PUT /1/members/1234... x=x&csrf =1234&username=testzzz&bio=cake”) i enviar un missatge que inclogui la sol·licitud original d'un usuari de tercers i la galeta d'autenticació que s'hi especifica. Per a un atac a saas-app.com, va resultar possible substituir el codi JavaScript a la resposta substituint-lo en un dels paràmetres de sol·licitud. Per a l'atac a redhat.com, es va utilitzar un gestor intern per redirigir al lloc web de l'atacant (una sol·licitud del formulari "POST /search?dest=../assets/idx?redir=//[protegit per correu electrònic]/ HTTP/1.1").
L'ús del mètode per a xarxes de lliurament de contingut va permetre substituir simplement el lloc sol·licitat substituint la capçalera "Host:". L'atac també es pot utilitzar per enverinar el contingut dels sistemes de memòria cau i extreure dades confidencials a la memòria cau. El punt àlgid del mètode va ser l'organització d'un atac a PayPal, que va permetre interceptar les contrasenyes enviades pels usuaris durant l'autenticació (la sol·licitud iframe es va modificar per executar JavaScript en el context de la pàgina paypal.com/us/gifts, per quina CSP (política de seguretat de contingut) no s'ha aplicat).
Curiosament, l'any 2005 n'hi havia una tècnica de falsificació de sol·licituds essencialment similar que us permet falsificar dades en servidors intermediaris de memòria cau (Tomcat, squid, mod_proxy) o evitar el bloqueig del tallafoc especificant diverses sol·licituds "GET" o "POST" dins d'una sessió HTTP.
Font: opennet.ru