Everyone would agree that security is very important and with the increase in cyber attacks in the recent past, organizations are investing\nheavily on application security. In this post lets talk about securing a web application built in NodeJS.
\nNOTE: The security concepts discussed here are language or framework agnostic. However, here we will see how these practices are implemented\nin NodeJS web applications.
\nIt is always a good practice to send your data over HTTPS rather than HTTP and it is imperative if your app transmits sensitive data.\nEncrypting data transmitted between the client and server helps mitigate several attacks like man-in-the-middle(MITM) attack, packet sniffing,\neavesdropping etc. Let’s see how to set up TLS/SSL in Express 4.x:
\nLets first generate a self-signed certificate:
\n$ openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365This generates a self-signed certificate valid for 365 days.
\nNOTE: The self-signed certificate is not ideal for production. For production, you should get a certificate from a Certificate Authority(CA).
\nNext, enable HTTPS on Express. Additionally, redirect all HTTP traffic to HTTPS:
\nconst fs = require('fs');\nconst https = require('https');\nconst express = require('express');\n\nconst NODE_ENV = process.env.NODE_ENV || 'development';\nconst PORT = process.env.PORT || 3443;\n\nconst app = express();\n\nhttps.createServer({\n key: fs.readFileSync('/path/to/key.pem'),\n cert: fs.readFileSync('/path/to/cert.pem')\n}, app).listen(PORT);\n\n// Redirect http requests to use https in production\nif (NODE_ENV === 'production') {\n app.use((req, res, next) => {\n if (req.header('x-forwarded-proto') !== 'https') {\n res.redirect(`https://${req.header('host')}${req.url}`);\n } else {\n next();\n }\n });\n}i) Strict-Transport-Security: The HTTP Strict Transport Security(HSTS) if set in the response header, tells the browser that it should only communicate using HTTPS instead of HTTP while communicating with the specified domain.
\nSyntax:
\nStrict-Transport-Security: max-age=<expire-time>
Here, max-age is the time(in secs) that the browser should remember that this site is only to be accessed using HTTPS.
\nExample: from facebook.com:
\nstrict-transport-security:max-age=15552000;
ii) X-Frame-Options: This HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe> or <object>. Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites.
Syntax:
\nX-Frame-Options: DENY\nX-Frame-Options: SAMEORIGIN\nX-Frame-Options: ALLOW-FROM https://siteutrust.com/iii) X-XSS-Protection: This HTTP response header enables the built-in XSS filter in modern browsers.
\nExample:
\nX-XSS-Protection: 1
iv) X-Content-Type-Options: This response HTTP header is a marker used by the server to indicate that the MIME types advertised in the Content-Type headers should not be changed and be followed. This prevents MIME type sniffing attacks.
\nSyntax:
\nX-Content-Type-Options: nosniff
v) Content-Security-Policy: Prevents a range of injection attacks including Cross Site Scripting(XSS) attack.
\nSyntax:
\nContent-Security-Policy: policy
For a detailed explanation of CSP, go through this link.
\nTo set these headers in NodeJS, use the helmet npm package:
\nconst express = require('express');\nconst helmet = require('helmet');\n\nconst app = express();\n\n<b>app.use(helmet())</b>This sets all the necessary headers in response.
\nTo set the headers individually:
\napp.use(helmet({\n frameguard: {\n action: 'deny'\n }\n}));For an exhaustive list of security headers that should be set in a web application, check out the OWASP Secure Headers Project.
\nNOTE: In some web servers, the security headers can be set in the server configuration file itself. For example, in nginx server, we can set the above headers in nginx.conf as shown below:
\nadd_header X-Frame-Options DENY;\nadd_header X-Content-Type-Options nosniff;\nadd_header X-XSS-Protection 1;\nadd_header Content-Security-Policy \"default-src 'self'\";Cross site request forgery (CSRF), also known as XSRF, Sea Surf or Session Riding, is an attack vector that tricks a web browser into executing an unwanted action in an application to which a user is logged in. CSRF attacks specially targets state-changing requests and can force the victim to transfer funds, change email/password and so on.
\nCSRFs are typically conducted using social engineering, such as an email or link that tricks the victim into sending a request to a server on behalf of the attacker. The server has no way to distinguish a forged request from a genuine one.
\nIn NodeJS, to prevent CSRF attack, we usually use the csurf express middleware:
\nconst cookieParser = require('cookie-parser');\nconst csrf = require('csurf');\nconst bodyParser = require('body-parser');\nconst express = require('express');\n\nconst csrfProtection = csrf({ cookie: true });\nconst parseForm = bodyParser.urlencoded({ extended: false });\n\n// create express app\nconst app = express();\n\n// we need this because \"cookie\" is true in csrfProtection\napp.use(cookieParser());\n\napp.get('/form', csrfProtection, (req, res) => {\n // pass the csrfToken to the view\n res.render('send', { csrfToken: req.csrfToken() });\n});In the view use the CSRF token passed:
\n<form action=\"/process\" method=\"POST\">\n <input type=\"hidden\" name=\"csrf_token\" value=\"{{csrfToken}}\">\n\n Enter amount: <input type=\"number\" name=\"amount\">\n <button type=\"submit\">Submit</button>\n\n</form>Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted web sites.\nAn attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not\nbe trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.
\nThe thumb rule to prevent this category of attack is to always validate and sanitize user data before processing or storing in database. Never trust data coming from user.\nValidation must be done on the server-side as client-side validation can be easily bypassed using tools such as Burp Suite, TamperData etc.
\nA common approach to validate and sanitize user data is to use a library like validator.js.
\nExample: To validate an email
\nimport validator from 'validator';\n\nif(validator.isEmail('foo@bar.com')) {\n // Process email or store in DB\n}This library provides a number of validators and sanitizers to filter user inputs.
\nOther useful libraries include DOMPurify and xss-filters.
\nHere is an example to sanitize user input using xss-filters:
\nconst express = require('express');\nconst app = express();\nconst xssFilters = require('xss-filters');\n\napp.get('/', (req, res) => {\n let firstname = req.query.firstname; //an untrusted input\n res.send('<h1> Hello, ' + xssFilters.inHTMLData(firstname) + '!</h1>');\n});\n\napp.listen(3000);Passing unvalidated user input directly to a SQL statement is vulnerable to SQL injection attack.
\nConside the following example:
\n// SQL query vulnerable to SQLi\nsql = \"SELECT * FROM users WHERE username='\" + username + \"' AND password='\" + password + \"'\";\n\n// Execute the SQL statement\ndatabase.execute(sql)Now suppose the user enters the following in the username field:
\n' OR '1'='1' --
The above SQL statement becomes:
\nsql = \"SELECT * FROM users WHERE username='\" + ' OR 1=1 -- + \"' AND password='\" + password + \"'\";This effectively nullifies the need of a password and returns all the users in the database.
\nThis attack can be completely prevented by using parametrized or prepared statement.
\nIf you’re using an ORM to access the database (Mongoose, Sequelize etc), the ORM will normally take care of SQL injection by using prepared statements under the hood.
\nXSS vulnerability in an application can be used to steal browser cookies. To prevent cookie stealing we can set the httpOnly flag of the cookie.\nAdditionaly, we can tell the browser to send cookies only over HTTPS using the secure flag.
\nsecure : this attribute tells the browser to only send the cookie if the request is being sent over HTTPS.
\nHttpOnly : this attribute is used to help prevent attacks such as cross-site scripting, since it does not allow the cookie to be accessed via JavaScript.
\nExample:
\napp.use(session({\n secret: ‘My super secret’,\n <b>cookie: { httpOnly: true, secure: true }</b>\n}));To prevent our site from overwhelming with a large number of requests, we need to put some kind of rate limiting to our API.
\nWe can use the ratelimiter npm package to implement rate limiting. If you are using Express, the express-rate-limit middleware can be used as shown below:
\nconst RateLimit = require('express-rate-limit');\n\nconst limiter = new RateLimit({\n windowMs: 15*60*1000, // 15 minutes\n max: 100, // limit each IP to 100 requests per windowMs\n delayMs: 0 // disable delaying — full speed until the max limit is reached\n});\n\n// apply to all requests\napp.use(limiter);Any error in the application should be handled gracefully by showing a custom error page to the user instead of showing stack trace in the error page\nthereby leaking sensitive infrastructure information like server info.
\ni) The Node Security Project\nTo check the various npm modules for known vulnerabilities, the Node Security Project provides the nsp tool to check for vulnerabilities:
\n$ nsp checkii) Synk\nSynk checks the application against Snyk’s open source vulnerability database for any known vulnerabilities in our dependencies.
\n$ npm install -g snyk\n$ cd your-app\n$ snyk testiii) nmap\nNmap (“Network Mapper”) is a free and open source utility for network exploration or security auditing.
\niv) sqlmap\nsqlmap is an open source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and taking over of database servers.
\nv) Burp Suite\nThe must-have tool for application penetration testing. It includes an automated scanner to detect most common vulnerabilities in a web application.
\n