A generic rule to apply (the very basic attack prevention) is "filter input, escape output" just be paranoid about everything that is inputted into your system, start now if you dont so you dont have to learn the hard way :(
There is also another quite common session security issue with php, if your site is its on a shared host ie its not on its own dedicated server.
Very awesome article. I've read it completely and I must say, bravo.
My system is protected against querystring attacks. Every command MySQL uses, every designated die or exit function is blocked an I left nothing to coincidence there.
Refering back to the mysql_real_escape_string and the sprintf command. I still don't quite understand those. What's up with them. Are they handy to use, easy to filter out and do they provide a safe security and a easy handle?
Next to that, my cookies are stored ... well, of course on a users PC, but stored quite safely.
I used part of a method mr. buddha 'invented'. So to speak anyways. I retrieve the ID from the user, the username, the sha1 (4x) md5 (4x) password, the IP, the browser (incl language) and the time. Next, I am pushing it all into a once again formatted sha1 (4x) md5 (4x) string, which I call the cookies validationkey. For short, unforgeable as I know it. Since you cannot copy the login SECOND, IP, Language, Browser, username and 8 times encrypted password. Next, I push it, when succesfuly logged in, into the users database, where it's stored as user_validationkey. That is the key which will be refreshed every time. The NEXT thing I do, is of course update the userrecords and give the cookie an ID of it's own. It's almost logical that the $_SESSION[ID] and user_id still stored the user's ID, but sessions don't last as long as 30day cookies, or more.
Well, I am quite amazed by the topic but as you can see and if I am correct, my system is at least a little bit foolproof. Tho I bet some of your handy people could still get in.