Hi Pierre, On Wed, Oct 19, 2016 at 9:52 AM, Pierre Joye <pierre....@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 yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
