|
|
Posted by Mike on 02/23/07 08:12
On 23 Feb, 01:56, Curtis <zer0d...@verizon.net> wrote:
> 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- Hide quoted text -
>
> - Show quoted text -
umm, I think we are drifting from my original post!!
Mike
[Back to original message]
|