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.
Related
Let's assume my site is example.com. On my server I have script which must works only for white listed site. I have setuped this code which allow XHR requests only from my site.
header('Access-Control-Allow-Origin: https://www.example.com')
Now I'm wondering can someone change origin parameter and send fake AJAX requests from another sites ?
So is origin parameter trusted or there is a ways to "override" origin parameter example from script or browser configuration or from some third part service ?
CORS policies are enforced on the client side; i.e. by the browser.
You can trust that they will work to prevent CSRF for your regular visitors, but there's nothing preventing someone from manually sending requests to you as they wish.
We moved our website from HTTP to HTTPS.
But we are still missing Google Analytics Referrals data from some HTTPS referrals sites.
Could it be because:
Referrals sites still point to our HTTP web pages? (hence HTTPS -> HTTP (301 redirection) -> HTTPS looses the referral data)
Some referrals sites have links with nofollow noreferrer like <a href="https://ourdomain" rel="nofollow noreferrer">. Oddly enough from our history data it looks like noreferrer didn't have any influence even just a few months ago like in April 2017.
some other reasons?
The default value of the meta referrer tag is no-referrer-when-downgrade. This means you lose the referrer information on your existing http links from most https sites.
301 Redirect
When you 301 redirect from an http request to the https version on your website, the referrer information has already been lost during the http request. There is no way to recover it later in the redirect chain.
The solution is to update the links to https. Unfortunately, this can be a big challenge when they're on websites all across the web.
Meta Referrer Tag
Websites can also use the meta referrer tag to override the default value. It is possible to configure this so that the referrer information is not passed along, even on an https to https request.
Google does this by using the origin value for the meta referrer tag and consequently, you know a visitor came from Google, but not what query they used to find your site.
noreferrer
Setting rel="noreferrer" informs browsers that support this attribute not to pass on referrer information for that specific link. However, older browsers don't support this and will still pass on referrer information.
nofollow
This does not affect the referrer information.
It is used to communicate to search engines that the website does not vouch for the link. Most search engines use this information to ignore the link when calculating the link targets ranking. Some search engines also interpret the tag literally and choose not to follow the link at all, while others follow the link sometimes, and still others follow the link as they would a normal link.
I have a bit.ly account, with a customized short URL.
However, I want to turn off http and turn on https.
I can't figure out how to get bit.ly to point to a HTTPS URL.
Is there a way? Thanks.
I can't comment on whether HTTPS can be used with customized URLs, but bit.ly does support HTTPS target URLs to some extent because the following link works:
http://bit.ly/tT1Ms maps to https://test.com
Bit.ly only stores the part of the URL that follows the "http://" or "https://" prefix. Unfortunately that means you can't specify one or the other. The protocol will be determined by the website you're connecting to. Sorry!
I use Fiddler to look at some attack-vectors on my site.
I copy the http-request from my validate-function and changed it: I cut off the referer-line. And it works. Is that an evidence for CSRF?
The Question in other Words: When I reproduce the HTTP-Request in Fiddler without the Referer, is that an evidence that my Site is vulnerable against CSRF? Or can I look for CSRF-Attacks by using only Fiddler?
Not necessarily, no. Referer-checking is one way to attempt to prevent CSRF, but it's generally not the best choice because some intermediaries strip this header, and if the client browser or one of its plugins had a bug, an attacker could send a fake referer. Most sites today send a nonce in the HTTP POST body that the server uses to validate that the request was generated by a page on the 1st party site and not a cross-site request.
Is it secure to pass login credentials as plain text in an HTTPS URL?
https://domain.com/ClientLogin?Email=jondoe#gmail.com&Passwd=123password
Update: So let's say this is not being entered in the browser, but being generated programmatically and being requested with a POST request (not a GET request). Is it secure?
Solution:
It is not secure to use this type of URL in a GET request (i.e. typing the URL into the browser) as the requested URL will be saved in browser history and server logs.
However, it is secure to submit as a POST request to https://domain.com/ClientLogin (i.e. submitting a form) while passing the credentials as part of the POST body, since the POST body is encrypted and sent after making a connection to the requested URL. So, the form action would be https://domain.com/ClientLogin and the form field values will be passed in the POST body.
Here are some links that helped me understand this better:
Answer to StackOverflow Question: Are https URLs encrypted?
Straightforward Explanation of SSL and HTTPS
Google Answers: HTTPS - is URL string itself secure?
HTTP Made Really Easy
No. They won't be seen in transit, but they will remain in:
browser history
server logs
If it's at all possible, use POST over HTTPS on authentication, and then set a "authenticated" cookie, or use HTTP Digest Authorization over HTTPS, or even HTTP Basic auth over HTTPS - but whatever you do, don't put secret/sensitive data in the URL.
Edit: when I wrote "use POST", I meant "send sensitive data over HTTPS in POST fields". Sending a POST http://example.com/ClientLogin?password=hunter2 is every bit as wrong as sending it with GET.
TL;DR: Don't put passwords in the URL. Ever.
Passing login info in url parameters is not secure, even with SSL
Passing login info in POST body with SSL is considered secure.
If you're using SSL, consider HTTP Basic authentication. While this is horribly problematic without SSL, it is no worse than POST with credentials, it achieves what you want, but does so according to an established standard, rather than custom field names.