[PHP-DEV] Re: register_globals vs session.force_nocookie

2002-06-15 Thread Sascha Schumann

Let's analyze the meaning of session.use_cookies, shall we?

http://php.net/manual/en/ref.session.php says:

session.use_cookies specifies whether the module will use
cookies to store the session id on the client side. Defaults
to 1 (enabled).

Please note the absence of words like only.

The combination of session.use_cookies=1 and
session.use_trans_sid=0 is working perfectly fine at the moment.

This is also not about forgery.  While cookies are user data,
the thing Mr. Pinerolo worries about is tricking a victim
into using session ids which are known to the attacker.

While it is easy for an attacker to send a URL to the victim
containing a session id, injecting a malice cookie into the
victim's system is a much harder job.  I would say it is
impossible, if I would not know about user habits and the
quality of the software coming out of Redmond.  Despite the
availability of patches, many systems are simply not updated
in a timely fashion.

You also cannot compare this issue to register_globals,
unless you are used to compare apples and oranges.

With register_globals=on, a malice user can directly cause
harm and severe damage to a service, if the scripts are badly
written.  For example, an attacker could inject SQL directly
and cause all tables to be dropped.

With session.use_only_cookies=0, an attacker has a tool for
planting social engineering attacks against unwitting users.
It does not cause direct damage on the server side.  It is
one way of thousands to manipulate users.  Just look at how
many AOL accounts are pfished each day, because users
ignore the warning that noone will legitimately ask them for
their password.

Mr. Pinerolo's example of online banking is immune to this
scheme, because all bank transactions are protected by
a one-time pad (called TANs in Germany).

I would not have come up with the session.use_only_cookies
idea, if I did not see an advantage for using it under some
circumstances.  These circumstances are rare though and do
not apply to all sites in general.  Badly written PHP scripts
are more common apparently which was the deciding factor for
disabling register_globals.  I do not foresee such a
compatibility breaking step with regard to
session.use_only_cookies.

- Sascha


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




[PHP-DEV] Re: register_globals vs session.force_nocookie

2002-06-15 Thread Giancarlo Pinerolo

[EMAIL PROTECTED] (Sascha Schumann) wrote:
---
Let's analyze the meaning of session.use_cookies, shall we?

http://php.net/manual/en/ref.session.php says:

session.use_cookies specifies whether the module will use
cookies to store the session id on the client side. Defaults
to 1 (enabled).

Please note the absence of words like only.

The combination of session.use_cookies=1 and
session.use_trans_sid=0 is working perfectly fine at the moment.

This is also not about forgery.  While cookies are user data,
the thing Mr. Pinerolo worries about is tricking a victim
into using session ids which are known to the attacker.

While it is easy for an attacker to send a URL to the victim
containing a session id, injecting a malice cookie into the
victim's system is a much harder job.  I would say it is
impossible, if I would not know about user habits and the
quality of the software coming out of Redmond.  Despite the
availability of patches, many systems are simply not updated
in a timely fashion.

You also cannot compare this issue to register_globals,
unless you are used to compare apples and oranges.

With register_globals=on, a malice user can directly cause
harm and severe damage to a service, if the scripts are badly
written.  For example, an attacker could inject SQL directly
and cause all tables to be dropped.

With session.use_only_cookies=0, an attacker has a tool for
planting social engineering attacks against unwitting users.
It does not cause direct damage on the server side.  It is
one way of thousands to manipulate users.  Just look at how
many AOL accounts are pfished each day, because users
ignore the warning that noone will legitimately ask them for
their password.

Mr. Pinerolo's example of online banking is immune to this
scheme, because all bank transactions are protected by
a one-time pad (called TANs in Germany).

I would not have come up with the session.use_only_cookies
idea, if I did not see an advantage for using it under some
circumstances.  These circumstances are rare though and do

Frankly,  what I think of this is that it is a piece of social engineering in itself.
The new session.use_only_cookies directive, put like that, that can only be set on a 
per installation basis, will never be adopted.
This will leave all sites in the world vulnerable to damn easy snooping.
I understand there are historical reasons for trying to keep the status quo, probably 
too many applications rely on the actual weakness. I do not share that vision.

Anyway this will come back to your face one day, I have no doubts about it. This is 
not my problem, I'll be fairly offshore for the next months, so really you do what you 
want, discuss it or impose it among yourselves, I've done my duty.

Mr. Pinerolo

not apply to all sites in general.  Badly written PHP scripts
are more common apparently which was the deciding factor for
disabling register_globals.  I do not foresee such a
compatibility breaking step with regard to
session.use_only_cookies.

- Sascha



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php