The XSS filter in IE8/9 breaks certain tools
OpenPublic

Description

Posting on behalf of User:Dispenser:

When POSTing data from the Toolserver to foundation wikis the cross-domain POSTing triggers the XSS Filter in Internet Explorer 8 and 9. [1] When the filter is triggered, usually with a Preview or Diff, it sanitatises the edit box of many non-alphanumeric characters as seen in [2]. A regular user is unaware the edit box's contents were changed from those present in the diff. Additionally, earlier flaws in the mangling heuristics introduced a "universal XSS" venerability. [3][4]

The suggested solution is disalbing the filter by setting the HTTP header X-XSS-Protection: 0 when submitting a form.

[1] http://blogs.msdn.com/b/ie/archive/2008/07/02/ie8-security-part-iv-the-xss-filter.aspx
[2] http://en.wikipedia.org/w/index.php?diff=454843408
[3] http://p42.us/ie8xss/Abusing_IE8s_XSS_Filters.pdf
[4] http://p42.us/ie8xss/wikipedia.png


Version: 1.17.x
Severity: normal

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz32013.
Emufarmers created this task.Via LegacyOct 28 2011, 3:52 AM
MarkAHershberger added a comment.Via ConduitOct 28 2011, 5:47 PM

How much is the toolserver used for this sort of edittng?

Emufarmers added a comment.Via ConduitOct 28 2011, 11:48 PM

http://toolserver.org/~dispenser/cgi-bin/rcput.py?offset=1 is his tool. He thought http://toolserver.org/~bryan/flickr/upload might also be affected, and there might be some non-Toolserver ones.

bzimport added a comment.Via ConduitNov 28 2011, 10:25 AM

zedlightman wrote:

I have used this tool many times:
*http://toolserver.org/~dispenser/cgi-bin/webreflinks.py

That page has this: "Got a Bugzilla account? Then vote for Bug 32013 so Internet Explorer 8 and 9 users can use my tools."

I use Firefox browser. Is this tool being effected by this bug when using Internet Explorer 8 and 9? If so, then I hope this bug is dealt with. Here is more info on this tool:
*http://en.wikipedia.org/wiki/User:Dispenser/Reflinks

bzimport added a comment.Via ConduitDec 3 2011, 8:46 PM

anneandadeson wrote:

I use Google Chrome, but would also like to support this as sometimes I use Explorer and it would be good to be able to use it then.

TTO added a comment.Via ConduitDec 12 2011, 6:45 AM

This would appear to be a Toolserver-specific issue? If so, it should be at Toolserver JIRA.[1] You'll probably get better service over there.

If not, this bug is filed in the wrong product (should be Wikimedia). Again, faster service.

[1] https://jira.toolserver.org/secure/Dashboard.jspa

Emufarmers added a comment.Via ConduitDec 12 2011, 9:35 PM

It's not Toolserver-specific, or even strictly Wikimedia-specific. Toolserver tools designed for Wikimedia wikis just happen to be what prompted the complaint.

Krinkle added a comment.Via ConduitFeb 29 2012, 12:05 AM

This bug is in the right place.

To come back at the issue at hand: You can work around this problem by offering your service via a Gadget instead of a Toolserver tool. The only down-side is that it is opt-in and users need to enable the gadget via the preferences.

The advantage is as follows: instead of having the user go to the Toolserver and submit back to the wiki, you can make a JSONP request to the toolserver, get the data you need, and insert it in the text-area and submit to preview/diff whatever.

GoingBatty added a comment.Via ConduitMar 16 2012, 4:02 AM

Didn't realize how much I used Dab Solver and Reflinks until I upgraded to IE8 and can no longer use the tools :-(

MarkAHershberger added a comment.Via ConduitMar 18 2012, 5:41 PM

(In reply to comment #7)

You can work around this problem by offering
your service via a Gadget instead of a Toolserver tool.

Krinkle,

Should we fix this so a workaround isn't needed?

Krinkle added a comment.Via ConduitMar 19 2012, 1:39 PM

(In reply to comment #9)

(In reply to comment #7)
> You can work around this problem by offering
> your service via a Gadget instead of a Toolserver tool.

Krinkle,

Should we fix this so a workaround isn't needed?

The workaround I suggested is a better coding pattern in general, I wouldn't consider it a workaround.

However in general POSTING to a MediaWiki edit-action should work. Although I wouldn't recommend doing it in any scenario, the bug is valid. But unless there is a way I don't know about, this is an upstream issue we can't do much about.

If I understand the problem correctly, the IE development team made a decision to now allow this type of submission and as such implemented an XXS filter to break it.

Reporting upstream to Microsoft will be pointless as this XSS filter is a decision by them, a feature, not a bug.

Even if there is any way to "fix" it from our side (it wouldn't be the first security leak in IE), as soon as we publish that fix it is not unlikely that IE will get a security update making that fix no longer work.

MarkAHershberger added a comment.Via ConduitMar 19 2012, 5:46 PM

(In reply to comment #10)

Although I
wouldn't recommend doing it in any scenario, the bug is valid. But unless there
is a way I don't know about, this is an upstream issue we can't do much about.

WONTFIXING

bzimport added a comment.Via ConduitMar 27 2012, 3:07 AM

headbomb_v wrote:

Maybe add an editfilter to catch these errors?

Emufarmers added a comment.Via ConduitMar 30 2012, 2:31 AM

The closure of this bug seems to be based on a misunderstanding. At the very least, it was premature. Reopening.

DanielFriesen added a comment.Via ConduitApr 2 2012, 6:59 PM

The XSS filter has been known to cause various problems, in some cases even introducing XSS injection where it never existed and the web app was secure from XSS holes.

Disabling this filter sounds like a good idea anyways. It's another IE 'feature' that Microsoft introduces that does little but make the web worse instead of better. Just like IE6's 'feature' we have to work around using text/text.

bzimport added a comment.Via ConduitApr 9 2012, 4:21 PM

jaga_x_1 wrote:

This bug is affecting the usefulness of at least one popular tool that I know of - namely, Dab Solver, one of Dispenser's tools. I've integrated Dab Solver into messages sent by a bot that tells people when they've added links to disambiguation pages. The bot is popular and successful, but many people have been prevented from fixing the dablinks due to this bug.

I saw the suggestion to covert Dab Solver to a Gadget. Not only that is tail wagging the dog, but it wouldn't be reasonable for DPL bot to ask users to opt into a Gadget just to fix dablinks. (Not to mention that many of the people I message are newbies that would be scared off by the instructions.)

Aklapper added a comment.Via ConduitMar 11 2014, 2:38 PM

Hmm, wondering if the same problem still happen using Tool Labs (instead of Toolserver), once http://tools.wmflabs.org/?tool=dispenser is set up properly.

Emufarmers added a comment.Via ConduitMar 12 2014, 5:17 PM

(In reply to Andre Klapper from comment #16)

Hmm, wondering if the same problem still happen using Tool Labs (instead of
Toolserver), once http://tools.wmflabs.org/?tool=dispenser is set up
properly.

Yes.

Krinkle added a comment.Via ConduitMar 12 2014, 6:01 PM

(In reply to JaGa from comment #15)

I saw the suggestion to covert Dab Solver to a Gadget. Not only that is tail
wagging the dog, but it wouldn't be reasonable for DPL bot to ask users to
opt into a Gadget just to fix dablinks. (Not to mention that many of the
people I message are newbies that would be scared off by the instructions.)

I was not suggesting converting anything to a Gadget. You misunderstood.

(Citing Krinkle from comment #7)

This bug is in the right place.

To come back at the issue at hand: You can work around this problem by
offering your service via a Gadget instead of a Toolserver tool. The only
down-side is that it is opt-in and users need to enable the gadget via the
preferences.

The advantage is as follows: instead of having the user go to the Toolserver
and submit back to the wiki, you can make a JSONP request to the toolserver,
get the data you need, and insert it in the text-area and submit to
preview/diff whatever.

I didn't explain it in great detail, but I think the author of the Dab Solver tool knows what I meant.

So instead of making a link on the wiki to the Toolserver tool, using the interface there, and then having the tool submit POST back to action=edit.

Instead, the gadget goes to action=edit, it makes a request to the Toolserver tool for all the data (all the logic and stuff is at the Toolserver, the Gadget is merely a gateway and your ticket of authorisation to send and receive information) using a JSON-P request that responds with the content you want to put it), and then the javascript gadget puts it in the edit field.

So you'd refactor your tool slightly to (if not already) have a pure data API, and use that from the Gadget. If you want you can even keep the user interface on the Toolserver as well and pop it up in an iframe in a jQuery UI dialog, though I'd recommend moving that little bit of code to the gadget, using a <form> created by javascript and some input fields, and on submit, in your callback you make that request to your API on the Toolserver (or Tool Labs now) and get back the data you ask for and use it.

This has the added benefit of the user not "leaving" their wiki during this experience, it's a more integrated experience and encourages good practices.

Aklapper added a comment.Via ConduitJun 24 2014, 5:12 PM

Feedback from Security:
<csteipp> I'd prefer to keep the header, and have the tool be updated (per comment #18)
<csteipp> anyone is welcome to submit a patch that adds the disabling header, based on a feature flag. WMF sites will most likely not enable that flag.

...so this is not considered high priority.

Add Comment