[Esapi-dev] CSS encoding

[Jim Manico]

Jeff,

This may work but only if you get your expression blacklist correct,
something that I feel is rather fragile. And that code will need to change
over time as standards change.

Enterprise code rarely allows user-driven/untrusted data to drive style.
Here are a few uses cases that I see:

1) User can change style of entire page, based on a series of pre-set
styles: just re-load an entirely new CSS file from a trusted location. No
need to process untrusted style values at all.

2) User can change color of font, background or some other widget. In this
case I contextually and structurally validate the user selected hex color
CSS format both on input and output. Or I use a lookup map to allow the user
to select from a pre-selected list of colors from a trusted location. This
is really simple whitelist validation (or a lookup map), and this code will
never change over time regardless of how browsers change.

3) User can change font size. Like most media/news sites this can easily and
safely be done on the client by just incrementing font size via JS.

I feel that if programmers are doing anything much more complex than that
which requires output encoding or blacklist validation then they have a
design flaw of some kind.

I'm sorry to not answer your comments directly but can you give me a more
specific use case where CSS hex encoding and blacklist validation is
required in enterprise, eCommerce, banking, gov't or even modern social
network web software?

- Jim Manico

On Aug 5, 2011, at 9:40 PM, Jeff Williams <jeff.williams at owasp.org> wrote:

Hi Jim,



Could you take a look at this and see if you agree?

* *

* *

*Injecting Up*

*Injecting Down*

*Quoted Style Value*

You can “inject up” are with the " and ' tokens as well as the </style>
token which targets the HTML parser.

You can “inject  down” with the expression( token (IE7 and earlier only) and
any of the URL tokens (like background-image:url)

*Unquoted Style Value*

You can “inject up” with ; } and </style> and possibly other characters like
/* and @-rules

Same



Let me know if your understanding is different.  *
http://www.w3.org/TR/CSS2/syndata.html#tokenization



I’m nervous about attempting to build support for strictly validating all
the possible CSS property values. That seems difficult to me. I think there
are hundreds and then lots of extensions, particularly the –moz stuff.



If I have this right, then I think we can create a single “defusing” method
to handle these requirements. In fact, I think it’s as simple as adding some
logic to prevent the “expression(“ token and “javascript:” urls to our
current escaping method.



I don’t want to get into a terminology battle about whether this is
encoding, escaping, or validation.  I’m focused on making the value safe for
rendering in a CSS context.  I think of this as “defusing” attacks – so
maybe that’s a better name.



--Jeff





-----Original Message-----
From: esapi-dev-bounces at lists.owasp.org [mailto:
esapi-dev-bounces at lists.owasp.org] On Behalf Of Jim Manico
Sent: Thursday, August 04, 2011 2:19 PM
To: esapi-dev at lists.owasp.org
Subject: [Esapi-dev] CSS encoding



CSS hex encoding is an almost useless control due to IE expressions.

This is exactly why this control does not exist in .NET AntiXSS libraries.



When dealing with user driven CSS values, you •must• very strictly validate
both the characters and structure of the user driven CSS value.



I say we deprecate CSS encoding or at least fix the JavaDoc.



- Jim Manico

_______________________________________________

Esapi-dev mailing list

Esapi-dev at lists.owasp.org

https://lists.owasp.org/mailman/listinfo/esapi-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-dev/attachments/20110806/e45dd5f4/attachment.html