I know it's possible to get an empty HTTP_REFERER. Under what circumstances does this happen? If I get an empty one, does it always mean that the user changed it? Is getting an empty one the same as getting a null one? and under what circumstances do I get that too?
It will/may be empty when the enduser
entered the site URL in browser address bar itself.
visited the site by a browser-maintained bookmark.
visited the site as first page in the window/tab.
clicked a link in an external application.
switched from a https URL to a http URL.
switched from a https URL to a different https URL.
has security software installed (antivirus/firewall/etc) which strips the referrer from all requests.
is behind a proxy which strips the referrer from all requests.
visited the site programmatically (like, curl) without setting the referrer header (searchbots!).
HTTP_REFERER - sent by the browser, stating the last page the browser viewed!
If you trusting [HTTP_REFERER] for any reason that is important, you should not, since it can be faked easily:
Some browsers limit access to not allow HTTP_REFERER to be passed
Type a address in the address bar will not pass the HTTP_REFERER
open a new browser window will not pass the HTTP_REFERER, because HTTP_REFERER = NULL
has some browser addon that blocks it for privacy reasons. Some firewalls and AVs do to.
Try this firefox extension, you'll be able to set any headers you want:
#Master of Celebration:
Firefox:
extensions: refspoof, refontrol, modify headers, no-referer
Completely disable: the option is available in about:config under "network.http.sendRefererHeader" and you want to set this to 0 to disable referer passing.
Google chrome / Chromium:
extensions: noref, spoofy, external noreferrer
Completely disable: Chnage ~/.config/google-chrome/Default/Preferences or ~/.config/chromium/Default/Preferences and set this:
{
...
"enable_referrers": false,
...
}
Or simply add --no-referrers to shortcut or in cli:
google-chrome --no-referrers
Opera:
Completely disable: Settings > Preferences > Advanced > Network, and uncheck "Send referrer information"
Spoofing web service:
http://referer.us/
Standalone filtering proxy (spoof any header):
Privoxy
Spoofing http_referer when using wget
‘--referer=url’
Spoofing http_referer when using curl
-e, --referer
Spoofing http_referer wth telnet
telnet www.yoursite.com 80 (press return)
GET /index.html HTTP/1.0 (press return)
Referer: http://www.hah-hah.com (press return)
(press return again)
It will also be empty if the new Referrer Policy standard draft is used to prevent that the referer header is sent to the request origin. Example:
<meta name="referrer" content="none">
Although Chrome and Firefox have already implemented a draft version of the Referrer Policy, you should be careful with it because for example Chrome expects no-referrer instead of none (and I have seen also never somewhere).
BalusC's list is solid. One additional way this field frequently appears empty is when the user is behind a proxy server. This is similar to being behind a firewall but is slightly different so I wanted to mention it for the sake of completeness.
I have found the browser referer implementation to be really inconsistent.
For example, an anchor element with the "download" attribute works as expected in Safari and sends the referer, but in Chrome the referer will be empty or "-" in the web server logs.
click to download
Is broken in Chrome - no referer sent.
Related
When there is mixed http/https content in the webpage. IE prompt me this message.
I know how to disable this message.By the way, can I somehow know what exactly the insecure contents are (the urls)?
Use Developer Tools (Settings menu > F12 Developer Tools) within Internet Explorer to view the resources being loaded using the Network tab, and look for any plain HTTP URLs as per the screenshot below.
Insecure content is content loaded over http (and not https).
It could be images, css, ...
The fix is to point to the secure (https) version of these contents.
I have been looking for a way to make sure my web server is secure against a man in the middle attack. It does seem that Google Chrome and Firefox work in blocking requests to my server even if I select to advance after the security warning. I am testing this by using Charles Proxy to intercept Https traffic without having trusted the Charles Cert on my Mac.
When I run the same tests with Safari it will let me through if I chose to ignore the secure warning, which I expect a certain number of users to do. So it seems there is more configuration needed to lock down Safari traffic. I know this is possible because when trying to navigate to github.com with the same scenario I get the following message:
Does anyone know what GitHub is doing to block Safari traffic on an untrusted connection?
Looks like Safari is supporting HSTS and that github is using it. Their HTTP response contains the following header:
Strict-Transport-Security:max-age=31536000; includeSubdomains; preload
This way a browser supporting HSTS knows that for the foreseeable time this site should only be visited with https and any attempts to use http only will automatically be upgraded by the browser.
Apart from basic HSTS which only works after the first visit of the site github also adds the preload directive. This tells browser makers that github likes to be included in the preloaded HSTS list shipped with the browsers, so that the browser applies HSTS even if the site was never visited before by the user. See HSTS Preloading for more information.
I have a site which is completely on https: and works well, but, some of the images served are from other sources e.g. ebay, or Amazon.
This causes the browser to prompt a message: "this website does not supply identity information"
How can I avoid this? The images must be served from elsewhere sometimes.
"This website does not supply identity information." is not only about the encryption of the link to the website itself but also the identification of the operators/owners of the website - just like it actually says. For that warning (it's not really an error) to stop, I believe you have to apply for the Extended Validation Certificate https://en.wikipedia.org/wiki/Extended_Validation_Certificate. EVC rigorously validates the entity behind the website not just the website itself.
Firefox shows the message
"This website does not supply identity information."
while hovering or clicking the favicon (Site Identity Button) when
you requested a page over HTTP
you requested a page over HTTPS, but the page contains mixed passive content
HTTP
HTTP connections generally don't supply any reliable identity information to the browser. That's normal. HTTP was designed to simply transmit data, not to secure the data it transmits.
On server side you could only avoid that message, if the server would start using a SSL certificate and the code of the page would be changed to exclusively use HTTPS requests.
To avoid the message on client side you could enter about:config in the address bar, confirm you'll be careful and set browser.chrome.toolbar_tips = false.
HTTPS, mixed passive content
When you request a page over HTTPS from a site which is using a SSL certificate, the site does supply identity information to the browser and normally the message wouldn't appear.
But if the requested page embeds at least one <img>, <video>, <audio> or <object> element which includes content over HTTP (which won't supply identity information), than you'll get a so-called mixed passive content * situation.
Firefox won't block mixed passive content by default, but only show said message to warn the user.
To avoid this on server side, you'd first need to identify which requests are producing mixed content.
With Firefox on Windows you can use Ctrl+Shift+K (Control-Option-K on Mac) to open the web console, deactivate the css, js and security filters, and press F5 to reload the page, to show all the requests of the page.
Then fix your code for each line which is showing "mixed content", i.e. change the appropriate parts of your code to use https:// or, depending on your case, protocol-relative URLs.
If the external site an element is requested from doesn't use a SSL certificate, the only chance to avoid the message would be to copy the external content over to your site so your code can refer to it locally via HTTPS.
* Firefox also knows mixed active content, which is blocked by default, but that's another story.
Jürgen Thelen's answer is absolutely correct. If the images (quite often the case) displayed on the page are served over "http" the result will be exactly as described no matter what kind of cert you have, EV or not. This is very common on e-commerce sites due to the way they're constructed. I've encountered this before on my own site AND CORRECTED IT by simply making sure that no images have an "http" address - and this was on a site that did not have an EV cert. Use the ctrl +shift +K process that Jürgen describes and it will point you to the offending objects. If the path to an object is hard coded and the image resides on your server (not called from somewhere else) simply remove the "http://servername.com" and change it to a relative path instead. Correct that and the problem will go away. Note that the problem may be in one of the configuration files as well, such as one of the config.php files.
The real issue is that Firefox's error message is misleading and has nothing to do with whether the SSL is an EV cert or not. It really means there is mixed content on the page but doesn't say that. A couple of weeks ago I had a site with the same problem and Firefox displayed the no-identity message. Chrome, however, (which I normally don't use) displayed an exclamation mark instead of a lock. I clicked on it and it said the cert was valid (with a green dot), it was a secure connection (another green dot), AND had "Mixed Content. The site includes HTTP resources" which was entirely accurate and the source of the problem (with a red dot). Once the offending paths were changed to relative paths, the error messages in both Firefox and Chrome disappeared.
For me, it was a problem of mixed content. I forced everything to make HTTPS requests on the page and it fixed the problem.
For people who come here from Google search, you can use Cloudflare's (free) page rules to accomplish this without touching your source code. Use the "Always use HTTPS" setting for your domain.
You can also transfrom http links to https links using url shortener www.tr.im. That is the only URL-shortener I found that provides shorter links through https.
You just have to change it manually from http://tr.im/xxxxxx to https://tr.im/xxxxxx.
We've partnered with a company whose website will display our content in an IFRAME. I understand what the header is and what it does and why, what I need help with is tracking down where it's coming from!
Windows Server 2003/IIS6
Container page: https://testDomain.com/test.asp
IFRAME Content: https://ourDomain.com/index.asp?lots_of_parameters,_wheeeee
Testing in Firefox 24 with Firebug installed. (IE and Chrome do the same thing.) Also running Fiddler so I can watch network traffic while I'm at it.
For simplicity's sake, I created a page with nothing on it but the IFRAME in question - same physical server, different domain/site - and it failed with
Load denied by X-Frame-Options: https://www.google.com/ does not permit cross-origin framing.
(That's in the Firebug console.) I'm confused because:
Google is not referenced anywhere in the containing app, or in the IFRAMEd app. All javascript libraries are kept locally; there is no analytics in the app. No Google, nowhere.
The containing page has NOTHING on it, except the IFRAME. No html tags, no head tag, no body tag. IFRAME. That's it.
The X-FRAME-OPTIONS header does not exist in IIS on the server: not at the "Websites" node, not in the individual sites.
So where the h-e-double-sticks is that coming from? What am I missing?
Interesting point: if I remove http"S" from the IFRAME url, it works. Given the nature of the data, SSL is required.
You might check global.asax.cs, the app could be adding the header to every response automatically. If you just search the app for "x-frame-options" you might find something also.
I've inherited an ASP.NET web site that has an SSL certificate bought via GoDaddy.
The problem is that the certificate seems to be invalid because of some "mixed content/resources" (I think that's how its called) coming from http sites.
Chrome is showing the red cross over the lock next to https, meaning it's unsecured. The popups says the following:
Click in "What do these mean?" goes here which says:
The [crossed-lock] icon appears when
Google Chrome detects high-risk mixed
content, such as JavaScript, on the
page or when the site presents an
invalid certificate.
The certificate is correct and valid because I tried creating a blank "Hi world" .aspx page and it's showing the green lock with no problems.
Reading a little bit, I found that I should only include images and javascript coming from https sites. The only thing it had coming from http was the addthis widget, but they support https, so I changed to https, but it's still saying that is unsecured.
I've searched for anything else coming from http in the source, but didn't find anything.
Is there some way (site, chrome extension, firefox extension, whatever) that will show exactly which are the resources that are "unsecured"?
I've never dealt with SSL/HTTPS certificates, but I need to fix this issue asap.
Check your site in http://www.whynopadlock.com, which will give you a list of url which is not consider as secure by your browser.
Check the chrome console
You will get it like this,
The page at https://xys displayed insecure content from http://asdasda.png.
Make it http site to https then it will work.
I've found the problem using the Chrome Developer Tools. It was a js that's embedding a flash from an 3rd party site which it's using http.
Are you on Windows? Download and run Fiddler while browsing the site, and watch for HTTP connections.
Mixed content means contents of a web page are mixed with HTTP and HTTPS links.
These links include your JS, CSS, Image, Video, Audio, Iframes etc.
If your website is enabled for HTTPS (SSL certificate has installed), make sure you serve only HTTPS contents throughout your web page.