<summary><strong>Dowiedz się, jak 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ź [**PLAN SUBSKRYPCJI**](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) github repos.
Użyj [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks), aby łatwo tworzyć i **automatyzować przepływy pracy** przy użyciu najbardziej zaawansowanych narzędzi społeczności na świecie.\
> * W **zatruciu pamięci podręcznej** atakujący powoduje, że aplikacja przechowuje w pamięci podręcznej pewne złośliwe treści, a te treści są serwowane z pamięci podręcznej innym użytkownikom aplikacji.
> * W **oszustwie pamięci podręcznej** atakujący powoduje, że aplikacja przechowuje w pamięci podręcznej pewne wrażliwe treści należące do innego użytkownika, a następnie atakujący odzyskuje te treści z pamięci podręcznej.
Zatrucie pamięci podręcznej ma na celu manipulację pamięcią podręczną po stronie klienta, aby zmusić klientów do ładowania zasobów, które są nieoczekiwane, częściowe lub kontrolowane przez atakującego. Zakres wpływu zależy od popularności dotkniętej strony, ponieważ skażona odpowiedź jest serwowana wyłącznie użytkownikom odwiedzającym stronę podczas okresu zanieczyszczenia pamięci podręcznej.
1.**Identyfikacja niezakodowanych danych wejściowych**: Są to parametry, które, chociaż nie są wymagane do przechowywania żądania w pamięci podręcznej, mogą zmienić odpowiedź zwróconą przez serwer. Identyfikacja tych danych wejściowych jest kluczowa, ponieważ mogą być wykorzystane do manipulacji pamięcią podręczną.
2.**Wykorzystanie niezakodowanych danych wejściowych**: Po zidentyfikowaniu niezakodowanych danych wejściowych, kolejnym krokiem jest zrozumienie, jak wykorzystać te parametry do modyfikacji odpowiedzi serwera w sposób korzystny dla atakującego.
3.**Zapewnienie, że skażona odpowiedź jest przechowywana w pamięci podręcznej**: Ostatnim krokiem jest zapewnienie, że zmodyfikowana odpowiedź jest przechowywana w pamięci podręcznej. W ten sposób każdy użytkownik uzyskujący dostęp do dotkniętej strony podczas skażenia pamięci podręcznej otrzyma skażoną odpowiedź.
Zwykle, gdy odpowiedź została **przechowana w pamięci podręcznej**, będzie istniał **nagłówek wskazujący na to**, można sprawdzić, na jakie nagłówki należy zwrócić uwagę w tym poście: [**Nagłówki pamięci podręcznej HTTP**](../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
Jeśli podejrzewasz, że odpowiedź jest przechowywana w pamięci podręcznej, możesz spróbować **wysłać żądania z nieprawidłowym nagłówkiem**, na które powinno być odpowiedzią **kod stanu 400**. Następnie spróbuj normalnie uzyskać dostęp do żądania i jeśli **odpowiedź to kod stanu 400**, wiesz, że jest podatne (i możesz nawet przeprowadzić atak typu DoS).\
Nieprawidłowo skonfigurowanym nagłówkiem może być po prostu `\:` jako nagłówek.\
Należy zauważyć, że czasami tego rodzaju kody stanu nie są przechowywane w pamięci podręcznej, więc ten test będzie bezużyteczny.
Możesz użyć [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943), aby **przez próbę i błąd** przeprowadzić atak na parametry i nagłówki, które mogą **zmieniać odpowiedź strony**. Na przykład strona może używać nagłówka `X-Forwarded-For`, aby wskazać klientowi, skąd ma załadować skrypt:
Po zidentyfikowaniu parametru/nagłówka sprawdź, jak jest on **oczyszczany** i **gdzie** jest **odzwierciedlany** lub wpływa na odpowiedź z nagłówka. Czy można go w jakiś sposób wykorzystać (wykonać XSS lub załadować kod JS kontrolowany przez ciebie? przeprowadzić atak DoS?...)
Po zidentyfikowaniu **strony**, która może być wykorzystana, **parametru/nagłówka**, który należy użyć i **sposobu** jego wykorzystania, musisz zdobyć stronę z pamięci podręcznej. W zależności od zasobu, który próbujesz umieścić w pamięci podręcznej, może to zająć trochę czasu, możliwe, że będziesz musiał próbować przez kilka sekund.\
Nagłówek **`X-Cache`** w odpowiedzi może być bardzo przydatny, ponieważ może mieć wartość **`miss`**, gdy żądanie nie zostało umieszczone w pamięci podręcznej, i wartość **`hit`**, gdy jest umieszczone w pamięci podręcznej.\
Nagłówek **`Cache-Control`** również jest interesujący, aby dowiedzieć się, czy zasób jest umieszczany w pamięci podręcznej i kiedy zostanie ponownie umieszczony w pamięci podręcznej: `Cache-Control: public, max-age=1800`\
Innym interesującym nagłówkiem jest **`Vary`**. Ten nagłówek jest często używany do **wskazania dodatkowych nagłówków**, które są traktowane jako **część klucza pamięci podręcznej**, nawet jeśli normalnie nie są kluczowe. Dlatego jeśli użytkownik zna `User-Agent` ofiary, którą celuje, może zatruć pamięć podręczną dla użytkowników korzystających z tego konkretnego `User-Agent`.\
Jeszcze jeden nagłówek związany z pamięcią podręczną to **`Age`**. Określa on czas w sekundach, przez który obiekt znajduje się w pamięci podręcznej serwera pośredniczącego.
Podczas umieszczania żądania w pamięci podręcznej **uważaj na używane nagłówki**, ponieważ niektóre z nich mogą być **niespodziewanie używane jako kluczowe**, a ofiara będzie musiała użyć tego samego nagłówka. Zawsze **testuj** zatruwanie pamięci podręcznej z **różnymi przeglądarkami**, aby sprawdzić, czy działa.
Pliki cookie mogą również być odzwierciedlane w odpowiedzi strony. Jeśli można je wykorzystać do spowodowania ataku XSS, na przykład, można będzie wykorzystać XSS w kilku klientach, które wczytują złośliwą odpowiedź z pamięci podręcznej.
### Wykorzystanie wielu nagłówków do wykorzystania podatności na zatrucie pamięci podręcznej witryny <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
Czasami będziesz musiał wykorzystać **kilka niezależnych wejść**, aby móc nadużyć pamięci podręcznej. Na przykład, możesz znaleźć **przekierowanie otwarte** jeśli ustawisz `X-Forwarded-Host` na domenę kontrolowaną przez ciebie i `X-Forwarded-Scheme` na `http`. **Jeśli** serwer przekierowuje wszystkie żądania **HTTP** na **HTTPS** i używa nagłówka `X-Forwarded-Scheme` jako nazwy domeny dla przekierowania. Możesz kontrolować, gdzie strona jest przekierowywana.
Jeśli odkryjesz, że nagłówek **`X-Host`** jest używany jako **nazwa domeny do ładowania zasobu JS**, ale nagłówek **`Vary`** w odpowiedzi wskazuje na **`User-Agent`**, musisz znaleźć sposób na wydostanie User-Agent ofiary i zatrucie pamięci podręcznej, używając tego user agenta:
[Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) można użyć do automatycznego testowania zatrucia pamięci podręcznej sieci Web. Obsługuje wiele różnych technik i jest bardzo konfigurowalny.
Użyj [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks), aby łatwo tworzyć i **automatyzować zadania** z wykorzystaniem najbardziej zaawansowanych narzędzi społecznościowych na świecie.\
ATS przekazywał fragment wewnątrz adresu URL bez usuwania go i generował klucz pamięci podręcznej, używając tylko hosta, ścieżki i zapytania (ignorując fragment). Dlatego żądanie `/#/../?r=javascript:alert(1)` zostało wysłane do backendu jako `/#/../?r=javascript:alert(1)`, a klucz pamięci podręcznej nie zawierał ładunku, tylko hosta, ścieżkę i zapytanie.
Wysłanie nieprawidłowej wartości w nagłówku `content-type` wywoływało odpowiedź 405 z pamięci podręcznej. Klucz pamięci podręcznej zawierał ciasteczko, więc możliwe było tylko atakowanie nieuwierzytelnionych użytkowników.
GitLab używa kubełków GCP do przechowywania statycznych treści. **Kubełki GCP** obsługują **nagłówek `x-http-method-override`**. Dlatego można było wysłać nagłówek `x-http-method-override: HEAD` i zatrucić pamięć podręczną, zwracając pusty ciało odpowiedzi. Może również obsługiwać metodę `PURGE`.
W aplikacjach Ruby on Rails często wykorzystuje się oprogramowanie pośredniczące Rack. Kod Rack ma na celu pobranie wartości nagłówka **`x-forwarded-scheme`** i ustawienie jej jako schematu żądania. Gdy wysłany jest nagłówek `x-forwarded-scheme: http`, następuje przekierowanie 301 do tej samej lokalizacji, co potencjalnie powoduje odmowę usługi (DoS) dla tego zasobu. Dodatkowo, aplikacja może uwzględniać nagłówek `X-forwarded-host` i przekierowywać użytkowników na określony host. To zachowanie może prowadzić do ładowania plików JavaScript z serwera atakującego, co stanowi ryzyko dla bezpieczeństwa.
Cloudflare wcześniej buforował odpowiedzi 403. Próba dostępu do zasobów S3 lub Azure Storage Blobs z nieprawidłowymi nagłówkami autoryzacji skutkowała odpowiedzią 403, która była buforowana. Chociaż Cloudflare zaprzestał buforowania odpowiedzi 403, to zachowanie to może nadal występować w innych usługach proxy.
Bufory podręczne często zawierają określone parametry GET w kluczu pamięci podręcznej. Na przykład, Varnish Fastly buforował parametr `size` w żądaniach. Jednak jeśli wraz z poprawną wartością została wysłana również zakodowana wartość parametru (np. `siz%65`) z błędną wartością, klucz pamięci podręcznej był konstruowany przy użyciu poprawnego parametru `size`. Jednak backend przetwarzał wartość w zakodowanym parametrze URL. Zakodowanie drugiego parametru `size` powodowało jego pominięcie przez pamięć podręczną, ale wykorzystanie przez backend. Przypisanie wartości 0 do tego parametru skutkowało buforowalnym błędem 400 Bad Request.
Niektórzy programiści blokują żądania z agentami użytkownika pasującymi do narzędzi o dużym ruchu, takich jak FFUF lub Nuclei, aby zarządzać obciążeniem serwera. Ironicznie, takie podejście może wprowadzać podatności, takie jak zatrucie pamięci podręcznej i DoS.
[RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) określa dopuszczalne znaki w nazwach nagłówków. Nagłówki zawierające znaki spoza określonego zakresu **tchar** powinny idealnie wywoływać odpowiedź 400 Bad Request. W praktyce serwery nie zawsze przestrzegają tego standardu. Przykładem jest Akamai, który przekazuje nagłówki z nieprawidłowymi znakami i buforuje każdy błąd 400, o ile nie jest obecny nagłówek `cache-control`. Zidentyfikowano wzorzec podatny na wykorzystanie, w którym wysłanie nagłówka z nielegalnym znakiem, takim jak `\`, skutkowało buforowalnym błędem 400 Bad Request.
Celem zatrucia pamięci podręcznej jest sprawienie, aby klienci **ładowali zasoby, które zostaną zapisane w pamięci podręcznej wraz z ich poufnymi informacjami**.
Po pierwsze, zauważ, że **rozszerzenia** takie jak `.css`, `.js`, `.png` itp. są zazwyczaj **skonfigurowane** do **zapisywania** w **pamięci podręcznej**. Dlatego jeśli uzyskasz dostęp do `www.example.com/profile.php/nonexistent.js`, pamięć podręczna prawdopodobnie przechowa odpowiedź, ponieważ widzi rozszerzenie `.js`. Jednak jeśli **aplikacja** odtwarza **poufne** treści użytkownika przechowywane w _www.example.com/profile.php_, można **ukraść** te treści od innych użytkowników.
<summary><strong>Dowiedz się, jak 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ć **reklamę swojej firmy w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLAN SUBSKRYPCJI**](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) repozytoriów github.
