OWASP TOP-10: A Practical View of Web Application Security

Habr, hello! We, Ivan Pritula and Dmitry Agapitov, are developing solutions that make people's lives easier and more comfortable. Today we want to introduce one of our new services - this is a SimplePay payment aggregator. Everything we do is dictated by the painful inability to put up with imperfections in general, and the imperfections of specific software solutions in particular. It is in the pursuit of perfection that our products are born. We are trying our best, and it’s not for us to judge how close we are.

To make it more interesting for everyone, we will not advertise our service (well, if only slightly). Instead, we have prepared the first series of publications, which will be devoted to such an exciting and highly relevant topic as the security of Web applications. We will try to uncover the dangers associated with any existing Internet project and in simple language convey the importance of a responsible approach to routine, it would seem, the little things in matters of data security. We hope our articles will not be useless for you. We are sure that you will know us much better.

Web application security

The modern world carries thousands of threats and potential dangers at every step and every moment of time. The global network, which has become an integral part of our lives, is no exception.

Cybercrime is now more developed than ever - after all, almost every company has its own website on the Internet, and an attacker on the network can easily remain completely anonymous.

At the same time, all companies that have a website on the Internet are divided into three types:

• Those whose site is already broken;
• Those whose site has not yet broken;
• Those who are familiar with the main attack vectors and protected applications.

Representatives of the third category further presentation is unlikely to be very interesting. The remaining two categories should at least be aware of the main vectors of attacks on web applications and the possibility of their practical application - after all, forewarned, - almost protected.

The emphasis on the possibility of practical application is not accidental. We believe that it is not enough to know the theory to understand the true scale of the threat — after all, vulnerabilities that do not look very scary in theory can often carry disastrous consequences for a business.

The number of threats grows in proportion to business growth, but long-term practice has shown that 99% of attacks occur through a dozen standard errors in incoming data validation, or vulnerabilities found in installed third-party software components, or trite, due to system administrators' negligence using settings and passwords set default.

The classification of attack and vulnerability vectors is carried out by the OWASP (Open Web Application Security Project) community. It is an international non-profit organization focused on analyzing and improving software security.

OWASP has created a list of the 10 most dangerous attack vectors for Web applications. This list is called OWASP TOP-10 and it contains the most dangerous vulnerabilities that can cost some people a lot of money, or undermine their business reputation, or even lose their business.

In this introductory article, we will go over the list of OWASP TOP-10, and then in the series of our articles “Theory and practice of protecting Web-applications” we take a detailed look at each of the listed attack vectors, methods of practical operation, the degree of danger in examples of real business, as well as Practical protection methods for Web applications and Web services.

We will try to keep the presentation as accessible as possible, in order to convey information not only and not so much to technical specialists, but also to business owners and managers, who, at times, are in happy ignorance until they are broken by attackers and are engaged in online business, not aware of the gravest danger looming over them.

So let's go.

1. Injections - Injections

All data is usually stored in special databases, references to which are built in the form of queries, most often written in a special SQL query language (Structured Query Language - structured query language).

Applications use SQL queries to get, add, change, or delete data, for example, when a user edits personal data or completes a form on a site. If there is insufficient verification of data from the user, an attacker can embed special code in the application's web interface form containing a piece of SQL query.

This type of attack is called injection, in this case the most common is SQL injection. This is a dangerous vulnerability, allowing an attacker to access the database and the ability to read / modify / delete information that is not intended for him.

For example, change with the name and surname the balance of your account, see the balance of someone else's account, or steal confidential personal data.

This vulnerability is a consequence of insufficient data validation from the user. This allows an attacker to “slip”, for example, into web forms, specially prepared requests that will “deceive” the application and allow you to read or write illegitimate data.

In general, this type of attack has the common name “Validation Errors”, it does not include only SQL injections, and we will mention this vector more than once.

2. Shortcomings of the session authentication and storage system (Broken Authentication and Session Management)

In order to distinguish one user from another, the web application uses so-called session cookies. After you have entered the login and password and the application has authorized you, a special identifier is stored in the browser storage, which the browser subsequently presents to the server with each page request of your web application. This is how a web application understands that you are you.

If your ID is stolen by an attacker, and the system has not implemented checks, say IP addresses of the session, or checks for more than one connection in one session, the attacker will be able to access the system with the rights of your account. And if this is an Internet bank or a payment system office, you can easily guess the consequences of such unauthorized access.

3. Cross Site Scripting - XSS (Cross Site Scripting)

Cross-site scripting is another user data validation error that allows you to send JavaScript code for execution to the user's browser. Attacks of this kind are often also called HTML injections, because the mechanism of their implementation is very similar to SQL injections, but unlike the latter, the injected code is executed in the user's browser. What is it fraught with?

Firstly, an attacker can steal your session cookie, the consequences of which were described in the second paragraph, literally a couple of paragraphs above. It should be noted that not all application servers are vulnerable to this type of attack, we will talk about this separately in paragraph 5.

Secondly, data entered into forms on an infected page may be stolen. This can be confidential personal data, or, even worse, credit card details along with a CVC code.

Thirdly, through JavaScript, you can change the data located on the page, for example, there may be details for a bank transfer, which the attacker will gladly fake and replace with dummy.

4. Insecure Direct Object References (Insecure Direct Object References)

This type of vulnerability is also a consequence of insufficient user data checking. Its essence lies in the fact that when displaying any confidential data, such as personal messages or customer records, the object identifier is used to access the object, which is transmitted in the clear form in the browser’s address bar, And the access permissions for objects are not implemented. For example, there is a page that displays a private message and it has an address of the form:

mysite.ru/read_message.jsp?id=123654

Looking through the number after "id =" you can read other people's private messages. Operation of this vulnerability is very simple and does not require any special skills at all - you just have to touch the number in the address bar of the browser and enjoy the result. Paradoxical as it may seem, quite large European payment systems were sometimes exposed to this children's disease.

5. Unsafe Configuration (Security Misconfiguration)

Web application security requires the secure configuration of all infrastructure components: application components (such as frameworks), a web server, a database server, and the platform itself. The default settings of server components are often unsafe and offer opportunities for attacks. For example, theft of a session cookie via JavaScript during an XSS attack is made possible by setting off cookie_http only by default.

If the server is properly configured and the cookie_httponly option is enabled, it is not possible to get a session cookie via JavaScript, but often this simple and important setting was not available in such critical places as personal accounts of payment systems.

Another example of a child vulnerability is the use of default settings in database servers such as Redis, Memcached and others - a closed service may be available at the server’s public IP address, and / or the manufacturer’s default passwords were used. This allows an attacker to read and modify data easily, including session cookies (which is fraught with - we already know), and data that is output to users in the browser (which also allows the XSS attack to be used).

In addition, the software must be up to date: vulnerabilities are found every day in a wide variety of software components - the operating system, web servers, database servers, mail servers, etc. And even if your application is correctly written and carefully checks all incoming data, and in general, is well protected, this does not mean that at one point there will not be a vulnerability in your OS or Web server.

6. Security of sensitive data (Sensitive Data Exposure)

Many web applications do not protect sensitive data, such as credit cards and authentication credentials. Attackers can steal or modify such weakly protected data for use in their personal gain.

The simplest example is HTTP data transfer. The fact is that the data transmitted via the HTTP protocol is not encrypted in any way, and when passing data from the user's computer to the Web server, the data will go through a lot of different nodes: an office router or a home router, a provider router, a router on a channel, a router in data mode. center hosting provider server and so on. At each of these nodes, a malicious program can be hidden, a so-called sniffer, a program that reads all traffic and sends it to an attacker. And the latter views the data obtained for personal data and credit card data.

Such data should be transmitted exclusively via the HTTPS protocol, as the corresponding inscription in the address bar of the browser should read:



Another task of the SSL certificate (namely, this is the name of the special key with which authentication and encryption is performed in HTTPS) is to confirm that it was issued for this particular site. In case the certificate is expired or forged, you will see the following picture:



Another example is the lack of encryption of sensitive data, such as passwords or credit card numbers. If the data is encrypted, then even in the case of unauthorized access to the server, the attacker will not be able to steal critical data. For passwords, in particular, an irreversible hash function should be applied - decryption of the cipher is not possible and the password is checked by generating the cipher of the entered password and comparing it with the one in the database.

7. Missing Access Control (Missing Function Level Access Control)

The essence of the vulnerability, as the name implies, is the lack of verification of proper access to the requested object.

Most web applications check permissions before displaying data in the user interface. However, applications must perform the same access control checks on the server when requesting any function. After all, there are many more auxiliary service requests, which are often sent in the background asynchronously, using AJAX technology.

If the request parameters are not thoroughly checked, attackers will be able to fake a request to access the data without proper permission.

The private, and perhaps the most common case of this vulnerability, we have already considered in paragraph 4 of our article - the lack of user verification in private messages.

8. Cross-Site Request Forgery (CSRF / XSRF)

The CSRF attack vector, also known as XSRF, allows an attacker to perform actions on behalf of the victim on a server where additional checks are not implemented.

For example, in some payment system for transferring funds to another account, there is a page like this:

demobank.com/transfer_money.jsp? transfer_amount = 1000 & transfer_account = 123456789

where transfer_amount is the amount to transfer and transfer_account is the account number to which funds should be transferred.

If the victim enters the site created by the attacker, a request to the above page of the payment system is secretly sent on its behalf. As a result, the money will go to the attacker's account, after which they will probably be promptly exchanged for Bitcoin or transferred to another non-refundable payment system, and it will not be possible to get them back.

It is assumed that the victim should have previously been authenticated in the payment system and an active session should be opened (for example, the page of the payment system is open in another browser tab).

The problem is solved quite simply and we will tell about it in a separate article on the CSRF.

9. Using Components with Known Vulnerabilities (Using Components with Known Vulnerabilities)

Often, web-applications are written using special libraries or “frameworks” (eng - framework), which are supplied by third-party companies. In most cases, these components are open source, which means that they are available not only for you, but also for millions of people around the world who study their source code, including for vulnerabilities. And it should be noted that they are doing this not without success.

Vulnerabilities are also searched (and found) in lower-level system components, such as a database server, a web server, and finally, operating system components down to its core.

It is very important to use the latest versions of the components and monitor the emerging known vulnerabilities on sites like securityfocus.com.

10. Unvalidated Redirects and Forwards

Web applications often redirect users from one page to another. The process may use inappropriately verifiable parameters with an indication of the final destination page of the redirect.

Without proper checks, an attacker can use such pages to redirect the victim to a fake website, which, for example, can have a very similar or indistinguishable interface, but will steal your credit card information or other sensitive confidential data.

This kind of vulnerabilities, as well as many others listed above, is a kind of input validation error.

Instead of conclusion

We reviewed the main types of vulnerabilities from OWASP TOP-10 in general, tried to tell about them as simply as possible, and also to show with simple practical examples what risks these or other attack vectors carry for your business.

First of all, this article was designed for owners of Internet projects and young developers. In future articles we will cover in more detail each of the mentioned attack vectors, already with detailed technical details and good examples, and of course, methods of protection.

If you are a business owner, we hope that your understanding of the risks associated with IT security has become more complete, and the following articles can be an excellent tool for your IT specialists.