Closed
Bug 912440
Opened 11 years ago
Closed 11 years ago
XSS Reflected in support.mozilla.org
Categories
(support.mozilla.org :: General, defect)
support.mozilla.org
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: akkilionx, Assigned: willkg)
Details
(Whiteboard: [site:support.mozilla.org][reporter-external][verif?] u=user c=messages p=1 s=2013.19)
Attachments
(1 file)
448.47 KB,
image/jpeg
|
Details |
User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.62 Safari/537.36 Steps to reproduce: 1. You need to be registered on support.mozilla.org 2. Login and go to this link: https://support.mozilla.org/en-US/messages/new 3. Open LIVE HTTP Headers 4. Add a user on the field "to" (e.g add you account ) 5. In the body field you can write anything. 6. Press SEND button and then go to the Live HTTP Headers ! 7. Scroll up to the top and you will see: POST https://support.mozilla.org/en-US/messages/new POST Content: csrfmiddlewaretoken=cVhQKrlx5abrH7beZv2R06ZwOIexIQuQ&in_reply_to=&to=YOUR ACCOUNT&message=test&send= * &to=YOUR ACCOUNT (This parameter is vulnerable to XSS Reflected) 8. Then delete your account from "&to" field and add a javascript code ! (e.g POST Content: csrfmiddlewaretoken=cVhQKrlx5abrH7beZv2R06ZwOIexIQuQ&in_reply_to=&to="><SCRIPT>alert(1)</SCRIPT>&message=test&send= 9. Press Replay and the alertbox it will appear. Actual results: The alertbox it will appear and you can steal cookie, or to use it for phishing, redirect, etc. Expected results: The alertbox it will appear and you can steal cookie, or to use it for phishing, redirect, etc.
Updated•11 years ago
|
Assignee: nobody → ptheriault
Whiteboard: [site:support.mozilla.org][reporter-external][verif?]
assigned to paul to verify
Assignee | ||
Comment 2•11 years ago
|
||
cc:ing Ricky so he sees this bug as it progresses.
Reporter | ||
Comment 3•11 years ago
|
||
If you need a V.P.o.C, I will upload the video in case you can't reproduce the vulnerability. Regards, Darius Petrescu
Comment 4•11 years ago
|
||
I can reproduce this bug as described above. However I don't think this is actually exploitable due to the presence of a CSRF token. I don't have time to test this further today, but Darius, if you want to help, what would be very interesting to me is trying to create an actual exploit for this issue. I.e create the web page that actually exploits this issue that an attacker would get the victim to vicit. In my brief testing, I wasn't able to do this. Since it isn't possible to know the victim's valid CSRF token, the request induced by the attacker will result in a 403 forbidden response, instead of the xss code being run. So while this is more or less zero risk currently, we probably want to fix this anyways, since there may well be ways to exploit this issue. That is, the _to_ field should be sanitized to remove the risk entirely. PS I tested this on staging - https://support.allizom.org/en-US/messages/new?to=ptheriault Darius, thanks for your help, and please use our staging instance if you are doing further testing - this has the latest code, and doesn't matter if you create test data etc there.
Reporter | ||
Comment 5•11 years ago
|
||
I see it can't be exploitable ( by me )! I can't make something ... Can you tell me which is your last decision ? This bug can be elgibile for a reward ? But for a SELF XSS I don't think it is. Thank you Paul and have a nice day. PS This is my first bug reported, and not so good :( Regards, Darius
Assignee | ||
Comment 6•11 years ago
|
||
Sorry for responding late here. I appreciate any security work done on SUMO. It makes our users safer. Even though this particular issue doesn't seem to be exploitable, I really appreciate you pointing it out. I'll try to get it fixed soon. Thank you!
Comment 7•11 years ago
|
||
(In reply to Darius Petrescu from comment #5) > I see it can't be exploitable ( by me )! > I can't make something ... Can you tell me which is your last decision ? > This bug can be elgibile for a reward ? But for a SELF XSS I don't think it > is. > Thank you Paul and have a nice day. > > PS This is my first bug reported, and not so good :( > > Regards, > Darius Regarding bounty, support.mozilla.org is not covered by the bounty program. (see http://www.mozilla.org/security/bug-bounty-faq-webapp.html) Sometimes we might pay for high risks or extraordinary issues on a case by case basis, but this I don't think this is such a case.
Assignee | ||
Comment 8•11 years ago
|
||
Paul: Are you still working on this bug? I'm waiting for you to finish up whatever you need to do with it so then I can grab it and fix it.
Comment 9•11 years ago
|
||
All yours - I was only assigned for verification.
Assignee: ptheriault → nobody
Assignee | ||
Comment 11•11 years ago
|
||
In a PR: https://github.com/mozilla/kitsune/pull/1635
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Assignee | ||
Comment 12•11 years ago
|
||
Landed in master in https://github.com/mozilla/kitsune/commit/8d411f2 We don't push on Fridays, so I'll make sure this gets pushed out and mark the bug FIXED on Monday.
Assignee | ||
Comment 13•11 years ago
|
||
Oops--I forgot to mark this as FIXED. Pretty sure we pushed this out September 30th.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 14•11 years ago
|
||
Adding whiteboard sprint data.
Whiteboard: [site:support.mozilla.org][reporter-external][verif?] → [site:support.mozilla.org][reporter-external][verif?] p=1 s=2013.19
Assignee | ||
Updated•11 years ago
|
Whiteboard: [site:support.mozilla.org][reporter-external][verif?] p=1 s=2013.19 → [site:support.mozilla.org][reporter-external][verif?] u=user c=messages p=1 s=2013.19
Assignee | ||
Comment 15•8 years ago
|
||
These bugs are all resolved, so I'm removing the security flag from them.
Group: websites-security
You need to log in
before you can comment on or make changes to this bug.
Description
•