Re^3: In a web app, is using ssl, encrypting request data, and validating request data after decryption overkill?

[blokhead]

So you want to prevent logged-in users from making requests for things they aren't allowed to see. You mentioned in the OP that the server already verifies the permissions of each request, so what more is there to protect against?

I mentioned in my reply that the (only) purpose of encryption is to achieve data secrecy. Your proposed application of encryption addresses a data validation problem, not a secrecy problem. Let me explain..

This prevents a user client from requesting a resource which was not originally offered by the server.

It sounds like you have a mental model of the server handing out tokens for certain kinds of requests. To make a request, the client just sends back one of its tokens, with the implicit security assumption that only the tokens that were generated by the server (and for that particular user) should be accepted. Again, this is not a secrecy problem but a validation problem.

Crypto tools like digital signatures and MACs (not encryption schemes) are designed for validating the source of data. But even those are overkill here. In this case, the person who validates is the same as the person generates the data. So you don't need crypto at all -- to validate something, just check whether it was something you previously generated. This is effectively what you do by only giving out "tokens" for things with ok permissions, and checking the same permissions on request "tokens" you get back.

Anyway, from what you have described, it sounds like you have the right paranoid mindset about servicing user-generated requests, so that's good! Better safe than sorry, but in this case I don't think that tacking on more encryption will really help much in the way you intend.

[leocharre]

(First and foremost, thank you for your discussion, you make sense- your comments have already helped me.)

Indeed what is being generated are tokens, the client chooses one and sends to server.
It seems I am using cryptography to identify that the tokens are generated by the server and for this authenticated session.

What other ways could I prove that the tokens *were* generated by the server?
To address your very dead-on point:

So you don't need crypto at all -- to validate something, just check whether it was something you previously generated.

In my case simply matching their session id, to the key in session and decrypting the token.. I am not exaclty *proving* it was generated by the server.

There *is* a way to come close to guarantee this?

( I don't see how else it could be possible?! Once the tokens, selections reach the client, there's nothing that I can do to control what they do with the data. All I can think of is that the server would keep a lookahead list of *possible* requests that would come next? That seems wild and whacky. )

[clinton]

You want to add a secret to your token, and then hash that. Send the client the token and the hash result.

When the user returns the token and the hash, you can recalculate the hash and check that it is valid.

This technique is described here: http://www.modperl.com/book/chapters/ch6.html#Cookie_Based_Access_Control

Clint