Hi Matt, Am 06.08.2015 um 05:46 schrieb Matt Tait: > With regards to the fact that not all SQL queries are directly > parameterizable, this is true. Structural parts of a query, such as table > names, column names and complex conditions are hard to parameterize with > "vanilla" prepared statements, and many developers like to abstract some of > these structural parts of a SQL query into config files, and append > additional conditional constraints into the query at runtime based on user > input. > > This feature addresses this head on. So long as the structural parts of the > prepared statement -- that is, table names, database names and column names > -- are not themselves attacker-controlled (I can't think of a valid reason > whey they would be), this feature is happy for developers to concatenate > them into a query string. For example, the following is not detected by the > feature as dangerous, because the query (whilst dynamically constructed) is > the linear concatenation of string literals, and so is a safeconst.
and how exactly do you guarantee the structural part from a configuration is not attacker-controlled? The config may come from a json file, from a database, from APCu, etc. and may have been inserted/generated previously from unsafe user input. If I understand you right, these parts will not be tainted and thus will give a wrong feeling of safety to the unskilled/unknowing programmer. Or did I miss that part in the RFC? Greets Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
