xss when editing a collection on addons.mozilla

RESOLVED FIXED in 2014-06

Status

addons.mozilla.org Graveyard
Collections
P1
critical
RESOLVED FIXED
4 years ago
a year ago

People

(Reporter: Umer Shakil, Assigned: ybon)

Tracking

(Blocks: 1 bug, {sec-high, wsec-xss})

unspecified
2014-06
x86_64
Windows 7
sec-high, wsec-xss
Bug Flags:
sec-bounty +

Details

(Whiteboard: [site:addons.mozilla.org][reporter-external][self-xss], URL)

Attachments

(5 attachments)

(Reporter)

Description

4 years ago
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.
(Reporter)

Updated

4 years ago
Severity: normal → critical
Component: Firefox Sync: Backend → Server: Core
(Reporter)

Comment 1

4 years ago
Created attachment 8433128 [details]
2.png

enter the following script in the name field:
"><svg/onload=alert(document.domain)>
and click save.
(Reporter)

Comment 2

4 years ago
Created attachment 8433129 [details]
5.png

After saving this page will appear. Just click on Edit Collection.
(Reporter)

Comment 3

4 years ago
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.
(Reporter)

Comment 4

4 years ago
Created attachment 8433134 [details]
cookie.png

Here is the cookie as well.
(Reporter)

Comment 5

4 years ago
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
Group: mozilla-services-security
Flags: sec-bounty?
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.
Group: mozilla-services-security → client-services-security
Component: Server: Core → Collections
Product: Mozilla Services → addons.mozilla.org
Summary: xss in addons.mozilla → self-xss when editing a collection on addons.mozilla
(Reporter)

Comment 7

4 years ago
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?
Group: client-services-security → mozilla-services-security
Component: Collections → Server: Core
Product: addons.mozilla.org → Mozilla Services
Summary: self-xss when editing a collection on addons.mozilla → xss in addons.mozilla
Whiteboard: [site:addons.mozilla.org][reporter-external] [dupem:780438?]

Comment 9

4 years ago
(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".
Group: mozilla-services-security → client-services-security
Component: Server: Core → Collections
Product: Mozilla Services → addons.mozilla.org
Summary: xss in addons.mozilla → self-xss when editing a collection on addons.mozilla
Whiteboard: [site:addons.mozilla.org][reporter-external] [dupem:780438?]

Updated

4 years ago
Blocks: 835438
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: sec-high, wsec-xss
Whiteboard: [site:addons.mozilla.org][reporter-external]
> (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).
(Reporter)

Comment 12

4 years ago
So this bug is valid?
David: a self-xss is not sec-high. Are you seeing a way to get this payload stored?
Flags: needinfo?(dchan)
Keywords: sec-high → sec-low
Whiteboard: [site:addons.mozilla.org][reporter-external] → [site:addons.mozilla.org][reporter-external][self-xss]
(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
Flags: needinfo?(dchan)
(Reporter)

Comment 15

4 years ago
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
Flags: needinfo?(clouserw)
Whiteboard: [site:addons.mozilla.org][reporter-external][self-xss] → [site:addons.mozilla.org][reporter-external]
(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.
Whiteboard: [site:addons.mozilla.org][reporter-external] → [site:addons.mozilla.org][reporter-external][self-xss]

Comment 18

4 years ago
(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.
Assignee: nobody → yboniface
Flags: needinfo?(clouserw)
Severity: critical → normal
Priority: -- → P2
Target Milestone: --- → 2014-06
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)?
Severity: normal → critical
Keywords: sec-low → sec-high
Flags: needinfo?(clouserw)
Ok, putting as a P1.  This will go out on Jun 11.  Yohan - let us know any questions/concerns.
Flags: needinfo?(clouserw)
Priority: P2 → P1
(Reporter)

Comment 22

4 years ago
Kindly update me with the final details when this is concluded. I will be waiting.
Thanks,
Umer
(Assignee)

Comment 23

4 years ago
Very close to Bug 780438 but in another place.

PR https://github.com/mozilla/olympia-security/pull/9 (private repo until it lands)
Flags: sec-bounty? → sec-bounty+
Summary: self-xss when editing a collection on addons.mozilla → xss when editing a collection on addons.mozilla
Duplicate of this bug: 1023249
(Reporter)

Comment 26

4 years ago
Thanks
Duplicate of this bug: 1023827
(Assignee)

Comment 28

4 years ago
Fixed in https://github.com/mozilla/olympia/commit/927efac6d848f7f893efb02c71bc01008930bb09
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Product: addons.mozilla.org → addons.mozilla.org Graveyard
Group: client-services-security
You need to log in before you can comment on or make changes to this bug.