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
