[Ur] Supporting 'style' attribute securely

[Alexei Golovko]

xss-sanitize package contains filtering of CSS; maybe, you can follow the same approach. (The concrete code is even too restrictive, for example rejects z-index, because its goal is to filter _user_ input, not programmer's.)
https://github.com/yesodweb/haskell-xss-sanitize/blob/master/Text/HTML/SanitizeXSS/Css.hs

It allows a set of safe parsers like "read number and CSS unit", "read 'rgb(', three comma-separated numbers, ')'" etc; in urweb we need not parse strings but only declare appropriate set of constructors and define rendering for them; and implement syntax sugar at compile time.



And I disagree that compiler should prevent things like phishing through absolute positioning etc. Compiler should be safe with respect to _programmer's_ errors; this also means that user data can't appear in unsafe place unintentionally, without explicit parsing of this data. But if programmer do explicit parsing, compiler can not check correctness --- for example, if I use plain text design of forum, for safe input I need check alignments (that is leading spaces), compiler can't help me in this question.



22.04.2012, 18:29, "Adam Chlipala" <adamc at impredicative.com>:
> Sorry for the late reply; been working on a few modest compiler
> improvements, and now I'm ready to think about this again!
>
> Edward Z. Yang wrote:
>
>>  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.
>
>>     - A trivial example: background-color:expression(...) causes JavaScript execution
>>       in Internet Explorer.
>
> 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"?
>
>>     - The background CSS property takes an embedded URL, so it is neither pure URL
>>       nor pure text.
>
> Does my proposal above deal adequately with this one?
>
>>     - User provided styles can be used to implement phishing; via absolute
>>       positioning user-controlled links on top of normal ones.
>
> Perhaps it's worth including a special case for the "position" property,
> with an explicit whitelist of choices?
>
>>     - The innerHTML attack: foo.innerHTML = foo.innerHTML is not an idempotent
>>       operation; if applied multiple times you "lose" levels of backslash escaping.
>
> 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?
>
>>     - Treatment of escape sequences is inconsistent across browsers; for example,
>>       numeric escapes don't work in many contexts.  You have to very carefully
>>       pick the escaping function you want.
>
> So perhaps we just disallow (in CSS style code) all characters that need
> escaping?
>
>>     - Font-families are another can of worms, because they're "unrestricted" but
>>       subject to the above problems.
>
> Can you give an example of some funny business with font families?
>
> _______________________________________________
> Ur mailing list
> Ur at impredicative.com
> http://www.impredicative.com/cgi-bin/mailman/listinfo/ur