0

I'm trying to do a PoC for a Cross Frame Scripting attack (https://www.owasp.org/index.php/Cross_Frame_Scripting) to show in my job how dangerous can be this attack for any version of IE browser. This attack can be easily prevent by using X-FRAME-OPTIONS: deny header on IE8 or newer versions. But it would be nice if every develop include such header on all web server responses. Using the code below I can see the alert window with the keycode but in case of forms on the target page I can not see the letter of the key pressed inside the form.

<script>
        window.onkeydown = function() {
                alert(window.event.keyCode);
        }
</script>
<frameset onload="this.focus()" onblur="this.focus()">
        <frame src="http://www.uol.com.br">
</frameset>

Using the simple code below I can press the key and see both (alert window and the letter inside the form).

<script>
        window.onkeydown = function() {
                alert(window.event.keyCode);
        }
</script>
<input>

Is there something missing on the first code block? Thanks!

Ricardo.Iramar
  • 441
  • 4
  • 3

1 Answers1

0

There's probably nothing wrong with your code. Cross Frame Scripting is not a real vulnerability - it is only a vulnerability in old versions of Internet Explorer that contains a bug where the onkeypress event is triggered inside the parent frame, despite the domains not matching where this would usually be protected by the Same Origin Policy.

Other Cross Frame Scripting attacks are merely Cross Site Scripting attacks with a different name because they involve frames.

SilverlightFox
  • 32,436
  • 11
  • 76
  • 145
  • 1
    What about clickjacking attacks? Granted, their attack surface is tiny (pages where meaningful state changes can be triggered with only mouse clicks) but they are still distinct from XSS. – Aurand Jan 26 '14 at 20:23
  • I agree with you, but that's my point: click jacking is click jacking, I wouldn't call it cross frame scripting. XFS seems to muddy the waters between several different types of attack, whereas the vulnerability only falls within a single category (xss, browser bug or click jacking). I agree it is a good idea to add the header, although this can be done at a web server level rather than the application. – SilverlightFox Jan 26 '14 at 20:43
  • Thanks @SilverlightFox! I tested the first code using IE11 and I could see the alert window with the key pressed html code. I could use ajax to make a request and send the key code to a malicious site. The problem is that I can not see the the respective letter into the inputbox, which means any user will think that there is a problem on the site since he/she can not see what they are typing. – Ricardo.Iramar Jan 27 '14 at 18:29
  • @Ricardo.Iramar It appears that this is the way Microsoft have plugged the vulnerability. The event is handled in the frameset page preventing the text entered into the framed page from being grabbed. – SilverlightFox Jan 29 '14 at 09:20