Comment by _urga | Hacker News Reader

Comment by _urga | Hacker News Reader

Parent Full thread

"I don't see [DOM Clobbering] as a valid security concern in this case"

It is for sure a valid security concern when doing client-side XSS filtering, which is what the presentation is about. And no, DOM Clobbering does not require an attacker to "have access to the page in your user's security context". Fastmail have an introduction here: https://fastmail.blog/2015/12/20/sanitising-html-the-dom-clo.... Simply put, there's no way to do safe client-side XSS filtering without addressing DOM Clobbering as a valid security concern.

"hardening the DOM won't provide the necessary solution."

And the author is not suggesting or waiting for that. On the contrary, the premise is that XSS sanitizers need to be client-side exactly because the DOM is not hardened and has so many different implementations (even across browser versions). It's counter-intuitive I know, but server-side XSS sanitizers really can't address cross-browser parser differences safely. So again, it's not a question of "stylistic concerns" or "code management" but of doing secure XSS filtering wherever it is best done.

"There are better ways to solve for this."

And if you go on to the next slide, 28, the point is that despite the difficulties, this has been solved in DOMPurify, which should be added to the DOM so that developers can finally have a first-class client-side XSS sanitizer, without having to trust DOMPurify as third-party code.

There are not many people who know more about client-side XSS filtering than Mario Heiderich. And I know of no better client-side solution than DOMPurify.

How does the security aspect of DOM clobbering occur without injecting malicious code into a page?

Again, see Fastmail's introduction: https://fastmail.blog/2015/12/20/sanitising-html-the-dom-clo...

No code injection is required. DOM Clobbering simply presents an ambiguous view of the content being sanitized.

The article makes some false assumptions. My first job out of college was writing HTML in Email. HTML embedded in email presented in webmail was the toughest. That is learning CSS through the school of hard knocks, particularly when IE7 was released with a different box model.

Again, the problem here is injection, specifically HTTP injection. Email doesn't have an injection problem because it has a more robust protocol: RFC 2821, 2822 and their descendants. To make emails pretty somebody had the really bad idea of embedding HTML in email messaging. HTML is reliant upon the simplified architecture of the HTTP protocol. When you want that pretty content in email you make an HTTP request and some server issues a response.

If they simply took the HTML out of email this security problem would be instantly solved for email. Therefore this isn't an email problem. It isn't even an HTML problem. Its a problem of unregulated HTTP requests.

> HTMl is essentially just a serialisation format for the Document Object Model (DOM)

They are separate things.

I can speak to all of this with confidence. I passed the Security +, CASP, and CISSP exams on the first try just from reading a book. I did security for the military for 10 years, have been developing web technologies for 20 years, and have been writing JavaScript/TypeScript for more than a decade.

The real problem is that lazy developers are punishing their users under pressure from business marketing leaders. There are two simple solutions to this problem:

1. Don't do stupid things that punish your users.

2. Create a web standard ACL that limits all HTTP traffic to/from a browser.

These are both sane and simple solutions. Nobody wants them because bad developers don't want to own the liability for implementing somebody (probably a marketing executive) else's bad decisions. Also, because an ACL standard in the browser would kill the web media business.

Reply on news.ycombinator.com