OWASP Top 10: Injection (A1:2017)

Photo by Sara Bakhshi
This is part of my OWASP Top 10 series that cover the top 10 most critical web application security risks. If you've missed any of the previous security risks, check out the intro and overview.
Risk Rating
Threat Agents
|
Exploitability
|
Weakness Prevalence
|
Weakness Detectability
|
Technical Impacts
|
Business Impacts
|
---|---|---|---|---|---|
Application Specific
|
Easy: 3
|
Widespread: 3
|
Easy: 3
|
Severe: 3
|
Business Specific
|
Average: 2
|
Common: 2
|
Average: 2
|
Moderate: 2
|
||
Difficult: 1
|
Uncommon: 1
|
Difficult: 1
|
Minor: 1
|
What is an injection attack?
Imagine there's a robot working in a factory. Its job is to move boxes around the factory; picking up boxes from one area and moving them to a packing area. This robot needs a set of instructions to follow so it knows which boxes to pickup and where to put them. Those instructions might be provided by its human manager through a form.
That form might look like this: pickup box from ____ move box to packing area ___, wait for next instruction.
The robot's manager might input the following data into that form: pickup box from aisle 4 move box to packing area 4b, wait for next instruction.
That's all well and good. But what happens if someone enters the following into the form: pickup box from aisle 4 move box to packing area 4b - then destroy the entire factory whilst singing I Wanna Dance With Somebody, wait for next instruction.
Well, we have a problem. No more factory. Oh, and a robot that won't stop singing I Wanna Dance With Somebody.
This example demonstrates an injection attack. Our machine (in this case, a robot) was given an untrusted input. That input was interpreted as a command, which ultimately altered the execution of the program.
Examples of injection attacks
In the real world, injection attacks can target any application that does not validate, sanitize, or filter user input. Some common types of injection are:
- SQL
- NoSQL
- OS command
- Object relational mapping (ORM)
- LDAP
- EL / OGNL
Let's look at an SQL injection example. The following code makes an SQL call:
String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";
What's going on here? Well, the code is basically asking the SQL engine to return all rows and columns from the table named accounts which have the column custID set as whatever's stored in the variable request.getParameter("id").
Let's say request.getParameter("id") contains the integer 7463 - which is probably what we're expecting. The SQL query will be:
String query = "SELECT * FROM accounts WHERE custID='7463'";
The result will be all rows from the accounts table that have 7463 set as the custID. It's probably just one specific customer. Simple.
But now let's place the value 7463' OR 1=1-- into request.getParameter("id"). The SQL query now looks like this:
String query = "SELECT * FROM accounts WHERE custID='7463' OR 1=1";
This will return all rows from the accounts table -- not just the one(s) matching custID = 7463. Why? The boolean logic OR checks if either statement is true. Since 1=1 will always be true, it will return all rows.
What's the impact of an injection attack?
As we saw in the example above, injection attacks can result in data leaks. A malicious user executing that SQL code will see all of our customer accounts.
However, the impact of injection attacks isn't limited to data leaks. They can result in any number of impacts such as data loss, denial of service, etc.
How to defend against injection attacks
Review your source code to check for cases where user input isn't being validated, sanitized, or filtered. Following code review, carry out automated testing of all data inputs (such as parameters, headers, URL, cookies, JSON, SOAP, XML, etc).
Both static application security testing (SAST) and dynamic application security testing (DAST) can help uncover injection vulnerabilities. These tools can be implemented into the CI/CD pipeline to identify newly introduced injection vulnerabilities before they're deployed.
More on OWASP Top 10
- OWASP Top 10: Intro
- OWASP Top 10: Injection (A1:2017)
- OWASP Top 10: Broken Authentication (A2:2017)
- OWASP Top 10: Sensitive Data Exposure (A3:2017)
- OWASP Top 10: XML External Entities (XXE) (A4:2017)
- OWASP Top 10: Broken Access Control (A5:2017)
- OWASP Top 10: Security Misconfiguration (A6:2017)
- OWASP Top 10: Cross-Site Scripting (XSS) (A7:2017)
- OWASP Top 10: Insecure Deserialisation (A8:2017)
- OWASP Top 10: Using Components with Known Vulnerabilities (A9:2017)
- OWASP Top 10: Insufficient Logging and Monitoring (A10: 2017)
Recent
Top 10 Web App Security Risks
-
OWASP Top 10: Intro
-
OWASP Top 10: Injection (A1:2017)
-
OWASP Top 10: Broken Authentication (A2:2017)
-
OWASP Top 10: Sensitive Data Exposure (A3:2017)
-
OWASP Top 10: XML External Entities (XXE) (A4:2017)
-
OWASP Top 10: Broken Access Control (A5:2017)
-
OWASP Top 10: Security Misconfiguration (A6:2017)
-
OWASP Top 10: Cross-Site Scripting (XSS) (A7:2017)
-
OWASP Top 10: Insecure Deserialisation (A8:2017)
-
OWASP Top 10: Using Components with Known Vulnerabilities (A9:2017)
-
OWASP Top 10: Insufficient Logging and Monitoring (A10: 2017)