Vulnerabilities from OWASP Top 10. A1: 2017 - Injections (Part 1)

The description of vulnerabilities is one thing, but to try to find a vulnerability and work with it is another matter. It is for these purposes that special applications are created and developed, in which vulnerabilities are intentionally left. If you type in the search engine request "Purposely vulnerable app", you will find a dozen links.

In this cycle, we will begin to break down vulnerabilities from OWASP Top 10, and I will use this intentionally vulnerable application as a testing ground. In my case it will be OWASP Mutillidae II. This is not the best option, but in it vulnerabilities are structured exactly as needed for educational purposes.



Give your hand.

So, the first vulnerability is an injection. In OWASP Mutillidae II, several options are presented, and we will start with the simplest “SQLi extract Data”> “User Info (SQL)”.
Before us is the usual authentication window - with which you interact daily:



We have no login or password - nothing. Well, let's register on this site. I will create a user with the name belowzero273 and password 123:



Fine! We have created an account, the solemn inscription “1 rows inserted” seems to hint that a certain row has been added, apparently to the table, because a large number of accounts are the easiest to store in the DBMS.

Now log in with our new account to the system. Successful, great.
When we work with a web page, you should always remember that our interaction is not limited to the content of the page. There is also an address string, for example. In which we can notice a lot of interesting:

http://127.0.0.1/mutillidae/index.php?page=user-info.php&username=belowzero273&password=123&user-info-php-submit-button=View+Account+Details

For example, we see that the password is transmitted in clear text. This is bad, as traffic can intercept. But perhaps not such a disaster - the traffic will be wrapped in TLS.
Let's try to replace the password directly in the line, for example, this piece:

username=belowzero273&password=123

on

username=belowzero273&password=12345

The password, of course, is now incorrect, and we received the corresponding error: and this is bad. This is bad, because with the help of THC-Hydra, about which I spoke here , we can pick up this password, substituting it into this line without any form. But it is long and not always can lead to a positive result in a reasonable time.

We do not have so much time, so try something else. Add the apostrophe sign to our wrong password:

username=belowzero273&password=123

on

username=belowzero273&password=12345'

Now we got a full error:



There is nothing wrong with mistakes. How else to diagnose a fault if we do not see feedback from the application? But such errors should not be visible to users and intruders.

Now we see that, in fact, when we click the “Send” button in the background, the following query is executed:

SELECT * FROM accounts WHERE username='belowzero273'ANDpassword='12345'

String variables are distinguished by apostrophes. Our web application does not filter the data that the user enters, and with our additional apostrophe we violated the request. Now that we know what this query looks like in the background, we need to figure out how to change it to get the information we need from the database.

Please note that the query is a function and, that is, both variables must be true, because it is a combination of username and password. Is logical.

Let's do a little more with this query:

SELECT * FROM accounts WHERE (username='belowzero273'ANDpassword='12345') OR1=’1

We have added a condition that always holds: 1 = 1. And the request will be executed in two cases: either we guessed the combination of login and password, or 1 = 1. That is, it will always be executed.

It turns out that you can specify the following as a password:

' or 1='1

The apostrophe at the end of the line is no longer needed, the logic of the web application will put it for us. Boom! And we got a sample from the database with all accounts:



Cool, now we have logins and passwords of all who are registered in this application. And even worse, the passwords here are in the clear.

What's wrong with it? And the fact that most people use the same logins and passwords for all sites. And by registering this way on one vulnerable site, they may lose access to all of their sites.

You can still experiment with this vulnerability, for example, search for the administrator password. To do this, as the login substitute:

admin' or 1='1

That is, we are looking for a record in the database, where the login is admin, and the password is any.

Пароль не найден!

Passwords are not always stored in clear text, but does not mean that authentication is done securely. Let's see the second example in OWASP Mutillidae II “SQLi Bypass Authentication”> “Login”.

Authentication can be bypassed if you form an appropriate request. Most recently, we created the account belowzero273, and now let's specify as a login:

' or ('a' = 'a' and username='belowzero273') -- 

Here we check the obviously correct condition - a = a, and login - belowzero273, and also we cut off part of the request with the help “-”.

We press Enter and successfully log in, despite the fact that we have not indicated our password anywhere.

So simple?

Sometimes clients ask, is it really so easy to bypass authentication on our site? I usually answer a question with a question: "Are you sure that this has not happened already?" Injections are not accidentally in the top of the OWASP rating, since these vulnerabilities tend to have disastrous consequences if implemented.

In practice, of course, everything is somewhat more complicated than in these examples. But it is precisely on such basic examples that an understanding of deeper problems begins to take shape. We will continue next time.

You can read the blog of the author of the articleon this link .