A fair number of years ago, I had the “pleasure” of reviewing an application written in ASP. Unfortunately, it had over 2000 SQL injections. I do not know what happened to the company, which produced legal case management software, but it would have taken a great deal of work to re-engineer the code to be safe. Why then, some six years later are injections still all the rage?
Injections, are to put it in the simplest possible terms, are the simple result of intermingling instructions with potentially hostile user supplied data. This paradigm, although powerful, has failed. As Dr Phil says, “how’s that working for ya?”
So we have to move on. Luckily, this post is not all bad.
HTML injections
It’s becoming increasingly hard to ensure that output is properly encoded, especially as I18N becomes more popular. Will encoding data to be XSS safe be viewable to non-US readers? Hard to say. I’ve been working with Benjamin Field (or more precisely, I farmed out) the re-implementing the Microsoft AntiXSS library API to PHP. This is nearly done. Once it is ready, we’ll make it available.
However, I’m still worried as it’s not the simplest, default way to output. When the simplest way to output is wrong from a security stand point, mistakes will be made.
SQL injections
Seriously, we have the technology to stop these today. Both strongly typed parameterized queries (a.k.a bound statements) and most forms of ORMs and Active Record systems are SQL injection resistant. Stored procedures are mostly safe, but are at risk if a certain lack of care is demonstrated.
LDAP injections
Want to be someone else? It’s easy today. This is the great unexploited attack vector for *serious* applications. Toy apps don’t use LDAP, so most researchers do not concentrate on it. But you betchya that most large orgs and govt types have signed up for the “SSO magic bullet” and landed themselves with a LDAP shaped white elephant. They may not be even aware that they are running LDAP. It’s certainly not made clear in many of the marketing materials. How do architects who have never coded understand the risks?
Today’s LDAP code are eerily reminiscent of the SQL days of yore. Here’s a typical LDAP login method (I have worse, but for this I’ve borrowed from php.net’s manual page):
$ds = ldap_connect($ldaphost, $ldapport) or die(“Could not connect to $ldaphost”);
if ($ds) {
$username = “some_user”;
$upasswd = “secret”;
$binddn = “uid=$username,ou=people,dc=yourdomain,dc=com”;
$ldapbind = ldap_bind($ds, $binddn, $upasswd);
if ($ldapbind) {
print “Congratulations! $username is authenticated.”;
}
else {
print “Nice try, kid. Better luck next time!”;}
}
Yes, not only can you choose your location within the ldap tree, you can also do XSS if you’re clever.
XML
Don’t even get me started. Creating uninjectable XML functionality is a PhD in itself, and once it’s done, I doubt the resulting XML would be anywhere near as useful as it is today.
Injections will continue to occur to why the USA still has pennies and $1 bills: they didn’t remove the old form from circulation. This is the only solution: ensure the safer solution is available by default (and is the easiest method to use), and remove the old unsafe methods. Make it HARD or IMPOSSIBLE to do it badly.