Re: "cleaning HTML for security"

Neil,

I'm agree with the js part. The CSS handling looks different. Today modern
email web clients parse the emails before the mail will be show. In this
way it is possible to read CSS classes and renamed it if there any problems
with the internal CSS.

CSS will be tricky in case of file size and external references, but there
no problem with a UI Hacking for web clients

Stefan
Am 17.11.2014 07:45 schrieb "Neil Jenkins" <neilj@fastmail.fm>:

>  For a generic API, I would say the main thing is to remove all forms of
> scripting (<script> tags, onX attributes, etc.) and all references to
> external plugins; these are security holes if they are allowed to run in
> the context of your application and are impossible to reliably sanitise.
> Browsers implementing this have a huge advantage in that they already have
> a full HTML5 parser, so if they need to sanitise an HTML string they can
> use this to parse out a tree, then it is trivial to walk the tree and use a
> whitelist of allowed tags and attributes to strip out any scripting
> elements before serialising it again. External systems doing this need to
> be wary of all the ways they can be tricked into parsing something one way,
> only for the browser to interpret it differently, making what you thought
> was a safe string suddenly be inside a script tag etc.
>
> One thing I would say is <noscript> contents should be *included* (since
> you're removing the scripting) but the tags themselves removed (since it
> will probably be injected into a context that *does* support scripting). We
> once had a security bug due to the unexpected interaction between
> <noscript> and comment tags.
>
> CSS is a tricky one; what should be allowed depends on the context it will
> be inserted into. In a webmail system you have to be careful to avoid
> conflict with existing styles and not allow the content to draw over your
> UI, which could lead to phishing attacks. iframes can be used to sandbox
> content, but bring a whole world of other problems unfortunately. However,
> the nice thing about CSS is that the JS of the application handling the
> paste can be used to sanitise the CSS as required, so I don't think it's
> necessary to do this at the browser level.
>
> Neil.
>
>