OWASP Top 10 in 2021: Injection Practical Overview

OWASP A03 (Injection) covers diversified injection vulnerabilities and security flaws including SQL and NoSQL injections, OS command injection and LDAP query manipulations.

Views: 283k Read Time: 4 min.

SQLi is an attack used against web applications. The Open Web Application Security Project (OWASP) has, since 2003, published an ongoing list of the ten most serious web application attacks. Since 2010, injection attacks – including SQLi [CWE-89] – have been ranked as the #1 most serious web application risk.

Do you want to have an in-depth understanding of all modern aspects of
Injection?
Read this article and bookmark it to get back later, we regularly update this page.

What is it?

In general terms, an application is vulnerable to injection attacks when it is not properly equipped to deal with unexpected commands or queries. Any such application or code that accepts input from the user may be subject to injection flaws, allowing the user to inject malicious code via the user interface.

Injection vulnerabilities affect protocols used to retrieve data from a database or server, like SQL or LDAP. They can, however, be found in any language used to retrieve specific parcels of data or code, such as data nodes in XML documents via XPath and other XML parsers.

SQL vulnerabilities are by far the most common and most frequently exploited injection vulnerabilities because it is such a common language for database management. But, as OWASP’s web risks document says, “The concept is identical among all interpreters”.

SQL vulnerabilities are by far the most common and most frequently exploited injection vulnerabilities because it is such a common language for database management.

It is most common to see injection being used to maliciously access user data, such as identity details or the account password; but injection attacks are also capable of directly executing OS commands or introducing new code into a system. This could give administrative access to unauthorized new parties, or deny access to legitimate users.

The OWASP top 10 document illustrates how injection flaws are exploited, providing two examples of vulnerable code:

1. String query = "SELECT * FROM accounts WHERE
2. custID='" + request.getParameter("id") + "'";

1. Query HQLQuery = session.createQuery("FROM accounts
2. WHERE custID='" + request.getParameter("id") + “'");

The context for each example is different, but in both cases an attacker would be able to use a browser to modify the ‘id’ parameter. OWASP’s example:

The use of “id=' or ‘1’=‘1" creates an unexpected use of the database’s syntax, and would return details from all entries referred to by the “account” part of the URL, instead of a specific one.

Why is it bad?

The immediate impact of injection attacks and the goal of most attacks is to gain access to user data– as happened with the Heartland breach in 2008. While the exact numbers were not disclosed, it was for many years touted as the “largest data breach in history” and saw the personal and payment details of many customers compromised due to SQL injection attacks.

This should have been a wake-up call for the industry to pay much more attention to security in web applications, and it did prompt greater awareness of the need for app-sec, but not enough to prevent injection attacks being a persistent issue.

Regardless of the frequency of injection-based breaches, they can and should be preventable. Sometimes, injection flaws are discovered by researchers and closed by vendors. In September 2017, WordPress version 4.8.2 was released to patch a SQLi vulnerability via plug-ins. In February 2018, Joomla 3.8.4 patched a SQli flaw while SAP patches fixed two separate SQLi flaws.

Relying on a vendor to fix problems, however, is not enough – firstly because of an organization’s in-house software development, and secondly because of old flaws hidden in legacy code.

The TalkTalk breach is again a good example. The exploited flaw was in a legacy database inherited with the 2009 acquisition of Tiscali. It was too late for good coding practices, and there was no chance of a vendor patch.

But there was still no excuse. TalkTalk had a responsibility to protect its user data, and should have undertaken its own code review to find any vulnerabilities. This was the view taken by the UK’s data protection regulator (ICO). “Yes, hacking is wrong,” it declared,“but that is not an excuse for companies to abdicate their security obligations. TalkTalk should and could have done more to safeguard its customer information.”

"Hacking is not an excuse for companies to abdicate their security obligations."

The ICO fined TalkTalk £400,000 (80 per cent of the maximum then allowable) for failing to prevent its users from the effect of a SQLi attack. It is worth noting that GDPR has since dramatically increased potential fines. If the ICO fined TalkTalk 80 percent of the maximum allowable today (up to 4% of the annual revenue of £1,78 billion), that fine would be nearly £57 million.

Solutions

Injection attacks do not require great hacking skill. With just a browser and spare time, hackers can find vulnerabilities by simply playing around with an URL’s syntax. People with little or no coding knowledge can find and follow online tutorials, and there are plenty of automated tools for blind SQL injecting.

Fortunately, the low barrier of entry for injection attacks has a correspondingly simple solution in most cases: the proper testing and securing of any database and how it handles data queries. Use of a good API is essential, and controls need to be put in place to protect against mass-disclosure of data and the exploitation of special characters within the code’s syntax. It sounds complicated, but all of this can be achieved with proper modernization of databases and compliance with already-existing guidelines.

The most important part of protecting against injection flaws is diligence; OWASP recommends a thorough manual source code review and automated testing.

The most important part of protecting against injection flaws, however, is diligence; OWASP recommends a thorough manual source code review, and automated testing of “all parameters, headers, URL, cookies, JSON, SOAP, and XML data inputs”. The use of both Static and Dynamic Application Security Testing (SAST and DAST) tools, such as the ones incorporated into and used by High-Tech Bridge’s ImmuniWeb solution, is suggested to protect against any new vulnerabilities going forward.