Threat model does not address availability (spec. DOS) and some compression&crypto vulns #14
Comments
Thanks for giving it a read.
I'm afraid I'm unfamiliar with the specifics of Node.js that make it particularly vulnerable to this. Where might I may find more on this topic?
Agreed. This may be a bit of a Google-specific blind spot because we tend to handle DOS mostly in the reverse proxy. How do existing node projects deal with this? Is it usually handled by the app container? Re other availability problems, we didn't spend much time on runaway computations either, like crafted inputs reaching badly written RegExps causing excessive backtracking. |
To be certain, Node.js is not any more vulnerable to this than any other platform. The basic idea is that when using transfer compression over a TLS connection, if the attacker is able to control any of the information within the encrypted and compressed data, then it can use various statistical analysis methods to derive the other content simply by looking at the compression ratios. This, for instance, is why HTTP/2 forbids using TLS compression and is why Node.js has disabled TLS compression by default. There are ways, however, in which users can get in to trouble still, however. Again, it is not something that is particularly unique to Node.js, but it is worth at least mentioning. Here's one resource to begin researching: http://breachattack.com/resources/
To be absolutely honest, dealing with DOS at the edge is the best practice for Node.js also. Node.js itself has a variety of shortcomings when it comes to how it interfaces with the network -- for instance, libuv will accept any connection from any client causing resources to be consumed prior to any user code being invoked. While this can be managed and while idle sockets are thankfully not that expensive of a resource to maintain, it is a vector that can be leveraged by an attacker. Node.js generally has very few protections built-in to prevent a malicious party from consuming significant resources. |
Maybe it's worth noting this when contrasting client- and server-side JS. Something like
and refer to it from a new threat-DOS which says something like
|
First of all, A+ on this. Love it.
Some feedback.
In https://github.com/google/node-sec-roadmap/blob/master/chapter-1/threat-CRY.md, it would make sense to at least briefly cover the possibility of attacks based on the intersection of Crypto and Compression that make even strong crypto algorithms vulnerable. This is particularly relevant in Node.js when using transfer compression over TLS connections.
I'm surprised that Denial of Service attacks are not specifically called out, especially given the focus on HTTP in Node.js. It is surprisingly easy to get in to trouble on this.
The text was updated successfully, but these errors were encountered: