Morning Yasuo,
First, thanks for all the effort ... You already know that, a refusal
to merge a patch doesn't mean you wasted your time, it should serve to
refocus your research.
So, I thought I'd say some stuff, to aid with that ...
The first thing I would do is break down the problem into smaller, much
smaller, RFC's: We know there are many inconsistencies in the language, we
could write a huge long list, and do a bumper RFC to solve them all at
once. But would that be a good idea !?
As already mentioned it's much easier to consider each problem on it's
own, and the solution for that problem on it's own, than it is to consider
what we are going to do about this huge mess. Try to remember that while
you have had your head buried in this stuff for a long time, the rest of us
likely haven't.
I don't really like to talk about security, it's not a thing I feel
qualified to talk about ... but, there is inconsistency in saying "we
should have a secure by default session module", and then introducing ini
settings that can vary the effectiveness of the solution, based on guesses
about the length, and speed at which elevators travel ...
Having another setting which seems to be 18 times longer than the
recommended value for "low security applications" is also extremely odd to
me ...
That you can't find sensible defaults for these values, says to me that
these problems don't have solutions in our domain; Application security is
a problem that can only be solved by the programmer using PHP.
We should provide the tools, we should not lie about the validity of a
session because of faults in our design, every layer we provide should be
consistent, but the problem still belongs to the programmer using PHP.
Cheers
Joe
On Thu, Mar 24, 2016 at 4:18 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> Hi all,
>
> On Thu, Mar 24, 2016 at 11:34 AM, Yasuo Ohgaki <yohg...@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
> yohg...@ohgaki.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
