You are here: Re: _SESSION weirdness behind a NAT firewall/router: bug? « PHP Programming Language « IT news, forums, messages
Re: _SESSION weirdness behind a NAT firewall/router: bug?

Posted by axlq on 07/31/06 06:20

In article <_--dnRWshvgkYFHZnZ2dnUVZ_uydnZ2d@comcast.com>,
Jerry Stuckle <jstucklex@attglobal.net> 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.
>
>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_path 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_destroy(). 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/function.session-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

 

Navigation:

[Reply to this message]


Удаленная работа для программистов  •  Как заработать на Google AdSense  •  England, UK  •  статьи на английском  •  PHP MySQL CMS Apache Oscommerce  •  Online Business Knowledge Base  •  DVD MP3 AVI MP4 players codecs conversion help
Home  •  Search  •  Site Map  •  Set as Homepage  •  Add to Favourites

Copyright © 2005-2006 Powered by Custom PHP Programming

Сайт изготовлен в Студии Валентина Петручека
изготовление и поддержка веб-сайтов, разработка программного обеспечения, поисковая оптимизация