We’ve all heard this horror story on the news: Mega-Corporation gets taken down by hackers and user data is captured for distribution on the dark web. The corporations’ reputation is tarnished and their security team is awash in total disgrace. As developers, we know that we must always be on the cutting edge of security measures in order to mitigate the potential risk of user data being compromised.
In this talk, you’ll learn:
How Trusted Types can significantly strengthen the security posture of your Angular application How to get started with Trusted Types How to roll out Trusted Types in your applicaiton How to fix any vulnerabilities you may find along the way. Upon completion of this session, you’ll have the tools and knowledge you need to fully adopt Trusted Types, and be able to worry less about the risk of security compromise within your applications. ng-conf is a three-day Angular conference focused on delivering the highest quality training in the Angular JavaScript framework. 1500+ developers from across the globe converge on Salt Lake City, UT every year to attend talks and workshops by the Angular team and community experts.
Follow us on twitter https://twitter.com/ngconf Official Website: https://www.ng-conf.org/ Join the Angular Community: http://www.ng-conf.org/ Get your ng-conf tickets: https://ti.to/ng-conf Follow Us: https://twitter.com/ngconf Learn More: https://ng-conf-school.teachable
Read More: https://medium.com/ngconf
Hear More: http://theangularshow.com
Hey there, I'm Joe Williams. Before we get into the video, I want to remind you about Ng Cough happening on August 31 in person. So head over to Ngcoff.org to check out the speakers, check out the talks, and get your ticket. It's time to get it back together. Hello everyone. My name is Gatquie, and I'm a security engineer at Google, where I work on web framework security. Today I'm going to show you how you can eliminate cross site scripting vulnerabilities from your Angular application by adopting a new web platform security mechanism called Trusted Types. Let's start with a little bit of background. Google's VRP is a bug bounty program that pays external security researchers for reporting vulnerabilities. Looking at the data from 2018 and the total payouts by vulnerability class, we can see that crossed scripting accounts for more than a third of the entire budget. And considering that almost half the budget isn't even on web related issues, we can see that XSS is by far the most expensive type of web vulnerability, and this graph looks largely the same even today. As well as if you look at other programs. Cross site scripting vulnerabilities occur when a web application passes user input which hasn't been escaped or sanitized into an HTML or script context that the browser then interprets and execute. This can be serious, as an attacker may be able to leverage this to leak sensitive data from users or perform actions on their behalf. This can happen both because of unsafe server side and client side rendering. Client site or Dom based XSS, which we are going to focus on, occurs when the application passes user input to one of the dangerous Dom APIs, which we call injection syncs. On the right you can see some examples of injection syncs. EVAs is probably the most recognized one, but assigning to inhtml or script source are other good examples and will cause excess if past untrusted user input. There have been a number of attempts at mitigating Dombased excess, including content security policies, static code analysis, and XSS detection in browsers. While most of these help considerably, as we saw on the previous slide, access is still a huge threat, expanding based on content security policies. They allow you to restrict which scripts are allowed to run on your page. They are configured by having your web server send an Http header. For example, a Content Security policy header with a value of script source example.com will make the browser block execution of any scripts that are not loaded over Https from example.com. This ensures that only scripts that you trust are executed on your page. While a good CSP policy may limit or even block impact from Domxss in your application, it does not address the root cause of these vulnerabilities, which are unsafe uses of injection syncs. And indeed, attackers may still be able to deface a website or use it for phishing attacks. Luckily, Angular does a great job of limiting direct interaction with injection syncs. It provides a template language that ensures that all interpolated user input is escaped or sanitized before rendering. If you need to bypass Sanitization, you must explicitly call one of the bypass Security Trust functions, which marks the value as safe for injection into a specific context. But even if a secure web framework such as Angular is used, there are still many opportunities for director interaction that could lead to excess. For example, there is nothing that forces a developer to use Angular snapped in language, so they may still call out to the Dom directly, and in some cases, this may even be necessary. External JavaScript libraries that the application depends on are also a common source of excess vulnerabilities, as they frequently perform direct Dom interaction. And both of these points are especially true in enterprise scale applications, where there is often little oversight over what code gets checked in. This brings us to the main subject, which is Trusted Types. Trusted Types is a new web browser API that allows you to completely block write access to injection syncs. They are CSP feature and are configured by serving a CSP header with required Trusted Types for script. When enabled, any attempt at using an injection sync will be blocked by the browser throwing an exception. Also known as a Trusted Types violation, Angular has recently been made compatible with Trusted Types, meaning that using Angular and its temporary language will not cause any violations. When running your Angular application locally, you can enable Trusted Types by adding the CSP header to Angular JSON. You can verify that it works by opening the developer console in your application and executing eval on a plane string. Enabling Trusted Types makes an application very secure, but it can also break its functionality. So before rolling this out to production, we first need to identify the Trusted Types of violations and fix them. There are a few different ways to identify Trusted Types of violations. The simplest way is to run Nt Serve and open the application in a browser. Trusted Types violations will surface as exceptions in the developer console and contain a stack trace. Enabling Trusted Types in Angular dossiers will also cause Trusted Types to be enforced in end to end tests. Running Nt E to E is a good source of violations if the tests are comprehensive. It is also possible to use static code analysis. We've developed a tool called TSAC that looks for Trusted Types violations in TypeScript code. Finally, you can use a feature CSP known as reportONLY Mode, which allows you to collect and analyze CSP reports containing Trusted Types violations from actual users without causing production breakouts. This is a good practice before deploying any CSP feature. Now, when you've identified usage of an injection sink that is causing a Trusted Types of violation, you need to refactor that code in a way that does not cause a violation. First and foremost, you should be using Angular Stampede language whenever possible. Otherwise, here are some common examples of violations and save alternatives. If you're assigning plain text to inner HTML, you can assign the text to text content instead. If you're constructing some simple inline HTML, you can use save Dom APIs instead. For example, document create, element, set attribute text content and a pentagon. If you're creating inline event handlers using strings, you should be using add event listener or angle's event bindings instead. If you're creating that workers and you're using Webpack, you can use import Meta URL to instruct webpac to align the workers script in a way that is compatible with trusted Types. These are some common examples, but sometimes there is simply no safe alternative. As a last resort, Trusted Types provides a mechanism known as Trusted Types Policies. These policies allow the application to produce values that are safe or used in specific injection sinks without causing a trusted types of violation. Sinks require one of three different types of values depending on the nature of the sync. Either trusted HTML, for example when assigning to inner HTML, trusted Script, for example when I called Eval, or trusted Script URL, for example when creating a worker. Policies are simple JavaScript objects defined by the application. On the right is an example of an application that wants to assign potentially untrusted user input to any HTML in a safe way. It starts by defining a Trusted Types policy. Using the Trusted Types Create Policy API and giving it a name of Sanitized HTML. The Createhtml function defines how unsafe user input should be transformed or validated to ensure that the resulting HTML is trusted. In this case, the Dom Purify library is used to sanitize the HTML. The application can then pass untrusted HTML to the Policies Create HTML function which sanitizes the HTML and returns a trust HTML value. This value can then be assigned to in your HTML without causing a Trusted Types violation. In this way, Trusted Types forces any security sensitive code into Trusted Types policies, and as a result these policies must be scrutinized for security. Once all the violations have been fixed, Trusted Types can be enabled in production. Going forward, we must also ensure that no new Trusted Types violations appear, as that may break the application. The approach is similar to how we originally identified violations by enabling Trusted Types in Angular JSON. Trusted Types will be enabled in development mode. Developers should any new violations when they are developing a feature. The same applies for EndToEnd tests which should be run as part of your CI pipeline. TSEC or Static Code Analysis Tool can be added as a presubmit check to your code repository and in the unlikely case any violations make it into production, you will be notified through CSP reports. One final feature of Trusted Types that I will want to tell you about is restricting policy creation. This is useful as when you rolled out Trusted Types trusted Types policies will remain as the only place where security sensitive code lives in your application. Policy creation can be restricted by explicitly listing the names of the allowed policies in the Trusted Types directive in your CSP header. In the example on this slide, only the two policies named Sanitized, HTML and Angular, are allowed. Trying to create a policy with any other name or using the same name more than once will result in a Trusted Types violation. Restricting policy creation gives you even stronger guarantees about the security of your application and is especially useful in enterprise scale applications where you may not want developers to create arbitrary Trusted Types policies. Angular itself may create a number of Trusted Types policies, which you can either allow or block using the Trusted Types directive. The angular and angular bundler policies are required for basic angular functionality and are always safe to allow. The Angular Unsafe bypass policy is created when any of the bypass security trust functions are called. Depending on whether you allow this policy, you can control whether you want to allow calls to bypass security trust in your application. Angular unsafety is required if you need to use angulars just in time compilation, but using ahead of time compilation is strongly encouraged not only for security but also for performance reasons. Finally, if you want to use the Angular dev tools while developing your application, you need to allow the Angular Dev Tools policy, but make sure you only do this locally. Wrapping Up These are the steps you need in order to deploy Trusted Types. You start by enabling Trusted Types in report only mode. You look for Trusted Types violations either locally, by navigating around your application, or by looking at CSP reports from users. You fix these violations by refactoring code to use saved Dom APIs, using Trusted Types policies as a last resort. When you're confident you fixed all Trusted Types violations, drop the report only mode and start enforcing Trusted Types. Finally, you can rely on EndToEnd tests and continuous integration to prevent any new violations. To get an idea of how effective Trusted Types are, we analyzed Dom based XSS reports from last year's Google VRP program and found that at least 61% of the reported vulnerabilities would have been mitigated by Trusted Types. And note that this only includes vulnerabilities that were already missed by Google static code analysis, pipeline, and security reviews, which is pretty impressive. We've seen how Trusted Types forces you to use Safe APIs and move security sensitive code into Trusted Types policies that can be reviewed in isolation, even in browsers that do not support tester types. This still increases the security of your application considerably, but Trusted Types gives you more than that. I was recently playing around with one of my anchor applications when I ran into a Trusted Types violation. I thought to myself, Oh no, I must have forgotten to refactor some Insecure code in my application. But after peeking into the stack trace, I noticed that the violation was coming from inside the Angular framework. I was using internationalization in my Angular application, and it turned out that in certain scenarios, angular was not escaping user input that went through the I 18 pipeline. I had discovered a cross that scripting vulnerability in angular itself, but because I was enforcing trusted types, my application was immune to the vulnerability, at least in browsers that support hostile types. And the same principle applies to obscure but potentially dangerous cold paths. In both your application and the third party dependencies, they are simply blocked. So that's it. Thank you for listening, and I hope I've inspired you to give just the types a try in your application. Hi, I'm Joe Williams. Thanks for checking out this video from Enterprise Ng 2021. Online conferences were great, but it's time to get back in person, see your old friends, make some new ones, and take Career to the next level. Head over to Ng Cough.org to get your ticket. See you there.