How do I restrict JSON access?

问题:

I have a web application that pulls data from my newly created JSON API.

My static HTML pages dynamically calls the JSON API via JavaScript from the static HTML page.

How do I restrict access to my JSON API so that only I (my website) can call from it?

In case it helps, my API is something like: http://example.com/json/?var1=x&var2=y&var3=z... which generates the appropriate JSON based on the query.

I'm using PHP to generate my JSON results ... can restricting access to the JSON API be as simple as checking the $_SERVER['HTTP_REFERER'] to ensure that the API is only being called from my domain and not a remote user?

回答1:

The usual method for restricting access to your domain is prepend the content with something that runs infinitely.

For example:

while(1);{"json": "here"} // google uses this method
for (;;);{"json": "here"} // facebook uses this method

So when you fetch this via XMLHttpRequest or any other method that is restricted solely to your domain, you know that you need to parse out the infinite loop. But if it is fetched via script node:

<script src="http://some.server/secret_api?..."></script>

It will fail because the script will never get beyond the first statement.

回答2:

I think you might be misunderstanding the part where the JSON request is initiated from the user's browser rather than from your own server. The static HTML page is delivered to the user's browser, then it turns around and executes the Javascript code on the page. This code opens a new connection back to your server to obtain the JSON data. From your PHP script's point of view, the JSON request comes from somewhere in the outside world.

Given the above mechanism, there isn't much you can do to prevent anybody from calling the JSON API outside the context of your HTML page.

回答3:

In my opinion, you can't restrict the access, only make it harder. It's a bit like access-restriction by obscurity. Referrers can be easily forged, and even with the short-lived key a script can get the responses by constantly refreshing the key.

So, what can we do?

Identify the weakness here:

http://www.example.com/json/getUserInfo.php?id=443

The attacker now can easily request all user info from 1 to 1.000.000 in a loop. The weak point of auto_increment IDs is their linearity and that they're easy to guess.

Solution: use non-numeric unique identifiers for your data.

http://www.example.com/json/getUserInfo.php?userid=XijjP4ow

You can't loop over those. True, you can still parse the HTML pages for keys for all kinds of keys, but this type of attack is different (and more easily avoidable) problem.

Downside: of course you can't use this method to restrict queries that aren't key-dependent, e.g. search.

回答4:

Any solution here is going to be imperfect if your static pages that use the API need to be on the public Internet. Since you need to be able to have the client's browser send the request and have it be honored, it's possibly for just about anyone to see exactly how you are forming that URL.

You can have the app behind your API check the http referrer, but that is easy to fake if somebody wants to.

If it's not a requirement for the pages to be static, you could try something where you have a short-lived "key" generated by the API and included in the HTML response of the first page which gets passed along as a parameter back to the API. This would add overhead to your API though as you would have to have the server on that end maintain a list of "keys" that are valid, how long they are valid for, etc.

So, you can take some steps which won't cost a lot but aren't hard to get around if someone really wants to, or you can spend more time to make it a tiny bit harder, but there is no perfect way to do this if your API has to be publically-accessible.

回答5:

The short answer is: anyone who can access the pages of your website will also be able to access your API.

You can attempt to make using your API more difficult by encrypting it in various ways, but since you'll have to include JavaScript code for decrypting the output of your API, you're just going to be setting yourself up for an arms race with anyone who decides they want to use your API through other means. Even if you use short-lived keys, a determined "attacker" could always just scrape your HTML (along with the current key) just before using the API.

If all you want to do is prevent other websites from using your API on their web pages then you could use Referrer headers but keep in mind that not all browsers send Referrers (and some proxies strip them too!). This means you'd want to allow all requests missing a referrer, and this would only give you partial protection. Also, Referrers can be easily forged, so if some other website really wants to use your API they can always just spoof a browser and access your API from their servers.

回答6:

Are you, or can you use a cookie based authentication? My experience is based on ASP.NET forms authentication, but the same approach should be viable with PHP with a little code.

The basic idea is, when the user authenticates through the web app, a cookie that has an encrypted value is returned to the client browser. The json api would then use that cookie to validate the identity of the caller.

This approach obviously requires the use of cookies, so that may or may not be a problem for you.

回答7:

Sorry, maybe I'm wrong but... can it be made using HTTPS?

You can (?) have your API accessible via https://example.com/json/?var1=x&var2=y, thus only authenticated consumer can get your data...

回答8:

Sorry, there's no DRM on the web :-)

You can not treat HTML as a trusted client. It's a plain text script interpreted on other people's computers as they see fit. Whatever you allow your "own" JavaScript code do you allow anyone. You can't even define how long it's "yours" with Greasemonkey and Firebug in the wild.

You must duplicate all access control and business logic restrictions in the server as if none of it were present in your JavaScript client.

Include the service in your SSO, restrict the URLs each user has access to, design the service keeping wget as the client in mind, not your well behaved JavaScript code.