Threat model does not address availability (spec. DOS) and some compression&crypto vulns

[jasnell]

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.

[mikesamuel]

Thanks for giving it a read.

attacks based on the intersection of Crypto and Compression

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?

Denial of Service attacks

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.
Are there ways to tweak how the node runtime deals with runaway threads?

[jasnell]

I'm afraid I'm unfamiliar with the specifics of Node.js that make it particularly vulnerable to this.

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/

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?

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.

[mikesamuel]

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

Client-side, a script that consumes too much processor in a single event loop run causes the browser to halt all script execution for that document.
Node.js has few ways to manage runaway computations on the server.

and refer to it from a new threat-DOS which says something like

Denial of Service

Denial of service occurs when an authorized user cannot access a system.

"Denial of service" is most often associated with flooding a network endpoint with
many bogus requests so it cannot respond to the smaller number of legitimate
requests but there are other vectors:

• Supplying over-large inputs to super-linear (> O(n)) algorithms
• Supplying crafted strings to ambiguous RegExps causing [excessive backtracking][].
• Causing the server to use too many of a finite resource like file descriptors causing
  threads to block.
• Tar-pitting: causing the server itself to issue a network to an endpoint you control and
  responding slowly.

Additional risk: Integrity depends on Availability

A transactional requirement is when two or more effects have to happen together or not at all.

If there is a transactional requirement, and an attacker can cause computation to halt
after part of the transaction, and halting the computation does not roll-back then a
breach of availability can become a breach of integrity.

Client-side, runaway computations rarely translate into an integrity violation since transactional requirements are typically maintained on the server.
Server-side, we would expect to find more code that uses ad-hoc methods to maintain transactional requirements so unfinished computations are more likely to violate system integrity.

Risk / severity TBD.
"""