Re: php session without cookie useage

Gordon Burditt wrote:

>>> Since web servers don't retain state from page to page, it is up to the
>>> browser or the application to maintain the state if needed. Browsers
>>> can do so with a cookie. Alternatively, if you code the application to
>>> transfer a session key created on login to subsequent pages via a POST
>>> (more secure) or GET, you can maintain state. Each page must be
>>> responsible for checking the validity of the key obtained from the
>>> browser via a cookie or via POST or GET.
>>
>>Hi Michael,
>>
>>I have a question:
>>Why do you say that passing PHPSESSID via POST is more safe than via a
>>COOKIE?
>>
>>Or do you mean that passing the PHPSESSID via POST is more secure than
>>GET?
>

Hi Gordon, thanks for your warning.

I wasn't aware of any round-robin proxies that result in a changed IP-adres
for the same session.
Strange setup... I must say I do not like it.
But that is my problem, not your's of course. :-)

One thing: The fact that many people share the same IP doesn't frustrate the
setup I described. The fact that a SESSION has an IP stored, doesn't mean
that every IP can only be used once.
It is only ment as a way to make sure the IP stays the same during one
session.

But of course, the AOL-members and roundrobin proxies are a real concern.

Thanks for your advise.
:-)

Regards,
Erwin Moller


> I think the OP meant that POST is more secure than GET. GET leaves
> the session ID in stored URLs in the browser history. POST does
> not. Cookies with a duration longer than for a browser session
> also get left around in files, although this is much less obvious
> than leaving it in the browser history. Sessions, however done
> (GET, POST, COOKIE), with a short timeout are less vulnerable to
> spoofing since spoofing an expired session does no good whatever.
>
>>I mean: the request to the webbrowser send the GET, POST and COOKIE, all
>>unencrypted (unless you use shhtp of course), so it all sounds very unsafe
>>to me as far a sessionhijacking goes.
>
> Session hijacking does not have to be done by sniffing the wire.
> It could be done by using the same computer after the original user
> leaves (think about Internet Cafes, or families with less than one
> computer per family member). Thus, session IDs left in browser
> history or cookies that last longer than the session can be read,
> by other users or perhaps by spyware. Browser URLs (including the
> session ID, if done with GET) may get cut-and-pasted into email or
> news posts when the user decides to tell his friends about something
> interesting he found on the web.
>
>>One tip a friend once gave me (Rein Velt) is storing the remote IP-adres
>>(the the client's IP) also in the session, and always compare it before
>>using session. :-)
>
> That may block legitimate users using a round-robin proxy (different
> requests come from different IPs, even including pieces of the same
> page). AOL users would have problems with this, I believe, and
> they aren't the only ones. ISPs can inject proxies into the http
> path without users knowing about it or having to change their browser
> settings. (Router magic to redirect the traffic to go through the
> proxy.)
>
> Some users even PAY for a proxy that uses a compressed protocol
> between the proxy and the user's browser with some add-on software
> ("web accelerators"), although they may not realize that's how it
> works. Decent software for this does not cache pages requiring
> authentication. Nor does it cache https. If someone tries caching
> https, and the user is paying attention, they may notice that the
> certificate is different (that of the proxy, not the site they
> requested) for such a man-in-the-middle attack on https.
>
> The browser may pop up warnings in this situation. How many people
> will notice this? Not very many people noticed when I put up a
> secure site with a home-grown certificate for "Satan, Prince of
> Darkness" with an address in Hell. And this was a prototype
> E-commerce site (none of the order-taking or credit-card charging
> stuff ever got done) I was asking them to check out.
>
> Also, the IP check is less than 100% effective against spoofing:
> office users spoofing each other behind a NAT gateway all may have
> the same public IP, and users of the same proxy have the same IP.
>
> The fact that it's less than 100% effective shouldn't discourage
> you, but the fact that you lock out legitimate users might. If
> it's an intranet application, you may not care that AOL users can't
> use it. If it's an E-commerce site, you (or your employer) may be
> upset to realize you've locked out AOL users from buying from you.
>
> Gordon L. Burditt

.

Relevant Pages

  • Re: _SESSION weirdness behind a NAT firewall/router: bug?
    ... that the 'sess_deleted' file is actually being used as a session ID. ... force the cookie to expire. ... Any $_SESSION values introduced by one browser become part of the ... I re-load the non-logged-in index page in Opera. ...
    (comp.lang.php)
  • Re: php session without cookie useage
    ... >> transfer a session key created on login to subsequent pages via a POST ... >> browser via a cookie or via POST or GET. ... the session ID in stored URLs in the browser history. ... That may block legitimate users using a round-robin proxy (different ...
    (comp.lang.php)
  • Re: Is Session Always Cleared?
    ... If the first user closes his browser after he is finished, the session cookie is forgotten. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Detecting loss of session
    ... > a request. ... From what I've read on session cookies ... > sending) them as soon as they expire, not when the browser is closed? ... If you don't set the expiration on a Cookie, ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Cookies , Session Which is Better ? and Global.asa Question
    ... YOU SHOULD NEVER STORE PERSONALLY IDENTIFIABLE INFORMATION IN A ... If you needed to store personal information in a cookie use non ... impossible - its much harder for me to hijack session information from ... The average time a session lasts is 20 mins. So, when your browser ...
    (microsoft.public.inetserver.asp.general)