At the moment I'm coding a small web application in PHP. The way I'm doing the verification is by setting a session with the users unique code. When the user does a successful login, a session is set. PHP: $_SESSION['userOK'] = "user-unique-code"; All other pages see if the the session is set, and that it's not null like this: PHP: if ($_SESSION['userOK'] > '' ) { // do the stuff } As you can see, all is okay when the session "userOK" is set bigger than null (could be anything) Now this does not really look seccure to me.. That is if a session can be faked! So.. Is it possible to fake a session with some tools/trick? (no need to explain how) If it is possible, I will need to do some more coding (verify per page the session with the user-unique-code in the database) PS: I'm not a PHP person. I'm more into Coldfusion
Why don't you use PHP's built-in session functions? http://www.tizag.com/phpT/phpsessions.php http://www.sitepoint.com/article/users-php-sessions-mysql http://www.php.net/session
Hi falko, The "user-unique-code" is info that is needed on all the other "member" pages. Basically it's an ID for the uses. Thinking of this. Even if a user can fake a session, he will never guess the "user-unique-code" (it a MD5 generated code and stored in the DB) When using a bad / faked session, the "member" pages will not work as the faked "user-unique-code" is not known in the DB.. I guess I'm safe using it this way...
Here's a good way to create a good unique ID: PHP: $id = md5(uniqid(rand(), true)); (from http://www.php.net/manual/en/function.uniqid.php )
In my eyes it is not really importan, what the user unique code contains. Even though an attacker will fake the session, the question is how he gather's this. If it get's a valid session ID maybe via XSS or similar things the has the session no matter what the uniqe code inside the session file tells. Assuming I create a SessionID, and be able to insert code there (maybe via weakness inside the code or and that's even worse, I got access to the server and directly editing the session file), than I got other problems than just having the uniqueID beeing valid in the session or not. But if you feel unsafe with storing just anything in that session variable an check wether thies arrayfield is set or not, to decide wether a user is logged in, why don't you store the timestamp. It's not that random but with this you have the possibilty to easyly unset the whole session after a session-time limit (besides the one php gives you by default. But this is in my eyes not very helpfull esp. in shared hosting environments). Another thing would be to track from which "functions" the user came from to check if anybody tries to break your app's logic. E.g. how should sb. reach the function to store any data when he's never been to the page displaying the form to enter this data.
Hi Ben, This post was from 14th June 2007, and the project is finished. Till now the project has been running safe I think that user "batista" is a bot, and registered to post some spam later :/ (I could be wrong)
essions are significantly safer than, say, cookies. But it is still possible to steal a session and thus the hacker will have total access to whatever is in that session. Some ways to avoid this are IP Checking (which works pretty well, but is very low fi and thus not reliable on its own), and using a nonce. Typically with a nonce, you have a per-page "token" so that each page checks that the last page's nonce matches what it has stored. In either security check, there is a loss of usability. If you do IP checking and the user is behind a intranet firewall (or any other situation that causes this) which doesn't hold a steady IP for that user, they will have to re-authenticate every time they lose their IP. With a nonce, you get the always fun "Clicking back will cause this page to break" situation. But with a cookie, a hacker can steal the session simply by using fairly simple XSS techniques. If you store the user's session ID as a cookie, they are vulnerable to this as well. So even though the session is only penetrable to someone who can do a server-level hack (which requires much more sophisticated methods and usually some amount of privilege, if your server is secure), you are still going to need some extra level of verification upon each script request. You should not use cookies and AJAX together, as this makes it a tad easier to totally go to town if that cookie is stolen, as your ajax requests may not get the security checks on each request. For example, if the page uses a nonce, but the page is never reloaded, the script may only be checking for that match. And if the cookie is holding the authentication method, I can now go to town doing my evilness using the stolen cookie and the AJAX hole.
