www.webdeveloper.com
Page 1 of 2 12 LastLast
Results 1 to 15 of 24

Thread: Deferent Session Values for each instance? possible or not?

  1. #1
    Join Date
    Feb 2008
    Posts
    70

    Deferent Session Values for each instance? possible or not?

    Hello there guys, I was wondering if it is possible to have deferent session values for each window, for example having two tabs in firefox open and each one having deferent value for variable $_SESSON[color].

  2. #2
    Join Date
    Aug 2004
    Location
    Ankh-Morpork
    Posts
    19,145
    On the PHP side, no: it has no idea which tab it's dealing with on the client. I'm not aware of any way to do it on the browser side, either, but there are so many Firefox plug-ins out there that it's possible there's one that could accomplish this.

    If you just need to test two different concurrent users, I just open up a second, different browser, e.g. Google Chrome or IE.
    "Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be."
    ~ Terry Pratchett in Nation

    eBookworm.us

  3. #3
    Join Date
    Dec 2009
    Location
    Denmark
    Posts
    240
    Sure you can. You can set PHP to grap the session id from a querystring instead of a cookie. That should allow you to use a different session pr. tab/window.

  4. #4
    Join Date
    Aug 2004
    Location
    Ankh-Morpork
    Posts
    19,145
    Quote Originally Posted by dk_zero-cool View Post
    Sure you can. You can set PHP to grap the session id from a querystring instead of a cookie. That should allow you to use a different session pr. tab/window.
    Valid point, though I'm not generally in favor of transmitting the session ID in the query string for security and usability reasons (e.g. bookmarking a URL that contains a session ID); but if you just set it up, say, for testing purposes, it could be a useful solution.
    "Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be."
    ~ Terry Pratchett in Nation

    eBookworm.us

  5. #5
    Join Date
    Dec 2009
    Location
    Denmark
    Posts
    240
    Well, did'nt say that I would do it, just that you could
    But I would only use usability as arguments not to do it. Cookies is not more secure than querystrings, so as for security it does not realy matter. And if someone should bookmark a session id, it would not do anything other than that the user would use the same id for the new session, which you could program your way out of. So the real reason not to, would be that a session id looks ugly in the address field

  6. #6
    Join Date
    Aug 2004
    Location
    Ankh-Morpork
    Posts
    19,145
    Quote Originally Posted by dk_zero-cool View Post
    Well, did'nt say that I would do it, just that you could
    But I would only use usability as arguments not to do it. Cookies is not more secure than querystrings, so as for security it does not realy matter. And if someone should bookmark a session id, it would not do anything other than that the user would use the same id for the new session, which you could program your way out of. So the real reason not to, would be that a session id looks ugly in the address field
    The only real security advantage with the cookie (that I can think of at the moment) is stuff like someone posting a link somewhere saying, "Hey, this is a really cool site: http://example.com/?SESSID=123345."
    "Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be."
    ~ Terry Pratchett in Nation

    eBookworm.us

  7. #7
    Join Date
    Dec 2009
    Location
    Denmark
    Posts
    240
    This you can also program your way out of.
    Here is a small example of how to avoid such things.

    PHP Code:
    function my_session_start() {
        
    # If a session is is parsed in the URI, but the session id container cookie
        # is not set, we unset the session id GET index forcing PHP to 
        # start a new session with another id.
        
    if(empty($_COOKIE["my_session_ids"]) && isset($_GET["SESSID"])) {
            unset(
    $_GET["SESSID"]);
            
    $ids = array();

        }else {
            
    # If the cookie did exist, we check to see if the current
            # id is in this cookie.
            
    $ids unserialize($_COOKIE["my_session_ids"]);

            if(isset(
    $_GET["SESSID"]) && !in_array($_GET["SESSID"], $ids)) {
                unset(
    $_GET["SESSID"]);
            }
        }

        
    session_start();
        
        
    # Now we check to make sure that this session id is not an old expired one.
        # The above checks should take care of the most, this is just in case
        # the session id collection cookie was not deleted on browser shutdown
        # or that the browser has not been closed since the session expired.
        
    if(isset($_GET["SESSID"]) && !isset($_SESSION["validated"])) {
            
    session_regenerate_id();
            
    $_SESSION["validated"] = true;
        }

        
    # Store the id if it is not already in the id container.
        
    if(!in_array($_GET["SESSID"], $ids)) {
            
    $ids[] = $_GET["SESSID"];
            
    setcookie("my_session_ids"serialize($ids));
        }


  8. #8
    Join Date
    Mar 2010
    Posts
    672
    Quote Originally Posted by NogDog View Post
    The only real security advantage with the cookie (that I can think of at the moment) is stuff like someone posting a link somewhere saying, "Hey, this is a really cool site: http://example.com/?SESSID=123345."
    There are more problems than just that. Though the impact varies with your session time, it causes the same issues that make developers not use GET for things like credit card info. So not only is it more difficult to do session fixation (you can't easily trick a person into downloading a cookie editor, editing their cookie to a session id of the attackers choice and then using it...etc), but the session id does not get logged in things like url referrers, server logs...etc. Cookies offer a padding/buffer between the parts of the web (the url) that users deal with and the parts (get/post/session id's...etc) that developers deal with. Mixing the two increases the ease for an attacker to do his job.
    Last edited by Jarrod1937; 06-30-2010 at 06:12 PM. Reason: Fixed grammar issues... aka "I is smart"...

  9. #9
    Join Date
    Mar 2010
    Posts
    672
    Quote Originally Posted by dk_zero-cool View Post
    This you can also program your way out of.
    Here is a small example of how to avoid such things.
    If thats meant to protect against session fixation it looks like the attacker would simply need to get a valid session id and then send it to the victim to do the attack. Though it is a good check for general session handling, it is not secure.

  10. #10
    Join Date
    Dec 2009
    Location
    Denmark
    Posts
    240
    Quote Originally Posted by Jarrod1937 View Post
    If thats meant to protect against session fixation it looks like the attacker would simply need to get a valid session id and then send it to the victim to do the attack. Though it is a good check for general session handling, it is not secure.
    It is not meant for protection against session fixation. The example was meant as an example for solving the issues that @NogDog used as arguments for not using GET. Increased session security is another topic.
    Last edited by dk_zero-cool; 06-30-2010 at 06:21 PM.

  11. #11
    Join Date
    Nov 2008
    Posts
    2,477
    Quote Originally Posted by dk_zero-cool View Post
    It is not meant for protection against session fixation. The example was meant as an example for solving the issues that @NogDog used as arguments for not using GET. Increased session security is another topic.
    The issue NogDog highlighted is session fixation, ie trying to get a user to utilise a session initiated by the attacker.

    Quote Originally Posted by Jarrod1937 View Post
    If thats meant to protect against session fixation it looks like the attacker would simply need to get a valid session id and then send it to the victim to do the attack. Though it is a good check for general session handling, it is not secure.
    The whole point of session fixation is that the attacker has a valid session is which is sent to the victim. This section mitigates it somewhat:

    PHP Code:
    if(isset($_GET["SESSID"]) && !isset($_SESSION["validated"])) {
        
    session_regenerate_id();
        
    $_SESSION["validated"] = true;

    as it regenerates the session id and the attacker no longer knows the new id.

    The absolute best thing you can do to protect against session fixation though is simply to regenerate the id either on every single request, or at least on every change in authentication level such as logging in.
    Last edited by Mindzai; 07-01-2010 at 04:56 AM.
    The first rule of Tautology Club is the first rule of Tautology Club.

  12. #12
    Join Date
    Dec 2009
    Location
    Denmark
    Posts
    240
    Quote Originally Posted by Mindzai View Post
    The issue NogDog highlighted is session fixation, ie trying to get a user to utilise a session initiated by the attacker.
    The example I posted was meant to deal with the fallowing of @NogDog's problems.

    #4
    (e.g. bookmarking a URL that contains a session ID)
    #6
    The only real security advantage with the cookie (that I can think of at the moment) is stuff like someone posting a link somewhere saying, "Hey, this is a really cool site: http://example.com/?SESSID=123345."
    These where the arguments used for not using GET to transfer the session id. And since the example still uses a session cookie, only in my example to store several ID's, the problem with session fixation is not grater than using the normal approach.

    By the way, there is an error in my code
    It should be
    PHP Code:
        if(!in_array(session_id(), $ids)) {
            
    $ids[] = session_id(); 
    NOT
    PHP Code:
        if(!in_array($_GET["SESSID"], $ids)) {
            
    $ids[] = $_GET["SESSID"]; 
    at the bottom...
    Last edited by dk_zero-cool; 07-01-2010 at 08:06 AM.

  13. #13
    Join Date
    Nov 2008
    Posts
    2,477
    Quote Originally Posted by dk_zero-cool View Post
    The example I posted was meant to deal with the fallowing of @NogDog's problems...
    And like I said, #6 is an example of a session fixation attack, albeit a basic one.
    The first rule of Tautology Club is the first rule of Tautology Club.

  14. #14
    Join Date
    Mar 2010
    Posts
    672
    Quote Originally Posted by Mindzai View Post
    The whole point of session fixation is that the attacker has a valid session is which is sent to the victim. This section mitigates it somewhat:

    PHP Code:
    if(isset($_GET["SESSID"]) && !isset($_SESSION["validated"])) {
        
    session_regenerate_id();
        
    $_SESSION["validated"] = true;

    as it regenerates the session id and the attacker no longer knows the new id.
    It looks to me that it is simply checking if a value is assigned to $_SESSION["validated"], which would only happen if the session id is valid... But as i stated "it looks like the attacker would simply need to get a valid session id and then send it to the victim to do the attack". In other words, the attacker visits the site, gets the session id, extracts it from his cookie, and then places it within a url and sends it to the victim. Doing those steps the above code is no longer effective. So my original statement still stands. If you want protection from session fixation you should simply not accept session id's from the url, hence why a lot of the bigger sites out there do just that and require cookies.

  15. #15
    Join Date
    Nov 2008
    Posts
    2,477
    Quote Originally Posted by Jarrod1937 View Post
    ...the attacker visits the site, gets the session id, extracts it from his cookie, and then places it within a url and sends it to the victim. Doing those steps the above code is no longer effective...
    Not so. $_SESSION["validated"] will not be set in the attacker's session since they are using a cookie not $_GET. When the victim clicks the link, since $_SESSION["validated"] is not set, the session id is regenerated and the attacker no longer knows the victims new session id. Granted this technique is not watertight, hence my statement that it "mitigates it somewhat" and that regenerating the session id every request or priviledge level change is the best approach.
    Last edited by Mindzai; 07-01-2010 at 09:14 AM.
    The first rule of Tautology Club is the first rule of Tautology Club.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

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



Recent Articles