security | privacy | web dev

OWASP Top 10: Injection

Wednesday 1st July 2020. By Simon Bell

Reading time: 3 minutes
Tags: security, web development

Picture of an apple with lots of needles in it (to illustrate injection)

Photo by Sara Bakhshi

This is part of our OWASP Top 10 series of articles 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.

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
OWASP's Risk Rating Methodology

A1:2017 - Injection

Exploitability: 3
Prevalence: 2
Detectability: 3
Technical: 3

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 WH​ERE 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.

Picture of simon bell

Simon Bell

I'm a software engineer and cyber security specialist. I recently passed my Cyber Security PhD viva (subject to amendments) and I have a BSc in Computer Science. In my spare time I enjoy running, tinkering with the Raspberry Pi, and experimenting with redstone circuits in Minecraft.

This website is where I enjoy writing about security, privacy, and web development.

Connect with me at: SJBell.com

Join the Key Threat Community

Every Wednesday I share:

  • A roundup of important cybersecurity news stories
  • Summary of popular cybersecurity content from Twitter
  • The latest security, privacy, and web info from Key Threat
Up arrow Back to top