Hi Stas, Thank you for your reply. I understand your view, yet I thought it's better to share your view with all of us.
On Thu, Feb 26, 2015 at 7:46 AM, Stanislav Malyshev <smalys...@gmail.com> wrote: > > I saw you voted "no". > > Could you share us the reason behind? > > I think I did, in my past messages to the list, but maybe I was not > clear. I will repeat in short: > > 1. I think this RFC does not provide any security improvement, due to > extreme ease with which the measures in this RFC can be circumvented by > the attacker. > It's secure by default. This RFC protects programs even with most obvious mistakes like include($_GET['var']);. Since this RFC is simple, there is no space is left being circumvented by attackers. 2. I think this RFC provides false sense of security for people that > create vulnerable code and lets them think it's OK to have variable > includes without adequate safety, since they are "protected" by these > changes. > This is not true. No security standards/guidelines discourage input validations regardless of protections existence. We already have NULL byte prevention and URI restriction for include/require, these mitigations neither promote false sense of security as all of these are "defense in depth". Besides, the protection can be disabled easily. Smart developers will never rely on it. 3. I think it causes significant BC break which might be warranted in > case it provides major improvement in security, but IMO in the light of > the above it does not provide even minor one. > BC is minor. Users can disable protections in various ways while vulnerability addressed by this RFC is the most fatal vulnerability. (Arbitrarily code execution is the most fatal) This is why I vote no and call everybody to do the same. We have simple and effective counter measure proposal against fatal security breach. Your reasons are not fatal reason to reject this. It could be hardly a logical choice. IMHO. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
