Monday, August 06, 2007

Core Security Patterns - Wish List

I have pretty much read the Core Security Patterns book from Sun. Ok I skimmed a couple issues we aren't reading but I read some parts 3 or 4 times looking for the information I wanted.

The book is very good, but as I read it I realized I was doing a lot of things in it without having anyone tell me it is a "pattern" because they are just common sense.

The part I found missing was a basic comprehensive example of managing user logins and lost passwords and clearly identify when you send out someone's password that you are sending it to the right user (sending being as an encrypted email, or via allowing them to reset their password online). I understand to some degree this is in the book but from a comprehensive standpoint:

Ok so I store my user passwords as a one-way hash and that's fine and dandy.

But when a user wants to reset their password - what is the best and most secure way to do that? How do you ensure someone who has ripped off the hash cannot reset the password to whatever they want?

Also why do some places have additional questions you have to answer before you login or photos that have to match what you expect - otherwise you know you're at the wrong site. There could be security patterns for this as well for these type of double logins. Do they have login information coming from two different sources in that case?

And how do you know when someone is on dynamic IP addresses and moving from location to location that it is really the same person - you have to assume the user name and password are good enough?

And it talks about man-in-the middle attacks but as I read this it seems like all the discussion is one way - from the client to the server. The client ends up on a different web site.

What about from the server to the client? How can you really know that that the person you think is sending you the request is really that person? This is related to the above issue. What if someone submits a request and your server gets hacked and the person is redirected elsewhere from that point and all future requests are from another source that is then controlling that user? I would like some discussion on how and why that would or would not be possible.

Also your firewall should prevent IP spoofing, but does it in all cases? This is something I wonder because I have actually seen IPs missing in request logs, but perhaps this is some xss in interjection technique and my backup logs are getting all the data. I haven't had time to drill into this in more detail.

There is information about filtering requests but the book does not go into detail about how to filter out invalid characters for XSS and sql injection attacks. Why not put a chunk of sample code and say - use this for JavaScript, this for SQL, this for Java, this for Perl, etc. etc. etc. so people can drop this code into their apps for better security.

What about random request keys so requests cannot be duplicated as in the case of a hiddne form submitting from another tab open in the browser to your site? How can this be determined if the hidden frame does not pass the referrer with the request?

These are just some things I wondered about as I read this book.