Goof - Snyk's vulnerable demo app
A vulnerable Node.js demo application, based on the Dreamers Lab tutorial.
Features
This vulnerable app includes the following capabilities to experiment with:
- Exploitable packages with known vulnerabilities
- Docker Image Scanning for base images with known vulnerabilities in system libraries
- Runtime alerts for detecting an invocation of vulnerable functions in open source dependencies
Running
mongod &
git clone https://github.com/Snyk/snyk-demo-todo
npm install
npm start
This will run Goof locally, using a local mongo on the default port and listening on port 3001 (http://localhost:3001)
Running with docker-compose
docker-compose up --build
docker-compose down
Heroku usage
Goof requires attaching a MongoLab service to be deployed as a Heroku app. That sets up the MONGOLAB_URI env var so everything after should just work.
CloudFoundry usage
Goof requires attaching a MongoLab service and naming it "goof-mongo" to be deployed on CloudFoundry. The code explicitly looks for credentials to that service.
Cleanup
To bulk delete the current list of TODO items from the DB run:
npm run cleanup
Exploiting the vulnerabilities
This app uses npm dependencies holding known vulnerabilities, as well as insecure code that introduces code-level vulnerabilities.
The exploits/
directory includes a series of steps to demonstrate each one.
Vulnerabilities in open source dependencies
Here are the exploitable vulnerable packages:
- Mongoose - Buffer Memory Exposure - requires a version <= Node.js 8. For the exploit demo purposes, one can update the Dockerfile
node
base image to useFROM node:6-stretch
. - st - Directory Traversal
- ms - ReDoS
- marked - XSS
Vulnerabilities in code
- Open Redirect
- NoSQL Injection
- Code Injection
- Command execution
- Cross-site Scripting (XSS)
- Information exposure
- Security misconfiguration exposes server information
- Insecure protocol (HTTP) communication
Code injection
The page at /account_details
is rendered as an Handlebars view.
The same view is used for both the GET request which shows the account details, as well as the form itself for a POST request which updates the account details. A so-called Server-side Rendering.
The form is completely functional. The way it works is, it receives the profile information from the req.body
and passes it, as-is to the template. This however means, that the attacker is able to control a variable that flows directly from the request into the view template library.
You'd think that what's the worst that can happen because we use a validation to confirm the expected input, however the validation doesn't take into account a new field that can be added to the object, such as layout
, which when passed to a template language, could lead to Local File Inclusion (Path Traversal) vulnerabilities. Here is a proof-of-concept showing it:
curl -X 'POST' -H 'Content-Type: application/json' --data-binary $'{"layout": "./../package.json"}' 'http://localhost:3001/account_details'
Actually, there's even another vulnerability in this code.
The validator
library that we use has several known regular expression denial of service vulnerabilities. One of them, is associated with the email regex, which if validated with the {allow_display_name: true}
option then we can trigger a denial of service for this route:
curl -X 'POST' -H 'Content-Type: application/json' --data-binary "{\"email\": \"`seq -s "" -f "<" 100000`\"}" 'http://localhost:3001/account_details'
The validator.rtrim()
sanitizer is also vulnerable, and we can use this to create a similar denial of service attack:
curl -X 'POST' -H 'Content-Type: application/json' --data-binary "{\"email\": \"[email protected]\", \"country\": \"nop\", \"phone\": \"0501234123\", \"lastname\": \"nop\", \"firstname\": \"`node -e 'console.log(" ".repeat(100000) + "!")'`\"}" 'http://localhost:3001/account_details'
Open redirect
The /admin
view introduces a redirectPage
query path, as follows in the admin view:
<input type="hidden" name="redirectPage" value="<%- redirectPage %>" />
One fault here is that the redirectPage
is rendered as raw HTML and not properly escaped, because it uses <%- >
instead of <%= >
. That itself, introduces a Cross-site Scripting (XSS) vulnerability via:
http://localhost:3001/login?redirectPage="><script>alert(1)</script>
To exploit the open redirect, simply provide a URL such as redirectPage=https://google.com
which exploits the fact that the code doesn't enforce local URLs in index.js:72
.
Hardcoded values - session information
The application initializes a cookie-based session on app.js:40
as follows:
app.use(session({
secret: 'keyboard cat',
name: 'connect.sid',
cookie: { secure: true }
}))
As you can see, the session secret
used to sign the session is a hardcoded sensitive information inside the code.
First attempt to fix it, can be to move it out to a config file such as:
module.exports = {
cookieSecret: `keyboard cat`
}
And then require the configuration file and use it to initialize the session. However, that still maintains the secret information inside another file, and Snyk Code will warn you about it.
Another case we can discuss here in session management, is that the cookie setting is initialized with secure: true
which means it will only be transmitted over HTTPS connections. However, there's no httpOnly
flag set to true, which means that the default false value of it makes the cookie accessible via JavaScript. Snyk Code highlights this potential security misconfiguration so we can fix it. We can note that Snyk Code shows this as a quality information, and not as a security error.
Docker Image Scanning
The Dockerfile
makes use of a base image (node:6-stretch
) that is known to have system libraries with vulnerabilities.
To scan the image for vulnerabilities, run:
snyk test --docker node:6-stretch --file=Dockerfile
To monitor this image and receive alerts with Snyk:
snyk monitor --docker node:6-stretch
Runtime Alerts
Snyk provides the ability to monitor application runtime behavior and detect an invocation of a function is known to be vulnerable and used within open source dependencies that the application makes use of.
The agent is installed and initialized in app.js.
For the agent to report back to your snyk account on the vulnerabilities it detected it needs to know which project on Snyk to associate with the monitoring. Due to that, we need to provide it with the project id through an environment variable SNYK_PROJECT_ID
To run the Node.js app with runtime monitoring:
SNYK_PROJECT_ID=<PROJECT_ID> npm start
** The app will continue to work normally even if not provided a project id
Fixing the issues
To find these flaws in this application (and in your own apps), run:
npm install -g snyk
snyk wizard
In this application, the default snyk wizard
answers will fix all the issues.
When the wizard is done, restart the application and run the exploits again to confirm they are fixed.