Edward Z. Yang wrote:
Excerpts from Adam Chlipala's message of Sun Apr 22 10:28:41 -0400 2012:
Perhaps a simpler policy, more in line with the current support for URL
policies, would be to allow whitelisting of properties by name, in .urp
files. This has the advantage of supporting new or browser-specific
properties without hardcoding them in the Ur/Web implementation.
If we're punting on the issue, sure, it kind of sounds reasonable.
(Though I've worked with this long enough to be kind of allergic
to half-way attempts.)
Perhaps, compared to HTML Purifier, a key difference here is that I'm
willing to expose only a drastically limited, but still useful, subset
of CSS? That's the same general approach I'm taking to HTML, SQL, etc.
Adopting that perspective, can you give a solid example of a likely bad
consequence of a "half-way" attempt?
A broader philosophical note: in an adversarial context, I
don't /trust/ developers to make the right judgment call on what
are safe to allow. URLs are relatively straightforward, and do
what people might think (although beware the wary eye of the URL
redirector on a trusted domain!), but it's easy to add support for
a CSS property without quite understanding the implications of
doing so...
My take on this point would be that it would be nice to provide a
library of .urp files corresponding to some reasonable whitelists of CSS
properties and values, written by experts, with prose descriptions of
what is being enabled and when it's appropriate.
Hm... so perhaps we also want a whitelist of "functions" that have
parens after them, and not allow parens in "text" property values?
Perhaps then a property value is a _list_ of items, each of which is
either paren-free text or a call to a whitelisted "function," with
special handling for the "url" "function"?
Might as well build in full understanding of CSS2.1 atomic data types; integers,
lengths, percentages, URLs, colors and strings. There aren't that many!
OK, that sounds reasonable.
Perhaps it's worth including a special case for the "position" property,
with an explicit whitelist of choices?
I don't know. It seems like an eminently reasonable thing for a developer
to what to put in position. The adversarial and non-adversarial cases
look /very/ different.
Which is why .urp files should be able to choose the mode.
Can you give an example of some funny business with font families?
Since fonts are "unrestricted text", they make a great vector for
taking advantage of browsers not understanding escape sequences properly.
Out of the four major security bugs HTML Purifier has had in its
entire lifetime, font-family was involved in two of them:
http://htmlpurifier.org/security/2010/css-quoting
http://htmlpurifier.org/security/2008/css-backslash
Ah, thanks, that's very useful. I was assuming the problem was in
interpreting the font files themselves, but I see it's just in embedding
of unrestricted strings in styles, with opportunities to make quoting
mistakes. Safety here should follow from the above plan to disallow
quote-worthy characters anywhere in CSS embedded in Ur/Web. Probably
I'd want to explicitly whitelist allowed characters, omitting many
printable ones that aren't usually quoted in programming languages,
since I see IE gets confused by exclamation marks.
_______________________________________________
Ur mailing list
[email protected]
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
