The most common vulnerabilities to look out for in Angular and React applications: template injection, XSSI, authentication bypass, and more.
Photo by Lautaro Andreani on Unsplash
Securing applications is not the easiest thing to do. An application has many components: server-side logic, client-side logic, data storage, data transportation, API, and more. With all these components to secure, building a secure application can seem really daunting.
Thankfully, most real-life vulnerabilities share the same root causes. And by studying these common vulnerability types, why they happen, and how to spot them, you can learn to prevent them and secure your application.
The use of every language, framework, or environment exposes the application to a unique set of vulnerabilities. The first step to fixing vulnerabilities in your application is to know what to look for.
Today, let’s take a look at six of the most common vulnerabilities that affect Angular and React applications, and how you can find and prevent them. The vulnerabilities I will cover in this post are:
- Authentication bypass
- Improper access control
- Open redirects
- Cross-site request forgery (CSRF)
- Template injection
- Cross-site script inclusion (XSSI)
Authentication Bypass
Authentication refers to proving one’s identity before executing sensitive actions or accessing sensitive data. If authentication is not implemented correctly on an application, attackers can exploit these misconfigurations to gain access to functionalities they should not be able to.
For instance, routing in Angular is usually done with the AppRoutingModule. Before directing users to sensitive routes in the application, you should check whether the user has been authenticated and authorized to access that resource.
https://medium.com/media/3118c0931f2696ee250275303952447d/hrefFor more details about how you can configure authentication properly in Angular and React, read this tutorial.
Improper Access Control
Improper access control occurs anytime when access control in an application is improperly implemented and can be bypassed by an attacker. Authentication bypass issues are essentially a type of improper access control. However, access control comprises of more than authentication. While authentication asks a user to prove their identity: “Who are you?”, authorization asks the application “What is this user allowed to do?”. Proper authentication and authorization together ensure that users cannot access functionalities outside of their permissions.
There are several ways of configuring authorization for users: role-based access control, ownership-based access control, access control lists, and more. A good post to reference for implementing access control in Angular and React is here.
One common mistake that developers make is to perform authorization checks on the client side. This is not secure since client-side checks can be overridden by an attacker. These authorization checks must be performed using server-side code instead:
https://medium.com/media/ff07abdce53c65f86324428bcb1a461b/hrefOpen Redirects
Websites often need to automatically redirect their users. For example, this
scenario happens when unauthenticated users try to access a page
that requires logging in. The website will usually redirect those users to the
login page, and then return them to their original location after they are authenticated.
During an open-redirect attack, an attacker tricks the user into visiting
an external site by providing them with a URL from the legitimate site that
redirects somewhere else. This can lead users to believe that they are still on the original site, and help scammers build a more believable phishing campaign.
To prevent open redirects, you need to make sure the application doesn’t redirect users to malicious locations. For instance, you can disallow offsite redirects completely by validating redirect URLs:
https://medium.com/media/e65fe81e5a652928961f59a288cb38c6/hrefThere are many other ways of preventing open redirects, like checking the referrer of requests, or using page indexes for redirects. But because it’s difficult to validate URLs, open redirects remain a prevalent issue in modern web applications.
Cross-Site Request Forgery
Cross-site request forgery (CSRF) is a client-side technique used to attack other users of a web application. Using CSRF, attackers can send HTTP requests that pretend to come from the victim, carrying out unwanted actions on a victim’s behalf. For example, an attacker could change your password or transfer money from your bank account without your permission.
Unlike open redirects, there is a surefire way of preventing CSRF: using a combination of CSRF tokens and SameSite cookies, and avoiding using GET requests for state-changing actions. As an example, Angular allows you to add anti-forgery tokens to HTTP requests using the HttpClientXsrfModule module:
https://medium.com/media/e14b6d09fb81c3b28cd9081681bcd1b3/hrefTemplate Injection
Web templates are HTML-like files that provide developers with a way to specify how a page should be rendered by combining application data with static templates. This functionality allows developers to insert dynamic content retrieved from a database or from an HTTP request into web pages.
Template injection refers to injection into web templates. Depending on the permissions of the compromised application, attackers might be able to use the template injection vulnerability to read sensitive files, execute code, or escalate their privileges on the system. For instance, here is an unsafe usage of an Angular template that allows attackers to inject code via URL hashes:
https://medium.com/media/a789db884d44dcc90494fa73203590d7/hrefYou should never directly concatenate user-provided input into templates. Instead, use the template engine’s built-in substitution mechanism to safely embed dynamic input:
https://medium.com/media/032940d81a02319a1d1e0f31cdf31cf5/hrefLearn more about how template injection work and how to prevent them in Angular and React in this post.
Cross-Site Script Inclusion
Cross-site script inclusion attacks are also referred to as XSSI. These attacks happen when a malicious site includes Javascript from a victim site to extract sensitive info from the script.
The same-origin policy (SOP) usually controls data access cross-origins. But the SOP does not limit javascript code, and the HTML tag is allowed to load Javascript code from any origin. This is an extremely convenient feature that allows JavaScript files to be reused across domains. But this feature also poses a security risk: attackers might be able to steal data written in JavaScript files by loading the JS files of their victims.
For example, imagine that a website stores and transports sensitive data for logged-in users via Javascript files. If a user visits a malicious site in the same browser, the malicious site can import that JavaScript file and gain access to sensitive information associated with the user’s session, all thanks to the user’s cookies stored in the browser. See an example of this vulnerability and learn how to prevent them in Angular and React here.
To avoid XSSI attacks, don’t transport sensitive data within JavaScript files. Here’s an example of how to safely load an API token in Angular using JSON files (which are limited by SOP):
What other security concepts do you want to learn about? I’d love to know. Feel free to connect on Twitter @vickieli7.
Now that you know how to fix these vulnerabilities, secure your Javascript application by scanning for these vulnerabilities! ShiftLeft CORE (https://www.shiftleft.io/shiftleft-core/) can find these vulnerabilities in your application, show you how to fix these bugs, and protect you from Javascript security issues.
Top comments (0)