![\"Community](\"https://i.postimg.cc/kMLNzY3y/Picture1.png\")
At AUTO1, we rely on Terraform to manage our cloud infrastructure. And of course, we are trying to pay close attention to its security posture. Over time we realized that relying solely on reactive methods, such as AWS Config and Security Hub, to identify and combat misconfigurations in our AWS services wasn't sufficient. It was imperative for us to shift left in our infrastructure development cycle to avoid repeating the same misconfigurations over and over again. In this blog post, we'll be discussing the journey of how we implemented security scans for our Terraform code.
\nIdea would be to introduce some sort of security tool, that would scan all of our changes introduced in the infrastructure codebase and report on security finding. Based on that we could eventually start to prevent merge of PRs that contain some of the most critical misconfigurations. That way we wouldn't have to chase the same Security Hun findings all of the time.
\nTo ensure successful implementation of Terraform security scanning, we needed to address two key questions:
\nAre we fully prepared to incorporate Terraform security scanners into our daily operations, even if it means potential blocks on some of our changes?
\nIf yes, then which one would be the best fit for our requirements?
\nTo answer these questions, we had to formulate specific criteria that the security scanning tool had to meet.
\n| # | \nOur ideal terraform security scanner... | \nImportance | \n
|---|---|---|
| 1 | \nis able to perform various security checks on the terraform code for the majority of important AWS services (including custom checks: encryption, IAM, public resources, etc. | \nCRITICAL | \n
| 2 | \ncan be integrated into our development cycle for different repositories via Github Actions | \nCRITICAL | \n
| 3 | \ncan be run on self-hosted Github runners | \nHIGH | \n
| 4 | \nhas capability to configure different conditions to fail or pass checks (for example severity of the finding) | \nMEDIUM | \n
| 5 | \nhas capability to suppress findings directly inline in code | \nHIGH | \n
| 6 | \nhas good readability of the scan results | \nMEDIUM | \n
| 7 | \ncan be integrated into AWS Security Hub or AWS Inspector (or some other centralized view for analysis, like DefectDojo) | \nLOW | \n
| 8 | \nhas an open source community version | \nHIGH | \n
| 9 | \nhas good documentation, including mitigation recipes for found misconfigurations | \nLOW | \n
| 10 | \nshould take as little time as possible to scan target modules | \nMEDIUM | \n
| 11 | \ncan scan external terraform modules (local or on Github) | \nLOW | \n
| 12 | \ncan scan single files, not only directories | \nLOW | \n
I think all of the criteria are pretty self-explanatory. Assigned 'importance' will come into play later, for now it just should be noted that of course chosen criteria and assigned values are mostly subjective and very team-dependent — for our specific case this outline was close enough.
\nWith goals and criteria of PoC figured out, we had to round up some contenders.
\n
We started by conducting an initial assessment of the available Terraform security scanning tools. Based mostly on community adoption, we compiled a longlist of contenders, which included:
\nHere it is important to know that PoC took place in the second part of 2022, so our observations and conclusions were made based on the versions of these tools that were available at the time.
\nThe initial assessment was rather straightforward. It involved installing each tool, scanning a Terraform module that was part of our infrastructure, and evaluating the scan results. Based on the results of the evaluation (which basically boiled down to briefly looking at the produced report and comparing it to the results generated by other tools), we narrowed down the list to the following contenders:
\nThe ones that didn't make the cut either:
\nwere producing non-satisfactory scan results:
\nAt the same time all the tools that we chose to shortlist looked pretty great. So, now we had to test each of them properly in order to decide which one would win.
\nTo properly evaluate the shortlisted tools, we decided to integrate them into our main infrastructure repository as Github Workflows.
\nThis way we would gather relevant statistics very quickly and at the same time get a taste of the new way of implementing changes.
\nGithub Workflows is an automation tool that is integrated within the Github platform. These workflows allow you to automate a variety of tasks, such as building and testing your code, releasing software updates, and more. Workflows are defined in a specific file format called YAML, which is stored in your Github repository. The workflows are triggered by specific events, such as a code push or a pull request, and they can run a series of actions in response to these events. These actions can be anything from running a set of commands, to integrating with external tools and services.
\nTypical workflow in our case looked roughly like this:
\nname: tfsec\non:\n pull_request:\n\njobs:\n tfsec:\n name: tfsec\n runs-on: ubuntu-latest\n\n steps:\n - name: Checkout\n uses: actions/checkout@v3\n with:\n fetch-depth: 0\n\n - name: Get changed files\n id: changed-files\n uses: tj-actions/changed-files@v35\n with:\n dir_names: true\n\n - name: Install tfsec\n continue-on-error: true\n run: |\n wget -O - -q "$(wget -q https://api.github.com/repos/aquasecurity/tfsec/releases/latest -O - | grep -o -E "https://.+?tfsec-linux-amd64" | head -n1)" > tfsec\n install tfsec /usr/local/bin/\n tfsec --version\n\n - name: Setup SSH Keys and known_hosts\n env:\n SSH_AUTH_SOCK: /tmp/ssh_agent.sock\n continue-on-error: true\n run: |\n ssh-agent -a $SSH_AUTH_SOCK > /dev/null\n ssh-add - <<< "${{ secrets.TERRASCAN_SSH_KEY }}"\n\n - name: tfsec Security Scan\n env:\n SSH_AUTH_SOCK: /tmp/ssh_agent.sock\n TERM: xterm-color\n continue-on-error: true\n run: |\n for directory in ${{ steps.changed-files.outputs.all_changed_files }}; do\n echo "$(tput setaf 2) Currently scanning module: $directory"\n tfsec $directory --soft-fail || true\n done\n\n - name: Post scan message\n continue-on-error: true\n run: |\n cat << EOF\n If security scan found misconfigurations in the code,\n please either try to fix them or create inline ignore comments for the\n appropriate resources.\n\n Format:\n (Place comment before resource code block or in the offending line)\n #tfsec:ignore:<rule>\n\n Rule identificators are specified in the scan results.\n\n More about tfsecs format can be found here:\n https://aquasecurity.github.io/tfsec/v1.27.4/guides/configuration/ignores/\n EOFLet's go over it bit by bit to explain what exactly is going on here:
\nname: tfsec\non:\n pull_request:\n\njobs:\n tfsec:\n name: tfsec\n runs-on: ubuntu-latestIn the beginning we need to define the name of the workflow (\"tfsec\"), its trigger (in our case — only opening or changing PRs) and where it will run. In this case it will run on Github Managed runners, but it is possible to integrate your own runners deployed, for example, in AWS — then we'd have to reference them using a specific name tag.
\nIn this case we defined only one job with multiple steps.
\nHere they are:
\n steps:\n - name: Checkout\n uses: actions/checkout@v3\n with:\n fetch-depth: 0Pretty standard, we use another Github Action (provided by Github in this case) to checkout target repo.
\n - name: Get changed files\n id: changed-files\n uses: tj-actions/changed-files@v35\n with:\n dir_names: trueHere is the attempt to optimize our process. So, obviously when we started this PoC, we already had a pretty sizable terraform repo on our hands. For that reason, it didn't make a lot of sense (and also would be kind of unfair to a person that wants to make some small change to a specific module) to scan the whole repo and report on it each time someone creates a new PR. So here we use another awesome action to limit our scan to only changed modules. dir_names option indicates that we get only names of the directories that hold changed files, not the filenames themselves. This is used here because tfsec expect scanning path to be a single directory. For tools, that can scan separate files, we would disable this option to optimize scope.
\n - name: Install tfsec\n continue-on-error: true\n run: |\n wget -O - -q "$(wget -q https://api.github.com/repos/aquasecurity/tfsec/releases/latest -O - | grep -o -E "https://.+?tfsec-linux-amd64" | head -n1)" > tfsec\n install tfsec /usr/local/bin/\n tfsec --versionThis one is pretty self-explanatory. We need to download and install the latest version of the required tool.
\n - name: Setup SSH Keys and known_hosts\n env:\n SSH_AUTH_SOCK: /tmp/ssh_agent.sock\n continue-on-error: true\n run: |\n ssh-agent -a $SSH_AUTH_SOCK > /dev/null\n ssh-add - <<< "${{ secrets.TERRASCAN_SSH_KEY }}"This one is actually pretty tool and environment specific. It's relevant for tools that can scan modules that are being sourced from Github repos. Here we allow runners to use previously created SSH key, authorized to pull those modules.
\n - name: tfsec Security Scan\n env:\n SSH_AUTH_SOCK: /tmp/ssh_agent.sock\n TERM: xterm-color\n continue-on-error: true\n run: |\n for directory in ${{ steps.changed-files.outputs.all_changed_files }}; do\n echo "$(tput setaf 2) Currently scanning module: $directory"\n tfsec $directory --soft-fail || true\n doneFinally, we can scan code. We use a list of changed directories, found by one the previous steps, and just iterate through, launching the security tool to scan each one.
\nLast part would be just a message to hint at the next possible steps for the engineers. In our case it was just a link to the documentation.
\nOne important thing. You might have noticed that almost in every step we use this option:
\ncontinue-on-error: trueIt was really crucial at this stage to not block work of the engineers under any circumstances. This option ensured that even if some step of the workflow would fail or produce security finding, it wouldn't block the PR.
\nBecause we wanted to compare all three scanners simultaneously to ensure that our observations were always in the same context, we had to construct a workflow for each one and activate them in our repository. Workflows looked roughly the same with small adjustments specific for each tool. After implementation was done it was time for the team members to continue to write code, push PRs and that way generate more and more scan results. For those who were directly responsible for the PoC it was time to perform some tests against formulated success criteria based on accumulated statistics.
\nBased on the accumulated scan results we tried to estimate how well each tool complies with our requirements.
\nBoiled down results are listed below. We tried to make them at least a bit self-explanatory so we could be able to reference them in the future, when someone will inevitably ask: \"Does anybody remember why we chose this scanner over that scanner?\".
\nWe listed previously defined criteria and assigned numeric value to their importance characteristic:
\nThen based on our observations we graded every tool, basically evaluating compliance of each tool to every criterion. Grades multiplied by importance got us numeric results that we could use to objectively compare contenders. Below are the results supplemented by the comments, intended to justify each grade. For better readability you can check out this Google sheet.
\n\nIn the end we chose KICS as our terraform security scanner. Honestly, I believe that we'd have chosen it even if it wouldn't score highest in our internal test rating (but it also helped to reach the decision, of course). Reason for that would be that basically with the same scanning quality as other just these two KICS's killer-features:
\nmade it the most appealing candidate. It is now integrated to all of our terraform repositories (more than a 100 in total). It scans every PR we make, reports on it and blocks them if any of the findings were classified with severity \"high\" (highest in the KICS terminology).
\nAs for the initial goal — to make our infrastructure a bit more secure — I believe KICS has indeed assisted us with that quite well. Sometimes we just fix one small existing or newly introduced misconfiguration and go on with our day. But sometimes we find something that turns into an epic with dozens of tickets that cover hundreds and hundreds of our resources and services. Both scenarios are great and valuable in the end. Additionally, it spreads awareness across all of the DevOps team about available security options of various AWS services and in general more secure ways to use them (at least I really hope so). Taking all this into account, the effort was well worth it and I think we will continue to benefit from it further and further.
\nThank you for reading!
","fields":{"slug":"/terraform-security-scanners/","tags":["security","terraform","DevOps","DevSecOps"]}}},{"node":{"id":"c61acf9d-7746-503a-ba8f-cf96f4042096","frontmatter":{"category":"Coding","title":"Secure coding practices for NodeJS Web Applications","date":"2018-06-20","summary":"This post highlights various coding practices for securing a NodeJS web application against the most critical web attacks.","thumbnail":{"relativePath":"pages/securing-nodejs-applications/thumbnail.jpeg","childImageSharp":{"resolutions":{"base64":"data:image/jpeg;base64,/9j/2wBDABALDA4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVGC8aGi9jQjhCY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2P/wgARCAAIABQDASIAAhEBAxEB/8QAFwABAAMAAAAAAAAAAAAAAAAAAAECBf/EABUBAQEAAAAAAAAAAAAAAAAAAAEC/9oADAMBAAIQAxAAAAHMkZoCv//EABUQAQEAAAAAAAAAAAAAAAAAAAAS/9oACAEBAAEFApSl/8QAFREBAQAAAAAAAAAAAAAAAAAAARD/2gAIAQMBAT8BJ//EABURAQEAAAAAAAAAAAAAAAAAAAEQ/9oACAECAQE/AWf/xAAXEAADAQAAAAAAAAAAAAAAAAAAECEx/9oACAEBAAY/AoYv/8QAGhABAAIDAQAAAAAAAAAAAAAAAQARIUFxUf/aAAgBAQABPyHOqLFGlciV85P/2gAMAwEAAgADAAAAEHvP/8QAFhEBAQEAAAAAAAAAAAAAAAAAARAh/9oACAEDAQE/EAJs/8QAFhEBAQEAAAAAAAAAAAAAAAAAARAR/9oACAECAQE/EFjP/8QAHBABAAEEAwAAAAAAAAAAAAAAASEAETFxUWHw/9oACAEBAAE/EMpW8q+4qwMgymddUsU0EV//2Q==","width":867,"height":325,"src":"/static/f21842b8ed2aa0a1b2cd57f6dbf9e7fc/a2998/thumbnail.jpeg","srcSet":"/static/f21842b8ed2aa0a1b2cd57f6dbf9e7fc/a2998/thumbnail.jpeg 1x"}}},"authorName":"Rajababu Pradhan","authorDescription":"Raja is Senior Frontend Engineer at AUTO1 Group.","authorAvatar":{"relativePath":"pages/securing-nodejs-applications/avatar.png","childImageSharp":{"resolutions":{"base64":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAACXBIWXMAAAsSAAALEgHS3X78AAACyElEQVQ4y4VUO2gUURR9mZmN8YcItoKVjeXuzsxu9jOzm92NkBBTqDEmjZAEgtqIpSgI1gp+uhS6kEI7wc7GQsFCLERiISGCaGHhF02yu+M5s/cujyC4cJY379573r3n3XdNvV51xsYiJ4rKbqlUyBj8wjAYyWazp4BVYB3YAraBDeAhMBcE/l76lkrFTLVachuNyCGXEbJMrVbx6ADnaWAtn88nvu8nWBMdQcJ9Auv3wCxjWq2aC9IMSF3DzCyyG1YAs9pSYkL2melmLpfT71tKGkUlz2iZJAuCgA5dEjGAwPoV0AbuAy+tfR7YkZjb5CiXR1OutEw5jWQdCfgCnEiSxNg/7LWAj+KTSiHSzBvrAtascrriPCmnDkP4AYQ0Em3TGPHf8P38ARpP/4PsHQ7aU69Hqdi4OJeI47JXLg9IX1tVbUuWCzSsygcJO+L0goGNRpySoB1colarerhEvcCn4tuxCB/TsC5ZdS3Ct2Ho75uZmRoigWbIbgCxt7Q0O8TLsgg17o2R2+JHzzJcV/1IoBlybel42SLsCcc3I6UqoaZ+lUHFYjjCzJSQa+4J4UVLKiX8ScOGVXJXDN+xd7SfZXFYS65U+n2Wz+cOw+ezHadSkfCRdVJiZdlmMG9ZtHMpgWR3Z0eMSvWExjmrbXoCbZ951dIim7Yk6u1IYtlwavChW51Pp01tXOwf01eC9RHs/Rbbnx2Hf4IUh/Q5zdol8H3KG22Pj9edOK54LF1876pd37TELhqdZ+J4MwxDHUvXgDOFQrB7YqLpjI4WdhG8GLYNbCeBK/1+TWNWRG+Pfy5Hj5Dek3IXzX9+8DkL/AIeLC/PDU1NHXdSQk5altNsDkjPAT+ArzKyFnK5bB2IxbYik4hanmfM5GTL6Q/Y2DUc25y0HLToubR8TI39cL4APJOxr/35AXgOXEJnHKQvepP6eiQj119kDrZjqLo8HAAAAABJRU5ErkJggg==","width":50,"height":50,"src":"/static/26a7a327ccc4b335712e5a7086f2b26d/45876/avatar.png","srcSet":"/static/26a7a327ccc4b335712e5a7086f2b26d/45876/avatar.png 1x,\n/static/26a7a327ccc4b335712e5a7086f2b26d/eb85b/avatar.png 1.5x,\n/static/26a7a327ccc4b335712e5a7086f2b26d/4f71c/avatar.png 2x,\n/static/26a7a327ccc4b335712e5a7086f2b26d/9ec3e/avatar.png 3x"}}},"headerImage":{"relativePath":"pages/securing-nodejs-applications/header-image.jpeg","childImageSharp":{"resolutions":{"base64":"data:image/jpeg;base64,/9j/2wBDABALDA4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVGC8aGi9jQjhCY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2P/wgARCAAIABQDASIAAhEBAxEB/8QAFwABAAMAAAAAAAAAAAAAAAAAAAECBf/EABUBAQEAAAAAAAAAAAAAAAAAAAEC/9oADAMBAAIQAxAAAAHMkZoCv//EABUQAQEAAAAAAAAAAAAAAAAAAAAS/9oACAEBAAEFApSl/8QAFREBAQAAAAAAAAAAAAAAAAAAARD/2gAIAQMBAT8BJ//EABURAQEAAAAAAAAAAAAAAAAAAAEQ/9oACAECAQE/AWf/xAAXEAADAQAAAAAAAAAAAAAAAAAAECEx/9oACAEBAAY/AoYv/8QAGhABAAIDAQAAAAAAAAAAAAAAAQARIUFxUf/aAAgBAQABPyHOqLFGlciV85P/2gAMAwEAAgADAAAAEHvP/8QAFhEBAQEAAAAAAAAAAAAAAAAAARAh/9oACAEDAQE/EAJs/8QAFhEBAQEAAAAAAAAAAAAAAAAAARAR/9oACAECAQE/EFjP/8QAHBABAAEEAwAAAAAAAAAAAAAAASEAETFxUWHw/9oACAEBAAE/EMpW8q+4qwMgymddUsU0EV//2Q==","width":1200,"height":450,"src":"/static/f21842b8ed2aa0a1b2cd57f6dbf9e7fc/935ac/header-image.jpeg","srcSet":"/static/f21842b8ed2aa0a1b2cd57f6dbf9e7fc/935ac/header-image.jpeg 1x"}}}},"html":"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