One topic we discuss in Learning Tree’s System and Network Security Introduction and Defending the Perimeter from Cyber Attacks courses is “code injection.” I wrote a bit about this four years ago, but I want to provide more detail as these attacks are not going way as quickly as we thought they might.
Wikipedia defines code injection as:
“…the exploitation of a computer bug that is caused by processing invalid data. Injection is used by an attacker to introduce (or “inject”) code into a vulnerable computer program and change the course of execution. The result of successful code injection is often disastrous (for instance: code injection is used by some computer worms to propagate).
Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code. They are often found in SQL, LDAP, Xpath, or NoSQL queries; OS commands; XML parsers, SMTP Headers, program arguments, etc. Injection flaws are easy to discover when examining code, but frequently hard to discover via testing. Scanners and fuzzers can help attackers find injection flaws.
Injection can result in data loss or corruption, lack of accountability, or denial of access. Injection can sometimes lead to complete host takeover.”
Let’s look at a simple injection example similar to one I use when I teach 468 (and similar to one in Wikipedia’s article). Consider a website that asks for a product review. A malicious user could write a review containing the following little script if the site were not well designed:
That script would then be executed when someone reads the review. The browser would then pop up a little window with the “Gotcha!” message. Of course, the attacker could do something potentially more dangerous. The attack could set cookies for her own site or cause information about the user to be sent to a third site.
If, for example, the site asked for a name, and the user entered some malicious SQL code in the name field, a poorly designed site could execute the script.
Name: Mary ;drop table users; Smith
Fortunately, these types of injection attacks are easy to defeat. The first step is to validate the input. Some sites, for instance, allow markup of comments (e.g. allowing italics), but use square brackets (‘[‘ and ‘]’) instead of the angle brackets used by HTML markup. That way it is easy to detect and remove the HTML markup or block the post.
SQL injection attempts can also be defeated by examining the input data. No reasonable name should have semi-colons in it (and my grammar checker pointed this out!). Additionally, script writers can “prepare” SQL statements so the input would be put directly into the database and not processed by the SQL engine. That, combined with sanitizing the input, provides significant protection against the injection.
Virtually all scripting languages used on the web are subject to injection attacks. Some (e.g. perl) treat input data specially, so the programmer is strongly motivated to sanitize it.
It is difficult to believe that an attack that is so easy to prevent is so prevalent. It shows that programmers are still not learning how to code securely. Test your sites for injection vulnerabilities. Help your programmers learn how to secure their code. And let us know in the comments below your thoughts about preventing injection attacks.
To your safe computing,