Ending Injection Vulnerabilities

Injection Vulnerabilities are still common - even with Parameterised Queries, ORMs, etc.

But, we can stop them completely, because:

You cannot have an Injection Vulnerability if the command (SQL, HTML, CLI, etc) does not include user data.

This is why Libraries must receive user values separately from sensitive strings, e.g.

$articles->limit('word_count > ?', $count); // Correct
$articles->limit('word_count > ' . $count); // Insecure (concatenation)

$template->parse('<a href="?">Link</a>', $href); // Correct
$template->parse('<a href=' . $href . '>Link</a>'); // Insecure (concatenation)

To do this, Libraries need Programming Languages to:

"Distinguish strings from a trusted developer, from strings that may be attacker controlled"

Mike Samuel, March 2019

This was explained in 2016 with Preventing Security Bugs through Software Design (Christoph Kern, Google Information Security Engineer). Also discussed at USENIX Security 2015 and OWASP AppSec US 2021.

The usual responses are:

How can we distinguish strings from a trusted developer today?

Programming languages need to have this concept built in (like Go and C++), because anything seen as optional (e.g. Static Analysis) will be skipped by many developers (who probably need this the most).

This approach will bring an End to Injection Vulnerabilities.