Because you can never trust any data coming from "the client". SSL enables that the data between that computer and the server cannot be intercepted and seen by the inbetween points.Great.
But once logged in, it means that the person in there has used a valid username and password combo (and passed a captcha test ). It means that a human being can act through the rights of user entity x.
Example:
User entity x has rights to physical rights on server to file x/y...
What if the client data received is a request for file f/y ?
Let's quickly go over how the server offers the client what files they can act upon...
we will be offering files x/y x/x ..
- A human logs in as user x, we look up that they can meddle with files x/y and x/x.
- we encrypt what those choices are. make the 'page', send it to client
- They select x/y, server receives selection request
- server decrypts say.. 2387q23895yqguhaejghaerhg to x/y and we verify this really is a valid file request.
- we lookup that user x really has this right over file x/y
- now we check the request for stupidity (rename, move, download, whatever) and we are go.
What if you're a malicious valid user? If you sent the server a request for file y/xx, then we would negate you based on the fact that you don't have rights over file y/xx. But with encryption of the files requested, you can't even ask for file y/xx, because you don't know how to encode the request for file y/xx It is likely that my code will have holes somewhere. But encryption is encryption.
I am freaking paranoid. The data being secured and used is sensitive in nature. I know it's not a valid user sipping tea and petting her kitty while she looks at her files. I know it's really Satan 666. Don't you know that? Obviously you didn't. So.. Satan (666) just logged in as a valid user. Do you want the selections encrypted? I do.
|