Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73298
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.173 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <20140319080229.GA83863@mail>
References: <CAGa2bXYJqGqegGy=rYcDBXd8RmFFR9j=p2m63ZVSADoga+vwhg@mail.gmail.com>
 <20140319080229.GA83863@mail>
Date: Wed, 19 Mar 2014 17:50:28 +0900
Message-ID: <CAGa2bXZiGJO+ioJ1qV3YUQVpU9-5TbmdH0WaXmWHxZ_6umYoOQ@mail.gmail.com>
To: Mateusz Kocielski <shm@digitalsun.pl>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c373ecf8e36f04f4f1c06e
Subject: Re: [PHP-DEV] [RFC] [Discussion] Secure session_regenerate_id()
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c373ecf8e36f04f4f1c06e
Content-Type: text/plain; charset=UTF-8

Hi Mateusz,

On Wed, Mar 19, 2014 at 5:02 PM, Mateusz Kocielski <shm@digitalsun.pl>wrote:

> [...]
> Errors may be raised for either legitimate user or attacker. If error is
> raised for legitimate user, legitimate user could know they are under
> attack.
> (Possibly network is dangerous or app has vulnerability) If error is raised
> for attacker, attacker could know they might be caught by illegal access.
> [...]
>
> I wonder how many legitimate users will realize they're under attack. For
> average user it will look like application does weird things (i.e. logout
> immediately). If network is dangerous or app has vulnerability then we
> cannot
> fix the problem - you can't make n-th layer secure if (n-1)-th layer is
> insecure.
>

It depends on how developer treats possible attack. Session manager raises
exception only. Developer may ignore or give detailed information about the
risk in their page.

My proposal does not alert victims/attackers automatically, but only give
tools for developers.
How to use tools is up to developers.


 [...]
> Stealing session ID is easy regardless of HTTPS. Attacker can set up fake
> router by ARP spoofing. Most networks do not have ARP spoofing prevention,
> even detection. For HTTP, attacker can view session ID simply. For HTTPS,
> attacker can set up transparent HTTPS stripping proxy and steal session ID.
> Most users do not care much if they are connecting via HTTPS or not.
> [...]
>
> What if application uses secure attribute on session cookie? We've got
> already
> session.cookie_secure setting which seems to solve the issue. I don't see
> how
> by introducing your proposal will make situation better. If application
> allows
> login and operates as user without HTTPS, then it's not our problem.
>

Secure attribute does not matter if attacker is stripping HTTPS.

I'm having hard time to explain why "detection" is better for security.
Surveillance camera does not "prevent" crime, but "identify" who did.
Surveillance cameras are good for security.

BTW, almost all security measures are "mitigation".
Security measure does not have to "remove risk", but mitigates risk like
HTTPS.
Do you agree that HTTPS is security measure, right?


 [...]
>  Problem of immediate old session deletion:
>
>     Make session ID regeneration unreliable. (Unacceptable)
> [...]
>
> I haven't found single issue in
> bugs.php.net that session_regenerate_id(TRUE) is a problem to any user.
>

Of course, there aren't. session_regenerate_id(FALSE) is the default now and
random logout by race condition is hard to be noticed by developers.


>
> [...]
>     Remove alarm for possible attacks. (No detection = Insecure)
> Make sure old session is deleted certain period and Raise
> error/exception for invalid access provides much better security than
> current way or immediate deletion.
> [...]
>
>  What you mean by "No detection = Insecure"?
>

I think I've answered this in previous comment.

Thank you for asking question.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c373ecf8e36f04f4f1c06e--