<summary><strong>Naucz się hakować AWS od zera do bohatera z</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLANY SUBSKRYPCYJNE**](https://github.com/sponsors/carlospolop)!
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) na GitHubie.
**Technika tej publikacji została zaczerpnięta z wideo:** [**https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s**](https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s)
**Główną różnicą** między tą techniką a zwykłym Desynchronizacją Żądań HTTP jest to, że **zamiast atakować żądanie ofiary, dodając do niego prefiks**, będziemy **ujawniać lub modyfikować odpowiedź, którą otrzymuje ofiara**. Robimy to, wysyłając **2 kompletnie różne żądania, aby desynchronizować kolejkę odpowiedzi proxy**.
Ponieważ będziemy w stanie **desynchronizować kolejkę odpowiedzi**, odpowiedź z **legitymalnego żądania ofiary zostanie wysłana do atakującego**, lub przez **wstrzyknięcie kontrolowanej treści atakującego w odpowiedź do ofiary**.
HTTP/1.1 pozwala na **żądanie różnych zasobów bez konieczności oczekiwania na poprzednie**. Dlatego, jeśli jest **proxy** pośrodku, to zadaniem proxy jest **utrzymywanie zsynchronizowanego dopasowania wysłanych żądań do backendu i odpowiedzi z niego**.
Jednakże, istnieje problem desynchronizacji kolejki odpowiedzi. Jeśli atakujący wysyła atak Desynchronizacji Odpowiedzi HTTP i odpowiedzi na **początkowe żądanie i to podszyte są odpowiedziane natychmiast**, odpowiedź podszyta nie zostanie wstawiona do kolejki odpowiedzi ofiary, ale **po prostu zostanie odrzucona jako błąd**.
Dlatego konieczne jest, aby **podszyte żądanie zajęło więcej czasu na przetworzenie** w serwerze backendowym. Dlatego, gdy podszyte żądanie zostanie przetworzone, komunikacja z atakującym będzie zakończona.
Jeśli w tej konkretnej sytuacji **ofiara wysłała żądanie** i **podszyte żądanie zostanie odpowiedziane przed** prawidłowym żądaniem, **podszyta odpowiedź zostanie wysłana do ofiary**. W rezultacie atakujący będzie **kontrolować żądanie "wykonane" przez ofiarę**.
Co więcej, jeśli **atakujący wykonuje żądanie** i **legitymacyjna odpowiedź** na **żądanie ofiary jest odpowiedziana****przed** żądaniem atakującego. **Odpowiedź do ofiary zostanie wysłana do atakującego**, **kradnąc** odpowiedź dla ofiary (która może zawierać na przykład nagłówek **Set-Cookie**).
Inną **ciekawą różnicą** w porównaniu z zwykłym **Desynchronizacją Żądań HTTP** jest to, że w zwykłym ataku desynchronizacji żądań HTTP, **celem** jest **modyfikacja początku żądania ofiary**, aby wykonała ona nieoczekiwane działanie. W ataku **Desynchronizacji Odpowiedzi HTTP**, wysyłając pełne żądania, można **wstrzyknąć w jednym ładunku dziesiątki odpowiedzi**, które będą **desynchronizować dziesiątki użytkowników**, którzy będą **odbierać****wstrzyknięte odpowiedzi**.
Oprócz możliwości **łatwiejszego rozprowadzania dziesiątek exploitów** wśród prawidłowych użytkowników, można to również wykorzystać do spowodowania **DoS** na serwerze.
Jak wyjaśniono wcześniej, aby wykorzystać tę technikę, konieczne jest, aby **pierwsza podszyta wiadomość** do serwera **zajmowała dużo czasu na przetworzenie**.
Ten **czasochłonny żądanie jest wystarczający**, jeśli chcemy **spróbować ukraść odpowiedź ofiary**. Ale jeśli chcesz przeprowadzić bardziej złożony exploit, to będzie to powszechna struktura dla exploitu.
Po pierwsze **początkowe** żądanie wykorzystujące **Desynchronizację Żądań HTTP**, następnie **czasochłonne żądanie**, a następnie **1 lub więcej żądań ładunkowych**, których odpowiedzi zostaną wysłane do ofiar.
Podobnie jak w przypadku znanych ładunków Desynchronizacji Żądań HTTP, możesz **ukraść żądanie ofiary** z jedną ważną różnicą: W tym przypadku potrzebujesz, aby **wysłana treść została odzwierciedlona w odpowiedzi**, **nie jest wymagane trwałe przechowywanie**.
Następnie, gdy **początkowe żądanie** (niebieskie) zostało **przetworzone** i **podczas** gdy **śpiące** jest przetwarzane (żółte), **następne żądanie, które przychodzi od ofiary**, zostanie **dodane do kolejki zaraz po odzwierciedlonym parametrze**:
Następnie **ofiara** otrzyma **odpowiedź na żądanie śpiące** i jeśli w międzyczasie **atakujący wysłał kolejne żądanie**, **odpowiedź z żądania odzwierciedlonej treści zostanie wysłana do niego**.
Do tej pory nauczyliśmy się wykorzystywać ataki Desynchronizacji Żądań HTTP do **kontroli****żądania**, **na które****odpowiedź****otrzyma****klient** i jak można wtedy **ukraść odpowiedź, która była przeznaczona dla ofiary**.
Istnieją interesujące żądania, takie jak żądanie **HEAD**, które są określone jako nieposiadające **żadnej zawartości w ciele odpowiedzi** i które powinny (muszą) **zawierać Content-Length** żądania, jak **gdyby to było żądanie GET**.
Następnie **ofiara** otrzyma **odpowiedź** z **żądania HEAD**, która **będzie zawierać Content-Length, ale w ogóle nie będzie zawierać treści**. Dlatego, proxy **nie wyśle tej odpowiedzi** do ofiary, ale będzie **czekać** na **jakąś treść**, która faktycznie będzie **odpowiedzią na żądanie żółte** (również wstrzyknięte przez atakującego):
W oparciu o poprzedni przykład, mając świadomość, że można **kontrolować treść** żądania, którego odpowiedź otrzyma ofiara, a **odpowiedź HEAD** zazwyczaj zawiera w nagłówkach **Content-Type i Content-Length**, można **wysłać żądanie takie jak to poniżej**, aby **wywołać XSS** u ofiary, nawet jeśli strona nie jest podatna na XSS:
Wykorzystując wcześniej omawiany atak zamieszania treści odpowiedzi desynchronizacji, **jeśli pamięć podręczna przechowuje odpowiedź na żądanie wykonane przez ofiarę, a ta odpowiedź jest wstrzyknięta i powoduje XSS, to pamięć podręczna jest zatruta**.
Zauważ, że w tym przypadku jeśli **"ofiara" jest atakującym**, może teraz przeprowadzić **zatrucie pamięci podręcznej w dowolnych adresach URL**, ponieważ może **kontrolować adres URL, który zostanie zapisany w pamięci podręcznej** za pomocą złośliwej odpowiedzi.
Ten atak jest podobny do poprzedniego, ale **zamiast wstrzykiwać ładunek do pamięci podręcznej, atakujący będzie przechowywał informacje ofiary w pamięci podręcznej:**
Celem tego ataku jest ponowne wykorzystanie **desynchronizacji odpowiedzi** w celu **przekazania przez proxy odpowiedzi w 100% wygenerowanej przez atakującego**.
Aby osiągnąć ten cel, atakujący musi znaleźć punkt końcowy aplikacji internetowej, który **odzwierciedla pewne wartości w odpowiedzi** i **znać długość treści odpowiedzi HEAD**.
Ofiara otrzyma jako odpowiedź **odpowiedź HEAD + treść odpowiedzi drugiego żądania (zawierająca część odzwierciedlonych danych):**
.png>)
Zauważ jednak, że **odzwierciedlone dane miały rozmiar zgodny z Content-Length** odpowiedzi **HEAD**, co **wygenerowało poprawną odpowiedź HTTP w kolejce odpowiedzi**.
Dlatego **następne żądanie drugiej ofiary** otrzyma jako **odpowiedź coś całkowicie spreparowanego przez atakującego**. Ponieważ odpowiedź jest całkowicie spreparowana przez atakującego, może on również **spowodować, że proxy przechowa odpowiedź**.
