Sorry, I am not being clear (and my thinking might be a bit muddled, too). I was just going through the list of XSS issues and seeing what, if we assume browser normalization, do they all boil down to, for my own benefit really.
We're discussing the security of messages added to the DOM, from JavaScript, via jQuery objects. So there's three things, I think, to consider.
1 - security of original message string. I'm still talking to the i18n team about this, will report later.
2 - security of parameters you add to messages, e.g. $('.user-name').msg( 'user-name-here', user.name );
This is complicated because we by design we accept entire jQuery nodes as arguments, which can do anything.
I think the issue here is to make it clear, to the developer, when they are adding a jQuery node and when they aren't. That is, if they enter a string, don't automatically promote it into a jQuery object. Because from their perspective, they might be adding a user's name to a DIV, but the malicious user might have made their name contain a SCRIPT tag. I think I fixed that adequately yesterday.
3 - from the output jQuery node, stripping out certain things just out of sheer paranoia
My last message was referring to (3) only -- what might we do to be extra safe, if somehow we miss things in 1 and 2. In this case we're just making reasonable guesses about what we think reasonable users of the library will want to do.
For instance while I can see justifications for injecting a form field with JavaScript behavior into a message, I can see no reason why you would ever add an entire SCRIPT tag into a message. That seems likely to be evil.
But you're right, maybe a whitelist approach is better there.
On 1/24/12 3:57 PM, bawolff wrote:
Message: 10 Date: Tue, 24 Jan 2012 15:43:14 -0800 From: Neil Kandalgaonkarneilk@wikimedia.org To: Wikimedia developerswikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Escaping messages Message-ID:4F1F4212.9050003@wikimedia.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 1/23/12 9:59 PM, Daniel Friesen wrote:
2 - We could ensure that the message library never emits scripts, by applying a simple jQuery filter to the final result.
Don't delude yourself into thinking that you can easily blacklist the elements that would run a script. http://ha.ckers.org/xss.html
Thanks for the pointer. You're right, I wasn't being careful enough.
Even so I think we have some reason for limited optimism in this case, because jQuery operates on nodes in browser, not strings on the server. Adding something to a DOM usually normalizes it, so there's less chance of missing something due to unusual ways of encoding, escaping, or delimiting input.
As far as I know these are the main dangers:
- SCRIPT, STYLE tags
- LINK, IFRAME, FRAME, FRAMESET, META, OBJECT, EMBED tags
- inherently scripted attributes, such as "onclick".
- attribute values beginning with 'javascript:', 'vbscript:',
'mocha:', 'livescript:', matched case-insensitively.
- hardest one: element styles with values that, once cleaned of
comments, contain the script words above or /expression(.*)/
However there are other dangers too. Yesterday I discovered that in Chrome, a script will be executed if you .append() it to anything, even if it's not part of the document. Annoying.
Anyway I'm not going to war on this, but some reasonable efforts can be made.
-- Neil Kandalgaonkarneilk@wikimedia.org
That's a really scary approach to security in my opinion. Well its true that browsers may generally normalize things, are we sure every browser ever made (including browsers not yet released) do that? Are we sure there isn't certain weird situations (aka bugs) where the browser would not normalize something, etc.
Things should either be escaped totally (So we know its safe), or not escaped at all (so we know its dangerous and treat it as such). Half measures of just stripping some tags on a blacklist will lull people into a false senses of security.
-bawolff
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l