Created attachment 8433125 [details] 4.png Hello. This is my second report. https://addons.mozilla.org/ is vulnerable to xss. Have a look at the screenshots.
Created attachment 8433128 [details] 2.png enter the following script in the name field: "><svg/onload=alert(document.domain)> and click save.
Created attachment 8433129 [details] 5.png After saving this page will appear. Just click on Edit Collection.
Created attachment 8433133 [details] final.png when you click Edit collection, the editor will open and will give you the stored xss pop uo due to the vulnerability in the name field.
Here are all the details: Vulnerable Link: https://addons.mozilla.org/en-US/firefox/collections/vergiltest/svg-onload-alert-document/edit/ Vulnerable Field: <input id="id_name" class="long" type="text" value=""><svg/onload=alert(document.domain)>" name="name"></input> Scripts Used: "><svg/onload=alert('X-S-S')> "><svg/onload=alert(document.domain)> "><svg/onload=alert(document.cookie)> Thanks, Umer
Where is the "cross-site" scripting coming from? You can't edit someone else's collections so you can't send an unsuspecting victim there.
Daniel Veditz [:dveditz]. I did not mailed as the bug bounty program guided to file a bug through the bugzilla form. Well in this case I have already filed the bug via bugzilla, and as you told I have emailed the report as well. Kindly guide me now, where to track the bug details, via email or via the bugzilla bug 1019429 portal?
This looks like a duplicate of bug 780438, but that one is marked FIXED. Is that code not pushed to the servers?
(In reply to Daniel Veditz [:dveditz] from comment #8) > This looks like a duplicate of bug 780438, but that one is marked FIXED. Is > that code not pushed to the servers? This bug is slightly different from bug 780438. The other bug deals with an XSS for addons in the collection. This bug is for the collection name in the editor. I was able to reproduce with a different payload since the page wanted a name < 30 characters. "><svg/onload=alert(document)>
(In reply to Umer Shakil from comment #7) > Daniel Veditz [:dveditz]. I did not mailed as the bug bounty program guided > to file a bug through the bugzilla form. Yup, filing the bug is step one (although you missed the confidential checkbox). The next step is just after that: "Notify the Mozilla Security Group by email and include the number of the bug you filed".
> (In reply to Daniel Veditz [:dveditz] from comment #8) > I was able to reproduce with a different payload since the page wanted a name < 30 characters. Yeah, I confirmed it too, but was surprised not to have found a dupe since I'm sure we've seen this many times before (not just "this type", but specifically with collections).
So this bug is valid?
David: a self-xss is not sec-high. Are you seeing a way to get this payload stored?
(In reply to Umer Shakil from comment #12) > So this bug is valid? valid, but rated as low due to self-xss so likely not eligible for a bounty
how can it be a self xss? when it is giving you the the pop up everytime you visit the page? it stored the value and next time you visit the page u can see the script stored ad well like ""> plus the pop up. Self xss is just like reflected ones, but they are generated on temperorily basis. This vulnerability is giving you the cookie of the user, I can send this page to anybody else like phishing is done you know, he will use this page and his cookies can be intercepted. So how can it be rated as self xss when its storing the complete scripts without any filtering, and its normal for normal users but not for the attackers who know how to trick or attempt phishing and data interception.
bug 808391 is this bug, but was duped to bug 780438. Is that fix not yet pushed (weeks after landing) or was 808391 incorrectly duped? Same with bug 1002173, this issue, duped to bug 780438
(In reply to Umer Shakil from comment #15) > how can it be a self xss? when it is giving you the the pop up everytime you > visit the page? It gives _you_, who created it, the popup every time. No other user can edit a collection you created and they see an error page when following your link. > This vulnerability is giving you the cookie of the user, In this case it doesn't, the cookies are all analytics useless junk (the real session id cookies are httponly), but that's obviously not the only bad thing you can do with a real XSS vuln. > I can send this page to > anybody else like phishing is done you know, he will use this page and his > cookies can be intercepted. So how can it be rated as self xss when its > storing the complete scripts without any filtering, and its normal for > normal users but not for the attackers who know how to trick or attempt > phishing and data interception. I agree that if you could send this link to any random person (or even "any random person already logged-in to AMO") and get the script to run it would be a bad "sec-high" problem. If that's what you see then we're missing some steps.
(In reply to Daniel Veditz [:dveditz] from comment #13) > David: a self-xss is not sec-high. Are you seeing a way to get this payload > stored? It is possible to attack other users by adding them as a contributor and making the collection non private. You can rename the URL to be something not as obvious as "alert(...)". The user will still have to visit the edit page, but the script will execute.
Bug 780438 is live. It's possible it didn't completely fix the bug, or it's possible this is something else. I can assign it to :ybon who closed the last bug. We currently update AMO once a month unless something critical is found (https://wiki.mozilla.org/AMO/Updating). sec-low would go out with our regular push.
Wil: dchan's convinced me this is sec-high since you can make someone an unwilling contributor and then send them there (assuming they have an AMO account, but they're only worth attacking with XSS if they're an addon author or site admin). do you see an alert on https://addons.mozilla.org/en-US/firefox/collections/dchan2/sec-things/edit/ (if you're logged into amo with your @mozilla.com account)?
Ok, putting as a P1. This will go out on Jun 11. Yohan - let us know any questions/concerns.
Kindly update me with the final details when this is concluded. I will be waiting. Thanks, Umer
Very close to Bug 780438 but in another place. PR https://github.com/mozilla/olympia-security/pull/9 (private repo until it lands)