3 ms·

Nothing wrong with _GET and _POST. The problem is that their elements have type "string" instead of "unsafe_string", so PHP allows them to be used as/with regul

Nothing wrong with _GET and _POST. The problem is that their elements have type "string" instead of "unsafe_string", so PHP allows them to be used as/with regular "safe" strings. Edit: Except of course that they're mutable, which is stupid. In an ideal world they wouldn't be global either; they'd only be available at the top level, and passed into the application's initialising function/object, but that's low on the priority list.

yuliyp 12y ago
what is an unsafe_string? Did you mean "non-literal string" instead?
- chriswarbo 12y ago
  > what is an unsafe_string? 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: 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.
- cygx 12y ago
  See http://en.wikipedia.org/wiki/Taint_checking http://en.wikipedia.org/wiki/Taint_checking

yuliyp 12y ago

what is an unsafe_string? Did you mean "non-literal string" instead?

chriswarbo 12y ago
> what is an unsafe_string? 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: 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.
cygx 12y ago
See http://en.wikipedia.org/wiki/Taint_checking http://en.wikipedia.org/wiki/Taint_checking