JavaScript Programming: 3 In 1 Security Design, Expressions And Web Development

Introduction

The web runs on JavaScript is the dominant programming language for writing browser applications, and thanks to the Node.js runtime, it is increasingly common to see it in the back end too. The quality of JavaScript code is crucial for security of web applications. This book, however, is not about general web application security. We will not address problems that can affect applications written in any programming language. We will focus on security issues that are unique to JavaScript, and they are a result of its dynamic nature. I will teach you how to identify such vulnerabilities, how to fix them, and prevent those issues from creeping into your code. First, we will focus on the fundamental role that JavaScript plays in web application security. JavaScript can contain vulnerabilities, but in some cases it may even become an attack vector. There are two popular environments for running JavaScript code, and both of them have very different security properties. First, we will take a look at how browsers run JavaScript, and then we will see how Node.js is different. Then, we will look at language features that may lead to security vulnerabilities, dynamic typing, dynamic code execution, and prototypal inheritance. We will wrap up with an example of a simple coding mistake, literally just a missing character, that leads to a significant leak of sensitive data. Information security professionals are well known for specific jargon to use. We will not use it here, but it is important to understand some basic concepts of web security. Attacks against web applications are carried out by people. You may have an image of a person in a black hoodie typing at their keyboard in their basement, but the reality is much more nuanced. Attackers differ based on their capabilities and motivations. They can be teenagers wanting to impress their friends, fired employees seeking revenge, as well as criminals breaking into applications for money. Attacks would not be possible without vulnerabilities. Vulnerabilities are technical flaws in the system that allow people with malicious intent to break into our applications and systems. They can be simple bugs in the code, fundamental architecture flaws or configuration mistakes. All of them can lead to data breaches. Those that usually hit the headlines are about leaking millions of sensitive data records, such as credit card numbers. Data breaches can also involve abusing application functionality, for example toward their goods without paying or getting a refund for goods that were never purchased in the first place. The most common web application architecture has three tiers, the browser, the server, and the database JavaScript code can run both in the browser and the user's device, such as a laptop or smartphone, or on the server using Node.js. Vulnerabilities in server-side code may allow attackers to breach access to the application datastore. A successful attack in a database may lead to a data breach that involves many users. The impact of a vulnerability in client-side code is typically limited to a single user. That sounds like good news. Unfortunately, bugs in JavaScript code running in a browser may allow attackers to impersonate the victim and to perform actions on their behalf. In this case, the vulnerable JavaScript code becomes an attack vector.

Chapter 1 How Browser Execute JavaScript Code

JavaScript was created to add interactivity to HTML pages. Web browsers are the native environment to run JavaScript code. In fact, JavaScript is the dominant programming language in this space. When the user visits a web page, the browser downloads the HTML code of that page, as well as all the other assets needed to display this page. This includes CSS style sheets, images, and JavaScript code. Browsers allow users to visit multiple pages at the same time in tabs or separate browser windows. This means that at any given time, JavaScript code downloaded from several different sites is executed in the same browser. If one of those sites is infected or even owned by the attacker, aren't we at risk of malicious code stealing our data from legitimate sites? Luckily, browsers do not allow for this, and every website executes JavaScript code in its own sandbox within the browser. Code from one website cannot access data or functionality from another website. This is one of the most fundamental security properties of the web. Some browsers use very sophisticated sandboxing mechanisms, like running each tab in a separate operating system process. Downloading code over the Secure HTTP Protocol and using Subresource Integrity, or SRI for short, prevents attackers from injecting their own malicious code into benign sites. JavaScript code running in the browser is restricted in what it can do. It has no access to local resources in a user's computer, and this applies to devices such as webcams or microphones, the file system, and the local network. The code can use those resources only using very limited browser APIs. This allows the browser to minimize the attack surface and ask the user for explicit consent for using those resources. Code originating from different sites cannot access each other's data and functionality. This allows for even stronger protection of data and code execution within the browser.

Node.js is a runtime environment for JavaScript based on the V8 engine built for the Google Chrome browser. The unusual thing about it is that it allows JavaScript code to run outside of the browser. It has gained a lot of popularity and has proven to be a popular tool to build command line programs and web applications. It is quite different from the browser from a security perspective. Browsers download the code, and Node.js loads the code from local files, much like other popular programming languages. The permissions model is also different. Browsers treat the code as untrusted and restrict capabilities it has access to, and Node.js treats the code with full trust and grants access to all the privileges the operating system user has access to, including devices, files, and the local network. Attacks based on a security vulnerability in a browser may affect one victim at a time. Bugs in Node.js may allow for full server compromise, potentially leading to a serious data breach.

JavaScript is a little bit of an unusual programming language. Its rapid development and massive popularity gave us several language features and coding patterns that may easily lead to exploitable security bugs. JavaScript variables can refer to objects of different types. In statically typed programming languages, variables can only store or reference values of a particular type. An integer can only store numbers, never strings or objects. In JavaScript, 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 variables. It may lead to unintentional information disclosure or other security bugs. JavaScript programs can invoke JavaScript engine at runtime. It sounds like a really powerful feature, and it is. It allows for easy processing of complex data formats, such as mathematical formulas or implementing applications that users can extend with their own JavaScript code. Unfortunately, this is also what attackers dream about, the ability to inject their code into your application. JavaScript has a pretty unusual inheritance mechanism. Most mainstream programming languages use classes to express static, hierarchical relationships between types of objects. In JavaScript, the same goal is achieved by building dynamic relationships between individual objects. Each object has a parent object, the prototype it inherits properties from. If attackers can modify the objects forming the prototype chain, they may alter the behavior of your code in unforeseen ways. The dynamism of JavaScript is powerful and flexible. It facilitates rapid development and unlocks programmer productivity. If the same dynamism is abused by attackers, it can lead to security vulnerabilities.

The ecommerce application consists of two components, server and client. The back-end code is implemented in JavaScript using Node.js and the Express framework. The details of this framework are not relevant for this book, but it allows us to easily handle serving JavaScript code, as well as CSS and HTML assets. It also allows us to dynamically generate and serve JSON documents. All those files are served by the server to the browser. Let's take a look at the server code.

The app.js file configures the Express framework to serve static files, parse JSON documents, and handle HTML forms. The code in login.js handles the login form.

It first reads the email and password from the form and checks if they match the users in our database.

This is a sample application, so storing user information in a flat JSON file is good enough. If the user credentials are verified, the code sends the cookie back to the browser and redirects the user to the return URL from the JSON object from the query string.

If the credentials are not verified, the code returns an HTTP 401 code. The code in logout.js is very simple.

It removes the cookie and redirects the user back to the home page. Profile.js has two functions.

One of them is responsible for reading profile information from the JSON file based on some search criteria. The criteria are sent in the field and value query string parameters. Then, we filter the user database based on those criteria. The results are sent back to the browser in a JSON file. The function responsible for saving the profile information is a bit more complex.

First, we find a user based on the Email field. If the user has been found, we clone the field from the request using a JavaScript idiom that merges the request object with an empty object. Then, we assign all the fields from this copy to the user object in our user database. Then, we return to user profile and JSON file. I'm sure you have noticed a few helper functions defined in utils.js.

The filter function returns those elements of the items array where a given field matches the provided value. The getParams function retrieves an array of values from the query string object. The values are retrieved by names specified in the params array. The function also gracefully handles missing values returning null, which is a JavaScript value to denote missing data. The merge function performs a deep recursive merge of properties of the source object with the properties of the target object.

Using such a function with an empty object as the target is a popular JavaScript idiom for performing deep copies of objects.

Chapter 2 Exploiting the Vulnerability

JavaScript has a dynamic type system. It means that variables can reference values of different types throughout their lifetime. At one point, a variable may refer to a number, and it may refer to a string later on. The rules that describe how operations are applying to values of different types are quite complex and can lead to security issues. When JavaScript code attempts to perform an operation on two values of different types, it needs to convert them to a common type where that operation is well defined. For example, adding a number to a string will convert that number to a string, and the addition operation will become a concatenation of two strings. This may lead to unexpected code being called if types of variables are not properly tracked and controlled. JavaScript has two comparison operators, strict, also known as triple equals (===), and loose, known as double equals (==). The strict comparison operator compares both the value and type, so a string can never be equal to a number. The loose comparison, when applied to parameters of different types, automatically converts the operands to a common type to make the comparison possible. When using this operator, a string can, in some cases, be equal to a number. Comparing values such as null and undefined is another corner case. Strict comparison will always treat those two values as different, but the loose comparison will treat them as equal. This may lead to security checks being bypassed. If they use the loose comparison, variable types are not enforced. Another aspect of JavaScript dynamism is that it used to be very forgiving of programming errors. Over