Is PHP session safe?

[howa]

1. For example, without SSL, If I capture my local LAN packet and
scanned the SESSION ID, is it possible to hijack the session?

2. So any recommendation for web apps session handling without SSL?

Thanks.

[iktorn]

howa napisał(a):

1. For example, without SSL, If I capture my local LAN packet and
scanned the SESSION ID, is it possible to hijack the session?

unfortunately yes

2. So any recommendation for web apps session handling without SSL?

- use very short session life time
- force user to login again before doing something important

--
Wiktor Walc
http://phpfreelancer.net

[howa]

- use very short session life time

- force user to login again before doing something important

I found that many Yahoo! or Google only use SSL during authentication
only, the rest of the services are provided by plain HTTP only...

really interested in how to prevent session hijacking, especailly from
neighbor hosts with the SAME IP, really difficult...

[Willem Bogaerts]

> - use very short session life time

> - force user to login again before doing something important

And change session whenever you change user rights (i.e., after a
successful login). PHP's function session_regenerate_id() is suitable
for this.

Search the net for "session hijacking" and "session fixation". There is
a lot of info available...

Best regards,
--
Willem Bogaerts

Application smith
Kratz B.V.
http://www.kratz.nl/

[Roman]

iktorn wrote:

howa napisał(a):

>1. For example, without SSL, If I capture my local LAN packet and
scanned the SESSION ID, is it possible to hijack the session?

unfortunately yes

>2. So any recommendation for web apps session handling without SSL?

- use very short session life time
- force user to login again before doing something important

How about caching the initiating IP during session creation? Unless
potential hijacker is behind same NAT box, he will have have different
IP and should not be able to hijack.

Roman

[Jerry Stuckle]

Roman wrote:

iktorn wrote:

>howa napisał(a):

>>1. For example, without SSL, If I capture my local LAN packet and
scanned the SESSION ID, is it possible to hijack the session?

unfortunately yes

>>2. So any recommendation for web apps session handling without SSL?

- use very short session life time
- force user to login again before doing something important

How about caching the initiating IP during session creation? Unless
potential hijacker is behind same NAT box, he will have have different
IP and should not be able to hijack.

Roman

And what do you do when the IP address can change with every request -
for instance, AOL users and some corporations?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[howa]

>

And what do you do when the IP address can change with every request -
for instance, AOL users and some corporations?

Hi,

You made a very good point, never thought of IP address can change
with every request...

How about only rely on the first 3 part, e.g. 202.92.94.xxx (drop the
last part) ?

[Michael Fesser]

..oO(howa)

>And what do you do when the IP address can change with every request -
for instance, AOL users and some corporations?

You made a very good point, never thought of IP address can change
with every request...

How about only rely on the first 3 part, e.g. 202.92.94.xxx (drop the
last part) ?

Still not reliable. The really big companies and providers usually have
class B or even class A networks, which means that the last two or three
octets may change. Even entirely different IPs are possible, so relying
on that is _never_ reliable.

Micha

[Toby A Inkster]

Michael Fesser wrote:

Still not reliable. The really big companies and providers usually have
class B or even class A networks, which means that the last two or three
octets may change. Even entirely different IPs are possible, so relying
on that is _never_ reliable.

Indeed, my workplace isn't a big company -- it's a medium charity, with
fewer than 100 employees -- but we have three ADSL lines with two
different ISPs, providing us with some redundancy. Each ADSL line has a
very different IP address (not even the first octet is the same). Because
of our load balancing router, a request from a computer in our office
could appear to come from any of those three IP addresses.

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.12-12mdksmp, up 109 days, 4:18.]

URLs in demiblog
http://tobyinkster.co.uk/blog/2007/05/31/demiblog-urls/

[Jerry Stuckle]

howa wrote:

>And what do you do when the IP address can change with every request -
for instance, AOL users and some corporations?

Hi,

You made a very good point, never thought of IP address can change
with every request...

How about only rely on the first 3 part, e.g. 202.92.94.xxx (drop the
last part) ?

No guarantee there, either - although I don't see why it should change,
you're also losing a main security feature. Just figure that IP
addresses are not reliable security indicators.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[max.schulze]

On Jun 12, 11:05 pm, Jerry Stuckle <[e-mail]:

howa wrote:

And what do you do when the IP address can change with every request -
for instance, AOL users and some corporations?

Hi,

You made a very good point, never thought of IP address can change
with every request...

How about only rely on the first 3 part, e.g. 202.92.94.xxx (drop the
last part) ?

No guarantee there, either - although I don't see why it should change,
you're also losing a main security feature. Just figure that IP
addresses are not reliable security indicators.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Maybe you can do that with AJAX
What about chaning the session_id on every request?

Or check if 2 Users with the same ip are logged in?

[Jerry Stuckle]

ma*********@googlemail.com wrote:

On Jun 12, 11:05 pm, Jerry Stuckle <[e-mail]:

>howa wrote:

>>>And what do you do when the IP address can change with every request -
for instance, AOL users and some corporations?
Hi,
You made a very good point, never thought of IP address can change
with every request...
How about only rely on the first 3 part, e.g. 202.92.94.xxx (drop the
last part) ?

No guarantee there, either - although I don't see why it should change,
you're also losing a main security feature. Just figure that IP
addresses are not reliable security indicators.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Maybe you can do that with AJAX
What about chaning the session_id on every request?

Or check if 2 Users with the same ip are logged in?

Ajax requires javascript be enabled. And in a small corporation with a
single firewall/proxy, all users will have the same ip address.

IP addresses are not reliable at any time other than when responding to
the immediate request.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[howa]

On Jun 13, 11:44 pm, Jerry Stuckle <[e-mail]:

Ajax requires javascript be enabled. And in a small corporation with a
single firewall/proxy, all users will have the same ip address.

IP addresses are not reliable at any time other than when responding to
the immediate request.

yes, IP should not be used. I agree

back to the corporation example, if SSL can't be used, what are the
best practices for protecting session cookie?

Seems there is no 100% safe solution - if people can capture your
request and can reproduce them!

[Jerry Stuckle]

howa wrote:

On Jun 13, 11:44 pm, Jerry Stuckle <[e-mail]:

>Ajax requires javascript be enabled. And in a small corporation with a
single firewall/proxy, all users will have the same ip address.

IP addresses are not reliable at any time other than when responding to
the immediate request.

yes, IP should not be used. I agree

back to the corporation example, if SSL can't be used, what are the
best practices for protecting session cookie?

Seems there is no 100% safe solution - if people can capture your
request and can reproduce them!

No, short of SSL, there is no safe solution. Anyone anywhere between
the client and the server can intercept the data and use it for whatever
reason. Of course, because there's no guarantee as to what route a
packet will follow, the most likely places to intercept the packets is
on either end.

But then that's why SSL was invented.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[howa]

On 6 14 , 12 21 , Jerry Stuckle <[e-mail]:

No, short of SSL, there is no safe solution. Anyone anywhere between
the client and the server can intercept the data and use it for whatever
reason. Of course, because there's no guarantee as to what route a
packet will follow, the most likely places to intercept the packets is
on either end.

But then that's why SSL was invented.

Okay, let have some constraints, say you can use SSL during login, but
you can't use SSL for data transmission afterward, so it is possible?
(similar to yahoo or gmail)

[Gordon Burditt]

>No, short of SSL, there is no safe solution. Anyone anywhere between

>the client and the server can intercept the data and use it for whatever
reason. Of course, because there's no guarantee as to what route a
packet will follow, the most likely places to intercept the packets is
on either end.

But then that's why SSL was invented.

Okay, let have some constraints, say you can use SSL during login, but
you can't use SSL for data transmission afterward, so it is possible?
(similar to yahoo or gmail)

SSL isn't 100% safe, either. I could guess the key on the first
try. (VERY unlikely!) I could also guess a 8K-bit session cookie
on the first try. In the case of the session cookie, there's
sniffing it off the wire, session fixation, and a bunch of other
attacks after you've left the SSL session.

[Jerry Stuckle]

howa wrote:

On 6 14 , 12 21 , Jerry Stuckle <[e-mail]:

>No, short of SSL, there is no safe solution. Anyone anywhere between
the client and the server can intercept the data and use it for whatever
reason. Of course, because there's no guarantee as to what route a
packet will follow, the most likely places to intercept the packets is
on either end.

But then that's why SSL was invented.

Okay, let have some constraints, say you can use SSL during login, but
you can't use SSL for data transmission afterward, so it is possible?
(similar to yahoo or gmail)

No, the session id is still sent in plain text then, and can be
intercepted and hacked.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================