Skip to content
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

Closed
davisjam opened this issue Nov 15, 2017 · 5 comments

Comments

@davisjam
Copy link
Contributor

commented Nov 15, 2017

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.

@davisjam

This comment has been minimized.

Copy link
Contributor Author

commented Nov 18, 2017

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?

@Tiriel

This comment has been minimized.

Copy link
Member

commented Nov 18, 2017

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 😄

@davisjam

This comment has been minimized.

Copy link
Contributor Author

commented Nov 18, 2017

people tend a bit more to comment to say when they don't agree than when they agree

Ain't that the truth. I'll work on a draft, thank you.

davisjam pushed a commit to davisjam/nodejs.org that referenced this issue Nov 19, 2017
davisjam pushed a commit to davisjam/nodejs.org that referenced this issue Nov 19, 2017
@davisjam

This comment has been minimized.

Copy link
Contributor Author

commented Nov 19, 2017

@Tiriel and others, see #1478.

Let's continue this discussion over there.

davisjam added a commit to davisjam/nodejs.org that referenced this issue Nov 19, 2017
@davisjam

This comment has been minimized.

Copy link
Contributor Author

commented Dec 7, 2017

Addressed by #1478.

@davisjam davisjam closed this Dec 7, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.