Authenticating cURL Requests

[mburt]

My question is huge, and it involves cross-server scripting. Basically it involves two files, one hosted on the server someone would be trying to log in from:

login.php:

<?php
//a <form> would send various input data here
if (count($_POST) > 0) {
  $c = curl_init();
  curl_setopt($c, CURLOPT_USERAGENT, $_SERVER["HTTP_USER_AGENT"]);
  curl_setopt($c, CURLOPT_URL, "..somedomain../validate.php");
  curl_setopt($c, CURLOPT_POST, count($_POST));
  curl_setopt($c, CURLOPT_POSTFIELDS, $_POST);
  $result = curl_exec($c);
  curl_close($c);
  if ($result) // login validate
}
?>

and validate.php on the other domain:

<?php
if (count($_POST) > 0) {
  // evaluate post data, validate login
  // if login is good:
  echo "1";
}
?>

However my question is this: is there any way that validate.php can check the domain that the cURL request comes from? Or in this case, the domain that login.php is on?

I thought of doing it this way, adding an input field with the domain name in it (this would be in login.php):

<input name="server" value="<?php echo $_SERVER["SERVER_NAME"]; ?>">

But obviously anyone could edit this input field and enter in any server name they would want. Therefore it wouldn't exactly be secure.

The point:
To only allow cross-domain logins for verified domains, so the domain that would be sent to validate.php would be checked with a database.

I'm trying to learn how to do some cross-server scripting and this is my first attempt at it. Any advice or constructive criticism gladly accepted.

Thanks all

[djr33]

Are you validating on the first server or on the second? You might want to do both. But let's start with one or the other. Which are you doing at the moment? Let's, for convenience, call one the FROM-server and the other the TO-server.

[mburt]

It's hard to speak in such vague terms, so let me try to clarify.

Let's say the main server is "michaelburtdesigns.com"
- this contains DB information
- validation is done here

The second server is "someserver.com"
- contains the html form element
- sends POST data to "michaelburtdesigns.com"

The process:
- html form is completed and sent
- info is sent to "michaelburtdesigns.com"
- post data is evaluated
- the domain the data is coming from, "someserver.com", is validated
- validation result is sent back

This is basically what I want to achieve

[djr33]

I'm asking a much simpler question than that. Let me see if this phrasing helps. Pick (1) or (2):

(1) Computer X validates data then sends it to computer Y.
(2) Computer X sends data to computer Y, then computer Y validates data.
(3) Both.


Secondly, your last posts makes sense (I think), but I don't see how curl fits in. It's not include in your description. Can't you just point the action of the HTML form directly to your other domain?

[mburt]

Yeah sorry, I'm not saying exactly what I'm trying to ask- and for the situation I'm describing I'm using number (2).

I'm thinking of a "login with Facebook" like function, where a website can use login credentials to verify a login session.

Using cURL I can actually do it- but there's no way to verify the domain that the login is coming from, and that's what I'm seeking to do.

Technically, file_get_contents() would do the exact same thing as using a executing a curl function but some (most?) servers aren't set up for external domains, for file_get_contents().

[djr33]

Hm. Is curl allowed to get what file_get_contents() cannot? I think there might be potential restrictions on both.

But now it's clearer.

Well, you could check the headers, but they're not entirely reliable. The IP of the server requesting it should be easy enough to check, just use $_SERVER['REMOTE_ADDR'], but I've heard that can (in weird cases) be faked.

Why not use some sort of personal key? (One per site that wants to connect to yours)

Generally, you need the same sort of security or lack thereof that other sites have for APIs, regardless of the language they use.

You should also limit the number of failed attempts per server to something reasonable, like 50 per hour, so they won't often hit that, but in case someone tries a brute force attack, they'll be denied.

Does any of that help?

By the way, there might be a way around this-- check out methods using JSON, called JSONP. Basically it's a way to dynamically generate a ".js" file that will allow you to send info to another server. It allows you to get around cross-domain security issues.
It only works if you have access to the server sending out info with the API, not the other way around. (That is, you can't force google to send you a JSONP file, but you could send one too google if it asked and you wanted to.) In this case, it should work for you. Security might still be an issue, but this might work out better for you.

Note that using JSONP would mean it would be clientside again, so the IP and request would be from the user, not your/their server. So this would limit extra serverside traffic as well, and allow you to track individual users directly.

[mburt]

Okay. Yes that's basically what I was looking for. I'll start doing some research with the $_SERVER["REMOTE_ADDR"], and go from there.

My problem with a "key" was that the key would always be visible in the HTML file of the secondary website (maybe in a hidden form element), and anyone else could grab that key and use it as their own- therefore getting around the "stored key" idea. My plan is to combine the unique key idea with the referrer domain name.

Thanks again,

Michael

[djr33]

If this is serverside, then, no, the key does not need to be visible.

Store the key serverside (in the PHP script as a variable for example), and never show the users. Then when you do the curl() request, add that key.

curl is entirely serverside, so you don't need to worry about the client ever seeing it. It's all hidden. And so can be the key.

That WON'T work if you do it with a clientside thing like the JSONP option.

Does that help?

[mburt]

Ah yes it does... Actually all I need to do is add it to the post data that curl sends, then validate it from on the other end.

This might work. Interestingly enough, curl allows the manipulation of post data so I think that might be the part that adds some security.

[djr33]

Security before curl: make sure it's not a spammer or someone trying to use it for evil purposes. Eg, check the HTTP_REFERER (page they came from). (And escape it to the extent that it won't break the curl command, but don't bother doing more than that.)

Security after receiving the data: now actually secure it; escape it, whatever.


CORRECTION: I made an error above-- it's REMOTE_ADDR for the IP, and HTTP_REFERER for the page that sent the user to that request. Sorry for any confusion. I've fixed the typo in my post (and edited yours in case anyone else reads this and might get confused). Note that both HTTP_REFERER and REMOTE_ADDR might help you-- that's why I confused them originally.