I'm quite surprised that these exploits aren't blocked at the browser level by default with developers having to write code to make the exploits work if they need to.
For example, if browsers flatly refused to load code from an external URL unless the address was whitelisted in the page's HTTP response headers then you'd make level 6's exploit impossible without much of an impact on web development.
The CORS header Access-Control-Allow-Origin can be used to force a browser to work that way, but only if a site sets it. I'm suggesting we're at the point now where browsers should be secure by default, even if it breaks some old sites.
So I was trying to accomplish this in Firefox and couldn't get past level 3. Switched to Chrome and the exact same solution worked just fine. Firefox was URL encoding my single and double quotes so I couldn't break out of the string for the image (if that makes sense). Firefox 50 and Chrome 54.0.2840.98
Chrome's XSS filter can still be circumvented in quite a few instances. The easiest way I've seen is when the attacker controls at least two variables and can split the XSS across them in such a way that neither half appears malicious but when loaded into the page they create a malicious script.
This is possible with the Content Security Policy header, including automated reports from the browsers when things are blocked. It's hard to implement however since a whitelist of allowed domains can grow very, very large for the average site.
Eg if your web app uses embedded Tweets, MixPanel, and GoogleFonts:
var policy = cspByAPI(basePolicy, ['twitter', 'mixpanel', 'googleFonts' ]);
Ie, the package maintains an up to date list of the image, script, etc sources for all those different embeds, so you only have to specify what your own code needs (that's the basePolicy).
It's for node, but you can easily port it to Elixir or Python or Ruby.
Policies for 16 common CSP embeds are included, please send a pull request to add more.
That's the point I'm questioning - I think browsers should block by default and only allow things that are specifically allowed by the CSP (or by CORS).
For better or worse technologists have largely decided that backwards compatibility trumps all unless absolutely necessary. This means ELS for security patches, only non-breaking changes to the web (which is how we ended up with 'use strict' in Javascript), and even if it is "more secure" if it could break some portion of people's websites it must not be done by default, but must be opted into.
I don't personally agree with the decisions - but I can understand why they are made. It's easier to say I'd personally choose to give devs the finger and tell them to fix their code than to actually give devs the finger and tell them to fix/update their code.
> I'm quite surprised that these exploits aren't blocked at the browser level... I'm suggesting we're at the point now where browsers should be secure by default, even if it breaks some old sites.
Some are. But in general, XSS (especially reflected) are not possible to block exclusively at the browser level.
> For example, if browsers flatly refused to load code from an external URL unless the address was whitelisted in the page's HTTP response headers then you'd make level 6's exploit impossible without much of an impact on web development.
You would also break ALOT of sites with a requirement like that. Not to mention the millions of people who has a website but has no idea what an HTTP header even is...
Its pretty normal to include external scripts on a website (CDN for dependencies, tracking like google analytics etc)
For example, if browsers flatly refused to load code from an external URL unless the address was whitelisted in the page's HTTP response headers then you'd make level 6's exploit impossible without much of an impact on web development.
The CORS header Access-Control-Allow-Origin can be used to force a browser to work that way, but only if a site sets it. I'm suggesting we're at the point now where browsers should be secure by default, even if it breaks some old sites.