-
Notifications
You must be signed in to change notification settings - Fork 6.3k
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.
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
"Don't block the event loop": New guide on avoiding DoS #1471
Comments
I was hoping for some discussion here about whether or not there's interest. I haven't contributed to this project before -- am I supposed to prepare the guide first, so people can see what I have in mind? |
Well, TBH I think there would indeed be more to discuss if you had a draft. Though anyway, I'm probably not the most qualified to discuss the technical quality of such draft, I'd very much like to read it and the discussion that might follow. And also no worries, globally, "no discussion" generally means "go ahead"; people tend a bit more to comment to say when they don't agree than when they agree, from what I've seen 😄 |
Ain't that the truth. I'll work on a draft, thank you. |
* WIP Guide on "Don't block the event loop" For #1471 * More formal language, some examples * Add indexOf * Edits and more examples - REDOS - JSON DOS - "Complex calculations without blocking the Event Loop" * Typo * Refresh sections: npm modules, conclusion * Don't Block the Worker Pool * Describe core module use of the Node Worker Pool * Address review comments - Rewrite the "A quick review of Node" section - Remove "Event Handler" abstraction - Provide more internal details - Relax the "Offloading best practices" - New task variation example: crypto.randomBytes - Misc. formatting and bonus material * Add link to node/17054 * Address review comments
Addressed by #1478. |
We know, we know, "Don't block the event loop"
Node.js event loop follows the event-driven architecture, with a single-threaded Event Loop supported by a small Worker Pool for expensive operations like FS and DNS.
Though "Don't block the event loop" is a good rule of thumb, developers new to the EDA could easily expose themselves to this and other Denial of Service vulnerabilities if they don't think carefully about the implications of the limited supply of threads. For example, REDOS is a very real threat but a bit of a surprise as a way to block the event loop.
There are of course a lot of blog posts describing this issue in varying levels of formality and detail, but I think the community would benefit from a guide put out by a central authority -- like nodejs.org!
Also don't block the threadpool
Since libuv's threadpool is tiny (default 4 threads, max 128), cavalierly offloading hugely expensive work to the threadpool is also not a good idea. Continuing with the REDOS example, unfortunately, this is done by some of the "safe" regex modules.
More on this if you're interested
I've discussed this a bit in an academic workshop paper (link), but since then I've done a larger survey of the npm vulnerabilities reported by Snyk.io and believe that the Node community would benefit from a public guide to this problem.
PR
I'm happy to prepare this guide and submit a PR if there's interest. However, I can only prepare this document in English.
The text was updated successfully, but these errors were encountered: