The idea behind is_literal() is of good intention, but as they say the road to
hell is paved with good intentions.
The RFC proposes to add an internal "literal" flag to a string, the
is_literal() function, and nothing else.
Further the RFC states a vision to get "libraries to start using is_literal()
to check their inputs." Again, that comes from a great intention.
The problem lies with the fact that library developer who choose to disallow
non-literal strings will offer solutions when a use-case literally
(pun-intended) cannot produce a literal string.
Sure, most leading library developers will offer a solution, but many of the
long-tail library developers will not either because it will add scope and/or
because those library developers don't have to skill and/or experience to do so.
So what will those users of those libraries do when faced with a required to
only use literal strings? They will find a workaround so they can get their
jobs done. And that workaround is really simple:
function make_literal(string $non_literal):string {
$literal = '';
for( $i = 0; $i< strlen($non_literal); $i++ ){
$literal .= chr(ord($non_literal[$i]));
}
return $literal;
}
You can see it in action 3v4l.org <http://3v4l.org/> here[1] and for posterity
on gist.github.com <http://gist.github.com/> here[2].
Once developers start bypassing the is_literal() check then all those good
intentions will be moot, and many who think they are secure from injection
attacks will be vulnerable:
$sql = 'SELECT * FROM foo WHERE id=' . make_literal( $_GET['id']);
$result = mysqli_query($conn, $sql);
So what am I suggesting we do?
1. We postpone passing this is_literal() RFC until we have collectively
addressed how userland developers will be able to handle non-literals in SQL,
HTML, etc. when their use-cases require non-literals.
2. We could also go ahead and add the internal "literal" flag to a string so
that if someone wants to use it to write an extension to add an is_literal()
function in the mean time it would be available, but not yet standardized into
PHP.
Thank you in advance for your consideration.
-Mike
[1] https://3v4l.org/oCBp7#focus=rfc.literals
<https://3v4l.org/oCBp7#focus=rfc.literals>
[2] https://gist.github.com/mikeschinkel/b9abd4178db461568b813269bc936c18
<https://gist.github.com/mikeschinkel/b9abd4178db461568b813269bc936c18>
