Server-side HTML sanitization is a familiar web application building block, yet despite years of offensive security research, defensive “sanitizer science” is still a kind of voodoo magic. This talk will make the case that as server-side HTML sanitizers lack the ability to effectively simulate every potential user agent, the client itself is the only party empowered to perform accurate sanitization. We will examine the DOM API primitives required to perform such client-side sanitization and review results and learning from a prototype implementation.

1. David Ross
Principal Software Security Engineer
Trustworthy Computing Security
Microsoft

2. @randomdross

5. *

6. @NealPoole
https://t.co/5omk5ec2UD

8. @kkotowicz
@NealPoole @adam_baldwin

9. @sneak_
@superevr

11. difficult

13. • No independent parsing / context handling

14. everything else

15. document.implementation.createHTMLDocument

16. document.createTreeWalker

17. 3. Remove elements / attributes / etc. not explicitly allowed*
*Old (less-performant) approach:
Build yet another DOM by copying safe
elements / attributes / etc. to a new
DOM during tree walk

20. document.implementation.createHTMLDocument
Must never run script

22. setAttribute

24. promises / deferreds

28. [Demo] [Benchmark]
Options precedence / inheritance rules:
(Options specified on target
element) > (options specified on
sanitize() call) > (default options)

32. Mario Heiderich @0x6D6172696F
JSAgents / IceShield
Gareth Heyes @garethheyes
JSLR
Ben Livshits
Loris D’Antoni
FAST
Caja HTML sanitizer
Stefano Di Paola Eduardo ‘Sirdarckcat’Vela N.

34. I just presented on HTML sanitization at OWASP AppSec EU 2013. AMA! (self.AMA)
1 Submitted 1 second ago by randomdross
0 comments share