We decided to repeat the large-scale research work of 2015 and analyzed the security of web resources of the world's leading banks. Since then, online banking has become not only more widespread, but even widespread. Indeed, it is fast and convenient, but how safe? Do banks follow best practices?

As last time , in the course of the study, we sent ordinary HTTP and DNS queries without interfering with the banks. That is, all data is collected as a normal user could do by visiting a resource. For analysis, we selected 200 Russian and 400 foreign banks. Under cut excerpts from the study. Full text can be found on our website.

This time we expanded the field of research by adding online resources of foreign banks to the scope. This allows you to compare the attitude to web security in Russia and other countries of the world.

Looking ahead, we regret to note that the classical methods of increasing the level of security are often ignored by banks, although they do not require global financial and technical resources. To miss opportunities is voluntary, but it is completely different to use them incorrectly. For example, in the case of Content Security Policy, one fifth of all the considered resources have settings, and almost every one of them has configuration errors. As part of the study, we tried to consider in detail how to work with this type of settings correctly, and what errors are most often made.

Purpose of the study

The main goal of the study is to assess the level of security of publicly available banking resources: the official website and RBS, in accordance with best practices for setting up web resources. We have selected a number of points, compliance with which can be checked, excluding any technical damage and without interfering with the work of the bank. It is important to note that all the information we collect is in the public domain, and manipulating this data does not require in-depth skills: if you wish, any interested user can come to such results.

Object of study

For testing, we took the TOP-200 banks in Russia. The full list can be found at: http://www.banki.ru/banks/ratings/ (current data as of March 2019).

The first step we identified all the official websites and Internet resources of the RB for individuals and legal entities. Then, for each bank, checks were performed using several standard requests using the HTTP / HTTPS / DNS protocols, similar to the usual requests from bank customers. Grouped List:

1. SSL settings - provide an opportunity to implement one of the many attacks related to SSL;
2. DNS settings - allow you to get information about company subdomains.

The following is a description and results of some checks. We will pay special attention to the section devoted to Content Security Policy: in it we tried to highlight the main errors and tell how they can be avoided. A full description and results of all checks are in the study .

Testing

SSL / TLS

One of the most important points is checking SSL / TLS settings, as Today, these cryptographic protocols are the most popular method of providing secure data exchange over the Internet. The main potential threat is the use of attacks to intercept traffic.

The following checks were selected:

Rating

SSL / TLS has a large number of settings and features that, to one degree or another, affect the security of both the connection itself and its participants as a whole. To conduct an overall assessment of this setting, we used the functionality provided by Qualys (www.ssllabs.com). It allows, on the basis of numerous parameters, to create an overall rating from A to F, where “A +” is the best result that can be achieved in terms of security. Very few companies, even the largest Internet corporations, have it. Accordingly, “F” is the worst result. It can be obtained if the server is exposed to any critical vulnerability, supports outdated protocols and has other problems. Like the “A +” rating, the worst result is rare, and is mainly associated with unprofessional staff.

The percentage of ratings below “A” is displayed on the card. The higher this percentage, the worse the situation with web security in the country.

HTTP headers

The headers in the response of the web server allow you to determine the behavior of the browser in certain situations. Their presence helps to avoid some attacks or complicate their conduct, while adding a header does not require any complex actions or settings. However, some settings, for example, CSP, are distinguished by too many options, the incorrect use of which can create the illusion of security or even damage some site functionality. We reviewed the following headings:

If the first ten headings are “positive” in nature, and it is desirable (correctly!) To use them, then the last three “tell” the attacker what technologies are being used. Naturally, such headings should be discarded.

Rating

The correct combination of HTTP headers allows you to ensure the security of the site, while setting them up is not at all difficult. We have collected data on the use of HTTP headers and based on them we have compiled a security rating for web resources.

For the compliance with the following parameters, we awarded or scored points:

Rating from “D” to “A +”, where “A +” is the best result that can be achieved in terms of security. The worst result was quite rare, however, like the best.

Rating distribution

The percentage of ratings below “A” is displayed on the card. The higher this percentage, the worse the situation with web security in the country.

Content Security Policy

A “content protection policy” or CSP is one of the main ways to reduce the risks associated with exploiting XSS attacks. This tool allows the site administrator to determine which web resources are allowed for use on pages - fonts, styles, images, JS scripts, SWF and so on. Find out which browsers support CSP here .

Thanks to CSP, you can completely prevent the browser from loading, for example, flash objects, or adjust the white list of domains - in this case, the browser will display only those SWFs that are located on the allowed domain. Another advantage that the CSP policy provides is the ability to quickly learn about the appearance of new XSS in the vastness of a controlled resource. By using the “report-uri” option, the browser of the attacker or the victim user sends a report to the specified URL as soon as the CSP is triggered.

Among the main errors related to the CSP policy, the following categories can be distinguished:

1. Incorrect configuration
   
   
   • Missing Directives (script-src | object-src | default-src | base-uri)
   • Redundant options (unsafe-inline | unsafe-eval | https: | data: | *)
2. Weaknesses of hosts and whitelisting
   
   
   • Ability to load arbitrary JS files
   • Callbacks
   • Script gadgets in Angular and similar template engines
3. JS-free attacks (“scriptless”)
   
   
   • Information leakage through open tags
   • Implement Phishing Forms

More detailed information, specific examples of errors and ways to avoid them can be found in the full text of the study .

The main goal of CSP is to reduce the likelihood of exploiting XSS attacks, but, as research has shown, few manage to correctly configure this policy: only 3% use CSP.

The graph shows the most common errors in the CSP of the sites reviewed.

Strict-transport-security

The HSTS (HTTP Strict Transport Security) security policy allows you to establish a secure connection instead of using the HTTP protocol. To do this, use the Strict-Transport-Security header, which forces the browser to force the use of HTTPS. This prevents some MITM attacks, in particular, attacks with a lower degree of protection and theft of cookies. The principle of the mechanism is as follows: the first time you visit a site using the HTTP (S) protocol, the browser receives the Strict-Transport-Security header and remembers that when you try to connect to this site again, you only need to use HTTPS.

This will prevent a scenario where an attacker, intercepting HTTP requests, redirects the user to the clone page to get his data.

Percentage of banks using the Strict-Transport-Security HTTP header

Set cookie

Having received the HTTP request, the server can send the Set-Cookie header along with the response.

Cookies with the Secure flag are sent to the server only if the request is performed over SSL and HTTPS. However, important data should never be transmitted or stored in a cookie, since its mechanism is very vulnerable, and the Secure flag does not provide additional encryption or security measures. Cookies with the HTTPonly flag are not accessible from JavaScript through the Document.cookie API properties, which helps to avoid theft of the cookie from the client in case of an XSS attack. This flag should be set for cookies that do not need to be accessed via JavaScript. In particular, if cookies are used only to support the session, then in JavaScript they are not needed and you can use the HTTPOnly flag. Without the HTTPOnly and Secure flags in the HTTP response header, you can steal or process a web application session and cookies.

Secure and HTTPonly flags in this header are not found more often than on every second official website of the bank in Bosnia and Herzegovina, Japan, China, Brazil, Bulgaria, Luxembourg, Finland, Israel, France, Great Britain and Spain.

Among DBO for physical. persons - China, Ireland, Israel and Japan.

Among RBS for jur. persons - Bosnia and Herzegovina, Brazil and China.

Among Russian banks, the statistics are as follows:

Official website of the bank - 42%;

RBS for physical. persons - 37%;

RBS for legal persons - 67%.

Server header

This header tells you which software the web server is running on, and may have the following meaning, for example:

Server:Apache/2.4.12 (Unix) mod_wsgi/3.5 Python/2.7.5 OpenSSL/1.0.1l
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Disclosure of this information does not pose a direct threat, but can reduce the time of the attack. Instead of checking for a particular vulnerability, you can immediately start looking for data on a specific version of the software. For example, during the study, the following data were found:



The study showed that 64% of banks' sites report a server version, while 24% of these servers are vulnerable.

Conclusion

Having received a general idea of ​​the security of banks' web resources, we came to the main conclusion: many banks neglect even the most common and easy-to-implement tips for improving the security of their web resources.

Vulnerabilities and errors discovered by us allow attackers to implement attacks on resources without spending a lot of effort. But the consequences of these attacks are quite serious: monetary losses of customers, financial and reputational losses of the bank, including in the long term. Few trust their money to a bank whose reputation is tarnished by security incidents.

Of course, following the standard practice of increasing the level of security - searching and closing vulnerabilities - is bearing fruit and can minimize risks. However, most developers of banking web applications forget about the simplest recommendations and methods that can significantly reduce the risk or complicate the exploitation of vulnerabilities (such as, for example, hiding headers from the server with information about the software used or installing CSP). The benefits of using such technologies are not immediately visible, but may not be obvious at all: having encountered them, an attacker will not be able to carry out an attack, and his actions will remain out of sight of those responsible for security.

Having examined the web resources of Russian banks from different angles, we found out that fairly well-known vulnerabilities and security problems are still present in them. This allows attackers to count on the successful implementation of attacks on these financial institutions. And the more problems, the higher the financial and reputation risks of banks.

The situation in the world as a whole is not particularly different. Among the clearly lagging behind in terms of security can be identified online banking resources of the following countries: China, Japan, Brazil, Israel, Spain. Paradoxically, in most cases, foreign banks pay more attention to the security of the main pages than to the RB. It is worth noting that the share of analysis of foreign banks in the study is not so extensive and is, rather, familiarization.