hacktricks/pentesting-web/http-response-smuggling-desync.md

HTTP Response Smuggling / Desync

Leer AWS-hacking van nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

• As jy jou maatskappy geadverteer wil sien in HackTricks of HackTricks in PDF wil aflaai, kyk na die SUBSCRIPTION PLANS!
• Kry die amptelike PEASS & HackTricks swag
• Ontdek The PEASS Family, ons versameling eksklusiewe NFTs
• Sluit aan by die 💬 Discord-groep of die telegram-groep of volg ons op Twitter 🐦 @carlospolopm.
• Deel jou hacktruuks deur PR's in te dien by die HackTricks en HackTricks Cloud github-opslag.

Die tegniek van hierdie berig is geneem uit die video: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s

HTTP Aanvraag-ry Desinkronisasie

Eerstens, hierdie tegniek misbruik 'n HTTP Aanvraag Smuggling kwesbaarheid, so jy moet weet wat dit is:

Die hoofverskil tussen hierdie tegniek en 'n gewone HTTP Aanvraag-smuggling is dat in plaas daarvan om die aanvraag van die slagoffer aan te val deur 'n voorvoegsel by te voeg, ons die reaksie wat die slagoffer ontvang lek of wysig. Dit word gedoen deur, in plaas van om 1 en 'n half aanvraag te stuur om die HTTP Aanvraag-smuggling te misbruik, 2 volledige aanvrae te stuur om die reaksie-ry van die proksi te desinkroniseer.

Dit is omdat ons in staat sal wees om die reaksie-ry te desinkroniseer, sodat die reaksie van die wettige aanvraag van die slagoffer na die aanvaller gestuur word, of deur aanvallersbeheerde inhoud in die reaksie na die slagoffer in te spuit.

HTTP Pyplyn Desinkronisasie

HTTP/1.1 maak dit moontlik om verskillende hulpbronne aan te vra sonder om te wag vir voriges. Daarom, as daar 'n proksi in die middel is, is dit die proksi se taak om 'n gesinkroniseerde ooreenstemming van aanvrae wat na die agterste gestuur word en reaksies wat daarvandaan kom, te handhaaf.

Daar is egter 'n probleem om die reaksies-ry te desinkroniseer. As 'n aanvaller 'n HTTP Reaksie-smuggling-aanval stuur en die reaksies op die oorspronklike aanvraag en die gesmokkelde een onmiddellik beantwoord word, sal die gesmokkelde reaksie nie in die ry van die slagoffer se reaksie ingevoeg word nie, maar sal net as 'n fout verwerp word.

Daarom is dit nodig dat die gesmokkelde aanvraag langer tyd neem om in die agterste bediener verwerk te word. Teen die tyd dat die gesmokkelde aanvraag verwerk word, sal die kommunikasie met die aanvaller verby wees.

As in hierdie spesifieke situasie 'n slagoffer 'n aanvraag gestuur het en die gesmokkelde aanvraag voor die wettige aanvraag beantwoord word, sal die gesmokkelde reaksie na die slagoffer gestuur word. Daarom sal die aanvaller die aanvraag "uitgevoer" deur die slagoffer beheer.

Verder, as die aanvaller dan 'n aanvraag uitvoer en die wettige reaksie op die slagoffer se aanvraag beantwoord word voordat die aanvaller se aanvraag. Die reaksie na die slagoffer sal na die aanvaller gestuur word, wat die reaksie na die slagoffer steel (wat byvoorbeeld die kop Set-Cookie kan bevat).

Meervoudige Geneste Inspuitings

'n Ander interessante verskil met gewone HTTP Aanvraag-smuggling is dat, in 'n gewone smokkelingsaanval, die doel is om die begin van die slagoffer se aanvraag te verander sodat dit 'n onverwagte aksie uitvoer. In 'n HTTP Reaksie-smokkelingsaanval, aangesien jy volledige aanvrae stuur, kan jy tientalle reaksies in een payload inspuit wat tientalle gebruikers sal desinkroniseer wat die ingespuite reaksies sal ontvang.

Afgesien daarvan dat jy makliker tientalle exploits kan versprei onder wettige gebruikers, kan dit ook gebruik word om 'n DoS in die bediener te veroorsaak.

Exploit Organisasie

Soos voorheen verduidelik, om hierdie tegniek te misbruik, is dit nodig dat die eerste gesmokkelde boodskap in die bediener baie tyd neem om verwerk te word.

Hierdie tydrowende aanvraag is genoeg as ons net die slagoffer se reaksie wil probeer steel. Maar as jy 'n meer komplekse exploit wil uitvoer, sal dit 'n algemene struktuur vir die exploit wees.

Eerstens die oorspronklike aanvraag wat HTTP Aanvraag-smuggling misbruik, dan die tydrowende aanvraag en dan 1 of meer payloads wat se reaksies na die slagoffers gestuur sal word.

Misbruik van HTTP Reaksie-ry Desinkronisasie

Vaslegging van ander gebruikers se aanvrae

Soos met bekende HTTP Aanvraag-smuggling payloads, kan jy die slagoffer se aanvraag steel met een belangrike verskil: In hierdie geval het jy net die gestuurde inhoud nodig om in die reaksie gereflekteer te word, geen volgehoue berging is nodig nie.

Eerstens stuur die aanvaller 'n payload wat 'n finale POST-aanvraag met die gereflekteerde parameter aan die einde en 'n groot Content-Length bevat

Dan, sodra die oorspronklike aanvraag (blou) verwerk is en terwyl die slaperige een verwerk word (geel), sal die volgende aanvraag wat van 'n slagoffer afkomstig is, in die ry na die gereflekteerde parameter ingevoeg word:

Dan sal die slagoffer die reaksie op die slaperige aanvraag ontvang en as intussen die aanvaller 'n ander aanvraag stuur, sal die reaksie van die gereflekteerde inhoudsaanvraag na hom gestuur word.

Reaksie Desinkronisasie

Tot dusver het ons geleer hoe om HTTP Aanvraag

Inhoudsverwarring

Na die vorige voorbeeld, wetende dat jy die liggaam van die versoek kan beheer waarvan die slagoffer die respons gaan ontvang en dat 'n HEAD respons gewoonlik die Content-Type en die Content-Length in sy koppe bevat, kan jy 'n versoek soos die volgende stuur om 'n XSS in die slagoffer te veroorsaak sonder dat die bladsy vatbaar is vir XSS:

Cache-vergiftiging

Deur misbruik te maak van die voorheen bespreekte respons-desinkronisasie van inhoudsverwarringsaanval, as die cache die respons op die versoek wat deur die slagoffer uitgevoer is, stoor en hierdie respons 'n ingespuit een is wat 'n XSS veroorsaak, dan is die cache vergiftig.

Boosaardige versoek wat die XSS-lading bevat:

Boosaardige respons aan die slagoffer wat die kop bevat wat die cache aandui om die respons te stoor:

{% hint style="warning" %} Let daarop dat in hierdie geval as die "slagoffer" die aanvaller is, kan hy nou cache-vergiftiging in willekeurige URL's uitvoer omdat hy die URL wat met die boosaardige respons gestoor gaan word, kan beheer. {% endhint %}

Webkassaverwarring

Hierdie aanval is soortgelyk aan die vorige een, maar in plaas daarvan om 'n lading binne die cache in te spuit, sal die aanvaller slagofferinligting binne die cache stoor:

Responsverdeling

Die doel van hierdie aanval is om weer die respons-desinkronisasie te misbruik om 'n 100% aanvaller gegenereerde respons deur die proksi te laat stuur.

Om dit te bereik, moet die aanvaller 'n eindpunt van die webtoepassing vind wat waardes binne die respons reflekteer en die inhoudslengte van die HEAD-respons ken.

Hy sal 'n uitbuiting soos die volgende stuur:

Nadat die eerste versoek opgelos en teruggestuur is na die aanvaller, word die versoek van die slagoffer by die waglys gevoeg:

Die slagoffer sal as respons die HEAD-respons + die inhoud van die tweede versoekrespons (wat 'n deel van die gereflekte data bevat) ontvang:

Let egter daarop hoe die gereflekte data 'n grootte gehad het volgens die Content-Length van die HEAD-respons wat 'n geldige HTTP-respons in die responswag gekry het.

Daarom sal die volgende versoek van die tweede slagoffer as respons iets heeltemal deur die aanvaller vervaardig ontvang. Aangesien die respons heeltemal deur die aanvaller vervaardig is, kan hy ook die proksi die respons laat stoor.

Leer AWS-hacking van nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

• As jy wil sien dat jou maatskappy geadverteer word in HackTricks of HackTricks in PDF aflaai, kyk na die SUBSCRIPTION PLANS!
• Kry die amptelike PEASS & HackTricks-uitrusting
• Ontdek The PEASS Family, ons versameling eksklusiewe NFT's
• Sluit aan by die 💬 Discord-groep of die telegram-groep of volg ons op Twitter 🐦 @carlospolopm.
• Deel jou haktruuks deur PR's in te dien by die HackTricks en HackTricks Cloud github-opslag.