Closed Bug 912440 Opened 11 years ago Closed 11 years ago

XSS Reflected in support.mozilla.org

Categories

(support.mozilla.org :: General, defect)

defect
Not set
normal

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)

Attached image XSSReflectedPoC.jpg
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.
Assignee: nobody → ptheriault
Whiteboard: [site:support.mozilla.org][reporter-external][verif?]
assigned to paul to verify
cc:ing Ricky so he sees this bug as it progresses.
If you need a V.P.o.C, I will upload the video in case you can't reproduce the vulnerability.

Regards,
Darius Petrescu
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.
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
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!
(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.
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.
All yours - I was only assigned for verification.
Assignee: ptheriault → nobody
Grabbing to fix today.
Assignee: nobody → willkg
In a PR: https://github.com/mozilla/kitsune/pull/1635
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
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.
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
Adding whiteboard sprint data.
Whiteboard: [site:support.mozilla.org][reporter-external][verif?] → [site:support.mozilla.org][reporter-external][verif?] p=1 s=2013.19
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
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.

Attachment

General

Created:
Updated:
Size: