Hi, I'm looking at creating an RFC to address security issues that relate to poor string handling / escaping, such as SQL-Injection, XSS, etc.
Considering these are still major issues on the OWSP Top 10, we need to do more to mitigate them. For example, an inexperienced programmer can easily create an XSS vulnerability with: echo '<p>Searched for: ' . $_GET['q'] . '</p>'; I'm proposing that we extend the error_reporting of E_NOTICE, so that PHP itself can tell the developer when they have made a mistake. And this will work well with existing SQL prepared statements, ORMs, templating systems, etc. -------------------------------------------------- So PHP assigns a "type" to every string (this must be done by PHP itself, "value objects" still allow mistakes). This defaults to the "plain" string type... for example, values that come from GET/POST/COOKIE, the database, file_get_contents(), etc. When a string is passed though htmlentities(), the returned string has a "html" type. When a string is passed though pg_escape_literal(), the returned string has an "sql" type. There are more :-) --- When an "sql" string is concatenated with an "sql" string, it would result in an "sql" string. When a hard coded string in the PHP script itself is concatenated with an "sql" string, the result is an "sql" string. But if you concatenate an "sql" string with a "plain" string, then PHP will raise a Notice. --- Then functions such as mysqli_query() can test the provided string type... e.g. a "plain" string can raise a Notice. This could extend the PHP7 scalar type hints, so methods could check the string types as well. And likewise, anything that is sent as output (e.g. echo/print) would be tested against a configurable output type, which defaults to "html". -------------------------------------------------- There are a couple of edge cases (with solutions)... but does this interest anyone? Craig -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
