OWASP TOP-10: a practical look at web application security: # 1 - injections

We are pleased to present you another article from our series on the security of Web applications for non- programmers and novice developers who have a poor understanding of the issues. In this article we will talk about the importance of data filtering and such a common and very dangerous type of vulnerabilities, like injections.

All systems (complex and not so) store a large amount of data and various objects. For example, business logic objects such as user accounts, accounts in the system, transactions, transaction logs, etc.

In order to access these objects, each of them, in one form or another, has its own unique identifier. In addition, objects can contain arbitrary sets of fields. All fields also have their own unique names or identifiers.
')
All these objects, and not only these, are stored in tables, where each row is 1 object.

For example, the object “Client” can have the following set of fields: id, first name, last name, e-mail, mobile phone, and stored in a table of the form:

Clients table

id (identifier)	cl_name (name)	cl_sur_name (last name)	e-mail	cell (mobile)	other (etc.)
one	Ivan	Ivanov	ivan @ mail	+70000000000	42

The essence of user interaction with the Web application is to exchange requests between the browser and the server, where the browser sends various parameters to the server and receives a response from the server.

To receive or change objects (for example, to receive an account statement or update your profile), you must request this or that page on the server (hereinafter referred to as the script). Web applications for this purpose use forms or calls directly to the script URL.

To communicate between the browser and the server, HTTP has been developed. Data is transmitted in the form of so-called HTTP requests, each of which consists of a header and request body.

To transfer data from the user's browser to the server using the HTTP protocol, two methods are mainly used - GET and POST (there are also PUT and DELETE methods, but they are used primarily in the API).

When transferring data using the GET method, all request parameters are passed to the page URL in the HTTP request header, for example:

http://simplethreats.ru/get_order?order=150 

In case of using the POST method, the server will receive data already in the body of the HTTP request, and the parameters will not be listed in the URL. Thus, for example, most forms are sent, and always critical authentication data (transferring data to a URL is unsafe, because URL records and HTTP request headers remain in many logs).

Calls via GET or POST can be made to any objects, be it records in the database or reading a file (say, a picture or script from a disk). And since there can be a lot of objects of business logic in the system and they can be of various types, then there can be many requests for identifiers within a single, even simple Web application.

We decided to determine how the data gets into the Web application, but what happens inside?

What happens to the parameters from the request in the application

In our first article we have already told that, all data is usually stored in special databases in the form of tables, the references to which are built in the form of text queries, most often written in a special SQL query language (Structured Query Language). requests).

Web applications, as a rule, build SQL queries that combine code written by the application developer with parameters passed by the user. Consider an example:

 SELECT title, text FROM news WHERE id=$id 

In our example, $ id is a parameter passed by the user (the variable part of the request), while the rest of the request is static and was created by the application developer. The presence of user data variables in a static SQL query makes the entire query dynamic.

What is the essence of the injection?

In the case of SQL, the whole point of the injection is to modify the parameters of the HTTP request in such a way as to distort the SQL query to the database and “slip” it to the server as normal. This will allow the attacker to gain unauthorized access to the data.

Suppose we have a “transactions” table in the database with data about user transactions. It contains the following fields:

• "User_id" - a unique user ID
• "Date" - Date
• "Amount" - Amount
• "Description" - Purpose

Transactions table

user_id	date	amount	description
ten	2015-05-26	1000	...
eleven	2015-05-26	1500	...
12	2015-05-26	1300	...
n	2015-05-26	x	...

Suppose that our account, under which we are in the application, has the identifier 10 (user_id = 10) and this data is stored in the application session (they were written there when the user was authorized).

In general, if we are not a privileged user, we can refer to the database for information on our transactions, i.e. on transactions user_id = 10.

In order for us to obtain data on our transactions for May 26, 2015. in the user account page can be used with the following address:

 http://mybank.simplethreats.ru/transactions.jsp?date=2015-05-26 

When called, the date “2015-05-26” will be obtained from the GET parameter in the URL, and the value of user_id will be obtained from the application session. Based on this data, to obtain information about user transactions, the application will generate a SQL query:

 SELECT * FROM transactions WHERE date = "2015-05-26" AND user_id = 10 

For those who are not familiar with the syntax of SQL for a better understanding, analyze this query.

What is in the request?

A query consists of a SELECT statement (literally from English - “ SELECT ”), which is used to select data from a table. There are also UPDATE, INSERT, and DELETE statements, which, as one can easily guess from their names, perform update, insert, and delete rows, respectively.

The symbol "*" means that we select all the columns in the table. This is followed by the key word FROM (literally - “ FROM ”) with the name of the table from which the sample is taken.

Next comes the keyword WHERE (literally from the English. " WHERE "), followed by the part defining the selection conditions directly from the table.

After this, the conditions of the form “field_name = value” are separated by the keywords AND or OR, meaning “ AND ” and “ OR ”, respectively.

Thus, translating the query from SQL to Russian, we get:

SELECT all fields FROM the transactions table, WHERE date = "2015-05-26" AND user_id = 10

If there is insufficient verification of data from the user, an attacker can embed a special code in the web application interface form containing a piece of the database query. This most dangerous vulnerability will allow an attacker to read / modify / delete information that is not intended for him.

Exploitation

How it works? In the above example, the value of the date "2015-05-26" gets into the SQL query from the script URL, and for the purpose of the example in question, it is not filtered by the application.

If you pass a few more characters to the date parameter along with the date 2015-05-26 :

 2015-05-26" AND user_id=11 -- 

Then instead of the correct one:

 SELECT * FROM transactions WHERE date ="2015-05-26" AND user_id = 10 

The specified query will generate the following SQL:

 SELECT * FROM transactions WHERE date = "2015-05-26" AND user_id = 11 -- " AND user_id = 10 

Two minuses of "-" in SQL syntax mean the beginning of a comment, so all characters after the "-" will not be interpreted by the interpreter, and the part of the query in which the user ID was checked will be truncated by the database server.

In fact, the request will be executed:

 SELECT * FROM transactions WHERE date = "2015-05-26" AND user_id = 11 

As a result of which, we will receive information about the transactions of another user. And going through the id - any other user.

What are the techniques of attacks with SQL injections?

The OWASP community described five main methods (techniques) of attacks with SQL injections.

• Union statement : the approach can be used when there is a vulnerability in a SELECT query that allows you to combine two queries into one result or a set of results.

• Logical method : involves the use of a logical condition, or conditions that reliably determine the truth or falsity of some assumption.

• On the basis of errors : this method involves the deliberate transmission of various incorrect requests, in order to force the web application to issue information about the error, on the basis of which, an attacker can compose and transmit a valid injected request.

• Method with an alternative data transmission channel : the method assumes the use of an alternative transmission channel for the extracted data (for example, through an outgoing HTTP connection to a web server)

• Time delay : the method uses database commands, for example sleep to determine the delay by conditional requests. The method is effective when it is not possible to get a response from the web application (result, error)

In addition, a combined approach can be used, which includes a combination of two or more of these techniques.

By the method of data extraction, there are three types of attacks:

• Related: The data from the injected SQL query is retrieved in the same way that the injected query was transferred. This is the most straightforward type of attack, as a result of which, the data requested by the modified query is displayed directly on the web application page.

• Unrelated : The data from the injected SQL query is retrieved in a way that is different from the way the modified query is passed. (for example, the data is transmitted to the attacker in an e-mail message)

• Deductive or blind : As a result of the SQL injection, the actual data extraction does not occur, but the attacker can get information by observing the behavior of the web server as a result of sending a series of specific injected SQL queries.

How to protect yourself?

The recommendation is extremely simple - filter incoming data. In this case, before filtering, it is better not to bring the data that is clearly not in accordance with the format. In other words, the input data should be checked for compliance with the format and give the user an error.

For example, we need to get the news ID to display. In our system, this is always an integer greater than zero, and we know about it. If a number is not transmitted, or this number is less than or equal to zero, you need to give an error and stop the script execution.

How to proceed to the implementation of this recommendation, if you already have a large web-application that has many different entry points?

We will present some systematic approach to the implementation of protection against database injection. To minimize the potential threat from this type of attack, you must consistently perform the following steps:

• Define all data retrieval points by the web application from the outside, write out all entry points (URLs), the names of the transmitted parameters, the protocol (HTTP / HTTPS) and the transfer method - GET, POST, PUT or DELETE.
  
  
• Determine the data type for each parameter by answering the question - what type of value should we get?
  
  
• Implement checking each parameter for its type.
  
  
• Implement escaping quotes and other special characters with the backslash “\”. Moreover, if the parameter in the request is enclosed in single quotes, then exactly single quotes should be shielded and replaced with “\ '”, similarly with double quotes. In this case, it is not necessary to shield single quotes inside doubles and vice versa. This is in theory, in practice, almost all popular frameworks and scripting languages ​​have built-in functions for escaping special characters, like php for example mysqli_real_escape_string.

In general terms, it is also possible to recommend to skip all database requests through a single point (for example, a framework), when passing through which they will undergo special training - filtering and screening.

It should also be remembered that in order to successfully attack via SQL injection, an attacker needs to submit a syntactically correct SQL query. However, if the web application returns information about the error as a result of an incorrect injected request, it can help the attacker to recover the logic of the original request and give him an opportunity to understand how to properly perform the injection.

Therefore, you need to carefully monitor what information about errors is given by the application. However, if the web application hides error information, the developer should in any case be able to restore the logic of the original request (in the simplest case, keep a log of errors, but not display them on the screen).

What other injections?

In addition to database injection, any other medium that receives raw data from the outside can be attacked by an “injection” type attack. Another common case is the injection of the command interpreter of the operating system, the so-called “OS injections”.

Consider this example from the description of “Command injections” OWASP.

There is a certain social network that provides users with the functionality of downloading photos and their subsequent removal. It has a script written in PHP, and he is responsible for deleting photos:

  <?php $file=$_GET['filename']; system("rm /var/www/user_photos/$file"); ?> 

His typical challenge is:

 http://mysocnet.simplethreats.ru/user_file_delete.php?filename=1246.jpg 

And entails the execution of the command:

 rm /var/www/user_photos/1246.jpg 

It is very easy to clear the entire directory with the application by passing such a request:

 user_file_delete.php?filename=../ -rf 

(in fact, spaces and certain characters are encoded when passing to a URL into something like user_file_delete.php? filename = ..% 2F + -rf - but for clarity, we will write with spaces and other characters without wrapping them)

what will cause the execution:

 rm /var/www/user_photos/.. –rf 

and will be tantamount to

 rm /var/www/ -rf 

that is, deletes (the rf command) the entire contents of the www directory where the application files are stored, without confirmation (the –f parameter) and recursively (the –r parameter), i.e. with all nested directories and their files. Fate - the enemy does not wish.

And you can not delete the file system, and sending a request like:

 user_file_delete.php?filename=12346.jpg && adduser ghost && echo ghostpass | passwd ghost –stdin 

The attacker will execute the command:

 rm /var/www/user_photos/12346.jpg && adduser ghost && echo ghostpass | passwd ghost –stdin 

And create for yourself an account to access the server.

It should be noted that in practice it is almost impossible to create a user in this way, since a Web server in 99% of the systems is run from an unprivileged user who cannot create other accounts.

The execution of the specified chain of commands is possible due to two features of UNIX-systems and their command interpreters.

The first feature is pipelines (pipelines, pipes, “pipes”). The essence of the pipelines is the ability to transfer the output of one command to the input of another, if they are separated by the operator "|".

The second feature is the ability to run a combination of commands through the logical operators "&&" and "||". The “&&” operator will execute the next specified command, in case the previous one was executed successfully and is a kind of logical “AND” - execute the command one And the command two. The operator "||" is analogous to the logical "OR" and will execute the second command only if the first command was not executed - to execute the command one OR the command two.

What's next?

Of course, we considered only a small fraction of what can be classified as injection. A huge reservoir is occupied by the so-called DOM- or HTML-injections, thanks to which it becomes possible to conduct this type of attack as XSS.

The problem of XSS at all times was acute enough, and now, in an era of dynamic content, when JavaScript provides very powerful features, attacks of this kind carry an increased danger (to the extent that an infected application can take a picture of you and send your photo to an attacker ).

XSS, as well as methods of operation and protection from this type of attack, we will devote one of our next articles, which will be released in June.

Be carefull!