What is an Injection Attack?

This is a 4-part series:

In this post we are talking about injection attacks. As the name would elude, this is typically a scenario where data is injected into a query or a call, is not validated, filtered or sanitized by the application, thus resulting in unintended action from the application. This could be in the form of returning data in a query that should not be returned, causing the application to crash, or even inserting fraudulent data into a database or data stream. You get the idea, right? Overall it's a difficult type of attack to explain because there are many ways it can happen and different results that can be seen. There are however, a few notable Common Weakness Enumerations that I'll share in this post and I'll provide you with a simple example of one.

For this example, we're going to look at an example of a Cross Site Scripting (XSS) attack. To do this, I'll be using a deployment of the OWASP Juice Shop application. This is an open source web application that is intentionally insecure. You can obtain this application yourself if you wish to recreate what I'm showing here or to play around on your own with other vulnerabilities. Of course, I only recommend installing it in a lab environment that is isolated from production resources.

That being said, my server is up and running, as you can see below. Let's look at an attack.

First, we'll run the attack from the search box on the GUI. The following animated GIF shows the attack in action. What we are doing here is entering a bit of JavaScript code in the search box of the web UI. This causes the browser to display an alert rather than a search result.

As you can see in the above animated GIF, we get a nice alert pop-up with the text we entered. This is not supposed to happen. We shouldn't be able to interact with the page using the search box in this way. What you are seeing here is a DOM XSS attack.

Next, lets formulate the attack from the command line using the curl command. When I run the command, I'll run it against the URL of the Juice Shop application and I have created an environment variable using the command export JUICESHOP_URL=<Your Juice Shop URL>.

Let's run a similar command to initiate an XSS attack.

And the result is that the page was served as seen below. Nothing blocked. Attack successful.

Remember, this is just one simple example, however there are several CWEs that involve scripting attacks of other sorts. So how can we prevent attacks like this? Let's look at one solution.

As far as prevention goes, I'm not going to give you the definitive guide. The intent here is to simply show you that attacks like this exist, they are on the OWASP Top 10, and can be mitigated in many cases by using the right tools. For the example I provided here, I'm going to use a AWS WAF and deploy the simple managed rules.

With those core rules in place, we should have some protection against XSS. Let's try the same attack again.

In the above output, you can see the "Request blocked" notification was returned. We now have protection for our server against XSS attacks.

I've said it throughout this series, but I'll say it again: this is not meant to be an exhaustive list of attacks or prevention mechanisms. Instead, the hope is that it spurs a bit of thinking on anyone reading this. Trying to keep up with every vulnerability, every CWE, every potential issue is quite a chore, however much can be accomplished by just having a sense for the common attacks and employing the tools available to establish a base level of protection. From there you can always get into the weeds with specific attacks that your organization is susceptible to. That's the fun part!