OWASP Top Ten Series: Code Injection
What is the vulnerability?
A Code Injection occurs when untrusted data is injected or manually entered into an input sent to an application or database. The untrusted data contains malicious code or input parameters that the target application is tricked into executing. This malicious code can often enable access to data that shouldn’t be displayed, or it can allow the calling of other external code that an attacker has full control over.
There are many types of Code Injection attack. These include Command Injection, XPATH Injection and LDAP Injection. However the most prevalent type is an SQL Injection. This is because SQL injection vulnerabilities are very easy to overlook and therefore common, plus the potential rewards for a malicious attacker are great. Such as ready access to sensitive data that further compromises system integrity. Oracle recently revealed survey results they sponsored from Unisphere Research (PDF Link) that showed 58% of Database Administrators agreed that databases are vulnerable to security issues.
Here is an example of a simple SQL Injection attack. A web site that has an SQL database backend needs to ask for a User ID, then use it in a SELECT command to return meaningful data to a user. The following code could be used to get the user input and then construct a query:
txtUserId = getRequestString("UserId"); txtSQL = "SELECT * FROM Users WHERE UserId = " + txtUserId;
If an attacker enters the answer below into an input field asking for the User ID:
234 or 1=1
Then the resulting SQL code that is constructed will be:
SELECT * FROM Users WHERE UserId = 234 or 1=1
This will always return True as 1=1 is true. So all data rows in the table that has user information would be returned when this SQL code is executed by the backend database engine. If the database table includes sensitive information then this will also be returned to the attacker.
Similar methods of exploiting this type of SQL input flaw also exist in situations were users aren’t even asked for input. One method exploits the common URL scheme used by the PHP scripting language that takes the form:
What happens if the URL above is modified to be:
https://www.mysite.com/index.php?row=1′ OR ‘1’=‘1
Again as with the direct user input this could be passed by the PHP processor to a database engine as a request that includes a query that asks for the results when 1=1. Which is always true, and could cause the database engine to return everything in the Table being queried.
These examples are simple. They are easily countered, but outline the techniques that a code injection can use. Sophisticated attacks will use more complicated code that tricks the application and database engine into executing.
How to protect against Code Injection attacks
Protecting against code injection should be part of all security procedures for applications and databases. Not just those that are exposed to external users on the Internet. Security threats can also come from within organisations. It’s even possible that a vulnerability could be triggered inadvertently if the wrong input is used with an application, allowing sensitive information to be displayed to people who shouldn’t see it. Patient records to unauthorised administrators in a health care organisation for example. It’s worth noting that PCI DSS 3.0 mandates that you implement safeguards against code injection attacks. So ensuring that there are procedures, processes and tools in place to guard against code injection vulnerabilities is essential for organisations that take VISA and MasterCard payments.
There are many tools available to help check for and guard against code injection vulnerabilities. Scanners to automatically check a site and report on known vulnerabilities are available. Developers writing applications that use popular web scripting languages and database engines can use known techniques that prevent the use of code injection techniques. OWASP produces a large number of security cheat sheets that cover scripting languages and the types of Code Injection attacks. All developers and system administrators should read these and use them as a starting point for ensuring that their applications and infrastructure deployments are using the current best practice in security.
It’s also vital that systems are kept up to date with the latest software versions for scripting languages, content delivery platforms and database engines. Security vulnerabilities and bugs are constantly being discovered and fixed. The 9th OWASP Top 10 vulnerability is related to exploiting known security holes in software systems. Including using known code injection attacks.
General network security infrastructure should be kept up to date as well. Firewalls, content checkers, anti-malware systems and Load Balancers should be running the latest software patches. Additional security tools should also be deployed and kept up to date. The KEMP Web Application Firewall Pack (AFP) for LoadMaster includes tools that continuously monitor traffic to application and web servers. It detects and counters known vulnerabilities, including those outlined in the OWASP top 10. The AFP pack is updated constantly by KEMP security experts so that vulnerabilities developers and system administrators may not have heard about are countered.