Hi Steph, > > In a preliminary release for feedback purposes you talk about wrong > assumptions? Surely this is the whole point of having a preliminary > release for feedback :) yes of course it is preliminary. But the whole idea is flawed. It is assumed that a single function exists that makes user input secure for HTML or for SQL. But infact there is not.
There exists a wide number of possible contexts like 1) SQL: Inside a SQL string 2) SQL: Inside a SQL table name 3) SQL: Inside a SQL field name (uncommon) 4) SQL: Inside a SQL comment 5) SQL: Where a numerical id is expected 6) ... possible others All these different contexts need another way of preparation/escaping. What kind of handling is actually needed can only be found out by parsing the query and knowing what bytes are tained. This cannot be done if you only use variable level tainting. If you look at HTML it gets even more complicated because you have many more possibilities like 1) HTML: Outside of a TAG 2) HTML: Inside a TAG 3) HTML: Inside an attribut of a style tag 4) HTML: Dangerous URLs in attributes 5) HTML: JavaScript between <script> tags 6) HTML: JavaScript inside a JS String 7) .... That said the implicit untainting by use of mysql_real_escape_string() and htmlentities() is simply not feasible. Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
