Go and Java have "compile time constants", and JavaScript will soon get a feature that allows "Distinguishing strings from a trusted developer from strings that may be attacker controlled" via isTemplateObject.
These allow the program to check if a variable contains a string that came from the source code (i.e. a literal).
This is useful, as it allows you to be sure a variable cannot cause an Injection Vulnerability.
For example an SQL string, where the user values have been kept separate (parameterised queries).
In theory, combining literals should be fine (think of a programmer building up an SQL/HTML/CLI string).
But, if the attacker was given the ability to extract an arbitrary part of the string, or some way of using split() to convert the string into an array... is there any way this could cause issues, and undermine this valuable distinction of "strings from a trusted developer".
For example:
$my_literal_html = '<a href="?">Example<a>';
This by itself cannot contain an injection vulnerability (does not contain user data).
We could even append more HTML to it, and it will also be fine:
$my_literal_html .= ' <em>Text</em>';
At this point we would send it to a HTML Templating Engine, which could check that it's a literal... then it's free to incorporate the user supplied values (using the appropriate encoding, and context checking, like preventing 'javascript:' URLs).
But, is there anything the programmer could do, which could inadvertently break this... to take their literal, split/cut/substr it, still be seen as a literal, but also introduce a security issue.
Maybe $length could be attacker controlled (for some reason)?
$start = 0;
$length = ($_GET['length'] ?? 9);
$my_literal_html = substr($my_literal_html, $start, $length);
That would result in the string '<a href="'... which I think is still fine, but in a larger program, could issues be introduced?
For reference, I'm writing the is_literal RFC for PHP, it will allow libraries to check certain input strings came from the programmer, and it does support concatenated strings... but a question has come up about splitting strings, I don't think it's useful (can't think of why anyone would), but I'm also concerned it could undermine the security value.
