|
|
Posted by Erwin Moller on 02/22/07 12:53
Mike wrote:
> On 22 Feb, 09:56, Curtis <zer0d...@verizon.net> wrote:
>> 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- 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
Navigation:
[Reply to this message]
|