|
|
Posted by Jerry Stuckle on 02/23/07 01:41
Curtis wrote:
> Erwin Moller wrote:
>> 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.
>
> 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@attglobal.net
==================
[Back to original message]
|