Translated ['src/pentesting-web/domain-subdomain-takeover.md', 'src/pent

2025-10-10 18:36:50 +00:00 · 2025-02-04 18:48:32 +00:00 · 2025-02-04 18:48:32 +00:00 · 0834a3a8bf
commit 0834a3a8bf
parent 68e907363e
2 changed files with 76 additions and 34 deletions
--- a/src/pentesting-web/domain-subdomain-takeover.md
+++ b/src/pentesting-web/domain-subdomain-takeover.md
@ -5,11 +5,11 @@

 ## Domain takeover

-Wenn Sie eine Domain (domain.tld) entdecken, die **von einem Dienst innerhalb des Umfangs verwendet wird**, aber das **Unternehmen** hat die **Eigentümerschaft** daran **verloren**, können Sie versuchen, sie **zu registrieren** (wenn sie günstig genug ist) und das Unternehmen darüber informieren. Wenn diese Domain einige **sensible Informationen** wie ein Sitzungscookie über einen **GET**-Parameter oder im **Referer**-Header erhält, ist dies mit Sicherheit eine **Schwachstelle**.
+Wenn Sie eine Domain (domain.tld) entdecken, die **von einem Dienst innerhalb des Geltungsbereichs verwendet wird**, aber das **Unternehmen** die **Eigentümerschaft** verloren hat, können Sie versuchen, sie **zu registrieren** (wenn sie günstig genug ist) und das Unternehmen darüber informieren. Wenn diese Domain einige **sensible Informationen** wie ein Sitzungscookie über einen **GET**-Parameter oder im **Referer**-Header erhält, ist dies mit Sicherheit eine **Schwachstelle**.

 ### Subdomain takeover

-Eine Subdomain des Unternehmens zeigt auf einen **nicht registrierten Drittanbieterdienst**. Wenn Sie ein **Konto** in diesem **Drittanbieterdienst** **erstellen** und den **Namen**, der verwendet wird, **registrieren** können, können Sie den Subdomain Takeover durchführen.
+Eine Subdomain des Unternehmens verweist auf einen **nicht registrierten Drittanbieterdienst**. Wenn Sie ein **Konto** in diesem **Drittanbieterdienst** **erstellen** und den **Namen**, der verwendet wird, **registrieren** können, können Sie den Subdomain-Takeover durchführen.

 Es gibt mehrere Tools mit Wörterbüchern, um mögliche Übernahmen zu überprüfen:

@ -29,17 +29,17 @@ Es gibt mehrere Tools mit Wörterbüchern, um mögliche Übernahmen zu überprü

 ### Subdomain Takeover Generation via DNS Wildcard

-Wenn ein DNS-Wildcard in einer Domain verwendet wird, wird jede angeforderte Subdomain dieser Domain, die keine andere Adresse explizit hat, **auf die gleichen Informationen aufgelöst**. Dies könnte eine A-IP-Adresse, ein CNAME...
+Wenn ein DNS-Wildcard in einer Domain verwendet wird, wird jede angeforderte Subdomain dieser Domain, die keine andere Adresse hat, explizit **auf die gleichen Informationen aufgelöst**. Dies könnte eine A-IP-Adresse, ein CNAME...

-Zum Beispiel, wenn `*.testing.com` auf `1.1.1.1` wildcarded ist. Dann wird `not-existent.testing.com` auf `1.1.1.1` zeigen.
+Wenn zum Beispiel `*.testing.com` auf `1.1.1.1` wildcarded ist. Dann wird `not-existent.testing.com` auf `1.1.1.1` zeigen.

-Wenn der Sysadmin jedoch anstelle einer IP-Adresse auf einen **Drittanbieterdienst über CNAME** zeigt, wie zum Beispiel eine G**ithub-Subdomain** (`sohomdatta1.github.io`). Ein Angreifer könnte **seine eigene Drittanbieter-Seite** (in diesem Fall auf GitHub) erstellen und sagen, dass `something.testing.com` dort hinzeigt. Da das **CNAME-Wildcard** zustimmt, wird der Angreifer in der Lage sein, **willkürliche Subdomains für die Domain des Opfers zu generieren, die auf seine Seiten zeigen**.
+Wenn der Sysadmin jedoch anstelle der Verweisung auf eine IP-Adresse auf einen **Drittanbieterdienst über CNAME** verweist, wie zum Beispiel eine G**ithub-Subdomain** (`sohomdatta1.github.io`). Ein Angreifer könnte **seine eigene Drittanbieter-Seite** (in diesem Fall auf GitHub) erstellen und sagen, dass `something.testing.com` dorthin verweist. Denn das **CNAME-Wildcard** wird zustimmen, dass der Angreifer in der Lage sein wird, **willkürliche Subdomains für die Domain des Opfers zu generieren, die auf seine Seiten verweisen**.

 Ein Beispiel für diese Schwachstelle finden Sie im CTF-Bericht: [https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api](https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api)

 ## Exploiting a subdomain takeover

-Der Subdomain Takeover ist im Wesentlichen DNS-Spoofing für eine bestimmte Domain im Internet, das es Angreifern ermöglicht, A-Records für eine Domain festzulegen, wodurch Browser Inhalte vom Server des Angreifers anzeigen. Diese **Transparenz** in Browsern macht Domains anfällig für Phishing. Angreifer können [_Typosquatting_](https://en.wikipedia.org/wiki/Typosquatting) oder [_Doppelgänger-Domains_](https://en.wikipedia.org/wiki/Doppelg%C3%A4nger) zu diesem Zweck verwenden. Besonders anfällig sind Domains, bei denen die URL in einer Phishing-E-Mail legitim erscheint, Benutzer täuscht und Spam-Filter aufgrund des inhärenten Vertrauens der Domain umgeht.
+Der Subdomain-Takeover ist im Wesentlichen DNS-Spoofing für eine bestimmte Domain im Internet, das es Angreifern ermöglicht, A-Records für eine Domain festzulegen, wodurch Browser Inhalte vom Server des Angreifers anzeigen. Diese **Transparenz** in Browsern macht Domains anfällig für Phishing. Angreifer können [_Typosquatting_](https://en.wikipedia.org/wiki/Typosquatting) oder [_Doppelgänger-Domains_](https://en.wikipedia.org/wiki/Doppelg%C3%A4nger) zu diesem Zweck verwenden. Besonders anfällig sind Domains, bei denen die URL in einer Phishing-E-Mail legitim erscheint, Benutzer täuscht und Spam-Filter aufgrund des inhärenten Vertrauens der Domain umgeht.

 Überprüfen Sie diesen [Beitrag für weitere Details](https://0xpatrik.com/subdomain-takeover/)

@ -49,11 +49,27 @@ SSL-Zertifikate, die von Angreifern über Dienste wie [_Let's Encrypt_](https://

 ### **Cookie Security and Browser Transparency**

-Die Transparenz von Browsern erstreckt sich auch auf die Sicherheit von Cookies, die durch Richtlinien wie die [Same-origin policy](https://en.wikipedia.org/wiki/Same-origin_policy) geregelt wird. Cookies, die häufig zur Verwaltung von Sitzungen und zur Speicherung von Anmeldetoken verwendet werden, können durch Subdomain Takeover ausgenutzt werden. Angreifer können **Sitzungscookies sammeln**, indem sie Benutzer einfach zu einer kompromittierten Subdomain leiten, was die Benutzerdaten und die Privatsphäre gefährdet.
+Die Transparenz von Browsern erstreckt sich auch auf die Sicherheit von Cookies, die durch Richtlinien wie die [Same-origin policy](https://en.wikipedia.org/wiki/Same-origin_policy) geregelt wird. Cookies, die häufig zur Verwaltung von Sitzungen und zur Speicherung von Anmeldetoken verwendet werden, können durch Subdomain-Takeover ausgenutzt werden. Angreifer können **Sitzungscookies sammeln**, indem sie Benutzer einfach auf eine kompromittierte Subdomain leiten, was die Benutzerdaten und die Privatsphäre gefährdet.
+
+### CORS Bypass
+
+Es könnte möglich sein, dass jede Subdomain auf CORS-Ressourcen von der Hauptdomain oder anderen Subdomains zugreifen darf. Dies könnte von einem Angreifer ausgenutzt werden, um **sensible Informationen** durch Missbrauch von CORS-Anfragen zu **erlangen**.
+
+### CSRF - Same-Site Cookies bypass
+
+Es könnte möglich sein, dass die Subdomain Cookies an die Domain oder andere Subdomains senden darf, was durch das `Same-Site`-Attribut der Cookies verhindert wurde. Beachten Sie jedoch, dass Anti-CSRF-Token diesen Angriff weiterhin verhindern, wenn sie ordnungsgemäß implementiert sind.
+
+### OAuth tokens redirect
+
+Es könnte möglich sein, dass die kompromittierte Subdomain in der `redirect_uri`-URL eines OAuth-Flows verwendet werden darf. Dies könnte von einem Angreifer ausgenutzt werden, um das **OAuth-Token zu stehlen**.
+
+### CSP Bypass
+
+Es könnte möglich sein, dass die kompromittierte Subdomain (oder jede Subdomain) beispielsweise für die `script-src` der CSP verwendet werden darf. Dies könnte von einem Angreifer ausgenutzt werden, um **schadhafte Skripte einzuschleusen** und potenzielle XSS-Schwachstellen auszunutzen.

 ### **Emails and Subdomain Takeover**

-Ein weiterer Aspekt des Subdomain Takeover betrifft E-Mail-Dienste. Angreifer können **MX-Records** manipulieren, um E-Mails von einer legitimen Subdomain zu empfangen oder zu senden, was die Effektivität von Phishing-Angriffen erhöht.
+Ein weiterer Aspekt des Subdomain-Takeovers betrifft E-Mail-Dienste. Angreifer können **MX-Records** manipulieren, um E-Mails von einer legitimen Subdomain zu empfangen oder zu senden, was die Wirksamkeit von Phishing-Angriffen erhöht.

 ### **Higher Order Risks**

@ -61,7 +77,7 @@ Weitere Risiken umfassen **NS-Record-Übernahmen**. Wenn ein Angreifer die Kontr

 ### CNAME Record Vulnerability

-Angreifer könnten unbeanspruchte CNAME-Records ausnutzen, die auf externe Dienste zeigen, die nicht mehr verwendet werden oder stillgelegt wurden. Dies ermöglicht es ihnen, eine Seite unter der vertrauenswürdigen Domain zu erstellen, was Phishing oder die Verbreitung von Malware weiter erleichtert.
+Angreifer könnten unbeanspruchte CNAME-Records ausnutzen, die auf externe Dienste verweisen, die nicht mehr verwendet werden oder stillgelegt wurden. Dies ermöglicht es ihnen, eine Seite unter der vertrauenswürdigen Domain zu erstellen, was Phishing oder die Verbreitung von Malware weiter erleichtert.

 ### **Mitigation Strategies**

@ -71,11 +87,12 @@ Minderungsstrategien umfassen:
 2. **Beanspruchen des Domainnamens** - Registrieren der Ressource beim jeweiligen Cloud-Anbieter oder Wiedererwerb einer abgelaufenen Domain.
 3. **Regelmäßige Überwachung auf Schwachstellen** - Tools wie [aquatone](https://github.com/michenriksen/aquatone) können helfen, anfällige Domains zu identifizieren. Organisationen sollten auch ihre Infrastrukturmanagementprozesse überarbeiten, um sicherzustellen, dass die Erstellung von DNS-Records der letzte Schritt bei der Ressourcenerstellung und der erste Schritt bei der Ressourcenzerstörung ist.

-Für Cloud-Anbieter ist die Überprüfung des Domainbesitzes entscheidend, um Subdomain-Übernahmen zu verhindern. Einige, wie [GitLab](https://about.gitlab.com/2018/02/05/gitlab-pages-custom-domain-validation/), haben dieses Problem erkannt und Mechanismen zur Domainverifizierung implementiert.
+Für Cloud-Anbieter ist die Überprüfung des Domainbesitzes entscheidend, um Subdomain-Takeovers zu verhindern. Einige, wie [GitLab](https://about.gitlab.com/2018/02/05/gitlab-pages-custom-domain-validation/), haben dieses Problem erkannt und Mechanismen zur Domainverifizierung implementiert.

 ## References

 - [https://0xpatrik.com/subdomain-takeover/](https://0xpatrik.com/subdomain-takeover/)
 - [https://www.stratussecurity.com/post/subdomain-takeover-guide](https://www.stratussecurity.com/post/subdomain-takeover-guide)
+- [https://www.hackerone.com/blog/guide-subdomain-takeovers-20](https://www.hackerone.com/blog/guide-subdomain-takeovers-20)

 {{#include ../banners/hacktricks-training.md}}
--- a/src/pentesting-web/hacking-with-cookies/README.md
+++ b/src/pentesting-web/hacking-with-cookies/README.md
@ -16,9 +16,9 @@ Die Hosts, die ein Cookie empfangen, werden durch das Attribut `Domain` festgele

 ### Path

-Ein spezifischer URL-Pfad, der in der angeforderten URL vorhanden sein muss, damit der `Cookie`-Header gesendet wird, wird durch das Attribut `Path` angezeigt. Dieses Attribut betrachtet das Zeichen `/` als Verzeichnistrenner, was auch Übereinstimmungen in Unterverzeichnissen ermöglicht.
+Ein spezifischer URL-Pfad, der in der angeforderten URL vorhanden sein muss, damit der `Cookie`-Header gesendet wird, wird durch das Attribut `Path` angezeigt. Dieses Attribut betrachtet das Zeichen `/` als Verzeichnistrenner, was Übereinstimmungen in Unterverzeichnissen ermöglicht.

-### Ordering Rules
+### Reihenfolge-Regeln

 Wenn zwei Cookies denselben Namen tragen, wird dasjenige, das zum Senden ausgewählt wird, basierend auf:

@ -62,7 +62,7 @@ Dies verhindert, dass der **Client** auf das Cookie zugreift (zum Beispiel über
 - Dies könnte mit **TRACE** **HTTP**-Anfragen umgangen werden, da die Antwort des Servers (wenn diese HTTP-Methode verfügbar ist) die gesendeten Cookies widerspiegelt. Diese Technik wird als **Cross-Site Tracking** bezeichnet.
 - Diese Technik wird von **modernen Browsern vermieden, indem das Senden einer TRACE**-Anfrage von JS nicht erlaubt wird. Einige Umgehungen dafür wurden jedoch in spezifischer Software gefunden, wie das Senden von `\r\nTRACE` anstelle von `TRACE` an IE6.0 SP2.
 - Eine andere Möglichkeit ist die Ausnutzung von Zero-Day-Sicherheitsanfälligkeiten der Browser.
- Es ist möglich, **HttpOnly-Cookies** durch einen Cookie-Jar-Overflow-Angriff zu **überschreiben**:
+- Es ist möglich, **HttpOnly-Cookies zu überschreiben**, indem man einen Cookie-Jar-Overflow-Angriff durchführt:

 {{#ref}}
 cookie-jar-overflow.md
@ -82,14 +82,14 @@ Für Cookies, die mit `__Host-` beginnen, müssen mehrere Bedingungen erfüllt s

 - Sie müssen mit dem `secure`-Flag gesetzt werden.
 - Sie müssen von einer durch HTTPS gesicherten Seite stammen.
- Es ist ihnen untersagt, eine Domain anzugeben, was ihre Übertragung an Subdomains verhindert.
+- Es ist verboten, eine Domain anzugeben, was ihre Übertragung an Subdomains verhindert.
 - Der Pfad für diese Cookies muss auf `/` gesetzt werden.

 Es ist wichtig zu beachten, dass Cookies, die mit `__Host-` beginnen, nicht an Superdomains oder Subdomains gesendet werden dürfen. Diese Einschränkung hilft, Anwendungscookies zu isolieren. Daher kann die Verwendung des `__Host-`-Präfixes für alle Anwendungscookies als gute Praxis zur Verbesserung der Sicherheit und Isolation angesehen werden.

 ### Überschreiben von Cookies

-Eine der Schutzmaßnahmen von Cookies mit dem Präfix `__Host-` besteht darin, zu verhindern, dass sie von Subdomains überschrieben werden. Dies verhindert beispielsweise [**Cookie Tossing-Angriffe**](cookie-tossing.md). In dem Vortrag [**Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities**](https://www.youtube.com/watch?v=F_wAzF4a7Xg) ([**Paper**](https://www.usenix.org/system/files/usenixsecurity23-squarcina.pdf)) wird präsentiert, dass es möglich war, \_\_HOST- präfixierte Cookies von einer Subdomain zu setzen, indem man den Parser täuschte, zum Beispiel, indem man "=" am Anfang oder am Ende hinzufügte...:
+Eine der Schutzmaßnahmen von Cookies mit dem Präfix `__Host-` besteht darin, zu verhindern, dass sie von Subdomains überschrieben werden. Dies verhindert beispielsweise [**Cookie Tossing-Angriffe**](cookie-tossing.md). In dem Vortrag [**Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities**](https://www.youtube.com/watch?v=F_wAzF4a7Xg) ([**Paper**](https://www.usenix.org/system/files/usenixsecurity23-squarcina.pdf)) wird präsentiert, dass es möglich war, \_\_HOST- Cookies von einer Subdomain zu setzen, indem man den Parser täuschte, zum Beispiel, indem man "=" am Anfang oder am Ende hinzufügte...:

 <figure><img src="../../images/image (6) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>

@ -103,15 +103,15 @@ Wenn ein benutzerdefiniertes Cookie sensible Daten enthält, überprüfen Sie es

 ### Dekodierung und Manipulation von Cookies

-Sensible Daten, die in Cookies eingebettet sind, sollten immer überprüft werden. Cookies, die in Base64 oder ähnlichen Formaten kodiert sind, können oft dekodiert werden. Diese Sicherheitsanfälligkeit ermöglicht es Angreifern, den Inhalt des Cookies zu ändern und sich als andere Benutzer auszugeben, indem sie ihre modifizierten Daten wieder in das Cookie kodieren.
+Sensible Daten, die in Cookies eingebettet sind, sollten immer überprüft werden. Cookies, die in Base64 oder ähnlichen Formaten codiert sind, können oft dekodiert werden. Diese Sicherheitsanfälligkeit ermöglicht es Angreifern, den Inhalt des Cookies zu ändern und sich als andere Benutzer auszugeben, indem sie ihre modifizierten Daten wieder in das Cookie codieren.

-### Session Hijacking
+### Sitzungsübernahme

 Dieser Angriff besteht darin, das Cookie eines Benutzers zu stehlen, um unbefugten Zugriff auf dessen Konto innerhalb einer Anwendung zu erlangen. Durch die Verwendung des gestohlenen Cookies kann ein Angreifer den legitimen Benutzer imitieren.

-### Session Fixation
+### Sitzungsfixierung

-In diesem Szenario bringt ein Angreifer ein Opfer dazu, ein bestimmtes Cookie zum Anmelden zu verwenden. Wenn die Anwendung beim Anmelden kein neues Cookie zuweist, kann der Angreifer, der das ursprüngliche Cookie besitzt, das Opfer imitieren. Diese Technik beruht darauf, dass das Opfer sich mit einem vom Angreifer bereitgestellten Cookie anmeldet.
+In diesem Szenario bringt ein Angreifer ein Opfer dazu, ein bestimmtes Cookie zum Anmelden zu verwenden. Wenn die Anwendung beim Anmelden kein neues Cookie zuweist, kann der Angreifer, der das ursprüngliche Cookie besitzt, das Opfer imitieren. Diese Technik beruht darauf, dass das Opfer sich mit einem Cookie anmeldet, das vom Angreifer bereitgestellt wurde.

 Wenn Sie ein **XSS in einer Subdomain** gefunden haben oder **eine Subdomain kontrollieren**, lesen Sie:

@ -119,9 +119,9 @@ Wenn Sie ein **XSS in einer Subdomain** gefunden haben oder **eine Subdomain kon
 cookie-tossing.md
 {{#endref}}

-### Session Donation
+### Sitzungsdonation

-Hier überzeugt der Angreifer das Opfer, das Session-Cookie des Angreifers zu verwenden. Das Opfer, das glaubt, in seinem eigenen Konto angemeldet zu sein, wird unbeabsichtigt Aktionen im Kontext des Kontos des Angreifers ausführen.
+Hier überzeugt der Angreifer das Opfer, das Sitzungscookie des Angreifers zu verwenden. Das Opfer, das glaubt, in seinem eigenen Konto angemeldet zu sein, wird unbeabsichtigt Aktionen im Kontext des Kontos des Angreifers ausführen.

 Wenn Sie ein **XSS in einer Subdomain** gefunden haben oder **eine Subdomain kontrollieren**, lesen Sie:

@ -129,7 +129,7 @@ Wenn Sie ein **XSS in einer Subdomain** gefunden haben oder **eine Subdomain kon
 cookie-tossing.md
 {{#endref}}

-### [JWT Cookies](../hacking-jwt-json-web-tokens.md)
+### [JWT-Cookies](../hacking-jwt-json-web-tokens.md)

 Klicken Sie auf den vorherigen Link, um auf eine Seite zuzugreifen, die mögliche Schwächen in JWT erklärt.

@ -167,36 +167,61 @@ Dies führt dazu, dass `document.cookie` einen leeren String ausgibt, was auf ei

 #### Cookie Smuggling aufgrund von Parsing-Problemen

-(Weitere Details finden Sie in der[originalen Forschung](https://blog.ankursundara.com/cookie-bugs/)) Mehrere Webserver, einschließlich der von Java (Jetty, TomCat, Undertow) und Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), gehen mit Cookie-Strings aufgrund veralteter RFC2965-Unterstützung falsch um. Sie lesen einen doppelt zitierten Cookie-Wert als einen einzigen Wert, selbst wenn er Semikolons enthält, die normalerweise Schlüssel-Wert-Paare trennen sollten:
+(Weitere Details finden Sie in der[originalen Forschung](https://blog.ankursundara.com/cookie-bugs/)) Mehrere Webserver, einschließlich der von Java (Jetty, TomCat, Undertow) und Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), behandeln Cookie-Strings aufgrund veralteter RFC2965-Unterstützung falsch. Sie lesen einen doppelt zitierten Cookie-Wert als einen einzelnen Wert, selbst wenn er Semikolons enthält, die normalerweise Schlüssel-Wert-Paare trennen sollten:
 ```
 RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";
 ```
 #### Cookie Injection Vulnerabilities

-(Check further details in the[original research](https://blog.ankursundara.com/cookie-bugs/)) Die falsche Analyse von Cookies durch Server, insbesondere Undertow, Zope und solche, die Python's `http.cookie.SimpleCookie` und `http.cookie.BaseCookie` verwenden, schafft Möglichkeiten für Cookie-Injektionsangriffe. Diese Server versäumen es, den Beginn neuer Cookies ordnungsgemäß zu begrenzen, was Angreifern ermöglicht, Cookies zu fälschen:
+(Check further details in the[original research](https://blog.ankursundara.com/cookie-bugs/)) Die falsche Analyse von Cookies durch Server, insbesondere Undertow, Zope und solche, die Python's `http.cookie.SimpleCookie` und `http.cookie.BaseCookie` verwenden, schafft Möglichkeiten für Cookie-Injektionsangriffe. Diese Server versäumen es, den Beginn neuer Cookies ordnungsgemäß zu kennzeichnen, was es Angreifern ermöglicht, Cookies zu fälschen:

 - Undertow erwartet ein neues Cookie sofort nach einem zitierten Wert ohne Semikolon.
 - Zope sucht nach einem Komma, um mit der Analyse des nächsten Cookies zu beginnen.
 - Pythons Cookie-Klassen beginnen die Analyse bei einem Leerzeichen.

-Diese Schwachstelle ist besonders gefährlich in Webanwendungen, die auf cookie-basiertem CSRF-Schutz basieren, da sie Angreifern ermöglicht, gefälschte CSRF-Token-Cookies einzuschleusen, was potenziell Sicherheitsmaßnahmen umgeht. Das Problem wird durch Pythons Umgang mit doppelten Cookienamen verschärft, bei dem das letzte Vorkommen frühere überschreibt. Es wirft auch Bedenken hinsichtlich `__Secure-` und `__Host-` Cookies in unsicheren Kontexten auf und könnte zu Autorisierungsumgehungen führen, wenn Cookies an Backend-Server weitergegeben werden, die anfällig für Spoofing sind.
+Diese Schwachstelle ist besonders gefährlich in Webanwendungen, die auf cookie-basiertem CSRF-Schutz basieren, da sie es Angreifern ermöglicht, gefälschte CSRF-Token-Cookies einzuschleusen, was potenziell Sicherheitsmaßnahmen umgeht. Das Problem wird durch Pythons Umgang mit doppelten Cookie-Namen verschärft, bei dem das letzte Vorkommen frühere überschreibt. Es wirft auch Bedenken hinsichtlich `__Secure-` und `__Host-` Cookies in unsicheren Kontexten auf und könnte zu Autorisierungsumgehungen führen, wenn Cookies an Backend-Server weitergegeben werden, die anfällig für Spoofing sind.

-### Cookies $version and WAF bypasses
+### Cookies $version
+
+#### WAF Bypass

 Laut [**diesem Blogbeitrag**](https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie) könnte es möglich sein, das Cookie-Attribut **`$Version=1`** zu verwenden, um das Backend dazu zu bringen, eine alte Logik zur Analyse des Cookies aufgrund der **RFC2109** zu verwenden. Darüber hinaus können andere Werte wie **`$Domain`** und **`$Path`** verwendet werden, um das Verhalten des Backends mit dem Cookie zu ändern.

-#### Bypassing value analysis with quoted-string encoding
+#### Cookie Sandwich Attack

-Diese Analyse deutet darauf hin, dass escaped Werte innerhalb der Cookies unescaped werden, sodass "\a" zu "a" wird. Dies kann nützlich sein, um WAFS zu umgehen, da:
+Laut [**diesem Blogbeitrag**](https://portswigger.net/research/stealing-httponly-cookies-with-the-cookie-sandwich-technique) ist es möglich, die Cookie-Sandwich-Technik zu verwenden, um HttpOnly-Cookies zu stehlen. Dies sind die Anforderungen und Schritte:
+
+- Finde einen Ort, an dem ein scheinbar nutzloses **Cookie in der Antwort reflektiert wird**
+- **Erstelle ein Cookie mit dem Namen `$Version`** mit dem Wert `1` (du kannst dies in einem XSS-Angriff von JS aus tun) mit einem spezifischeren Pfad, damit es die ursprüngliche Position erhält (einige Frameworks wie Python benötigen diesen Schritt nicht)
+- **Erstelle das Cookie, das reflektiert wird** mit einem Wert, der ein **offenes doppeltes Anführungszeichen** hinterlässt und mit einem spezifischen Pfad, damit es in der Cookie-Datenbank nach dem vorherigen (`$Version`) positioniert wird
+- Dann wird das legitime Cookie in der Reihenfolge als nächstes kommen
+- **Erstelle ein Dummy-Cookie, das das doppelte Anführungszeichen** innerhalb seines Wertes schließt
+
+Auf diese Weise wird das Opfer-Cookie innerhalb der neuen Cookie-Version 1 gefangen und wird immer dann reflektiert, wenn es reflektiert wird.
+```javascript
+document.cookie = `$Version=1;`;
+document.cookie = `param1="start`;
+// any cookies inside the sandwich will be placed into param1 value server-side
+document.cookie = `param2=end";`;
+```
+### WAF-Bypässe
+
+#### Cookies $version
+
+Überprüfen Sie den vorherigen Abschnitt.
+
+#### Umgehung der Wertanalyse mit quoted-string-Encoding
+
+Diese Analyse zeigt an, dass escaped Werte innerhalb der Cookies unescaped werden, sodass "\a" zu "a" wird. Dies kann nützlich sein, um WAFS zu umgehen, da:

 - `eval('test') => forbidden`
 - `"\e\v\a\l\(\'\t\e\s\t\'\)" => allowed`

-#### Bypassing cookie-name blocklists
+#### Umgehung von Cookie-Namen-Blocklisten

-In der RFC2109 wird angegeben, dass ein **Komma als Trennzeichen zwischen Cookie-Werten verwendet werden kann**. Außerdem ist es möglich, **Leerzeichen und Tabs vor und nach dem Gleichheitszeichen hinzuzufügen**. Daher erzeugt ein Cookie wie `$Version=1; foo=bar, abc = qux` nicht das Cookie `"foo":"bar, admin = qux"`, sondern die Cookies `foo":"bar"` und `"admin":"qux"`. Beachten Sie, wie 2 Cookies generiert werden und wie der Raum vor und nach dem Gleichheitszeichen für admin entfernt wurde.
+In der RFC2109 wird angegeben, dass ein **Komma als Trennzeichen zwischen Cookie-Werten verwendet werden kann**. Außerdem ist es möglich, **Leerzeichen und Tabs vor und nach dem Gleichheitszeichen hinzuzufügen**. Daher erzeugt ein Cookie wie `$Version=1; foo=bar, abc = qux` nicht das Cookie `"foo":"bar, admin = qux"`, sondern die Cookies `foo":"bar"` und `"admin":"qux"`. Beachten Sie, wie 2 Cookies erzeugt werden und wie der Raum vor und nach dem Gleichheitszeichen bei admin entfernt wurde.

-#### Bypassing value analysis with cookie splitting
+#### Umgehung der Wertanalyse mit Cookie-Splitting

 Schließlich würden verschiedene Backdoors in einem String verschiedene Cookies zusammenführen, die in verschiedenen Cookie-Headern übergeben werden, wie in:
 ```
@ -216,7 +241,7 @@ Resulting cookie: name=eval('test//, comment') => allowed

 #### **Grundlegende Überprüfungen**

- Das **Cookie** ist jedes Mal, wenn Sie sich **einloggen**, **gleich**.
+- Das **Cookie** ist jedes Mal, wenn Sie sich **anmelden**, **gleich**.
 - Melden Sie sich ab und versuchen Sie, dasselbe Cookie zu verwenden.
 - Versuchen Sie, sich mit 2 Geräten (oder Browsern) mit demselben Cookie in dasselbe Konto einzuloggen.
 - Überprüfen Sie, ob das Cookie Informationen enthält, und versuchen Sie, es zu ändern.
@ -226,9 +251,9 @@ Resulting cookie: name=eval('test//, comment') => allowed

 #### **Erweiterte Cookie-Angriffe**

-Wenn das Cookie beim Einloggen gleich bleibt (oder fast gleich bleibt), bedeutet dies wahrscheinlich, dass das Cookie mit einem Feld Ihres Kontos (wahrscheinlich dem Benutzernamen) verbunden ist. Dann können Sie:
+Wenn das Cookie beim Anmelden gleich bleibt (oder fast gleich bleibt), bedeutet dies wahrscheinlich, dass das Cookie mit einem Feld Ihres Kontos (wahrscheinlich dem Benutzernamen) verbunden ist. Dann können Sie:

- Versuchen, viele **Konten** mit sehr **ähnlichen** Benutzernamen zu erstellen und versuchen, zu **erraten**, wie der Algorithmus funktioniert.
+- Versuchen, viele **Konten** mit sehr **ähnlichen** Benutzernamen zu erstellen und versuchen, **zu erraten**, wie der Algorithmus funktioniert.
 - Versuchen, den **Benutzernamen zu bruteforcen**. Wenn das Cookie nur als Authentifizierungsmethode für Ihren Benutzernamen gespeichert wird, können Sie ein Konto mit dem Benutzernamen "**Bmin**" erstellen und jeden einzelnen **Bit** Ihres Cookies **bruteforcen**, da eines der Cookies, die Sie versuchen werden, das von "**admin**" sein wird.
 - Versuchen Sie **Padding** **Oracle** (Sie können den Inhalt des Cookies entschlüsseln). Verwenden Sie **padbuster**.