can you concentrate your last paragraph into a definite question? How is a modified string (splitting yields a different string) the same as the trusted one?

Thanks @MarcusMüller, I tried to keep it short, and made it much harder to understand... does the example and context help?

Well, as said, to me, quite obviously, anything that splits a trusted string based on anything that is not hard-coded but depends on data / input is a untrusted modification. Any other definition of "trusted" seems more than hazardous?

also, uff, that's a perfect example of PHP intending to do all the right things, and falling short of doing so by not sitting down and clearly defining what they're doing. Instead, the RFC tries to define behaviour by examples... sigh. PHP, will you ever learn? This is not hard to do "righter", by at least trying to formally define which operations are allowed and which are not. Passing as argument would be OK. Copying would be OK; concatenation would not be OK. and so on.

I think so too, and I think your comment a really nice way of putting it... while I'd like to give an example to prove that's the case, I think it's hard to come up with something that would be shot and realistic.

also. UFFF. PHP, could you PLEASE one day learn from your mistakes: Because so much existing code uses string concatenation (as noted by Benjamin Eberlei), and because it does not modify what the programmer has written, concatenated literals will keep their flag What. You found a prime source of injection, and you keep it, because it's such a commonly done pattern...

Erm... concatenating of literals is fine... it happens with SQL strings all the time, it's when the concatenation includes a non-literal string that you get a "prime source of injection"

Ha, so if you have one string with a prepared SQL statement (why keep that as string, to begin with? That's an anti-pattern, by the way.) for UPDATEing values and you compose a new string that might contain a different SELECT than developer-intended, that's not an injection? The SELECT thing might be useful in a different context, but chosen due to an unexpected case in an if clause handling user input

@MarcusMüller, btw, I'm happy to discuss in non-comments (I'm "craigfrancis" on Twitter, can use Zoom/GoogleChat/etc), I'm hoping to get the RFC ready for next week, and I'm a bit concerned that you're reading it that way.

hey, sorry for the harsh words; it's just that PHP every time I try to use it, bites me with design decisions :) I think your proposal is a step in the right direction, but please write out exactly what operations, as formally as possible, are allowed, and which aren't.

I think that if anyone uses such 'trusted' strings to avoid SQL injections, the security of the system will depend on all other code (what if someone eventually adds some 'exploitable' string somewhere else, and it can be used to build a payload?) (also, can trusted characters from many unrelated trusted strings be concatenated to obtain a trusted payload?)

@MarcusMüller I'm trying to finalise that list at the moment (why the question on splitting was raised, which I feel uncomfortable including, but couldn't really prove why)

@thedefault. that depends on your definition of "trusted" or "tainted". For example, you can tag every object with whether its value is a result of environment/input/data or hardcoded (trusted), and once you combine a trusted object with any untrusted object, that property is lost.

Can you think of an 'exploitable' string... I'm going on the basis that the SQL should be written by the developer (aka strings from the PHP source code).

There is no way to say something is trusted (e.g. no untaint function)... I tried to explain that a few times in the RFC, because that would cause the issue you raise (it's why this RFC is not implementing a traditional taint based system, which does cause a false sense of security).

Hm, thinking of this: string1="UPDATE t1 SET role='admin' WHERE privilege=(", string2="SELECT MAX(privilege) FROM t1", string3=");", something_else=0. In that case, you want string1 . string2 . string3, but you might do string1 . something_else . string3 instead. I think if(GET['foobar']) middle_string_in_a_query = foobar is a common pattern

But the order those strings are concatenated will still be done by the programmer? so unless the programmer intentionally writes them to be joined in an evil way (they wrote that code), it's not going to be an issue, is it?

@CraigFrancis A ' character is probably such an 'exploitable' string, if it can be concatenated with other trusted strings (and string concatenation normally is not a vulnerability). And if no user-controlled data at all is required to build a SQL statement, it is essentially a constant string.

@thedefault. Just checking... if you had $sql = "'"; that's a literal, but it would be down to the programmers code to incorporate it in weird ways, all under the programmers control... so yeah, I think it is essentially a constant string, and safe (from injection vulnerabilities)... but I want to make sure I've not missed anything that a programmer could realistically do, and cause an issue somehow.

@CraigFrancis if($_GET["action"] === "make_admin") { start_string=string1; middle_string=string2; end_string=string3; } else { middle_string="-1"; } if($_GET["datarequest"] === "least_user") { start_string_B = "SELECT * FROM t1 WHERE priv = "; middle_string="0"; } and finally execute_sql_query(start_string . middle_string . end_string); [some confusing code] execute_sql_query(start_string_B . middle_string . end_string);

@MarcusMüller, I think we're looking at two different things... I'm saying that a literal string is safe from injection vulnerabilities, I'm not saying it's safe in general... classic example, the command string 'rm -rf ?' is a literal, it's not vulnerable to injection issues (it does not include a user value, which would be correctly quoted by something that knows how to do that)... but it's not safe when the path gets get to '/'... and I think your example demonstrates that difference.

@tim, Thanks, I think that's about right, and while I would be surprised to see a developer do those specific examples, I suspect there are cases where the end of a string could be cut off as the developer intends, but by allowing an arbitrary value (what could go wrong?) it could cause issues (I'm still waiting for the person asking for it to give me an example where it would be useful).