Stopping session hijacking

Question

I have been contacted by a hacker saying there gonna take my site down using session hijacking he has said that my text boxes are session hijacking vulnerable.

Is there anyway to protect text boxes from session hijacking Im using this to escape and protect from sql injection.

Here is my form

      <form name="hide" action="hideboxupdate.php" method="post">
          <input type="radio" name="yes" value="1" />
  Yes<br />
  <input type="radio" name="no" value="0" />
  No
  <input name="submit" type="submit" value="Submit" />
        </form>

Then here is my hideboxupdate.php

<?php

$yes= mysql_real_escape_string($_POST['yes']);
$yes2 = strip_tags($yes);




$no= mysql_real_escape_string($_POST['no']);
$no2 = strip_tags($no);
?>
             <?php

             if (isset($yes2)) {





   $result3333 = mysql_query("UPDATE users SET hide_box='1' WHERE username = '".$_SESSION['username']."'")
or die(mysql_error());  

echo "Users now can not see your user box";
}

 if (isset($no2)) {


$result3333 = mysql_query("UPDATE users SET hide_box='0' WHERE username = '".$_SESSION['username']."'")
or die(mysql_error());  

echo "Users can now see your box on your profile";

}
?>

is there anyways to protect from session hijacking ???

Yes, read this related question: http://stackoverflow.com/questions/6483092/php-session-hijacking — joelparkerhenderson, Apr 03 '12 at 13:21
possible duplicate of [PHP Session Security](http://stackoverflow.com/q/328/), [What is the best way to prevent session hijacking?](http://stackoverflow.com/q/22880/90527) — outis, Apr 19 '12 at 09:22

score 5 · Accepted Answer · answered Apr 03 '12 at 13:19

5

make an md5 of the session, browser data and ip and put in in the database, on every page load check if its still the same, if not destroy the session.

answered Apr 03 '12 at 13:19

MakuraYami

3,398
3
16
19

1

I surgest making a new table for sessions, bind it on user id or something, add a update timestamp and delete old sessions (this is also a good way to be able to prevent double-logins) – MakuraYami Apr 03 '12 at 13:49

score 3 · Answer 2 · answered Apr 03 '12 at 13:24

When you send the page with the form, include a hidden input with a random string that you also write to user's record in the database, something like this:

 <input type="hidden" name="csrf" value="0432985732409857243"/>

When the user submits the form, you verify that the form's hidden data csrf matches the value you stored in the database. If the csrf matches, that means the update is good and you also delete the csrf; if the csrf fails to match, then you don't do the update.

This protects the user because only he will be able to submit that form, and only once.

Yes, firebug will show the value to a user for his own page load -- but his value will be different from everyone else's value. — joelparkerhenderson, Apr 03 '12 at 13:42

score 2 · Answer 3 · answered Apr 03 '12 at 13:26

This does not prevent your code from attacks. People can post arbitrary data to your form just by creating a form on their localhost and posting to your server with the same variable name that you use.

This is just one case. Use white-listing approach. On the server side, create an array which contains all possible values for each variable in your form that you expect to be correct inputs (Obviously not possible for <input>,<textarea>..).

Also, since the user is talking about session fixation...destroy session after each logout....use session_regenarate_id after login (with md5 + salt encryption). Don't propagate session_id in url's.

A few pointers: (Written by Chris Shiflett...a Renowed Web Security Expert)

http://shiflett.org/articles/session-hijacking

http://shiflett.org/articles/session-fixation

http://shiflett.org/articles/foiling-cross-site-attacks

http://shiflett.org/articles/the-truth-about-sessions

http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string

Hope it helps...

davej · Answer 4 · 2014-02-14T19:18:00.120

Consider that the server and client go through a login phase that is often SSL, or that the server can have other customer data available such that client and server can form a unique shared salt value (for example the user password). Even in a non-SSL login only a salted hash of the password needs to be transmitted for the login -- not the password itself. The server can then begin transmitting counts with its responses and the client can respond with the hash of (count+private salt) on the next page request. The potential session hijacker does not have any way to obtain this private salt and thus cannot generate the next hash in the sequence.

score 0 · Answer 5 · answered Apr 03 '12 at 13:22

0

You should consider protecting request that issue "write" to your system by installing captcha protection.

I use Google reCaptcha and it's quite good...

Also, make sure you're reseting your PHPSESSID after authenticating to system (e.g. login form): session-regenerate-id

answered Apr 03 '12 at 13:22

Jovan Perovic

19,846
5
44
85

i use captcha and could you explain about the "make sure you're reseting your PHPSESSID after authenticating to system (e.g. login form): session-regenerate-id" – user1152332 Apr 03 '12 at 13:23
The idea behind resetting is that you make session change mandatory, of course after successful login. As you know, session files are not deleted automatically after session invalidation and could be used by hackers to gain privileged access to your system. This way you specifically request that **current id** should be reset with **new one** - I believe that old session will be deleted automatically. – Jovan Perovic Apr 03 '12 at 13:54

Stopping session hijacking

5 Answers5

Linked