Hey,
Do we trust that messages do not have evil (XSS) stuff in them? The reason why I ask is that I was just using .msg from mediawiki.jqueryMsg, and realized that things in the message do not get escaped. Since the function can take in HTML elements, this seems to be pretty inherent.
Is this "properly" escaped? (Any HTML in the message is not.) http://pastebin.com/XaWL2bVJ
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
On 16 January 2012 20:22, Jeroen De Dauw jeroendedauw@gmail.com wrote:
Hey,
Do we trust that messages do not have evil (XSS) stuff in them?
Ignoring the "how" for a moment, I personally think that no new uses of unescaped message output should be introduced, and we should get rid of the existing ones. -Niklas
On Mon, Jan 16, 2012 at 7:22 PM, Jeroen De Dauw jeroendedauw@gmail.com wrote:
Hey,
Do we trust that messages do not have evil (XSS) stuff in them? The reason why I ask is that I was just using .msg from mediawiki.jqueryMsg, and realized that things in the message do not get escaped. Since the function can take in HTML elements, this seems to be pretty inherent.
jQueryMsg doesn't really do this very well just yet, that's an issue with jQueryMsg.
Roan
On Mon, Jan 16, 2012 at 7:22 PM, Jeroen De Dauwjeroendedauw@gmail.com wrote:
Do we trust that messages do not have evil (XSS) stuff in them?
MediaWiki will sanitize tags it does not recognize. Unless you find a flaw in the sanitizer, you can't put a working <script> in a message string.
On 1/22/12 10:26 PM, Roan Kattouw wrote:
jQueryMsg doesn't really do this very well just yet, that's an issue with jQueryMsg.
It already does escaping, it just trusts jQuery to do it. So a string that doesn't "look" like HTML is already escaped just fine. But if it does look like HTML, for convenience' sake, it gets turned into jQuery.
Since it's a frontend library, we have a lot less to worry about. The one case I see is when we have non-sanitized, user-contributed data, that we got from the server, used in HTML parameters. Like, someone saying their first name is '<script src="evil.js"></script>'.
The whole point of the library is to allow you to pass in jQuery objects into a message. But, we could make that safer:
1 - Right now, the library allows you to pass HTML in a string, as a convenience. We could instead make it that all strings are assumed to be Just Strings, and escape them on the way in. So you couldn't use '<b>foo</b>' as a parameter, you'd have to declare your intention that it should be HTML by passing a real jQuery object. This may break old code in a few places, but not many.
2 - We could ensure that the message library never emits scripts, by applying a simple jQuery filter to the final result.
On Mon, 23 Jan 2012 14:45:14 -0800, Neil Kandalgaonkar neilk@wikimedia.org wrote:
On Mon, Jan 16, 2012 at 7:22 PM, Jeroen De Dauwjeroendedauw@gmail.com wrote:
Do we trust that messages do not have evil (XSS) stuff in them?
MediaWiki will sanitize tags it does not recognize. Unless you find a flaw in the sanitizer, you can't put a working <script> in a message string.
There are numerous places where wfMsg is used directly and dropped right into html. It's something we'd love to eventually kill. But yes, there are messages you can put a <script> into and have it executed.
On 1/22/12 10:26 PM, Roan Kattouw wrote:
jQueryMsg doesn't really do this very well just yet, that's an issue with jQueryMsg.
It already does escaping, it just trusts jQuery to do it. So a string that doesn't "look" like HTML is already escaped just fine. But if it does look like HTML, for convenience' sake, it gets turned into jQuery.
Since it's a frontend library, we have a lot less to worry about. The one case I see is when we have non-sanitized, user-contributed data, that we got from the server, used in HTML parameters. Like, someone saying their first name is '<script src="evil.js"></script>'.
The whole point of the library is to allow you to pass in jQuery objects into a message. But, we could make that safer:
1 - Right now, the library allows you to pass HTML in a string, as a convenience. We could instead make it that all strings are assumed to be Just Strings, and escape them on the way in. So you couldn't use '<b>foo</b>' as a parameter, you'd have to declare your intention that it should be HTML by passing a real jQuery object. This may break old code in a few places, but not many.
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
On 24 January 2012 06:59, Daniel Friesen lists@nadir-seen-fire.com wrote: ..
Don't delude yourself into thinking that you can easily blacklist the elements that would run a script. http://ha.ckers.org/xss.html
What about using textNodes? http://stackoverflow.com/questions/476821/is-a-dom-text-node-guaranteed-to-n...
On Tue, 24 Jan 2012 06:16:48 -0800, Tei oscar.vives@gmail.com wrote:
On 24 January 2012 06:59, Daniel Friesen lists@nadir-seen-fire.com wrote: ..
Don't delude yourself into thinking that you can easily blacklist the elements that would run a script. http://ha.ckers.org/xss.html
What about using textNodes? http://stackoverflow.com/questions/476821/is-a-dom-text-node-guaranteed-to-n...
Then it's just text. That's about as safe as throwing everything through htmlspecialchars, it's fine.
I'm saying that you can't blacklist things. ie: You can't run a message through a jquery message filter, try to strip out script tags from the dom and then insert it thinking that you've removed all the XSS vectors.
On 24 January 2012 15:57, Daniel Friesen lists@nadir-seen-fire.com wrote:
On Tue, 24 Jan 2012 06:16:48 -0800, Tei oscar.vives@gmail.com wrote:
On 24 January 2012 06:59, Daniel Friesen lists@nadir-seen-fire.com wrote: ..
Don't delude yourself into thinking that you can easily blacklist the elements that would run a script. http://ha.ckers.org/xss.html
What about using textNodes?
http://stackoverflow.com/questions/476821/is-a-dom-text-node-guaranteed-to-n...
Then it's just text. That's about as safe as throwing everything through htmlspecialchars, it's fine.
I'm saying that you can't blacklist things. ie: You can't run a message through a jquery message filter, try to strip out script tags from the dom and then insert it thinking that you've removed all the XSS vectors.
People on the internet suggest something like $("<div/>").text( "<script>alert('lets do evil!')</script>" ).html();
postdata: Some random code I just wrote.
var Stringbuilder = (function(){ var text = []; return { add:function(txt){ text.push(txt); return this;}, encode:function(txt){ text.push( new String( $("<div/>").text( txt ).html() ) ); return this;}, toString:function() { return text.join(""); } }; });
var str = Stringbuilder();
str.add("<table>") . add("<tr>") . add("<td>") . encode("<script>alert('lets do evil!)</script>") . add("</td>") . add("</tr>") . add("</table>");
str.toString();
Tei schrieb:
People on the internet suggest something like $("<div/>").text( "<script>alert('lets do evil!')</script>" ).html();
Please don't use that. We have mw.html.escape(), which does the task fine.
As Neil already pointed out, there are 2 concerns:
1 - security of original message string
Not a js problem, I'd say. When there are unsafe messages, the whole site has a problem
2 - security of parameters you add to messages
Just mw.html.escape them. And if someone should really need to add dom parameters, we may accept DOM-nodes/jQuery-objects. And we won't have to escape them, because when there are already malicious elements in the page the problem is not in mw.message.
So not taking html strings as parameters is the easiest, best and imho only solution.
Bergi
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.
wikitech-l@lists.wikimedia.org