Home > Archive > PHP Programming > February 2007 > Sessions
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
| I have had this session issue for months now and I just can't crack
it. I have the following 2 scripts...
aoltest.php
*************
<?php
session_start();
$_SESSION[s_check1] = "4";
?>
<a href="aoltest3.php">click me</a>
aoltest3.php
**************
<?php
session_start();
?>
<body>
The session is <?php echo $_SESSION[s_check1];?><br>
</body>
As you can see, what is supposed to happen is you open aoltest.php and
click the link and in aoltest3.php the session variable is visable.
Yes, this works fine, except on users on AOL. Not just an AOL browser
but the AOL ISP.
I am using PHP version 5.0.4 and from my phpinfo below are the
settings of the sessions section..
session
Session Support enabled
Registered save handlers files user
Registered serializer handlers php php_binary wddx
Directive Local Value Master Value
session.auto_start Off Off
session.bug_compat_42 Off Off
session.bug_compat_warn On On
session.cache_expire 180 180
session.cache_limiter nocache nocache
session.cookie_domain no value no value
session.cookie_lifetime 0 0
session.cookie_path / /
session.cookie_secure Off Off
session.entropy_file no value no value
session.entropy_length 0 0
session.gc_divisor 1000 1000
session.gc_maxlifetime 1440 1440
session.gc_probability 1 1
session.hash_bits_per_character 5 5
session.hash_function 0 0
session.name PHPSESSID PHPSESSID
session.referer_check no value no value
session.save_handler files files
session.save_path /tmp /tmp
session.serialize_handler php php
session.use_cookies On On
session.use_only_cookies Off Off
session.use_trans_sid 0 0
I've tried changing the session.use_trans_sid and the
session.use_cookies using int_set() but to no luck. I can't changed
the php.ini as I'm on a shared server.
I can't beleive I am the only person with this issue. Has anyone seen
this problem before and has a solution?
Many Thanks
Mike
| |
| Curtis 2007-02-22, 4:01 am |
| Mike wrote:
> I have had this session issue for months now and I just can't crack
> it. I have the following 2 scripts...
>
> aoltest.php
> *************
> <?php
> session_start();
> $_SESSION[s_check1] = "4";
> ?>
> <a href="aoltest3.php">click me</a>
>
> aoltest3.php
> **************
>
> <?php
> session_start();
> ?>
> <body>
> The session is <?php echo $_SESSION[s_check1];?><br>
> </body>
>
> As you can see, what is supposed to happen is you open aoltest.php and
> click the link and in aoltest3.php the session variable is visable.
>
> Yes, this works fine, except on users on AOL. Not just an AOL browser
> but the AOL ISP.
>
> I am using PHP version 5.0.4 and from my phpinfo below are the
> settings of the sessions section..
>
> session
> Session Support enabled
> Registered save handlers files user
> Registered serializer handlers php php_binary wddx
>
> Directive Local Value Master Value
> session.auto_start Off Off
> session.bug_compat_42 Off Off
> session.bug_compat_warn On On
> session.cache_expire 180 180
> session.cache_limiter nocache nocache
> session.cookie_domain no value no value
> session.cookie_lifetime 0 0
> session.cookie_path / /
> session.cookie_secure Off Off
> session.entropy_file no value no value
> session.entropy_length 0 0
> session.gc_divisor 1000 1000
> session.gc_maxlifetime 1440 1440
> session.gc_probability 1 1
> session.hash_bits_per_character 5 5
> session.hash_function 0 0
> session.name PHPSESSID PHPSESSID
> session.referer_check no value no value
> session.save_handler files files
> session.save_path /tmp /tmp
> session.serialize_handler php php
> session.use_cookies On On
> session.use_only_cookies Off Off
> session.use_trans_sid 0 0
>
> I've tried changing the session.use_trans_sid and the
> session.use_cookies using int_set() but to no luck. I can't changed
> the php.ini as I'm on a shared server.
>
> I can't beleive I am the only person with this issue. Has anyone seen
> this problem before and has a solution?
>
> Many Thanks
>
> Mike
>
If the problem is not being able to set cookies, then you can pass the
SID using the query string, but note that it is less secure than using
cookies.
--
Curtis, http://dyersweb.com
| |
|
| On 22 Feb, 09:56, Curtis <zer0d...@verizon.net> wrote:
> Mike wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
> If the problem is not being able to set cookies, then you can pass the
> SID using the query string, but note that it is less secure than using
> cookies.
>
> --
> Curtis,http://dyersweb.com- Hide quoted text -
>
> - Show quoted text -
I've tried adding the SID in the url as well. In the above test with
one of the php.ini settings changed, if you hovered over the link you
could see the ID in the url but the session data still didn't pass to
the next page.
Anyway, why should my website be made less secure just to keep AOL
users happy?
Thanks
Mike
| |
| Erwin Moller 2007-02-22, 7:59 am |
| Mike wrote:
> On 22 Feb, 09:56, Curtis <zer0d...@verizon.net> wrote:
>
> I've tried adding the SID in the url as well. In the above test with
> one of the php.ini settings changed, if you hovered over the link you
> could see the ID in the url but the session data still didn't pass to
> the next page.
>
> Anyway, why should my website be made less secure just to keep AOL
> users happy?
Hi Mike and Curtis,
I say it is a myth that passing PHPSESSID by URL is less secure than passing
it by cookie.
Anybody who can eavesdrop on the traffic between the client and server can
see the PHPSESSID, in a cookie, or in the URL.
The content of the cookie is just plain there for anybody to read: in plain
text.
The only thing I can think of making URL-passed PHPSESSID less secure would
be (both with a but..):
1) Somebody behind you, looking at the URL, and make a note of it.
But that same person might as well just note your username password, so I
think this is a farfetched argument.
2) Somebody who can see all URLs served by the server.
a) Serverside
But you need access to apache logfiles (or IIS, ow whatever). In general
people who can read these files are admins on the server (or also, owner of
the logfiles if you configure your webserver in such a way every domain has
it own logfile, a common practice.)
b) On your network (proxyserver, gateway, whatever).
Here also: Only people with access to such logs can see the URL (and the
PHPSESSID)
I also want to add that people described in 2a and 2b (admins) can also get
the content of the cookie passing through their networks if they want.
Bottomline: URL and cookie are both equally (in)secure.
If you want safe communication, use SSL (https).
Regards,
Erwin Moller
>
> Thanks
>
> Mike
| |
| Erwin Moller 2007-02-22, 8:00 am |
| Mike wrote:
> I have had this session issue for months now and I just can't crack
> it. I have the following 2 scripts...
>
> aoltest.php
> *************
> <?php
> session_start();
> $_SESSION[s_check1] = "4";
> ?>
> <a href="aoltest3.php">click me</a>
>
> aoltest3.php
> **************
>
> <?php
> session_start();
> ?>
> <body>
> The session is <?php echo $_SESSION[s_check1];?><br>
> </body>
>
> As you can see, what is supposed to happen is you open aoltest.php and
> click the link and in aoltest3.php the session variable is visable.
>
> Yes, this works fine, except on users on AOL. Not just an AOL browser
> but the AOL ISP.
>
> I am using PHP version 5.0.4 and from my phpinfo below are the
> settings of the sessions section..
>
> session
> Session Support enabled
> Registered save handlers files user
> Registered serializer handlers php php_binary wddx
>
> Directive Local Value Master Value
> session.auto_start Off Off
> session.bug_compat_42 Off Off
> session.bug_compat_warn On On
> session.cache_expire 180 180
> session.cache_limiter nocache nocache
> session.cookie_domain no value no value
> session.cookie_lifetime 0 0
> session.cookie_path / /
> session.cookie_secure Off Off
> session.entropy_file no value no value
> session.entropy_length 0 0
> session.gc_divisor 1000 1000
> session.gc_maxlifetime 1440 1440
> session.gc_probability 1 1
> session.hash_bits_per_character 5 5
> session.hash_function 0 0
> session.name PHPSESSID PHPSESSID
> session.referer_check no value no value
> session.save_handler files files
> session.save_path /tmp /tmp
> session.serialize_handler php php
> session.use_cookies On On
> session.use_only_cookies Off Off
> session.use_trans_sid 0 0
>
> I've tried changing the session.use_trans_sid and the
> session.use_cookies using int_set() but to no luck. I can't changed
> the php.ini as I'm on a shared server.
>
> I can't beleive I am the only person with this issue. Has anyone seen
> this problem before and has a solution?
Hi,
I have seen this kind of postings before (regarding AOL).
The only thing that might be relevant is that AOL users can (and often do)
switch IP address with every request.
But since you do not check on IP yourself, and PHP doesn't care, I am not
very sure that causes the problem.
Any chance you didn't post the real code (but just samplecode), and DO
ip-checks in your real program?
Regards,
Erwin Moller
>
> Many Thanks
>
> Mike
| |
|
| On 22 Feb, 13:10, Erwin Moller
< since_humans_read_this_I_am_spammed_too_
m...@spamyourself.com> wrote:
> Mike wrote:
>
>
>
>
>
>
>
>
>
>
>
> Hi,
>
> I have seen this kind of postings before (regarding AOL).
> The only thing that might be relevant is that AOL users can (and often do)
> switch IP address with every request.
> But since you do not check on IP yourself, and PHP doesn't care, I am not
> very sure that causes the problem.
> Any chance you didn't post the real code (but just samplecode), and DO
> ip-checks in your real program?
>
> Regards,
> Erwin Moller
>
>
>
>
>
>
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
The 2 scripts in my original post are excacly as they are 100%.
I have done another test since but on another server, this one running
PHP version 4.4.3 and the session passed to the page OK.
So, sessions arn't passing when using PHP version 5.0.4 but they do
work with 4.4.3. Anyone know the changes/differences between these 2
versions?
Thanks
Mike
| |
|
| Erwin Moller wrote:
> I say it is a myth that passing PHPSESSID by URL is less secure than passing
> it by cookie.
> Anybody who can eavesdrop on the traffic between the client and server can
> see the PHPSESSID, in a cookie, or in the URL.
> The content of the cookie is just plain there for anybody to read: in plain
> text.
Simple explanation, try to perform session fixation by sending an URL
over an email client or IM with trans_sid turned off.
--
Cz.
| |
| Curtis 2007-02-22, 7:00 pm |
| Erwin Moller wrote:
> Mike wrote:
>
>
> Hi Mike and Curtis,
>
> I say it is a myth that passing PHPSESSID by URL is less secure than passing
> it by cookie.
You have a good point here. Passing the SID via query string just
makes it more convenient for certain script kiddies. But what I was
thinking about was that it's easier for users to unwittingly
authenticate other visitors. A scenario might be something like this:
Let's say they just copy and paste the URL and give it to a friend
(let's say the person giving the link is a forum admin), if her/his
friend weren't actually very friendly, s/he'd be able to do damage.
Also note that the friend wouldn't necessarily need any technical
knowledge.
Cookies aren't necessarily more secure, but they help prevent *some*
unnecessary breaches.
But, as you pointed out toward the end of your post, SSL is the surest
way to secure client-server communication.
> Anybody who can eavesdrop on the traffic between the client and server can
> see the PHPSESSID, in a cookie, or in the URL.
> The content of the cookie is just plain there for anybody to read: in plain
> text.
>
> The only thing I can think of making URL-passed PHPSESSID less secure would
> be (both with a but..):
> 1) Somebody behind you, looking at the URL, and make a note of it.
> But that same person might as well just note your username password, so I
> think this is a farfetched argument.
Password input is masked, so even if someone across were directly
viewing your monitor, they could determine the user name and length of
the password (not even that, if you are logging on using certain
terminals), but that's it. If they're watching your hands as you type,
I guess that might give them some clues, but it'd be hard to observe
closely enough without being noticed.
> <snip>
--
Curtis, http://dyersweb.com
| |
| Jerry Stuckle 2007-02-22, 10:00 pm |
| Curtis wrote:
> Erwin Moller wrote:
>
> You have a good point here. Passing the SID via query string just makes
> it more convenient for certain script kiddies. But what I was thinking
> about was that it's easier for users to unwittingly authenticate other
> visitors. A scenario might be something like this: Let's say they just
> copy and paste the URL and give it to a friend (let's say the person
> giving the link is a forum admin), if her/his friend weren't actually
> very friendly, s/he'd be able to do damage. Also note that the friend
> wouldn't necessarily need any technical knowledge.
>
> Cookies aren't necessarily more secure, but they help prevent *some*
> unnecessary breaches.
>
> But, as you pointed out toward the end of your post, SSL is the surest
> way to secure client-server communication.
>
>
> Password input is masked, so even if someone across were directly
> viewing your monitor, they could determine the user name and length of
> the password (not even that, if you are logging on using certain
> terminals), but that's it. If they're watching your hands as you type, I
> guess that might give them some clues, but it'd be hard to observe
> closely enough without being noticed.
>
>
> --
> Curtis, http://dyersweb.com
Curtis.
The password input is masking is very minimal - just base64 encoded.
Anyone who wants it can easily get it from the packets and freely
available software.
Again - if security is important, use SSL.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
| |
| Curtis 2007-02-22, 10:00 pm |
| Jerry Stuckle wrote:
> Curtis wrote:
>
> Curtis.
>
> The password input is masking is very minimal - just base64 encoded.
> Anyone who wants it can easily get it from the packets and freely
> available software.
>
> Again - if security is important, use SSL.
>
I was talking about someone trying to view your monitor while you are
entering a password. I know it can be sniffed out easily by sniffing
packets, but I wasn't addressing that issue.
Curtis, http://dyersweb.com
| |
|
| On 23 Feb, 01:56, Curtis <zer0d...@verizon.net> wrote:
> Jerry Stuckle wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> I was talking about someone trying to view your monitor while you are
> entering a password. I know it can be sniffed out easily by sniffing
> packets, but I wasn't addressing that issue.
>
> Curtis,http://dyersweb.com- Hide quoted text -
>
> - Show quoted text -
umm, I think we are drifting from my original post!!
Mike
|
|
|
|
|