Comments on: Bulletproof Rich-content Filters

By: arshan

arshan — Thu, 24 Apr 2008 03:50:10 +0000

there are a few problems with using xsd after you turn the input into the predictable xhtml format. if i had not been so rushed and drained in san jose we could have talked about this.

a) xsd is a blanket yes/no validation, so the application can’t provide the user any feedback on how their input was altered. you may want to prevent any information leakage if you’re a hardcore security person, but that’s not very usable, especially for the myspace scenario when you want to help the user tune their input. i want the antisamy project to be an enabler – help give the little guy some functionality that has been totally reserved for the big players, and feedback is one way antisamy can differentiate you from others, safely.

b) an xsd would have a very difficult time parsing cascading style sheets (which AntiSamy does, safely). if you’re attacking antisamy, you can’t provide a z-index, position values other than auto/inherit, and other CSS tricks that could lead to phishing.

c) since antisamy doesn’t retain all the extra functionality that an xsd parser has, it has a lighter footprint and doesn’t have any of the xsd parser’s attack surface.

there are benefits of using xsd, of course: speed, stability, better supported code.

By: ArkanoiD

ArkanoiD — Sun, 30 Dec 2007 21:20:08 +0000

I’d go for schema for “compliance” and XPath-based filter for extra filtering rules if there is need in more restructions..

By: pdp

pdp — Thu, 20 Dec 2007 10:00:22 +0000

yes, I see your point. I don’t see why it shouldn’t be possible to strip out anything that does not much the XML Definition. Though, I am not aware of how this can be done in practice. It might be the case of converting the XML Definition into XML Stylesheet which only extract the parts that are safe and produce a normalized document. That might be a good solution.

By: Sverre Johansen

Sverre Johansen — Thu, 20 Dec 2007 08:38:59 +0000

That would be a usability tradeoff, in my opinion. It is probably OK for small texts such as comments and descriptions, but not that suited for larger content such as a blog post. People are used to being able to write tagsoup and the browser will figure it out for them, it’s really the same with security validation. A blogger might not know that the recipe he found for having a floating CSS menu (or whatever), could also be used for phishing. The content could even be something produces by Microsoft Word.

It’s kind of like how the web works, even if we like it or not :)

By: pdp

pdp — Wed, 19 Dec 2007 23:18:48 +0000

Sverre, hmmm, this is the hard bit. But I don’t see why you have to be so user friendly. If the markup looks different from what you allow you should really say stop to the user and ask them to rephrase their input.

By: Sverre Johansen

Sverre Johansen — Wed, 19 Dec 2007 23:07:59 +0000

If I understand you correct this parser would drop any message that contains invalid (evil) markup. What you usually want is a parser that drops the invalid parts and produces a safe version.

Is there any way of specifying what is legal in a formal way (like XML Schema, as you suggest, or RelaxNG), and then drop the invalid parts?

By: tenest

tenest — Wed, 19 Dec 2007 17:57:28 +0000

Not that this is a big deal, but XML Spy is by AltovA not AltovE. http://www.altova.com/

By: pdp

pdp — Tue, 18 Dec 2007 12:43:29 +0000

Thomas, sure I can, but it will be better if someone transmits the message to the people who need to know about it. :)

By: Thomas Roessler

Thomas Roessler — Tue, 18 Dec 2007 11:41:18 +0000

This sounds like the kind of stuff that the W3C HTML working group should hear.

See here for joining instructions: http://www.w3.org/html/wg/#who