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

The short answer is "No". There is no such thing as 'too much paranoia'.

"If you make it 'idiot proof', the Universe will develop a better Idiot" -- The Darwinian Rule of Software Development.

Seriously, it is very hard to go over-board in checking what an unknown (and possibly malicious) User has sent you. Bear in mind that from time to time new attack vectors appear and encryption methods are compromised. Having your suspenders buttoned on tight as well as buckling your belt can be the difference between sleeping the night through and the O'Dark Hundred phone call ....

----
I Go Back to Sleep, Now.

OGB

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

Replies are listed 'Best First'.
Re^2: In a web app, is using ssl, encrypting request data, and validating request data after decryption overkill? by Fletch (Bishop) on Jul 02, 2007 at 16:02 UTC
Seconded. Users are dirty, untrustworthy creatures who should all be rounded up and shot (but I guess they'd have a hard time using your app; then again, that'd fix any load problems . . . hrmm, tough call :). Never trust anything provided by a user. If at all possible, don't even send information you're going to use to them to begin with. Send them a "token" (actually the word I'd use here normally would be "cookie", but considering the context that might be overloading the term a bit much; it might be very well keyed off of an HTTP cookie, or it could be something in the URL), then use your copy of the information keyed by that token instead (after verifying that they match up with that token via whatever authentication you're doing, of course). They see a display copy of the information, but you work from your version and validate / scrub / cleanse any changes you receive from the user before updating your version.	[reply]

Replies are listed 'Best First'.

Re^2: In a web app, is using ssl, encrypting request data, and validating request data after decryption overkill?
by Fletch (Bishop) on Jul 02, 2007 at 16:02 UTC

Seconded. Users are dirty, untrustworthy creatures who should all be rounded up and shot (but I guess they'd have a hard time using your app; then again, that'd fix any load problems . . . hrmm, tough call :).

Never trust anything provided by a user. If at all possible, don't even send information you're going to use to them to begin with. Send them a "token" (actually the word I'd use here normally would be "cookie", but considering the context that might be overloading the term a bit much; it might be very well keyed off of an HTTP cookie, or it could be something in the URL), then use your copy of the information keyed by that token instead (after verifying that they match up with that token via whatever authentication you're doing, of course). They see a display copy of the information, but you work from your version and validate / scrub / cleanse any changes you receive from the user before updating your version.

[reply]