Think about Loose Coupling | |
PerlMonks |
Re^3: In a web app, is using ssl, encrypting request data, and validating request data after decryption overkill?by blokhead (Monsignor) |
on Jul 02, 2007 at 23:16 UTC ( [id://624568]=note: print w/replies, xml ) | Need Help?? |
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. blokhead
In Section
Seekers of Perl Wisdom
|
|