> what is an unsafe_string?

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

Posted by chriswarbo on Oct 2, 2014, 4:49 PM

Tags

• hackernews (Other)

Related issues

• Not sure what you suggest to do.
• Why is this not yet published on the official website and why is there no CVE?
• The biggest problem with having an LLM do this, from what I've observed of at least frontier models, is that the way they are trained&#x2...
• The biggest problem with MOND is that it was hand-crafted with additional parameters simply to fit the data.
• (My comment is about detached houses).
• The biggest problem with this is that I can't run my company's own internal benchmarks against this API, because they will be trained int...