# XSS (Cross Site Scripting)
## Methodologie
1. Überprüfen Sie, ob **irgendein Wert, den Sie kontrollieren** (_Parameter_, _Pfad_, _Header_?, _Cookies_?) im HTML **reflektiert** oder von **JS**-Code **verwendet** wird.
2. **Finden Sie den Kontext**, in dem es reflektiert/verwendet wird.
3. Wenn **reflektiert**:
1. Überprüfen Sie, **welche Symbole Sie verwenden können** und bereiten Sie je nach dem die Payload vor:
1. In **rohem HTML**:
1. Können Sie neue HTML-Tags erstellen?
2. Können Sie Ereignisse oder Attribute verwenden, die das `javascript:`-Protokoll unterstützen?
3. Können Sie Schutzmaßnahmen umgehen?
4. Wird der HTML-Inhalt von einer clientseitigen JS-Engine (_AngularJS_, _VueJS_, _Mavo_...) interpretiert, könnten Sie eine [**Client Side Template Injection**](../client-side-template-injection-csti.md) ausnutzen.
5. Wenn Sie keine HTML-Tags erstellen können, die JS-Code ausführen, könnten Sie eine [**Dangling Markup - HTML scriptless injection**](../dangling-markup-html-scriptless-injection/index.html) ausnutzen?
2. Innerhalb eines **HTML-Tags**:
1. Können Sie in den rohen HTML-Kontext wechseln?
2. Können Sie neue Ereignisse/Attribute erstellen, um JS-Code auszuführen?
3. Unterstützt das Attribut, in dem Sie gefangen sind, die Ausführung von JS?
4. Können Sie Schutzmaßnahmen umgehen?
3. Innerhalb **JavaScript-Code**:
1. Können Sie das ``**-Tags einer HTML-Seite, in einer `.js`-Datei oder innerhalb eines Attributs mit dem **`javascript:`**-Protokoll reflektiert:
- Wenn sie zwischen **``**-Tags reflektiert wird, können Sie versuchen, `` einzufügen und aus diesem Kontext zu entkommen, selbst wenn Ihre Eingabe in irgendeiner Art von Anführungszeichen steht. Dies funktioniert, weil der **Browser zuerst die HTML-Tags** parst und dann den Inhalt, daher wird er nicht bemerken, dass Ihr injiziertes ``-Tag im HTML-Code enthalten 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 es innerhalb von Template-Literalen reflektiert wird, können Sie **JS-Ausdrücke einbetten** mit der `${ ... }`-Syntax: `` var greetings = `Hello, ${alert(1)}` ``
- **Unicode-Encoding** funktioniert, um **gültigen JavaScript-Code** zu schreiben:
```javascript
alert(1)
alert(1)
alert(1)
```
#### Javascript Hoisting
Javascript Hoisting bezieht sich auf die Möglichkeit, **Funktionen, Variablen oder Klassen nach ihrer Verwendung zu deklarieren, sodass Sie Szenarien ausnutzen können, in denen ein XSS nicht deklarierte Variablen oder Funktionen verwendet.**\
**Überprüfen Sie die folgende Seite für weitere Informationen:**
{{#ref}}
js-hoisting.md
{{#endref}}
### Javascript Funktion
Mehrere Webseiten haben Endpunkte, die **den Namen der auszuführenden Funktion als Parameter akzeptieren**. Ein häufiges Beispiel, das man in der Wildnis sieht, ist etwas wie: `?callback=callbackFunc`.
Eine gute Möglichkeit herauszufinden, ob etwas, das direkt vom Benutzer gegeben wird, versucht wird auszuführen, ist **den Parameterwert zu ändern** (zum Beispiel auf 'Vulnerable') und in der Konsole nach Fehlern zu suchen wie:
.png>)
Falls es anfällig ist, könnten Sie in der Lage sein, **einen Alert auszulösen**, indem Sie einfach den Wert senden: **`?callback=alert(1)`**. Es ist jedoch sehr häufig, dass diese Endpunkte **den Inhalt validieren**, um nur Buchstaben, Zahlen, Punkte und Unterstriche zuzulassen (**`[\w\._]`**).
Dennoch ist es selbst mit dieser Einschränkung möglich, einige Aktionen durchzuführen. Das liegt daran, dass Sie diese gültigen Zeichen verwenden können, um **auf jedes Element im DOM zuzugreifen**:
.png>)
Einige nützliche Funktionen dafür:
```
firstElementChild
lastElementChild
nextElementSibiling
lastElementSibiling
parentElement
```
Sie können auch versuchen, **Javascript-Funktionen** direkt auszulösen: `obj.sales.delOrders`.
In der Regel sind die Endpunkte, die die angegebene Funktion ausführen, Endpunkte ohne viel interessantes DOM, **andere Seiten im selben Ursprung** haben ein **interessanteres DOM**, um mehr Aktionen durchzuführen.
Daher wurde zur **Ausnutzung dieser Schwachstelle in einem anderen DOM** die **Same Origin Method Execution (SOME)**-Ausnutzung entwickelt:
{{#ref}}
some-same-origin-method-execution.md
{{#endref}}
### DOM
Es gibt **JS-Code**, der **unsicher** einige **von einem Angreifer kontrollierte Daten** wie `location.href` verwendet. Ein Angreifer könnte dies ausnutzen, um beliebigen JS-Code auszuführen.
{{#ref}}
dom-xss.md
{{#endref}}
### **Universelles XSS**
Diese Art von XSS kann **überall** gefunden werden. Sie hängt nicht nur von der Client-Ausnutzung einer Webanwendung ab, sondern von **jedem** **Kontext**. Diese Art der **beliebigen JavaScript-Ausführung** kann sogar ausgenutzt werden, um **RCE** zu erhalten, **beliebige** **Dateien** auf Clients und Servern zu lesen und mehr.\
Einige **Beispiele**:
{{#ref}}
server-side-xss-dynamic-pdf.md
{{#endref}}
{{#ref}}
../../network-services-pentesting/pentesting-web/electron-desktop-apps/
{{#endref}}
## WAF-Bypass-Codierung Bild
.jpg>)
## In rohes HTML injizieren
Wenn Ihre Eingabe **innerhalb der HTML-Seite** widergespiegelt wird oder Sie HTML-Code in diesem Kontext entkommen und injizieren können, ist das **erste**, was Sie tun müssen, zu überprüfen, ob Sie `<` ausnutzen können, um neue Tags zu erstellen: Versuchen Sie einfach, dieses **Zeichen** zu **reflektieren** und überprüfen Sie, ob es **HTML-codiert** oder **gelöscht** wird oder ob es **unverändert widergespiegelt** wird. **Nur im letzten Fall werden Sie in der Lage sein, diesen Fall auszunutzen**.\
Für diese Fälle sollten Sie auch **im Hinterkopf behalten** [**Client Side Template Injection**](../client-side-template-injection-csti.md)**.**\
_**Hinweis: Ein HTML-Kommentar kann mit\*\***\***\*`-->`\*\***\***\*oder \*\***`--!>`\*\*geschlossen werden._
In diesem Fall und wenn keine Black-/Whitelisting verwendet wird, könnten Sie Payloads wie verwenden:
```html