|
|
Posted by Curtis on 02/23/07 01:56
Jerry Stuckle wrote:
> 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.
>
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
Navigation:
[Reply to this message]
|