Threat Analysis

Welcome to the injection flaws session. In this first part, we will focus on threat analysis. We will take our time to dig into injection flaw details. Then we will discuss how the system can be harmed, the impact of successful exploitation, and give you some insights to identify who may want to harm your system. Injection is a very broad concept. No better place to look for a definition than in the dictionary. Unfortunately, we don’t get that much here, but keep in mind that we’re talking about something that is injected. And so we need a place where to inject. Let’s see what the dictionary still has to offer following some links.

Following the link in the inject word, we get something far more interesting. What is injected, is something arbitrary or inappropriately. In app tech, this inappropriate something is called payload. In the next few minutes, we will do our way to find what is this something and to find a place where to inject it. We have discussed the world wide web architecture before. But now I want to look at it from another perspective. In the image we call server to the whole infrastructure required to satisfy client requests, including web application firewalls, HTTP servers, backend and database servers, and even third party services. Note that data flows through all these systems, back and forth, to satisfy client requests.

The server is a business asset in the right place to keep valuable data such as the user database, health records, financial data, et cetera. Direct access to the server is expected to be reserved to authorized parties, and attackers are not supposed to be one of them. If attackers cannot directly access the server, nor the data, then the best they can do is behave like a regular client. Of course, they won’t get the gold from your server if they are well-behaved. A traditional login feature is something implemented by the backend server which requires user input, email and password provided by a client, and the database record that matches the provided data, if any.

To get unauthorized access to the system when requested to login, instead of a valid email address, attackers will provide something inappropriately, but not arbitrarily. They will provide a special crafted input, which will compromise your backends or database servers. We will explore this attack scenario in detail. How did an attacker get access to the system using inappropriately something other than a valid email address? What payload would do it? First, let’s have a look into the database table where authentication credentials are stored. There are several types of databases. Our application uses the relational database management system with SQL support for data management. This is how an accounts table aimed to store authentication credentials would look like. This is an oversimplified example.

Nevertheless, this is what we find quite often on vulnerable applications. Note that passwords are not the actual secrets but their hash. If you are not familiar with the hashing concept or with password storage, please read the OWASP password storage cheatsheet following the link below. To retrieve admins records, we need to send the following SQL query to the database. If we get exactly one record, then the account exists and the credentials are okay. Otherwise, the email address does not exist in the database or the password is wrong. Again, this does not comply with the best practices, but it is quite a common pattern found on vulnerable applications.

This is how it works for the admin account, but as a feature, email address, and password can’t be hard coded. And they should take arbitrary user provided values. This is a template for a generic query that will work for any user provided values. What’s enclosed within square brackets should be replaced on every login request with provided data. And here we have implementation of the login feature in the backend server responsible for doing such replacements. Our query template is in the first few lines. User provided data is available in the req.body object variable and it will be interpolated with a template string. If no database match is found, then record variable will be null.

In such cases, an error is thrown and no access is granted. Otherwise the program flow continues and access is granted. Let’s see this in action with two examples. On a legit admin login request, user provides a valid email address and the corresponding password. The backend server replaces the values in the right places and sends the query to the database server. What the database server receives is a valid query. And it will look up the accounts table for a record matching both email and password values. There is only one record in our database matching the query criteria, the admin’s account. Let’s now attack. Instead of a valid email address, the attacker provides a partial SQL query.

Check how it looks like in the backend server highlighted with the red background. On the right side is what the database server receives. Again, a valid SQL query. If you look closer, the search criteria is different from what we had before. We are now searching for a record with empty mail or where 1 is equal to 1. Everything else after the semicolon does not belong to the first query. And so this time, no match will be performed regarding the password value. Although there’s no such record with empty email, every record matches the 1 equal to 1 condition. Since we’re dealing with an R, matching one criteria will be enough. The first match record will be returned to the backend server.

The backend server doesn’t know that password wasn’t matched. Remind that the backend server is written in the programming language other than SQL and it knows nothing about SQL. Since the backend server receives some data from the database, the variable record won’t to be null, and access will be granted. And voila! Admin account is often the first row in the database table in the first match of malicious queries like the one we discussed before. This means that chances are attackers will be able to log in as admins. Now we have the answers we were looking for. Something in this case is a partial SQL query, our payload.

And the place where the payload is injected is in the backend server, in the security template. There are several types of injections. What we have discussed until now is called SQL injection, but injection vulnerabilities are often found in null SQL queries, LDAP, XPath, operating system commands, XML parsers, and many, many more other places. They all work the same way. The backend has a template to which external data is appended and the results sent to an interpreter.