Web application security: practical cases

Web application security has been in the top ten of trends and threats to information security for over 10 years. Indeed, modern business processes and daily life are increasingly dependent on the use of web applications, in a variety of aspects: from complex infrastructure systems to IoT devices. Nevertheless, there are very few specialized tools for protecting web applications, for the most part this task is entrusted (or it is hoped that it will be solved) to developers. This and the use of various frameworks, means of rehabilitation, data cleaning, normalization, and more. However, even with the use of these tools, the web did not become safer, moreover, all the vulnerabilities of the "classic web" migrated to mobile development in almost unchanged form. This article will not explain how to prevent a vulnerability, but how to protect a web application from its operation using the Web Application Firewall.

What was the security of a web application before? From the competent setting of the web server, cleaning the site from unnecessary files and code sections and minimal control. Indeed, the channels were weak, DDoS was not common, there were few vulnerabilities, applications were simple, and user actions were predictable in several scenarios.

Over time, web applications became more complicated, server infrastructure and interaction, the code became more voluminous and cumbersome - this greatly increased the so-called "attack surface". The web has become very popular, there appeared opportunities for financial growth - which naturally attracted those who wanted to illegally take advantage of someone else’s work into this area.

The number and type of attacks on web applications began to grow exponentially, which can be divided into two categories (based on the concept of information security):

• threats aimed at breaching confidentiality of information;
• threats to the violation of the availability of information.

First of all, this concerns exploitation of vulnerabilities, and secondly, attacks on denial of service. And if part of the attacks can be avoided during the planning and development of the application (using testing tools, debugging, code analysis, etc.), then when placing a web application on the Internet website (especially a popular field of activity or company) begins to be attacked in almost all areas:

• automatic systems exploit vulnerabilities;
• professional cyber criminals;
• beginners, lovers.

They have different methods, methods and tools - the only goal that unites them is to hack or disable a web application.

Practice and statistics

Enough theory, let's move on to practice. Very often, many opponents from dev appeal to the fact that there will not be any vulnerabilities soon (or already), there are frameworks, fashionable and security tools, the source code is checked by thousands of people, hackers will soon die out. But what about the practice?

Let's go through the “information security” blog and see what has been “hot” lately:

Case: April 3: 0day in banking software for geolocation (topic removed)
Type of vulnerability: SQL injection, RCE, Auth Bypass.
Description: Blind injection on a bank geolocation entry form. The service is critical, available on the Internet.
Risks: business processes, security, theft, reputation.
Protection: detect and block patterns of SQL injection exploitation, such as: using quotes, special constructions - in this example, the sleep function.

Case: March 24: Hacking a pizza delivery site, hacking mobidel.ru
Vulnerability type: Insecure Direct Object References, XSS stored, session capture
Description: the absence of any checks, classic client-side attacks.
Risks: business processes, security, theft, reputation.
Protection: detect and block patterns of XSS vector operation - using the functions of html code injection, multiple authorization requests with different id.

Case: March 22: A bit about the privacy of real Git repositories
Vulnerability Type: Insecure Direct Object References, Information Disclosure
Description: Direct access to critical objects.
Risks: obtaining information about an attack development application.
Protection: detect and block multiple calls to the repository service files.
')
Case: March 12: Secure authorization for the web service in one evening
Vulnerability type: SQL injection
Description: typical developer, figac-and production.
Risks: security through obscurity.
Protection: detect and block patterns of exploitation of SQL injections (union, select, etc.) - even knowing where it is located (with the source code), the attacker will not be able to exploit it.

Case: March 6: How to break telecom providers: analysis of a real attack
Vulnerability type: SQL injection
Description: Perimeter breaking through the web, network penetration.
Risks: business processes, security, theft, reputation.
Protection: detect and block patterns of using automatic vulnerability scanners (by headers, frequency (parsing) of downloads).

This is all that as they say "in plain sight." Web applications as broken, and will break on. No instructions on how to develop secure code, recommendations, best features, etc. does not work. Additional security measures, or even insurance measures, are needed in order to prevent hacking of the web application. This does not mean that modern WAF is a panacea. This is one of the protective measures that will help prevent hacking of a web application.

Pattern Detection

Let's take a look at the main patterns from the cases presented above.

Injections

Operation sql-injection. First of all, an attacker (or an automatic tool) will look at the behavior of the application, when you substitute quotation marks for one parameter or another:

site?id=1' 

We assume that there is an injection, and the site will display an error (classic) to us. Can we block a simple quote? In theory, yes, but what to do with last names like O'Connor, service or admin panels, where the use of quotes is quite appropriate? (the same markdown markup will give us a lot of false detectors).

 site?search=O'Connor 

Such requests are not directly related to the operation, it can be called a probe, a probe request that helps an attacker to detect a sign of vulnerability. Those. such requests should be blocked, but in those areas where no other rule is defined. Also, it is necessary to check the IP address where the request came from: if there were previously attacks from this address, it is blacklisted, etc. - You can block based on the reputation policy.

The attacker has found a vulnerability, now he will try to exploit it (first, select the number of fields):

 site?id=1+union+select+null,null/* 

Or, as in the first example:

 demo'+sleep(10)+' 

These requests are clearly related to attempts at exploitation (and there are usually many of them) and should be blocked by protective equipment. But, it is necessary to take into account the scope - if it is in the request body, it is necessary to carry out the conversion (or cleaning) of hazardous structures by means of a web application. As for example in my article - Habr does not swear at the broken syntax of the request and allows me to normally publish the quotation mark and attack pattern (without execution).

Attack. The attacker knows the web application (he has the code, as in the example above), he can prepare the structure for the attack in advance, for example using special requests like drop / infile / outfile / dumpfile / load_file:

 site?id=1+union+select+null,LOAD_FILE('/etc/passwd'),null/* 

This is an obvious attack and it must be blocked (again, according to the zone of application of the rule). If we take the point system as a basis, then this construction should receive a lot of penalty points: using the union select pattern (and variations), the LOAD_FILE function, the presence of special characters and their potentially dangerous combinations ('/ , access to the service files / etc / passwd , and symbols termination / commenting / *.

Xss

We now turn to XSS. There are quite a few payload variations, they are more diverse and complex. In this case, it is necessary to protect the web application and enable the user to enter data into the input form without blocking it. This must be done both at the application level and with security features.

For example, the simplest form of phone input (take the option without validating the entered values ​​and types) can be filled by the user due to his skills and imagination:
canonically:

 +7 999 999 99 99 

with a broken space:

 +79999999999 

habitually:

 +7 (999) 999-99-99 

in European style:

 +7.999.999.99.99 

Those. a user even in such a simple form can use several variations of the use of symbols and their combinations, what to say about large web forms that contain many fields? And if they involve the decoration / selection of the text? Your company:

 ++" ""++ 

Of course, such a request will not be blocked, there are no dangerous combinations here. "Normal" xss-probes are also detected quite simply:

 alert( prompt( onload= onerror= onmouseover= location.href= document.cookie( 

This may reveal attempts to exploit the vulnerability, so such requests will be blocked.
There are also more serious requests for XSS detection - for example, a classic of the genre (practically non-obsolete) - the universal XSS vector from raz0r :

 javascript:/*--></marquee></script></title></textarea></noscript></style></xmp>">[img=1]<img -/style=-=expression&#40&#47;&#42;'/-/*&#39;,/**/eval(name)//&#41;;width:100%;height:100%;position:absolute;behavior:url(#default#VML);-o-link:javascript:eval(title);-o-link-source:current name=alert(1) onerror=eval(name) src=1 autofocus onfocus=eval(name) onclick=eval(name) onmouseover=eval(name) background=javascript:eval(name)//>" 

In this request, there is almost everything to "shoot" in the presence of XSS. Such a request is an obvious attack and it should be immediately blocked.

Vulnerability Scanners

Usually, the forerunner of an attack is scanning a web application with one or another utility. A clear sign: frequent access from one IP to different pages, more than 404 errors. This may be a search bot (we won’t ban it in any case, but at the same time we must be sure that it is a bot - checking the User Agent field will not give such guarantees). This may be a crawler or a parser - if we don’t feel sorry - let it be a parsit, you can only limit its appetite to the number of requests per minute if you have a weak server. Scanners are another matter: first of all, they can be immediately identified by User Agent / service headers (and most of those who use them never change it and most likely do not even know about it): for example, scanners such as : acunetix, w3af, netsparker, nikto, etc. Such messages should be blocked immediately, so as not to facilitate the work of the attackers (and not to litter the logs). If the headers are nevertheless masked - the scanner can be identified by a variety of 404 errors, authorization attempts, and access to service files.

Protection

As we have seen in the above examples, different technologies are used, platforms - so modern protective equipment must take this into account. In all cases, the use of WAF could prevent exploitation of the vulnerability, and the notification system could report on attempted exploitation.

In order to avoid exploitation of certain vulnerabilities, modern WAF should:

• process traffic instantly;
• block illegitimate requests;
• detect bot activity;
• be able to work with any http / https protocol;
• do not depend on the web application platform;
• be able to identify brute force attacks, cracking, etc.
• be able to work with websockets, etc .;
• minimize false detections;
• block DoS (L7);
• detect and block new attacks, incl. using machine learning;
• contain the current and updated database of attack signatures;
• contain the current and updated IP-reputation base;
• apply virtual patching.