User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20100101 Firefox/14.0.1 Build ID: 20120713134347 Steps to reproduce: There is a reflective XSS on https://wiki.mozilla.org. Request to reproduce: GET /Special:Search?search=999"onmousemove="alert(1) HTTP/1.1 Host: wiki.mozilla.org Response (relevant part): <div id="breadcrumbs"> <a href="https://wiki.mozilla.org">Home</a> » <a href="https://wiki.mozilla.org/Special:Search?search=999"onmousemove="alert(1)"> Search: 999"onmousemove="alert(1)</a> </div> <h3 id="siteSub">From MozillaWiki</h3> <div id="contentSub"></div>
Group: mozilla-services-security → mozilla-corporation-confidential
Component: General → wiki.mozilla.org
Product: Mozilla Services → Websites
Group: mozilla-corporation-confidential → websites-security
Christian: I see the output properly escaped as " Is this the correct link https://wiki.mozilla.org/Special:Search?search=999"onmousemove="alert(1)
This code is terrible... http://viewvc.svn.mozilla.org/vc/projects/wikimo/trunk/skins/gmo.php?view=markup#l317 I can confirm this using `curl`. I haven't looked super-carefully yet, but perhaps wenzel already fixed it in r100350 (bug 714540)... Really hard to tell.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I can confirm the issue is still existing at the time of writing.
you confirm it using curl, or do you actually see this in any modern browser? Browsers ought to be escaping the " in the request as %22 which is then how it's returned in about 9 different links. One of those, the logout link, looks like it would have escaped the quote correctly but the others may not have (will have to look at the curl output). IIRC we've had other XSS bugs filed against wikimo (or media wiki generally, which is an upstream project) that only actually worked in curl and not browsers. Still, we can't assume that future browsers will be brilliantly written and/or follow the specs so media wiki ought to be escaping the output regardless.
I'm rating this sec-low on the assumption that other current browsers aren't dumb, but we should probably check older IE at least to be sure.
I reproduced using curl. But I would follow your last statement, plus one might be able to design auto-submitting forms to that destination that encode these chars so that they actually lead to execution in a browser. Fact is, the application is vulnerable in the sense that it does not encode output properly in this case. So I would always recommend edit the code accordingly. Btw, the response extract I provided should help to identify the spot. It is right below <div id="breadcrumbs">.
Daniel: sec-low is fine with me if you think that is reasonable, but keep in mind that there are various ways to issue a browser redirect. I'm pretty sure a versed attacker would be able to encode everything so that it actually executes, I don't have the expertise (tried...) or the time to come up with a working browser poc though.
FWIW, IT should be able to tell if the revision from comment 3 was actually deployed. If not, I suggest deploying it, then double-checking if this bug persists.
ok, we are going to non-qual this as we just can't come up with a working exploit. If anybody can come up with a proof of concept of this working in the future, we will be happy to qualify it as a bug to receive a bounty.
Just attached a video showing js execution due to this vulnerability in the browser. I've used Burp Suite pro for constructing an auto-submitting html form to the vulnerable location. Admittedly, I do not yet understand why browsers behave like this, but I think it shows the possibility for an exploit.
(In reply to Christian from comment #11) > Admittedly, I do not yet understand why browsers behave like this, but I > think it shows the possibility for an exploit. We need to see an exploit though. We can't see a working exploit, which is why this is non-qualified for a bounty.
I have not checked this specifically for XSS, but regardless there should be more filtering happening than what actually is. Here is output of a script I wrote to check common escaping issues: http://pastebin.mozilla.org/1863410 As you can see, quotes are not properly escaped in multiple locations and a > symbol is not escaped in occurrence 6.
Near as I can tell, this is gmo-skin specific and low-priority in terms of security. Due to limited resources, we're not addressing non-critical issues on deprecated themes. I suggest we close at as WONTFIX, unless there is a strong reason not to.
(In reply to Christie Koehler [:ckoehler] from comment #14) > Near as I can tell, this is gmo-skin specific and low-priority in terms of > security. Due to limited resources, we're not addressing non-critical issues > on deprecated themes. > > I suggest we close at as WONTFIX, unless there is a strong reason not to. I concur.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.