Introduction

Injection issues are quite interesting to me and are quite easy to exploit, and many a times (if not always), they can lead to quite severe consequences.

They can lead to RCE or XSS on the client side or some other obscure attack like Host Header Injection for instance. All in all, if you found an injection attack, chances are you might get your hands-on a big lottery, if you will.

But wait! I don't even know what Injections mean. How am I supposed to follow along?

Worry not, we've got you covered. Read this post: Injections for Dummies to understand Injection attacks quite well.

Why these posts?

I think it must be clear now that traditional web applications security is being matched up with the newer paradigm where APIs are ruling the world.

So the goal with these posts would be to share all you need to up your API Security game and develop a pentesting methodology.

If that sounds like something up your alley, then stick along with me and we will learn all the methodology for pentesting APIs.

Injection

This issue happens when there is some user-supplied data mixed with the commands for some interpreter by the backend API.

Now this could be quite vague but it boils down to the following things:

• User-supplied data being added in the database queries, or passed directly to the ORMs, XML/JSON parsers or server-side templates, or shell without proper sanitisation.
• Data coming from anything external (and possibly controlled by the untrusted entities) entering into any of the systems listed in the previous point.

Example Scenario

e-shoppe.com just released a new website and they are using postgres as the database and AWS Lambda as the API backend.

They ended up building a custom ORM because they feel that SQLAlchemy is too hard for their developers to learn (I really can't comment, please ask them).

Now the thing is: their custom ORM's code was vulnerable to SQL Injection and when I try to login to any website, that's what I hunt for.

The injection issue was not in the obvious login/signup forms but instead in the parameters passed to one of the APIs.

When I pass an empty quote, thinks break and I get back a 500 (Internal Server Error).

Ofcourse I then tried to supply a valid query returning a response and voila! page worked.

Now I know there's an injection issue, I use sqlmap just to make my job a bit easier, and get all the data. Credit cards, cash and what not ;)

And that's what Injections are: the vulnerability that's fun to exploit and gets you a lot of money ($$).

If you think that you understand the vulnerability in the above scenario, then read on. If not, then it would be quite helpful to learn about the vulnerability first. Else you will be missing on some things…

One great source that immediately comes to my mind is (you guessed it!) is the OWASP's crAPI.

Pentesting Methodology

Now you understand Injections well, let's see how can we hunt for this issue. And more importantly how can we escalate it!

Now depending on the application, what you would do is: Identify all the APIs that accept user input and pass it to some interpreter.

This would be the most important thing. Because once you know of such APIs then only we can move forward with the exploitation.

Exploitation

1. Find all such APIs accepting user input directly or indirectly. This is just a starting step, if you are able to filter APIs where this user input gets passed to some interpreter like a database engine, a shell, a JSON/XML parser or some template engine, then that's much better.
2. Now try sending payloads for testing different interpreters: Command Injection, SSTI, JSON Injection, XXE, SQLi, NoSQLi, etc.
3. You can even send polyglot payloads and see if you get back any indicators that would help you craft more specific payloads.
4. If any of the above 2 points give you a success, then well done, you have found an Injection issue and you are just 1 bug report away from that amazing bounty or the cool swag!
5. If the above things didn't worked or you atleast didn't gave the responses indicating the presence of such issues, then it's time to go blind! What I mean here is that for SQLi or NoSQLi, try sending payloads that would make the response delayed by 10–20 seconds, for command injections you can try sending a request to your Burp Collaborator / RequestBin / custom cloud listener, for instance or directly get back the reverse shell. This would indicate of any blind injections and ofcourse this is not the end all, it's just the beginning.
6. If nothing still worked, then don't get disheartened, there's a next issue that you can look out for — that is —Improper Assets Management, which is the subject of our next post.

Closing Thoughts

I hope that you now understand and are able to exploit Injection vulnerabilities right when you see one!

One important thing to understand is that be it the traditional Web Apps or be it the APIs, both paradigms suffer from this issue.

In case of Web Apps, it's quite prominent but in case of APIs its not that common. Not saying that it doesn't exists but it's less common compared to other issues that we have discussed so far, in this series.