Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96459
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ohgaki.net designates 180.42.98.130 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEZPtU7JK=RCvyVJ6yyLHziH0Eog4pu4kXGHNTcS4gtY9Oxu-g@mail.gmail.com>
References: <CAGa2bXbUmRZ8EK4HB=WyKLK5EcACXZ_wisH1v3=2ib81-HetUQ@mail.gmail.com>
 <CAEZPtU7JK=RCvyVJ6yyLHziH0Eog4pu4kXGHNTcS4gtY9Oxu-g@mail.gmail.com>
Date: Wed, 19 Oct 2016 10:14:26 +0900
Message-ID: <CAGa2bXZFrg81K8KYHAYyBf8dHq9Y3pLczmidg=Ecm0v+LcwS2g@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Bug fix and RFC/Merge rule
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi Pierre,

On Wed, Oct 19, 2016 at 9:52 AM, Pierre Joye <pierre.php@gmail.com> wrote:
> Like your session change, while not really critical to me (has been
> like that for ages) is relatively logical while as a RM, I would not

It's off topic, but I'll paste answer to a question regarding
session.use_strict_mode. i.e. session ID validation. I recently got
this question personally.

> I have a question regarding this quite old RFC - my question is, how was it practically possible to attack a PHP app that uses sessions prior to PHP 5.5.2?
> Doesn't it require the ability for the attackers to place an SID cookie in the victim's browser?  How would they do that (assuming trans_sid is off)?

Possible scenarios are:
 - Attacker sets SID by XSS. (Set cookies via JavaScript)
 - Physical access to victim's device. (e.g. Friends, Colleague
attacker, Shared PC)
 - Compromised network. (WiFi access point, ARP spoofing)

When aboves are the case, attacker may set malicious cookies including
unchangeable cookies.

I think this answers to your question. Followings are additional info.

Malicious active SID is security risk even without authentication.
e.g. Shopping sites may store user info (name, address, purchased
product, etc) w/o authentication to enable shopping without user
registration. Another example is session ID has meaning. e.g. User ID
prefixed session that I'm currently proposing. Attacker may set
attacker generated SIDs that includes user ID for system's checks max
number of active session per user, and perform personal DoS attacks.

Another possible attack scenario is broken session_regenerate_id()
usage. When session_regenerate_id() is used properly, attacker cannot
gain authenticated session ID. However, if user is aware of risks of
session management w/o timestamp and try to set timestamp by
him/herself, the code could be broken by mistakes, and PHP may keep
using attacker set session ID, and attacker may gain authenticated
session ID. (Or more simpler, program didn't call
session_regenerate_id() at all, or at least call improperly)

When latter scenario is effective, attacker can set undeletable
session ID cookie, and attacker may gain authenticated session almost
forever.

To remove risks,
 - Enable use_strict_session (Attackers cannot set their SIDs)
 - Make session_regenerate_id() can set programmer specified session
ID. (Need this because I can modify session_regenerate_id() work
safely w/o knowing session management details)
 - Adopt timestamp management via session data (i.e. $_SESSION) so
that programs can manage session data precisely.

I hope this helps!

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net