Embed Size (px)
DESCRIPTION
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.
Citation preview
David RossPrincipal Software Security EngineerTrustworthy Computing SecurityMicrosoft
@NealPoolehttps://t.co/5omk5ec2UD
@kkotowicz@NealPoole @adam_baldwin
difficult
• No independent parsing / context handling
everything else
document.implementation.createHTMLDocument
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
document.implementation.createHTMLDocument
Must never run script
setAttribute
promises / deferreds
[Demo] [Benchmark]
Options precedence / inheritance rules: (Options specified on target element) > (options specified on sanitize() call) > (default options)
Mario Heiderich @0x6D6172696FJSAgents / IceShield
Gareth Heyes @garethheyesJSLR
Ben LivshitsLoris D’Antoni
FAST
Caja HTML sanitizer
Stefano Di Paola Eduardo ‘Sirdarckcat’ Vela N.
I just presented on HTML sanitization at OWASP AppSec EU 2013. AMA! (self.AMA)
1 Submitted 1 second ago by randomdross
0 comments share
![Robust JavaScript [50min] · iframe sandbox same-origin policy CORS content security policy html sanitization. A software architecture view of security ... Modularity: avoid needless](https://img.pdfslide.us/doc/110x75/5f447aebcf0dce16702e7afc/robust-javascript-50min-iframe-sandbox-same-origin-policy-cors-content-security.jpg)
