3 ms·

> Security. Kill the _GET and _POST and _SERVER arrays and introduce a proper API that can be used to filter all incoming data. So, reinvent magic quotes? > k

> Security. Kill the _GET and _POST and _SERVER arrays and introduce a proper API that can be used to filter all incoming data. So, reinvent magic quotes? > kill save_mode, open_basedir and other acient concepts safe mode is already gone (removed in 5.4)

trebor 12y ago
I disagree with his opinion on open_basedir. When configured correctly your application never experiences a problem, and can only write to paths it is directly allowed to. This prevents a security breach from accessing the system's configuration files. Disable it when you're building a system-level configuration package, but use it for all consumer-grade web applications.
chriswarbo 12y ago
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

trebor 12y ago

I disagree with his opinion on open_basedir. When configured correctly your application never experiences a problem, and can only write to paths it is directly allowed to. This prevents a security breach from accessing the system's configuration files. Disable it when you're building a system-level configuration package, but use it for all consumer-grade web applications.

chriswarbo 12y ago

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