DEV Community: Marcin Hoppe

Abusing the Type System

Marcin Hoppe — Tue, 15 Sep 2020 07:14:39 +0000

I learned to write computer programs before JavaScript was created. The languages used in schools back then were mainly C and Pascal. They taught me that each variable has a specific type, such as integer or string, and that this type determines the operations that can be performed on a variable.

JavaScript is a bit different.

Types

JavaScript also has types. Variables can refer to numbers, strings, Boolean values, objects, symbols, and special values such as undefined and null.

Dynamic typing

Unlike C and Pascal, JavaScript variables can hold values of different types throughout their lifetime. A variable can be a number in one execution scenario and a string in another one. This makes it difficult to analyze how the program works just by reading its source code.

Weak typing

Operators work on values. For example, the + operator adds two numbers together or concatenates two strings. In C and Pascal, you cannot add a number to a string. This operation is undefined, and you need to convert one of the variables to a different type.

JavaScript will do its best to convert the operands implicitly, often in surprising ways.

Comparing objects of different types

JavaScript has two comparison operators:

Strict comparison (===) compares both the value and the type. If the compared values have different types, it will return false. This is what we would intuitively expect from a comparison operator.
Loose comparison (==) tries to automatically convert the operands to a common type to make the comparison possible. The rules of the conversions are complex and can be confusing for newcomers. Who would expect that the special value null can be equal to another special value undefined?

Both dynamic and weak typing allow JavaScript programs to be very flexible and succinct, but they may also lead to security problems.

Searching based on dynamic criteria

The dynamic nature of JavaScript makes it possible to implement algorithms that work on different types of data, including objects with different properties.

Let’s try to implement an HTTP endpoint that allows searching for objects in an array based on an arbitrary field and value and see how the type system can help us make the code as generic as possible. This will help us reuse it for different types of objects, and different types of search fields.

Our sample will use the Express framework to deal with details of handling HTTP requests but you don’t need to know Express in-depth to understand the code.

Search example

In our example, we will search the array of objects representing users. The search parameters will be passed as query string parameters. The callers will pass an object property name in the field parameter, and the search value in the value parameter. This way one endpoint can support multiple different search criteria.

The sample HTTP request and response could look like this:

GET /profile?field=email&value=joe%40wiredbraincoffee.com HTTP/1.1
Host: localhost:3000
Connection: keep-alive
Accept: */*

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 120
Connection: keep-alive

[{"email":"joe@wiredbraincoffee.com","password":"coldbrew","address":"1235 Wired Brain Blvd\r\nAwesome City, MM 55555"}]

Handler

The HTTP handler code is quite generic:

const users = require('./users');

function readProfile(req, res) {
    // Get search params
    const [field, value] = getParams(req.query, ['field', 'value']);
    // Find user(s)
    const results = filter(users, field, value);
    res.json(results);
}

First, we import the users array from a separate module. The readProfile function implements the search algorithm and conforms to Express conventions of taking the HTTP request and response objects as parameters.

Here is where the fun begins: we grab the values of field and value query string parameters and use those values to search the users array to find objects that have the property stored in the field variable with the value equal to the value variable.

Utility functions

The readProfile implementation looks simple, but the bulk of the work happens in the filter function:

// Return items where a field has specific value
function filter(items, field, value) {
    const results = [];
    for (let i = 0; i < items.length; ++i) {
        if (items[i][field] == value) {
            results.push(items[i]);
        }
    }
    return results;
}

The filter function iterates over each element of the array and uses the bracket notation to retrieve the object property by name. The algorithm uses the loose comparison operator to compare object property value to the search criteria provided by the user.

// Retrieve array of parameters from the query string
function getParams(qs, params) {
    const results = [];
    for (let i = 0; i < params.length; ++i) {
        const value = qs.hasOwnProperty(params[i])
            ? qs[params[i]]
            : null;
        results.push(value);
    }
    return results;
}

The getParams function streamlines retrieval of search parameters from the query string. It takes an array of parameter names as an argument and iterates over it. For each parameter, it checks if it is present in the query string and adds it to the results array. If the requested parameter is not in the query string, it adds null instead. null is a special JavaScript value used to denote missing data.

The resulting code is short and can easily be reused to implement search over other data sets, and based on criteria provided by the caller at runtime.

It also has a security flaw.

Abusing loose comparison

One of the surprising rules that the loose comparison operator uses to compare values of different types is the one that says that null and undefined are equal, while the strict comparison algorithm treats those two values as different.
Let’s take one more look at the comparison in the filter function:

if (items[i][field] == value) {

If we were able to force one operand to be always null, and the other to always be undefined, the comparison would always return true. Our HTTP endpoint would return the entire content of the users array, disclosing sensitive information about all the users of our application.

How can we do that?

Attack payload

The right-hand side of the comparison is a value returned by the getParams function. We can for this value to be null by… omitting it from the query string altogether.

Now we need a way to get the left-hand side to always return undefined. undefined is a special value that JavaScript uses for variables and object properties that have not been written to. If the field variable referred to a property that does not exist, the entire left-hand side of the comparison would always return undefined.

We do not always know what properties exist on objects. With a little bit of trial and error, it should not be difficult to find a value that is very unlikely to be a real property name.

A successful attack could look like this:

GET /profile?field=doesnotexist HTTP/1.1
Host: localhost:3000
Connection: keep-alive
Accept: */*

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 364
Connection: keep-alive

[{"email":"janet@wiredbraincoffee.com","password":"coldbrew","address":"1234 Wired Brain Blvd\r\nAwesome City, MM 55555"},{"email":"joe@wiredbraincoffee.com","password":"coldbrew","address":"1235 Wired Brain Blvd\r\nAwesome City, MM 55555"},{"email":"michael@wiredbraincoffee.com","password":"coldbrew","address":"1236 Wired Brain Blvd\r\nAwesome City, MM 55555"}]

The fix

The root cause of the vulnerability is not difficult to fix. The === operator will treat undefined and null as different values. The comparison will always return false and the endpoint will not return any data from the users array, as expected.

This simple change fixed the vulnerability but there is more than we can do.

A more robust fix

The vulnerability was exploitable because of the loose comparison and the fact that the attacker could omit the value parameter. Instead of returning an error, the readProfile function was executed with corrupt input data.
A more complete fix uses the === operator but also adds more strict input validation. Our endpoint should return HTTP 400 response code when query string parameters are:

Missing. Omitting a parameter can lead to unexpected code behavior. The dynamic and weak typing make our program work without errors, even if it does something we did not expect it to do.
Invalid. We also need to validate if the values are within the expected range. In our example, we should do it for the field parameter: we know what properties objects from the users array have, and there is no reason to allow other values.

We will leave adding this input validation logic as an exercise for… you, dear reader. Have fun!

What's next?

The next post in this series will explain how using certain unsafe functions can allow attackers to execute their code within our applications.

How to Think About JavaScript Security

Marcin Hoppe — Thu, 02 Jul 2020 13:31:38 +0000

JavaScript has no security model. The runtime environments do. This post is a primer on how to think about JavaScript code security in Web browsers and Node.js.

How Browsers Execute JavaScript Code?

JavaScript was created to add interactivity to HTML pages. Web browsers were the first runtime environment for JavaScript code.

When the user visits a Web page, the browser downloads the HTML code of that page and parses it to create the Document Object Model (DOM). The HTML contains information about other assets that need to be downloaded to render the page to the user. This includes stylesheets (CSS), images, other documents to display in frames, and many more.

The type of asset we are most interested in here is JavaScript code. It is also downloaded by the browser from locations referenced in the HTML.

Same-Origin Policy

Users can simultaneously visit many pages in tabs or separate browser windows. JavaScript code downloaded from multiple different sites is executed in the same browser.

One of those sites could be infected or operated by an attacker. Is this a risk? Could malicious code compromise the machine or steal data from other sites the user is browsing?

Browsers protect against this. Each Web site executes JavaScript code in a sandbox. Code downloaded from one Web site cannot read or write data from another site. It also cannot call functions or methods across different sites.

This is called the Same-origin policy (SOP) and it is one of the most fundamental security policies on the Web.

Protecting Code Integrity

Attackers could breach the SOP through the injection of malicious code at the network level, making the injected code appear as coming from the legitimate site. Browsers use the secure HTTPS protocol to ensure JavaScript code is downloaded from the legitimate server and that the code is not tampered with in transit.

JavaScript is often distributed using Content Delivery Networks (CDN). Attackers capable of injecting content into the CDN could also compromise the SOP. Subresource Integrity (SRI) provides an additional level of protection that allows HTML code to be cryptographically bound to JavaScript code to prevent this.

Sandboxing

Sandboxing is difficult to implement. Browsers use isolation mechanisms provided by the hardware and the operating system. JavaScript code from different sites is executed in separate processes.

The code in a sandbox is restricted in what it can do. It cannot directly access devices such as webcams or microphones. The filesystem and the local network are also not directly available.

JavaScript can use those resources only through very limited APIs. This reduces the attack surface. It also allows the browser to always ask the user for explicit permission before uploading files, capturing the webcam, or listening to the user’s microphone.

Node.js vs Browsers

Node.js is a runtime environment for JavaScript based on the V8 engine built for the Google Chrome browser. It allows JavaScript code to be executed outside of the browser, typically on servers.

Node.js does not use the browser sandbox to run JavaScript. Security properties of both execution environments are different:

Origin. Browsers download the code and Node.js loads the code from local files like other popular programming languages.
Trust. Browsers treat the code as untrusted and Node.js treats the code with full trust.
Permissions. Browsers restrict capabilities the code has access to and Node.js grants all the privileges of the operating system account. This includes access to devices, files, and the local network.

Impact on Security

The same JavaScript script or module can be executed in the browser or Node.js. Potential attacks may be different in both environments. The impact of successful exploits may be drastically different. It is very hard to reason about the security of JavaScript code without a specific execution environment in mind.

Browsers

A successful attack on JavaScript code running in the browser impacts a single user. The impact is limited to what the sandbox, browser APIs, and the user’s explicit consent allow for.

Compromised JavaScript script or module runs within the context of an authenticated session of the victim and it can perform actions on behalf of the user. In this scenario, the vulnerable code becomes an attack vector against Web applications the victim has legitimate access to.

Node.js

A successful attack on Node.js programs may impact the entire server the program runs on. The attacker may get access to all the resources the operating system account has access to, potentially leading to a full compromise of the server.

What’s next?

The next post in this series will demonstrate how the dynamic type system may lead to subtle security bugs.

JavaScript Security Pitfalls

Marcin Hoppe — Wed, 01 Jul 2020 09:51:47 +0000

Why bother with JavaScript security?

The Web runs on JavaScript. If you are a software developer, chances are you are writing JavaScript. Even if you are not, you rely on tools and applications written in this popular language. You would not be reading this article without JavaScript.

A lot has been written about Web security. Many software engineers know what SQL injection is and can tell cross-site scripting (XSS) from cross-site request forgery (CSRF). And yet, security issues that are unique to JavaScript remain unknown to many developers.

Unfortunately, this does not mean that those vulnerabilities cannot be exploited by attackers seeking fame, fortune, or revenge. They certainly can.

A series is born

The goal of this blog post series is to help you become a better JavaScript developer. I will help you to build a strong mental model of the most prevalent vulnerabilities that plague JavaScript code. Follow along to learn how to write secure and robust code that prevents them.

Here be dragons

JavaScript is a bit of an odd animal in the programming language menagerie. Rapid development and massive popularity gave us language features and coding patterns that may easily lead to exploitable security bugs.

Dynamic typing. JavaScript variables can refer to objects of different types. A variable can refer to a number, a string, or an object, depending on the flow of control. When you look at the code, you do not always know the types of your variables. It may lead to unintentional information disclosure or other security issues.
Dynamic code execution. JavaScript programs can invoke the JavaScript engine at runtime. It sounds like a really powerful feature, and it is. Also, this is what attackers dream about: the ability to inject their code into your application.
Prototype pollution. JavaScript has a pretty unusual inheritance mechanism. Instead of expressing static relationships between classes, the same goal is achieved by building dynamic relationships between objects. If attackers can modify the objects forming the prototype chain, they may alter the behavior of your code in unforeseen ways.

This series of posts will look into those problems in detail. It will also offer actionable guidance on how to find and avoid them.

What’s next?

The next post in this series will explain the JavaScript security model in two most popular runtime environments: Web browsers and Node.js.

Video course

I am also working on a video course JavaScript Security: Best Practices on Pluralsight. It will be a part of the JavaScript Core Language learning path. Learn more on the Courses page on my website and subscribe to the newsletter to get regular updates about the progress.