05.30.07A Method for Preventing Replay in APP Applications
Today I read an article on Pete Lacey’s blog about using message-level security in REST applications (especially using the Atom Publishing Protocol). There was a comment by Bob McCormick that I found interesting. Bob pointed out that the protocol is vulnerable to replay attacks.
A replay attack (if you don’t already know) is when a duplicate transaction is run against an account of some sort. I’m sure you’ve seen duplicate comments on a blog because someone clicked submit twice (don’t double-click on web forms, ‘kay?) or something similar.
Here is a simple method for preventing replay attacks in an APP application. It requires client-level support of ETags, but that shouldn’t be too much to ask. Say you want to purchase something on a mythical site (http://example.com/). You could do the following to make a transaction (a variant on what is currently in an example in the draft):
- Create a transaction using
POST - The server provides an ETag back with the response (as well as a content location URI).
- The client then PUTs the payment information to the URI specified in the content location, with a
If-Matchheader. This is important, as the server should not accept anyPUTrequests without the proper ETag. - If the entities match, the server accepts the
PUT, otherwise412 Precondition Failed. A new ETag SHOULD be generated upon thePUTand the credentials used to execute thePUT(say WSSE UsernameToken) should be invalidated. These two bits combine to ensure that the original transaction has taken place. A client can thenGETthe URI with the If-None-Match header set to the original ETag to ensure the transaction went through (in this case, a 304 Not Modified indicates that the transaction failed).
This method should work for most sensitive transactions but I admit it seems odd to make the 304 indicate failure.
