Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange
49

This is a very interesting question. First of all, let's start with your scenario: A user visiting website www.evil.com which is a reverse proxy that loads www.good.com and modifies its content. Congratulations! You've just re-invented a classic MiTM attack, but a very poor one. Visiting evil.com means that your browser won't send good.com cookies, which ...


27

X-Frame-Options is an HTTP header. As such, it's not part of HTML and can't be set inside an HTML document. One reason why it's an HTTP header only is that clients should be able to decide if the document is allowed to be embedded in a frame before parsing the HTML code. Hence, you can't achieve that by editing the file but you need to modify the server's ...


14

First and foremost, your web browser must be kept updated. So are your plugins and plugin-related applications, especially Java and Flash. Secondly, it's very recommend to use the ClearClick functionality in NoScript. If you're not planning to block scripts, you can use the relaxed settings, but make sure you enable ClearClick. This feature protects against ...


14

The X-Frame-Options header is added on the server-side, not the client. This is because the header is used to control how the browser should render the page. Whatever server is hosting your file would have to add this header.


9

The NoScript Firefox extension is going to be effective to protect you from clickjacking attacks. This kind of attack usually requires the attacker to use JavaScript in order to move an iframe under your cursor. Therefore, it has to be executed on a website where the attacker can inject JavaScript. Beware of links to jsfiddle.net or similiar websites, ...


7

In my opinion there's no such thing as a frame killer/buster script as JavaScript can be disabled in the <iframe tag, rendering your code useless. The best way to protect your application from clickjacking attacks, for modern browsers, is configuring your web server to send the X-Frame-Options in the response header. Configuring this is quite easy: ...


6

You are talking about ClickJacking attacks. (The title was different before my edit) Can any one bypass it? Yes, this can be bypassed when loading the page in an iframe. Unfortunately I do not have the code at the moment. However, what can be done is disable javascript while loading the iframe. This will bypass your frame busting code. (There's no such ...


6

It is not possible to use clickjacking to get cross-origin access to the source code of a web page. This access is restricted by the same-origin policy and clickjacking does not bypass it. This means that, similar to a CSRF attack, you can cause a cross-origin action with clickjacking but you cannot read back the result of this action. Thanks for Arminius ...


5

Let's say an attacker wants to get a user to click something on victim.com. For this, they need to place an iframe somewhere - anywhere - where the victim will see it. It doesn't really matter where it is placed, or how it was placed there. This is not required, but ideally, the attacker can also run JavaScript here, as it increases the chance of ...


5

Share buttons will often use an iframe to protect them selves from CSRF. In this context CSRF and ClickJacking have an identical impact which is sometimes called "LikeJacking". You have to choose to be vulnerable to CSRF OR you can use an iframe prevent CSRF but then you expose your self to ClickJacking. It so happens that ClickJacking is the lesser of ...


5

The easiest way of guarding against clickjacking is via NoScript. Disable scripts for all pages except ones you trust. In addition, enable ClearClick. Usually, a site that is trying to clickjack you will ask you to do something in a roundabout fashion, and may involve partially obscured elements that you need to click. For example, one common Facebook ...


5

There's a number of potential methods you can use to differentiate bots from humans but none of them are likely 100% Obviously as you say rate limiting catches the really stupid bots who don't know to click at human speed. You could say one click per IP but that will artificially deflate your stats in the case of humans behind a proxy (becoming more common ...


5

As far as I know it is impossible to insert a completely fake Referer header within a normal browsing session. But there are various ways to make sure that no Referer header is sent at all. Thus as long as you only allow to be framed if the Referer header is set and that the domain in the Referer is explicitly allowed to frame your site you should be safe. ...


5

There is one caveat when using X-Frame-Options header: it only checks the top level frame. This means that if you have nested frames, i.e. frames within frames, it is still possible for another origin to include a site with a X-Frame-Options: SAMEORIGIN header. In this regard the header Content-Security-Policy: frame-ancestors 'self' is better, because it ...


5

By default, any new website is probably vulnerable to Clickjacking, depending on the webserver defaults. For defense against it, you should set HTTP-Response-Headers, as the OWASP Clickjacking Defense Cheat Sheet recommends. Another valuable and more concise ressource is Wikipedia: Disallow embedding: All iframes etc. will be blank, or contain a browser ...


4

One approach is to use separate browsers for general browsing and sensitive browsing. Perhaps you use Chrome for your general browsing. If you open your online banking in a Chrome tab, while you have untrusted sites in other tabs, you are potentially vulnerable to a whole range of web attacks: cross-site scripting, CSRF, clickjacking, etc. Of course, we ...


4

Can any one bypass it? Yes. This can be one with the sandbox attribute. With this attribute execution of Javascript within the iframe can be disabled and thus your frame buster code will not be executed. Also, some clients might have execution of Javascript disabled like when using the NoScript browser extension. For more information see https://en....


4

There is an anti ClickJacking HTTP header you can add to your responses. X-Frame-Options: DENY X-Frame-Options: SAMEORIGIN X-Frame-Options: ALLOW-FROM https://example.com/ Deny will stop the content loading into a frame, iframe or object, Same Origin will allow loading into pages on the same domain, 'Allow From' allows you to specify URIs that may frame ...


4

Is it possible to read information entered into an iframe like this through a keylogger or invisible divs floating on top of the iframe? Technically, the parent document can't capture a user's interactions with the iframe.1 But your main problem here is that the user has no way of verifying that the box they are interacting with is actually an iframe that ...


3

A user cannot trust a web page that is inside an app that they don't trust. Therefore, if there was a UI redress attack against your website when using a particular app, then this would be the user's fault for trusting the application. Furthermore, if an application developer wanted users to click something on your site using the phone, then they would ...


3

Firefox doesn't have an option to turn of iframes in about:config, see this bug report. It's also not that likely that it will get that option anytime soon, seeing that this issue was first reported 15 years ago. You could disable iframes without plugins by using custom CSS (iframe { display: none !important; }). This would be done via an CSS file in /~/....


3

The parts of the script you identified that are important to the source are as follows: //ad.directrev.com/RealMedia/ads/adstream_sx.ads/ and n.attr('data', '//az413505.vo.msecnd.net/images/g.swf'), Both of these are URLs and can be use to identify who is involved in this script. The first URL identifies the advertising affiliate network - "directrev.com"...


3

The only way to prevent clickjacking on a version of IE too old to support X-Frame-Options is to make the page dependent on JavaScript, so that it breaks when run with security="restricted". For example: <style type="text/css"> body.notframed #warning { display: none; } body.framed #content { display: none; } </style> <body class="...


3

As I understand it this guy reads all content of a website and then displays it in his iframe. He literally downloads the site's content and prints it out on his own page. This means that the content he downloaded afterwards belongs to his own domain. But whole the idea of a clickjacking attack is that you embed a site from a different origin in a frame. ...


3

A website prevents clickjacking by preventing untrusted origins from embedding the site in a frame. The established and reliable way to achieve this is to send an X-Frame-Options header. If you have no intention of having you page embedded in a frame of any origin, you can set it to DENY: X-Frame-Options: DENY Other options are SAMEORIGIN for access from ...


3

If your application is hosted with IIS you can activate the X-Frame-Options header in web.config. <httpProtocol> <customHeaders> <add name="X-Frame-Options" value="DENY" /> </customHeaders> </httpProtocol> Other ways for using X-Frame-Options are described here. A more modern approach would be using the Content ...


3

Why is the "original policy" altered ('self' vs. https://www.lidl.de)? Does this make any difference? 'self' in the CSP actually stands for "same domain". It is just a placeholder, so this is evaluated by browsers to, in your case, https://www.lidl.de. That's exactly what you say the directive should do, it is just written in another way. So no, it does not ...


2

First I'd advise simplifying the problem by getting rid of the secure content being served over a frame. Not a dig against you or your organization, but we're trying to train the world not to trust forms like the one you provided an image for. I know this isn't part of your question, but a Secure Transaction image is no substitute for that https cert. If ...


2

In general, every page which allows the user to change data is a potential target for clickjacking. The goal of clickjacking is to trick the victim into taking actions on the attacker's behalf. This affects every page with forms or buttons or other UI elements which have persistent effects. However, I strongly recommend against taking the blacklist approach ...


2

Suppose my site does not have the concept of a user account... Then is a clickjacking attack still applicable to my site? Even though there are no accounts, if there is a concept of user sessions, then Clickjacking could possibly apply. It all depends on what is being stored at session level. The best way to think of this is that if your site remembers ...


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