Last modified: 2014-10-25 00:58:32 UTC
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
How much is the toolserver used for this sort of edittng?
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.
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
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.
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
It's not Toolserver-specific, or even strictly Wikimedia-specific. Toolserver tools designed for Wikimedia wikis just happen to be what prompted the complaint.
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.
Didn't realize how much I used Dab Solver and Reflinks until I upgraded to IE8 and can no longer use the tools :-(
(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?
(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.
(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
Maybe add an editfilter to catch these errors?
The closure of this bug seems to be based on a misunderstanding. At the very least, it was premature. Reopening.
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.
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.)
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.
(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.
(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.
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.
