Due to hotlink protection I'm having difficulty displaying images. The http request send in order to obtain the images contains a non empty referer header. This causes the hotlink protection to kick in.
Using a referer control tool, I can block the referer, which bypasses hotlink protection. However now I want to do this in a PHP/HTML/javascript code. I found information that it is possible, but I don't fully understand how to implement it.
Can some one give me a hand?
Thanks in advance!
FYI: I have permission of the website to do the hotlinking, as it's for an android app. However they cannot provide me with an API.
There is no way to forge the referer header from a browser request, not even via a call made from JavaScript.
2022 UPDATE: As pointed out in the comments, and other answer, this is now possible (except on IE and other really old browsers).
You could set up a proxy server, that forges the Referer header. You then need to have your android app point to your own server to get all the images. You can do this from PHP, using the curl functions (or even directly via the socket API).
Note: if the purpose was to actually hotlink then this saves nothing, as you end up serving all the images. And it adds another moving part that could break. If your image supplier cannot give you a better solution, find another provider?
You can try to avoid hotlink protection by setting no-referrer value to attribute referrerpolicy of img element.
Details here.
Related
I want to put a restriction on my API so only registered users can use it on their websites. The javascript will be used on their website by pasting it into their html. Right now I use a token for each user but it's visible to the public on their site so anyone could copy it. It tracks usage but doesn't restrict it to only their site.
My first thought was to get the HTTP_REFERER variable from the http headers on the server and make sure it's from the domain registered by the user. This won't work because HTTP_REFERER can be blank or changed.
My second thought was to use JavaScript in the pasted script to get the document.location and pass that back the to server. That can also be tampered with so it is unreliable.
I'm looking at OAUTH2 now as a solution. I don't know much about it besides it's used for SSO. Looking at this JS OAUTH2 Lib too: https://github.com/andreassolberg/jso
Could they be used for what I need to do?
One requirement is that the script is pasted into the HTML. There shouldn't be any other configuration on their site that needs to be done.
What other solutions are their for this?
There shouldn't be any other configuration on their site that needs to be done other than pasting your javascript ?
Well, then probably OAUTH2 is not what you are looking for, OAUTH adds the concept of an authorization server to your web API and the complexity increases.
http://www.asp.net/aspnet/overview/owin-and-katana/owin-oauth-20-authorization-server
if you are not looking to authorize users but just identify domains that can consume your api from javascript, enable cors and add an attribute to specify which origins are allowed to access the resource. Example :
http://www.asp.net/web-api/overview/security/enabling-cross-origin-requests-in-web-api
Thanks.
I have some HTML/PHP pages that include javascript calls.
Those calls points on JS/PHP methods included into a library (PIWIK) stored onto a distant server.
They are triggered using an http://www.domainname.com/ prefix to point the correct files.
I cannot modify the source code of the library.
When my own HTML/PHP pages are locally previewed within a browser, I mean using a c:\xxxx kind path, not a localhost://xxxx one, the distant script are called and do their process.
I don't want this to happen, only allowing those scripts to execute if they are called from a www.domainname.com page.
Can you help me to secure this ?
One can for sure directly bypass this security modifying the web pages on-the-fly with some browser add-on while browsing the real web site, but it's a little bit harder to achieve.
I've opened an issue onto the PIWIK issue tracker, but I would like to secure and protect my web site and the according statistics as soon as possible from this issue, waiting for a further Piwik update.
EDIT
The process I'd like to put in place would be :
Someone opens a page from anywhere than www.domainname.com
> this page calls a JS method on a distant server (or not, may be copied locally),
> this script calls a php script on the distant server
> the PHP script says "hey, from where damn do yo call me, go to hell !". Or the PHP script just do not execute....
I've tried to play with .htaccess for that, but as any JS script must be on a client, it blocks also the legitimate calls from www.domainname.com
Untested, but I think you can use php_sapi_name() or the PHP_SAPI constant to detect the interface PHP is using, and do logic accordingly.
Not wanting to sound cheeky, but your situation sounds rather scary and I would advise searching for some PHP configuration best practices regarding security ;)
Edit after the question has been amended twice:
Now the problem is more clear. But you will struggle to secure this if the JavaScript and PHP are not on the same server.
If they are not on the same server, you will be reliant on HTTP headers (like the Referer or Origin header) which are fakeable.
But PIWIK already tracks the referer ("Piwik uses first-party cookies to keep track some information (number of visits, original referrer, and unique visitor ID)" so you can discount hits from invalid referrers.
If that is not enough, the standard way of being sure that the request to a web service comes from a verified source is to use a standard Cross-Site Request Forgery prevention technique -- a CSRF "token", sometimes also called "crumb" or "nonce", and as this is analytics software I would be surprised if PIWIK does not do this already, if it is possible with their architecture. I would ask them.
Most web frameworks these days have CSRF token generators & API's you should be able to make use of, it's not hard to make your own, but if you cannot amend the JS you will have problems passing the token around. Again PIWIK JS API may have methods for passing session ID's & similar data around.
Original answer
This can be accomplished with a Content Security Policy to restrict the domains that scripts can be called from:
CSP defines the Content-Security-Policy HTTP header that allows you to create a whitelist of sources of trusted content, and instructs the browser to only execute or render resources from those sources.
Therefore, you can set the script policy to self to only allow scripts from your current domain (the filing system) to be executed. Any remote ones will not be allowed.
Normally this would only be available from a source where you get set HTTP headers, but as you are running from the local filing system this is not possible. However, you may be able to get around this with the http-equiv <meta> tag:
Authors who are unable to support signaling via HTTP headers can use tags with http-equiv="X-Content-Security-Policy" to define their policies. HTTP header-based policy will take precedence over tag-based policy if both are present.
Answer after question edit
Look into the Referer or Origin HTTP headers. Referer is available for most requests, however it is not sent from HTTPS resources in the browser and if the user has a proxy or privacy plugin installed it may block this header.
Origin is available for XHR requests only made cross domain, or even same domain for some browsers.
You will be able to check that these headers contain your domain where you will want the scripts to be called from. See here for how to do this with htaccess.
At the end of the day this doesn't make it secure, but as in your own words will make it a little bit harder to achieve.
I have a main header page that is included in many different applications across a couple of different languages, including Java and classic ASP. The file (file.js) is going to be obsolete soon. We are going to be going to an "out-of-the-box" solution, a new header created by another group. They gave us a link ("google.com") that we need to use to show this new header. I was wondering if there was a simple solution I could implement in my file.js that would show this content to the users. I know an easy way to do it in jsp is
<c:import url="http://google.com"/>
but this won't work in the js file, nor will it work in the jsp. Is there a way for me to do this?
Thank you,
Explosive_donut
Obviously the URL you are really given isn't Google. I suppose the second team is able to modify their own (document) headers sent to clients.
First way I think of is to use AJAX to retrieve the contents of the URL and create a div or select an existing to set its new content.
Unfortunately AJAX is restricted to the Same Origin Policy which can be circumvented with CORS (Cross Origin Resource Sharing). To allow CORS, your remote server as well as your client maschines need to send respective headers. Check out the link for more information.
If you need any more information and/or tutorials, let me know in the comments.
I run a site A and I want to be able to POST data to site B, which is hosted on a different subdomain. Now I have complete access to A, but cannot modify B at all.
My requirements are:
supports file upload
does not refresh browser on POST
uses Windows integrated security
works in IE 7/8 (does not need to support any other browsers)
What's the best way to accomplish this?
What I've tried:
Ideally this could be done in a simple AJAX call. However the current standard does not support sending binary data (supported in the XMLHttpRequest Level 2 standard, which is not implemented in IE yet).
So the next best thing is to POST to a hidden <iframe> element. Now I've tried this but the server on site B won't accept the data. I looked at the request and the only discrepancies that I found were the referer URL and the integrated authentication. The referer URL might have to be spoofed, which cannot be accomplished by this method. Also for some reason the authentication isn't being negotiated. I'm not 100% sure why.
Ideas:
I'm thinking of creating a proxy page on the server that I run (site A) that forwards the request to site B. Site A also uses integrated security. I don't see anything wrong with this, but I'm not sure if this is the best way to go. Will there be any authentication issues if I just forward the request over?
Using a proxy seems to be the only thing which can work in your case. If you want to make a get request then it can be done using JSONP provided that the server supports JSONP. To make the <iframe> hack work the server should send the headers as
Access-Control-Allow-Origin:*
which is not the case with you.
So using a proxy seems the solution
Is it possible through jQuery (or plain javascript) to test if a webpage on another domain is available?
I tried getting the response headers with an ajax-call but I get an error no matter what site outside my own domain I test.
So do I really need a proxy script on my server or would I be able to skip that request?
Is it possible through jQuery (or plain javascript) to test if a webpage on another domain is available?
Due to same origin policy restriction you need a proxy/bridge on your server unless the remote server implements JSONP which obviously we cannot assume for the general case.
You can create an <img> tag that points to an existing image on the external domain.
If the onerror event fires, image, and perhaps the entire site, is down.
If it fires after 5 seconds or so, it probably timed out, so the entire site is likely to be down.
Yes, you need to use a proxy script on your server. JavaScript cannot be used in a browser to request resources across domains, as per the same-origin policy.