Information security
Injection vulnerabilities are usually vulnerabilities caused by command execution or user data inclusion that are not controlled or prevented. According to statistics, 28% of organizations are affected by this vulnerability.
This vulnerability is divided into the following attack vectors:
- Injection through SQL, LDAP, XPath queries.
- Injection with commands in operating systems
- Injection via XML parsing
- Injection via SMTP headers
An attacker could use these vectors (which can execute commands on the system by sending various data) to gain access to both an account and the entire client database of that resource, which he should not be able to access. He exploits the privilege escalation vulnerability by using only special characters and additional operators to work with the database, using different syntax depending on the SQL database type. It increases its effectiveness in the system and can even infiltrate the entire organization. This vulnerability occurs when the user’s data is not filtered or stripped of bad code.
To illustrate, here is an example:
As an example, let’s enter the data as follows:
In the User field, let’s replace the $username variable marked with a red arrow as we see in the path with Hilmi.
In the Transition field, we enter 1234, which is marked with a blue arrow, to replace the $password variable.
After running this SQL query, a search is performed in the database where this user exists with all his information accordingly and we get a positive response on the authorization page and authorize him successfully.
Now let’s see what an attacker can do in this situation:
Here the attacker makes an aggressive move and targets the user manager. Let’s take a closer look at where he logged in:
–An admin value was entered in the user field to replace the $username variable, which is marked with a red arrow, as we can see.
–In the password field, ‘OR 1 = 1— was entered to replace the $password variable (marked with a blue arrow),
Let’s see what happens when such data is entered into the $password variable; The value ‘admin‘ was entered into the username field using a single quote. By closing the given variable, we leave the password empty after the AND operator (visible in the image above). Then we move from ‘OR 1 =1 -‘ to the word OR which says that since we closed our variable with the previous quote, we have called the OR -operator which will already perform its function in the SQL query. OR 1 = 1– tells us that it returns a real value, since it is 1 = 1 TRUE in its expression.
After entering ‘OR 1 = 1 – into the password field, let’s see how our SQL query was transformed in the following image:
We hope that by looking at the above image it is clear what is now… According to this, SQL has been given an additional condition, which means that this query will return a string for the user with the user administrator, even if the correct password was not entered. By adding OR 1 = 1 to the query, it will always be considered TRUE (because 1 always equals 1). Since OR is TRUE entered by the current user, you automatically get the correct result, regardless of anything else. That user is now authorized as an administrator, even if they do not know the password. If there is such a vulnerability, then you may end up with a situation like in the image below…
In the password field’; DROP TABLE users – enter such a value and then send it to the server, if we don’t filter what the user enters in our application then normally the user can use our data in our database. (Drop Table always removes the indexes, rules, triggers, and constraints contained in the target table).
We can imagine such a situation when we make a call. Let’s take this example by calling a user in the system:
As we can see, the SQL query here enters the variable $id, which tells us which user to pull from the user table in our database. Accordingly, it returns us the first and last name of the user found with this ID.
Let’s enter an ID value and see what happens:
So, after entering id=1 in our domain, we see that there is a user named admin with the last name adminoglu. It looks like this may be false. However, if the attacker decides to enter special characters in this domain, and if we do not filter what the user of our system enters, it is obvious that there will be big problems. For example, let’s enter the special character % and see what happens:
As you can see in the image above, all users are displayed here because the special character % we entered creates a list of all existing users. Let’s remember that the % character is used when calling a SQL query LIKE operator in a WHERE statement to search for a word specified in a column that stands for “null, one or more characters“.
And now, in the next example, we use the operator UNION, which combines strings that we add to the existing query executed by the application itself, which we want to display in addition to the user’s first and last name instead of the last one of the passwords. Accordingly, we see the result in front of us. After an ordinary query and the output of the data, the data of the query will appear in the table after UNION, that is, Select username, password From users will bring us the names and passwords of users.
If there is such a vulnerability, you can even try to install various things from the file system using the command LOAD _FILE. This will allow us to read the contents of the file and return it as text. As in the following query example:
Remember that this type of attack is described below and is done by trial and error with many other parameters.
Owasp recommends that the best methods for detecting such vulnerabilities are source code analysis and timely penetration testing.
