6

The HTTP header Content-Security-Policy can be used to protect from loading the page in an iframe. In this case, its value is set to default-src 'self' *.xyz.com which means that only the current domain, and *.xyz.com can load this page in an iframe. That HTTP header has other uses like protecting from XSS attacks. You can find more information on the ...


5

No. A malicious site cannot interact with its iframes which point to other domains. It can only issue GET and POST requests without reading the corresponding responses, like any other web page opened in the same browser. A feasible attack would instead be clickjacking. This question is a possible duplicate of the question Javascript and same origin iframes.


5

Though this being an old question, I'm adding an answer for future viewers. "Cross-Frame Scripting" is basically data leakage that can happen when an attacker embeds a victim's website into a frame within their own website and monitor/spy on the activities does on the framed website. An attacker can register a JavaScript listener which listens to all key ...


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 ...


4

A vulnerability does not exists until someone creates a Proof of Concept or method of exploiting a given software defect. "Cross-Frame Scripting" does not exist, and is a horrible name. That being said OWASP has a disorganized entry for Cross-Frame Scripting. Frames have scripting rights and protections granted by the Same-Origin Policy. A script ...


3

One answer: No. This is a good start but these headers are indicators for the Anti-XSS filters and engines which are incorporated by the modern browsers. These are very fragile and thin protection against Cross-Site Scripting (XSS). An attacker will easily bypass these. In order to completely make your application armoured and protected against XSS, I ...


2

Cross-frame scripting is not a term I've seen used before. From what I've read, it sounds like it's a subset of XSS (Cross-site scripting) using injected frames. Blocking cross-site scripting should be the top priority. The critical behaviors to protect against XSS are output encoding (anything that could possibly be user-controlled gets escaped or entity-...


1

The answer is simple and straight-forward: Having clickjacking protection only on the login page only protects the login page. The rest of your site is still vulnerable It sounds like you have a bit of a misunderstanding, and are hoping that because the login page is clickjacking-protected, someone can't use clickjacking to attack your site. ...


1

By default, yes, though the sandbox parameter in the iframe tag can change this behavior.


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>


1

You need to send an X-Frame-Options header, usually with the value "sameorigin". You can do this in Apache using mod_headers, something like: Header set X-Frame-Options sameorigin


Only top voted, non community-wiki answers of a minimum length are eligible