Hi Stas, On Wed, Jan 27, 2016 at 8:49 AM, Stanislav Malyshev <smalys...@gmail.com> wrote: > >> I have >> https://wiki.php.net/rfc/dbc2 > > This doesn't seem to do anything with security. It's just a way of doing > asserts, which we already have.
It's a framework for secure programming. Using it is up to users, but DbC is proven method for writing sold(secure) code while maintaining the code execution performance in production. Assert is a weak tool for it. > >> https://wiki.php.net/rfc/secure_serialization > > This may be a viable extension of somebody really is going to use it. I > would suggest making a PECL extension. MHAC is also a proven method for message validation. Unvalidated inputs for serialize are source of vulnerabilities for a long time. I think it worth to provide it for all users. I see work in progress phpt for serialize vulnerability, why not provide secure way out of the box? > >> https://wiki.php.net/rfc/introduce-type-affinity > > This also has nothing to do with security, and also looks unfinished, > not clear what is sought and what is the benefit. It related to secure programming. Validating inputs and use of proper types is basic thing in secure programming. Type affinity helps this. > >> https://wiki.php.net/rfc/script_only_include > > This one we already discussed at length, and the vote result is clear. It may be. However, easiness of code inclusion in PHP is one of the weakest point that is unique to PHP. I'm not sure how it goes, but I shall try. > >> Three RFCs for session is just too much for me already... > > Maybe we should concentrate on doing one specific thing, bring it to > conclusion and then get to the next one? I would like not to start discussions for these RFCs now. Fine for me. > >> Anyway, we may be better to talk about how it should be. >> For this thread, how session management should be. >> It's just not good enough currently. Besides exploiting >> PHP session is too easy, random lost sessions is not > > I am sorry, but I still see no base to this claim. You seem to be under > impression that stealing cookies from HTTPS connection is trivial, but I > do not see how it is. Moreover, since virtually all secure communication > over the web relies on this, if it were trivial, no secure communication > would be possible, and I don't see this happening. I'm not saying stealing session cookie from HTTPS is trivial. It could be trivial with certain environment, though. Other than HTTPS, setting unremovable cookies is easy with JavaScript vulnerability. Currently, we only has session.use_strict_mode=1. This is not good enough because attacker can generate valid session ID by themselves, and set it to victims cookie. Without session ID regeneration with precise expiration, attacker may keep logged in session forever. > If, however, HTTPS/cookies are secure, then I don't see how exploiting > PHP session in current state is easy. There may be some browser bugs > that make some scenarios not work sometimes, but so far I don't see any > problem that were bigger than light annoyance. Described how easy to steal session permanently above. Without this proposal, user/web site owner will never know possible security breach. With this proposal, user/web site owner can detect it by raised errors for access to expired sessions. > >> acceptable. Weak defaults are not acceptable also. Let's > > There are a lot of different use cases for PHP and session, and the same > requirements do not apply to all of them. So in my opinion, the defaults > should cover the most common cases, and avoid breaking applications as > much as possible. Other than restricting chars for session_id(), this proposal will not break application. Other possible minor BC happens when apps rely on constant session ID. Relying on constant session ID is _bad_ practice, but the patch allows to disable automatic session ID regeneration for better compatibility. Tests for session behavior may be affected, but it will not affect production code. Other than these, user should not have problems in their production codes. If any, please let me know. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
