CODEWITHSUNDEEP
javascriptphpajaxsecurityendpoint
GluePear
GluePear

Reputation: 7715

Protect PHP endpoints called by AJAX

My app consists of several PHP endpoints which are accessible via AJAX. The problem is they are also accessible via anyone who makes an HTTP request to the same endpoint. I can add checks for HTTP_X_REQUESTED_WITH and HTTP_REFERER as specified in this answer, but these can be spoofed. I could add a secret key that needs to be posted with the request, but anyone viewing the javascript and/or the console would be able to see this key. What is the solution here?

Upvotes: 4

Views: 2142

Answers (4)

Steven M
Steven M

Reputation: 574

Most of the answers are not helpful if you have your app and your api on separate domains for example app.example.com and api.example.com - in that case sessions won't work and you would have to turn to OAuth which is quite a big hammer for such a simple problem.

Here is what I would do:

I assume you have users in a database and a unique identifier like user_id=12345. I also assume that you have your Jobs in a Database and they also have unique ID's like job_id=6789.

First on app.example.com you encrypt both IDs with something fast and easy like Blowfish:

$secret_uid = mcrypt_encrypt(MCRYPT_BLOWFISH, "your_secret", strval($user_id));
$secret_jid = mcrypt_encrypt(MCRYPT_BLOWFISH, "your_secret", strval($job_id));

I assume your endpoint would work somewhat like this:

api.example.com/jobs/delete/<job_id>/<user_id>

so now from Ajax you call that endpoint, but instead of calling with plain IDs 

api.example.com/jobs/delete/6789/12345

you call it with the encrypted IDs:

api.example.com/jobs/delete/6A73D5B557C622B3/57F064C07F83644F

On the API side of your software you decrypt the parameters:

$jid = mcrypt_decrypt(MCRYPT_BLOWFISH, "your_secret", <param_1>);
$uid = mcrypt_decrypt(MCRYPT_BLOWFISH, "your_secret", <param_2>);

Now you can search your db for uid and jid and perform whichever task you were planning to do. Make sure that a user can only delete his own jobs of course.

I admit this is not a 100% solution, but it leaves an attacker with a lot of guess work - he would have to guess the user_id and a matching job_id, the encryption algo and your secret. It does not protect against running millions of brute force attempts to guess a matching pair, but it put's the odds in your favor (and you should have some sort of quota limitation protection of your endpoints anyway).

Good luck!

Upvotes: 4

Marmik Bhatt
Marmik Bhatt

Reputation: 607

it is very important for a developer to put authentication for API or web services. dchacke and BugHunterUK has given perfect answers, I just want show you simple code I use to make very simple and easy to use authentication.

Adding Session for the authentication

you can add session, and session timeout for your APIs so, only your app can use this, you can start session when front page of your app is loaded, you can set timeouts and also restrict the different service for different users by sessions.

General Idea how to do that

<?php
if(!empty($_SESSION['api_session']) && $_SESSION['api_session'] == 'usertype'){
 //usertype comprise of what access you want to give 
 //guest, registered user, stack holder, admin etc. 
...
header('Content-Type:application/json;');
echo json_encode($output);
}

Upvotes: 0

BugHunterUK
BugHunterUK

Reputation: 8938

People often think that because they're using Ajax requests regular sessions don't work. They do. If you have an endpoint to delete something from the database that's visible in the source code, such as:

example.com/user/1/delete

You can protect this request from non authenticated users the same way you would when using a non Ajax HTTP request in the browser. Using sessions. If the user has the privileges to remove users, this route will work, otherwise return an error (or do nothing).

You can also protect an API using OAuth. There's a great document here that explains how it works: http://tatiyants.com/using-oauth-to-protect-internal-rest-api/

Upvotes: 4

Quentin
Quentin

Reputation: 943142

There isn't one. If you give someone some data, then they can process it in whatever way they like. You can't control what happens to it after it leaves your server.

Likewise, you can't control what data they send to the endpoint.

Upvotes: 2

Related Questions