13

I am working on a web page that uses a lot of AJAX to communicate with the server. The server, in turn, has an extensive REST/JSON API exposing the different operations called by the web client.

This web site is used by both anonymous and authenticated users. As you might expect, the web service calls issued by authenticated users require authentication, and are thus protected from unauthorized users or applications.

However, the web site has a lot of features that require no authentication, and some of these make use of anonymous web services. The only way I am using to prevent outsiders from calling this web services is by using a CSRF token. I know, the CSRF token is not very useful in this regard... with some time in hand, you can figure out how to consume the web services even if they use a CSRF token.

Of course, you can use a CAPTCHA to prevent applications or bots from autonomously using your web service. However, any human will be able to use it.

Sharing a secret key between client and server, on the other side, would be useless. This, because of the ability of any outsider to read it from the web page source code.

I would like to make these web services as difficult to invoke as posible to any 3rd party application. What would you do besides using the CSRF token? It sounds a little stupid, but hey, maybe it is stupid and I am just losing my time.

Note: given this application uses a browser and not an "executable" as the client, this question is irrelevant to the discussion. I cannot use a secret between server and client (not to my knowledge, at least)

Community
  • 1
  • 1
Pablo Marambio
  • 1,562
  • 1
  • 15
  • 29

5 Answers5

2

I would take a few steps.

  • Force https on the site. Automatically redirect any incoming http requests to https ones (the RequireHttps attribute is handy for this)
  • Each page needs to (securely, hence the https) send a one-time use token to the client, to be used for the page. The script running on the client can hold this in the page memory. Any request coming back sends a hashed & salted response, along with the nonce salt. The server can repeat the steps with the saved token + salt and hash to confirm the request. (much like explunit's answer above) (It's worth noting that the secure request from a client isn't being authenticated from a user account, merely a token sent with the full page.)
  • The definition for one-time could either be session or page load, depending on your security vs convenience preference. Tokens should be long and expired fairly quickly to frustrate attackers.

The SSL + Hash(token + nonce) should be enough for your needs.

Christopher Stevenson
  • 2,843
  • 20
  • 25
2

This is interesting. Below is a crazy suggestion. Remember, your question is also equally crazy.

Your website, once opened through a browser, should generate a long polling connection (Comet programing). This will create a unique session between the browser and the server. When ur JS is making the ajax call, send some token (unique token every time) to the server through the long polling thread. Let the AJAX also send the same token. At the server, get the AJAX token and check whether you have a similar token in you long polling session. If yes, fulfill the request. Any coder can break this. But, it won't be easy. Chances are the freeboarders won't even see these second piece of comet code. You can implement the comet code in such a way it is not easy to detect or understand. When they call ur service, send a 'Service Unavailable' message. They will be confused. Also make the comet code https.

You can also check how long that long polling thread is open. If the session was just opened and you get a ajax call right away, you can assume it is a 3rd party call. It depends on ur website flow. If ur Ajax call happens after 1 second of page load, you can check for that pattern on server side.

Anyone coding for your public api, will have 1 to 2 secret checks that they wouldn't even know and even if they know, they might be discouraged by all the extra coding they have to do.

Arun J
  • 537
  • 2
  • 12
  • No one is going to "guess" at what the calls are, so those attempts at fooling humans aren't really going to work. They'd simply go through as a normal user and record the transmissions to/from the server. It would quickly reveal any oddities as part of the actual security handshake... – badunk Oct 11 '13 at 07:42
1

You might have an easier problem than the one described in the linked question since you don't need to distribute a binary to the users. Even if your app is open source, the HMAC/signature key (in the "Request Signatures" part of that answer) can be controlled by an environment/configuration setting.

To summarize:

  1. The secret key is not actually sent between client and server. Rather, it's used to sign the requests
  2. Be sure that the requests include some unique/random element (your CSRF key probably suffices) so that two requests for the same API data are not identical.
  3. Sign the request with the secret key and append the signature to the request. You linked to a PHP question but not clear if what language you're using. In .Net I would use a HMAC class such as HMACSHA256.
  4. On the API server-side use the same HMAC object to verify that the request was signed with the same secret key.
explunit
  • 18,967
  • 6
  • 69
  • 94
  • I think I might have explained myself incorrectly. This is a Web Application, and I am talking about the *anonymously accesible components* it exposes. I understand that request signatures need not to append the secret key. However, ¿how would you securely distribute that key, given the Web Application is anonymously accesible? – Pablo Marambio Oct 12 '12 at 19:49
  • I thought the question was about controlling access to the web services/API, not the web site itself. I.e. you want only **your** web site code to call the API, not some other web site or bot. And since you control the server-side logic for both pieces, they have a shared key between them that's used to authenticate the requests. – explunit Oct 13 '12 at 01:17
1

Maybe you could use counters to keep track of conversations. Only the Server and Clients will be able to predict the next iteration in a conversation. This way, I think, you can prevent third party applications to impersonate someone (Just an idea though).

At the beginning, they start talking at some iteration (i=0, for example).

  • Every time the client requests something, the counter is incremented by some number in both the server side and the client (i=i+some_number).

  • And, after a few minutes of no communication, they both know they have to reset the counter (i=0).

Luis Ortega Araneda
  • 865
  • 1
  • 12
  • 26
1

This is just an idea based on the concept of RSA and also placing Fraud Detection on your system. The Risk from Authorized users is minimal however they can attempt to make anonymous calls to your web-service too.

For UN-Authorised users : For each web-service call , generate a token say using RSA which changes after some time(can be configured say 30 min). This way prediction of code is minimized. I have not heard of RSA collision till now. Send this token back to the user for his browser session. For further security , we might want to attach a session id with RSA token. Since session ids are unique new anonymous calls would require new session id.

Calls can be tracked using Auditing mechanism. Also per-web service there can be a different RSA setup. How the Algorithm for Fraud Detection would work is a challenge by itself.

For Authorized Users : Every user should be tracked by his IP Address using Header block. The RSA token principle can be applied.

The solution is very vague but worth considering.

user1428716
  • 2,078
  • 2
  • 18
  • 37