<summary><strong>Jifunze kuhusu kuvamia AWS kutoka sifuri hadi shujaa na</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Mtaalam wa Timu Nyekundu ya AWS ya HackTricks)</strong></a><strong>!</strong></summary>
* Ikiwa unataka kuona **kampuni yako ikitangazwa kwenye HackTricks** au **kupakua HackTricks kwa PDF** Angalia [**MIPANGO YA KUJIUNGA**](https://github.com/sponsors/carlospolop)!
* Pata [**bidhaa rasmi za PEASS & HackTricks**](https://peass.creator-spring.com)
* Gundua [**Familia ya PEASS**](https://opensea.io/collection/the-peass-family), mkusanyiko wetu wa kipekee wa [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Jiunge na** 💬 [**Kikundi cha Discord**](https://discord.gg/hRep4RUj7f) au **kikundi cha** [**telegram**](https://t.me/peass) au **tufuate** kwenye **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Shiriki mbinu zako za kuvamia kwa kuwasilisha PRs kwa** [**HackTricks**](https://github.com/carlospolop/hacktricks) na [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
**Mbinu ya chapisho hili ilitolewa kutoka kwenye video:** [**https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s**](https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s)
**Tofauti kuu** kati ya mbinu hii na kupotosha kawaida ya ombi la HTTP ni kwamba **badala ya kushambulia ombi la mwathiriwa kwa kuongeza kipimo kwake**, tutakuwa **kufichua au kubadilisha jibu ambalo mwathiriwa anapokea**. Hii inafanywa kwa kutuma ombi 2 kamili badala ya ombi na nusu kwa kufanya upotoshaji wa ombi la HTTP, **tuma ombi 2 kamili kwa kudharau safu za majibu ya wakala**.
Hii ni kwa sababu tutaweza **kupotosha safu ya majibu** ili **jibu** kutoka kwa **ombi halali** la **mwathiriwa litumwe kwa muovu**, au kwa **kuingiza maudhui yanayodhibitiwa na muovu kwenye jibu kwa mwathiriwa**.
HTTP/1.1 inaruhusu kuomba **rasilimali tofauti bila kusubiri zile za awali**. Kwa hivyo, ikiwa kuna **wakala** katikati, ni jukumu la wakala **kuhifadhi mechi iliyosawazishwa ya maombi yanayotumwa kwa seva ya nyuma na majibu yanayokuja kutoka kwake**.
Walakini, kuna tatizo la kupotosha safu za majibu. Ikiwa muovu anatuma shambulio la Kupotosha Majibu ya HTTP na majibu kwa **ombi la awali na lile lililopotoshwa yanajibiwa mara moja**, jibu lililopotoshwa halitawekwa ndani ya safu ya jibu la mwathiriwa lakini litakuwa **tu linatupiliwa mbali kama kosa**.
Kwa hivyo, ni muhimu kwamba **ombi lililopotoshwa****linachukua muda zaidi kusindika** ndani ya seva ya nyuma. Kwa hivyo, kufikia wakati ombi lililopotoshwa linasindika, mawasiliano na muovu yatakuwa yameisha.
Ikiwa katika hali hii maalum **mwathiriwa amepeleka ombi** na **ombi lililopotoshwa linajibiwa kabla** ya ombi halali, **jibu lililopotoshwa litatumwa kwa mwathiriwa**. Kwa hivyo, muovu atakuwa **anadhibiti ombi "lililofanywa" na mwathiriwa**.
Zaidi ya hayo, ikiwa **muovu kisha atafanya ombi** na **jibu halali** kwa **mwathiriwa** linajibiwa **kabla** ya ombi la muovu. **Jibu kwa mwathiriwa litatumwa kwa muovu**, **kuiba** jibu kwa mwathiriwa (ambalo linaweza kuwa na kichwa kama vile **Set-Cookie**).
Tofauti nyingine **ya kuvutia** na **Kupotosha Kawaida ya Ombi la HTTP** ni kwamba, katika shambulio la kawaida la kupotosha, ** lengo** ni **kubadilisha mwanzo wa ombi la mwathiriwa** ili ifanye hatua isiyotarajiwa. Katika **shambulio la Kupotosha Majibu ya HTTP**, kwa kuwa **unatuma maombi kamili**, unaweza **kuingiza kwenye mzigo mmoja majibu kadhaa** ambayo yatakuwa **kupotosha mamia ya watumiaji** ambao watakuwa **wanapokea****majibu****yaliyoingizwa**.
Kama ilivyoelezwa hapo awali, ili kutumia mbinu hii, ni muhimu kwamba **ujumbe wa kwanza uliopotoshwa** ndani ya seva **unachukua muda mwingi kusindika**.
Hii **ombi lenye kuchukua muda** ni ya kutosha ikiwa tunataka **jaribu kuiba jibu la mwathiriwa**. Lakini ikiwa unataka kufanya shambulio lenye utata zaidi hii itakuwa muundo wa kawaida wa shambulio.
Kwanza kabisa **ombi la kwanza** likitumia **Kupotosha Ombi la HTTP**, kisha **ombi lenye kuchukua muda** na kisha **ombi 1 au zaidi la mzigo** ambalo majibu yake yatatumiwa kwa waathiriwa.
### Kukamata maombi ya watumiaji wengine <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
Kama ilivyo na malipo yaliyofahamika ya Kupotosha Ombi la HTTP, unaweza **kuiba ombi la mwathiriwa** na tofauti muhimu: Katika kesi hii unahitaji **maudhui yaliyotumwa yarudi kwenye jibu**, **hakuna uhifadhi endelevu** unahitajika.
Kisha, mara tu **ombi la awali** (buluu) liliposindika na **wakati****wakati****ombi lenye usingizi** linasindika (njano) **ombi linalofuata linalofika kutoka kwa mwathiriwa** litakuwa **kuongezwa kwenye foleni mara baada ya parameta iliyorudiwa**:
Kisha, **mwathiriwa** atapokea **jibu kwa ombi lenye usingizi** na ikiwa kwa wakati huo **muovu****alituma****ombi lingine**, **jibu kutoka kwa ombi la maudhui lililorudiwa litatumwa kwake**.
Mpaka sasa, tumepata jinsi ya kutumia mashambulio ya Kupotosha Ombi la HTTP kudhibiti **ombi** ambalo **jibu** mteja atapokea na jinsi unavyoweza kisha **kuiba jibu lililokusudiwa kwa mwathiriwa**.
Kuna maombi ya kuvutia kama **ombi la KICHWA** ambayo yameelezwa kutokuwa na **maudhui yoyote ndani ya mwili wa majibu** na inapaswa (lazima) **iwe na Content-Length** ya ombi kama **kama ilivyokuwa ombi la GET**.
Kisha, **mara tu lililokuwa buluu linajibiwa kwa muovu**, ombi la mwathiriwa linayofuata litawekwa kwenye foleni:
Kisha, **mwathiriwa** atapokea **jibu** kutoka kwa **ombi la KICHWA**, ambalo **litakuwa na Content-Length lakini hakuna maudhui kabisa**. Kwa hivyo, wakala **hautatuma jibu hili** kwa mwathiriwa, bali **utangoja** kwa **maudhui**, ambayo kimsingi itakuwa **jibu kwa ombi la njano** (pia lililoingizwa na muovu):
Kufuatia mfano uliopita, ukijua kwamba unaweza **kudhibiti mwili** wa ombi ambalo jibu lake linatarajiwa kupokea na muathiriwa na kwamba jibu la **HEAD** kawaida lina **Content-Type na Content-Length** katika vichwa vyake, unaweza **kutuma ombi kama ifuatavyo** kusababisha XSS kwa muathiriwa bila ukurasa kuwa na udhaifu wa XSS:
Kwa kutumia shambulio la Utata wa Yaliyomo lililopita la kudhoofisha majibu yaliyosafishwa, **ikiwa cache inahifadhi jibu kwa ombi lililofanywa na muathiriwa na jibu hili ni moja linalosababisha XSS, basi cache imechafuliwa**.
Tambua kwamba katika kesi hii ikiwa **"muathiriwa" ni mshambuliaji** anaweza sasa kufanya **kudhoofisha cache kwa URL za kupindukia** kwani anaweza **kudhibiti URL itakayohifadhiwa** na jibu la uovu.
Shambulio hili ni sawa na lile lililopita, lakini **badala ya kuingiza mzigo ndani ya cache, mshambuliaji atahifadhi habari za muathiriwa ndani ya cache:**
Ili kufanikisha hili, mshambuliaji anahitaji kupata mwisho wa programu ya wavuti ambao **unarejea baadhi ya thamani ndani ya majibu** na **kujua urefu wa yaliyomo wa jibu la HEAD**.
Hata hivyo, angalia jinsi **data iliyorejelewa ilikuwa na ukubwa kulingana na Content-Length** ya jibu la **HEAD** lililosababisha jibu la HTTP linalofaa katika foleni ya majibu**.
Kwa hivyo, **ombi la pili la muathiriwa** litakuwa **likipokea** kama **jibu kitu kilichoundwa kabisa na mshambuliaji**. Kwa kuwa jibu limeundwa kabisa na mshambuliaji, yeye pia **anaweza kufanya proksi kuhifadhi jibu**.
