Injection attack remains at the A1 position on the latest 2017 OWASP Top 10 list of most prevalent security threats for web-based applications. It is straightforward to exploit on systems that are vulnerable, and as a result, attacks using it are common. The effects of a successful attack can be severe due to data loss and damage to an organizations reputation. Protecting against injection vulnerabilities is relatively easy as long as organizations follow security best practice.
An injection attack 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 executes. This malicious input often enables access to data that shouldn’t be displayed, or it can call external code that an attacker can use to compromise a web application in additional ways.
There are many types of injection attack such as SQL, NoSQL, OS command, Object Relational Mapping (ORM), LDAP, and Expression Language (EL) or Object Graph Navigation Library (OGNL) injection. The concepts for each type are identical with just the attack methods for each varying based on how they accept inputs.
The most prevalent injection type is an SQL injection as they are very easy to overlook and therefore common, plus the rewards for a successful attack are plentiful. Such as access that further compromises system integrity or access to complete database tables full of sensitive data.
Here is an example of a simple SQL injection attack. A website that has an SQL database backend needs to ask for a User ID, then use it in an SQL SELECT command to return meaningful data about that 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 constructed is:
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 Users table would be returned when the backend database engine executes this SQL code. If the Users 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 where users are not even asked for input. One method exploits the common URL scheme used by the PHP scripting language that takes the form:
https://www.mysite.com/index.php?row=1
However, 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. This is always true, and this input could cause the database engine to return everything in the database table.
These examples are simple. They are easily countered but outline the techniques that an injection can use. Current injection attacks use more complicated methods that trick the application and database engine in more sophisticated ways.
Protecting against injection attacks should be part of all security procedures for applications & databases and not just for those on the Internet. Security threats can also come from within organizations. It is 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 should not see it. For example, patient records being shown to unauthorized administrators in a healthcare organization. It is worth noting that PCI DSS 3.2 mandates that you implement safeguards against injection attacks. So, ensuring that there are procedures, processes, and tools in place to guard against injection vulnerabilities is essential for organizations that take credit card payments.
The primary process that should be taken to guard against injection attacks is to perform comprehensive code reviews. These will highlight many injection attack vulnerabilities. There are also many code scanners and automatic testing tools available that can check code for injection and other vulnerabilities. Developers writing applications that use popular web scripting languages and database engines can use known techniques that prevent the use of injection attacks. OWASP produces a large number of security cheat sheets that cover scripting languages and the types of injection attack vulnerabilities they have. 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.
If possible web applications should be written to use a safe API that avoids the need for an interpreter to parse input parameters. If it is possible to whitelist the sources that inputs are accepted from then this should also be considered. Most database engines have built-in commands that stop the mass viewing of complete table data without extra steps that specifically request all the data. These commands, such as LIMIT or TOP, should be used in SQL queries that take parameters to help prevent the complete return of tables of data, either accidentally or maliciously.
It is also vital that systems are kept up to date with the latest software versions for scripting languages, content delivery platforms, and database engines. 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 continuously updated by KEMP security experts to protect against vulnerabilities that developers and system administrators may not have heard about.