Translated ['', 'src/pentesting-web/regular-expression-denial-of-service

This commit is contained in:
Translator 2025-10-01 15:16:24 +00:00
parent 9ce9e0f8a5
commit 2f5ffe0dfa

View File

@ -1,41 +1,70 @@
# Regular Expression Denial of Service - ReDoS
# Regular expression Denial of Service - ReDoS
{{#include ../banners/hacktricks-training.md}}
# Regular Expression Denial of Service (ReDoS)
Ein **Regular Expression Denial of Service (ReDoS)** tritt auf, wenn jemand Schwächen in der Funktionsweise von regulären Ausdrücken (eine Methode zum Suchen und Abgleichen von Mustern in Text) ausnutzt. Manchmal, wenn reguläre Ausdrücke verwendet werden, können sie sehr langsam werden, insbesondere wenn das Stück Text, mit dem sie arbeiten, größer wird. Diese Langsamkeit kann so schlimm werden, dass sie mit selbst kleinen Erhöhungen der Textgröße sehr schnell zunimmt. Angreifer können dieses Problem nutzen, um ein Programm, das reguläre Ausdrücke verwendet, für lange Zeit daran zu hindern, richtig zu funktionieren.
Ein **Regular Expression Denial of Service (ReDoS)** tritt auf, wenn jemand Schwächen in der Funktionsweise von regulären Ausdrücken (einer Möglichkeit, Muster in Text zu suchen und abzugleichen) ausnutzt. Manchmal werden reguläre Ausdrücke sehr langsam, besonders wenn der zu verarbeitende Text länger wird. Diese Verlangsamung kann so stark sein, dass sie bei kleinen Zuwächsen der Textlänge sehr schnell zunimmt. Angreifer können dieses Problem ausnutzen, um ein Programm, das reguläre Ausdrücke verwendet, für längere Zeit funktionsunfähig zu machen.
## Der problematische Regex naive Algorithmus
## Der problematische naive RegexAlgorithmus
**Überprüfen Sie die Details in [https://owasp.org/www-community/attacks/Regular*expression_Denial_of_Service*-\_ReDoS](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS)**
**Check the details in [https://owasp.org/www-community/attacks/Regular*expression_Denial_of_Service*-_ReDoS](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS)**
## Böse Regexes <a href="#evil-regexes" id="evil-regexes"></a>
### Engine behavior and exploitability
Ein böses reguläres Ausdrucksmuster ist eines, das **bei manipulierten Eingaben stecken bleibt und einen DoS verursacht**. Böse Regex-Muster enthalten typischerweise Gruppierungen mit Wiederholungen und Wiederholungen oder Alternationen mit Überlappungen innerhalb der wiederholten Gruppe. Einige Beispiele für böse Muster sind:
- Most popular engines (PCRE, Java `java.util.regex`, Python `re`, JavaScript `RegExp`) use a **backtracking** VM. Crafted inputs that create many overlapping ways to match a subpattern force exponential or high-polynomial backtracking.
- Einige Engines/Libraries sind von vornherein **ReDoS-resilient** konzipiert (kein Backtracking), z. B. **RE2** und Ports, die auf endlichen Automaten basieren und im WorstCase lineare Laufzeit bieten; ihr Einsatz für nichtvertrauenswürdige Eingaben entfernt die BacktrackingDoSPrimitive. Siehe die Referenzen am Ende für Details.
## Bösartige Regexes <a href="#evil-regexes" id="evil-regexes"></a>
Ein bösartiges regular expression pattern ist eines, das bei speziell gestalteter Eingabe **festhängt und einen DoS verursacht**. Bösartige regexPatterns enthalten typischerweise Gruppierungen mit Wiederholungen sowie Wiederholung oder Alternation mit Überlappung innerhalb der wiederholten Gruppe. Einige Beispiele für bösartige Patterns sind:
- (a+)+
- ([a-zA-Z]+)\*
- (a|aa)+
- (a|a?)+
- (.\*a){x} für x > 10
- (.*a){x} for x > 10
Alle diese sind anfällig für die Eingabe `aaaaaaaaaaaaaaaaaaaaaaaa!`.
Alle diese sind gegenüber der Eingabe `aaaaaaaaaaaaaaaaaaaaaaaa!` anfällig.
### Praktische Anleitung zum Erstellen von PoCs
Die meisten katastrophalen Fälle folgen diesem Muster:
- Prefix, das dich in das verwundbare Subpattern bringt (optional).
- Eine lange Folge eines Zeichens, die mehrdeutige Matches innerhalb verschachtelter/überlappender Quantifier verursacht (z. B. viele `a`, `_` oder Leerzeichen).
- Ein abschließendes Zeichen, das das Gesamtergebnis scheitern lässt, sodass die Engine alle Möglichkeiten backtracken muss (oft ein Zeichen, das nicht zum letzten Token passt, wie `!`).
Minimale Beispiele:
- `(a+)+$` vs input `"a"*N + "!"`
- `\w*_*\w*$` vs input `"v" + "_"*N + "!"`
Erhöhe N und beobachte superlineares Wachstum.
#### Schnelles TimingHarness (Python)
```python
import re, time
pat = re.compile(r'(\w*_)\w*$')
for n in [2**k for k in range(8, 15)]:
s = 'v' + '_'*n + '!'
t0=time.time(); pat.search(s); dt=time.time()-t0
print(n, f"{dt:.3f}s")
```
## ReDoS Payloads
### String Exfiltration via ReDoS
In einem CTF (oder Bug-Bounty) könnten Sie **den Regex kontrollieren, mit dem eine sensible Information (das Flag) abgeglichen wird**. Dann könnte es nützlich sein, die **Seite einfrieren zu lassen (Timeout oder längere Verarbeitungszeit)**, wenn der **Regex übereinstimmte** und **nicht, wenn er es nicht tat**. Auf diese Weise können Sie die **Zeichenkette** **Zeichen für Zeichen** **exfiltrieren**:
In einem CTF (or bug bounty) kontrollierst du vielleicht den **Regex, mit dem eine sensible Information (the flag) abgeglichen wird**. Dann kann es nützlich sein, die **Seite einfrieren zu lassen (timeout oder längere Verarbeitungszeit)**, wenn der **Regex übereinstimmt** und **nicht, wenn er es nicht tut**. Auf diese Weise kannst du die Zeichenkette **exfiltrate** **char by char**:
- In [**diesem Beitrag**](https://portswigger.net/daily-swig/blind-regex-injection-theoretical-exploit-offers-new-way-to-force-web-apps-to-spill-secrets) finden Sie diese ReDoS-Regel: `^(?=<flag>)((.*)*)*salt$`
- In [**this post**](https://portswigger.net/daily-swig/blind-regex-injection-theoretical-exploit-offers-new-way-to-force-web-apps-to-spill-secrets) findest du diese ReDoS-Regel: `^(?=<flag>)((.*)*)*salt$`
- Beispiel: `^(?=HTB{sOmE_fl§N§)((.*)*)*salt$`
- In [**diesem Writeup**](https://github.com/jorgectf/Created-CTF-Challenges/blob/main/challenges/TacoMaker%20%40%20DEKRA%20CTF%202022/solver/solver.html) finden Sie dieses: `<flag>(((((((.*)*)*)*)*)*)*)!`
- In [**diesem Writeup**](https://ctftime.org/writeup/25869) verwendete er: `^(?=${flag_prefix}).*.*.*.*.*.*.*.*!!!!$`
- In [**this writeup**](https://github.com/jorgectf/Created-CTF-Challenges/blob/main/challenges/TacoMaker%20@%20DEKRA%20CTF%202022/solver/solver.html) findest du diese: `<flag>(((((((.*)*)*)*)*)*)*)!`
- In [**this writeup**](https://ctftime.org/writeup/25869) verwendete er: `^(?=${flag_prefix}).*.*.*.*.*.*.*.*!!!!$`
### ReDoS kontrollierende Eingabe und Regex
### ReDoS Controlling Input and Regex
Die folgenden sind **ReDoS**-Beispiele, bei denen Sie sowohl die **Eingabe** als auch den **Regex** **kontrollieren**:
Die folgenden **ReDoS**-Beispiele zeigen Fälle, in denen du sowohl das **input** als auch den **regex** kontrollierst:
```javascript
function check_time_regexp(regexp, text) {
var t0 = new Date().getTime()
@ -65,16 +94,35 @@ Regexp ([a-zA-Z]+)*$ took 773 milliseconds.
Regexp (a+)*$ took 723 milliseconds.
*/
```
### Hinweise zu Sprachen/Engines für Angreifer
- JavaScript (browser/Node): Die eingebaute `RegExp` ist eine Backtracking-Engine und häufig ausnutzbar, wenn regex+Eingabe von Angreifern beeinflusst werden.
- Python: `re` verwendet Backtracking. Lange mehrdeutige Läufe plus ein scheiternder Abschluss führen oft zu katastrophalem Backtracking.
- Java: `java.util.regex` verwendet Backtracking. Wenn Sie nur die Eingabe kontrollieren, suchen Sie nach Endpunkten mit komplexen Validatoren; wenn Sie Patterns kontrollieren (z. B. gespeicherte Regeln), ist ReDoS meist trivial.
- Engines wie **RE2/RE2J/RE2JS** oder das **Rust regex** crate sind so konzipiert, katastrophales Backtracking zu vermeiden. Wenn Sie auf diese stoßen, konzentrieren Sie sich auf andere Engpässe (z. B. enorme Patterns) oder finden Sie Komponenten, die weiterhin Backtracking-Engines verwenden.
## Tools
- [https://github.com/doyensec/regexploit](https://github.com/doyensec/regexploit)
- Find vulnerable regexes and autogenerate evil inputs. Examples:
- `pip install regexploit`
- Analyze one pattern interactively: `regexploit`
- Scan Python/JS code for regexes: `regexploit-py path/` and `regexploit-js path/`
- [https://devina.io/redos-checker](https://devina.io/redos-checker)
- [https://github.com/davisjam/vuln-regex-detector](https://github.com/davisjam/vuln-regex-detector)
- Endtoend pipeline to extract regexes from a project, detect vulnerable ones, and validate PoCs in the target language. Useful for hunting through large codebases.
- [https://github.com/tjenkinson/redos-detector](https://github.com/tjenkinson/redos-detector)
- Simple CLI/JS library that reasons about backtracking to report if a pattern is safe.
## References
> Tipp: Wenn Sie nur die Eingabe kontrollieren, generieren Sie Zeichenketten mit sich verdoppelnden Längen (z. B. 2^k Zeichen) und messen Sie die Latenz. Exponentielles Wachstum deutet stark auf einen verwertbaren ReDoS hin.
- [https://owasp.org/www-community/attacks/Regular*expression_Denial_of_Service*-\_ReDoS](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS)
## Referenzen
- [https://owasp.org/www-community/attacks/Regular*expression_Denial_of_Service*-_ReDoS](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS)
- [https://portswigger.net/daily-swig/blind-regex-injection-theoretical-exploit-offers-new-way-to-force-web-apps-to-spill-secrets](https://portswigger.net/daily-swig/blind-regex-injection-theoretical-exploit-offers-new-way-to-force-web-apps-to-spill-secrets)
- [https://github.com/jorgectf/Created-CTF-Challenges/blob/main/challenges/TacoMaker%20%40%20DEKRA%20CTF%202022/solver/solver.html](https://github.com/jorgectf/Created-CTF-Challenges/blob/main/challenges/TacoMaker%20%40%20DEKRA%20CTF%202022/solver/solver.html)
- [https://github.com/jorgectf/Created-CTF-Challenges/blob/main/challenges/TacoMaker%20@%20DEKRA%20CTF%202022/solver/solver.html](https://github.com/jorgectf/Created-CTF-Challenges/blob/main/challenges/TacoMaker%20@%20DEKRA%20CTF%202022/solver/solver.html)
- [https://ctftime.org/writeup/25869](https://ctftime.org/writeup/25869)
- SoK (2024): Literatur- und Technik-Review zu Regular Expression Denial of Service (ReDoS) — [https://arxiv.org/abs/2406.11618](https://arxiv.org/abs/2406.11618)
- Why RE2 (lineartime regex engine) — [https://github.com/google/re2/wiki/WhyRE2](https://github.com/google/re2/wiki/WhyRE2)
{{#include ../banners/hacktricks-training.md}}