On Fri, Jul 12, 2013 at 9:32 AM, Johanneke Lamberink <[email protected]>wrote:
> But what would I put in there? Let's call it a sessionID, regardless of > the actual content. The only way this will give the protection I need > requires some sort of state on the server, doesn't it? > You could store some information about the request that is likely to be true of subsequent legitimate requests by the same client but not of a forged one, like the client's IP address. That doesn't require state on the server. It's by no means perfect, but it would force attackers to work harder to spoof client requests. > So I guess my question is, is it possible to protect against this specific > attack while maintaining a stateless server? Or did we already forfeit that > when we started setting cookies? > Aren't these three levels of protection sufficient? - Difficulty of obtaining a valid cookie in the first place. - Difficulty of using a valid cookie before it expires. - Difficulty of spoofing client-specific info. If an attacker is able to get to a client's cookie store, is not bothered by the expiration time limit, and can make requests with ClientInfo that matches the real client, then it's highly likely that the client is already deeply compromised, so keeping track of sessions on the server side doesn't really help: The attacker could just issue its requests in a valid session. So my answer is no, I don't think you give up security in any significant way by having a stateless server. If it still bothers you, though, why not isolate a small stateful service exclusively to address authentication concerns, leaving the rest of your server stateless? --tim ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3060350
