OWASP Top 10 vulnerabilities: Injection explained
Hello and welcome to this OWASP Top 10 vulnerabilities course. Today’s blog post is about Injection.
By the end of this post, you will have understood the following points:
- What is OWASP Top 10 Injection?
- Why Injection is on the top of the OWASP Top 10 vulnerabilities?
- What is the difference between error and blind-based injection?
- OWASP Top 10 Injection flaws.
- How to exploit Injection?
- Some real-world Injection attacks
- OWASP Top 10 Injection prevention
What is Injection and why it ranks top of OWASP Top 10 vulnerabilities?
Injection sits comfortably on the top of the OWASP TOP 10 vulnerabilities for the last decade. This is for a good reason. In fact, injection is a broad class of vulnerabilities that you can find on pretty much any target. Let’s take the definition of the OWASP Top 10 for injection and analyze it:
Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or a query. The attacker’s hostile data can trick the interpreter into performing unintended actions.
I highlighted the key ideas in italic. The first thing to notice is that injection is not specific to a technology. In fact, any feature which expects and processes input is potentially vulnerable to injection.
The second thing to point out is how large the attack surface is. Tell me how many features you encountered which fall under this very scenario! I’d say most of them. In fact, even a simple search feature on a website takes your input, uses it as part of a command, queries a data store and returns the results to you.
Continuing on the example above, a malicious user can inject a malicious input, called the payload, to perform unintended results by the vulnerable system. If successful, the malicious user can trick the application into returning sensitive information, modify data or delete it altogether.
Error based injection vs blind Injection vulnerabilities
When hunting for Injection vulnerabilities, you will typically encounter two use cases. On the one hand, the application can return error messages which your payload triggered. In this case, you can follow the application errors for what to do next. For example, you can inject a malformed SQL query as simple as a quote and you get the following error:
"You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'WHERE id=''' at line 1".
This tells you a lot! First, you have successfully found a SQL injection. Second, the database engine is MySQL. Third, the application tells you the exact vulnerable part of the SQL query. Lastly, you’ve got a solid bug to report if you are a bug bounty hunter.
On the other hand, you don’t have direct and naive feedback from the application, but rather a hint, or nothing at all! In this case, we call it a blind injection. It requires more effort, but it’s still possible to exploit it as you can see in the OWASP Top 10 training injection blog post.
Now that you have a general understanding, let’s dive into some instances of OWASP Top 10 Injection flaws.
OWASP Top 10 Injection flaws
There are many subsets of the OWASP Top 10 Injection vulnerability class. Below you find most of them. The list is growing, so make sure to subscribe to the newsletter below so that you get a notification each Friday about new content.
SQL injection
SQL injection is a flaw in the way user data is being handled inside a SQL query. Basically, a developer concatenates the expected input directly into the SQL query. SQL injection is one of the most impactful vulnerabilities that exist, it can affect the confidentiality, integrity and availability. To learn more about SQL injection, feel free to read this in-depth SQL injection tutorial.
OS Command injection
OS command injection is a flaw in the way user data is being handled inside an operating system command. Basically, a developer insecurely puts the expected input directly into the OS command. OS injection is one of the deadliest vulnerabilities that exist in the realm of security vulnerabilities. It allows an attacker to have a remote shell on your vulnerable server. As of its impact, it can affect the confidentiality, integrity and availability. If you want to see a real example, read my write-up about how I found and exploited one.
LDAP injection
This injection is a flaw in the way user input is being handled inside an LDAP query. LDAP stands for Lightweight Directory Access Protocol. It is an client-server open industry standard which can be used to access and maintain directory information services. For example, it can be used to authenticate a user, search items, modify entries, etc. Therefore, this type of injection impacts the confidentiality, integrity and availability. You will learn more about LDAP injection in the upcoming blog posts.
OWASP Top 10 Injection attacks
The following are real-world breaches which exploited one of the injections discussed above.
SQL injection in Magento, patch published on March 2019
On its release, Magento urges its users to upgrade to the latest version of Magento. One of the severe vulnerabilities patched was a SQL injection.
CVE-2018-1111 – DHCP Client Script Code Execution Vulnerability
On its advisory on May 2018, RedHat announced that Red Hat Enterprise Linux 6 and 7 are vulnerable to a command injection flaw found in a script included in the DHCP client.
SQL injection against TalkTalk
The breach that affected TalkTalk exploited a SQL injection. Over 4 Million customers were at risk. More than 150K customers’ data was compromised and the company was fined 400K pounds.
OWASP Top ten Injection prevention
Since Injection flaws reside in the way user inputs are handled, a developer should never trust any input. If you do, you’re exposing your asset to security risks which can be damaging. For each of the OWASP Top 10 Injection vulnerabilities discussed earlier, there is a section on how to prevent them. But in general, this OWASP Cheat Sheet covers the guidelines you need to follow when writing your code. The main ideas are as follows.
- Perform proper input validation: You should sanitize and normalize your input.
- Use a safe API: For example, using an ORM is far better and secure than building SQL queries yourself.
- Properly escape your input: If you don’t have an API available, make sure to escape special characters according to the interpreter that will handle your command or query.
That’s it for today, in the next episodes of this OWASP Top 10 vulnerabilities tutorial, we will discuss OWASP Top 10 broken authentication. Stay tuned!