Skip to content

Add ReDoS guidance to the Denial of Service Cheat Sheet #2947

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
abhinav-phi wants to merge 1 commit into from
Closed

Add ReDoS guidance to the Denial of Service Cheat Sheet #2947

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions cheatsheets/Denial_of_Service_Cheat_Sheet.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -81,6 +81,7 @@ Packet filtering technology can be used to inspect packets in transit to identif
- **Prevent input based resource allocation**: Again, to make it harder for resource-consuming DoS attacks to succeed. (resource exhaustion)
- **Prevent input based function and threading interaction**: User input can influence how many times a function needs to be executed, or how intensive the CPU consumption becomes. Depending on (unfiltered) user input for resource allocation could allow a DoS scenario through resource exhaustion. (resource exhaustion)
- **Input based puzzles** like captchas or simple math problems are often used to 'protect' a web form. The classic example is a webform that will send out an email after posting the request. A captcha could then prevent the mailbox from getting flooded by a malicious attacker or spambot. **Puzzles serve a purpose against functionality abuse but this kind of technology will not help defend against DoS attacks.**
- **Avoid regular expressions that can backtrack catastrophically**: on backtracking engines, patterns with nested or overlapping quantifiers take exponential time on some inputs, so a single short request can pin a CPU core (resource exhaustion). Prefer a linear-time engine where one is available ([RE2](https://github.com/google/re2), [Go's `regexp`](https://pkg.go.dev/regexp), [.NET's `RegexOptions.NonBacktracking`](https://learn.microsoft.com/en-us/dotnet/standard/base-types/backtracking-in-regular-expressions)); otherwise set a match timeout ([.NET's `Regex.MatchTimeout`](https://learn.microsoft.com/en-us/dotnet/standard/base-types/backtracking-in-regular-expressions)) and limit the input length before matching. See the [OWASP ReDoS guidance](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS) for the attack mechanics and the [Input Validation Cheat Sheet](Input_Validation_Cheat_Sheet.md#regular-expressions-regex) for the validation-side controls.

### Access control

Expand Down