[Ur] Supporting 'style' attribute securely

[Adam Chlipala]

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.