Sessions

**Curtis** · Feb 22 '07, 10:05 AM

Re: Sessions

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];?> 
</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_st art Off Off
session.bug_com pat_42 Off Off
session.bug_com pat_warn On On
session.cache_e xpire 180 180
session.cache_l imiter 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_divi sor 1000 1000
session.gc_maxl ifetime 1440 1440
session.gc_prob ability 1 1
session.hash_bi ts_per_characte r 5 5
session.hash_fu nction 0 0
session.name PHPSESSID PHPSESSID
session.referer _check no value no value
session.save_ha ndler files files
session.save_pa th /tmp /tmp
session.seriali ze_handler php php
session.use_coo kies On On
session.use_onl y_cookies Off Off
session.use_tra ns_sid 0 0
>
I've tried changing the session.use_tra ns_sid and the
session.use_coo kies 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

**Mike** · Feb 22 '07, 12:35 PM

Re: Sessions

On 22 Feb, 09:56, Curtis <zer0d...@veriz on.netwrote:

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];?> 
</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_st art Off Off
session.bug_com pat_42 Off Off
session.bug_com pat_warn On On
session.cache_e xpire 180 180
session.cache_l imiter 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_divi sor 1000 1000
session.gc_maxl ifetime 1440 1440
session.gc_prob ability 1 1
session.hash_bi ts_per_characte r 5 5
session.hash_fu nction 0 0
session.name PHPSESSID PHPSESSID
session.referer _check no value no value
session.save_ha ndler files files
session.save_pa th /tmp /tmp
session.seriali ze_handler php php
session.use_coo kies On On
session.use_onl y_cookies Off Off
session.use_tra ns_sid 0 0

>

I've tried changing the session.use_tra ns_sid and the
session.use_coo kies 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- 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** · Feb 22 '07, 01:05 PM

Re: Sessions

Mike wrote:

On 22 Feb, 09:56, Curtis <zer0d...@veriz on.netwrote:

>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];?> 
</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_st art Off Off
session.bug_com pat_42 Off Off
session.bug_com pat_warn On On
session.cache_e xpire 180 180
session.cache_l imiter 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_divi sor 1000 1000
session.gc_maxl ifetime 1440 1440
session.gc_prob ability 1 1
session.hash_bi ts_per_characte r 5 5
session.hash_fu nction 0 0
session.name PHPSESSID PHPSESSID
session.referer _check no value no value
session.save_ha ndler files files
session.save_pa th /tmp /tmp
session.seriali ze_handler php php
session.use_coo kies On On
session.use_onl y_cookies Off Off
session.use_tra ns_sid 0 0

>>

I've tried changing the session.use_tra ns_sid and the
session.use_coo kies 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- 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?

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** · Feb 22 '07, 01:25 PM

Re: Sessions

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];?> 
</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_st art Off Off
session.bug_com pat_42 Off Off
session.bug_com pat_warn On On
session.cache_e xpire 180 180
session.cache_l imiter 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_divi sor 1000 1000
session.gc_maxl ifetime 1440 1440
session.gc_prob ability 1 1
session.hash_bi ts_per_characte r 5 5
session.hash_fu nction 0 0
session.name PHPSESSID PHPSESSID
session.referer _check no value no value
session.save_ha ndler files files
session.save_pa th /tmp /tmp
session.seriali ze_handler php php
session.use_coo kies On On
session.use_onl y_cookies Off Off
session.use_tra ns_sid 0 0
>
I've tried changing the session.use_tra ns_sid and the
session.use_coo kies 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

**Mike** · Feb 22 '07, 01:45 PM

Re: Sessions

On 22 Feb, 13:10, Erwin Moller
<since_humans_r ead_this_I_am_s pammed_too_m... @spamyourself.c omwrote:

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];?> 
</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_st art Off Off
session.bug_com pat_42 Off Off
session.bug_com pat_warn On On
session.cache_e xpire 180 180
session.cache_l imiter 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_divi sor 1000 1000
session.gc_maxl ifetime 1440 1440
session.gc_prob ability 1 1
session.hash_bi ts_per_characte r 5 5
session.hash_fu nction 0 0
session.name PHPSESSID PHPSESSID
session.referer _check no value no value
session.save_ha ndler files files
session.save_pa th /tmp /tmp
session.seriali ze_handler php php
session.use_coo kies On On
session.use_onl y_cookies Off Off
session.use_tra ns_sid 0 0

>

I've tried changing the session.use_tra ns_sid and the
session.use_coo kies 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- Hide quoted text -

>
- 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

**Czapi** · Feb 22 '07, 04:15 PM

Re: Sessions

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** · Feb 23 '07, 01:05 AM

Re: Sessions

Erwin Moller wrote:

Mike wrote:
>

>On 22 Feb, 09:56, Curtis <zer0d...@veriz on.netwrote:

>>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.ph p
>>>************ *
>>><?php
>>>session_star t();
>>>$_SESSION[s_check1] = "4";
>>>?>
>>><a href="aoltest3. php">click me</a>
>>>aoltest3.p hp
>>>************ **
>>><?php
>>>session_star t();
>>>?>
>>><body>
>>>The session is <?php echo $_SESSION[s_check1];?> 
>>></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.cach e_expire 180 180
>>>session.cach e_limiter nocache nocache
>>>session.cook ie_domain no value no value
>>>session.cook ie_lifetime 0 0
>>>session.cook ie_path / /
>>>session.cook ie_secure Off Off
>>>session.entr opy_file no value no value
>>>session.entr opy_length 0 0
>>>session.gc_d ivisor 1000 1000
>>>session.gc_m axlifetime 1440 1440
>>>session.gc_p robability 1 1
>>>session.hash _bits_per_chara cter 5 5
>>>session.hash _function 0 0
>>>session.na me PHPSESSID PHPSESSID
>>>session.refe rer_check no value no value
>>>session.save _handler files files
>>>session.save _path /tmp /tmp
>>>session.seri alize_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_tra ns_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- 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?

>
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** · Feb 23 '07, 01:55 AM

Re: Sessions

Curtis wrote:

Erwin Moller wrote:

>Mike wrote:
>>

>>On 22 Feb, 09:56, Curtis <zer0d...@veriz on.netwrote:
>>>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.p hp
>>>>*********** **
>>>><?php
>>>>session_sta rt();
>>>>$_SESSION[s_check1] = "4";
>>>>?>
>>>><a href="aoltest3. php">click me</a>
>>>>aoltest3.ph p
>>>>*********** ***
>>>><?php
>>>>session_sta rt();
>>>>?>
>>>><body>
>>>>The session is <?php echo $_SESSION[s_check1];?> 
>>>></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
>>>>Registere d save handlers files user
>>>>Registere d serializer handlers php php_binary wddx
>>>>Directive Local Value Master Value
>>>>session.aut o_start Off Off
>>>>session.bug _compat_42 Off Off
>>>>session.bug _compat_warn On On
>>>>session.cac he_expire 180 180
>>>>session.cac he_limiter nocache nocache
>>>>session.coo kie_domain no value no value
>>>>session.coo kie_lifetime 0 0
>>>>session.coo kie_path / /
>>>>session.coo kie_secure Off Off
>>>>session.ent ropy_file no value no value
>>>>session.ent ropy_length 0 0
>>>>session.gc_ divisor 1000 1000
>>>>session.gc_ maxlifetime 1440 1440
>>>>session.gc_ probability 1 1
>>>>session.has h_bits_per_char acter 5 5
>>>>session.has h_function 0 0
>>>>session.nam e PHPSESSID PHPSESSID
>>>>session.ref erer_check no value no value
>>>>session.sav e_handler files files
>>>>session.sav e_path /tmp /tmp
>>>>session.ser ialize_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_tra ns_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- 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?

>>
>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

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@attgl obal.net
=============== ===

**Curtis** · Feb 23 '07, 02:05 AM

Re: Sessions

Jerry Stuckle wrote:

Curtis wrote:

>Erwin Moller wrote:

>>Mike wrote:
>>>
>>>On 22 Feb, 09:56, Curtis <zer0d...@veriz on.netwrote:
>>>>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.ph p
>>>>>********** ***
>>>>><?php
>>>>>session_st art();
>>>>>$_SESSIO N[s_check1] = "4";
>>>>>?>
>>>>><a href="aoltest3. php">click me</a>
>>>>>aoltest3.p hp
>>>>>********** ****
>>>>><?php
>>>>>session_st art();
>>>>>?>
>>>>><body>
>>>>>The session is <?php echo $_SESSION[s_check1];?> 
>>>>></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
>>>>>Register ed save handlers files user
>>>>>Register ed serializer handlers php php_binary wddx
>>>>>Directiv e Local Value Master Value
>>>>>session.au to_start Off Off
>>>>>session.bu g_compat_42 Off Off
>>>>>session.bu g_compat_warn On On
>>>>>session.ca che_expire 180 180
>>>>>session.ca che_limiter nocache nocache
>>>>>session.co okie_domain no value no value
>>>>>session.co okie_lifetime 0 0
>>>>>session.co okie_path / /
>>>>>session.co okie_secure Off Off
>>>>>session.en tropy_file no value no value
>>>>>session.en tropy_length 0 0
>>>>>session.gc _divisor 1000 1000
>>>>>session.gc _maxlifetime 1440 1440
>>>>>session.gc _probability 1 1
>>>>>session.ha sh_bits_per_cha racter 5 5
>>>>>session.ha sh_function 0 0
>>>>>session.na me PHPSESSID PHPSESSID
>>>>>session.re ferer_check no value no value
>>>>>session.sa ve_handler files files
>>>>>session.sa ve_path /tmp /tmp
>>>>>session.se rialize_handler php php
>>>>>session.us e_cookies On On
>>>>>session.us e_only_cookies Off Off
>>>>>session.us e_trans_sid 0 0
>>>>>I've tried changing the session.use_tra ns_sid and the
>>>>>session.us e_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- 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?
>>>
>>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

>
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

**Mike** · Feb 23 '07, 08:25 AM

Re: Sessions

On 23 Feb, 01:56, Curtis <zer0d...@veriz on.netwrote:

Jerry Stuckle wrote:

Curtis wrote:

Erwin Moller wrote:
>Mike wrote:

>

>>On 22 Feb, 09:56, Curtis <zer0d...@veriz on.netwrote:
>>>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.p hp
>>>>*********** **
>>>><?php
>>>>session_sta rt();
>>>>$_SESSION[s_check1] = "4";
>>>>?>
>>>><a href="aoltest3. php">click me</a>
>>>>aoltest3.ph p
>>>>*********** ***
>>>><?php
>>>>session_sta rt();
>>>>?>
>>>><body>
>>>>The session is <?php echo $_SESSION[s_check1];?> 
>>>></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
>>>>Registere d save handlers files user
>>>>Registere d serializer handlers php php_binary wddx
>>>>Directive Local Value Master Value
>>>>session.aut o_start Off Off
>>>>session.bug _compat_42 Off Off
>>>>session.bug _compat_warn On On
>>>>session.cac he_expire 180 180
>>>>session.cac he_limiter nocache nocache
>>>>session.coo kie_domain no value no value
>>>>session.coo kie_lifetime 0 0
>>>>session.coo kie_path / /
>>>>session.coo kie_secure Off Off
>>>>session.ent ropy_file no value no value
>>>>session.ent ropy_length 0 0
>>>>session.gc_ divisor 1000 1000
>>>>session.gc_ maxlifetime 1440 1440
>>>>session.gc_ probability 1 1
>>>>session.has h_bits_per_char acter 5 5
>>>>session.has h_function 0 0
>>>>session.nam e PHPSESSID PHPSESSID
>>>>session.ref erer_check no value no value
>>>>session.sav e_handler files files
>>>>session.sav e_path /tmp /tmp
>>>>session.ser ialize_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_tra ns_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-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?

>

>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

>

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- Hide quoted text -
>
- Show quoted text -

umm, I think we are drifting from my original post!!

Mike

Sessions

Sessions

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment