News for hackers. Stuff that matters.
Re:XSS Attacks: The Next Wave by tallclair on Thursday June 08, 2017 @04:46PM (#14517067)
Why can't we tackle XSS in the browser, by preventing javascript from executing in the <body> (or anywhere other than <head> for that matter)? There is an old memory protection technique of designating the stack & heap (data portions of memory) as non-executable. It seems like a similar idea should apply to the web, where the DOM is effectively a "data" portion, and separate out all executable javascript into a separate section. I know this breaks things like `onclick=` attributes, but can't those be replaced with event listeners? Of course it would be opt-in by setting an attribute somewhere in the DOM (e.g. <body non-executable="true">)

This seems like a fairly obvious idea to me, but I'm not a frontend developer, so I'm looking for someone to tell me why this doesn't already exist :)

Re:XSS Attacks: The Next Wave by dfabulich on Thursday June 08, 2017 @05:05PM (#14517198)
This already exists. It's called Content Security Policy. https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
Re:XSS Attacks: The Next Wave by simooooo on Thursday June 08, 2017 @06:08PM (#14517546)
And it is an almighty pain in the arse to set up
Re:XSS Attacks: The Next Wave by zxcmx on Thursday June 08, 2017 @10:41PM (#14518825)
Unless you can influence an organisation at a pretty high level it is often impossible to write a useful CSP.

To take a really degenerate example, media sites tend to have so many third-party JS integrations (maps, multiple analytics providers, ad systems etc etc) that you can't write a useful, security-improving CSP :/

Which means talking to marketing about their preferred analytics tool, asking the business if they really want these ad networks etc etc.