I understand that the referer header is trivial to spoof when using standard http. But when using https can you trust the referer or is that potentially faked as well?
No. Using HTTPS changes nothing; the referer can still trivially be spoofed; for example:
wget --referer=http://whitehouse.gov/ https://example.com/
Related
As far as I know, HTTPS requests are regular HTTP requests encrypted with the public key provided by the server during the initial handshake.
I have been reading about HSTS but have not been able to find anything related to the public key of sites that are in preloaded HSTS lists. Are the public keys of these sites also preloaded? Or is this key sent by the server on initial handshake like in any HTTPS request?
is this key sent by the server on initial handshake like in any HTTPS request?
Yes. HSTS just says “always use HTTPS for this domain so automatically correct any http:// calls to https:// before it is sent”.
It says nothing about how that HTTPS connection is set up, which is done through the usual manner.
My questions is simple, but I cannot find an answer and I haven't got any resources to test it myself.
Can I make HTTPS CORS request from one domain to another HTTPS domain?
Can I make HTTP CORS request from one domain to another HTTPS domain?
I know that I can do HTTP CORS request from one domain to another HTTP domain, but I don't know if there is any difference when I use HTTPS.
Yes you can do a CORS request from a HTTPS domain to another HTTPS domain.
The only difference is because HTTPS is a secure origin, you can only make call to secure origin, so not to HTTP, the browser will block it with a message like:
Mixed Content: The page at 'https://example.com/index.html' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://example2.com/endpoint'. This request has been blocked; the content must be served over HTTPS.
Warning: If you allow http requests to call your https webpage, it will be insecure because it means an attacker can force requests to your https webpage with the cookies of a victim and read the answer
Beware if you still need to support IE8/IE9 and are using XDomainRequest as it does not support cross-protocol requests. As per MDN:
The origin's security protocol must match that of the requested URL. (http to http, https to https). If these do not match, the request will error "Access is Denied".
When someone arrives on my site, I want to check whether they came from Gmail, Outlook.com or Hotmail.com.
I installed Fiddler, but I can't find a the referrer hostname anywhere when I come from Gmail.
Is a referrer hostname even passed for these mail clients?
Browsers don't pass the URL in the Referer field if it is an https:// URL, because it might contain private information. From RFC 2616 section 15.1.3:
Clients SHOULD NOT include a Referer header field in a (non-secure)
HTTP request if the referring page was transferred with a secure
protocol.
I found that if both the host and the linked to url are over the same protocols it does pass the HTTP_REFERER.
Outlook.com passes http_referer even if the link is non-secure (http). Looks like they just pass "https://outlook.live.com/" as the referer for all requests, which is great. I wish all the major providers would do this.
Is it possible to use HTTP caching for conditional GET requests over a secure HTTPS connection? I've got caching working over non-secure HTTP, but when I switch to HTTPS the browser stops sending if-none-match and if-modified-since headers, so the caching breaks. I've tried various Cache-Control settings like public, max-age=3600 and whatnot, no dice.
This happens in both Safari and Chrome, so I'm assuming the SSL is breaking it somehow. Is caching not allowed over SSL?
And just to be clear, the server is indeed properly setting the etag and last-modified headers, but the browser is not sending if-none-match and if-modified-since in the request, according to the Chrome developer tools.
Thanks for your help.
Figured it out! Turns out you have to have a trusted certificate. I was using my self-signed test certificate for SSL HTTPS. Adding it to my keychain and turning it green made the caching work.
I have a secured website that requires a user to authenticate, and would like to return sensitive data to the client from my API via JSON-P so that I can get around ajax cross-domain issues. I own both the client and server, so I am not concerned about the security from the client perspective (i.e. reading malicious js from the server).
I have been researching ways to secure the JSON-P to prevent Cross-Site Request Forgery, but haven't been able to clearly determine whether checking the Referer is a foolproof method for securing the data. As I understand it, the Referer header cannot be spoofed in this situation because the calls would be from javascript, and Headers cannot be changed. Is this a correct assumption?
I would like some clear-cut examples of why or why not checking the Referer would/wouldn't work to secure JSON-P.
Thanks!
EDIT:
Just to clarify - the JSON-P is secured via Spring Security, so it wouldn't only be secured by the Referer header. I am mostly concerned here about session hijacking...
Jsonp urls can be called using normal curl code. Http refer can easily be forged.
I would like some clear-cut examples of why or why not checking the Referer would/wouldn't work to secure JSON-P.
Referer is not guaranteed to be sent, so:
if you require it to be present and match a trusted site, you will be breaking the app for everyone whose browser or network setup doesn't send it;
if you permit it to be absent to get around that, you open yourself to attack not just for those users, but for everyone where the attacker can induce Referer not to be sent (most notably, from HTTPS pages;
also, to behave properly with proxies you would have to no-cache all your responses (or Vary: Referer, but that won't work right in IE)
Referrer-checking is a weak and problematic method which sometimes sees use as a desperate last measure... it's not something you should build when you've got the choice. If you control both servers you can easily include a request token on one page that gets recognised by the script on the either.