Add a Threat Model #5526
Add a Threat Model #5526
Conversation
UlisesGascon
added
top priority
|
I think this is a good starting point. |
Security.md
Outdated
|
|
||
| 1. Developers and infrastructure responsible for running it. | ||
| 2. The operating system and JavaScript runtime Express operates under, including its configuration and anything within the control of the operating system. | ||
| 3. The code it executes, comprising JavaScript and native code, even if dynamically loaded, such as dependencies installed from npm or similar repositories. |
There was a problem hiding this comment.
it seems strange to trust arbitrary plugins - this can be defended against.
There was a problem hiding this comment.
I agree here. What exactly do we mean by this in "real terms". Like what would be an outcome we expect to happen when triaging an issues where this would apply? Is it this "Malicious Third-Party Modules (CWE-1357)"?
There was a problem hiding this comment.
not true, express should trust the middleware not to be malicious, otherwise the plugin system would not work and express is not responsible of how a malicious plugin interacts
There was a problem hiding this comment.
Yeah this is why I am not sure I am clear on the distinction here. What you say @marco-ippolito makes sense, but this language is a bit "wide in scope" imo, just want to make sure I understand the goal.
There was a problem hiding this comment.
basically all of the express middleware I've written would be considered malicious from a security view 😃
There was a problem hiding this comment.
I too think its a good point.
Co-authored-by: Chris de Almeida <ctcpip@users.noreply.github.com>
|
this looks great, just some small edit suggestions. also, we should consider moving this to the |
Co-authored-by: Chris de Almeida <ctcpip@users.noreply.github.com>
Security.md
Outdated
|
|
||
| #### Prototype Pollution Attacks (CWE-1321) | ||
|
|
||
| * Express trusts the inputs provided by application code. Hence, scenarios necessitating control over user input are not considered vulnerabilities unless Express itself fails to sanitize the input properly. |
There was a problem hiding this comment.
Prototype pollution is not a sanitization issue.
In javascript, you can store arbitrary user-controlled data as a key of a javascript object in a safe way without any need for sanitization. If express is not doing that, it's worth asking why.
There was a problem hiding this comment.
There have been PP attacks which relied on missing input sanitization in the past, not that I am saying you are wrong, just that this can be caused by a few types of things. AFAIK all of those were addressed and closed out. Was this just speculation or trying to help find better wording for this section?
There was a problem hiding this comment.
Was this just speculation or trying to help find better wording for this section?
That was trying to clarify the intention behind this paragraph, and it was before I realized that it was copy-pasted from Node.js.
If express had PP issues, which were all addressed and fixed, then it shouldn't be in "not an issue" section, no?
But honestly, I think this document should be written from the ground up based on actual issues reported by people (in github and email). Threat models of a js runtime and js library are very different, and issues that node.js faced before aren't necessarily applicable here. (I also had "wtf" moment reading about uncontrolled paths trying to figure out how it's related to express - do people really report these?)
There was a problem hiding this comment.
That was trying to clarify the intention behind this paragraph, and it was before I realized that it was copy-pasted from Node.js.
Cool thanks! Just making sure I understood the intent since I was not sure my reply really addressed it.
then it shouldn't be in "not an issue" section, no? ... Threat models of a js runtime and js library are very different
Yeah that seems like a very relevant point! Hm. @UlisesGascon thoughts on this?
|
I guess this is ready to be merged |
|
I will merge this PR, the follow up can be found at expressjs/security-wg#3 (comment) As we plan to do more iterations soon, we just decided in a previous TC meeting to move the initiative to the security wg until is completed. |
This proposal is very open for debate and improvements, it is basically a fork from Node.js one (nodejs/node#45223).
I suggest you to review Node.js one first if you are not familiar with Threat models at all.
The main goal of this Threat Model is to provide a better support for Security Researches and for us on the triage. This Threat model can be considered as the "playbook rules" for reporting vulnerabilities into the project.
Note: Only the Threat Model is in scope of this PR. The
security.mdhas already existing elements that are going to change soon (see: expressjs/security-wg#7), so please keep the focus on the target.Context
Ref: expressjs/security-wg#3
Your feedback is more than appreciated: @bensternthal @ruddermann @ljharb @lirantal @mcollina @fraxken @expressjs/security-wg @expressjs/security-triage @expressjs/express-tc