Translated ['src/binary-exploitation/rop-return-oriented-programing/srop

src/binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md

@@ -191,7 +191,7 @@ rp++ -f ./binary --unique -r | grep "mov\s\+x8, #0x8b"   # 0x8b = __NR_rt_sigret
 ```
 Beide Werkzeuge verstehen **AArch64** Kodierungen und listen Kandidaten `mov x8, 0x8b ; svc #0` Sequenzen auf, die als *SROP Gadget* verwendet werden können.
 
-> Hinweis: Wenn Binärdateien mit **BTI** kompiliert werden, ist die erste Anweisung jedes gültigen indirekten Sprungziels `bti c`. `sigreturn` Trampolines, die vom Linker platziert werden, enthalten bereits das richtige BTI-Landingpad, sodass das Gadget aus unprivilegiertem Code weiterhin verwendbar bleibt.
+> Hinweis: Wenn Binärdateien mit **BTI** kompiliert werden, ist die erste Anweisung jedes gültigen indirekten Sprungziels `bti c`. `sigreturn` Trampolines, die vom Linker platziert werden, enthalten bereits das richtige BTI-Landing-Pad, sodass das Gadget aus nicht privilegiertem Code weiterhin verwendbar bleibt.
 
 ## Verknüpfung von SROP mit ROP (Pivot über `mprotect`)
 
@@ -205,11 +205,11 @@ frame.x2 = 7                       # PROT_READ|PROT_WRITE|PROT_EXEC
 frame.sp = 0x400000 + 0x100        # new pivot
 frame.pc = svc_call                # will re-enter kernel
 ```
-Nach dem Senden des Frames können Sie eine zweite Phase mit rohem Shell-Code bei `0x400000+0x100` senden. Da **AArch64** *PC-relative* Adressierung verwendet, ist dies oft bequemer als das Erstellen großer ROP-Ketten.
+Nach dem Senden des Frames können Sie eine zweite Stufe mit rohem Shell-Code bei `0x400000+0x100` senden. Da **AArch64** *PC-relative* Adressierung verwendet, ist dies oft bequemer als das Erstellen großer ROP-Ketten.
 
 ## Kernelvalidierung, PAC & Shadow-Stacks
 
-Linux 5.16 führte eine strengere Validierung von Benutzersignalrahmen ein (Commit `36f5a6c73096`). Der Kernel überprüft jetzt:
+Linux 5.16 führte eine strengere Validierung von Benutzersignal-Frames ein (Commit `36f5a6c73096`). Der Kernel überprüft jetzt:
 
 * `uc_flags` muss `UC_FP_XSTATE` enthalten, wenn `extra_context` vorhanden ist.
 * Das reservierte Wort in `struct rt_sigframe` muss null sein.
@@ -217,9 +217,9 @@ Linux 5.16 führte eine strengere Validierung von Benutzersignalrahmen ein (Comm
 
 `pwntools>=4.10` erstellt konforme Frames automatisch, aber wenn Sie sie manuell erstellen, stellen Sie sicher, dass Sie *reserviert* null-initialisieren und den SVE-Datensatz weglassen, es sei denn, Sie benötigen ihn wirklich – andernfalls liefert `rt_sigreturn` `SIGSEGV`, anstatt zurückzukehren.
 
-Beginnend mit dem Mainstream Android 14 und Fedora 38 wird der Userland standardmäßig mit **PAC** (*Pointer Authentication*) und **BTI** aktiviert kompiliert (`-mbranch-protection=standard`). *SROP* selbst ist nicht betroffen, da der Kernel `PC` direkt aus dem erstellten Frame überschreibt und den authentifizierten LR, der auf dem Stack gespeichert ist, umgeht; jedoch muss jede **nachfolgende ROP-Kette**, die indirekte Sprünge ausführt, zu BTI-aktivierten Anweisungen oder PAC-ed Adressen springen. Denken Sie daran, dies bei der Auswahl von Gadgets zu berücksichtigen.
+Beginnend mit dem Mainstream Android 14 und Fedora 38 wird der Userland standardmäßig mit **PAC** (*Pointer Authentication*) und **BTI** aktiviert kompiliert (`-mbranch-protection=standard`). *SROP* selbst ist nicht betroffen, da der Kernel `PC` direkt aus dem erstellten Frame überschreibt und so den authentifizierten LR, der auf dem Stack gespeichert ist, umgeht; jedoch muss jede **nachfolgende ROP-Kette**, die indirekte Sprünge ausführt, zu BTI-aktivierten Anweisungen oder PACed-Adressen springen. Behalten Sie das im Hinterkopf, wenn Sie Gadgets auswählen.
 
-Shadow-Call-Stacks, die in ARMv8.9 eingeführt wurden (und bereits in ChromeOS 1.27+ aktiviert sind), sind eine Compiler-Ebene Minderung und *beeinträchtigen* SROP nicht, da keine Rückgabebefehle ausgeführt werden – der Kontrollfluss wird vom Kernel übertragen.
+Shadow-Call-Stacks, die in ARMv8.9 eingeführt wurden (und bereits in ChromeOS 1.27+ aktiviert sind), sind eine Compiler-Ebene-Minderung und *beeinträchtigen* SROP nicht, da keine Rückgabebefehle ausgeführt werden – der Kontrollfluss wird vom Kernel übertragen.
 
 ## Referenzen
 

src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md

@@ -105,9 +105,9 @@ app.run()
 ```
 #### Neue (2023-2025) CSP-Bypass-Techniken mit Iframes
 
-Die Forschungsgemeinschaft entdeckt weiterhin kreative Möglichkeiten, um Iframes auszunutzen und restriktive Richtlinien zu umgehen. Im Folgenden finden Sie die bemerkenswertesten Techniken, die in den letzten Jahren veröffentlicht wurden:
+Die Forschungsgemeinschaft entdeckt weiterhin kreative Möglichkeiten, Iframes auszunutzen, um restriktive Richtlinien zu umgehen. Im Folgenden finden Sie die bemerkenswertesten Techniken, die in den letzten Jahren veröffentlicht wurden:
 
-* **Dangling-markup / named-iframe Datenexfiltration (PortSwigger 2023)** – Wenn eine Anwendung HTML reflektiert, aber eine starke CSP die Ausführung von Skripten blockiert, können Sie dennoch sensible Tokens durch das Injizieren eines *dangling* `<iframe name>` Attributs leaken. Sobald das partielle Markup geparst ist, navigiert das Angreifer-Skript, das in einem separaten Ursprung läuft, den Frame zu `about:blank` und liest `window.name`, das jetzt alles bis zum nächsten Anführungszeichen enthält (zum Beispiel ein CSRF-Token). Da kein JavaScript im Kontext des Opfers ausgeführt wird, umgeht der Angriff normalerweise `script-src 'none'`. Ein minimales PoC ist:
+* **Dangling-markup / named-iframe Datenexfiltration (PortSwigger 2023)** – Wenn eine Anwendung HTML reflektiert, aber eine starke CSP die Ausführung von Skripten blockiert, können Sie dennoch sensible Tokens leaken, indem Sie ein *dangling* `<iframe name>` Attribut injizieren. Sobald das partielle Markup geparst ist, navigiert das Angreifer-Skript, das in einem separaten Ursprung läuft, den Frame zu `about:blank` und liest `window.name`, das jetzt alles bis zum nächsten Anführungszeichen enthält (zum Beispiel ein CSRF-Token). Da kein JavaScript im Kontext des Opfers ausgeführt wird, umgeht der Angriff normalerweise `script-src 'none'`. Ein minimales PoC ist:
 
 ```html
 <!-- Injection point just before a sensitive <script> -->
@@ -164,7 +164,7 @@ Wenn verwendet, auferlegt das `sandbox`-Attribut mehrere Einschränkungen:
 - Es verhindert, dass Links mit anderen Browsing-Kontexten interagieren.
 - Die Verwendung von Plugins über `<embed>`, `<object>`, `<applet>` oder ähnliche Tags ist nicht erlaubt.
 - Die Navigation des übergeordneten Browsing-Kontexts des Inhalts durch den Inhalt selbst wird verhindert.
-- Automatisch ausgelöste Funktionen, wie die Wiedergabe von Videos oder das automatische Fokussieren von Formularsteuerelementen, werden blockiert.
+- Funktionen, die automatisch ausgelöst werden, wie die Wiedergabe von Videos oder das automatische Fokussieren von Formularsteuerelementen, werden blockiert.
 
 Tipp: Moderne Browser unterstützen granulare Flags wie `allow-scripts`, `allow-same-origin`, `allow-top-navigation-by-user-activation`, `allow-downloads-without-user-activation` usw. Kombinieren Sie sie, um nur die minimalen Fähigkeiten zu gewähren, die die eingebettete Anwendung benötigt.
 
@@ -181,7 +181,7 @@ Seit **Chrome 110 (Februar 2023) ist die Funktion standardmäßig aktiviert** un
 
 * Skripte in verschiedenen credentialless iframes **teilen sich weiterhin den gleichen Top-Level-Ursprung** und können über das DOM frei interagieren, was mehrfache iframe self-XSS-Angriffe möglich macht (siehe PoC unten).
 * Da das Netzwerk **credential-stripped** ist, verhält sich jede Anfrage innerhalb des iframes effektiv wie eine nicht authentifizierte Sitzung – CSRF-geschützte Endpunkte schlagen normalerweise fehl, aber öffentliche Seiten, die über das DOM auslesbar sind, sind weiterhin im Geltungsbereich.
-* Pop-ups, die aus einem credentialless iframe erzeugt werden, erhalten ein implizites `rel="noopener"`, was einige OAuth-Flows unterbricht.
+* Pop-ups, die aus einem credentialless iframe erzeugt werden, erhalten ein implizites `rel="noopener"`, was einige OAuth-Flüsse unterbricht.
 ```javascript
 // PoC: two same-origin credentialless iframes stealing cookies set by a third
 window.top[1].document.cookie = 'foo=bar';            // write
@@ -209,7 +209,7 @@ document.forms[0].submit();
 
 - Ein weiteres iframe, das tatsächlich den Benutzer angemeldet hat (ohne das `credentialless`-Flag).
 
-Dann ist es vom XSS aus möglich, auf das andere iframe zuzugreifen, da sie die gleiche SOP haben, und das Cookie zu stehlen, indem man beispielsweise Folgendes ausführt:
+Dann ist es von dem XSS aus möglich, auf das andere iframe zuzugreifen, da sie die gleiche SOP haben, und das Cookie zu stehlen, indem man beispielsweise Folgendes ausführt:
 ```javascript
 alert(window.top[1].document.cookie);
 ```
@@ -249,6 +249,6 @@ fetchLater(req,{activateAfter: timeout})
 
 ## References
 
-* [PortSwigger Research – Using form hijacking to bypass CSP (März 2024)](https://portswigger.net/research/using-form-hijacking-to-bypass-csp)
+* [PortSwigger Research – Using form hijacking to bypass CSP (March 2024)](https://portswigger.net/research/using-form-hijacking-to-bypass-csp)
 * [Chrome Developers – Iframe credentialless: Easily embed iframes in COEP environments (Feb 2023)](https://developer.chrome.com/blog/iframe-credentialless)
 {{#include ../../banners/hacktricks-training.md}}