Is there any option to detect if my page is being loaded from a clickjacking page?
I mean, does not matter if the page is the origing of the clickjacking(I've setted the X-FRAME-OPTIONS header), the thing is if from a clickjacked page users are browsing to mine page.
The first solution I found is to control the HTTP-REFERER, but is a hard work because I can't control all my traffic.
Sorry for my english.
Unless you intend for external sites to be able to POST to yours, if you have a POST request originating from another server, it's probably click jacking:
if($_SERVER['REQUEST_METHOD'] == 'POST' && !strstr($_SERVER['HTTP_REFERER'], 'mydomain.com') {
//probably clickjacking
}
If you have pages that use GET that are susceptible to clickjacking, you can either add a check for the HTTP_REFERER on a per-page basis, or change the page to use POST (which is usually best for something which does an update).
One of your options is to set your website header: "X-Frames-Options" to "SAMEORIGIN"
This should prevent your website from being loaded into iframes and frames unless the originating page is in your domain.
Note that this will only work for certain browsers, for example I don't think this will work with IE7 and below and I don't think it works with chrome. This will at least reduce your attack surface a little bit.
Apache:
Header always append X-Frame-Options SAMEORIGIN
MDN - The X-Frame-Options response header
EDIT: Now that I understand better...
Perhaps you can use code similar to this:
if (window.top !== window.self) {
// do something here
}
This is one way to detect if the page is loaded into an iframe. You could set a cookie here, call a WebService here, or use window.location.href to navigate.
Here is an example of the "frame-busting" defense for click jacking:
Clickjacking Defense
-KB
Related
I was asked to check how to prevent Clickjacking on our website.
I did some research and this is what I understand, please correct me if I'm wrong:
The attacker will use iframe to layer their website over your website, then make their iframe transparent.
When user click on a button on our website, they are actually clicking on hacker website.
To prevent this, disable iframe on our website.
I went to this website to check, but I got this error:
Couldn’t find the X-Frame-Options header
in the response headers.
What it means? I'm not sure.
I also searched online and found that you need to add this code in .htaccess
<IfModule mod_headers.c>
Header always append X-Frame-Options SAMEORIGIN
</IfModule>
But how do I know if it works?
Clickjacking is about an attacker using an iframe on their website to include yours, with tricks like making your website's iframe transparent. The point is that if a user is logged on to your website (the victim), your website will load the user's content, and the attacker can visually position elements on their website (over your invisible website's iframe for example) so that an unsuspecting user visiting the attacker website will click things in your application. This works, because without further protection of the authentication token (eg. session cookie), your website will just load the user's authenticated content in the iframe.
You could argue that if it loads in the iframe on the attacker's site, why don't they just read or do whatever they want. That's not possible though, because the same origin policy prevents javascript on the attacker's origin from accessing content from another origin (yours), even if it's on the same page in an iframe. But they can possibly make the user perform actions by inadvertently clicking stuff they didn't want to.
This was used to gather likes on Facebook for example, Facebook was loaded in an invisible iframe on malicious sites, and then something like an advertisement's close button was positioned right over a Facebook like button - you tried to close the annoying ad, and in fact liked something you didn't want to.
One protection against this is that your app (or Facebook in the example above) should not allow itself being displayed in an iframe. And that's exactly what X-Frame-Options does. With the value 'deny' it will just never be displayed in an iframe, with 'sameorigin' your own origin (~domain name) can display parts of itself in iframes, but other origins cannot (so an attacker cannot include your site on a different domain).
X-Frame-Options is an http response header, so to check that it works, you can use the network tab of the developer tools in your browser. In most browsers you hit F12, choose the network tab, load your website, find and click the initial request that downloaded the actual page, and you can inspect the list of response headers. That should include X-Frame-Options with the value 'deny' or 'sameorigin'.
You can also use online tools to perform these simple scans (see the other answer for an example), but I think it's worth to actually understand what and why you're doing.
You can get the more details of X-Frame-Options on below https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
You can add below snippet code on last of your server .htaccess file and test the site on https://clickjacker.io/test.
<IfModule mod_rewrite.c>
Header always set X-Frame-Options "SAMEORIGIN"
</IfModule>
How can I make it so when the site visitor of mysite.com clicks a link, like http://google.com, the referrer page is not sent to the target website ?
Is this possible with PHP ?
Basically I want the linked site to not be aware where the visitor came from
I don't think it is possible, as the HTTP referrer information is sent by the browser. You can install browser plugins to prevent sending referrers, but not directly with PHP.
Update: I just found this
If a website is accessed from a HTTP Secure (HTTPS) connection and a link points to anywhere except another secure location, then the referrer field is not sent.
The upcoming standard HTML5 will support the attribute/value rel = "noreferrer" in order to instruct the user agent not to send a referrer.
Source: http://en.wikipedia.org/wiki/HTTP_referrer#Referrer_hiding
The referer is set by the browser, not the server, so broadly speaking, you can't really control this.
You may be able to find ways to mask mysite.com by redirecting the user through an intermediary site to google.com. I wouldn't recommend this, though.
No. Not possible. The client (broswer) is responsible for that HTTP header. A browser might even choose to not (ever) send it. (I'm not sure about the exact protocols/specifications of when to send it.)
edit
There might be a trick. (But I don't know it.) Maybe some JavaScript or header cancelling image or something nasty.
I have an application which records users visits. None of these visits are directly accessed, 100% of these visits are referred from another site.
I am passing $_SERVER['HTTP_REFERER'] through to the database. Approximately 35% of the logged entrees pass a referer, the rest are blank.
Is there a reason for this?
There are a couple of number of reasons why HTTP_REFERER might be blank.
You have to understand it's an environment variable given by the browser. Meaning users can remove it or even change it, if they so intend to.
Users accessing the link from a bookmark, history or by typing the link manually do not have a referer.
IE has also been known to remove the referer in situations revolving around javascript. Such as window.open, window.location and even setting target="_blank" in anchors or meta refresh.
Clicking an embedded link in a chat application, PDF/Word/Excel document, will also not set a referer.
Using AJAX, file_get_contents, fopen and other similar functions in other languages will probably not set a referer request.
cURL, fsockopen, applications that have browser-like components might not set a referer.
There are probably more situations when this could happen, I'll update if I can think of anything that seems reasonable.
If a user visits your site directly, there is no referrer. It's also possible they have set it up so their browser never sends the referrer.
According to this answer, browsers do not necessarily send a referrer when doing a meta refresh.
Browsers sometimes will include the referer in the request. But it is not mandatory to do so (the referer is 100% voluntary). Indeed there are various privacy and security issues surrounding the referer (for example, if an HTTPS site refers you to an HTTP site, the browser should not include the referring site as the referer). So don't rely on it.
When linking from one document to another in Internet Explorer 4.0 and later, the Referer header will not be sent when the link is from an HTTPS page to a non-HTTPS page. The Referer header also will not be sent when the link is from a non-HTTP(S) protocol, such as file://, to another page. for more info go to this link
Direct access to your page (typing URL in address bar or from bookmarks, history, etc)
Browser settings (disabled referrer or empty)
if someone requests page content with file_get_contents() function...
It is common when you are stuck finding why it is missing:
- Sometime your referer is https and you are on http, it will be lost.
Otherwise:
- User accessing by inputing url directly.
- A user has bookmarked and come from bookmarks.
- Sometime user keep the url default for browser (similar like bookmark)
- Proxy surfying may remove referer.
- accessing website as bots (search engine)
It also depends on the Transport layer, I encountered an issue where my Consumer Application A was running on the HTTP layer while the Application from where I was sending the request was running on the HTTPS layer.
My goal
I would like to let browsers cache my whole website, but only download the static content when I have changed one or more files.
My situation
After some research I have found a way to do this. That is to add a Far Future Expires Header to my htaccess file and add a querystring to my files using the filemtime() function.
The problem
When I click on the address bar and type in my website address in firefox, then Firebug displays 38.3 KB (36.4 KB from cache)
When I press F5 in firefox, then Firebug displays:241.1 KB (10.9 KB from cache)
Now I have tried to do the same with Google and they are sending HTTP header 304 back. I have read a lot about ETag and the Last Modified header, but I have heard a lot of people saying that they are not really reliable.
My question
What would be the best solution if I would like to send HTTP header 304 back with my static content if the user presses on F5, like Google?
I am asking this question because I am often visiting a website and using F5 to see if there is some new information available. Not to reload the images etcetera.
Update
It seems that Firefox is controlling the way the cache is used and I would like to use the cache also when a user presses F5.
The very purpose of reload is to reload the page. There is no server-side header magic if the browser was witten to ignore caches when the user specifically asks for it.
The solution for Google is that you check if the crawler sent an If-Modified-Since header with:
if ($_SERVER["HTTP_IF_MODIFIED_SINCE"]) {
header("HTTP/1.0 304 Not Modified");
exit();
}
This trick could work for browsers, but not in forced reload modes, like Firefox's SHIFT+RELOAD.
You can also use the newer application cache feature.
I don't know what your target browser is, but most browsers have been supporting it for quite a few versions so far..
This way you can define your statics to be downloaded only once.
For some very good information on the subject you can take a look at this page:
http://diveintohtml5.ep.io/offline.html
I'm not sure I understand the intent of your question, but you can specify the response code in php, with the header function, regardless of whether or not your user presses a button.
http://php.net/manual/en/function.header.php
How can I hide $_SERVER['HTTP_REFERER'] when a user browses to another site via a link from my site?
You can't, you have no control over the headers that are sent to another site. Headers are sent from the browser, to the site being navigated. This means you cannot manipulate them in any way (short of a MITM attack).
You could redirect the user to the site via an intermediary proxy, but that proxy will become the new referrer. e.g.
Your Link -> Proxy -> End result
Not only should this generally not be done, but it is not possible, at least in the way you are describing. It is up to the client to decide what to send in the request headers to a different server, not you.
I should also point out that this has nothing to do with PHP. PHP makes this header variable accessible to you via $_SERVER['HTTP_REFERRER'], but the problem you are trying to solve is avoiding the client from sending the referrer URL to the next server.
A few options:
If your site utilizes HTTPS, then it won't be sent.
If you build a redirector script on your site and use the HTTP Refresh header, the browser will typically not send the referrer, and if it did, you would only be sending the URL of your redirector. For example:
http://www.yoursite.com/redir.php?url=http%3A%2F%2Fwww.google.com
<?php
if (isset($_GET['url'])) {
header("Refresh: 0; " . $_GET['url']);
}
?>
Now, you must be careful with this little script. Anyone could then use your site to make a redirect look like it was coming from you. Also, using this method, anyone can inject whatever headers they want to the client. This is just to give you an idea. Finally, using the refresh header for this goes against the grain of the standards and should not be done.
Finally, Google, Facebook, PayPal, etc. all have redirector scripts. They use some sort of encrypted hash on the URL to determine if they generated the redirect or not. If you don't specify that hash and just give the URL, then the user will be prompted before redirecting. Not friendly.
Look, the bottom line is, there isn't really a reason to do what you are doing. If you are trying to hide something in your URL, then you have bigger problems. Security through obscurity is bad, mmkay?
If you're working in a controlled (intranet say) environment you might benefit from fixing browser configs see eg. http://cafe.elharo.com/privacy/privacy-tip-3-block-referer-headers-in-firefox/ but this is far from ideal.