Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91885
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.49 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAGa2bXauwspEZ4HYSHgVOyd+VEvKxoymWYFPG6NaOdCa+APfKQ@mail.gmail.com>
References: <CAGa2bXauwspEZ4HYSHgVOyd+VEvKxoymWYFPG6NaOdCa+APfKQ@mail.gmail.com>
Date: Thu, 24 Mar 2016 13:18:03 +0900
Message-ID: <CAGa2bXbYKdW8LED566kUt50xYMTWLQWyzazWQkBktk5vxOSfpg@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [RFC][Discussion] Precise session data management
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi all,

On Thu, Mar 24, 2016 at 11:34 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> We have to come up with other solutions for
>
>  - Session loss by race conditions
>  - Method to make session abuse harder

I'll explain how attacker can steal PHP sessions forever with current
session module. There are multiple serious issues in current session
management. I suppose this makes difficult to understand what wrong
with current session. Any stolen session is not acceptable, but I'll
focus cases only that allows session abuse forever to make discussion
simpler.

** Exploit 1 ** Attack adoptive session management
Internet RFC does not define cookie precedence for multiple
outstanding cookies. Therefore, when multiple cookies for "httponly",
"secure", web site domain names, web app path are set, it's up to
browser implementation which cookie is sent to browser. Attacker can
set undeletable cookie by using this behavior. i.e. Simple Set-cookie
cannot delete nor update session ID cookie, but attacker's session ID
stay as outstanding session ID cookie forever.

If you experiment how browsers behave, you'll be surprised how easy to
set undeletable cookie by single XSS. You'll be surprised how some
browsers manage cookie by insane way also.

Requirement
 "session.use_strict_mode=0". This is the default

Note
 "session.use_strict_mode=1" can mitigate issue a little, but remained
risk is not acceptable. Attacker may use next attack method explained
to keep active session (to avoid GC). "session.use_strict_mode=1"
creates client side race condition also. This results in lost sessions
on occasion.

** Exploit 2 ** Attack static session ID
Stealing active session is easy especially when physical access to
device is possible. It's just a matter of displaying cookies for a
website and take picture, then abuse.

When https is not used, stealing active session ID is trivial by ARP
spoofing, evil twins, etc. Even if https is used, setting up https
stripping proxy is trivial and HSTS is not used widely.

Attackers can keep active session forever by accessing stolen session
periodically before GC.

Requirement
 Application that does not call session_regenerate_id() after login
and has no expiration period for active sessions.


In addition, PHP does not have any attack detection for these attacks
while precise session management proposal does.

Inclusion, if I were attacker, I would say attacking PHP session is
easy and safe (undetectable) by poor session management.

Let's discuss how we are going to address these issues and fix them.
My opinion is "PHP's session manager must be safe against these
attacks by default/out of the box. Users should not have to write code
and manage basic session status".

Those who were vote against the proposal, please let me know which
part of my RFC is not good enough at least, better proposal is
appreciated of course.

Thank you.

--
Yasuo Ohgaki
yohgaki@ohgaki.net