Node.js Node + JS Interactive 2019, 19 Dec 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Securing the DOM from the Bottom Up - Mike Samuel & Krzysztof Kotowicz, Google LLC

Description

18 years have passed since Cross-Site Scripting (XSS) became the single most common security problem in web applications. Since then, numerous efforts have been proposed to detect, fix or mitigate it, but these piecemeal efforts have not combined to make it easy to produce XSS-free code.

This talk introduces Trusted Types (being implemented in browsers) and explains how Google’s security team has achieved a high-level of safety against XSS and related problems by integrating tools to make it easier for developers to produce secure software than vulnerable, and to bound the portion of a codebase that could contribute to a vulnerability.

We will show how this works in practice and end with advice on how to achieve the same results on widely-used, open-source stacks and new browser mechanisms that will make it much easier to achieve high-levels of security with good developer experience.

A

How many people here write JavaScript on a regular basis, very cool and how many people here come from a security background? Anybody all right, very cool, so hopefully, I have a lot of content. That's new for you, then today, so my name is Mike. This is tree stuff. We both work or I, used to work in Google security engineering group tree stuff still does, and in security engineering. It's our job to provide the tools that for developers to allow them to produce, secure and robust software.

A

So a lot of what we're talking about today is kind of how you can use some of the new tools that we're producing in your day to day work to make it easier to produce, secure and robust software and we're talking specifically about Dom XSS. So if you're using a modern, client-side web application framework, Dom XSS is probably one of your biggest security problems. It's a kind of XSS that happens because the API is that the browser provides the JavaScript to let you dynamically change.

A

The page are insecure by default, and so what are the moving parts that are involved in Dom XSS? Well, you have a source of some values from an attacker and those reach a Dom sink, and so mostly the inputs to your system are going to be strings, so they might be strings that you get from a URL.

A

They might be strings that you receive as data via JSON or some other method, and you know one example: you might look in window dot location, you might grab part of that and you might make some decision based on that and if that substring then reaches a Dom sink. You know. One of these powerful API is like elementary HTML. Bad things can happen, and so you know a string is just a string until part of your program decides to treat it as trusted code and that's when it can do a lot of bad.

A

It can take user data phone home with it. It can present an interface that you did not expect to present to the user and trick them into doing things they didn't want to do so. For example, let's say our our application is running on example.com an attacker engineers, a user into going to this URL, and then your code looks in location, dot. Hash takes a substring, find some element on the page and uses that string as a string of HTML. That string then goes through the HTML parser.

A

It creates an image. The HTML parser then sees this on error attribute, which then gets routed to the JavaScript parser. When that image fails to load that on error handler is called and causes the side effect. So this is is the classic case of Dom XSS, and why is Dom XSS so prevalent in modern client-side web application frameworks? Where there's two reasons it's easy to introduce? You have to use these powerful Dom API s, to do your job and it's hard to detect.

A

Let's talk a little bit first about why it's easy to introduce so Dom syncs there's a lot of them. You know: we've got inner HTML we've got source attributes.

A

Each of these attackers have figured out how to craft payloads that let them subvert your program so that it's working towards their ends. Instead of yours, so the first thing you know, so you can't do work without these Dom API s and all of these Dom API czar vulnerable if an attacker controls the input. So the problem we have is that any code with access to Dom API is can introduce XSS and since the Dom API is our global. That basically means any code in your application.

A

So who can tell me, is this function safe, come on? This is Jas interactive. You guys could be a little more interactive, go for it yeah exactly. You have to know how it's called to determine whether it's saved, and so let's say we look through the code base and the only place that's called is in this function. G this function, G is passing document.body as node, and it's passing Y as as the value for inner HTML. Is this safe? Now exactly we don't know where Y comes from.

A

So let's say we look through the code again and we find that the only place that G is called is here and it's called with Z, which is the string hello world. So is it safe, yeah, it's safe and and, and there is there is critical, so it's safe in the present tense. If tomorrow somebody were to add another call to the function, f or g that situation might change.

A

So we could exhaustively review our code kind of connect, these dots and conclude that it's safe, but that judgment would only be valid for the current version of the code, and so the problem here is that we've got a use of F that uses a powerful Dom sink. It uses inner HTML, but its security is tightly coupled with all of its callers, its present callers and its future callers. This means that security review is really hard to do so.

A

You want to do.

B

Thank you Mike. So is this really a problem though it's thus, this leads to actual 108 is e natural code. Yes, it does so I work in the Google security team and.

A

B

Jobs is actually deciding on the rewards for the external people who report security bugs in our software, such that we can patch them and secure our users, and we are talking about millions of dollars paid yearly to research, security, researchers who find bugs in our code. It turns out that roughly half of the payments each year come to the researchers who find web bugs in our software. That's not really surprising right. Google has a lot of essentially web properties. Web applications and XSS is by far the most prevalent bug from this web category right.

B

Cross-Site scripting is responsible for the biggest payoffs that we do as part of our bug. Bounty program and donbass' cross-site scripting, which is the one that we are focusing on right now, is roughly right. Now, two-thirds of the payments right two out of three bugs that are XSS, is in let's say, Google software. Our dom-based xss is so this pattern. These problematic things about the JavaScript API in the browser api's does needs to be real security issues in the inner code, but this is just our data.

B

Other other datasets still show that cross-site scripting for web applications is super prevalent problem. Unfortunately, fortunately, though, we do know how to address this in Google as part of my team tasks.

B

We were thinking for years now on how to limit that, how to minimize the possibility that you know tens of thousands of Front and engineers can introduce a vulnerability without even realizing that, because no one obviously wants to create a vulnerable software, and we have found a solution that is practically responsible for a significant reduction in the number of cross-site scripting bugs in our software, and this is a software or this solution is mostly focused on server side exercises which don't based exercise is not not one-off, but this approach is very successful and it's so successful that we think it makes sense to port it to the browser's themselves, such that also the client-side exercises can be protected through this manner.

B

So we are trying to bake it for years now into the browser's themselves, such that you know, the JavaScript on the web pages can use our methods of trying to protect the applications against this very bad prevalent. Vulnerability. Type- and this is called trusted types trusted types are essentially, data objects are types that encapsulate not just a value, but also the security properties of that value.

B

To give you a very, very short introduction into this one, the core idea behind trusted types is to make the Dom API secure by default, which we think it is not right now, because, for example, as soon as you start using inner HTML as a function, you most likely have just introduced a vulnerability if you ever put a user controlled value into that sink as we call it.

B

So we try to switch the situation to make the Dom API secure by default and strongly-typed at the same time we're relying on well JavaScript types essentially to to give us those interesting properties. So once you start using trusted types in your application, the Dom sinks, all those cloud of functions that Mike has shown you before reject strings. You cannot call them or strings with mine Arkadia that I will demonstrate later on.

B

Instead, you have to create those typed objects that then can be safely passed to this function and those typed objects are of different kinds right because we have different contexts of various Val. So we have a trusted HTML object, which you can safely pass to. For example, in HTML setter or document write function.

B

We have a trusted script, URL object, which you can pass to say a source property of a script element, and then we have a trusted script object which you can safely pass to say an eval function or something that directly executes JavaScript snippet, and once we have those types we can put so many security rules and controls over it, which is exactly what we will demonstrate in a second. So let's look at how to use trusted types in the browser's.

B

Yeah, so we have a file here right. The way you enable trusted types in your application idea enable the trusted types. Enforcement for the Dom sinks is by using a content, security policy. Normally you would set an HTTP response header, but just to demonstrate it in an HTML file. I just use a meta tag to do that same thing right, so you have a Content security policy and there's this new directive as we call it require trusted types for script. Distantly it means I, don't allow strings to be passed to the sensitive functions.

B

I require a typed value and just to demonstrate that you know this. This solution already has some teeth behind it. I will just use it in a Firefox loading, a polyfill. We do have a native implementation in Chrome just to show you the demo on Firefox right. So this is just loading, the trust attack, polyfill and there's something don't look at it. Yet tt magic, Jas right. So let's see this one in action.

B

Nothing really interesting right, there's a hello world application, but what is interesting here is as soon as I try to have this code. In my application that, for example, does yes and this potentially could be and access this payload. This doesn't happen right. The page didn't reload the new code that cotton, constant, didn't appear. We actually got a type error here which says that well come on with document right. You actually need to use a trusted, HTML value and just to demonstrate that you can use a trusted HTML value.

B

What this one is, let's go, magically magic function. We have some value, don't look at the magic yet, but essentially yes, you can use the same still just with a different value type, and this is this- is the very base demonstration of the API functionality. So let's go back to the presentation right.

B

Did we actually change anything for security, because we just you know, changing the let's say the control that were given the function, we're changing the signature of it, but the very important change that is here, which is actually fundamental, is that when enabling trusted types and having the exact same code here, if we change this Z assignment to magically create a trusted HTML value, the safety becomes decoupled from the sinks.

B

From those dangerous, potentially dangerous functions, what that means that, when looking at the security, when reviewing an application for security, I can totally ignore all the other parts of the code. Now the only lines of code- let's say only functions- are the ones who creates trusted values.

B

These can potentially introduce something insecure, but the rest of the application code base is that completely irrelevant for Dom XSS, and this is a fundamental change like we end up or we move from a state where the API is unsecure by default and very clunky to work with, let's say to a state in which an action has to be deliberate, to interact with this API.

B

So to go back to the example that Mike showed without trusted types, any code with access to Dom sinks can introduces XSS. However, with trusted types, only the code that creates trusted touch can introduce XSS, which is a nice property. But then again, I am a security engineer right and the way I am reading. This statement is slightly different. I'm seeing code, creating trusted types can introduce XSS, that's a bad thing, I mean I, don't want XSS. So what can we do about it?

B

Well, we can guard the creation of those trusted values and we do that in trusted types API with objects, called policies, policies define the rules that convert the string values because in the end, you do read strings for various environments, some of them attacker controls and convert those strings into trusted, values or trusted types. Let's see a demo, so second thing not much has changed. We still have this required trusted for script directive. In CSP we have the polyfill, but now we call this specific function exposed on the window. Object right.

B

Every window now has a trusted types property and the trusted. Eps property has a create policy function and what we can do through this is well create policies, so I am creating a policy named strip tags which is very similar to what like say.

B

A PHP did with the strip tax function years ago right and what this policy simply says that this policy is able to create trusted, HTML objects, but any input to it will be somehow transformed, in this particular case, I'm doing a very lazy, HTML sort of sanitization, but not really just neutralizing the values all right, so I do some prefix and then I replace every you know, opening bracket to to you know an HTML escape of it and let's see how that works in practice. Oh and one more thing, this just is a JavaScript object.

B

You you create it, assign it to a variable. You can use that variable wherever you like in your in your program, yeah. So, let's, let's see it, nothing seemingly has changed, but now we can use document, dot, write and then strip tax policy.

B

Let's say something really bad, so image source equals exam really, but at typing sorry, on there or alert. Let's go one three, three: seven: why not yeah? This will succeed because the policy creates total HTML values unless it throws and, of course, doesn't know, I think I have the right. Oh yeah straight tax policy is not a function. That's interesting! Oh yes, of course, sorry you need to call its create HTML function and there you go.

B

The document right was called, but actually we said with the transformation of the value which correctly escaped the less than character.

B

What does it show us? Well, first of all, now not only the type creation is this security sensitive code, but we can put rules on top of it. We can define how the trusted objects can be created, adhering to which rules and of course you can have seven different policies for different parts of your application with different, let's say: Trust properties and different rules can apply to different to different objects right, so only policies by now can introduce Dom XSS in your application, which is a huge property, but then again, I read it slightly differently.

B

Policies can still introduce XSS, and this is clearly clearly bad. So, let's improve on this, let's see how we can actually control the policies. Now, seemingly nothing has changed right. We still have a Content security policy. We have the same directive here, but there is something else here. We have a separate directive, but it's called trusted types and then a list of tokens essentially- and this one simply says straight trip tags.

B

What this says that in my application, I'm allowing only the strip tax policy to be defined, other policies simply cannot be created or policies with a different name cannot be created. So I can still use the strip tax policy. That does you know something the same, the same logic as before, but let's imagine you have something else in your application. Most most most of you already do something like that, which is loading some extra code.

B

Let's say something that displays an advertisement and this advertisement is malicious, so what this does is it tries to well haha creates its own policy that does no transformation what so ever and then you know, supply XSS pilot through that policy object right. This is so bad.

B

This is an intentional bypass, but still a pretty bad situation right, but thankfully drop that types protect against that, and once you load this, you can see that this policy haha is this allowed your browser well in this case polyfill, but your browser prohibits the policy creation, so you can't just sneak in additional policies here, which is you know, desirable property, let's say, but also you cannot actually create a policy with the name that was already use. So what was it strip tags right, strip tags?

B

Let's imagine this one and the object yes strip.

A

B

Already exists: it's already registered right, so you can only use the policies in your applications that already were somehow white listed are listed in the content security policy. Other this one right, so you give even more control over how policies get created and with that I will switch back to Mike.

A

So without trusted types, any code could assign any value. 20 sync with trusted types enabled in without any policy controls any code can create a policy to create a value that will pass a sync and with policy controls, only code that that runs early enough to get one of these trusted names. One of these names in the security metadata can create a policy, and so this last dynamic really allows a security support team to support a application development team.

A

So how many people here know about github code owners, wonderful I, think this is actually probably the most people I've seen aware of that particular feature ever so code owners is an underrated feature of github and what it allows you to do is loop in experts when certain files change. So you you define a file that has a format kind of like get ignore, so you've got globs over paths in your codebase and then you can say for this glob.

A

These people should sign off on any changes to it, and so what that lets you do is have the vast bulk of your code, which can change. However, you like, but this small subset of files requires review by an expert, and so we've got trusted types, we're allowing my policy and my other policy and we're not allowing any other policies.

A

Whoever controls this header gets to decide which policies are allowed and code owners can guard the files that control those policies. So what that means is you're ensuring that your policy code is reviewed regularly next slide, so policies at runtime, they're, just JavaScript objects, but they're JavaScript objects whose code has been carefully reviewed and you can use the usual JavaScript language features to define how how other parts of the code interacts with them. So if you define them inside a mediately executed function, then they're only visible to other code in that function.

A

That means that you can define a policy that is, would be unsafe if globally available, but is safe, based on the callers that can appear in the scope in which it's defined, um and you you know at choose stuff- gave an example of a policy that auto escapes, so that might be a policy that is, should be available more widely to a larger amount of code. So it's very flexible, as you have a lot of flexibility as far as how you craft these policies and how you expose them and then once you're doing the review.

A

These are some some best practices that we've kind of come up with. So you don't want to depend on global State and.

A

When we are when you're kind of making decisions about what to allow and what not to allow, you always want to be whitelisting, you never want to be blacklisting looking for bad patterns when writing security relevant code, it's very hard to reason about everything, but it's much easier to reason about only so and I think when trying to craft a security mechanism, it's it's worth kind of explicitly stating what it is that you're providing. So what trusted types does it is.

A

It allows you to make arguments kind of like this, so we, the application development team with our security support people we're producing the code that is secure against Dom XSS, because Dom syncs only accept trusted types and only policies can create those types and the security experts have reviewed all that policy code and- and hopefully they're. You know good at their job and we restrict policy changes to a small, not infrequently changing subset of the code. So those reviews can be thorough and.

A

The so if it were the case that every developer was writing policy code and it were frequently changing, we wouldn't get much benefit. So we need to keep the amount of security, sensitive code, kind of isolated and small and I worked in Google security engineering group for six seven years and I was heavily involved in improving tools and libraries. So I did a lot of work on things like template. Languages, sanitizers and I was on a team that you know we took rotations.

A

So every couple months I'd spend a week reviewing all of the changes to policy code across Google. So there was a team about 10 people supporting a development group that was I think close to 10,000 engineers.

A

Not all of them are involved in web application work, but a small security team was able to scale to a large application development group because the number the amount of policy code was actually fairly small. Almost all of the policy uses are in some common infrastructure, and nice thing is that you know the nice thing in trusted types does. Is we don't have to reason about where things come from?

A

You? Don't have to reason about where they're going, you know, a small security group can kind of focus all of their attention, and a security engineering group can focus all of their improvement effort on this small core of policy coding.

A

So and so what what happens now is code doesn't become vulnerable because somebody makes a mistake in application code kind of introducing a vulnerability is you know like what we saw after several years of working on applications like Gmail was most of the excesses were my fault or somebody in a function like me, not the common application developers fault, so the system is flexible enough that it's possible to bypass this policy code has to be correct, and this allows it to be a good migration target for a lot of applications.

A

So we've built enough flexibility in here if you've got an application and you want to create a legacy policy that just converts things get trust, get it working with trusted types and then later tighten that down. You know kind of remove the need for that legacy policy you can, and so you know- and it's possible- it's also possible to bypass this system.

A

So if, if there's some dodgy code that runs before the policy that defines the before twist-offs policy, that defines the strip tags policy and it gets that uses the name strip tags, then it might run first. So you have to do a couple things like make sure that the trust, the small amount of trusted code that defines policies runs early in your bootstrapping process and I mentioned kind of tools and frameworks as key integration points.

A

So a small number of policies account for almost all of policy uses, template systems, sanitizers builder api's account for the vast majority, and that lets a small team kind of work on rotations to review the remaining ones. So talking about, we have time to talk about integration yeah, so.

A

We spent years kind of working on our own internal infrastructure to make sure that there's high-quality libraries and policies available to Google code. We don't want the web development community as a whole to have to recreate that process. So we've been working on a basic set of integrations that that mean that a lot of this trusted type stuff should actually be transparent to the bulk of developers.

A

So Facebook has integrated trusted types into react and I think you need to it's on in an experimental more right now, so you need to set something in your react feature flags to enable it. But then react is aware of and respects trusted types. So you know just using react with trust types turned on unless you're doing something kind of odd. That requires one of these safety hatches. It should just work for you and tools like Don purify dot. Sanitize can now be producers of trusted types.

A

We know that Dom purify with a wide set of configurations is, is produces HTML that is safe because it strips out things like script tags and all the other dodgy parts. So we can trust so when it produced it, it uses a policy internally to create a trusted. Html value and.

A

Yeah, so if you want to know more, this is a link to go to. It has a lot of information about trusted types. Trusted types is available in chrome. Now, chrome has an intent to ship. So it's right now, it's it's hidden behind a flag, but it should be coming to Chrome by default soon.

A

In the meantime, there's a polyfill Firefox hasn't decided yet that hasn't committed to shipping yet, but you saw in the demo that we loaded a polyfill, and that gave us the benefit of try some types in the browser and there's mailing lists that you can look at the specification is currently before the w3. Yes, a trusted types at Google, Groups, comm, we'd love to to deal with your questions there, where you can look us up on Twitter, so any questions.

B

So the question about was about integrating essentially building a HTML sanitizer in the browser's. Yes, there are there. There are plans of having that. It's not that easy, because essentially turns out that sometimes HTML sanitization needs to be customized to the application, and the amount of the customization knobs is just like staggering, but Firefox as far as I know, plants to start experimenting on something like that q1 next year, and we are also looking forward to that.

B

We actually, yes, also are thinking that robust achievement is not an easy task and it it's up to the web platform to solve that as well. Yes, you had a question.

B

Yes, it's all about the example being too simple, so.

A

One thing that I've we found kind.

B

A

Doing this is it's best to do the conversion as close to where we know why something is safe as possible, that usually mu means moving the trusted value creation earlier in the process, and so by the time you know this value reaches F, we've lost the context by the time it reaches F. All we know about it is that it's in a it's stored in a variable named X. We don't know that it's a string that appears of literally you know in the source code.

A

So here we can reason this string was written in the source code by a trusted developer. Therefore we can trust it, but we lose that context once once. It's there, so yeah.

B

A

One of the nice things about this is you know, by automatically checking at the sinks that means and having a mechanism for explicitly make. You know it's making trust decisions explicit. We can move those trust decisions to where we have the most context.