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.
Related
I have found a lot of information about serving http content into https websites and what to think of when doing / not doing that.
My problem is slightly different: I want to serve https content from one domain (active and passive) into another http only domain websites, but I can't find any information about browser support for that.
Example:
http://www.mydomain.com
loads scripts and images from
https://www.myotherdomain.com
I have tried this out in Chrome / Firefox and seem to not get any warnings, but wonder what the general browser support out there is. Can I expect this to work anywhere?
The reason for mixed content warnings are that when a user is browsing a page over https and it has content embedded which is accessed over http, the user would believe they are on a secure connection but not be aware of the insecure content otherwise. This could be used to trick a user into believing they are secure when actually they are not.
In your case the user would of course only see http, and not see anything to make them believe the connection is secure, this therefore would not be a security concern meaning that browsers will allow this.
The bigger question is why you may want to do this, remember you will not benefit from caching between your server and the client which would increase load on your https server. I'd be tempted to serve a copy of your files over http and only use the ones served over https for pages served over https.
I want to understand the technical background why it is not possible to track an HTTPS website with Piwik, when Piwik itself is installed on an HTTP server?
Somebody said, that if you would do that the browser would come up with an error message, but why?
I mean you do an HTTPS request, and on the bottom of the site is the tracking code to the HTTP Piwik site, that gets requested immediately. What's wrong about that?
All resources (such as the requests to Piwik) of the site requested through HTTPS have to go through the very same protocol since, otherwise, you will receive varying warning messages from different browsers (along the lines of "Your connection to XYZ is encrypted, however it contains resources that are not secure [...]").
So, to alleviate the problem, also Piwik has to be available via SSL.
The Piwik Javascript snipped already checks the protocol and redirects the user to the respective protocol. Now all you need to ensure is that your Piwik installation resides somewhere that has a valid SSL certificate.
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 was recently looking around at some of the features my current web host offers, and am now wondering about a few things. Even if you can only answer part of this, I appreciate any help you can provide.
I have a domain, mydomian.com, and the host offers shared SSL so I can use HTTPS by using this address https://mydomain.myhost.com. The SSL certificate is good for *.myhost.com.
I don't know a lot about SSL, but I'm assuming this means that the data between site users and ANY domain on myhost.com is encrypted. So was curious if this meant that if someone else on the same host as me somehow intercepted the data from my site would they be able to view it, since they would also have a https://theirdomain.myhost.com address, which uses the same SSL certificate? I may have no idea at all, and this was pretty much a guess.
If HTTPS is used on a login page, but after logging in the other pages are viewed over HTTP, is this a security issue?
Is there any way to show a web form via HTTP for bots like Google, but have real users redirected to the HTTPS version? Would be ideal if this could be done via .htaccess. I currently have some rewrite rules that redirect certain pages to HTTPS, but the rest as HTTP. So if a visitor visits the contact form they get the HTTPS version automatically, but it automatically switches back to HTTP for pages that don't contain forms. So, via htaccess, is there a way to direct real users to the HTTPS version, but have bots directed to the HTTP version? I would like these pages to still be indexed by the search engines, but would like users to see it via HTTPS.
Thanks in advance for any help you can provide.
I'm going to guess you'll be okay for number one. If your host does it correctly, individual subdomains never get to see the SSL keys. Here's how it would work:
Some guy with a browser sends an encrypted request to your subdomain server.
Your host's master server receives the request and decrypts it.
The master server sends the decrypted request to your subdomain server.
And any HTTPS responses you send back go through that process in reverse. It should be easy to check if they've set things up that way: If you can set up shared SSL without personally handling any key files, you're good. If you actually get your hands on some key files... not good.
For two: If you encrypt the login, you protect the passwords, which is good. But if you switch back to HTTP afterwards, you open yourself up to other attacks. See: Firesheep. There may be others.
And for three. Yes - definitely doable. Check out mod_rewrite. Can't give you an example, as I've never used this particular case, but I can point you to this page - particularly the section entitled "Browser Dependent Content."
Hope that helps!
Every traffic is encrypted, when you use https:// as protocol. (Except for some uncommon circumstances I won't talk about here). An SSL certificate's purpose is to prove the identity of the server, by combining it's public key with an identity. This certificate is only usable with the private key that belongs to the public one. In your case it seems that this certificate as well as the key-pair is provided by your hosting provider. I guess that neither you nor the other customers on the host have access to this private key. That means that only your provider is able to decrypt the traffic. Since that's always the case (he's running the server, so has access to every data), that should be no problem.
In most cases it is a security issue. On every further unencrypted http-request the client has to provide some information of the session to the server. These can be intercepted and used by an attacker. (simply speaking)
The bots should support https, why not redirect them? Anyhow: The important part is not to provide the page containing the form via https. To protect your user's data you should take care that the response is transferred via https.
I have SSL enabled for subdomain.mydomain.com so I can access files via https://subdomain.mydomain.com. Now please tell me if I'm right.. if I have file somwhere in subdomain.mydomain.com called index.php I can securely access it via:
https://subdomain.mydomain.com/someFolder/index.php
but I can also access it via
http://subdomain.mydomain.com/someFolder/index.php
This time communication won't be encrypted though. So now it comes down to links only if I access files in subdomain.mydomain.com securely or not?
I will have another related question (and many more probably), but will post it as separate topic to keep things clean :)
You can force the use of the SSL site for non-https URLs. This way people cannot access the pages without encrypting the communication
In the http virtual host, VirtualHost 192.168.0.4:80, put just the line
Redirect permanent / https://subdomain.mydomain.com
That's usually how it works, but it depends on your specific webserver's setup. For example, you can configure a web server to disallow non-HTTPS traffic completely or you can even serve totally different content between HTTP and HTTPS.
Yes, using https: or http: in your URLs controls whether the access is secure or not.