On Tue, Sep 18, 2012 at 7:19 PM, Stas Malyshev <smalys...@sugarcrm.com> wrote: > Hi! > >> Programmers haven't figured out how to use the 1-2 covering functions >> that already exist and you expect them to do it in userland code? > > I expect them to use libraries. I don't think anything that is written > in PHP means it's wrong and has to be rewritten in C.
The libraries and the frameworks are wrong. I'm serious too. Try finding just one that does Javascript escaping properly (if at all). >> Maybe we should ditch json_encode() tomorrow. I can do it in userland >> code too. PHP does a LOT of things possible in userland code. The >> argument I made in the RFC boils down to simply giving programmers a >> helping hand. They are writing insecure code because PHP isn't >> fulfilling that need for one of the most serious security risks in PHP >> today. Surely that warrants action to serve programmers? > > We already have basic functions that do that, and we have extension that > does that. If you need more, I'm not sure you should do it in C. If you > do just the same under a different name, I don't think it should be done > at all. Links? Last I checked, no, we don't already have functions for all of this. And those that do exist have insecure behaviour - I did link to the relevant article on htmlspecialchars() which details that with examples you can download from Github. >> encoding. That's 2 versus the list of flaws in htmlspecialchars() I >> blogged about (the link is in the RFC) and whatever might >> theoretically exist if PHP actually had Javascript and CSS options. > > I think the approach of creating third data filtering API (plain > functions, filter, and now this) in PHP core is wrong. I do not see why > the same functions can not be (in case of CSS) or already are not (in > case of most others) implemented in existing functionality. If the whole > question is that people don't know which one to use in which context, > creating an entirely new core API does not sound like a good solution to > me. The fact is that people neither know how to implement these safely AND do not know when and where to use them in their correct combinations. Security related code needs a lot of peer review. It's beyond the scope of the average programmer, barely within the scope of large frameworks but should be perfectly within PHP's scope to manage and have some level of confidence in its security while doing us all a favour by addressing a significant security risk in PHP applications. Paddy -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com Zend Framework Community Review Team -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
