On Sun, Aug 02, 2015 at 10:43:03PM -0400, Eric V. Smith wrote:
As I pointed out earlier, it's not exactly str(eval(s)). Also, what's your concern with the suggested approach? There are no security concerns as there would be with eval-ing arbitrary strings.
This comment has been sitting at the back of my mind for days, and I suddenly realised why. That's not correct, there are security concerns. They're not entirely new concerns, but the new syntax makes it easier to fall into the security hole. Here's an example of shell injection in PHP: <?php print("Please specify the name of the file to delete"); print("<p>"); $file=$_GET['filename']; system("rm $file"); ?> https://www.owasp.org/index.php/Command_Injection With the new syntax, Python's example will be: os.system(f"rm {file}") or even os.system("rm \{file}") if Eric's second proposal goes ahead. Similarly for SQL injection and other command injection attacks. It is true that the same issues can occur today, for example: os.system("rm %s" % file) but it's easier to see the possibility of an injection with an explicit interpolation operator than the proposed implicit one. We can teach people to avoid the risk of command injection attacks by avoiding interpolation, but the proposed syntax makes it easier to use interpolation without noticing. Especially with the proposed \{} syntax, any string literal could do runtime interpolation, and the only way to know whether it does or not is to inspect the entire string carefully. Passing a literal is no longer safe, as string literals will no longer just be literals, they will be runtime expressions. Bottom line: the new syntax will make it easier for command injection to remain unnoticed. Convenience cuts both ways. Making the use of string interpolation easier also makes the *misuse* of string interpolation easier. -- Steve