GitBook: [#3295] No subject

pentesting-web/regular-expression-denial-of-service-redos.md

@@ -1,4 +1,4 @@
-
+# Regular expression Denial of Service - ReDoS
 
 <details>
 
@@ -16,16 +16,15 @@ Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
 
 </details>
 
-
-# Introduction
+## Introduction
 
 **Copied from** [**https://owasp.org/www-community/attacks/Regular\_expression\_Denial\_of\_Service\_-\_ReDoS**](https://owasp.org/www-community/attacks/Regular\_expression\_Denial\_of\_Service\_-\_ReDoS)
 
 The **Regular expression Denial of Service (ReDoS)** is a [Denial of Service](https://owasp.org/www-community/attacks/Denial\_of\_Service) attack, that exploits the fact that most Regular Expression implementations may reach extreme situations that cause them to work very slowly (exponentially related to input size). An attacker can then cause a program using a Regular Expression to enter these extreme situations and then hang for a very long time.
 
-## Description
+### Description
 
-### The problematic Regex naïve algorithm <a href="#the-problematic-regex-naive-algorithm" id="the-problematic-regex-naive-algorithm"></a>
+#### The problematic Regex naïve algorithm <a href="#the-problematic-regex-naive-algorithm" id="the-problematic-regex-naive-algorithm"></a>
 
 The Regular Expression naïve algorithm builds a [Nondeterministic Finite Automaton (NFA)](https://en.wikipedia.org/wiki/Nondeterministic\_finite\_state\_machine), which is a finite state machine where for each pair of state and input symbol there may be several possible next states. Then the engine starts to make transition until the end of the input. Since there may be several possible next states, a deterministic algorithm is used. This algorithm tries one by one all the possible paths (if needed) until a match is found (or all the paths are tried and fail).
 
@@ -37,7 +36,7 @@ For the input `aaaaX` there are 16 possible paths in the above graph. But for `a
 
 Notice, that not all algorithms are naïve, and actually Regex algorithms can be written in an efficient way. Unfortunately, most Regex engines today try to solve not only “pure” Regexes, but also “expanded” Regexes with “special additions”, such as back-references that cannot be always be solved efficiently (see **Patterns for non-regular languages** in [Wiki-Regex](https://en.wikipedia.org/wiki/Regular\_expression) for some more details). So even if the Regex is not “expanded”, a naïve algorithm is used.
 
-### Evil Regexes <a href="#evil-regexes" id="evil-regexes"></a>
+#### Evil Regexes <a href="#evil-regexes" id="evil-regexes"></a>
 
 A Regex is called “evil” if it can stuck on crafted input.
 
@@ -58,17 +57,18 @@ A Regex is called “evil” if it can stuck on crafted input.
 
 All the above are susceptible to the input `aaaaaaaaaaaaaaaaaaaaaaaa!` (The minimum input length might change slightly, when using faster or slower machines).
 
-# ReDoS Payloads
+## ReDoS Payloads
 
-## String Exfiltration via ReDoS
+### String Exfiltration via ReDoS
 
 In a CTF (or bug bounty) maybe you **control the Regex a sensitive information (the flag) is matched with**. Then, if might be useful to make the **page freeze (timeout or longer processing time)** if the a **Regex matched** and **not if it didn't**. This way you will be able to **exfiltrate** the string **char by char**:
 
 * In [**this post**](https://portswigger.net/daily-swig/blind-regex-injection-theoretical-exploit-offers-new-way-to-force-web-apps-to-spill-secrets) you can find this ReDoS rule: `^(?=<flag>)((.*)*)*salt$`
   * Example: `^(?=HTB{sOmE_fl§N§)((.*)*)*salt$`
 * In [**this writeup**](https://github.com/jorgectf/Created-CTF-Challenges/blob/main/challenges/TacoMaker%20%40%20DEKRA%20CTF%202022/solver/solver.html) you can find this one:`<flag>(((((((.*)*)*)*)*)*)*)!`
+* In [**this writeup**](https://ctftime.org/writeup/25869) he used: `^(?=${flag_prefix}).*.*.*.*.*.*.*.*!!!!$`
 
-## ReDoS Controlling Input and Regex
+### ReDoS Controlling Input and Regex
 
 The following are **ReDoS** examples where you **control** both the **input** and the **regex**:
 
@@ -102,12 +102,11 @@ Regexp (a+)*$ took 723 milliseconds.
 */
 ```
 
-# Tools
+## Tools
 
 * [https://github.com/doyensec/regexploit](https://github.com/doyensec/regexploit)
 * [https://devina.io/redos-checker](https://devina.io/redos-checker)
 
-
 <details>
 
 <summary><strong>Support HackTricks and get benefits!</strong></summary>
@@ -123,5 +122,3 @@ Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
 **Share your hacking tricks submitting PRs to the** [**hacktricks github repo**](https://github.com/carlospolop/hacktricks)**.**
 
 </details>
-
-

pentesting-web/xs-search.md

@@ -694,7 +694,7 @@ Before accessing the cache is faster than loading a resource, it's possible to t
 * **Inclusion Methods**: Fetch API
 * **Detectable Difference**: Timing
 * **More info**: [https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller](https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller)
-* **Summary:** It's possible to try to load a resource and about before it's loaded the loading is interrupted. Depending on if an error is triggered, the resource was or wasn't cached.
+* **Summary:** It's possible to try to load a resource and about before it's loaded. Depending on if an error is triggered, the resource was or wasn't cached.
 * **Code Example**: [https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller](https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller)
 
 [**`AbortController`**](https://developer.mozilla.org/en-US/docs/Web/API/AbortController) **** could be combined with _**fetch**_ and _**setTimeout**_ to both detect whether the **resource is cached** and to evict a specific resource from the browser cache. A nice feature of this technique is that the probing occurs without caching new content in the process.