Translated ['src/pentesting-web/hacking-with-cookies/README.md'] to de

src/pentesting-web/hacking-with-cookies/README.md

@@ -12,13 +12,13 @@ Das Ablaufdatum eines Cookies wird durch das Attribut `Expires` bestimmt. Im Geg
 
 ### Domain
 
-Die Hosts, die ein Cookie empfangen, werden durch das Attribut `Domain` festgelegt. Standardmäßig ist dies auf den Host eingestellt, der das Cookie ausgegeben hat, ohne seine Subdomains einzuschließen. Wenn das Attribut `Domain` jedoch ausdrücklich festgelegt wird, umfasst es auch Subdomains. Dies macht die Spezifikation des Attributs `Domain` zu einer weniger restriktiven Option, die nützlich ist, wenn das Teilen von Cookies über Subdomains erforderlich ist. Zum Beispiel macht die Einstellung `Domain=mozilla.org` Cookies auf seinen Subdomains wie `developer.mozilla.org` zugänglich.
+Die Hosts, die ein Cookie empfangen sollen, werden durch das Attribut `Domain` festgelegt. Standardmäßig ist dies auf den Host eingestellt, der das Cookie ausgegeben hat, ohne seine Subdomains einzuschließen. Wenn das Attribut `Domain` jedoch ausdrücklich festgelegt wird, umfasst es auch Subdomains. Dies macht die Spezifikation des Attributs `Domain` zu einer weniger restriktiven Option, die nützlich ist, wenn das Teilen von Cookies über Subdomains erforderlich ist. Zum Beispiel macht die Einstellung `Domain=mozilla.org` Cookies auf seinen Subdomains wie `developer.mozilla.org` zugänglich.
 
 ### 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 Übereinstimmungen in Unterverzeichnissen ermöglicht.
 
-### Bestimmungsregeln
+### Reihenfolge-Regeln
 
 Wenn zwei Cookies denselben Namen tragen, wird dasjenige, das zum Senden ausgewählt wird, basierend auf:
 
@@ -59,7 +59,7 @@ Dies verhindert, dass der **Client** auf das Cookie zugreift (zum Beispiel über
 #### **Umgehungen**
 
 - Wenn die Seite **die Cookies als Antwort** auf eine Anfrage sendet (zum Beispiel auf einer **PHPinfo**-Seite), ist es möglich, XSS auszunutzen, um eine Anfrage an diese Seite zu senden und **die Cookies** aus der Antwort zu **stehlen** (siehe ein Beispiel in [https://blog.hackcommander.com/posts/2022/11/12/bypass-httponly-via-php-info-page/](https://blog.hackcommander.com/posts/2022/11/12/bypass-httponly-via-php-info-page/)).
-- 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.
+- Dies könnte mit **TRACE** **HTTP**-Anfragen umgangen werden, da die Antwort des Servers die gesendeten Cookies widerspiegelt (wenn diese HTTP-Methode verfügbar ist). 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**:
@@ -85,7 +85,7 @@ Für Cookies, die mit `__Host-` beginnen, müssen mehrere Bedingungen erfüllt s
 - 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.
+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.
 
 ### Cookies überschreiben
 
@@ -129,15 +129,15 @@ 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.
 
-JSON Web Tokens (JWT), die in Cookies verwendet werden, können ebenfalls Sicherheitsanfälligkeiten aufweisen. Für detaillierte Informationen zu potenziellen Schwächen und wie man sie ausnutzt, wird empfohlen, das verlinkte Dokument über das Hacken von JWT zu konsultieren.
+JSON Web Tokens (JWT), die in Cookies verwendet werden, können ebenfalls Sicherheitsanfälligkeiten aufweisen. Für detaillierte Informationen zu potenziellen Schwächen und deren Ausnutzung wird empfohlen, das verlinkte Dokument über das Hacken von JWT zu konsultieren.
 
 ### Cross-Site Request Forgery (CSRF)
 
-Dieser Angriff zwingt einen angemeldeten Benutzer, unerwünschte Aktionen in einer Webanwendung auszuführen, in der er derzeit authentifiziert ist. Angreifer können Cookies ausnutzen, die automatisch mit jeder Anfrage an die anfällige Seite gesendet werden.
+Dieser Angriff zwingt einen angemeldeten Benutzer, unerwünschte Aktionen in einer Webanwendung auszuführen, in der er derzeit authentifiziert ist. Angreifer können Cookies ausnutzen, die bei jeder Anfrage an die anfällige Seite automatisch gesendet werden.
 
 ### Leere Cookies
 
@@ -147,7 +147,7 @@ document.cookie = "a=v1"
 document.cookie = "=test value;" // Setting an empty named cookie
 document.cookie = "b=v2"
 ```
-Das Ergebnis im gesendeten Cookie-Header ist `a=v1; test value; b=v2;`. Interessanterweise ermöglicht dies die Manipulation von Cookies, wenn ein Cookie mit einem leeren Namen gesetzt wird, wodurch möglicherweise andere Cookies kontrolliert werden können, indem das leere Cookie auf einen bestimmten Wert gesetzt wird:
+Das Ergebnis im gesendeten Cookie-Header ist `a=v1; test value; b=v2;`. Interessanterweise ermöglicht dies die Manipulation von Cookies, wenn ein Cookie mit leerem Namen gesetzt wird, wodurch möglicherweise andere Cookies kontrolliert werden können, indem das leere Cookie auf einen bestimmten Wert gesetzt wird:
 ```js
 function setCookie(name, value) {
 document.cookie = `${name}=${value}`
@@ -175,11 +175,11 @@ RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";
 
 (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 unmittelbar nach einem in Anführungszeichen gesetzten Wert ohne Semikolon.
+- Undertow erwartet ein neues Cookie sofort nach einem in Anführungszeichen gesetzten 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 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.
+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
 
@@ -219,11 +219,11 @@ Diese Analyse zeigt an, dass escaped Werte innerhalb der Cookies unescaped werde
 
 #### Umgehung von Cookie-Namen-Blocklisten
 
-Im 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 admin das Leerzeichen vor und nach dem Gleichheitszeichen 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 generiert werden und wie der Raum vor und nach dem Gleichheitszeichen für admin entfernt wurde.
 
 #### Umgehung der Wertanalyse mit Cookie-Splitting
 
-Schließlich würden verschiedene Backdoors in einem String verschiedene Cookies zusammenführen, die in unterschiedlichen Cookie-Headern übergeben werden, wie in:
+Schließlich würden verschiedene Backdoors in einem String verschiedene Cookies zusammenführen, die in verschiedenen Cookie-Headern übergeben werden, wie in:
 ```
 GET / HTTP/1.1
 Host: example.com
@@ -237,24 +237,24 @@ Cookie: comment')
 
 Resulting cookie: name=eval('test//, comment') => allowed
 ```
-### Zusätzliche Überprüfungen von anfälligen Cookies
+### Zusätzliche Überprüfungen auf verwundbare Cookies
 
 #### **Grundlegende Überprüfungen**
 
-- Das **cookie** ist jedes Mal, wenn Sie sich **anmelden**, **gleich**.
+- Das **cookie** ist jedes Mal, wenn Sie sich **einloggen**, **gleich**.
 - Melden Sie sich ab und versuchen Sie, dasselbe Cookie zu verwenden.
-- Versuchen Sie, sich mit 2 Geräten (oder Browsern) bei demselben Konto mit demselben Cookie anzumelden.
+- 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.
 - Versuchen Sie, mehrere Konten mit fast demselben Benutzernamen zu erstellen, und überprüfen Sie, ob Sie Ähnlichkeiten sehen können.
-- Überprüfen Sie die Option "**remember me**", falls vorhanden, um zu sehen, wie sie funktioniert. Wenn sie vorhanden ist und anfällig sein könnte, verwenden Sie immer das Cookie von **remember me** ohne ein anderes Cookie.
+- Überprüfen Sie die Option "**remember me**", falls vorhanden, um zu sehen, wie sie funktioniert. Wenn sie vorhanden ist und verwundbar sein könnte, verwenden Sie immer das Cookie von **remember me** ohne ein anderes Cookie.
 - Überprüfen Sie, ob das vorherige Cookie funktioniert, selbst nachdem Sie das Passwort geändert haben.
 
 #### **Erweiterte Cookie-Angriffe**
 
-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:
+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:
 
 - 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, 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**.
 
 **Padding Oracle - Padbuster Beispiele**