How to avoid the cross-frame scripting attack over core php we application

Question

I have developed one web application that is in core-php as per the client's requirement. My client conducted a vulnerability test, and found a Cross-Frame Scripting as a vulnerability at hard level.

What can be done in this case to avoid it? Is there any better choice available?

@Jedi: in one form or another, it will always be all you need to do. Shaggie: if you could be more specific about the issue we can be more specific about mitigation. — dandavis, Dec 07 '16 at 22:16

score 4 · Answer 1 · edited Dec 07 '16 at 20:44

4

Cross-frame scripting allows an attacker to embed your website within their own, as a frame/iframe and then spy on the users of your website.

This requires some social engineering. An attacker would trick someone into visiting their web page, with an iframe containing (say) the login to your website. The parent website would also need to have some malicious Javascript to read keystrokes to capture login. Theoretically, browsers have a same-origin policy that should prevent the attacker from being able to do this, however in reality this attack is possible, often due to browser bugs.

Defenses:

As per the W3 spec, you should include the Content Security Policy frame-ancestors header in your HTTP response to prevent your website being loaded in a frame. Some older browsers may not have support for this header, so also use the X-Frame-Options header with value DENY, SAMEORIGIN or ALLOW-FROM uri. X-Frame-Options takes precedence over CSP frame-ancestors in some browsers.
You could additionally have some Javascript "frame-breaker" code that will prevent your website from being "framed" in older browsers.

These solutions and more details are discussed on this OWASP cheatsheet.

edited Dec 07 '16 at 20:44

Anders

64,406
24
178
215

answered Dec 07 '16 at 14:52

Jedi

3,906
2
24
42

"however in reality this attack is possible, often due to browser bugs" Do you have any examples? I did not know about this. – Anders Dec 07 '16 at 15:46
@Anders: clickjacking comes to mind. – dandavis Dec 07 '16 at 16:42
@dandavis While I agree that clickjacking should be taken seriously, I would not call that a browser bug violating the SOP. And I don't see how it could be used to read key strokes. – Anders Dec 07 '16 at 17:48
@Anders: agree the keystroke part doesn't make sense; why would someone start logging in to siteB from siteA, or, if the typing is on siteB, how would siteA get the key codes? bug-based escapes are rare now... @Jedi: `X-Frame-Options` is deprecated, probably better not to recommend it still... – dandavis Dec 07 '16 at 17:56
@Anders, [this](https://tools.cisco.com/security/center/viewAlert.x?alertId=7313) is the advisory that we link to when describing possible exploit paths. It describes an IE bug that allows keystroke-logging for typing within a frame. – Jedi Dec 07 '16 at 20:39
@dandavis,[SSLv3 is also deprecated](https://tools.ietf.org/html/rfc7568), but the reality is that using avoiding deprecated techniques is a luxury for some environments. An extra X-Frame-Options header has very little negative impact, but helps protect against these attacks. – Jedi Dec 07 '16 at 20:42
@Anders, TBH attacks like clickjacking and XFS are classified as higher risk than they should be, but many enterprises use vulnerabilities reported by tools as gospel and IT requires implementing the solutions above. – Jedi Dec 07 '16 at 20:45
1

@Jedi Thanks for the link! Old, but still very interesting! Took the liberty to edit it into your answer. – Anders Dec 07 '16 at 20:45
since nobody uses those browsers anymore, i find it misleading to justify "in reality this attack _is_ possible" with a decade old issue (emphasis mine). good info otherwise! – dandavis Dec 07 '16 at 22:10

Kurkula · Answer 2 · 2018-06-07T22:49:07.997

1

From this and this best place to get more info on issue

@*Prevent Cross-Frame Scripting attacks*@
<script>
    (function (window) {
        if (window.location !== window.top.location)
            window.top.location = window.location;
    })(this);
</script>

edited Jun 07 '18 at 22:49

answered Jun 07 '18 at 22:40

Kurkula

111
2

You should explain in more detail what this does and how it prevents XSS – Machavity Jun 08 '18 at 00:47
added hyperlink 1 and 2 in answer has detailed explanation. – Kurkula Jun 08 '18 at 02:51
And if those websites go offline [your answer loses all value](https://meta.stackexchange.com/questions/225370/your-answer-is-in-another-castle-when-is-an-answer-not-an-answer) – Machavity Jun 08 '18 at 02:54
@Kurkula Unfortunatly this is not secure. Check the paper in my Answer – Guillaume Beauvois Jun 08 '18 at 08:33

Guillaume Beauvois · Answer 3 · 2018-06-08T08:32:05.610

I can't find the related question where I found this link but here is a paper about FrameBusting and how you should implement it.

Written by Gustav Rydstedt, Elie Bursztein and Dan Boneh from the Stanford University with the collaboration of Collin Jackson of the Carnegie Mellon University

This is the paper recommandation :

<style>
    body {display: none; }
</style>
<script>
    if (self === top) {
        document.getElementsByTagName("body")[0].style.display = 'block';
    } else {
        top.location = self.location
    }
</script>

Notice the display: none, this is super important, because attacker can just disable javascript on part of your page. See the paper for more informations.

Where do you place this code? If you place it in the main parent page/layout, making body display none will hide the page completely. — Kurkula, Jun 12 '18 at 04:56

How to avoid the cross-frame scripting attack over core php we application

3 Answers3