5 years ago
3 years ago


(Reporter: picography, Unassigned)


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

Bug Flags:
sec-bounty -


(Whiteboard: [][reporter-external])


(2 attachments)



5 years ago
Created attachment 774829 [details]
1st step

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

Steps to reproduce:

As a 1st step log in to the and try to edit Wiki Document and delete everything and Click on "Source" Button the your will see HTML Tags then paste below Malicious JavaScript Code (without quotes) Please check Step 1.png

"<meta http-equiv="refresh" content="0;javascript&colon;prompt(document.cookie)"/>?" 

and click "Source" button again (

Actual results:

Malicious Javascript file executed Javascript POP UP Prompt 
check the Step 2.png for the proof of concept 

Expected results:

Javascript shouldn't execute that must be remain as plain text

Comment 1

5 years ago
Created attachment 774830 [details]
Javascript Pop up
Flags: sec-bounty?
Whiteboard: [][verif?]

Comment 2

5 years ago
Why don't you comment here?
assigned to paultjt for verification
Assignee: jypenator → ptheriault
I'm having trouble reproducing this on There definitely seems to be some kind of injection here, but I am not seeing the script injection. I do however seem to be seeing the <meta> tag injection but load is getting denied due to x-frame options. 

Muhammed, from your description, it sounds like you are only able to XSS yourself if I understand you correctly - i.e. you enter malicious HTML, and it gets rendered straight away, but only against yourself. Is the malicious script actually stored in the edited page?  (i.e. can you get the xss to be stored, such that you can then send a MDN link to another person to a page that contains the malicious script?) If you have seen it stored, could you send me a link to such a page?

I'm continuing to investigate and I'll post more when I know more.
Flags: needinfo?(picography)
Ok I think I can reproduce this in Chrome:

1. edit page
2. click the source button
3. paste <meta http-equiv="refresh" content="0;javascript&colon;prompt(document.cookie)"/>?
4. click the source button, and you get a prompt

So at this point, there is script injection, but its not a useful attack since you can only attack yourself.

Note that you can save the page, and the meta tag is preserved, but that is because meta is allowed so that you can have redirects from old page names to new pages names. I note that the URL parameter supplied is prepended with the domain.

I'll wait for the reporter to respond, but at the moment it seems like this isn't an exploitable issue.
NB you can't reproduce this in Firefox since we block javascript URIs in the address bar now, and this seems to block meta tags too.

Comment 7

5 years ago
First of All I'm sorry for the late reply as per your argument I'm agree with It's not a stored XSS and What i can say is it's an Self XSS Which can harm my or user who try to exploit it, BTW as a researcher i suggest you guys to check prevent such kind of Javascript pop out, and also I found MDN has some XSS prevention methods but above payload which I used to inject is Bypassing it!

* I didn't check out this on #FF but in Chrome 

Thanks waiting for the reply
Flags: needinfo?(picography)
Thanks for the update Muhammed. You are right that it would be better if the editor didn't render entered script - I don't think it is too serious an issue, but it would be nice to fix. I suspect though that this is just a fckeditor issue, and we would be reliant on a fix in the upstream code.

As for bypassing the filtering with <meta>, I think this is intended, since editors need to be able to insert redirects when pages are renamed (so that the user automatically get forwarded to the new page). Since we sanitize the URL, and make sure that the redirect is always on, I don't think this is exploitable at the moment. If however you found a way to bypass the sanitization of the URL parameter to the meta tag so that you could inject a script URL this would definitely be an issue (might be an area to do more research in if you are interested)

Thanks for your help either way though.

Comment 9

5 years ago
Thanks for the reply,
Yes! I should do more research on this to exploit it in another way,
don't you have any option to fix this bug?

I've doubt whether this is eligible for bounty ?
Whiteboard: [][verif?] → []

Comment 10

5 years ago
Sorry i didn't get the comment you published guys :\ is not in scope for the bug bounty at this time.
Flags: sec-bounty? → sec-bounty-


5 years ago
Blocks: 835457
Keywords: wsec-xss
Whiteboard: [] → [][reporter-external]

Comment 12

5 years ago
But already they told like even though some other sites doesn't come under bug bounty still we consider 
So can you check and get back to me :-(
AFAIK, we only consider bounties for out-of-scope sites in extraordinary cases where it is a interesting/dangerous bug. As  this isn't actually an exploitable vulnerability, I don't think it would qualify for such a bounty.
Assignee: ptheriault → jypenator
Assignee: jypenator → nobody
Component: HTML → Wiki pages
Product: Developer Documentation → Mozilla Developer Network
I tried to reproduce this bug today and when I click on Source the second time (switching the editor out of "source" mode), I don't get any JavaScript execution. Further, the meta tag seems to get replaced with "?".

Over the last 3 years, there have been a lot of updates and changes to MDN and the libraries it uses. I suspect this was fixed during one of those updates.

I'm going to mark this as RESOLVED/FIXED. If someone can still reproduce this, please reopen with the steps to reproduce.

Muhammad: Thank you for opening this bug! I'm sorry we didn't get to it sooner.
Last Resolved: 3 years ago
Resolution: --- → FIXED
For bugs that are resolved, we remove the security flag. These haven't had their flag removed, so I'm removing it now.
Group: websites-security
You need to log in before you can comment on or make changes to this bug.