API8:2019 Injection


API8:2019 Injection

Threat agents/attack vectorsSecurity weaknessImpacts
The threat agent/attack vector for the vulnerability type can be wherever we find an injection point, this can come from parameters, 3rd party service integrations, file imports, etc... . From my own personal experience i know that third party integrations are often a good place to start looking for these vulnerabilities because it's hard to get 2 or more teams to work together efficiently without good protocols in place.This issue type can manifest in several different ways, we can often see SQLi but lately graphQL has been coming up which is just as vulnerable to injection flaws. issue types like LDAP injection, OS command injection or any issue type with the word "injection" in it.This vulnerability is almos always one of the higher severities. Things like database leaks, authentication issues and even full system takeover can emerge from this issue.

What is Injection?

API's with the following properties are open to injection flaws:

Example Attack Scenarios

I can also draw from experience on this vulnerability type as i have and reported on it often. The form i prefer is SQL injections via the import feature and OS command injection from an unexpected source. Let's start with the SQL injection.

I found this issue while doing bug bounties on a private program and it happend because the developers did sanitise all the direct input very well, except they did not think to include the import functionality because the base of the application was built a year prior to building the import functionality.

Upload.csv looked like this: 

And while uploading i selected the comma as field seperator, this displayed a SQL error and from there on i dug in deeper.

The error was:
Expects paremeter 1 to be string, null given in /var/www/html/import.php
This made me close the query and start a new one of my own
';select * from users;--,',','

This made the application dump the entire uses table in an error message, that was enough for me to report this issue and collect my bounty.

The second example i have is a little bit less complicated, i noticed a parameter litteraly called "osParam" which seemed to have some flags in it, i rushed to start up burp suite intruder with a list of command injections i had prepared before and had a hit on the 9th request that burp suite made. The command seperate was a newline character '\n' and my ping command delayed the response.

index.php?osParam=\nping -c 10 

So i quickly tried a whoami, reported the result and awaited approval which cames 2 days later.

Preventive measures against Injections?

An example in php which is badly implemented and leaves the app open for things such as XSS 
		$id = $row['id'];
    $title = $row['title'];
    $des = $row['description'];
    $time = $row['date'];
This is how it's supposed to be done
		$id = htmlentities($row['id']);
    $title = htmlentities($row['title']);
    $des = htmlentities($row['description']);
    $time = htmlentities($row['date']);


This issue type is diverse and not always easy to automatically test, we have to keep a good overview of every endpoint, including the ones that are less obvious. Manual testing is still adviced to compliment the automated tests in areas where an automated test is falling short.

Taking every endpoint into account can be quite confusing as it includes finding all the hidden parameters as well. New API endpoints should already be added to the documentation and old endpoints should be indexed whenever possible.