php session without cookie useage

[ehendrikd]

hi all

i need some clarification on how the php session work in relation to
cookies.

we have a web site where users need to log in. a few of our users were
having troubles with their browser clients having different levels of
cookie security settings. i assumed a solution would be to have the php
site use the session only, and set session.use_cookies to 0 in the
php.ini file. after doing this, the session no longer persits after
moving from page to page.

does the session need to have cookies enabled to work? if so, what is
the point of this setting? if not, what settings do i need to set to
make the session work sever side only?

thanks in advance

[Michael Vilain]

In article <11*********************@f14g2000cwb.googlegroups. com>,
eh*******@gmail.com wrote:

hi all

i need some clarification on how the php session work in relation to
cookies.

we have a web site where users need to log in. a few of our users were
having troubles with their browser clients having different levels of
cookie security settings. i assumed a solution would be to have the php
site use the session only, and set session.use_cookies to 0 in the
php.ini file. after doing this, the session no longer persits after
moving from page to page.

does the session need to have cookies enabled to work? if so, what is
the point of this setting? if not, what settings do i need to set to
make the session work sever side only?

thanks in advance

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.

http://nl2.php.net/manual/en/ref.session.php has a more extensive
discussion.

--
DeeDee, don't press that button! DeeDee! NO! Dee...

[Erwin Moller]

Michael Vilain 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?

I am curious why you say that.

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.

By the way:
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. :-)

Regards,
Erwin

[Gordon Burditt]

>> 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?

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

[Michael Vilain]

In article <42***********************@news.xs4all.nl>,
Erwin Moller
<si******************************************@spam yourself.com> wrote:

Michael Vilain 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?

I am curious why you say that.

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.

By the way:
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. :-)

Regards,
Erwin

Your friend's advice is good. I'd listen to them.

Sorry for the unclear English. I meant that without cookies, all you
have to communicate between sessions are hidden fields and GET/POST
methods. If you use GET, the session ID is displayed in the URL which
isn't as secure as using the session ID as a hidden field and obtaining
it through a POST. I wasn't thinking specifically of PHPSESSID but one
you've coded yourself.

If you use IP address and some other info run through MD5, you can make
a quite secure session ID.

--
DeeDee, don't press that button! DeeDee! NO! Dee...

[Erwin Moller]

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

[Erwin Moller]

Michael Vilain wrote:

In article <42***********************@news.xs4all.nl>,
Erwin Moller
<si******************************************@spam yourself.com> wrote:

Michael Vilain 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?

I am curious why you say that.

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.

By the way:
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. :-)

Regards,
Erwin

Hi,
Your friend's advice is good. I'd listen to them.

Sorry for the unclear English.
No problem. I understand now what you were saying.

I meant that without cookies, all you
have to communicate between sessions are hidden fields and GET/POST
methods. If you use GET, the session ID is displayed in the URL which
isn't as secure as using the session ID as a hidden field and obtaining
it through a POST. I wasn't thinking specifically of PHPSESSID but one
you've coded yourself.

If you use IP address and some other info run through MD5, you can make
a quite secure session ID.

Yes,

Please read the warning Gordon Burditt gave me (us).

The setup will frustrate a certain percentage of users: The ones on AOL and
the ones that use roundrobin-proxy.

Regards,
Erwin Moller

[Gordon Burditt]

>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.
Proxies like this are often set up using router magic (and the
customer may not know he's using a proxy at all). Routers don't
have a lot of memory to keep track of state, like <this ip> is using
<this proxy>, so route all his requests there. Also, it evens out
the load more if it's done on a request-by-request basis. And you
want to use a different proxy if the one in use goes down.
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.

No, shared IPs don't lock out legitimate users. Shared IPs enable
session hijacking between users that share the IP, which was the
original reason for locking the session to the IP in the first
place, wasn't it? Now, I'm not going to say abandon locking the
session to the IP because it's not 100% perfect at preventing session
hijacking. (Credit card validation is nice, too, but it isn't 100%
either, as thieves use stolen credit card numbers) Some people
have abandoned locking the session to the IP because it locks out
legitimate users, but that's a different issue.

You can get a little trickier, say, by locking the session to *AOL*
rather than a specific AOL proxy. That limits session hijacking
to other AOL customers. It does, however, require somehow coming
up with a list of AOL proxies. Reverse DNS and a look at your web
logs might help with this.

Also, recording (logging) the IP (without DOING anything with it)
is not a bad idea either, especially when a user does something
sensitive and important (like changing a password, ordering something
that costs money, deleting stuff, or even just logging in). It
doesn't stop mischief but it leaves logs that might help you close
the hole afterwards. Is it reasonable that someone would order dialup
service from an ISP that serves only the USA from an Asian IP using
a credit card number with an address in France? Is it reasonable
that someone would order dialup service using a credit card later
determined to be stolen from your own help desk's IP?

Oh, when I said that proxies don't cache authenticated pages, I
meant they don't cache pages using authentication that the proxies
know about (like .htaccess/Basic Authentication, or https). They
may not recognize all the schemes used by PHP programmers. They
probably don't cache POST requests, either. They might cache GET
requests, thereby putting an automated session hijacker in the path
of lots of people who have no malicious intent or have any idea
they are doing it.

Gordon L. Burditt