XSS in Edit Review Functionality of AMO (rating POST parameter is vulnerable)

RESOLVED FIXED

Status

addons.mozilla.org Graveyard
Administration
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: Ashar Javed, Assigned: scolville)

Tracking

({sec-low, wsec-selfxss})

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
Created attachment 8705622 [details]
xssinratingparamter-domain1.PNG

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36

Steps to reproduce:

Hi,

I found an XSS in Edit Review Functionality in Mozilla Add-on site. If you're a logged-in user and had reviewed any add-on (this feature is available to all logged-in users), then your reviews can also be seen here:

https://addons.mozilla.org/en-US/firefox/user/usernamegoeshere/

Along with each review, one can see a Edit Review link. If you will click on Edit Review, the URL looks like ..

https://addons.mozilla.org/en-US/firefox/user/[username]/#review-edit-form

Fill the form with any values. The point of interest in this POST request when you will submit the edit review form after editing is "rating" parameter. 

You can change the "rating" parameter to any XSS vector e.g., '"><img src=x onerror=confirm(document.domain)>and it reflects back without encoding. 




Actual results:

It results in a JavaScript code execution. The screen-shot is also attached.


Expected results:

Output encoding at this time is missing. Though site is doing good when you change the rating parameter at the time of Add a new review (https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/reviews/add). At that time site properly encodes the output but you missed this at the time of Edit a Review.

Comment 1

2 years ago
Ashar -- is that Edit Review's page visible to users other than yourself? Are you able to get the reflect XSS when logged in as a separate user, or not logged in?
Flags: needinfo?(justashar)
(Reporter)

Comment 2

2 years ago
No. It does not reflect for the other user. The exploitation for this case is hard given Self-XSS.
Flags: needinfo?(justashar)
(Reporter)

Comment 3

2 years ago
Hi. No progress on this bug. I think it is because of low profile XSS or ...

Comment 4

2 years ago
Sorry about that, it's been a busy week.  :)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: sec-low, wsec-xss
Summary: XSS in Edit Review Functionality of https://addons.mozilla.org (rating POST parameter is vulnerable) → XSS in Edit Review Functionality of AMO (rating POST parameter is vulnerable)
(Reporter)

Comment 5

2 years ago
It was just a reminder and it seems it worked out :) Bug status has been changed :)

Comment 6

2 years ago
Stuart, whilst you are looking at CSP etc, could you take a quick look at this please? Its a self XSS so very low priority.
Assignee: nobody → scolville
Component: Add-on Security → Administration
PR: https://github.com/mozilla/addons-server-security/pull/27
Status: NEW → ASSIGNED
Fix is committed - should be rolled out shortly. https://github.com/mozilla/addons-server/commit/29e7607aefc08c3b2e4f07c4e055b0c5575253b8
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
Fix is on prod.
(Reporter)

Comment 10

2 years ago
Good! Can you make it open? It is closed for public viewing.

Comment 11

2 years ago
Done!
Group: client-services-security
Keywords: wsec-xss → wsec-selfxss
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.