[Ur] Supporting 'style' attribute securely

[Edward Z. Yang]

Excerpts from Adam Chlipala's message of Sun Apr 22 10:28:41 -0400 2012:
> > I can give a few examples, and we can patch them up, but perhaps
> > the bigger question is how adversarial we consider our users.
> > In an adversarial setting, the only secure policy is a whitelist
> > policy, and given the complexity of CSS you really need more
> > types than URLs and strings.
> 
> Do you think it should be possible to partition CSS properties into 
> those that are always safe to apply locally, and those that aren't?  
> Then the compiler could have two modes, to control whether the "unsafe" 
> properties are included.
> 
> 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.)

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...

The point is that developers do stupid shit, and in particular:

    - If something "doesn't work", they will fiddle with all the
      knobs until it does work: it is in our best interests to
      make sure that if what they're doing is wrong, they have
      turned a knob that looks obviously dangerous (ala
      unsafePerformIO).

    - They are thinking about a specific use-case, where the
      tool is actually a lot more general than they intended.
      This is the class of security bugs where the dev
      simply failed to think about "what happens if".  Being
      enlightened PL designers, we should design our language
      so that this is not a problem.

> 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!

> Does my proposal above deal adequately with this one?

In my experience, pretending that things are lists of items does OK.

> 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.

> This one I'm not sure applies to Ur/Web.  Are you thinking of a case 
> where a problem could arise from this property, outside of 
> project-specific JavaScript code accessed with the FFI?

Yes. Ur/Web being full stack might be able to get away with it.

> So perhaps we just disallow (in CSS style code) all characters that need 
> escaping?

Pretty reasonable.  You can do fancier tricks to allow for more characters,
but empirically people don't tend to need these things.

> 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

Edward