> I don't think the proposal is useless nor ineffective. > Taint system is nice to have, but the proposal does not seem preferable > resolution. > Don't get me wrong. I agree with your discussion overall. > > I tend to dislike all or nothing choice for security related issues > especially, nonetheless > "nothing" is my choice this time...
Hi Yasuo, I can certainly see why you would choose not to... e.g. if magic quotes had not been implemented, I think things would have been better. But I think any one of these 3 proposals (or maybe something else) would provide very helpful information to developers. I don't think anyone wants to go down the "PHP fixes things automatically" route, as I've yet to find any kind of automatic system that works reliably... for example I hate tempting systems that try to "automatically" HTML encode values (good in theory, but personally I want them to complain when I get it wrong - so I can either fix it, or put something in place to say that this one is fine). But this is a technique that has been proven to work in static analysis tools... it's probably one of their main features (even if they will always find it hard to check properly - as the code itself isn't really running), whereas PHP can be doing these checks as the code is executed. What PHP does with this information is up for debate, I personally just want a simple log of things to fix... and I take Ronabop's point that maybe this should not be enabled by default, as so many developers are out there who will see it as an annoyance (at least until the feature is introduced to them properly). I've also added a couple of notes below. Craig On 12 Aug 2015, at 00:27, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > Hi all, > > On Mon, Aug 10, 2015 at 6:57 PM, Craig Francis <cr...@craigfrancis.co.uk> > wrote: > I have been reading your conversation with great interest. > > But I would urge you to see Matts suggestion as a simple addition to the > language (it's simpler than my suggestion), where his RFC seems to have > already addressed your concerns (and he seems to have a working proof of > concept). > > Personally I would like to see any one of these solutions being added to the > core language, as there are far too many PHP programmers making ridiculous > mistakes that the core language can be (and should be) identifying. That > said, I am still biased to my suggestion, which also tries to consider other > problems like XSS. > > But anyway... > > Take the code below, it is obviously wrong, but it executes without any > complaints, and unless someone is checking every line of code that is written > (note: PHP is doing so already), then the developer will just move on without > thinking anything is wrong: > > > http://php.net/manual/en/pdo.exec.php > $dbh->exec("DELETE FROM fruit WHERE colour = '{$_GET['colour']}'"); > > This is awful... It seems someone already fixed the doc. > Actually, this was me demonstrating what I've seen a couple of developers do before now... take the example from the documentation, then hack it to make it work as they want it to (without reading anything else on the page). > > > Over the years I've heard many people say things like "use static analysis" > or "prepared statements fix everything", but I don't think these are enough. > > I fully agree "prepared statements fix everything" is simply wrong. > > To be secure truly, secure API must split command and all others completely > _and_ command part must be programmer supplied constant/static/validated > string. > (i.e. Perfectly secure API must prohibit command injections at all) > Prepared statement does not satisfy both conditions. > > Many APIs, that are considered secure API, are not perfectly secure > because "command part must be programmer supplied constant/static/validated > string" condition is not checked. It's left to developers. > > e.g. execl/execv splits command and arguments, only single command is > allowed, > but if "command" is user parameter, it cannot be secure. > Fair point... but I think we should still support escaping (kind of necessary for HTML output). But Matt's suggestion works with your preferred setup, where the main SQL command is made up of constants defined in the PHP code itself (i.e. no variables from outside). So if we had a way to check the source of a variables content, then functions like mysqli_query() or a wrapper for shell_exec() can check that the main command has only come from string constants, anything variable related would be passed in separately. > You only have to skim read things like the second comment (with 27 up votes) > on the PDO prepare page to see that these problems are happening all the time: > > > http://php.net/manual/en/pdo.prepare.php#111458 > SELECT * FROM users WHERE $search=:email > > > So accept that education alone is not enough, and that the basic building > blocks like prepared statements or ORMs are not enough, and look at these > proposals and see how they will make the language better... because I can > assure you, having a simple tainting system that can be switched on to show > your mistakes, is considerably better than what we have today (i.e. > nothing... or maybe using some half baked / expensive static analysis tool). > > Or are you scared that this will highlight the mistakes you have made in your > own (probably over-complicated) code? as this is why I want this feature, > because I know I have made mistakes, and with OOP, it is very easy todo so > (abstractions like ORMs have a tendency to allow for these mistakes to creep > in extremely easily). > > I don't think the proposal is useless nor ineffective. > Taint system is nice to have, but the proposal does not seem preferable > resolution. > Don't get me wrong. I agree with your discussion overall. > > I tend to dislike all or nothing choice for security related issues > especially, nonetheless > "nothing" is my choice this time... > > Regards, > > P.S. There are many outputs other than SQL. Context aware automatic > escaping/use of > secure API/validation for various outputs would be nice to have. This would > be new API > and wouldn't help users shooting their own foot, though. I don't have > concrete idea now, > but PHP may have features help it. > > -- > Yasuo Ohgaki > yohg...@ohgaki.net >
