I need resources for API security basics. Any suggestions?

I've done a little googling but have been a bit overwhelmed by the amount of information. Until now, I've been considering asking for a valid md5 hash for every API call but I realized that it wouldn't be a difficult task to开发者_Python百科 hijack such a system. Would you guys be kind enough to provide me with a few links that might help me in my search? Thanks.

First, consider OAuth. It's somewhat of a standard for web-based APIs nowadays.

Second, some other potential resources -

A couple of decent blog entries:

• http://blog.sonoasystems.com/detail/dont_roll_your_own_api_security_recommendations1/
• http://blog.sonoasystems.com/detail/more_api_security_choices_oauth_ssl_saml_and_rolling_your_own/

A previous question:

• Good approach for a web API token scheme?

I'd like to add some clarifying information to this question. The "use OAuth" answer is correct, but also loaded (given the spec is quite long and people who aren't familiar with it typically want to kill themselves after seeing it).

I wrote up a story-style tutorial on how to go from no security to HMAC-based security when designing a secure REST API here:

• http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/

This ends up being basically what is known as "2-legged OAuth"; because OAuth was originally intended to verifying client applications, the flow is 3-parts involving the authenticating service, the user staring at the screen and the service that wants to use the client's credentials.

2-legged OAuth (and what I outline in depth in that article) is intended for service APIs to authenticate between each other. For example, this is the approach Amazon Web Services uses for all their API calls.

The gist is that with any request over HTTP you have to consider the attack vector where some malicious man-in-the-middle is recording and replaying or changing your requests.

For example, you issue a POST to /user/create with name 'bob', well the man-in-the-middle can issue a POST to /user/delete with name 'bob' just to be nasty.

The client and server need some way to trust each other and the only way that can happen is via public/private keys.

You can't just pass the public/private keys back and forth NOR can you simply provide a unique token signed with the private key (which is typically what most people do and think that makes them safe), while that will identify the original request coming from the real client, it still leaves the arguments to the comment open to change.

For example, if I send: /chargeCC?user=bob&amt=100.00&key=kjDSLKjdasdmiUDSkjh

where the key is my public key signed by my private key only a man-in-the-middle can intercept this call, and re-submit it to the server with an "amt" value of "10000.00" instead.

The key is that you have to include ALL the parameters you send in the hash calculation, so when the server gets it, it re-vets all the values by recalculating the same hash on its side.

REMINDER: Only the client and server know the private key.

This style of verification is called an "HMAC"; it is a checksum verifying the contents of the request.

Because hash generation is SO touchy and must be done EXACTLY the same on both the client and server in order to get the same hash, there are super-strict rules on exactly how all the values should be combined.

For example, these two lines provides VERY different hashes when you try and sign them with SHA-1: /chargeCC&user=bob&amt=100 /chargeCC&amt=100&user=bob

A lot of the OAuth spec is spent describing that exact method of combination in excruciating detail, using terminology like "natural byte ordering" and other non-human-readable garbage.

It is important though, because if you get that combination of values wrong, the client and server cannot correctly vet each other's requests.

You also can't take shortcuts and just concatonate everything into a huge String, Amazon tried this with AWS Signature Version 1 and it turned out wrong.

I hope all of that helps, feel free to ask questions if you are stuck.