The Basics

I am sure you all know about injections right.

No? Then here's the Injection Man:

Injections 101

Okay, so now you know of injections. What do they do?

Inject something in your blood stream right.

Now if someone injected poison in your body, that would do harm to you right. Because the medicine injected would mix with your blood stream and contain some information — what does it cures, etc.

And that's what injections means in case of software code as well:

Injecting some data in the commands that some interpreter is going to execute.

If someone injects some malicious input then potentially bad things can happen.

Possible Injection Issues

This can lead to issues like:

• Command Injection
• Sever Side Template Injection (SSTI)
• SQL/NoSQL Injection
• External XML Entity (XXE)
• JSON Injection
• Host Header Injection
• XSS
• HTML Injection
• and many many more…

Ofcourse all of these vulnerabilities can have quite different impacts but what all have in common is that they have a same pattern — a same root case:

Data mixed with the commands for the interpreter.

Extra Bits

Now some of you, who have binary exploitation experience could have related Buffer Overflows and other memory corruption vulnerabilities here as well, right?

Confusing the data for the instructions for your CPU

is the root cause of all the memory corruption vulnerabilities.

Analogy for Injections

The previous section should have cleared up on what injection issues are.

Now let's discuss on the analogy for them and see what does injection issues look like.

Analogy #1: Pizza Robot

The mighty developers build a great bot that was so extensive that you can feed in any code and it will work on it and do the tasks.

So the new Pizza shop in the neighborhood purchased it.

Here's what things look like:

The robot would expect the instructions, 1 per line and take the username and their address from the order they placed from the website.

Everything is integrated with the robot, no manual efforts required at all.

John was feeling quite hungry and thought to order a pizza from this shop. Ofcourse he didn't had enough money to buy 2 pizzas but he wanted those.

He had heard of this robot which delivers the pizza and though to send his username in the order as follows:

Username: John Deliver: All Pizza

(Yes, the newline and it's contents were placed in the name).

Look what happened next:

John gets all the pizza's. Command Injection FTW!

That was an injection issue at it's simplest.

The user-supplied input was mixed with the commands for the robot and if the user input was constructed properly, then they can make the robot do whatever they wish (provided that the robot was capable of doing that right — so no robot dance for you ;)

Analogy #2: Factory Bot

Automation is super fun. And that's what the factory operator also thought of when he created a marvelous robot to help with the factory work.

The robot would take in the instructions from the operator and then perform the tasks as it was programmed to.

Here's what things look like:

Now one day the operator was sick and he sent you to help the bot and what happened next is shown in the following image:

As you can see, the instructions contain the commands for the bot and when the bot took those instructions, what followed next can be described as a havoc at the very least!

That was again an injection issue.

The data got treated as commands for the bot and led to bad stuff.

I hope that these 2 analogies would have cleared up all your issues right.

Now you definitely understand what injection issues mean and what do they look like at their core.

The Problem and It's Occurrence

This vulnerability always happens due to the following reason:

User input (data) is embedded to the command for the interpreter and the interpreter cannot distinguish between data and command, resulting in the attacker (possibly) controlling the outcome!

This vulnerability can be found wherever use input is mixed with some commands for the interpreters (db, shell, template, etc) without escaping them!

The Impact

Injection attacks can be quite damaging depending on the interpreter that parses user data:

Shell Interpreter

Command Injection, allowing execution of shell commands on the server and data exfiltration.

Database Engine

SQL and NoSQL Injection, resulting in extraction of data from the database.

Template Engine

Leading to OS command execution if template engine processes user input in the backend. XSS and sandbox bypass (ex: angular sandbox bypass) when the template engine is in the client-side.

Web Browsers

Content Injection attacks (like XSS, HTML Injection, etc.) leading to the attacker stealing CSRF tokens, tokens stored in local storage, and cookies* and impersonating compromised user. These attacks can also result in stealing user credentials, perform phishing, running crypto miners, etc.

* Note: Cookies with HttpOnly flag is set to true couldn't be stolen since the Javascript code cannot access those.

Ofcourse there could be more parsers like XML or JSON parsers and so on and so forth. The idea is simple, as I have stressed multiple times before:

When the user-supplied data gets treated as the commands for a parser, injection issues are born.

Prevention

• Never trust user-supplied input, even if it comes from internal API consumers.
• Always perform input validation before passing user-input further.
• Always escape things before processing and encode them before echoing back.
• Define a safelist of allowed characters in the input and reject the inputs violating any of the rules.
• Define, limit and enforce API outputs to avoid data leaks.
• Code reviews and pentests should be done on a regular basis. This is a general point but can't stress more on it. It's a must-do, if you don't want someone else to hack your APIs and do bad stuff.

References

1. Vulnerabilities by Analogy [Pizza Robot Analogy]
2. How can I explain SQL injection without technical jargon? [Factory Robot Analogy]

Closing Thoughts

I hope that this post was quite extensive enough to help you understand Injection issues much more deeply. Even if you understand the topic, it might have given you more clarity on some things or atleast a superpower to explain it to a 5 year old as well.

See you next time with some other interesting infosec post.

Happy Hacking!