July 1, 2023 3:30 PM (GMT+2) - KIAN JAMALI & AARON SHIM
DOM XSS continues to be the most critical threat to web security. Our current best defense against DOM XSS is Trusted Types, a browser-based runtime feature to limit the uses of DOM APIs (and limit the possibility of DOM injection). We will discuss our approach to using Trusted Types to protect billions of our users, the challenges of backporting Trusted Types compatibility to hundreds of webapps, and our approach to making the entire JS ecosystem safer with Trusted Types.
A Cross-Site Scripting (XSS) vulnerability in an Angular application can be a "game over" scenario. As soon as attackers discover an XSS vulnerability in the app, they often can control the entire application. Angular ships with advanced XSS protection out-of-the-box, but even the smallest bug or unaware code mistakes can become a serious XSS vulnerability.
This article is the third part of our "Preventing XSS in Angular" series; we will look at another security layer to add to our in-depth defence strategy: Trusted Types.
Trusted Types is a web platform defence mechanism that can help to stop XSS vulnerabilities in our Angular application. We will learn how Trusted Types can stop the emergence of DOM XSS vulnerabilities and discuss how to configure Trusted Types in Angular.
If you are interested in learning more about building secure Web applications consider joining our flagship online program WebSecurity Academy. It will teach you everything you need to know in that area with the support of our international community 😁. Some of the actionable advice is also available in our secure development training article.
Cross-Site Scripting is a very dangerous attack vector. If a web application is vulnerable to XSS, an attacker can execute malicious code in the context of the application. Cross-site scripting vulnerabilities often allow an attacker to act as the user, which means performing any action on behalf of the user or accessing their data. Suppose the user has privileged access within the app, the attacker might be able to gain full control over all app functionalities and possibly access even more sensitive data.
Based on where an attacker places an injection for execution, XSS attacks can be divided into three main types: reflected (non-persistent), stored (persistent), and DOM-based XSS attacks (non-persistent and persistent).
Reflected XSS (non-persistent XSS) is one of the most common types of XSS. To execute a reflected XSS attack, the perpetrator crafts a link using malicious query parameters and tricks the victim into clicking on it by sending phishing emails or other social engineering techniques. Compared to stored XSS, non-persistent XSS only requires the malicious script to be added to a link and a user to click on it.
Stored XSS, also known as persistent XSS, occurs when malicious code is injected directly into the vulnerable web application. To successfully execute stored XSS, the attacker locates a vulnerability in the app and injects a malicious script into the persistent memory of the server (for example, a user comment saved in the website’s database).
The most common targets for stores XSS are websites that allow users to share their self-created content, such as comments on blogs, social networks, or reviews on e-commerce platforms. Each time anyone views the infected page, the malicious script is transmitted to the victim’s browser.
DOM-based XSS is often quite similar to reflected XSS, except the malicious input never leaves the user’s browser. This type of attack occurs when the DOM environment changes, but the client-side code does not change.