Hacker News new | past | comments | ask | show | jobs | submit login

> 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)




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.


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


> 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.



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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: