SitePoint Sponsor

User Tag List

Results 1 to 5 of 5
  1. #1
    SitePoint Enthusiast
    Join Date
    Sep 2009
    Posts
    73
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Question About Preventing Session Hijacking...

    I'm looking at some of the example code in Marc Wandschneider's "Core Web Application Developement with PHP and MySQL". If anyone has the book, it's pages 406 & 407. Anyway, the book is discussing how to limit damage from a compromised Session ID. In other words that attacker has a valid session id.

    Here's the first bit of code..

    PHP Code:
    session_start();

    if(!isset(
    $_SESSION['user_agent']))
    {
        
    $_SESSION['user_agent'] = $_SERVER['HTTP_USER_AGENT'];
    }
    else
    {
      if (
    $_SESSION['user_agent'] != $_SERVER['HTTP_USER_AGENT'])
         {
           
    //POSSIBLE SECURITY VIOLATION
         
    }

    So I fully understand the purpose of this code. It checks to make sure user is using the same browser each time. However, the book goes on to mention that an attacker can try guessing common values for the User-Agent header and then the system is compromised.

    It then suggests to help prevent this that we

    1. Seed the User-Agent with some additional string and make a hash with md5 "so that the attacker cannot try to md5 encode common agent values"
    2. Save this encoded string in the session data for the user
    3. Verify the hash every time we receive a request for the user.

    Onto the next code snippet

    PHP Code:
    define('UA_SEED''WEBAPP');

    session_start();

    if(!isset(
    $_SESSION['user_agent']))
    {
       
    $_SESSION['user_agent'] = 
       
    md5($_SERVER['HTTP_USER_AGENT'] . UA_SEED)
    }
    else
    {
      if(
    $_SESSION['user_agent'] !=
          
    md5($_SERVER['HTTP_USER_AGENT'] . UA_SEED))
       {
         
    //POSSIBLE SECURITY VIOLATION
       
    }

    I'm not seeing how the 2nd option is anymore secure than the first. Other than if the session data store was hacked, the session data might be usless. But as far as an attacker having to guess more than the User-Agent, I'm not seeing it. Maybe, I'm missing something?

  2. #2
    Follow Me On Twitter: @djg gold trophysilver trophybronze trophy Dan Grossman's Avatar
    Join Date
    Aug 2000
    Location
    Philadephia, PA
    Posts
    20,580
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    I don't see it either, I think the author is confused about where session data is stored. The attacker can't md5 anything to break this, the session data is all on the server. Only the session ID gets sent by the client, as a cookie.

  3. #3
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2008
    Posts
    5,757
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I suppose the salted hash would be beneficial if you want to plan that the attacker were able to use some kind of a bug in the app which causes a specific, or all session variables to be revealed. For example, litteral code goof which spills the value, or maybe them being able to get the app to read the session file contents.

  4. #4
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    I came across this article on session security yesterday, the second part might help you.

    http://www.phpbuilder.com/columns/ma...009172009.php3

    Off Topic:

    .php3 !!

  5. #5
    SitePoint Enthusiast
    Join Date
    Sep 2009
    Posts
    73
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for the replies. Just wanted to confirm I wasn't crazy.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •