As I came across with the hot-leeching problem, I searched the website and found two ways to solve it.
The first is an easier and simpler way with the code showing below:
RewriteEngine On
RewriteCond %{HTTP_REFERER}!^$ Options +FollowSymlinks
RewriteCond %{HTTP_REFERER}!^http://(www\.)?mydomain.com(/)?.*$ [NC]
RewriteRule .*\.(gif¦jpg¦jpeg¦png¦swf)$ [mydomain.com...] [R,NC]"
This can only prevent some simple leeching ,but can do nothing with a determined person.
The other way is a better way with a script-and-cookies-based approach. They said "You set a cookie on an 'authorizated' page of your site, and then use a script to serve images only if the correct cookie is present in the image request. Images are kept in a directory accessible only to the script, and not via the Web. So, the script acts as an 'image server' on your site." I understand this principle but don't have any idea about how to realize it . Could anyone know how to realize this?
Any help appreciated.
I can't really give any implementation, but only some idea of how it can be achieved:
You will need a "portal" page, where you set the cookie for the user. Any request for resources without having a cookie of your site should be redirected here. There may not may not be a login mechanism here, depending on the purpose of your site, but usually you will set the cookie, after the user is logged in.
All resource links will link to to the same "script" page. The difference is that different resource will have different identifier (can be some sort of id - if you maintain a database of id to file path mapping). The identifier must be included in the query of the URL. The "script" will find the resource on the server based on the identifier (in case of id to file mapping, you will obtain the file path and go retrieve the file).
There will be a "script" page, which can be php code, for example. It will check for the cookie, then check for the identifier, then load the resource accordingly. You may also want to check for Referer to restrict the access a bit more (without checking, hot linking will work for any logged in user).
In this implementation, sharing a hot link to a resource will not work for any user that haven't visited the "portal" page (or haven't logged in, depending on your web site). It will also not work even for logged in user if they click the link from somewhere else.
However, scraping your website for resources is simple in both implementations mentioned in your question, since scraper can freely adjust the HTTP header.
Related
I'm trying to add a test coverage badge to the Readme of a private repository on GitHub. Our continuous integration process saves out the image to a secured Google Cloud Storage bucket that's not accessible to the public, and should remain that way.
Google's authorization layer is smart enough that if I go to the URL for the image, I'm automatically redirected to the resource with a valid auto-generated signed URL.
E.g., if I go to http://storage.cloud.google.com/secret-files/mysecretfile.png, then if I'm logged in and allowed to view it, I'm automatically redirected to something like https://blahblah-apidata.googleusercontent.com/download/storage/v1/b/secret-files/o/mysecretfile.png?key=verylongkey, where I can load the image.
This seemed perfect. Reference the canonical path in the GitHub Readme, authenticated users see the image, unauthenticated users are still blocked, we don't have to make the file public, and we don't have to do anything complicated.
Except that GitHub is proxying the image request, meaning that it will always be unauthenticated. My browser is loading something like https://camo.githubusercontent.com/mysecretimage.png.
Is there a clever way to work around this? Or do I need to go back to the drawing board?
All images on github.com are proxied using the Camo image proxy. There are a couple reasons for this:
It preserves the privacy of users. It isn't possible for a document to track users by directing them to a different site or using cookies to track them.
It means images can be cached and served at an appropriate size.
GitHub can have a very strict content security policy that does not allow loading from untrusted sites, which means that any sort of accidental security problem (like an XSS) is a lot less likely to work.
Note the last part. Even if you found some sneaky way to get another image URL to render properly in the website, your browser wouldn't load it because it violates the Content-Security-Policy header the site sent, and moreover, your browser would tattle about that to the reporting URL that GitHub provided.
So any image URL you provide will need to be readable by GitHub's image proxy and it won't be possible to serve different content to different users.
I have built a cookie consent module that is used on many sites, all using the same server architecture, on the same cluster. For the visitors of these sites it is possible to administer their cookie settings (eg. no advertising cookies, but allow analytics cookes) on a central domain that keeps track of the user preferences (and sites that are visited).
When they change their settings, all sites that the visitor has been to that are using my module (kept in cookie) are contacted by loading it with a parameter in hidden iframes. I tried the same with images.
On these sites a rewrite rule is in place that detects that parameter and then retracts the cookie (set the date in the past) and redirects to a page on the module site (or an image on the module site).
This scheme is working in all browsers, except IE, as it needs a P3P (Probably the reason why it is not working for images is similar).
I also tried loading a non-existent image on the source domain (that is, the domain that is using the module) through an image tag, obviously resulting in a 404. This works on all browsers, except Safari, which doesn't set cookies on 404's (at least, that is my conclusion).
My question is, how would it be possible to retract the cookie consent cookie on the connected domains, given that all I can change are the rewrite rules?
I hope that I have explained the problem well enough for you guys to give an answer, and that a solution is possible...
I am still not able to resolve this question, but when looked at it the other way around there is a solution. Using JSONP (for an example, see: Basic example of using .ajax() with JSONP?), the client domain can load information from the master server and compare that to local information.
Based on that, the client site can retract the cookie (or even replace it) and force a reload which will trigger the rewrite rules...
A drawback of this solution is that it will hit the server for every pageview, and in my case, that's a real problem. Only testing that every x minutes or so (by setting a temporary cookie) would provide a solution.
Another, even more simple solution would be to expire all the cookies on the client site every x hour. This will force a revisit of the main domain as well.
I have several audio files that I don't want to allow anyone else to gain access to them. Each file is in a separate folder inside a main folder, that I'll call "download" for now. So "download" has several other directories, and inside each directory are audio files. Those audio files are played with in a web app on the system.
The problem is that right now anyone can type in the full address of the file localhost/download/dir/sound.wav and play the audio file. This is what I want to prevent from happening, I want those files to only stream when they are access or streamed from our application.
I tried the following on the .htaccess file
deny from all
This just returned an 403 forbidden page, but i was unable to stream the file from within the application
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)localhost.com/.*$ [NC]
RewriteRule \.(mp3|wav)$ - [F]
This just disabled the stream all together did not return a 403 or anything it just did not stream from neither the application or direct access
Finally I'm using AJAX to call the script that holds the files to be streamed; are there any options I can use?
It is impossible to prevent the user from accessing those files
In order to hear them they have to be downloaded to the user's computer and that means that they have to be accessible!
The best you can do is encrypt the files and decrypt them in the player. But even then the player could be reverse-engineered and someone could discover the encryption key and algorithm. In the end you gonna find out that you just wasted a whole lot of processing time and in fact slowed down your application!
There is just one problem: how is server supposed to detect who has requested your media - application or some other system, just using similar protocol?
But if you just want to prevent simplest http request to you media, you could involve some token exchange system, e.g. your application sends request for media in certain format, server sends token for accessing certain file, and then your application may access special (say php) script supplying it with token, script returns your sound stream. This way, media can be forbidden to be accessed from outside world and only will be accessed by you own server-side php script.
Then in order to gain access to media file user would need to know your existing token or your exchange protocol which eliminates random users accessing your media at will. However, as you have been told before there is probably no way to protect against 'educated users'.
One possibility would be to:
Add an apache rewrite directive on that download folder to route all requests to a php script instead that takes the file requested as a parameter.
Create this script (say sound.php) in your application which takes that file path as a get parameter. This script can output the correct http headers to indicate that the type of data is wav or whatever you want. Then check some cookies or a token or similar, and output the content of the restricted file directly (see readfile) only if the user is valid.
Can someone please help me to find a solution to maintaining the session across subdomains.
The site uses fake subdomains for users, eg. (thisuser.mysite.com/). All the fake subdomains map to the main site (mysite.com) so there's a common database for everything.
The subdomains are used only for a couple of components(com_xxx) on the site. for other components the user is redirected to the main site via htaaccess.
The problem is when a user is redirected to mysite.com from thisuser.mysite.com and vice versa. Their session is not maintained. The user has to login back again.
I have tried updating the cookie domain in php.ini to '.mysite.com' but it doesnt seem to help.
Is it possible that the site may have auto-logins across all subdomains and main domain without any core hacks, assuming the solution lies in making cookies readable from all subdomains, irrespective of from where it's being set?
Thanks all, for your time and suggestions !
I'm not sure how you could do this....
Here is just an idea, it would rely on javascript...
WHen a user logs in using your login form... a hidden iframe would exist and javascript would post your login data to the login page of each domaine for your site. chaining them...
i dont feel its a safe thing tho... maybe im wrong...
u could use joomla's mootool framework to send an ajax requests to each domain...
Otherwise might want to check how joomla creates a session row in the database for each user on the site. maybe you can just create them for each domaine with 1 login. im gona check my mysql....
are you using joomla 1.5 or 2.5 ?
Otherwise i found this document for you:
http://docs.joomla.org/Multiple_Domains_and_Web_Sites_in_a_single_Joomla!_installation
okay, this was easy, I was testing on the local machine and it seems if domain doesnt have the dot, then the cookies are not handled well.
Just ensuring taht cookie domain is set to '.mysite.com' gets the job done
1. It is also recommended that you use the same joomla "secret" configuration value in the different websites as it is used to check the data exchanged between the different domains.
2. taht cookie domain is set to '.mysite.com' gets the job done
One of YSlow's measurables is to use cookie-free domains to serve static files.
"When the browser requests a static
image and sends cookies with the
request, the server ignores the
cookies. These cookies are unnecessary
network traffic. To workaround this
problem, make sure that static
components are requested with
cookie-free requests by creating a
subdomain and hosting them there." --
Yahoo YSlow
I interpret this to mean that I could experience performance gains if I move www.example.com/images to static.example.com/images.
Although this is easy to do, I would lose the handy ability within my content management system (Joomla/WordPress) to easily reference and link to these images.
Is it possible to use .htaccess to redirect all requests for a particular folder on www.example.com to a folder on static.example.com instead? Would this method also fool the CMS into thinking the images were located in the default locations on its own domain?
Is it possible to use .htaccess to redirect all requests
for a particular folder on www.example.com to a folder on
static.example.com instead?
Possible, but counter productive — the client would have to make an HTTP request, get the redirect response, then make another HTTP request.
This costs a lot more than the single line of cookie data saved!
Would this method also fool the CMS into thinking the images
were located in the default locations on its own domain?
No.
Although this is easy to do, I would
lose the handy ability within my
content management system
(Joomla/WordPress) to easily reference
and link to these images.
What you could try to do is create a plugin in Joomla that dinamically creates these references.
For example, you have a plugin that when you enter {dinamic_path path} in an article, it appends 'static.example.com/images' to the path provided. So, everytime you need to change the server path, you just change in the plugin. For the links that are already in the database, you can try to use phpMyAdmin to change them in this structure.
It still loses the WYSIWYG hability in TinyMCE, but is an alternative.
In theory you could create a virtual domain that points directly to the images folder, such as images.example.com. Then in your CMS (hopefully at the theme layer) you could replace any paths that point to the images folder with an absolute path to the subdomain.
The redirects would cause far more network traffic, and far more latency, than simply leaving things as they are.
It would redirect the request but the client would still be sending its cookies to the server, so really you accomplished nothing. You would have to directly access the files from a domain that isn't storing cookies for it to work.
What you really want to do is use staticexample.com/images instead of static.example.com/images so that you don't pick up any cookies on the example.com domain that you may have set. If all you do is server images from that domain with a simple apache server or something then you can configure that server not to return even a session cookie.
The redirects are a very bad idea. Cookies cause some performance hits but round trips to the server such as a redirect would cause are a much more serious performance issue.
I did below and gained success:
<FilesMatch "!\.(gif|jpe?g|png)$">
php_value session.cookie_domain example.com
</FilesMatch>
What it means is that if you do not set images in cookie information.
Then images are cookie-free with server.