Skip to main content

Insecure Configuration

This vulnerability category covers the following issues:

Why is this important?​

With JavaScript applications, especially when leveraging open source libraries, there are ways to introduce configuration issues. This page describes vulnerabilities that can be identified by GuardRails.

Check out this video for a high-level explanation:

Security Misconfiguration

Cross-Origin Resource Sharing​

Prior to HTML5, Web browsers enforced the Same Origin Policy which ensures that in order for JavaScript to access the contents of a Web page, both the JavaScript and the Web page must originate from the same domain. Without the Same Origin Policy, a malicious website could serve up JavaScript that loads \sensitive information from other websites using a client's credentials, cull through it, and communicate it back to the attacker. HTML5 makes it possible for JavaScript to access data across domains if a new HTTP header called Access-Control-Allow-Origin is defined. With this header, a Web server defines which other domains are allowed to access its domain using cross-origin requests. However, caution should be taken when defining the header because an overly permissive CORS policy will allow a malicious application to communicate with the victim application in an inappropriate way, leading to spoofing, data theft, relay and other attacks.

References:

Set a proper Cross-Origin Resource Sharing (CORS) policy​

  1. Go through the issues that GuardRails identified in the PR
  2. Remove the code that sets the Access-Control-Allow-Origin header with a *
  3. And add your domain name instead of the *
  4. Test it
  5. Ship it 🚒 and relax 🌴

Cookies support the secure and httpOnly flags. The secure flag is a directive to the browser to make sure that the cookie is not sent over an unencrypted channel. The httpOnly flag prevents JavaScript to access its value. Which helps to reduce the risk of β€œCross-Site Scripting” attacks.

References:

  1. Go through the issues that GuardRails identified in the PR

  2. Locate the pattern that either sets the secure or httpOnly flags to false, or doesn't set the values at all

  3. And modify it to set both flags, for example in Express:

    app.use(session({
    cookie: {
    secure: true,
    httpOnly: true
    }
    }))
  4. Test it, ship it 🚒 and relax 🌴

Security Headers​

HTTP security headers provide yet another layer of security by helping to prevent certain attacks and security vulnerabilities. These are simple to implement and have a range of benefits to protect your users.

References:

Fixing Security Headers​

Option A: Ensure Helmet is configured correctly​

  1. Go through the issues that GuardRails identified in the PR

  2. Locate the endpoint with the following pattern:

    app.use(
    helmet({
    hsts:: false,
    })
    );
  3. And ensure that they are enabled, unless there is a very good reason to do so

  4. Test it by checking your URL at SecurityHeaders.io

  5. Ship it 🚒 and relax 🌴

Option B: Ensure XSS Security Headers are enabled​

  1. Go through the issues that GuardRails identified in the PR

  2. Identify the code with one of these patterns:

    // XSS Security Headers
    lusca.xssProtection(false);
    X-XSS-Protection = 0;
  3. And ensure the headers are enabled. Note: It may be possible that this is handled on the loadbalancers or webservers

  4. Test it, ship it 🚒 and relax 🌴

Framework Security Settings​

Secure Electron Configuration​

Option A: Enable webSecurity​

Disabling webSecurity will disable the same-origin policy and allows the execution of insecure code from any domain.

  1. Go through the issues that GuardRails identified in the PR

  2. Locate the following pattern:

    const config = {
    webPreferences: {
    webSecurity: false
    }
    });
  3. And set webSecurity to true

  4. Test it, ship it 🚒 and relax 🌴

Option B: Disable nodeIntegration​

An electron app that has Node integration enabled and vulnerable to Cross-Site Scripting, can be abused to execute code remotely vulnerabilities on the application.

  1. Go through the issues that GuardRails identified in the PR

  2. Locate the following pattern:

    const mainWindow = new BrowserWindow({
    webPreferences: {
    nodeIntegration: true,
    nodeIntegrationInWorker: true
    }
    })
  3. And set nodeIntegration to false

  4. Test it, ship it 🚒 and relax 🌴

More information:​