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 Kandalgaonkar<[email protected]>
To: Wikimedia developers<[email protected]>
Subject: Re: [Wikitech-l] Escaping messages
Message-ID:<[email protected]>
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 Kandalgaonkar<[email protected]>
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
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
Neil Kandalgaonkar <[email protected]>
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
