From 4e6a9a580b4eb6dd620fe013890d845e2b15dde7 Mon Sep 17 00:00:00 2001 From: Translator Date: Mon, 29 Sep 2025 14:20:40 +0000 Subject: [PATCH] Translated ['', 'src/pentesting-web/websocket-attacks.md', 'src/pentesti --- src/SUMMARY.md | 9 +- src/pentesting-web/race-condition.md | 180 ++++++++--------- src/pentesting-web/websocket-attacks.md | 245 ++++++++++++++++++------ 3 files changed, 284 insertions(+), 150 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index abe382dcf..be4d4275a 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -837,9 +837,14 @@ - [WWW2Exec - GOT/PLT](binary-exploitation/arbitrary-write-2-exec/aw2exec-got-plt.md) - [WWW2Exec - \_\_malloc_hook & \_\_free_hook](binary-exploitation/arbitrary-write-2-exec/aw2exec-__malloc_hook.md) - [Common Exploiting Problems](binary-exploitation/common-exploiting-problems.md) -- [Linux kernel exploitation - toctou](binary-exploitation/linux-kernel-exploitation/posix-cpu-timers-toctou-cve-2025-38352.md) - [Windows Exploiting (Basic Guide - OSCP lvl)](binary-exploitation/windows-exploiting-basic-guide-oscp-lvl.md) -- [iOS Exploiting](binary-exploitation/ios-exploiting.md) +- [iOS Exploiting](binary-exploitation/ios-exploiting/README.md) + - [ios CVE-2020-27950-mach_msg_trailer_t](binary-exploitation/ios-exploiting/CVE-2020-27950-mach_msg_trailer_t.md) + - [ios CVE-2021-30807-IOMobileFrameBuffer](binary-exploitation/ios-exploiting/CVE-2021-30807-IOMobileFrameBuffer.md) + - [ios Corellium](binary-exploitation/ios-exploiting/ios-corellium.md) + - [ios Heap Exploitation](binary-exploitation/ios-exploiting/ios-example-heap-exploit.md) + - [ios Physical UAF - IOSurface](binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md) + # 🤖 AI - [AI Security](AI/README.md) diff --git a/src/pentesting-web/race-condition.md b/src/pentesting-web/race-condition.md index e00c8652b..bec674f4f 100644 --- a/src/pentesting-web/race-condition.md +++ b/src/pentesting-web/race-condition.md @@ -3,56 +3,56 @@ {{#include ../banners/hacktricks-training.md}} > [!WARNING] -> Vir 'n diep begrip van hierdie tegniek, kyk na die oorspronklike verslag in [https://portswigger.net/research/smashing-the-state-machine](https://portswigger.net/research/smashing-the-state-machine) +> Vir 'n diep begrip van hierdie tegniek, sien die oorspronklike verslag by [https://portswigger.net/research/smashing-the-state-machine](https://portswigger.net/research/smashing-the-state-machine) -## Verbetering van Race Condition Aanvalle +## Verbetering van Race Condition-aanvalle -Die hoofhindernis om voordeel te trek uit race condities is om te verseker dat verskeie versoeke gelyktydig hanteer word, met **baie min verskil in hul verwerkingstye—ideaal gesproke, minder as 1ms**. +Die grootste struikelblok om voordeel te trek uit race conditions is om te verseker dat meerdere requests terselfdertyd hanteer word, met **baie min verskil in hul verwerkingstye—ideaal minder as 1ms**. -Hier kan jy 'n paar tegnieke vir Sinchronisering van Versoeke vind: +Hier kan jy 'n paar tegnieke vind om requests te sinkroniseer: -#### HTTP/2 Enkel-Pakket Aanval vs. HTTP/1.1 Laaste-Byte Sinchronisering +#### HTTP/2 Single-Packet Attack vs. HTTP/1.1 Last-Byte Synchronization -- **HTTP/2**: Ondersteun die sending van twee versoeke oor 'n enkele TCP-verbinding, wat die impak van netwerk jitter verminder. egter, weens bediener-kant variasies, mag twee versoeke nie voldoende wees vir 'n konsekwente race condition uitbuiting nie. -- **HTTP/1.1 'Laaste-Byte Sync'**: Maak dit moontlik om die meeste dele van 20-30 versoeke vooraf te stuur, terwyl 'n klein fragment weerhou word, wat dan saamgestuur word, wat gelyktydige aankoms by die bediener bereik. +- **HTTP/2**: Ondersteun die stuur van twee requests oor 'n enkele TCP-verbinding, wat die impak van netwerk-jitter verminder. Weens bediener-side variasies mag twee requests egter nie genoeg wees vir 'n konsekwente race condition-uitbuiting nie. +- **HTTP/1.1 'Last-Byte Sync'**: Maak dit moontlik om die meeste dele van 20-30 requests vooraf te stuur, terwyl 'n klein fragment teruggehou word, wat dan saam gestuur word, en sodoende gelyktydige aankoms by die bediener bereik. -**Voorbereiding vir Laaste-Byte Sync** behels: +**Voorbereiding vir Last-Byte Sync** behels: -1. Stuur koptekste en liggaamsdata minus die finale byte sonder om die stroom te beëindig. -2. Pauzeer vir 100ms na die aanvanklike sending. -3. Deaktiveer TCP_NODELAY om Nagle se algoritme te benut vir die bundeling van finale rame. -4. Ping om die verbinding op te warm. +1. Stuur headers en body-data minus die laaste byte sonder om die stroom te beëindig. +2. Pouseer vir 100ms na die aanvanklike stuur. +3. Deaktiveer TCP_NODELAY om Nagle's algorithm te gebruik vir die groepering van finale frames. +4. Pinging om die verbinding op te warm. -Die daaropvolgende sending van weerhoudende rame moet lei tot hul aankoms in 'n enkele pakket, verifieerbaar via Wireshark. Hierdie metode is nie van toepassing op statiese lêers nie, wat tipies nie betrokke is by RC-aanvalle nie. +Die daaropvolgende stuur van die teruggehoue frames behoort tot hul aankoms in 'n enkele pakket te lei, wat met Wireshark verifieerbaar is. Hierdie metode is nie van toepassing op statiese lêers nie, wat gewoonlik nie by RC attacks betrokke is nie. -### Aanpassing by Bediener Argitektuur +### Aanpassing by bediener-argitektuur -Om die teiken se argitektuur te verstaan is van kardinale belang. Voorpunt bedieners mag versoeke anders roete, wat tydsberekening beïnvloed. Voorkomende bediener-kant verbinding opwarming, deur onbelangrike versoeke, mag versoek tydsberekening normaliseer. +Om die teiken se argitektuur te verstaan is noodsaaklik. Front-end servers kan requests anders routeer, wat die timing beïnvloed. Preemptiewe server-side verbindingsopwarming deur onbeduidende requests kan versoektiming normaliseer. -#### Hantering van Sessie-gebaseerde Vergrendeling +#### Hantering van Session-Based Locking -Raamwerke soos PHP se sessiehandler serialiseer versoeke volgens sessie, wat moontlik kwesbaarhede verdoesel. Die gebruik van verskillende sessietokens vir elke versoek kan hierdie probleem omseil. +Frameworks soos PHP se session handler serialiseer requests per session, wat moontlik kwesbaarhede verskuil. Deur vir elke request verskillende session tokens te gebruik, kan hierdie probleem omseil word. -#### Oorkoming van Tempo of Hulpbron Limiete +#### Oorkom Rate- of Hulpbronbeperkings -As verbinding opwarming nie effektief is nie, kan die doelbewuste onttriggering van webbedieners se tempo of hulpbron limiet vertragings deur 'n vloed van dummy versoeke die enkel-pakket aanval fasiliteer deur 'n bediener-kant vertraging te veroorsaak wat bevorderlik is vir race condities. +As verbinding-opwarming ondoeltreffend is, kan die doelbewuste veroorsaak van webservers se rate- of hulpbronlimiet-vertragings deur 'n vloed van dummy requests die single-packet attack vergemaklik deur 'n server-side vertraging te skep wat race conditions bevorder. -## Aanval Voorbeelde +## Voorbeelde van Aanvalle -- **Tubo Intruder - HTTP2 enkel-pakket aanval (1 eindpunt)**: Jy kan die versoek na **Turbo intruder** stuur (`Extensions` -> `Turbo Intruder` -> `Send to Turbo Intruder`), jy kan die waarde wat jy wil brute force vir **`%s`** verander soos in `csrf=Bn9VQB8OyefIs3ShR2fPESR0FzzulI1d&username=carlos&password=%s` en dan die **`examples/race-single-packer-attack.py`** uit die afrollys kies: +- **Tubo Intruder - HTTP2 single-packet attack (1 endpoint)**: Jy kan die request stuur na **Turbo intruder** (`Extensions` -> `Turbo Intruder` -> `Send to Turbo Intruder`), jy kan in die request die waarde verander wat jy wil brute force vir **`%s`** soos in `csrf=Bn9VQB8OyefIs3ShR2fPESR0FzzulI1d&username=carlos&password=%s` en dan die **`examples/race-single-packer-attack.py`** uit die keuselys kies:
-As jy **verskillende waardes** gaan stuur, kan jy die kode met hierdie een wat 'n woordlys van die klembord gebruik, aanpas: +As jy van plan is om **verskillende waardes te stuur**, kan jy die kode wysig met hierdie een wat 'n woordlys vanaf die klembord gebruik: ```python passwords = wordlists.clipboard for password in passwords: engine.queue(target.req, password, gate='race1') ``` > [!WARNING] -> As die web nie HTTP2 ondersteun nie (slegs HTTP1.1) gebruik `Engine.THREADED` of `Engine.BURP` in plaas van `Engine.BURP2`. +> As die web HTTP2 nie ondersteun nie (slegs HTTP1.1), gebruik `Engine.THREADED` of `Engine.BURP` in plaas van `Engine.BURP2`. -- **Tubo Intruder - HTTP2 enkele-pakket aanval (Verskeie eindpunte)**: In die geval dat jy 'n versoek na 1 eindpunt moet stuur en dan verskeie na ander eindpunte om die RCE te aktiveer, kan jy die `race-single-packet-attack.py` skrip met iets soos verander: +- **Tubo Intruder - HTTP2 single-packet attack (Several endpoints)**: As jy 'n versoek na 1 endpoint moet stuur en dan verskeie na ander endpoints om die RCE te trigger, kan jy die `race-single-packet-attack.py`-skrip verander met iets soos: ```python def queueRequests(target, wordlists): engine = RequestEngine(endpoint=target.endpoint, @@ -83,16 +83,16 @@ engine.queue(confirmationReq, gate=currentAttempt) # send all the queued requests for this attempt engine.openGate(currentAttempt) ``` -- Dit is ook beskikbaar in **Repeater** via die nuwe '**Stuur groep in parallel**' opsie in Burp Suite. -- Vir **limit-overrun** kan jy net die **dieselfde versoek 50 keer** in die groep voeg. -- Vir **connection warming** kan jy **byvoeg** aan die **begin** van die **groep** 'n paar **versoeke** na 'n nie-statiese deel van die webbediener. -- Vir **delaying** die proses **tussen** die verwerking van **een versoek en 'n ander** in 'n 2 substates stappe, kan jy **extra versoeke tussen** albei versoeke voeg. -- Vir 'n **multi-endpoint** RC kan jy begin om die **versoek** te stuur wat **na die versteekte toestand** gaan en dan **50 versoeke** net daarna wat **die versteekte toestand** benut. +- Dit is ook beskikbaar in **Repeater** via die nuwe '**Send group in parallel**' opsie in Burp Suite. +- Vir **limit-overrun** kan jy net die **same request 50 times** by die groep voeg. +- Vir **connection warming** kan jy **add** aan die **beginning** van die **group** 'n paar **requests** na 'n nie-statiese deel van die web server. +- Vir **delaying** die proses **between** die verwerking van **one request and another** in 'n 2 substates stappe, kan jy **add extra requests between** beide requests. +- Vir 'n **multi-endpoint** RC kan jy begin deur die **request** te stuur wat **goes to the hidden state** en dan net ná dit **50 requests** wat die **hidden state** **exploits**.
-- **Geoutomatiseerde python skrip**: Die doel van hierdie skrip is om die e-pos van 'n gebruiker te verander terwyl dit dit voortdurend verifieer totdat die verifikasietoken van die nuwe e-pos by die laaste e-pos aankom (dit is omdat daar in die kode 'n RC gesien is waar dit moontlik was om 'n e-pos te verander maar die verifikasie na die ou een te stuur omdat die veranderlike wat die e-pos aandui reeds met die eerste een bevolk was).\ -Wanneer die woord "objetivo" in die ontvangde e-posse gevind word, weet ons ons het die verifikasietoken van die veranderde e-pos ontvang en beëindig ons die aanval. +- **Automated python script**: Die doel van hierdie skrip is om die e-pos van 'n gebruiker te verander terwyl dit voortdurend verifieer totdat die verification token van die nuwe e-pos by die laaste e-pos aankom (dit is omdat die kode 'n RC gesien het waar dit moontlik was om 'n e-pos te wysig maar die verification na die ou een gestuur is omdat die veranderlike wat die e-pos aandui reeds met die eerste gevul was).\ +Wanneer die woord "objetivo" in die ontvangde e-posse gevind word, weet ons dat ons die verification token van die veranderde e-pos ontvang het en ons beëindig die aanval. ```python # https://portswigger.net/web-security/race-conditions/lab-race-conditions-limit-overrun # Script from victor to solve a HTB challenge @@ -217,22 +217,22 @@ h2_conn.close_connection() response = requests.get(url, verify=False) ``` -### Verbetering van Enkelpakketaanval +### Verbetering van Single Packet Attack -In die oorspronklike navorsing word verduidelik dat hierdie aanval 'n limiet van 1,500 bytes het. egter, in [**hierdie pos**](https://flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/), is verduidelik hoe dit moontlik is om die 1,500-byte beperking van die enkelpakketaanval uit te brei na die **65,535 B vensterbeperking van TCP deur IP-laag fragmentasie te gebruik** (om 'n enkele pakket in verskeie IP-pakkette te verdeel) en hulle in 'n ander volgorde te stuur, wat dit moontlik maak om die pakket te voorkom om weer saamgestel te word totdat al die fragmente by die bediener aankom. Hierdie tegniek het die navorser in staat gestel om 10,000 versoeke in ongeveer 166ms te stuur. +In die oorspronklike navorsing word verduidelik dat hierdie aanval 'n limiet van 1,500 bytes het. Echter, in [**this post**](https://flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/), is verduidelik hoe dit moontlik is om die 1,500-byte beperking van die single packet attack uit te brei na die **65,535 B window limitation of TCP by using IP layer fragmentation** (deur 'n enkele pakket in verskeie IP-pakkette op te deel) en dit in 'n ander volgorde te stuur, wat voorkom dat die pakket saamgestel word totdat al die fragmente die bediener bereik het. Hierdie tegniek het die navorser in staat gestel om ongeveer 10,000 requests in ~166ms te stuur. -Let daarop dat alhoewel hierdie verbetering die aanval meer betroubaar maak in RC wat honderde/duisende pakkette vereis om op dieselfde tyd aan te kom, dit ook 'n paar sagtewarebeperkings kan hê. Sommige gewilde HTTP-bedieners soos Apache, Nginx en Go het 'n streng `SETTINGS_MAX_CONCURRENT_STREAMS` instelling van 100, 128 en 250. egter, ander soos NodeJS en nghttp2 het dit onbeperk.\ -Dit beteken basies dat Apache slegs 100 HTTP-verbindinge van 'n enkele TCP-verbinding sal oorweeg (wat hierdie RC-aanval beperk). +Let daarop dat alhoewel hierdie verbetering die aanval meer betroubaar maak in RC wat honderde/duisende pakkette vereis om terselfdertyd aan te kom, dit ook sekere sagteware-beperkings kan hê. Sommige populêre HTTP-servers soos Apache, Nginx en Go het 'n streng `SETTINGS_MAX_CONCURRENT_STREAMS` instelling van 100, 128 en 250. Ander soos NodeJS en nghttp2 het dit egter onbeperk.\ +Dit beteken basies dat Apache slegs 100 HTTP-verbindinge vanaf 'n enkele TCP-verbinding sal oorweeg (wat hierdie RC-aanval beperk). -Jy kan 'n paar voorbeelde van hierdie tegniek in die repo vind [https://github.com/Ry0taK/first-sequence-sync/tree/main](https://github.com/Ry0taK/first-sequence-sync/tree/main). +Jy kan sommige voorbeelde wat hierdie tegniek gebruik in die repo [https://github.com/Ry0taK/first-sequence-sync/tree/main](https://github.com/Ry0taK/first-sequence-sync/tree/main) vind. -## Rau BF +## Raw BF -Voor die vorige navorsing was daar 'n paar payloads wat gebruik is wat net probeer het om die pakkette so vinnig as moontlik te stuur om 'n RC te veroorsaak. +Voor die vorige navorsing was dit sommige payloads wat gebruik is wat net probeer het om die pakkette so vinnig as moontlik te stuur om 'n RC te veroorsaak. -- **Herhaler:** Kyk na die voorbeelde van die vorige afdeling. -- **Indringer**: Stuur die **versoek** na **Indringer**, stel die **aantal drade** op **30** binne die **Opsies-menu en,** kies as payload **Null payloads** en genereer **30.** -- **Turbo Indringer** +- **Repeater:** Check the examples from the previous section. +- **Intruder**: Stuur die **request** na **Intruder**, stel die **number of threads** op **30** in die **Options menu**, en kies as payload **Null payloads** en genereer **30**. +- **Turbo Intruder** ```python def queueRequests(target, wordlists): engine = RequestEngine(endpoint=target.endpoint, @@ -279,75 +279,75 @@ print(results) asyncio.run(main()) ``` -## **RC Metodologie** +## **RC Methodology** -### Limit-oortreding / TOCTOU +### Limit-overrun / TOCTOU -Dit is die mees basiese tipe van 'n race condition waar **kwesbaarhede** wat **verskyn** in plekke wat **die aantal kere wat jy 'n aksie kan uitvoer, beperk**. Soos om dieselfde afslagkode verskeie kere in 'n webwinkel te gebruik. 'n Baie maklike voorbeeld kan gevind word in [**hierdie verslag**](https://medium.com/@pravinponnusamy/race-condition-vulnerability-found-in-bug-bounty-program-573260454c43) of in [**hierdie fout**](https://hackerone.com/reports/759247)**.** +Dit is die mees basiese tipe race condition waar **vulnerabilities** voorkom op plekke wat die aantal kere wat jy 'n aksie kan uitvoer beperk. Soos om dieselfde discount code in 'n web store verskeie kere te gebruik. 'n Baie eenvoudige voorbeeld is te vind in [**this report**](https://medium.com/@pravinponnusamy/race-condition-vulnerability-found-in-bug-bounty-program-573260454c43) of in [**this bug**](https://hackerone.com/reports/759247)**.** -Daar is baie variasies van hierdie tipe aanval, insluitend: +Daar is baie variasies van hierdie soort aanval, insluitend: -- 'n Geskenkkaart verskeie kere inlos -- 'n Produk verskeie kere beoordeel -- Kontant onttrek of oordra bo jou rekeningbalans -- 'n Enkele CAPTCHA-oplossing hergebruik -- 'n Anti-brute-force koerslimiet omseil +- Redeeming a gift card multiple times +- Rating a product multiple times +- Withdrawing or transferring cash in excess of your account balance +- Reusing a single CAPTCHA solution +- Bypassing an anti-brute-force rate limit -### **Versteekte substates** +### **Hidden substates** -Die benutting van komplekse race conditions behels dikwels die benutting van kort geleenthede om met versteekte of **onbedoelde masjien substates** te kommunikeer. Hier is hoe om dit aan te pak: +Exploiting complex race conditions behels dikwels om voordeel te trek uit kortgeleentheid om met verborgen of **unintended machine substates** te interaksie. Hier is hoe om dit te benader: -1. **Identifiseer Potensiële Versteekte Substates** -- Begin deur eindpunte te identifiseer wat kritieke data, soos gebruikersprofiele of wagwoordherstelprosesse, wysig of mee kommunikeer. Fokus op: -- **Berging**: Verkies eindpunte wat server-kant volhoubare data manipuleer bo dié wat data kliënt-kant hanteer. -- **Aksie**: Soek na operasies wat bestaande data verander, wat meer waarskynlik is om benutbare toestande te skep in vergelyking met dié wat nuwe data byvoeg. -- **Sleuteling**: Suksesvolle aanvalle behels gewoonlik operasies wat op dieselfde identifiseerder gesleutel is, bv. gebruikersnaam of hersteltoken. -2. **Voer Aanvanklike Probing Uit** -- Toets die geïdentifiseerde eindpunte met race condition aanvalle, en let op enige afwykings van verwagte uitkomste. Onverwagte reaksies of veranderinge in toepassingsgedrag kan 'n kwesbaarheid aandui. -3. **Demonstreer die Kwesbaarheid** -- Beperk die aanval tot die minimale aantal versoeke wat nodig is om die kwesbaarheid te benut, dikwels net twee. Hierdie stap mag verskeie pogings of outomatisering vereis weens die presiese tydsberekening wat betrokke is. +1. **Identify Potential Hidden Substates** +- Begin deur endpunte te identifiseer wat kritiese data wysig of daarmee interaksie het, soos user profiles of password reset-processes. Fokus op: +- **Storage**: Gee voorkeur aan endpunte wat server-side persistent data manipuleer bo daardie wat data client-side hanteer. +- **Action**: Soek na operasies wat bestaande data verander — dit is meer geneig om uitbuitbare toestande te skep in vergelyking met dié wat nuwe data byvoeg. +- **Keying**: Suksesvolle aanvalle behels gewoonlik operasies wat op dieselfde identifier gemik is, bv. username of reset token. +2. **Conduct Initial Probing** +- Toets die geïdentifiseerde endpunte met race condition-aanvalle en let op afwykings van verwagte uitkomste. Onverwagte antwoorde of veranderinge in toepassinggedrag kan 'n kwetsbaarheid aandui. +3. **Demonstrate the Vulnerability** +- Smal die aanval in tot die minimale aantal versoeke wat nodig is om die kwetsbaarheid uit te buit, dikwels net twee. Hierdie stap kan meerdere pogings of outomatisering vereis weens die presiese tydsberekening wat betrokke is. -### Tydsensitiewe Aanvalle +### Time Sensitive Attacks -Presisie in die tydsberekening van versoeke kan kwesbaarhede onthul, veral wanneer voorspelbare metodes soos tydstempels vir sekuriteits tokens gebruik word. Byvoorbeeld, die generering van wagwoordherstel tokens gebaseer op tydstempels kan identiese tokens vir gelyktydige versoeke toelaat. +Presisie in die tydsberekening van versoeke kan kwetsbaarhede openbaar, veral wanneer voorspelbare metodes soos timestamps gebruik word vir security tokens. Byvoorbeeld, die genereer van password reset tokens gebaseer op timestamps kan identiese tokens vir simultane versoeke toelaat. -**Om te Benut:** +**To Exploit:** -- Gebruik presiese tydsberekening, soos 'n enkele pakket aanval, om gelyktydige wagwoordherstel versoeke te maak. Identiese tokens dui op 'n kwesbaarheid aan. +- Gebruik presiese tydsberekening, soos 'n single packet attack, om concurrent password reset requests te verstuur. Identiese tokens dui op 'n kwetsbaarheid. -**Voorbeeld:** +**Example:** -- Versoek twee wagwoordherstel tokens op dieselfde tyd en vergelyk hulle. Ooreenstemmende tokens dui op 'n fout in token generasie. +- Request two password reset tokens op presies dieselfde tyd en vergelyk hulle. Ooreenstemmende tokens dui op 'n fout in token generation. -**Kyk na hierdie** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-exploiting-time-sensitive-vulnerabilities) **om dit te probeer.** +**Check this** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-exploiting-time-sensitive-vulnerabilities) **to try this.** -## Versteekte substates gevalstudies +## Hidden substates case studies -### Betaal & voeg 'n Item by +### Pay & add an Item -Kyk na hierdie [**PortSwigger Lab**](https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-insufficient-workflow-validation) om te sien hoe om te **betaal** in 'n winkel en **'n ekstra** item by te voeg wat jy **nie hoef te betaal nie**. +Check this [**PortSwigger Lab**](https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-insufficient-workflow-validation) om te sien hoe om in 'n store te **pay** en 'n **extra** item by te **add** wat jy nie hoef te betaal nie. -### Bevestig ander e-posse +### Confirm other emails -Die idee is om **'n e-posadres te verifieer en dit terselfdertyd na 'n ander een te verander** om uit te vind of die platform die nuwe een wat verander is, verifieer. +Die idee is om 'n e-posadres te **verify** en dit terselfdertyd na 'n ander een te verander om te ontdek of die platform die nuwe een verifieer. -### Verander e-pos na 2 e-posadresse koekie-gebaseerd +### Change email to 2 emails addresses Cookie based -Volgens [**hierdie navorsing**](https://portswigger.net/research/smashing-the-state-machine) was Gitlab kwesbaar vir 'n oorneem op hierdie manier omdat dit mag **stuur** die **e-posverifikasietoken van een e-pos na die ander e-pos**. +Volgens [**this research**](https://portswigger.net/research/smashing-the-state-machine) was Gitlab op hierdie wyse kwesbaar vir 'n takeover omdat dit moontlik die **email verification token of one email to the other email** kan **send**. -**Kyk na hierdie** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-single-endpoint) **om dit te probeer.** +**Check this** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-single-endpoint) **to try this.** -### Versteekte Databasis toestande / Bevestiging Omseiling +### Hidden Database states / Confirmation Bypass -As **2 verskillende skrywe** gebruik word om **inligting** binne 'n **databasis** toe te voeg, is daar 'n klein tydsdeel waar **slegs die eerste data geskryf is** binne die databasis. Byvoorbeeld, wanneer 'n gebruiker geskep word, kan die **gebruikersnaam** en **wagwoord** **geskryf** word en **dan die token** om die nuut geskepte rekening te bevestig, geskryf word. Dit beteken dat vir 'n kort tyd die **token om 'n rekening te bevestig is null**. +As **2 different writes** gebruik word om **information** binne 'n **database** by te voeg, bestaan daar 'n klein tydsbestek waarin slegs die eerste data geskryf is in die database. Byvoorbeeld, wanneer 'n user geskep word, kan die **username** en **password** geskryf word en daarna die token om die nuut geskepte account te bevestig. Dit beteken dat vir 'n kort tyd die **token to confirm an account is null**. -Daarom kan **die registrasie van 'n rekening en die stuur van verskeie versoeke met 'n leë token** (`token=` of `token[]=` of enige ander variasie) om die rekening onmiddellik te bevestig, toelaat om 'n **rekening te bevestig** waar jy nie die e-pos beheer nie. +Daarom kan **registering an account and sending several requests with an empty token** (`token=` or `token[]=` or any other variation) om die account dadelik te bevestig toelaat om **bevestig 'n rekening** waar jy nie die e-pos beheer nie. -**Kyk na hierdie** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-partial-construction) **om dit te probeer.** +**Check this** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-partial-construction) **to try this.** -### Omseil 2FA +### Bypass 2FA -Die volgende pseudo-kode is kwesbaar vir race condition omdat daar in 'n baie klein tyd die **2FA nie afgedwing** word terwyl die sessie geskep word: +Die volgende pseudo-code is kwetsbaar vir race condition omdat daar in 'n baie klein tydsbestek die **2FA is not enforced** terwyl die session geskep word: ```python session['userid'] = user.userid if user.mfa_enabled: @@ -355,22 +355,23 @@ session['enforce_mfa'] = True # generate and send MFA code to user # redirect browser to MFA code entry form ``` -### OAuth2 ewige volharding +### OAuth2 eternal persistence -Daar is verskeie [**OAUth verskaffers**](https://en.wikipedia.org/wiki/List_of_OAuth_providers). Hierdie dienste sal jou toelaat om 'n toepassing te skep en gebruikers te verifieer wat die verskaffer geregistreer het. Om dit te doen, sal die **klient** moet **toelaat dat jou toepassing** toegang tot sommige van hul data binne die **OAUth verskaffer**.\ -So, tot hier is dit net 'n algemene aanmelding met google/linkedin/github... waar jy 'n bladsy voorgelê word wat sê: "_Toepassing \ wil toegang tot jou inligting hê, wil jy dit toelaat?_" +There are several [**OAUth providers**](https://en.wikipedia.org/wiki/List_of_OAuth_providers). Hierdie dienste laat jou toe om 'n toepassing te skep en gebruikers te verifieer wat deur die provider geregistreer is. Om dit te doen, sal die **client** jou **toepassing toestemming moet gee** om 'n deel van hul data binne die **OAUth provider** te bereik.\ +Tot dusver net 'n gewone login met google/linkedin/github... waar jy 'n bladsy gesien kry wat sê: "_Application \ wants to access you information, do you want to allow it?_" #### Race Condition in `authorization_code` -Die **probleem** verskyn wanneer jy **dit aanvaar** en outomaties 'n **`authorization_code`** na die kwaadwillige toepassing stuur. Dan, hierdie **toepassing misbruik 'n Race Condition in die OAUth diensverskaffer om meer as een AT/RT** (_Authentication Token/Refresh Token_) van die **`authorization_code`** vir jou rekening te genereer. Basies, dit sal die feit misbruik dat jy die toepassing aanvaar het om toegang tot jou data te hê om **verskeie rekeninge te skep**. Dan, as jy **stop om die toepassing toe te laat om toegang tot jou data te hê, sal een paar AT/RT verwyder word, maar die ander sal steeds geldig wees**. +Die **probleem** verskyn wanneer jy **dit aanvaar** en dit outomaties 'n **`authorization_code`** na die kwaadwillige toepassing stuur. Dan misbruik die toepassing 'n Race Condition in die OAUth service provider om meer as een AT/RT (_Authentication Token/Refresh Token_) uit die **`authorization_code`** vir jou rekening te genereer. Basies sal dit die feit misbruik dat jy die toepassing toegang tot jou data gegee het om **verskeie rekeninge te skep**. Daarna, selfs al stop jy om die toepassing toegang tot jou data te gee, sal een paar AT/RT verwyder word, maar die ander sal steeds geldig wees. #### Race Condition in `Refresh Token` -Sodra jy 'n **geldige RT** **verkry** het, kan jy probeer om dit te **misbruik om verskeie AT/RT** te genereer en **selfs as die gebruiker die toestemmings** vir die kwaadwillige toepassing om toegang tot sy data te hê, **sal verskeie RT's steeds geldig wees.** +Sodra jy 'n **geldige RT** verkry het, kan jy probeer om dit te **misbruik om verskeie AT/RT te genereer** en **selfs as die gebruiker die toestemmings vir die kwaadwillige toepassing kanselleer**, sal **verskeie RTs steeds geldig bly.** ## **RC in WebSockets** -In [**WS_RaceCondition_PoC**](https://github.com/redrays-io/WS_RaceCondition_PoC) kan jy 'n PoC in Java vind om websocket boodskappe in **parallel** te stuur om **Race Conditions ook in Web Sockets** te misbruik. +- In [**WS_RaceCondition_PoC**](https://github.com/redrays-io/WS_RaceCondition_PoC) vind jy 'n PoC in Java om websocket boodskappe in **parallel** te stuur om **Race Conditions ook in Web Sockets** te misbruik. +- Met Burp’s WebSocket Turbo Intruder kan jy die **THREADED** engine gebruik om meerdere WS-verbindinge te skep en payloads parallel te stuur. Begin by die amptelike voorbeeld en stel `config()` (thread count) vir concurrency af; dit is dikwels meer betroubaar as om op 'n enkele verbinding te batche wanneer jy server‑side state oor WS handlers probeer race. Sien [RaceConditionExample.py](https://github.com/d0ge/WebSocketTurboIntruder/blob/main/src/main/resources/examples/RaceConditionExample.py). ## Verwysings @@ -380,5 +381,8 @@ In [**WS_RaceCondition_PoC**](https://github.com/redrays-io/WS_RaceCondition_PoC - [https://portswigger.net/research/smashing-the-state-machine](https://portswigger.net/research/smashing-the-state-machine) - [https://portswigger.net/web-security/race-conditions](https://portswigger.net/web-security/race-conditions) - [https://flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/](https://flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/) +- [WebSocket Turbo Intruder: Unearthing the WebSocket Goldmine](https://portswigger.net/research/websocket-turbo-intruder-unearthing-the-websocket-goldmine) +- [WebSocketTurboIntruder – GitHub](https://github.com/d0ge/WebSocketTurboIntruder) +- [RaceConditionExample.py](https://github.com/d0ge/WebSocketTurboIntruder/blob/main/src/main/resources/examples/RaceConditionExample.py) {{#include ../banners/hacktricks-training.md}} diff --git a/src/pentesting-web/websocket-attacks.md b/src/pentesting-web/websocket-attacks.md index bf42d484f..804febe0a 100644 --- a/src/pentesting-web/websocket-attacks.md +++ b/src/pentesting-web/websocket-attacks.md @@ -1,22 +1,22 @@ -# WebSocket Aanvalle +# WebSocket-aanvalle {{#include ../banners/hacktricks-training.md}} ## Wat is WebSockets -WebSocket verbindings word gevestig deur 'n aanvanklike **HTTP** handdruk en is ontwerp om **langdurig** te wees, wat bidireksionele boodskappe op enige tyd moontlik maak sonder die behoefte aan 'n transaksionele stelsel. Dit maak WebSockets veral voordelig vir toepassings wat **lae latensie of bediener-geïnisieerde kommunikasie** vereis, soos lewendige finansiële datastrome. +WebSocket-verbindinge word gevestig deur 'n aanvanklike **HTTP** handshake en is ontwerp om **lanklewende** te wees, wat tweerigtingboodskappe op enige tyd toelaat sonder die behoefte aan 'n transaksionele stelsel. Dit maak WebSockets veral voordelig vir toepassings wat **lae latensie of bediener-geïnisieerde kommunikasie** benodig, soos regstreekse finansiële datastrome. -### Vestiging van WebSocket Verbindings +### Vestiging van WebSocket-verbindinge -'n Gedetailleerde verduideliking oor die vestiging van WebSocket verbindings kan [**hier**](https://infosecwriteups.com/cross-site-websocket-hijacking-cswsh-ce2a6b0747fc) verkry word. In samevatting, WebSocket verbindings word gewoonlik geïnisieer via kliënt-kant JavaScript soos hieronder getoon: +'n Gedetaileerde verduideliking oor die vestiging van WebSocket-verbindinge is beskikbaar [**here**](https://infosecwriteups.com/cross-site-websocket-hijacking-cswsh-ce2a6b0747fc). In opsomming word WebSocket-verbindinge gewoonlik geïnisieer via client-side JavaScript soos hieronder getoon: ```javascript var ws = new WebSocket("wss://normal-website.com/ws") ``` -Die `wss` protokol dui 'n WebSocket-verbinding aan wat met **TLS** beveilig is, terwyl `ws` 'n **onbeveiligde** verbinding aandui. +Die `wss`-protokol dui op 'n WebSocket-verbinding wat beveilig is met **TLS**, terwyl `ws` 'n **onbeveiligde** verbinding aandui. -Tydens die verbindingsevaluering word 'n handdruk tussen die blaaier en bediener oor HTTP uitgevoer. Die handdrukproses behels dat die blaier 'n versoek stuur en die bediener antwoordgee, soos in die volgende voorbeelde geïllustreer: +Tydens die totstandkoming van die verbinding word 'n handshake tussen die blaaier en die bediener oor HTTP uitgevoer. Die handshake-proses behels dat die blaaier 'n versoek stuur en die bediener reageer, soos geïllustreer in die volgende voorbeelde: -Blaaier stuur 'n handdrukversoek: +Blaaier stuur 'n handshake-versoek: ```javascript GET /chat HTTP/1.1 Host: normal-website.com @@ -26,25 +26,25 @@ Connection: keep-alive, Upgrade Cookie: session=KOsEJNuflw4Rd9BDNrVmvwBF9rEijeE2 Upgrade: websocket ``` -Die bediener se handdrukrespons: +Server se handshake response: ```javascript HTTP/1.1 101 Switching Protocols Connection: Upgrade Upgrade: websocket Sec-WebSocket-Accept: 0FFP+2nmNIf/h+4BP36k9uzrYGk= ``` -Die verbinding bly oop vir boodskapswisseling in beide rigtings sodra dit gevestig is. +Die verbinding bly oop vir boodskapuitruiling in albei rigtings sodra dit ingestel is. -**Belangrike Punten van die WebSocket Handshake:** +**Belangrike punte van die WebSocket-handshake:** -- Die `Connection` en `Upgrade` headers dui die begin van 'n WebSocket handshake aan. -- Die `Sec-WebSocket-Version` header dui die verlangde WebSocket protokol weergawe aan, gewoonlik `13`. -- 'n Base64-gecodeerde ewekansige waarde word in die `Sec-WebSocket-Key` header gestuur, wat verseker dat elke handshake uniek is, wat help om probleme met kasproxies te voorkom. Hierdie waarde is nie vir outentisering nie, maar om te bevestig dat die antwoord nie deur 'n verkeerd geconfigureerde bediener of kas gegenereer is nie. -- Die `Sec-WebSocket-Accept` header in die bediener se antwoord is 'n hash van die `Sec-WebSocket-Key`, wat die bediener se bedoeling om 'n WebSocket verbinding te open, verifieer. +- Die `Connection` en `Upgrade` headers dui die inisiasie van 'n WebSocket-handshake aan. +- Die `Sec-WebSocket-Version` header dui die verlangde WebSocket-protokolweergawe aan, gewoonlik `13`. +- 'n Base64-geenkodeerde lukrake waarde word in die `Sec-WebSocket-Key` header gestuur, wat verseker dat elke handshake uniek is en help om probleme met caching proxies te voorkom. Hierdie waarde is nie vir autentisering nie, maar om te bevestig dat die antwoord nie deur 'n foutief gekonfigureerde bediener of cache gegenereer is nie. +- Die `Sec-WebSocket-Accept` header in die bediener se antwoord is 'n hash van die `Sec-WebSocket-Key`, wat die bediener se bedoeling bevestig om 'n WebSocket-verbinding te open. -Hierdie kenmerke verseker dat die handshake-proses veilig en betroubaar is, wat die pad baan vir doeltreffende regstreekse kommunikasie. +Hierdie kenmerke verseker dat die handshake-proses veilig en betroubaar is, en baan die weg vir doeltreffende regstreekse kommunikasie. -### Linux console +### Linux-konsol Jy kan `websocat` gebruik om 'n rou verbinding met 'n websocket te vestig. ```bash @@ -54,60 +54,177 @@ Of om 'n websocat-bediener te skep: ```bash websocat -s 0.0.0.0:8000 #Listen in port 8000 ``` -### MitM websocket verbindings +### MitM websocket verbindinge -As jy vind dat kliënte aan 'n **HTTP websocket** van jou huidige plaaslike netwerk gekoppel is, kan jy 'n [ARP Spoofing Attack ](../generic-methodologies-and-resources/pentesting-network/index.html#arp-spoofing)probeer om 'n MitM-aanval tussen die kliënt en die bediener uit te voer.\ -Sodra die kliënt probeer om te verbind, kan jy dan gebruik maak van: +As jy vind dat clients vanaf jou huidige plaaslike netwerk aan 'n **HTTP websocket** gekoppel is, kan jy 'n [ARP Spoofing Attack ](../generic-methodologies-and-resources/pentesting-network/index.html#arp-spoofing) probeer om 'n MitM attack tussen die client en die server uit te voer.\ +Sodra die client probeer om met jou te connect, kan jy dan gebruik: ```bash websocat -E --insecure --text ws-listen:0.0.0.0:8000 wss://10.10.10.10:8000 -v ``` -### Websockets opsporing +### Websockets enumeration -Jy kan die **tool** [**https://github.com/PalindromeLabs/STEWS**](https://github.com/PalindromeLabs/STEWS) **gebruik om bekend** **kwesbaarhede** in websockets outomaties te ontdek, te vingerafdruk en te soek. +Jy kan die **tool** [**https://github.com/PalindromeLabs/STEWS**](https://github.com/PalindromeLabs/STEWS) gebruik om outomaties bekende **vulnerabilities** in websockets te discover, fingerprint en te search. -### Websocket Ontwikkelhulpmiddels +### Websocket Debug tools -- **Burp Suite** ondersteun MitM websockets kommunikasie op 'n baie soortgelyke manier as wat dit vir gewone HTTP kommunikasie doen. -- Die [**socketsleuth**](https://github.com/snyk/socketsleuth) **Burp Suite uitbreiding** sal jou toelaat om beter Websocket kommunikasies in Burp te bestuur deur die **geskiedenis** te verkry, **afskakelreëls** in te stel, **ooreenkoms en vervang** reëls te gebruik, **Intruder** en **AutoRepeater** te gebruik. -- [**WSSiP**](https://github.com/nccgroup/wssip)**:** Kort vir "**WebSocket/Socket.io Proxy**", hierdie tool, geskryf in Node.js, bied 'n gebruikerskoppelvlak om **te vang, af te skakel, pasgemaakte** boodskappe te stuur en al WebSocket en Socket.IO kommunikasies tussen die kliënt en bediener te sien. -- [**wsrepl**](https://github.com/doyensec/wsrepl) is 'n **interaktiewe websocket REPL** wat spesifiek vir penetrasietoetsing ontwerp is. Dit bied 'n koppelvlak om **inkomende websocket boodskappe te observeer en nuwe te stuur**, met 'n maklik-om-te-gebruik raamwerk vir **outomatisering** van hierdie kommunikasie. -- [**https://websocketking.com/**](https://websocketking.com/) dit is 'n **web om te kommunikeer** met ander webs deur middel van **websockets**. -- [**https://hoppscotch.io/realtime/websocket**](https://hoppscotch.io/realtime/websocket) onder andere tipes kommunikasies/protokolle, bied dit 'n **web om te kommunikeer** met ander webs deur middel van **websockets.** +- **Burp Suite** ondersteun MitM websockets-kommunikasie op 'n baie soortgelyke wyse as wat dit vir gewone HTTP-kommunikasie doen. +- Die [**socketsleuth**](https://github.com/snyk/socketsleuth) **Burp Suite extension** sal jou toelaat om Websocket-kommunikasies in Burp beter te bestuur deur die **history** te kry, **interception rules** te stel, **match and replace** reëls te gebruik, en **Intruder** en **AutoRepeater.** +- [**WSSiP**](https://github.com/nccgroup/wssip)**:** Short for "**WebSocket/Socket.io Proxy**", hierdie tool, geskryf in Node.js, bied 'n gebruikerskoppelvlak om **capture, intercept, send custom** messages te doen en alle WebSocket en Socket.IO kommunikasie tussen kliënt en bediener te besigtig. +- [**wsrepl**](https://github.com/doyensec/wsrepl) is 'n **interactive websocket REPL** ontwerp spesifiek vir penetration testing. Dit verskaf 'n koppelvlak om **incoming websocket messages and sending new ones** waar te neem, met 'n maklik-om-te-gebruik raamwerk vir die **automating** van hierdie kommunikasie. +- [**https://websocketking.com/**](https://websocketking.com/) dit is 'n **web** om met ander webs te kommunikeer deur **websockets** te gebruik. +- [**https://hoppscotch.io/realtime/websocket**](https://hoppscotch.io/realtime/websocket) onder andere kommunikasie-/protokolsoorte, verskaf dit 'n **web** om met ander webs te kommunikeer deur **websockets** te gebruik. -## Ontsleuteling van Websocket +## Websocket ontsleuteling - [https://github.com/Anof-cyber/PyCript](https://github.com/Anof-cyber/PyCript) - [https://github.com/Anof-cyber/PyCript-WebSocket/](https://github.com/Anof-cyber/PyCript-WebSocket/) -## Websocket Laboratorium +## Websocket Lab -In [**Burp-Suite-Extender-Montoya-Course**](https://github.com/federicodotta/Burp-Suite-Extender-Montoya-Course) het jy 'n kode om 'n web te begin met websockets en in [**hierdie pos**](https://security.humanativaspa.it/extending-burp-suite-for-fun-and-profit-the-montoya-way-part-3/) kan jy 'n verduideliking vind. +In [**Burp-Suite-Extender-Montoya-Course**](https://github.com/federicodotta/Burp-Suite-Extender-Montoya-Course) het jy 'n kode om 'n web te launch wat websockets gebruik en in [**this post**](https://security.humanativaspa.it/extending-burp-suite-for-fun-and-profit-the-montoya-way-part-3/) kan jy 'n verklaring vind. ## Websocket Fuzzing -Die burp uitbreiding [**Backslash Powered Scanner**](https://github.com/PortSwigger/backslash-powered-scanner) laat nou ook toe om WebSocket boodskappe te fuzz. Jy kan meer inligting hieroor lees [**hier**](https://arete06.com/posts/fuzzing-ws/#adding-websocket-support-to-backslash-powered-scanner). +Die Burp extension [**Backslash Powered Scanner**](https://github.com/PortSwigger/backslash-powered-scanner) stel nou ook in staat om WebSocket-boodskappe te fuzz. Jy kan meer inligting daaroor lees [**here**](https://arete06.com/posts/fuzzing-ws/#adding-websocket-support-to-backslash-powered-scanner). -## Cross-site WebSocket kaping (CSWSH) +### WebSocket Turbo Intruder (Burp extension) -**Cross-site WebSocket kaping**, ook bekend as **cross-origin WebSocket kaping**, word geïdentifiseer as 'n spesifieke geval van **[Cross-Site Request Forgery (CSRF)](csrf-cross-site-request-forgery.md)** wat WebSocket handdrukke beïnvloed. Hierdie kwesbaarheid ontstaan wanneer WebSocket handdrukke slegs via **HTTP koekies** outentiseer sonder **CSRF tokens** of soortgelyke sekuriteitsmaatreëls. +PortSwigger's WebSocket Turbo Intruder bring Turbo Intruder–styl Python scripting en high‑rate fuzzing na WebSockets. Installeer dit vanaf die BApp Store of vanaf source. Dit sluit twee komponente in: -Aanvallers kan dit benut deur 'n **kwaadaardige webblad** te huisves wat 'n cross-site WebSocket verbinding met 'n kwesbare toepassing inisieer. Gevolglik word hierdie verbinding as deel van die slagoffer se sessie met die toepassing beskou, wat die gebrek aan CSRF beskerming in die sessie hanteringsmeganisme benut. +- Turbo Intruder: high‑volume messaging na 'n enkele WS endpoint met behulp van custom engines. +- HTTP Middleware: openbaar 'n plaaslike HTTP-endpoint wat bodies as WS-boodskappe oor 'n bestendige verbinding forwards, sodat enige HTTP‑based scanner WS backends kan probe. -Om hierdie aanval te laat werk, is die vereistes: +Basiese skrippatroon om 'n WS-endpoint te fuzz en relevante responses te filter: +```python +def queue_websockets(upgrade_request, message): +connection = websocket_connection.create(upgrade_request) +for i in range(10): +connection.queue(message, str(i)) -- Die websocket **outentisering moet koekie-gebaseerd wees** -- Die koekie moet vanaf die aanvaller se bediener toeganklik wees (dit beteken gewoonlik **`SameSite=None`**) en geen **Firefox Total Cookie Protection** geaktiveer in Firefox en geen **geblokkeerde derdeparty koekies** in Chrome. -- Die websocket bediener moet nie die oorsprong van die verbinding nagaan nie (of dit moet omseilbaar wees) +def handle_outgoing_message(websocket_message): +results_table.add(websocket_message) + +@MatchRegex(r'{\"user\":\"Hal Pline\"') +def handle_incoming_message(websocket_message): +results_table.add(websocket_message) +``` +Gebruik dekorateurs soos `@MatchRegex(...)` om geraas te verminder wanneer 'n enkele boodskap verskeie reaksies uitlok. + +### Brug WS agter HTTP (HTTP Middleware) + +Omsluit 'n permanente WS-verbinding en stuur HTTP-bodies as WS-boodskappe vir geoutomatiseerde toetsing met HTTP-scanners: +```python +def create_connection(upgrade_request): +connection = websocket_connection.create(upgrade_request) +return connection + +@MatchRegex(r'{\"user\":\"You\"') +def handle_incoming_message(websocket_message): +results_table.add(websocket_message) +``` +Stuur dan HTTP plaaslik; die body word as die WS-boodskap deurgestuur: +```http +POST /proxy?url=https%3A%2F%2Ftarget/ws HTTP/1.1 +Host: 127.0.0.1:9000 +Content-Length: 16 + +{"message":"hi"} +``` +Dit laat jou toe om WS-backends te bestuur terwyl jy filter vir “interessante” events (bv. SQLi errors, auth bypass, command injection behavior). + +### Socket.IO hantering (handshake, heartbeats, events) + +Socket.IO voeg sy eie framing bo-op WS. Detecteer dit via die verpligte query-parameter `EIO` (bv. `EIO=4`). Hou die sessie lewend met Ping (`2`) en Pong (`3`) en begin die gesprek met `"40"`, en stuur dan events soos `42["message","hello"]`. + +Intruder voorbeeld: +```python +import burp.api.montoya.http.message.params.HttpParameter as HttpParameter + +def queue_websockets(upgrade_request, message): +connection = websocket_connection.create( +upgrade_request.withUpdatedParameters(HttpParameter.urlParameter("EIO", "4"))) +connection.queue('40') +connection.queue('42["message","hello"]') + +@Pong("3") +def handle_outgoing_message(websocket_message): +results_table.add(websocket_message) + +@PingPong("2", "3") +def handle_incoming_message(websocket_message): +results_table.add(websocket_message) +``` +HTTP adapter-variant: +```python +import burp.api.montoya.http.message.params.HttpParameter as HttpParameter + +def create_connection(upgrade_request): +connection = websocket_connection.create( +upgrade_request.withUpdatedParameters(HttpParameter.urlParameter("EIO", "4"))) +connection.queue('40') +connection.decIn() +return connection + +@Pong("3") +def handle_outgoing_message(websocket_message): +results_table.add(websocket_message) + +@PingPong("2", "3") +def handle_incoming_message(websocket_message): +results_table.add(websocket_message) +``` +### Opsporing van bediener‑kant prototype pollution via Socket.IO + +Volg PortSwigger se veilige opsporingstegniek; probeer Express se interne dele besoedel deur 'n payload soos die volgende te stuur: +```json +{"__proto__":{"initialPacket":"Polluted"}} +``` +As groete of gedrag verander (bv., echo sluit "Polluted" in), het jy waarskynlik server-side prototypes besoedel. Impak hang af van bereikbare sinks; korreleer met die gadgets in die Node.js prototype pollution afdeling. Sien: + +- Check [NodeJS – __proto__ & prototype Pollution](deserialization/nodejs-proto-prototype-pollution/README.md) for sinks/gadgets and chaining ideas. + +### WebSocket race conditions with Turbo Intruder + +Die standaard engine groepeer boodskappe op een verbinding (groot throughput, swak vir races). Gebruik die THREADED engine om veelvuldige WS-verbindinge te skep en payloads parallel te stuur om logic races (double‑spend, token reuse, state desync) te trigger. Begin by die voorbeeldskrip en pas concurrency in `config()` aan. + +- Leer metodologie en alternatiewe in [Race Condition](race-condition.md) (see “RC in WebSockets”). + +### WebSocket DoS: malformed frame “Ping of Death” + +Skep WS-frames waarvan die header 'n reuse payload-lengte verklaar maar stuur geen body nie. Sommige WS-servers vertrou die lengte en pre‑alloceer buffers; om dit na `Integer.MAX_VALUE` te stel kan Out‑Of‑Memory veroorsaak en 'n remote unauth DoS. Sien die voorbeeldskrip. + +### CLI and debugging + +- Headless fuzzing: `java -jar WebSocketFuzzer-.jar ` +- Skakel die WS Logger aan om boodskappe te vang en te korreleer met behulp van internal IDs. +- Gebruik `inc*`/`dec*` helpers op `Connection` om message ID-hantering in komplekse adapters fyn te stel. +- Decorators soos `@PingPong`/`@Pong` en helpers soos `isInteresting()` verminder geraas en hou sessies lewendig. + +### Operational safety + +Hoë‑snelheids WS-fuzzing kan baie verbindings oopmaak en duisende boodskappe per sekonde stuur. Malformed frames en hoë snelhede kan werklike DoS veroorsaak. Gebruik slegs waar toegestaan. + +## Cross-site WebSocket hijacking (CSWSH) + +**Cross-site WebSocket hijacking**, ook bekend as **cross-origin WebSocket hijacking**, word geïdentifiseer as 'n spesifieke geval van **[Cross-Site Request Forgery (CSRF)](csrf-cross-site-request-forgery.md)** wat WebSocket-handshakes raak. Hierdie kwetsbaarheid ontstaan wanneer WebSocket-handshakes slegs via **HTTP cookies** geverifieer word sonder **CSRF tokens** of soortgelyke sekuriteitsmaatreëls. + +Aanvallers kan dit uitbuit deur 'n **kwaadaardige webblad** te host wat 'n cross-site WebSocket-verbinding na 'n kwesbare toepassing begin. Gevolglik word hierdie verbinding as deel van die slagoffer se sessie met die toepassing beskou, en word die gebrek aan CSRF-beskerming in die sessiehantering uitgebuit. + +In orde dat hierdie aanval werk, is dit die vereistes: + +- Die websocket **authentication must be cookie based** +- Die cookie moet toeganklik wees vanaf die aanvaller's bediener (dit beteken gewoonlik **`SameSite=None`**) en geen **Firefox Total Cookie Protection** in Firefox geaktiveer nie en geen **blocked third-party cookies** in Chrome nie. +- Die websocket server mag nie die origin van die verbinding nagaan nie (of dit moet omseilbaar wees) Ook: -- As die outentisering gebaseer is op 'n plaaslike verbinding (na localhost of na 'n plaaslike netwerk) sal die aanval **moontlik wees** aangesien geen huidige beskerming dit verbied nie (kyk [meer inligting hier](https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/)) +- As die authentication gebaseer is op 'n plaaslike verbinding (na localhost of na 'n plaaslike netwerk) sal die aanval **moontlik wees** aangesien geen huidige beskerming dit verbied nie (check [more info here](https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/)) -### Eenvoudige Aanval +### Simple Attack -Let daarop dat wanneer 'n **websocket** verbinding **gestig** word, die **koekie** na die bediener **gestuur** word. Die **bediener** mag dit gebruik om elke **spesifieke** **gebruiker** met sy **websocket** **sessie gebaseer op die gestuurde koekie** te **verbind**. +Let wel dat wanneer 'n **websocket**-verbinding **opgestel** word die **cookie** aan die server **gestuur** word. Die **server** mag dit gebruik om elke **spesifieke** **user** met sy **websocket** **session gebaseer op die gestuurde cookie** te koppel. -Dan, as die **websocket** **bediener** die **geskiedenis van die gesprek** van 'n gebruiker terugstuur as 'n boodskap met "**READY"** gestuur word, dan sal 'n **eenvoudige XSS** wat die verbinding tot stand bring (die **koekie** sal **automaties** gestuur word om die slagoffer gebruiker te autoriseer) wat "**READY**" stuur in staat wees om die **geskiedenis** van die **gesprek** te **herwin**. +As byvoorbeeld die **websocket** **server** die geskiedenis van die gesprek van 'n gebruiker terugstuur wanneer 'n msg met "**READY**" gestuur word, dan sal 'n **simple XSS** wat die verbinding vestig (die **cookie** sal **outomaties** gestuur word om die slagoffer te autoriseer) deur "**READY**" te **stuur**, in staat wees om die geskiedenis van die **gesprek** te **herwin**. ```html @@ -148,43 +265,51 @@ xhttp.send() return messageEvent } ``` -Laai nou die `wsHook.js` lêer af van [https://github.com/skepticfx/wshook](https://github.com/skepticfx/wshook) en **stoor dit binne die gids met die web lêers**.\ -Deur die webtoepassing bloot te stel en 'n gebruiker te laat aansluit, sal jy in staat wees om die gestuurde en ontvangde boodskappe via websocket te steel: +Laai nou die `wsHook.js` lêer af van [https://github.com/skepticfx/wshook](https://github.com/skepticfx/wshook) en **stoor dit binne die vouer met die web-lêers**.\ +Deur die webtoepassing bloot te stel en 'n gebruiker daarmee te laat koppel, kan jy die gestuurde en ontvangde boodskappe via websocket steel: ```javascript sudo python3 -m http.server 80 ``` ### CSWSH Beskerming -Die CSWSH-aanval is gebaseer op die feit dat 'n **gebruiker sal aansluit by 'n kwaadwillige bladsy** wat 'n **websocket-verbinding** sal oopmaak na 'n webblad waar die gebruiker reeds verbind is en as hom sal autentiseer, aangesien die versoek die gebruiker se koekies sal stuur. +Die CSWSH-aanval berus op die feit dat 'n **gebruiker na 'n kwaadwillige bladsy sal koppel** wat 'n **websocket connection** na 'n webblad sal open waarop die gebruiker reeds verbind is, en as die versoek die gebruiker se cookies stuur, sal dit as die gebruiker autentiseer. -Tans is dit baie maklik om hierdie probleem te voorkom: +Nou is dit baie maklik om hierdie probleem te voorkom: -- **Websocket-bediener wat die oorsprong nagaan**: Die websocket-bediener moet altyd nagaan van waar 'n gebruiker aansluit om te voorkom dat onverwagte bladsye met dit verbind. -- **Autentikasie-token**: In plaas daarvan om die autentikasie op 'n koekie te baseer, kan die websocket-verbinding gebaseer wees op 'n token wat deur die bediener vir die gebruiker gegenereer word wat onbekend is aan die aanvaller (soos 'n anti-CSRF-token). -- **SameSite Koekie-attribuut**: Koekies met `SameSite` waarde as `Lax` of `Strict` sal nie van 'n eksterne aanvallersbladsy na die slagofferbediener gestuur word nie, daarom sal koekie-gebaseerde autentikasie nie suksesvol wees nie. Let daarop dat Chrome nou die waarde **`Lax`** aan die koekies toeken wat sonder hierdie vlag gespesifiseer is, wat dit meer veilig maak per standaard. Alhoewel, die eerste 2 minute nadat 'n koekie geskep is, sal dit die waarde **`None`** hê, wat dit kwesbaar maak gedurende daardie beperkte tydperk (ook word verwag dat hierdie maatregel op 'n stadium verwyder sal word). -- **Firefox Totale Koekiebeskerming**: Totale Koekiebeskerming werk deur koekies te isoleer na die webwerf waarop hulle geskep is. Essensieel het elke webwerf sy eie koekie-opbergingsafdeling om te voorkom dat derde partye 'n gebruiker se blaai-geskiedenis saamvoeg. Dit maak **CSWSH onbruikbaar** aangesien die aanvallersbladsy nie toegang tot die koekies sal hê nie. -- **Chrome derdeparty-koekies blok**: Dit kan ook voorkom dat die koekie van die geverifieerde gebruiker na die websocket-bediener gestuur word, selfs met `SameSite=None`. +- **Websocket server checking the origin**: Die websocket-server moet altyd nagaan vanaf waar 'n gebruiker verbind om te verhoed dat onverwagte bladsye daaraan koppel. +- **Authentication token**: In plaas daarvan om die autentisering op 'n cookie te baseer, kan die websocket-verbinding op 'n token gebaseer wees wat deur die server vir die gebruiker gegenereer word en wat die aanvaller nie ken nie (soos 'n anti-CSRF token). +- **SameSite Cookie attribute**: Cookies met `SameSite`-waarde `Lax` of `Strict` sal nie vanaf 'n eksterne aanvaller se bladsy na die slagoffer-bediener gestuur word nie; daarom sal cookie-gebaseerde autentisering nie suksesvol wees nie. Let daarop dat Chrome nou die waarde **`Lax`** op cookies plaas wat sonder hierdie vlag gespesifiseer is, wat dit standaard veiliger maak. Alhoewel, die eerste 2 minute nadat 'n cookie geskep is sal dit die waarde **`None`** hê, wat dit in daardie beperkte periode kwesbaar maak (dit word ook verwag dat hierdie maatreël op 'n stadium verwyder sal word). +- **Firefox Total Cookie Protection**: Total Cookie Protection werk deur cookies te isoleer tot die site waarin hulle geskep is. Essensieel het elke site sy eie cookie-bewaarpartisie om te verhoed dat derde partye 'n gebruiker se blaai-geskiedenis kan koppel. Dit maak **CSWSH unusable** aangesien die aanvaller se site nie toegang tot die cookies sal hê nie. +- **Chrome third-party cookies block**: Dit kan ook verhoed dat die cookie van die geauthentiseerde gebruiker aan die websocket-server gestuur word selfs met `SameSite=None`. -## Wedlooptoestande +## Race Conditions -Wedlooptoestande in WebSockets is ook 'n werklikheid, [kyk hierdie inligting om meer te leer](race-condition.md#rc-in-websockets). +Race Conditions in WebSockets kom ook voor — [kry meer inligting hieroor om meer te leer](race-condition.md#rc-in-websockets). -## Ander kwesbaarhede +## Other vulnerabilities -Aangesien Web Sockets 'n meganisme is om **data na die bediener- en kliëntkant te stuur**, afhangende van hoe die bediener en kliënt die inligting hanteer, **kan Web Sockets gebruik word om verskeie ander kwesbaarhede soos XSS, SQLi of enige ander algemene web kwesbaarheid te benut deur die invoer van 'n gebruiker vanaf 'n websocket.** +Aangesien Web Sockets 'n meganisme is om data na die server- en kliëntekant te stuur, kan, afhangend van hoe die server en kliënt die inligting hanteer, **Web Sockets gebruik word om verskeie ander kwetsbaarhede soos XSS, SQLi of enige ander common web vuln te eksploiteer deur invoer van 'n gebruiker via 'n websocket.** ## **WebSocket Smuggling** -Hierdie kwesbaarheid kan jou toelaat om **terugproxies se beperkings te omseil** deur hulle te laat glo dat 'n **websocketkommunikasie gevestig is** (selfs al is dit nie waar nie). Dit kan 'n aanvaller toelaat om **verborgene eindpunte te benader**. Vir meer inligting, kyk die volgende bladsy: +Hierdie kwetsbaarheid kan toelaat dat jy **reverse proxies restrictions** omseil deur hulle te laat glo dat 'n **websocket communication was established** (selfs al is dit nie waar nie). Dit kan 'n aanvaller toelaat om **hidden endpoints** te bereik. Vir meer inligting kyk na die volgende bladsy: {{#ref}} h2c-smuggling.md {{#endref}} -## Verwysings +## References - [https://portswigger.net/web-security/websockets#intercepting-and-modifying-websocket-messages](https://portswigger.net/web-security/websockets#intercepting-and-modifying-websocket-messages) - [https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/](https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/) +- [WebSocket Turbo Intruder: Unearthing the WebSocket Goldmine](https://portswigger.net/research/websocket-turbo-intruder-unearthing-the-websocket-goldmine) +- [WebSocket Turbo Intruder – BApp Store](https://portswigger.net/bappstore/ba292c5982ea426c95c9d7325d9a1066) +- [WebSocketTurboIntruder – GitHub](https://github.com/d0ge/WebSocketTurboIntruder) +- [Turbo Intruder background](https://portswigger.net/research/turbo-intruder-embracing-the-billion-request-attack) +- [Server-side prototype pollution – safe detection methods](https://portswigger.net/research/server-side-prototype-pollution#safe-detection-methods-for-manual-testers) +- [WS RaceCondition PoC (Java)](https://github.com/redrays-io/WS_RaceCondition_PoC) +- [RaceConditionExample.py](https://github.com/d0ge/WebSocketTurboIntruder/blob/main/src/main/resources/examples/RaceConditionExample.py) +- [PingOfDeathExample.py](https://github.com/d0ge/WebSocketTurboIntruder/blob/main/src/main/resources/examples/PingOfDeathExample.py) {{#include ../banners/hacktricks-training.md}}