|
|
Posted by Curtis on 02/23/07 00:59
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
Navigation:
[Reply to this message]
|