No. Differentiating between literal/non-literal strings would destroy our ability to abstract and perform equational reasoning (although that's already pretty limited in PHP).
If I want to write:
echo "Hello " . $_GET['name'];
I should be prevented. However, I should be allowed to do:
echo "Hello " . htmlspecialchars($_GET['name']);
This is easy to do:
- Make the contents of $_GET['name'] have a type that doesn't work for string operators/functions like "." or "echo".
- Make the escaping functions like "htmlspecialchars" only accept "unsafe_string" arguments and produce "string" return values. This forces unsafe values to be escaped, and prevents safe values from being double-escaped.
- If you like, go further with an "sql_snippet" type, a "html_snippet" type, etc. and specialise the escaping functions. However, most of those values should really be more structured (eg. HTML should be a DOM, SQL should be an AST, etc.) since performing general string operations like concatenation on these values doesn't really make sense.
If we used your literal/non-literal distinction, we'd need our escaping functions to turn non-literal strings into literal strings; which doesn't make sense.
A type I just made up.
> Did you mean "non-literal string" instead?
No. Differentiating between literal/non-literal strings would destroy our ability to abstract and perform equational reasoning (although that's already pretty limited in PHP).
If I want to write:
I should be prevented. However, I should be allowed to do: This is easy to do:- Make the contents of $_GET['name'] have a type that doesn't work for string operators/functions like "." or "echo".
- Make the escaping functions like "htmlspecialchars" only accept "unsafe_string" arguments and produce "string" return values. This forces unsafe values to be escaped, and prevents safe values from being double-escaped.
- If you like, go further with an "sql_snippet" type, a "html_snippet" type, etc. and specialise the escaping functions. However, most of those values should really be more structured (eg. HTML should be a DOM, SQL should be an AST, etc.) since performing general string operations like concatenation on these values doesn't really make sense.
If we used your literal/non-literal distinction, we'd need our escaping functions to turn non-literal strings into literal strings; which doesn't make sense.