The title is wrong. Google's not ditching anything, it seems.
Google Chrome is ditching its XSS detection tool
21–28 of 28 posts
Re: Google Chrome is ditching its XSS detection tool
#22Disclaimer: I'm working on the Trusted Types project in Google. To clarify, Trusted Types are not a replacement for XSS auditor. They are both related to XSS, but are fundamentally different and even target different flavors of XSS. Trusted Types are an opt-in browser API that helps developers prevent DOM-based (~client-side) XSS by mandating that developer-specified rules are applied to data that reaches risky funct…
We have APIs to put content in DOM elements without it being interpreted as html, and we have APIs to build DOM elements without using strings. Given that trusted types don't actually prevent xss from occuring and only make your data flow more explicit, why not just recommend to developers that they use the other APIs, instead of adding this new one?
I don't think you can build applications without using the dangerous sinks at all yet. Some common scenarios we know are common:
window.open href Setting text on a script element Setting src of a script element form.action innerHTML
Applications do use these sinks quite often, and some of them cannot be just get ridden of (e.g. href or script.src). Even removing eval takes ages. Complex applications parse HTML from the users, load scripts dynamically, and such.
That said - TT allow you to have such enforcement too - just set a "Content-Security-Policy: trusted-types;" header and all dangerous sinks can never be called. We call it Perfect Types, but it's not yet practical to build client side applications in that setting.
Re: Google Chrome is ditching its XSS detection tool
#23Earlier quoted context omitted.
We have APIs to put content in DOM elements without it being interpreted as html, and we have APIs to build DOM elements without using strings. Given that trusted types don't actually prevent xss from occuring and only make your data flow more explicit, why not just recommend to developers that they use the other APIs, instead of adding this new one?
I don't think you can build applications without using the dangerous sinks at all yet. Some common scenarios we know are common: window.open href Setting text on a script element Setting src of a script element form.action innerHTML Applications do use these sinks quite often, and some of them cannot be just get ridden of (e.g. href or script.src). Even removing eval takes ages. Complex applications parse HTML from t…
Your response makes it sound like this is intended more for cases where a site uses innerHTML and its too much of a burden to rewrite, so you allow only that innerHTML, but that allowed innerHTML is still susceptible to XSS, so what is the point?
As a side note, having a header to disallow innerHTML and etc is definitely a good step, but the rest of this seems superfluous or even leading to a false sense of security.
Re: Google Chrome is ditching its XSS detection tool
#24> Websites should prevent this kind attack I've had far too coworkers argue that we shouldn't "waste time" preventing XSS attacks _because_ Chrome already detects and prevents (most of) them.
Your coworkers aren't too smart
Re: Google Chrome is ditching its XSS detection tool
#25> Websites should prevent this kind attack I've had far too coworkers argue that we shouldn't "waste time" preventing XSS attacks _because_ Chrome already detects and prevents (most of) them.
The classic "we already have a wall (1 meter high, that folks do not understand very well)" so why need to build a new wall, on top the current wall or prepare for a potential invasion?"
Re: Google Chrome is ditching its XSS detection tool
#26From a cursory glance, the replacement (Trusted Types), just seems like a very cumbersome runtime type-safety engine kind of thing, shoehorned into a JS/DOM context. Is that a correct understanding? If so... Why use this cumbersome API instead of just relying on existing and well-implemented concepts as already present in Flow or Typescript? That way you could have Flow or Typescript also compile to whatever form thi…
This isn't a programming language type safety mechanism, it's a way to tell the browser to enforce that you can't run code that could potentially be vulnerable to XSS, except in specific places that you designate with policies. This example was illuminating for me: https://developers.google.com/web/updates/2019/02/trusted-ty...
Tomato/tomato.
You are effectively saying that only certain types of strings and DOM structures are allowed on certain properties and attributes.
This is perfectly encodable in a type-system. I don’t see a reason to dismiss that observation outright.
Re: Google Chrome is ditching its XSS detection tool
#27> Websites should prevent this kind attack I've had far too coworkers argue that we shouldn't "waste time" preventing XSS attacks _because_ Chrome already detects and prevents (most of) them.
Your coworkers aren't too smart
This comment doesn't really contribute anything — and it makes a common mistake of treating this as an issue of intelligence when it's more specific security experience and awareness. In particular, I've seen a pathology around XSS where part of the problem is that someone is pretty savvy and downplays the risks thinking “well, I'd never set things up so that would work”, ignoring all of the times they've made mistakes, used a library or vendor product, had projects change hands, etc.
Re: Google Chrome is ditching its XSS detection tool
#28I learned about Xss mitigation 3-4 years ago through google gruyere, a tutorial that came with a sandboxed environment to practice in [1]
Where did others learn about XSS mitigation? Any resources to recommend?