Injection vulnerability: The big picture
Hello and welcome to this OWASP Top 10 vulnerabilities course. Today’s blog post is about Injection.
Download your own Web hacking LAB: https://thehackerish.com/owasp-top-10...
Blog post: https://thehackerish.com/owasp-top-10...
Follow us on Twitter: / thehackerish
Facebook Page: / thehackerish
By the end of this video, 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
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.
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.
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.