CSRF ( Cross Site Request Forgery - "cross-site request forgery", also known as CSRF) - a type of attack on website visitors that uses the disadvantages of the HTTP protocol . If a victim visits a site created by an attacker, a request is sent secretly on his behalf to another server (for example, to a payment system server) that performs some malicious operation (for example, transferring money to an attacker's account). To carry out this attack, the victim must be authenticated on the server to which the request is sent, and this request should not require any confirmation from the user , which cannot be ignored or tampered with by the attacking script .
This type of attack, contrary to a common misconception, appeared long ago: the first theoretical reasoning appeared in 1988 [1] , and the first vulnerabilities were discovered in 2000 . And the term itself was introduced by Peter Watkins in 2001 .
The main application of CSRF is forcing the user to perform any actions on a vulnerable site on behalf of the victim (changing the password , security question for password recovery, mail, adding an administrator, etc.). Also, using CSRF, it is possible to operate reflected XSS detected on another server.
Content
- 1 Example
- 2 Protection
- 3 See also
- 4 notes
- 5 Links
Example
The attack is carried out by placing on the web page a link or a script trying to access a site on which the attacked user is knowingly (or supposedly) already authenticated. For example, user Alice can view a forum where another user, Bob , posted a post. Let Bob create the <img> tag , in which he specified the URL as the source of the image, when you click on it, the action is performed on the Alice Bank website, for example:
Bob: Hello Alice! Look, what a cute cat: <img src = "http://bank.example.com/withdraw?account=Alice&amount=1000000&for=Bob">
If Alice’s bank stores Alice’s authentication information in cookies , and if the cookies have not expired yet, when trying to upload a picture, Alice’s browser will send cookies in a request to transfer money to Bob’s account, which confirms Alice’s authentication. Thus, the transaction will be successfully completed, although its confirmation will occur without the knowledge of Alice.
Protection
All requests that modify data on the server, as well as requests that return personal or other sensitive data should be protected.
The easiest way to protect against this type of attack is through a mechanism where websites should require confirmation of most user actions and check the HTTP_REFERER field, if specified in the request. But this method may be unsafe, and it is not recommended to use it [2] .
Another common method of protection is a mechanism in which each user session is associated with an additional secret unique key designed to fulfill requests. The secret key should not be transmitted in clear text, for example, for POST requests, the key should be transmitted in the request body, and not in the page address. The user's browser sends this key among the parameters of each request, and before performing any action, the server checks this key. The advantage of this mechanism, compared to the Referer check, is the guaranteed protection against CSRF attacks. The disadvantages are the requirement of the possibility of organizing user sessions and the requirement of dynamic generation of HTML-code of the site pages.
The HTTP / 1.1 protocol specification [3] defines secure request methods, such as GET, HEAD, which should not modify data on the server. For such requests, subject to server specifications, there is no need to apply CSRF protection.
You may want to play it safe and add a key to each request, but keep in mind that the HTTP / 1.1 specification [3] allows for a body for any request, but for some request methods (GET, HEAD, DELETE) the semantics of the request body are not defined, and should be ignored. Therefore, the key can only be transmitted in the URL itself or in the HTTP request header. It is necessary to protect the user from unreasonable distribution of the key as part of the URL, for example, in a forum where the key may be accessible to an attacker. Therefore, requests with a key in the URL should not be used as the address for the transition, that is, to exclude the passage to such an address with a client script, server redirection, form action, a hyperlink on the page, etc., in order to hide the key in the URL. They can be used only as internal requests by a script using XMLHttpRequest or a wrapper, such as AJAX .
It is significant that the key (CSRF token) can be designed not for a specific request or form, but for all user requests in general. Therefore, it suffices to leak the CSRF token with a URL that performs a simple action or does not perform an action at all, as protection against falsification of a request is lost for any action, and not just the one with which the URL has become known.
There is a tougher version of the previous mechanism, in which a unique one-time key is associated with each action. This method is more difficult to implement and resource-intensive. The method is used by some sites and portals, such as Livejournal , Rambler , etc. At the moment (2016) there is no information about the advantage of a tighter option compared to the option that uses a unique secret key for each session [4] .
See also
- Xss
Notes
- ↑ Cross-Site Request Forgery - Much Ado About Nothing , Securitylab.ru , March 13, 2007.
- ↑ We hide Referer during CSRF , InSys, (Translation of Stripping Referrer for fun and profit (English) , Krzysztof Kotowicz)
- ↑ 1 2 RFC 2616 .
- ↑ Multiple CSRF vulnerabilities in the largest Runet portals .
Links
- Client side trojan issue
- The Cross-Site Request Forgery (CSRF / XSRF) FAQ ( cgisecurity.com) - detailed English description
- A series of articles on CSRF , intsystem.org