Ending Injection Vulnerabilities

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

But, there is something we can say about them:

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

Which 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)

This is why Libraries need Programming Languages to:

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

Mike Samuel, March 2019

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