I need to learn how to properly Protect all Cookies and Sessions from any type of hack attempt. If you can show me examples, will be much help!
1. okay first of all if your talking about security.. then forget about cookies.. session will be the key in security.. just a simple session array will do. 2. upon creating of session array make sure form variables are safe from injections (mysql_real_escape_string, etc...) 3. use one session variable as possible make it an array
Funny you say this since a cookie set without a timelimit is treated as a session cookie.. and yes sessions are stored as cookies in the browser.. Also for maximum security store as little information as possible in the session/cookie.. better that you give the user a "key" and store all information in a database or a cache file..
Indeed, store as little information as possible. And I already store all information in a database. But how would I go about assigning a key, to see if they are logged in or not without storing there username into a session that verifies them through out the site? and be secure from session/cookie thefts!
that i didnt know.. for sure huh? hmm... when i create sessions here in my local its actually creating under localhost's directory, and for that i believed that i will create on the server side.. thanks for that info.. how about you didnt configure session timelimit?
I set the expiration date in database.. so the server controls if it´s expired.. not the browser.. after Xmin the key i set i useless.. For even more security i´ve got a few other tricks.. 1, Change Key every connections the user does.. 2, Connect the key to an IP.. So even if you manage to steal the cookie you need to be on same IP and connect before the other person.
I also use those tricks, and massively link hashes and keys to IPs. A simple md5() with a rather complex salt will do. Just remember NEVER to md5() the md5(). I mean, do NOT do this: $securityhash=md5(md5($ip)); PHP: Since, provided you have a good salt, it will only reduce your security level (you're md5'ing a 32-char string instead of your secure & complex salt)
Sanitize all inputs. Everywhere. Even places you think aren't necessary. Store as little as possible clientside - if possible just hand out completely hashed keys, don't let the client get a cookie like 'userid=199241' or 'username=hello'. Do as much as possible server side - do not trust any part of the client at all. Hash IP, useragent, etc., all into the cookie if possible and drop session if ANY changes. The client is extremely hostile territory and is not to be trusted. Use salted SHA512 instead of md5. Use time-based XSRF tokens on each form that change every single reload (forums, login page, etc) If a client sends a bad key, log it. Have session cookies change every single page - if cookies are stolen by a third party, and the legit user browses another page, the old cookies are useless.
I use the same trick, but sometimes it is not best way to do. I mean the situation when ISP works like proxy. Some ISP can use several gateways to send traffic from visitor to server. It means that your visitor can log in using one IP-address (for example: 100.100.100.93), but next request will be sent from another IP (for example: 100.100.100.98) - in this case session will be lost.
Wouldn't checking the browser, ip etc on every page load slow the server down? I mean I have over 500 users online at once on my gaming site, right now they each have a key stored in the database which is md5(time+email+password). It never changes. Session stealing is pretty easy, but I've managed to secure my site against XSS. What do you think?
I've personally, have stored a key based off the session key which is encrypted into md5 and 512 and 256 an, will log both users out if the key is duplicated. Meaing no two users can have the same key. Not only this the key changes on every load. Making it almost impossible to hack. Using Ip is bad, as with php more then one person can actually have the same ip because of the router
It's sent every pageload, why would it be slower than a single db query? It's not just XSS btw - you can trick a user into typing a javascript: link and it would expose your cookies. Don't forget human retardism in addition to technical means. My webapps all have multiple keys (3 cookies) and change per pageload and there isn't much of an impact serverside.
I think it's just the session ID that's stored in a Cookie not the session information (normally), the actual session data is stored on the server as far as I know, this is why some auth systems and stuff can work with cookies disabled if there is a SID in the URL.
You are correct. The key is to validate session information as people move throughout your site, so my suggestion would be create a sess_check function that is called at the top of your pages to validate the info
Indeed, so as long as you dont store sensitive information in Cookies like passwords with no encryption your being fairly secure, also a good idea to check cookies havnt been stolen by checking the IP address in the cookie against the request if you can.