which browsers do not send referer information?
This is not dependent on the browser make/version, but on the browser configuration. All decent browsers with default settings will send it, but the enduser can configure it to not send it. It's also dependent on the environmental software. If you have for example Norton AntiVirus/InternetSecurity installed, then you can configure it to let it block or spoof the referrer header with something entirely different, regardless of the browser used.
All the popular web browsers send referrer headers, at least by default. Some web browsers give their users the option to turn them off. (Example)
Referrer information not sent with a Flash http request
http://training.sessions.edu/resources/SoftwareDesignTips/current/flash.asp
For example, if someone clicks on flash banner linked to your site, request can come to your server without HTTP referrer information
Related
In Firefox using FireBug addon, the data you entered can be seen in POST headers. I wonder if this is a security flaw in the asp.net web application.
It's not. If a browser doesn't expose the headers, other tools will. They're public by nature except to the degree that https encryption keeps third parties from reading them.
I want to automate logging into a website and retrieving certain data.
I thought the way to do this would be to sniff the HTTP requests so I know where the login form is being POSTed to so I can do the same using NodeJS/Java/Python.
However I can't seem to find the HTTP request that handles it.
The site seems to use some Java-applet and a lot of Javascript.
This is the site: link
Should I have a different approach?
Also also wonder about storing a cookie session, and sending it with each HTTP request after logging in.
I'm sorry if I am not to clear, I will try to explain myself further and edit this post if needed.
You can use the developer console (hit F12) in Chrome (this works also in other browsers) and then click the "Network" tab. There you see all network calls.
To detect what http requests are performed from a mobile device, you can use a proxy like Charles Proxy.
Also be aware that if you post from nodejs the cookies won't be set in the users browser.
There are existing discussion [1] on the use of protocol relative URL in HTML, but how about email?
Will email client, or service providers like Gmail strip or modify protocol relative URL when they are used in HTML email?
[1] Can I change all my http:// links to just //?
I sent an email through Gmail with this content:
link
and it was received unmodified. When I right-clicked on the link to copy the link address, Chrome prepended https: to it (since Gmail uses secure HTTP), but when I inspected the element's HTML, it showed the <a> tag as I had written it.
It's not normal for email servers to change the contents of emails.
Omitting the protocol is intended to let a web browser choose between secure and insecure versions of the same content. If you load a page via https and it contains an image with an src beginning in http, the browser warns the user that it is dangerous to load insecure content -- a confusing and worrying message. If you load a page via http and it contains an image with an src beginning in https, that prevents caching among other inefficiencies.
The compromise is to allow the browser to load content with security matching the page that loads it -- efficiency for an insecure page; complete guarantee of security for a secure page.
But an email client always warns about embedded content (images, scripts, ...), meaning omitting the protocol has no benefit.
Furthermore, a non-browser email client doesn't have a protocol to begin with. It downloads information and then loads it from the disk. If you really want to let the email client choose to load embedded content with the security level with which it loaded the email, you'd let the client look for the information on the same computer. (They'll actually do that by assuming // means file:///.)
So is it safe to put a // URI in an email? I'd say it doesn't make sense; therefore, there has not become a standard way for non-browser clients to handle it, meaning you're looking at undefined behavior.
Better to choose the protocol based on the sensitivity of the information identified by the URI. Is it a chart of proprietary financial data? Use https. Is it a lolcat? Use http.
No , its not safe to use protocol relative URL in email. because its change protocol so that browser can fetch a resource from whatever protocol the site is telling it to use.
but some email clients (Outlook especially, as usual) won’t try to use HTTP or HTTPS as the protocol. Instead they’ll use the file:// protocol and assume the resource you’re referring to is on the local machine. But it won’t be. So don’t use these in emails.
You have to be sure that the server you’re requesting from is capable of serving content over both HTTP and HTTPS. If not you might end up fetching content from an unsecured or nonexistent server port.
IE6 does not know how to handle this. If you care about supporting Internet Explorer 6 then you shouldn’t use these.
IE7-8 support protocol relative URLs but they’ll end up fetching the resource twice. Once from HTTP and once over HTTPS. This can slow things down a bit but the way I see things it’s not much of a problem for anyone except the person using IE7-8 and if you’re using IE you’ve got more important things to worry about.
its browser dependent so its depends what browser you are using GMAIL working fine in crome but not in IE6.
We use the URLReferrer and a code passed in on the query string to produce online videos so that only our paid clients can link to our video playback page. This system has worked well for some time. I know the URL referrer can be spoofed, but who would tell their clients to do such a thing to access a video ? It's worked well for us.
However, today I was asked about someone for whom it did not work. The URLReferrer is null, and their site is HTTPS. I have done some reading online and I get the impression there's no way to access the URL referrer when the source page is https. Is this correct ? If I made a https version of our site, would that resolve it ? Or is there any other way for me to get around this ?
Thanks
Your online research is correct. The main reason for not setting an HTTP Referrer header or equivalent is that this could be a security issue. The referrer contains "where you come from", this is private information, and should not be exposed to others, what use is it otherwise to have a secure site if everyone can track where you have been?
So: you cannot get the referrer if the referrer is encrypted (with SSL or otherwise).
Update: here's what the HTTP specification says about coming from a secure site:
Clients SHOULD NOT include a Referer header field in a (non-secure)
HTTP request if the referring page was transferred with a secure
protocol.
As you might have guessed, there's no way around this restriction. Your only option is to use a different verification model. One such method is giving your users a key and require them to send that as a parameter with the request. Several other methods can be thought of.
I have a directory with my media files and I need no to display them on other sites.
Server doesn't support .htaccess, because it uses nginx.
How can I enable hotlink protection for my files??
Thank you.
Easiest way would be to check for the Referer header in HTTP request. Basically if that header does not have URL from your site, then this could be hot linking.
This has following problems:
Referrer header can be forged -> hot linking works
All user agents do not necessarily send the Referrer header -> legitimate user might not get the content.
You could also set a cookie when user is browsing your site, and check for existence of that cookie when user is accessing the streaming content.
The details may be dated, but Igor gives an example of referrer mapping for image hotlink protection that might be useful here: http://nginx.org/pipermail/nginx/2007-June/001082.html
If you decide to go the referrer route.
If you are using memcached you could also store store client IP addresses for a time and only serve up your streaming media if an unexpired client IP is found in the cache. The client IP gets cached during normal browsing ensuring that the person viewing your streaming content has also recently been visiting your site.
On my hostgator site, they used nginx as a proxy to Apache(nginx+apache). maybe that will help you. Also if you have access to the logs, if you see a lot of traffic that way from a ip I would investigate, and if it points to a site, then block the other web server. Php's file_get_contents doesn't get stopped by htaccess or anything else I know besides blocking the ip.