41–47 of 47 posts
What I learned only recently: With many modern javascript frameworks many of the assumptions you may have had about XSS in the past are obsolete. The strategies that worked in the past - proper escaping of untrusted input - don't necessarily work any more if you're using something like angularjs.
Why can't we tackle XSS in the browser, by preventing javascript from executing in the (or anywhere other than 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…
This already exists. It's called Content Security Policy. https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
> Lastly, “DOM-based XSS” attacks occur purely in the browser when client-side JavaScript echoes back a portion of the URL onto the page. This Google Doc has tracked almost all "sinks" and "sources" for DOM-based XSS[1]. They aren't by any means limited to the URL (usually accessed by the `document.location` object). [1] https://docs.google.com/spreadsheets/d/1Mnuqkbs9L-s3QpQtUrOk...
I'm interested in the topic, but found the article quite disappointing. It doesn't really go into the technical details why we have a new wave of XSS vulns. What I learned only recently: With many modern javascript frameworks many of the assumptions you may have had about XSS in the past are obsolete. The strategies that worked in the past - proper escaping of untrusted input - don't necessarily work any more if you'…
> AngularJS version 1, used at that point by approx. 30% of all websites :) Something got quoted wrong there.
I think they misread a chart from their source, which shows 0.3% market share for AngularJS: https://w3techs.com/technologies/history_overview/javascript...
Earlier quoted context omitted.
This already exists. It's called Content Security Policy. https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
And it is an almighty pain in the arse to set up
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.
The rise in the client doing heavy lifting via libraries such as React is driving an increase in vulnerabilities. Developers getting into React don't always realize that all the code is executed in the client and any input validation and authentication they come up with has to also exist on the server storing that data.
React by default has pretty good XSS protection. That being said, "don't trust the client" has been something developers have struggled with ever since we started writing client/server software.
I think it's a common misconception, heavy-weight software usually does pretty well with common problems. If you think of frameworks like Rails which make input validation easy, writing manual SQL almost obsolete (SQL injection) and even CSRF protection happens mostly transparently.