Testing for Injection Vulnerabilities

Before you can inject a payload using an API, you must uncover the best requests to attack. The best way to discover these injection points is by fuzzing and then analyzing the responses you receive. I have mentioned fuzzing before, but you should have a strong understanding of what is meant by this. Fuzzing APIs is the process of sending various types of input to an endpoint to provoke an unintended response. The payloads used for fuzzing include symbols, numbers, system commands, SQL queries, NoSQL queries, emojis, hexadecimal, boolean statements, and more. Essentially, you want any payload that the API may not be programmed to handle to cause the API to send a verbose response or to cause the application to behave adversely. If an endpoint does not sanitize or validate user input then the right payload could cause a verbose response, a delay in processing time, an internal server error, or an error with the database.

You should attempt fuzzing against all potential inputs and especially within the following:

• Headers.

• Query string parameters.

• Parameters in POST/PUT requests.

Your approach to fuzzing should depend on how much information you know about your target.

If you’re not worried about making noise, you could send a variety of fuzzing inputs likely to cause an issue in many possible supporting technologies. The more you know about the API, the more you can focus your attacks and increase your chance of finding a vulnerability. This is where your reconnaissance efforts will really pay off. If you know what database the application uses, what operating system is running on the web server, or the programming language in which the app was written, you’ll be able to submit targeted payloads aimed at detecting vulnerabilities in those particular technologies.

After sending your fuzzing requests, search for responses that contain a verbose error message or some other failure to properly handle the request. In particular, look for any indication that your payload bypassed security controls and was interpreted as a command, either at the operating system, programming, or database level. This response could be as obvious as a message such as “SQL Syntax Error” or something more subtle like taking a little more time to process a request. You could even receive an entire verbose error dump that can provide you with plenty of details about the host. As we know from working with crAPI throughout this course is that if you find a weakness in one endpoint, chances are that weakness is present in other endpoints. So when a request from one endpoint reveals a useful detail make sure to leverage that information in requests to other endpoints.