The Study into Cross-Site Request Forgery Attacks within the Framework of Analysis of Software Vulnerabilities

. Nowadays, web applications are one of the most popular types of target of evaluation within the framework of the information security certification. The relevance of the study of web applications vulnerabilities during information security certification is due to the fact that web technologies are actively used while producing modern information systems, including information systems critical from the information security point of view, and on the other hand carrying out basic attacks on such information systems do not require violators of high technical competence, since data on typical vulnerabilities and attacks, including the attacking tools are heavily represented in publicly available sources of information, and the information systems themselves are usually available from public communication networks. The paper presents the results of a study of the security of web applications that are target of evaluation within the framework of certification for information security requirements against cross-site requests forgery attacks. The results of systematization and generalization of information about the cross-site requests forgery attacks and security controls used by web application developers are presented. The results of experimental studies of 10 web applications that have passed certification tests against information security requirements are presented. The results of experimental studies have shown that most developers do not pay enough attention to protection from cross-site request forgery attack - 7 out of 10 web applications tested have been vulnerable to this type of attack. Based on the results of processing the results of experimental studies, the distribution of security controls used in web applications and identified vulnerabilities by programming languages were obtained. Recommendations regarding the protection of web applications against cross-site request forgery attack for developers planning to certify their software are formulated.


Introduction
Software created with the use of web-technologies is currently one of the main components in automated control system (ACS) design. The designed ACS are, as a rule, multi-user and can be found on public domain networks (for instance, Internet), which increases the risk of their successful attack. Various procedures (such as certification, independent security audit) are currently used to lower probability of successful attack. They are aimed at identifying vulnerabilities in the software used to design ACS [1,2]. Software vulnerabilities are analyzed during certification for compliance with the requirements to the protection profiles approved by FSTEC of Russia (Federal Service for Technology and Export Control), which clearly includes requirements of AVA_VAN assurance family "Vulnerability analysis", and during testing for compliance with the requirements of the technical specifications and classic governing documents of FSTEC of Russia. The procedure for vulnerability analysis recommended by FSTEC of Russia consists in the joint use of approaches specified in the Common Methodology for Information Technology Security Evaluation and ISO/IEC TR 20004 [3]. It should be noted that more specific instructions for the test laboratories (for instance, standard penetration tests ) have not yet been developed, which makes this procedure non-determined [4]. The experience of analysis into vulnerabilities of web-applications within the framework of the accredited test laboratory showed that Сross-Site Request Forgery attack, hereinafter -CSRF-attack is currently the most successful attack against targets of evaluation. The main attention of the developers of web-applications, as a rule, is concentrated on implementing measures protecting against attacks like SQLinjections or Cross-site scripting. The situation is aggravated by the fact that measures protecting against CSRF-attacks are still being actively studied, and best practices have not been rigidly registered yet [2,6]. The goal of this work consisted in developing guidelines for the developers of webapplications, who are planning to certify their solutions as to the information security requirements. The work solves the following tasks to achieve the set goal: а) Classification and summary of information about CSRF-attacks and measures of protection against them; b) Consolidation of information about vulnerabilities of web-applications identified within the framework of work of the accredited test laboratories.

The results of classification and summary of information about CSRF-attacks and relevant security measures
A hacker performing a CSRF-attack makes the web-browser used by the legal user, who has been authenticated in "security measures against " the attacked webapplication, send HTTP-request, which is going to be identified by the application as a request received from a legal user, to the web-application. A possible consequence from a successful CSRF-attack implementation is running of an arbitrary code in the web-application in the name of authenticated user. Thus, the main causes of CSRF-attacks are vulnerabilities in web-applications related to wrong implementation of algorithm of HTTP-request authorization. Success of CSRF-attack is determined by the following factors [7,8]:  The browser automatically applies authentication data of the user (for instance, session cookie-files), when sending HTTP-request to the webapplication;  Web-application uses the obtained authentication data to authorize the action required for performance by HTTP-request. It should be noted that despite difficulties in implementation, there are cases of successful CSRF-attacks of 'Login' and 'Logout' type on web-applications [1,9,10]. The probability of successful 'stored' CSRF-attack is higher, because a malicious code is stored on the side of the attacked web-application, and the hacker does not have to make the user (for instance, using methods of social engineering) go to a special resource with a malicious code. Implementation of the security measures on the client's side [11][12][13][14][15][16], represented by plugins/extensions of the browser or additional software (proxy), has significant drawbacks [8] and is currently only of academic interest. There are suggestion on implementing security measures directly with the browser source code, for instance, using 'samesite' properties of the cookie-files, but currently these measures are experimental and are implemented only in certain browsers. Integrated measures (measures implemented jointly by the software code on the client-and the server-sides), as a rule, implement a certain information control policy [6,17], which contain critical information (for instance, authentication data), between the browser and the web-server. It should be noted that effective implementation of this type of security measures is possible by making changes in the browser source code. Moreover, essential limitations of these security measures are well-known, which does not allow their use as a sole measure of protection. The most popular security measures against CSRF-attacks are tokens (synchronic tokens or generated using HMAC cryptographic function) that are generated and checked on the web-application side. This security measure is implemented, as a rule, by the web-application itself or the framework. It should be noted that the majority of the most popular frameworks (such as, Ruby on Rails, ASP.NET, Barabanov A.V., Lavrov A.I., Markov A.S., Polotnyanschikov I.A., Tsirlov V.L. The study into cross-site request forgery attacks within the framework of analysis of software vulnerabilities. Trudy ISP RAN/Proc. ISP RAS, vol. 29, issue 5, 2017, pp. 7-18 10 Django) implement this measure, which somewhat decreases the workload for the developer of a certain web-application and reduces the number of errors related to implementation of the security algorithm by the developer of the web-application. The main distinctive feature of the token-based security measures is in the token storage method:  Generated token may be stored on the web-application side (it is associated with the user session) and it shall be compared with the token received from the web-browser;  Generated token may be stored on the web-browser side (for instance, in the cookie); when the web-application receives a request from the webbrowser, the web-application compares the values of tokens in the cookie and the HTTP-request body. It should be noted that this measure of the web-application security is used correctly, if it is designed and implemented in a way that HTTP-requests of GET type do not change the server state, and are used only for request of the necessary information. AJAX-requests may be protected with tokens inserted in HTTP-header, or custom HTTP-headers (during implementation of this security measure the webapplication only checks availability of the heading in the received request). The leading specialists in the web-application security recommend using the defense in depth principle, when implementing security measures. Thus, specialists of OWASP community recommend implementing security of the web-application by combining two types of the security measures -HTTP-headers verification and tokens. In some cases, the developers use three or more security measures for critical information systems (for instance, online banking systems). For example, it can be a combination of tokens, verification of HTTP-header and security measures that require actions from the end user, who performs a critical operation (entry of onetime code/ password).

Methods and results of the study
The study into the security level of the web-application was carried out in the accredited test laboratory of NPO Echelon (study period: January -November 2016). Brief information about the web-applications that participate in the study is represented in Table 1. 2) Study of the requests to the identified parts of web-applications: transmission of the requests from the web-browser to the web-application with further interception and analysis of the request structure. The expert analyses the intercepted request and defines the type of security measure against CSRF-attack on a specific page.
3) Generating a mock HTTP-request, which is saved as an HTML-file on the local computer and is opened in the web-browser, provided that there is a session authenticated by the target of evaluation (web-application). 4) If the analysis of intercepted request (cl. 2) revealed security measures against CSRF-attacks, the following actions shall be additionally taken: а) when tokens are used as a security measure:  analysis of URL for a presence of token in a plain text;  sending a request without a token;  sending a request with an altered token; Barabanov A.V., Lavrov A.I., Markov A.S., Polotnyanschikov I.A., Tsirlov V.L. The study into cross-site request forgery attacks within the framework of analysis of software vulnerabilities. 12  sending a request using one token for various user accounts;  an attempt to guess /select a token; b) when using verification of the HTTP-headers as a security measure:  sending a request with altered HTTP Referer (originally a misspelling of «referrer»)/Origin fields;  sending a request without HTTP Referrer/Origin fields. The tests were performed using the following software: BurpSuite software, Scaner-VS software. The average time spent on testing of one web-application by one expert of the test laboratory is 8 hours. The results of the study are specified below. 1) CSRF-attacks were successful in 70% of cases -7 out of 10 analysed webapplications turned out to be vulnerable.
2) The majority of CSRF-attacks were successful in relation to web-applications developed in Russia. It should be noted that the only CSRF-attack that was successful in relation to the foreign web-application was that of "Logout" type, and the experts of the test laboratory failed to develop an attack vector that implements information security threat. Only one web-application initially did not have any security measures against CSRF-attacks. The other vulnerable web-applications had security measures based on verification of HTTP-headers or token (Figure 1).

Fig. 1. Distribution of protection measures used in vulnerable web-applications
3) It has been established that web-applications written in PHP have a few more vulnerabilities that results in successful CSRF-attacks (Figure 2) [20]. 4) The developers upgraded vulnerable web-applications using security measures based on tokens in all cases. 5) In the majority of cases the upgraded web-application and web-applications, where the vulnerability has not been identified, used a combination of several security measures against CSRF-attacks. Барабанов А.В., Лавров А.И., Марков А.С., Полотнянщиков И.А., Цирлов В.Л. Исследование атак типа «Cross-Site Request Forgery» в рамках проведения анализа уязвимостей веб-приложений. Труды ИСП РАН, 2017, том 29, вып. 5, pp 7-18 13 Fig. 2. Distribution of identified vulnerabilities as to the programming language 6) The average time required for the web-application developer to correct vulnerability is 3 weeks. 7) One of the results of the study was a deduced empirical rule, in accordance with which the number of vulnerabilities identified in the software is in inverse proportion to the maturity level of the secure software development processes implemented by the developer.

Recommendations to developers on increasing the security level of web-applications
Based on the results of the study the following recommendations were provided for the developers of web-applications that are planning to hold certification tests as to information safety requirements. 1) It is advisable that the developers implement measures for secure software development in the software lifecycle processes. At the very least, it is recommended to implement measures related to testing penetration of webapplication prior to their submission to the test laboratory. To minimize time for such testing, the developers should generate sets of standard tests, which may be developed with account of guidelines represented in the works [17,19]. The developers are advised against limiting their tests to the standard test only, and are recommended to run additional tests aimed at performing CSRF-attacks, like 'Login' and 'Logout', and verify that the selected security measure is correctly implemented.
2) The developers are recommended using the defense in depth principlecombine two or more security measures (as a rule, verification of token and HTTP-headers), when implementing security measures against CSRF-attacks in the web-application.
3) When implementing security measures against CSRF-attacks in the webapplication, the developers are, first of all, recommended to use security measures that are already implemented in the operational environment, for instance, frameworks.