I have done some researches on how to prevent fake cross-origin requests and have found a lot of useful information. However, none of them seems to directly resolve my concerns, and because my application has to deal with this specific situation, I would like to understand it completely.
I have a simple php mailing website: mailsite.com
This site will allow other pre-defined addresses, for instance, user.com, to send POST data to it, and process the information that contains to and mesaage; then send them an E-mail from mailsite.com to to with the message message.
Currently, I am using $_SERVER[ "HTTP_ORIGIN" ] and $_SERVER[ "HTTP_REFERER" ] to check where the requests come from; and process them if it is from the pre-defined domains. However, I've read some articles that say:
HTTP_ORIGIN is not even indexed in PHP documentation, because it is pretty much per-browser sort of thing, so browsers that refuse to send those information will not work. HTTP_REFERER is easy to fake.
Tokens are good in preventing CSRF.
However, the request I allow is coming from a third pre-defined website, how does Tokens work in this situation?
My question is: If I allow specific domains to POST data to my site, how can I make sure (or the most secured way) that those requests are coming from the sites I expected? Is HTTP_ORIGIN not even safe enough to use? I dare to think about allowing third website to POST data to my site because I've seen Facebook allowing people to access their database. There must be some possible solutions for checking where the requests come from.
It sounds like you have multiple solutions possible:
Use a token permission system. Give user.com a private token to add as a hidden value to the input form. Upon submitting this form, the browser will give your server the token, and the user shouldn't have to know about the token. You check the token against your own database. If you find the token, allow the mail to be sent.
Use CORS (Cross-Origin Resource Sharing). When an Ajax request is sent to your server from user.com, there should be multiple Access-Control headers. You check if these exist and what their values are using $_SERVER['HTTP_ACCESS_CONTROL_header'] where header is one of the Access-Control header names. If these values match up to your expectations, respond with multiple header('Access-Control-header: value'); calls so that the browser knows you accepted the preflight request, otherwise don't add any extra headers. The browser will send another request after the preflight, and this is when you'll actually send the mail.
If this is being sent from user.com's server rather than a visitor of user.com, most likely the server's IP address won't change (though it may or may not use a defined range of IPs, so be mindful of that.), so you could verify that the $_SERVER['REMOTE_ADDR'] matches a value in your database. You can keep a table of approved IP addresses in your database for this purpose. If you find the IP address in your table, allow the mail to be sent.
Hope this helps.
Related
I've built an API for providing some data a user needs to get. So every time a user hits the server with a curl post request and the server checks the header auth token and provides the data. Now I want to
check the domain from where the post request comes from
. How could I check this?
That isn't feasible as far as I can tell.
Browsers may send a Referer (sic) HTTP header, but Curl clients don't normally care. In any case the information is provided by the client so it isn't something you can trust.
The IP address of the incoming request may or may not be the actual client address. Even if it is, an IP address can resolve to zero, one or several domains.
I have a simple PHP script which accepts a $_REQUEST from a javascript Ajax call and adds a post to the DB
But I need to ensure that only javascript requests from my domain is allowed, to prevent someone from submitting thousands of junk posts to my DB.
My question is, how do I ensure that my script only accepts $_REQUEST from my domain?
Thanks
The short answer is: You can't.
It sounds like you need to introduce the usual defences against CSRF (i.e. to generate a random security token and store it in a cookie (or session) as well as in your HTML document. You then submit the token as part of your request and compare it to the one in the cookie. If they match, then it is an intentional post from the user and not their browser being tricked into making the request by another site).
This won't stop people submitting "thousands of junk posts" though. You also need to authenticate users and check they are authorised to make a submission before allowing it to go through.
You can consider also including rate limiting checks and spam filtering.
You use a 'secret' key, a response and a remote IP to validate.
Google has provided this for you
https://developers.google.com/recaptcha/docs/verify
https://developers.google.com/recaptcha/docs/display
https://developers.google.com/recaptcha/docs/invisible#auto_render
works like a charm.
Once you implement you get an ADMIN panel here:
https://www.google.com/recaptcha/admin
At which time you set the Domains to be ONLY your URL's.
Which will do what you want and make sure the form validates from your domain using both keys from server side and client side integration. If someone try's to generate the "key" using their domain recaptcha will detect it as spam.
(see the verify link above)
I'm seeking to utilize an iframe to embed some html in customers websites that will list some information from my database using a simple GET request like so:
// customer would copy/paste this code onto their site
// value of key would be unique key for that customer
<iframe src='http://mydomain.php/api?key=1234j1lj1hj124kh' ></iframe>
Now I want to be able to verify that the request is coming from customer that owns the key, and not just anybody who copy/pasted that code onto their page.
I've done some research and found that $_SERVER['HTTP_REFERRER'] can give me this information, but with mostly mixed reviews saying it isn't always reliable (and most of the questions I came across were a couple years old).
QUESTIONS
1.) Is this method of using an iframe/GET request the standard way of achieving this functionality?
2.) Is there a standard, SECURE and RELIABLE way to verify the origin of the GET request?
Unfortunately this is not possible in a secure way.
To answer your questions: In fact this is not a standard functionality itself. I mean, there is no standard secure way of allowing content to be loaded only through iframes from allowed websites.
There are three parties in this communication:
1) Your website
2) Customer website that loads your website's data in an iframe
3) End user visiting customer website
When an end user visits customer web site, he will perform a GET request to your website through the iframe. At this connection, 2nd party above (customer website) is not involved. In this case, there is no reliable way for your website to know whether this request is coming through the iframe or not. Only favor that party 2 does here is adding HTTP_REFERER header to end-user's request. But this header cannot be trusted.
For example, if I want to abuse this and show that content on my website, I can create a proxy page on my application, where I perform a back-end call to your app (adding a valid HTTP_REFERER header) and display results back.
Personally I would never use iFrames for this functionality. I am assuming that this has to be reasonably secure, which is why only your specified customer can view it? If for whatever reason you can't use PHP to embed the content you need to display (through the use of an "included" file for example), I would instead use AJAX which would still use any PHP user verification you have in place to dynamically load content into a secure webpage.
This is because your PHP user verification will (should!) use cookie/session information to determine which customer is viewing the page and therefore decide whether the content should be delivered, since Session variables are determined by a single unique code stored client-side, which match up to as much information as you want to collect about a user server-side (Which could include the last page they visited, which is what the "HTTP_REFERRER" variable would give you, if they came from another page on your website).
'$_SERVER' variables aren't reliable because they rely on the information given to them by the web browser when the request is made, and such information can easily be forged, by most people who have a basic understanding about how headers are sent.
In summary, use a NONCE (cookied), validate IP and user agent.
Steps:
When you deliver the outer frame, generate a unique identifier
(totally random, long string) and return that in a cookie with the
HTML content.
At the same time, note the IP and the user agent string you have
sent that unique identifier to, and store in a DB with the time.
When requesting the inner frame, assuming the same domain, the
cookie will come too. (If a different domain, you'll need to attach
the unique identifier as a visible string, but that's not really of
concern, just uglier)
If the user agent or IP do not match those you stored against the
unique string, or the request is too long (i.e. after an hour, or
whatever is reasonable for your application) or the unique string is used more than once
(or whatever other restrictions you place on it) then reject the
request and invalidate (delete) the unique identifier.
Not 100% foolproof, but just combine more options to make it less and less likely to be abused.
I've read these webpages:
PHP Form Security With Referer and http://www.mustap.com/phpzone_post_62_how-to-bypass-the-referer-se
So basically my question is how do we determine for certain that the request was sent from our own domain? Or is there no way at all?
(Question targeted at any server side language including but not limited to PHP/JSP/ASP.Net etc)
My Problem: I have a page at http://me.com/login and on form submit, it will post to itself the login particulars. So far so good. until someone else can simply do this
<form action="http://me.com/login">
<input name="password" value="p">
<input name="username" value="u">
</form>
and they can send a request to login to my application through their domain. I do not want this. I need a way to make sure that if my page receives a post, its from my domain. Else i will reject it.
Besides, I'm abit shock when i read this: There are plugins for Firefox that allow the user to specify whatever value they want to be supplied as the REFERER. source: http://www.phpbuilder.com/board/showthread.php?t=10324100
So we don't even need a hacker to break it now. Just about anyone could do it.
I need a solution to make sure that i reject ALL requests not from my domain.
So basically my question is how do we determine for certain that the request was sent from our own domain? Or is there no way at all?
You are asking the impossible. There is no way to know for certain that a submit button on a page on your domain generated the request.
You say it's not about CSRF, so I don't know why you are concerned. But the solutions are the same.
Check the HTTP_REFERER header anyway. If it isn't your domain, then reject the request. You'll probably need to accept missing headers though since some people disable it. This doesn't prevent people who mess with their browser settings from spoofing the value though. But it does prevent people who are tricked into submitting the form from another site (assuming they haven't disabled HTTP_REFERER).
Use a "nonce" or temporary token that is only valid for one request. Hence, the person who submits the request must visit your website at least once per request. This is basically the same thing as ensuring that the request originated from your website. You can also tie a nonce to an IP address or session to prevent people from querying your site and relying the token along to another computer.
There's no way to make sure where's the origin of the request. This is the nature of HTTP state-less protocol.
In common Referrer HTTP header is used as the source of request, but it can be manipulated easily.
Use a hidden input with an encrypted key that is held on your server, and make it change frequently (I give 30 seconds before it changes!). This wont stop it but will minimise the risk, also, log the failed attempts per IP and block that IP/user after the 4th failed attempt until re-verified via email.
If the username that had the failed attempts doesn't match the DB after the 4th time, block the IP and give an email to contact.
I have a Javascript widget that people can embed on their site.
I want to use a simple cross domain get request to pull in a hash.
However I need my PHP script to only allow this cross domain request from a series of domains I have stored in an array.
What can I do in my PHP script (not in .htaccessor iptables) to find out the source (hostname) of the get request?
Considering the client (user's browser) can send you whatever it wants, I would say there is no way to be sure which website your script is called from :
As you want to know the URL of the website embedding your widget, and not the address of the user, $_SERVER['REMOTE_HOST'] will not help
$_SERVER['HTTP_REFERER'] could seem OK, but actually is not :
The client doesn't have to send it (and it doesn't always do)
As it is sent by the client, it can be forged / faked Quite easily
So, I'd say there is no real solution to this problem, at least on your server's side (If I'm wrong, I'm interested to know !)
But maybe you can do something on the client's side : when writing all this, I thought about google maps, and it's system of API Key :
you have an (unique) API key four your domain
When you load the JS scripts from google, your send this key
if the key is not registered for the domain on which you are trying to display the map, there is an alert message, saying "The Google Maps API server rejected your request. This could be because the API key used on this site was registered for a different web site."
but the map seems to be displayed anyway -- at least on my test server
this alert is really anoying for the end-user, and I don't think anyone would want an alert displayed on their site because they are using your service withot authorisation...
Maybe you can have a look at how this is done for google maps :-)
You could use the $_SERVER variable. In particular the $_SERVER['REMOTE_HOST'] but see below for caveat:
However, your web server must be
configured to create this variable.
For example in Apache you'll need
HostnameLookups On inside httpd.conf
for it to exist. See also
gethostbyaddr().
If the requests are coming from JavaScript, you could check the HTTP referrer header ($_SERVER['HTTP_REFERER']). However, it's optional - some proxies or security programs strip the referrer header out of HTTP requests.