Comment by antonymoose
2 months ago
I routinely handle regex DoS complaints on front-end input validation…
If a hacker wants to DoS their own browser I’m fine with that.
2 months ago
I routinely handle regex DoS complaints on front-end input validation…
If a hacker wants to DoS their own browser I’m fine with that.
This depends on the context to be fair. Front-end DoS can suddenly expand into botnet DDoS if you can trigger it by just serving a specific kind of URL. E.g. search goes into endless loop that makes requests into the backend.
No. The Regex DoS class of bugs is about infinite backtracking or looping inside the regex engine. Completely isolated component, just hogging CPU inside the regex engine. It may also have ‘DoS’ in its name, but there’s no relation to network (D)DoS attacks.
It could still be a security error, but only if all availability errors are for that project. But after triage, the outcome is almost always “user can hang own browser on input which isn’t likely”. And yes, it’s a pity I wrote ‘almost’, which means having to check 99% false alarms.
Until the same library for their "isomorphic" backend..
Even then the usual thing about regexp DoS is that "it's possible to write a regexp that is very very slow to process", not about the text being matched.
For validation, the programmer typically controls the regexp exactly as much as they control the rest of the source code.
Server side rendering is all the rage again, so yeah it might be.