When OWASP talks about injection flaws it's refering to flaws that allow for anything ranging from low impact issues (HTML injection) to critical bugs (SQLi allowing for dropping of table). Basically anything in between can also be mentioned here like LDAP injection, OS command injection, ... . These vulnerabilities all have one thing in common, their root cause. They all occur because developer pass unsanitised data from the user to an interpreter.
If you are a developer you've probably written some queries by now, these queries might sometimes take user input as well, for example:
SELECT * FROM PRODUCTS WHERE TEXT LIKE '%" . $_GET['q'] . "%';
This innocent looking line of code can mess up a lot if we don't sanitize the user input properly. A malicious user might enter a quote here which would interrupt the SQL statement and allow for the execution of user submitted queries. As you can imagine this is not something desireable and we have many different types of injection. Today we will be going over several of them and we will be looking at the from different viewpoints. We also need to note SQL injection is just a small part of this puzzel and we will go over command injection as well.
As a hacker, my point of view is going to be one of trying to rely on the fact that the developer will need to sanitize all my data and if they forget to do that at even just 1 point i might have a possible entry point for attacks. This is why my strategy as a test will depend very heavily on testing every single parameter that i see and and even the ones i don't see directly.
Since we can test for both SQLi and blind SQLi, this complicates matters. Blind SQLi is where the server will not return any values for us to process, we can only test this method by sending a query which is known to cause a delay but this has several issues that come along:
With this in mind, we will try to test every single parameter we can find for SQLi if we have a suspiscion of database queries being executed which we can control. A typical practical example you will find out there is SQLi on login and while this may happen on a pentest, it never does on a bug bounty target. That would just be way too obvious, we will have to look for those hidden parameters in javascript files, hidden form fields, waybackmachine and whatever else we can think of.
We typically test with a single and double quote
'"
When we see a SQL error, we will investigate further, either with tools like SQLmap.py or manually, though we have to note this does not work for blind SQLi.
A developer has a really tough job when it comes to SQLi protection, not only do they have to sanitize every parameter the user can control directly but they also have to think about indirect influence over their application. For example there might be batch jobs running that pick up files, the contents of those files often do need to be sanitized but that's not always easy.