_SESSION weirdness behind a NAT firewall/router: bug?

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • axlq

    _SESSION weirdness behind a NAT firewall/router: bug?

    Someone please tell me if I've discovered a PHP bug.

    I'm sitting in front of several computers on my home network, behind
    a NAT firewall/router. I am testing my web site on these different
    computers (running different browsers, logged in as different users,
    etc.). My web site keeps track of users logged in through the use
    of $_SESSION.

    Here's the bizarre thing: All computers are logged off, then I log
    into my web site with one computer -- and when I browse my site from
    another computer it behaves as if logged in! And if I log off with
    one computer, all other computers subsequently behave as if logged
    off! This happens also with different browsers (say IE and Opera)
    running on the same machine.

    This is especially serious because I have four classes of users:
    non-logged-in visitor, logged-in user, paying customer, and
    superuser. Logging in as superuser, for example, gives superuser
    privileges to ALL computers on my home network!

    AAAARRRGH!! I can't figure this out. It seems that $_SESSION is
    using *only* my IP address and no unique identifying information
    from the browsers on my network. Is this a php bug?

    Background:

    Here is basically what I'm doing. All scripts first contain a
    require_once() directive that includes a file which executes the
    following statements right up front:

    session_save_pa th("/home/mydomain/public_html/lists");
    session_name('l ogin_settings') ;
    session_start() ;

    (Naturally, the save path exists, and it contains session data
    files.) Then, each script calls a function isLoggedOn() to
    determine the type of user logged in, if any:

    function isLoggedOn()
    {
    if (isset($_SESSIO N['superuser']))
    return 'superuser';
    if (isset($_SESSIO N['customer']))
    return 'customer';
    if (isset($_SESSIO N['user']))
    return 'user';
    return NULL; // unregistered or not logged in
    }

    Upon receiving the return value from isLoggedOn(), the script
    behaves exactly the way it should depending on what type of user is
    logged in. The value of $_SESSION['user'], $_SESSION['customer'],
    and $_SESSION['superuser'] is the user's ID in the MySQL table for
    that user type; the value is set by a login.php script.

    I have three login.php scripts: for normal users, customers, and
    superuser. Each login.php script queries the appropriate database
    for user ID and password, and then sets some $_SESSION values.
    Here, for example, is what happens with $_SESSION when a normal user
    logs in. Note that it ensures that the customer and superuser types
    are unset upon this login:

    if ($sql->rows) {
    $userid = $sql->GetValue('id') ;
    if ($userid) {
    $_SESSION['user'] = $userid;
    if (isset($_SESSIO N['admin']))
    unset($_SESSION['customer']);
    if (isset($_SESSIO N['superuser']))
    unset($_SESSION['superuser']);
    header("Locatio n: http://www.example.com/userindex.php") ;
    } else header("Locatio n: http://www.example.com/login.php?error =1")
    } else header("Locatio n: http://www.example.com/login.php?error =1")

    Logging off shouldn't leave anything behind from prior users,
    deleting all $_SESSION data, killing the session cookie, and finally
    calling session_destroy (). So here's my logout.php script for all
    user types. It does seem to work correclty:

    $CookieInfo = session_get_coo kie_params();
    $_SESSION = array(); // unset all session values

    if ((empty($Cookie Info['domain'])) && (empty($CookieI nfo['secure'])))
    setcookie(sessi on_name(), '', time()-3600, $CookieInfo['path']);
    elseif (empty($CookieI nfo['secure']))
    setcookie(sessi on_name(), '', time()-3600, $CookieInfo['path'],
    $CookieInfo['domain']);
    else
    setcookie(sessi on_name(), '', time()-3600, $CookieInfo['path'],
    $CookieInfo['domain'], $CookieInfo['secure']);
    unset($_COOKIE[session_name()]);
    session_destroy ();

    I'm at my wit's end, almost ready to manage my own cookies and dump
    this PHP session handling stuff. I'd rather not though; I like
    having the one session cookie with sensitive data stored on the
    server. *Other* sites don't behave this way if I log into them
    simultaneously from different computers on my home network. What's
    wrong with MY site??

    -Alex
  • Rik

    #2
    Re: _SESSION weirdness behind a NAT firewall/router: bug?

    axlq wrote:
    So here's my logout.php script for all
    user types. It does seem to work correclty:
    I'm missing session_start() here.....
    $CookieInfo = session_get_coo kie_params();
    $_SESSION = array(); // unset all session values
    >
    if ((empty($Cookie Info['domain'])) &&
    (empty($CookieI nfo['secure']))) setcookie(sessi on_name(), '',
    time()-3600, $CookieInfo['path']); elseif
    (empty($CookieI nfo['secure'])) setcookie(sessi on_name(), '',
    time()-3600, $CookieInfo['path'], $CookieInfo['domain']);
    else
    setcookie(sessi on_name(), '', time()-3600, $CookieInfo['path'],
    $CookieInfo['domain'], $CookieInfo['secure']);
    unset($_COOKIE[session_name()]);
    session_destroy ();
    What if you just:

    session_save_pa th('/home/mydomain/public_html/lists');
    session_name('l ogin_settings') ;
    session_start() ;
    set_cookie(sess ion_name(),'',t ime()-3600,'/');//or your snippet offcourse
    $_SESSION = array();
    session_destroy ();

    Else, I'm very curious wether you cookies are actually deleted or not, and
    if not, what they hold.

    Grtz,
    --
    Rik Wasmus


    Comment

    • axlq

      #3
      Re: _SESSION weirdness behind a NAT firewall/router: bug?

      In article <48d5e$44cc3726 $8259c69c$24703 @news2.tudelft. nl>,
      Rik <luiheidsgoeroe @hotmail.comwro te:
      >axlq wrote:
      > So here's my logout.php script for all
      >user types. It does seem to work correclty:
      >
      >I'm missing session_start() here.....
      Not really... as I said at the beginning of my original post,
      *all* scripts - without exception - include a file that calls
      session_start() right at the beginning. I neglected to say that
      what I posted for logout.php was an excerpt, not the whole script.
      >What if you just:
      >
      >session_save_p ath('/home/mydomain/public_html/lists');
      >session_name(' login_settings' );
      >session_start( );
      >set_cookie(ses sion_name(),'', time()-3600,'/');//or your snippet offcourse
      >$_SESSION = array();
      >session_destro y();
      That's what it does already.
      >Else, I'm very curious wether you cookies are actually deleted or
      >not, and if not, what they hold.
      The cookie gets deleted. When I examine the cookie after logging
      off in Opera, it says "login_settings : deleted."

      The real problem is that the web hosting server seems to think that
      every computer on my home network shares the same session ID, and I
      don't know what to do about it. I haven't made the web site public
      yet. I certainly can't do so as long as $_SESSION poses such a huge
      security risk. There are much more than just home networks behind
      NAT firewall/routers. If multiple people in a large organization
      try to access my site, all kinds of conflicts will occur.

      -A

      Comment

      • Rik

        #4
        Re: _SESSION weirdness behind a NAT firewall/router: bug?

        axlq wrote:
        In article <48d5e$44cc3726 $8259c69c$24703 @news2.tudelft. nl>,
        Rik <luiheidsgoeroe @hotmail.comwro te:
        >axlq wrote:
        >> So here's my logout.php script for all
        >>user types. It does seem to work correclty:
        >>
        >I'm missing session_start() here.....
        >
        Not really... as I said at the beginning of my original post,
        *all* scripts - without exception - include a file that calls
        session_start() right at the beginning. I neglected to say that
        what I posted for logout.php was an excerpt, not the whole script.
        Sorry, missed that. As it is an excerpt, are you sure everything get's
        executed correctly? No notices when error_reporting (E_ALL)?
        >Else, I'm very curious wether you cookies are actually deleted or
        >not, and if not, what they hold.
        >
        The cookie gets deleted. When I examine the cookie after logging
        off in Opera, it says "login_settings : deleted."
        Hmmz, then I don't think the problem is there. What's the actual content of
        /home/mydomain/public_html/lists")? Are the sessions cleaned up?

        It could also have something to do with the actual logging in/checking,
        maybe post a portion of that code.

        Grtz,
        --
        Rik Wasmus


        Comment

        • Jerry Stuckle

          #5
          Re: _SESSION weirdness behind a NAT firewall/router: bug?

          axlq wrote:
          >
          The real problem is that the web hosting server seems to think that
          every computer on my home network shares the same session ID, and I
          don't know what to do about it. I haven't made the web site public
          yet. I certainly can't do so as long as $_SESSION poses such a huge
          security risk. There are much more than just home networks behind
          NAT firewall/routers. If multiple people in a large organization
          try to access my site, all kinds of conflicts will occur.
          >
          -A
          The web server doesn't keep track of the session like that. It sends a
          cookie to the browser with the session id, and the browser keeps track
          of the id.

          However, that also depends on your PHP.INI file. You should have

          session.use_coo kies = 1

          in your php.ini file.

          But I'm also not sure why you're using those other calls - such as
          session_save_pa th and session_name(). These should be set up in your
          php.ini file and you shouldn't need to override them.

          I'm also not sure why you're using set_cookie on the session name.


          --
          =============== ===
          Remove the "x" from my email address
          Jerry Stuckle
          JDS Computer Training Corp.
          jstucklex@attgl obal.net
          =============== ===

          Comment

          • axlq

            #6
            Re: _SESSION weirdness behind a NAT firewall/router: bug?

            In article <8oudnZWwZoMwVV HZnZ2dnUVZ_vSdn Z2d@comcast.com >,
            Jerry Stuckle <jstucklex@attg lobal.netwrote:
            >axlq wrote:
            >The real problem is that the web hosting server seems to think that
            >every computer on my home network shares the same session ID, and I
            >don't know what to do about it. I haven't made the web site public
            >yet. I certainly can't do so as long as $_SESSION poses such a huge
            >security risk. There are much more than just home networks behind
            >NAT firewall/routers. If multiple people in a large organization
            >try to access my site, all kinds of conflicts will occur.
            >
            >The web server doesn't keep track of the session like that. It sends a
            >cookie to the browser with the session id, and the browser keeps track
            >of the id.
            It sends a cookie to ONE browser. Once this cookie is set and the
            session established on the server, the cookie doesn't seem to get
            used any more.
            >However, that also depends on your PHP.INI file. You should have
            >session.use_co okies = 1
            >in your php.ini file.
            It's set that way already.
            >But I'm also not sure why you're using those other calls - such as
            >session_save_p ath and session_name(). These should be set up in your
            >php.ini file and you shouldn't need to override them.
            Two reasons:

            1. This is a shared server, I don't own php.ini, I didn't want to
            use the /tmp path already set in it, and I didn't like the default
            session name set in it.

            2. I can set my own php.ini, but I may have multiple web sites under
            the same account, so I preferred having each site's sessions have
            their own path -- therefore I set session_save_pa th and session_name
            in the script. It shouldn't make any difference as long as these
            settings are consistent in every invocation of my scripts.
            >I'm also not sure why you're using set_cookie on the session name.
            That's only to delete the session cookie when logging off. This was
            recommended in a php documentation page somewhere, so I pretty much
            just lifted the code from there. set_cookie isn't used anywhere else
            on my site except for the one logoff script.

            -A

            Comment

            • Miguel Cruz

              #7
              Re: _SESSION weirdness behind a NAT firewall/router: bug?

              axlq@spamcop.ne t (axlq) wrote:
              It sends a cookie to ONE browser. Once this cookie is set and the
              session established on the server, the cookie doesn't seem to get
              used any more.
              Have you tested this in other NAT environments? The behavior you
              describe is not how PHP normally works. I wonder if you are, perhaps
              unbeknownst to you, sitting behind a faulty http proxy.

              miguel
              --
              Photos from 40 countries on 5 continents: http://travel.u.nu
              Latest photos: Malaysia; Thailand; Singapore; Spain; Morocco
              Airports of the world: http://airport.u.nu

              Comment

              • axlq

                #8
                Re: _SESSION weirdness behind a NAT firewall/router: bug?

                In article <98e1e$44cc5d3f $8259c69c$647@n ews2.tudelft.nl >,
                Rik <luiheidsgoeroe @hotmail.comwro te:
                >are you sure everything get's executed correctly? No notices when
                >error_reportin g(E_ALL)?
                Good idea. No unusual notices came from error_reporting (E_ALL)
                - just some instances of testing values of nonexistent variables
                instead of using isset(), which doesn't affect the logical execution
                of the code and isn't related to the problem at hand.

                However, my testing to see if the error reporting gave any surprises
                *did* clarify that the problem arises from the 'sess_deleted' files
                that are left behind in my session path when logging off. It seems
                that the 'sess_deleted' file is actually being used as a session ID.

                Here is what seems to be wrong:

                A. After logging off, re-logging in doesn't re-set the session
                cookie. It persists as having the value 'deleted', which is how it
                gets set after using set_cookie() with a timestamp of time()-3600 to
                force the cookie to expire.

                B. The session file 'sess_deleted' - which appears from
                session_destroy () in the logoff script - is used as an actual
                session by browsers with a 'login_settings ' cookie set to 'deleted'.
                Any $_SESSION values introduced by one browser become part of the
                $_SESSION in all browsers.

                ==========

                Here's what I did. The first 5 steps are set-up steps.

                1. Choose two computers on my end, delete the cookies and clear the
                browser cache to start fresh. I also delete any session files in my
                session_path on the server, just to make sure it's fresh on that end.

                2. Computer A: I open up the Opera browser log in as a normal user.
                A session cookie appears in the cookie list, and a file called
                sess_99eae3b908 fa57142f08f31a7 eafc6c2 appeared in my session_path
                when the browser first accessed the site.

                3. Computer A (again): I open up the Firefox browser and log in
                as a customer. A session cookie is set properly in the browser,
                and a new file sess_4dd766f5f0 bb86404b1e6d872 e59035e appears in my
                session_path.

                4. Computer B: Open up the IE browser and log in as superuser.
                A new file sess_92d1cd69bb 176cb4167c08220 af30be7 appears.
                Everything fine so far. So far all three computers are working fine
                independently. No surprises from E_ALL error reporting.

                5. I log off computer B. The session file disappears and becomes
                'sess_deleted' instead. The two browsers on computer A still behave
                properly.

                OK. HERE'S WERE IT GETS WEIRD.

                6. I log off the Opera browser in computer A. The session file
                disappears. The browser displays the non-logged-in index page,as it
                should. However... there is still ONE 'sess_deleted' file, but with
                a new timestamp.

                7. I re-log in computer B as superuser. The superuser index page
                appears, but no new session file is created! Nothing strange
                appears in the E_ALL errors.

                8. From computer A, I re-load the non-logged-in index page in Opera.
                It loads up the superuser index page that B is seeing! Opera's
                cookie manager says of the session cookie, "login_settings : deleted"

                9. All this time, the Firefox browser on computer A has
                been operating normally in its own session. There has been
                no interference so far. Now I log off. The session file
                disappears. The browser loads the superuser index page instead of
                the non-logged-in index page! Firefox says of the session cookie:
                Name: login_settings
                Content: deleted

                10. Logging off from 'superuser' from any computer logs off all
                browsers. There is still one 'sess_deleted' file in my session_path
                with a timestamp updated to the logoff time.
                >It could also have something to do with the actual logging in/checking,
                >maybe post a portion of that code.
                It now seems to have everything to do with sess_deleted and session
                cookies set to 'deleted'. My logoff script follows the example shown
                in http://us2.php.net/manual/en/functio...on-destroy.php

                -A

                Comment

                • axlq

                  #9
                  Re: _SESSION weirdness behind a NAT firewall/router: bug?

                  In article <spam-A7BC28.00113331 072006@localhos t>,
                  Miguel Cruz <spam@admin.u.n uwrote:
                  >axlq@spamcop.n et (axlq) wrote:
                  >It sends a cookie to ONE browser. Once this cookie is set and the
                  >session established on the server, the cookie doesn't seem to get
                  >used any more.
                  >
                  >Have you tested this in other NAT environments? The behavior you
                  >describe is not how PHP normally works. I wonder if you are, perhaps
                  >unbeknownst to you, sitting behind a faulty http proxy.
                  No, as I posted elsewhere in this thread, I've identified the
                  problem as arising from multiple users sharing the same sess_deleted
                  session file after logging off and then re-logging in. I think now
                  it's unlikely to have anything to do with a NAT or http proxy.

                  I'm not sure what to do about this yet.

                  -Alex

                  Comment

                  • axlq

                    #10
                    Re: _SESSION weirdness behind a NAT firewall/router: bug?

                    Followup to my own post. I think I have solved the problem by
                    forcing regeneration of the session ID if the session ID has the
                    value 'deleted' -- like this:

                    session_start() ;
                    if (session_id() == 'deleted')
                    session_regener ate_id(true);

                    As far as my tests have shown, this prevents multiple browsers
                    from sharing the 'sess_deleted' session file on the server, if
                    those browsers have a deleted session cookie and are attempting to
                    re-log-in to my site.

                    This has nothing to do with being behind a NAT.

                    -Alex

                    Comment

                    • Jerry Stuckle

                      #11
                      Re: _SESSION weirdness behind a NAT firewall/router: bug?

                      axlq wrote:
                      In article <8oudnZWwZoMwVV HZnZ2dnUVZ_vSdn Z2d@comcast.com >,
                      Jerry Stuckle <jstucklex@attg lobal.netwrote:
                      >
                      >>axlq wrote:
                      >>
                      >>>The real problem is that the web hosting server seems to think that
                      >>>every computer on my home network shares the same session ID, and I
                      >>>don't know what to do about it. I haven't made the web site public
                      >>>yet. I certainly can't do so as long as $_SESSION poses such a huge
                      >>>security risk. There are much more than just home networks behind
                      >>>NAT firewall/routers. If multiple people in a large organization
                      >>>try to access my site, all kinds of conflicts will occur.
                      >>
                      >>The web server doesn't keep track of the session like that. It sends a
                      >>cookie to the browser with the session id, and the browser keeps track
                      >>of the id.
                      >
                      >
                      It sends a cookie to ONE browser. Once this cookie is set and the
                      session established on the server, the cookie doesn't seem to get
                      used any more.
                      >
                      It does on my systems. But all I uses is session_start() - not all the
                      rest of the stuff you use.
                      >
                      >>However, that also depends on your PHP.INI file. You should have
                      >>session.use_c ookies = 1
                      >>in your php.ini file.
                      >
                      >
                      It's set that way already.
                      >
                      Then it should use cookies automatically, You shouldn't need the rest
                      of it that stuff.
                      >
                      >>But I'm also not sure why you're using those other calls - such as
                      >>session_save_ path and session_name(). These should be set up in your
                      >>php.ini file and you shouldn't need to override them.
                      >
                      >
                      Two reasons:
                      >
                      1. This is a shared server, I don't own php.ini, I didn't want to
                      use the /tmp path already set in it, and I didn't like the default
                      session name set in it.
                      >
                      2. I can set my own php.ini, but I may have multiple web sites under
                      the same account, so I preferred having each site's sessions have
                      their own path -- therefore I set session_save_pa th and session_name
                      in the script. It shouldn't make any difference as long as these
                      settings are consistent in every invocation of my scripts.
                      >
                      So? It's a shared server. Sure, someone can access your session info
                      in /tmp - but only if they know the session id, which is VERY hard to
                      guess. And BTW - the could access the information in your own
                      directory, also. This is worse than no security - it is false security;
                      making you think your data is safe when you've actually gained nothing.

                      Just don't keep sensitive information like passwords in the session.
                      Or, if you must, encrypt it.
                      >
                      >>I'm also not sure why you're using set_cookie on the session name.
                      >
                      >
                      That's only to delete the session cookie when logging off. This was
                      recommended in a php documentation page somewhere, so I pretty much
                      just lifted the code from there. set_cookie isn't used anywhere else
                      on my site except for the one logoff script.
                      >
                      -A
                      Whatever. Works fine for me without it just by calling
                      session_destroy (). Then the cookie would have an invalid session ID,
                      which is just fine, also.

                      I don't think this is a PHP problem - it's in something you're doing.
                      Check phpinfo() to ensure your settings are as you expect and you're
                      using the php.ini you think you're using.

                      As for other browsers getting the session information - the only way
                      they would get this is if the server were sending the same information
                      and/or the pages are cached somewhere between the server and your
                      internal network.

                      --
                      =============== ===
                      Remove the "x" from my email address
                      Jerry Stuckle
                      JDS Computer Training Corp.
                      jstucklex@attgl obal.net
                      =============== ===

                      Comment

                      • Rik

                        #12
                        Re: _SESSION weirdness behind a NAT firewall/router: bug?

                        axlq wrote:
                        Followup to my own post. I think I have solved the problem by
                        forcing regeneration of the session ID if the session ID has the
                        value 'deleted' -- like this:
                        >
                        session_start() ;
                        if (session_id() == 'deleted')
                        session_regener ate_id(true);
                        >
                        As far as my tests have shown, this prevents multiple browsers
                        from sharing the 'sess_deleted' session file on the server, if
                        those browsers have a deleted session cookie and are attempting to
                        re-log-in to my site.
                        >
                        This has nothing to do with being behind a NAT.
                        Hmmm, when I

                        file1.php
                        <?
                        session_name('c heck_name');
                        session_start() ;
                        $_SESSION['var1'] = 'something';
                        ?>

                        file2.php

                        <?php
                        session_name('c heck_name');
                        session_start() ;
                        $_SESSION = array();
                        setcookie(sessi on_name(),'',ti me()-3600,'/');
                        session_destroy ();
                        ?>

                        There doesn't appear a 'sess_deleted' file. the sess_{random_st ring} file
                        just disappears. This is also true with a custom save path. Even adding a
                        session_start() directly after it, or on a redirect, will create a totally
                        new unique sess_file.

                        Allthough you have a workaround now, could you maybe post you total logout
                        script (for I still think there's the error) and not just the excerpt?
                        Otherwise, it will haunt me for days :-)

                        Grtz,
                        --
                        Rik Wasmus


                        Comment

                        • axlq

                          #13
                          Re: _SESSION weirdness behind a NAT firewall/router: bug?

                          In article <538cd$44cd10c7 $8259c69c$28897 @news2.tudelft. nl>,
                          Rik <luiheidsgoeroe @hotmail.comwro te:
                          >Hmmm, when I
                          >
                          >file1.php
                          ><?
                          >session_name(' check_name');
                          >session_start( );
                          >$_SESSION['var1'] = 'something';
                          >?>
                          >
                          >file2.php
                          >
                          ><?php
                          >session_name(' check_name');
                          >session_start( );
                          >$_SESSION = array();
                          >setcookie(sess ion_name(),'',t ime()-3600,'/');
                          >session_destro y();
                          >?>
                          >
                          >There doesn't appear a 'sess_deleted' file.
                          Do you access file1.php and file2.php from your browser, and keep your
                          browser open? Does your session cookie have the value 'deleted'?

                          According to the documentation at
                          http://www.php.net/manual/en/ref.session.php I'm not the only one
                          who sees a sess_deleted file when terminating a session. Maybe it's
                          an Apache thing for my ISP's particular configuration of the server.
                          >Allthough you have a workaround now, could you maybe post you total
                          >logout script (for I still think there's the error) and not just
                          >the excerpt? Otherwise, it will haunt me for days :-)
                          No problem, but it's several files. I think you might have a server
                          configuration that simply won't create a sess_deleted file.

                          logout.php:
                          =============== =============== =============== =============== ========
                          <?php
                          require_once('c lass_lib/class.setup.php ');

                          $CookieInfo = session_get_coo kie_params();
                          $_SESSION = array(); // unset all session values

                          if ((empty($Cookie Info['domain'])) && (empty($CookieI nfo['secure'])))
                          setcookie(sessi on_name(), '', time()-3600, $CookieInfo['path']);
                          elseif (empty($CookieI nfo['secure']))
                          setcookie(sessi on_name(), '', time()-3600, $CookieInfo['path'],
                          $CookieInfo['domain']);
                          else
                          setcookie(sessi on_name(), '', time()-3600, $CookieInfo['path'],
                          $CookieInfo['domain'], $CookieInfo['secure']);
                          unset($_COOKIE[session_name()]);
                          session_destroy ();
                          header("Locatio n: ".WWW_PATH."ind ex.php");
                          ?>
                          =============== =============== =============== =============== ========

                          That big 'if' statement above to delete the session cookie is
                          lifted directly from the example at the bottom of this page:


                          class_lib/class.setup.php contains the following at the beginning; the
                          rest is smarty template manager setup needed by all scripts except
                          logout.php, so that stuff isn't relevant.

                          class_lib/class.setup.php :
                          =============== =============== =============== =============== ========
                          <?php
                          // configs.php defines PROG_PATH, WWW_PATH, and a bunch of other stuff
                          require_once('/home/mydomain/public_html/configs.php');

                          session_save_pa th(PROG_PATH."/lists");
                          session_name('l ogin_settings') ;
                          session_start() ;
                          if (session_id() == 'deleted') session_regener ate_id(true);

                          /* smarty setup class and isLoggedOn() function goes here... */
                          ?>
                          =============== =============== =============== =============== ========

                          -Alex

                          Comment

                          • axlq

                            #14
                            Re: _SESSION weirdness behind a NAT firewall/router: bug?

                            In article <_--dnRWshvgkYFHZnZ 2dnUVZ_uydnZ2d@ comcast.com>,
                            Jerry Stuckle <jstucklex@attg lobal.netwrote:
                            >It sends a cookie to ONE browser. Once this cookie is set and the
                            >session established on the server, the cookie doesn't seem to get
                            >used any more.
                            >
                            >It does on my systems. But all I uses is session_start() - not all the
                            >rest of the stuff you use.
                            Sorry for my sloppiness - the cookie gets READ, but only WRITTEN
                            once upon the first access to the site, and then again when it's
                            deleted. If the value of the cookie matches the file name of a
                            session, it seems to be considered a valid session cookie. So if
                            the cookie has the value 'deleted' (which session cookies do until
                            you close the browser), and it matches the ID for sess_deleted on
                            the server, then sess_deleted gets used for the session, causing
                            user account collisions.
                            >>>But I'm also not sure why you're using those other calls - such as
                            >>>session_save _path and session_name(). These should be set up in your
                            >>>php.ini file and you shouldn't need to override them.
                            >>
                            >Two reasons:
                            >>
                            >1. This is a shared server, I don't own php.ini, I didn't want to
                            >use the /tmp path already set in it, and I didn't like the default
                            >session name set in it.
                            >>
                            >2. I can set my own php.ini, but I may have multiple web sites under
                            >the same account, so I preferred having each site's sessions have
                            >their own path -- therefore I set session_save_pa th and session_name
                            >in the script. It shouldn't make any difference as long as these
                            >settings are consistent in every invocation of my scripts.
                            >>
                            >
                            >So? It's a shared server. Sure, someone can access your session info
                            >in /tmp - but only if they know the session id, which is VERY hard to
                            >guess. And BTW - the could access the information in your own
                            >directory, also.
                            No, they can't. How? An .htaccess file prevents any kind of access
                            through the web server, and the session files have permissions only
                            for apache.
                            >Just don't keep sensitive information like passwords in the session.
                            I don't. Submitting a correct password during login is what
                            establishes the session data, which consists of just basic
                            information like the user ID and last page accessed.
                            >>>I'm also not sure why you're using set_cookie on the session name.
                            >>
                            >That's only to delete the session cookie when logging off. This was
                            >recommended in a php documentation page somewhere, so I pretty much
                            >just lifted the code from there. set_cookie isn't used anywhere else
                            >on my site except for the one logoff script.
                            >
                            >Whatever. Works fine for me without it just by calling
                            >session_destro y(). Then the cookie would have an invalid session ID,
                            >which is just fine, also.
                            I'm going by the php documentation at
                            http://www.php.net/manual/en/functio...on-destroy.php which
                            states: "In order to kill the session altogether, like to log the
                            user out, the session id must also be unset. If a cookie is used to
                            propagate the session id (default behavior), then THE SESSION COOKIE
                            MUST BE DELETED" (emphasis mine). The example that follows this
                            sentence shows how to kill the cookie. I use the expanded example
                            given at the very bottom of that page.
                            >I don't think this is a PHP problem - it's in something you're doing.
                            It's neither a problem or something I'm doing; it's a feature :)
                            >Check phpinfo() to ensure your settings are as you expect and you're
                            >using the php.ini you think you're using.
                            They are and I am.
                            >As for other browsers getting the session information - the only
                            >way they would get this is if the server were sending the same
                            >information and/or the pages are cached somewhere between the
                            >server and your internal network.
                            Well, one way the problem could happen is if two or more browsers
                            have the same session ID set in their cookie. And that's exactly
                            what happened here: other browsers have identical cookies, with
                            the value 'deleted' for the session ID, which corresponds to the
                            sess_deleted file on the server.

                            I believe this should even work for valid session IDs if you knew
                            a valid id and spoofed it from another browser. Log in with one
                            browser to get a session id, then manually edit the cookie in
                            another browser to be identical to that in the first browser. Now
                            both browsers will act as if they're logged into the same user
                            account.

                            -Alex

                            Comment

                            • axlq

                              #15
                              Re: _SESSION weirdness behind a NAT firewall/router: bug?

                              In article <eak7fk$vrg$3@b lue.rahul.net>, axlq <axlq@spamcop.n etwrote:
                              >>>>But I'm also not sure why you're using those other calls - such as
                              >>>>session_sav e_path and session_name().
                              I forgot to mention that using session_save_pa th() set to your own
                              directory is one way to avoid an early 20-minute session expiration
                              that one gets on some servers if using the default path. I was
                              experiencing that. So I went on a search for the reason, during
                              which I found the trick with session_save_pa th().

                              -Alex

                              Comment

                              Working...