4 ms·

I don't see any evidence of alleged DOM-bashing in Mario's slides? In fact, rather than bash the DOM, Mario wants the DOM to subsume his own DOMPurify project,

I don't see any evidence of alleged DOM-bashing in Mario's slides? In fact, rather than bash the DOM, Mario wants the DOM to subsume his own DOMPurify project, rather than have users trust him as a third-party module developer. I think that paints the DOM in a favorable light if you ask me.

austincheney 7y ago
It's slide 27.
- jorangreef 7y ago
  That's not referring to stylistic concerns, and it's not bashing the DOM per se. The context of "The DOM is a mess!" on slide 27 is specifically in terms of security, namely "DOM Clobbering" where an attacker can rewrite DOM methods from underneath you, and impedance mismatch owing to parser differences and bugs ("HTML elements implemented in completely different ways, different attribute handling" in the context of defending against XSS). It's an honest assessment that's more a statement of fact than anything intended to be hurtful. It's not even a harsh statement of truth at that. I find it hard to believe that Chrome or Firefox engineers would find that offensive. I think they would well agree. DOMPurify is really fantastic security work. It would make for a brilliant contribution to the DOM.
  - austincheney 7y ago
    > namely "DOM Clobbering" where an attacker can rewrite DOM methods from underneath you I don't see that as a valid security concern in this case. Yes, it will break your code or do unintended things. In order for this to happen an attacker must have access to the page in your user's security context, which means some other preventable security violation has already transpired. This applies equally with any application/language. Even if you could freeze the DOM such that nothing can be assigned to object properties then you might be able to ward off DOM clobbering, but there is still a malicious user in your security context reading all your secure and private details. If you prevent the malicious agent from access this security concern with the DOM is eliminated. In other words whether or not DOM clobbering occurs a prerequisite security violation is necessary and hardening the DOM won't provide the necessary solution. Aside from malicious third parties intentionally writing over event handler assignments DOM clobbering really comes down to poor code management, which is the real security problem here. That makes this a stylistic concern. Additional layers of concerns isn't going to make people instantly less lazy. There are better ways to solve for this. > HTML elements implemented in completely different ways HTML is not the DOM. These are separate and unrelated technologies that are maintained in very different specifications. This separation is not an accident. It is by design. I know this is a contentious point, about HTML and the DOM being far separated.
    - jorangreef 7y ago
      "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-clobbering-issue/ 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.
      - austincheney 7y ago
        How does the security aspect of DOM clobbering occur without injecting malicious code into a page?
        jorangreef 7y ago
        Again, see Fastmail's introduction: https://fastmail.blog/2015/12/20/sanitising-html-the-dom-clobbering-issue/ 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.

austincheney 7y ago

It's slide 27.

jorangreef 7y ago
That's not referring to stylistic concerns, and it's not bashing the DOM per se. The context of "The DOM is a mess!" on slide 27 is specifically in terms of security, namely "DOM Clobbering" where an attacker can rewrite DOM methods from underneath you, and impedance mismatch owing to parser differences and bugs ("HTML elements implemented in completely different ways, different attribute handling" in the context of defending against XSS). It's an honest assessment that's more a statement of fact than anything intended to be hurtful. It's not even a harsh statement of truth at that. I find it hard to believe that Chrome or Firefox engineers would find that offensive. I think they would well agree. DOMPurify is really fantastic security work. It would make for a brilliant contribution to the DOM.
- austincheney 7y ago
  > namely "DOM Clobbering" where an attacker can rewrite DOM methods from underneath you I don't see that as a valid security concern in this case. Yes, it will break your code or do unintended things. In order for this to happen an attacker must have access to the page in your user's security context, which means some other preventable security violation has already transpired. This applies equally with any application/language. Even if you could freeze the DOM such that nothing can be assigned to object properties then you might be able to ward off DOM clobbering, but there is still a malicious user in your security context reading all your secure and private details. If you prevent the malicious agent from access this security concern with the DOM is eliminated. In other words whether or not DOM clobbering occurs a prerequisite security violation is necessary and hardening the DOM won't provide the necessary solution. Aside from malicious third parties intentionally writing over event handler assignments DOM clobbering really comes down to poor code management, which is the real security problem here. That makes this a stylistic concern. Additional layers of concerns isn't going to make people instantly less lazy. There are better ways to solve for this. > HTML elements implemented in completely different ways HTML is not the DOM. These are separate and unrelated technologies that are maintained in very different specifications. This separation is not an accident. It is by design. I know this is a contentious point, about HTML and the DOM being far separated.
  - jorangreef 7y ago
    "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-clobbering-issue/ 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.
    - austincheney 7y ago
      How does the security aspect of DOM clobbering occur without injecting malicious code into a page?
      - jorangreef 7y ago
        Again, see Fastmail's introduction: https://fastmail.blog/2015/12/20/sanitising-html-the-dom-clobbering-issue/ 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.