Suspicion of a cross site request forgery attack. What is CSRF? Meaning of the term CSRF

From the author: The reason for writing this lesson was a question on our forum, which sounded like this - how to protect a site from CSRF attacks? Of course, we immediately answered on this topic and gave a small algorithm for implementing the protection mechanism. But since, most likely, they read the forum, not all of our readers, I decided to write a separate lesson on the above issue.

I would like to note right away that the current video will not provide a full-fledged ready-made solution that can be implemented on the required site. Because each of you has or will have a site with a unique logical structure, that is, not at all like the others, which means it is impossible to create a ready-made protection script, observing absolutely all possible implementation options.

Yes, and this is not necessary, since the essence of the protection mechanism is quite simple, and therefore in the current video, using the test site as an example, you will see how you can protect yourself from the above type of attack, and then, based on the knowledge gained, you will take similar steps on your own project. So let's get started.

CSRF is an abbreviation formed by the English words Cross-Site Request Forgery, which means cross-site request forgery. This term was introduced quite a long time ago in 2001 by Peter Watkins, but they started talking about possible attacks of this kind back in 1988. At the same time, note that a sufficient amount of time has already passed, but most of the Internet websites are still subject to this attack. The question immediately arises - why so? And the answer is quite simple and lies in the fact that the vulnerability to CSRF attacks is not a bug in the application code, but a consequence of the quite normal operation of the browser and web server.

The essence of the attack is that an attacker can perform various actions on an unprotected site on behalf of another registered (authorized) user. In other words given type The attack involves visiting the attacker's site by the user, which in turn leads to the fact that some pre-defined actions are performed imperceptibly for him on another site or service on which this user is in this moment authorized.

In this case, as a rule, the targets of CSRF attacks are various interactive Web applications that perform specific actions, for example, services for sending Email, various forums, payment systems, etc. That is, a hacker can perform some actions on behalf of other users - send messages, add new Accounts, carry out financial transactions, etc.

Now let's look at the effect of this attack on the example of a test site.

Suppose there is a website whose task is to send an e-mail to a specified address on behalf of some authorized user. That is, on home page we see a form to send a message. Moreover, there is also a mechanism for sending messages when passing certain parameters via a GET request (just for example). The login page looks like this:

This page is quite ordinary, but the “Member” checkbox is striking, which is used to store this authorization in browser cookies. Actually, this mechanism is very convenient for users, as it simplifies repeated access to the page, but it is highly undesirable from a security point of view. But still, for the sake of visitors, you often have to make certain concessions.

The code for sending messages by two methods (GET and POST) looks something like this:

//Sending a message if($this->isGet() && !empty($_GET["email"])) ( $body = "Hello this is message form - ".$this->user["name"]; $body .= " Content - from GET - ".$_GET["content"]."From - ".$_GET["email"]; mail(" [email protected]","New message",$body); ) if($this->isPost()) ( $body = "Hello this is message form - ".$this->user["name"]; $body .= " Content - FROM POST - ".$_POST["content"]."From - ".$_POST["email"]; mail(" [email protected]","New message",$body); )

Now, let's look at another site - the site of a hacker.

On which he can place, quite simple, but very effective code, if you need to attack on a GET request:

That is, in fact, we see the img tag, in the src attribute of which is the path to the site intended for the attack, with a set of necessary parameters to perform a specific action. In our case, this is sending a message, which means that now it is enough for an attacker to lure the user to the current site and unnoticed from him, a request will be made to the site of interest, as the browser will try to download the image, the path to which is specified in the src attribute. At the same time, we remember that the browser cookies store data for authorization and, of course, the application immediately uses them and, accordingly, the above request will be successfully processed by the server. And this means that a message will be sent on behalf of the user.

If we look at the set of headers that are sent along with the request, then indeed, we can also see cookies with account login data, which by itself means - as mentioned above, that the request will be perceived as coming from an authenticated user.

The situation is exactly the same with sending a request using the POST method, only in this case the attacker will create a form on his site that will be automatically sent using JavaScript as soon as the visitor enters this site.

Thus, it is imperative to protect yourself from attacks of this kind, and the only most effective way to protect yourself is to use special tokens.

A security token is a string that is randomly generated for a specific user and is transmitted in every request that involves changing data. In addition, the token is also stored in the session. Thus, the essence of protection comes down to a simple check of the correspondence of the token that is transmitted in the request and the token that is stored in the session. If both tokens are identical, then the request was sent by an authorized user. If the tokens do not match, or it is not present at all in the request, it can be judged with great certainty that an attack is being carried out, which means that no actions can be performed.

Note that you need to protect absolutely all requests that are aimed at changing or performing certain actions.

Actually, at this stage, the text part of the lesson is completed and we will continue to talk about the subject we are already in the video version. At the same time, we will consider ways to generate tokens and practically implement the protection algorithm described above. Now let's say goodbye. Happy coding!!!

Article evacuated from DrupalDance.com

The reason for writing this article was that I found a vulnerability in a fairly well-known module. Since, according to the rules for detecting vulnerabilities, I am not yet entitled to talk about the details, I will talk about the vulnerability in general terms, as well as methods for dealing with it.

So, cross-site request forgery(eng. Cross Site Request Forgery, or, for short, CSRF): what is it and what is it eaten with.

CSRF is a type of attack on website visitors that exploits flaws in the HTTP protocol. If a victim visits a site created by an attacker, a request is secretly sent on behalf of the victim to another server (for example, to a payment system server) that performs some kind of malicious operation (for example, transferring money to an attacker's account). To carry out this attack, the victim must be authorized on the server to which the request is sent, and this request must not require any confirmation from the user.

This type of attack, contrary to popular misconception, appeared quite a long time ago: the first theoretical considerations appeared in 1988, and the first vulnerabilities were discovered in 2000.

One use of CSRF is to exploit passive XSS found on another server. It is also possible to send spam on behalf of the victim and change any account settings on other sites (for example, a secret question for password recovery).

Live example

For example, we need to make a small module that should remove nodes with Ajax. This can be implemented by a node service link, when clicked, an Ajax request is sent to the Drupal path. A handler is attached to this path, which removes the node. This is how the module does everything:

node_destroy.module

node_destroy.js

And everything would be fine, but one sunny day, an evil troll comes to the site ... Or a more embittered situation former employee comes to the site and tries to break it. Remembering the old experience, he tries to go to the address http://site.ru/node/123/destroy , but gets a turn from the gate, since he no longer has the rights to delete materials.

And then, in a burst of destructive creativity, he creates a node with the following content:

What is happening at this moment? No picture, of course, will not load, but the troll's browser will fulfill request for this path with the same result.

Resigned to failure, the troll leaves the site. A day later, the site administrator notices this garbage node, enters it and deletes it. And when he returns to the list of materials, he does not find a node with ID 123 in it. The attack was successful. Curtain.

For those who did not understand, when the administrator entered the node, his browser also rushed to the image link. But here there were already enough access rights, and the node was successfully deleted, and the admin did not even notice anything.

How to avoid CSRF vulnerabilities?

The answer is to use unique references for data change actions. How is this possible? Drupal uses a link tokenization method. This means that a unique parameter is added to the link of the active action, which is checked when the action itself is performed. In Drupal, you can generate such a parameter using the drupal_get_token() function. Check -drupal_valid_token() . The token is generated based on the value supplied, the user's session, and the site's private key, which virtually eliminates the likelihood that the pest will generate the correct token.

Let's make changes to our module. Let's start by setting the correct link:

Function node_destroy_link($type, $node = NULL, $teaser = FALSE) ( switch ($type) ( case "node": $path = drupal_get_path("module", "node_destroy"); drupal_add_js($path ."/node_destroy .js"); $links["node_destroy"] = array("title" => t("Destroy node"), "href" => "node/$node->nid/destroy", "attributes" => array("class" => "node_destroy_link"), // query is all GET parameters, i.e. everything in the link after the question mark // we add the parameter token "query" => "token=". drupal_get_token ("node_destroy_". $node->nid)); break; ) return $links; )

As you remember, we send an Ajax request to the address that is wired in the link, so in the callback we only have to check $_GET in the standard way.

Function node_destroy($node) ( if ($node->nid && isset($_GET["token"]) && drupal_valid_token($_GET["token"], "node_destroy_". $node->nid)) ( node_delete( $node->nid); print("SUCCESS"); ) exit(); )

Cross Site Request Forgery, or CSRF, is an attack that occurs when a malicious site, email, message, application, or anything else forces a user's browser to perform some action on another site where that user is already authenticated. This often happens without the knowledge of the user.

The harm from a CSRF attack depends on the site taking the action. Here is an example:

1. Bob logs into his personal account in the online banking client, performs some operations, but does not log out.
2. Bob checks his mail and clicks on a link leading to an unfamiliar site.
3. An unfamiliar site makes a request to Bob's online bank client to transfer money, passing information in Bob's cookie from his previous session.
4. Bob's bank site accepts a request from an unfamiliar (malicious) site without using a CSRF token and performs the transfer.

Even more interesting is the situation when a link to a malicious
the site can be contained in valid HTML, thanks to which Bo-
bu don't even have to click on the link: . If Bob's device (for example, a browser) renders
If this image is missing, it will make a request to malicious_site.com and potentially perform a CSRF attack.

Now that you know the dangers of CSRF attacks, you can protect yourself from them in many ways, the most popular of which is perhaps the use of a CSRF token, which must be sent with any request that can potentially change data (for example, with POST requests ). A web application (such as Bob's online bank) would need to generate a token consisting of two parts, one of which Bob would receive and the other would be stored in the application.

When Bob tries to make a money transfer request, he will have to send a token, which will be validated by the bank using the token stored in the application.

Now that we know about CSRF and CSRF tokens, Cross Origin Resource Sharing (CORS) is becoming more clear, though I may have just noticed this as I researched new targets. In general, CORS limits the list of resources that can access data. In other words, when CORS is being used to secure a site, you can write Javascript to call the target application, read the response, and make another call if the target site allows it.

If this seems confusing, then try using Javascript to make a call to HackerOne.com/activity.json, read the response, and make a second call. You will also see the importance of this and potential workarounds in example #3 below.

Finally, it's important to note (thanks to Jobert Abme for pointing this out) that not every request without a CSRF token is invalid. Some sites may perform additional checks, such as comparing the outgoing side header (although this is not a security guarantee and there are known workarounds). This is a field that identifies the address of the page that links to the requested resource. In other words, if the outgoing party (referrer)

makes a POST call from a site other than the one that received the HTTP request, the site may not allow the call to achieve the same effect that is achieved using a CSRF token. Also, not every site uses the csrf term when creating or defining a token. For example, on Badoo this is the rt parameter, as described below.

Read the OWASP Testing for CSRF guide

Examples

1. Export Installed Shopify Users

Difficulty: Low
Url: https://app.shopify.com/services/partners/api_clients/XXXX/export_installed_users

Description:

The Shopify API provides an endpoint for exporting a list of installed users via the URL shown above. The vulnerability was that the site could make a request to this endpoint and receive information in response, because

Shopify didn't use a CSRF token to validate this request. As a result, the following HTML code could be used to submit a form on behalf of an unsuspecting victim.

1 2 3 4

In this example, on a simple page visit, Javascript submits a form that includes a GET request to the Shopify API using the Shopify cookies set in the victim's browser.

conclusions

Scale up your attacks and look for bugs not only on the site, but also in the API. API endpoints are also a potential site for exploitation, so it's worth keeping this in mind, especially if you know that the API may have been developed or made available after the web interface was created.

2. Disconnecting Shopify from Twitter

Difficulty: Low
Url: https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect

Shopify provides a Twitter integration that allows store owners to tweet about their products. Similarly, the service allows you to disconnect your Twitter account from the associated store.

The URL to disable the Twitter account from the store is listed above. When making the request, Shopify did not validate the CSRF token, allowing the attacker to create a fake link that would lead the unsuspecting store owner to disconnect their store from Twitter.

Describing the vulnerability, WeSecureApp provided the following example of a vulnerable request, note that using the img tag makes a call to a vulnerable URL:

1 GET /auth/twitter/disconnect HTTP/1.1 2 Host: twitter-commerce.shopifyapps.com 3 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.1 4 1; rv:43.0) Gecko/20100101 Firefox/43.0 5 Accept: text/html, application/xhtml+xml, application/x 6 ml 7 Accept-Language: en-US,en;q=0.5 8 Accept-Encoding: gzip, deflate 9 Referer: https://twitter-commerce .shopifyapps.com/accou 10 nt 11 Cookie: _twitter-commerce_session=REDACTED 12 >Connection: keep-alive

Because the browser makes a GET request to get the image from the URL passed in and the CSRF token is not validated, the custom store is now disabled:

1 2 3 5 6

conclusions

In this situation, the described vulnerability could be found using a proxy server such as Burp or Firefox Tamper Data by looking at the request sent to Shopify and seeing that this request was made using a GET request. Since this was destructive and GET requests should not change data to the server, this is worth investigating.

3. Full account takeover on Badoo

Difficulty: Medium
URL: https://badoo.com
Report link: https://hackerone.com/reports/12770312
Report date: April 1, 2016
Compensation paid: $852

Description:

If you take a look at Badoo, you'll realize that they protect against CSRF by including the rt parameter in the URL, which is only 5 characters long (at least at the time of writing). Although I noticed this when Badoo launched a campaign on HackerOne, I didn't find a way to use it. However, Mahmoud Jamal (zombiehelp54) did.

After understanding the meaning of the rt parameter, he also noticed that the parameter was returned in almost all json responses. Unfortunately this was of no use as CORS shields Badoo from attacks by reading these answers. Mahmoud kept looking.

It turned out that the file https://eu1.badoo.com/worker-scope/chrome-ser contains the value rt. Even better was that this file
could be arbitrarily read by the attacker and did not require
victims no action other than visiting a malicious web page. Here is the code he provided:

1 2 3 4 6 7 8

Basically, when a victim loads a page, they make a request to the Badoo script, grab the rt parameter for that user, and then make the request on behalf of the victim. In this case, it was linking Mahmoud's account to the victim's account, which allowed the account to be completely taken over.

conclusions

Where there is smoke, there is fire. Here, Mahmoud noticed that the rt parameter was being returned in various places, in specific json responses. So he correctly guessed that it could be shown somewhere where it could be used in this case in a js file.

Results

CSRF attacks represent another dangerous attack vector and can be carried out with little or no victim notification. Finding CSRF vulnerabilities requires some ingenuity and, again, the desire to test everything.

Generally, forms are protected by default by frameworks like Rails if the site makes a POST request, but APIs can

be a separate story. For example, Shopify is written primarily based on the Ruby on Rails framework, which provides CSRF protection for all forms by default (although it can be turned off). However, this is obviously not necessarily the case for APIs built with this framework. Finally, pay attention to calls that modify data on the server (such as a delete action) and are made with a GET request.

Cross-Site Request Forgery - A lot of noise for nothing

Alexander Antipov

Recently, a "new" type of vulnerability called Cross-Site Request Forgery (CSRF or XSRF) has been widely discussed in the Web application security community. The article presented to the reader's attention contains a description of this type of vulnerability, methods of exploiting it, and basic approaches to protection.

Sergey Gordeychik

Gordey @ ptsecurity com

Recently, a "new" type of vulnerability called Cross-Site Request Forgery (CSRF or XSRF) has been widely discussed in the Web application security community. The article presented to the reader's attention contains a description of this type of vulnerability, methods of exploiting it, and basic approaches to protection. The generally accepted Russian term for Cross-Site Request Forgery has not yet settled down, and therefore the author suggests using the “HTTP request forgery” option.

Lyrical digression

First of all, I would like to dwell on the main misconceptions associated with CSRF:

1. HTTP request forgery is a new type of vulnerability.

This is far from true. Theoretical reflections on the topic of message source forgery date back to 1988 (http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html), and practical examples of vulnerabilities have been discussed in Bugtraq since at least 2000 (http://www. zope.org/Members/jim/ZopeSecurity/ClientSideTrojan). The term itself was introduced by Peter Watkins (http://www.securiteam.com/securitynews/5FP0C204KE.html) in 2001.

2. CSRF is a variant of Cross-Site Scripting (XSS).

The only similarity between CSRF and XSS is the use of Web application clients as an attack vector (Client-Side Attack in WASC terminology http://www.webappsec.org/projects/threat/). Vulnerabilities such as CSRF can be exploited in conjunction with XSS or "redirectors" (http://www..php), but represent a separate class of vulnerabilities.

3. CSRF vulnerability is not common and rather difficult to exploit.

Data obtained by Positive Technologies in the course of penetration testing and Web application security assessments shows that the majority of Web applications are affected by this vulnerability. Unlike other vulnerabilities, CSRF does not occur as a result of programming errors, but is the normal behavior of the Web server and browser. Those. most sites using the standard architecture are vulnerable by default.

Usage example

Let's look at the use of CSRF with an example. Suppose there is a Web application that sends e-mail messages. The user specifies the e-mail address and message text, presses the Submit button and the message from his address is sent to the recipient.

Rice. 1. Sending a message

The scheme is familiar from many sites and does not raise any objections. However, the specified application is highly likely to be vulnerable to HTTP Request Forgery attacks. To exploit the vulnerability, an attacker can create a page on his site containing a link to an "image", and then force the user to follow the link to his site (for example, http://bh.ptsecurity.ru/xcheck/csrf.htm).

When accessing a page, the user's browser tries to download an image, for which it refers to a vulnerable application, i.e. sends an e-mail message to the addressee specified in the "to" field of the request.

Rice. 2. CSRF attack

Please note that the user's browser will send the cookie value to the site, i.e. the request will be interpreted as coming from an authenticated user. An attacker can use social engineering techniques, as well as technical vulnerabilities such as XSS and bugs in the implementation of the redirect function, to force a user to load a page that sends a request to a vulnerable server.

Rice. 3. Logic of CSRF operation

Thus, a CSRF attack consists in using the user's browser to send HTTP requests to arbitrary sites, and the vulnerability lies in the lack of verification of the source of the HTTP request. The example application uses the GET HTTP method to pass parameters, making life easier for an attacker. However, don't think that using the POST method automatically eliminates the possibility of HTTP request forgery attacks. The page on the attacker's server may contain a prepared HTML form that is automatically submitted when the page is viewed.

An attacker does not need to have his own Web server to exploit CSRF. The page initiating the request may be transmitted via email or other means.

Billy Hoffman's overview of various networking techniques with Javascript. All of them, including XmlHttxmpquest (in some situations), can be used to implement CSRF attacks.

I hope that now the reader already understands the main difference between CSRF and XSS. In the case of XSS, an attacker gains the ability to access the DOM (Document Object Model) of a vulnerable page, both for reading and writing. When executing CSRF, the attacker has the ability to send a request to the server using the user's browser, but he will no longer be able to receive and analyze the server's response, and even more so its header (for example, Cookie). Accordingly, "HTTP request forgery" allows you to work with the application in the "write-only" mode, which, however, is quite enough to carry out real attacks.

The main targets of CSRF attacks are various interactive Web applications, such as e-mail systems, forums, CMS, remote control interfaces for network equipment. For example, an attacker can send messages on behalf of other users, add new accounts, or change router settings through the Web interface.

Rice. 4. Example of using CSRF in the forum

Let's dwell on the last one - changing the settings of network devices. The author is already in relation to systems for detecting wireless attacks, but of course, the matter is not limited to them.

Breaking through the perimeter

Last December, Symantec published a report on a "new" attack called "Drive-By Pharming" which is essentially a variant of CSRF exploitation. The attacker executes some "magic" JavaScript in the user's browser that changes the router settings, for example, sets a new DNS server value. To perform this attack, you need to solve the following tasks:

Port scanning with JavaScript;

Determining the type of Web application (fingerprint);

Password guessing and authentication with CSRF;

Changing host settings with a CSRF attack.

The technique of scanning to determine whether a Web server is available and its type using JavaScript is fairly well developed and boils down to dynamically creating HTML objects (for example, img src= ) pointing to various internal URLs (for example, http://192.168.0.1/pageerror .gif). If the “image” was successfully uploaded, then the Web server based on Microsoft IIS is located at the tested address. If the response is a 404 error, then the port is open and the Web server is running on it. If the timeout has been exceeded, the server is not on the network or the port is blocked on the firewall. Well, in other situations - the port is closed, but the host is available (the server returned the RST packet and the browser returned an error before the timeout expired). In some situations, such a port scan from the user's browser can be performed without JavaScript usage(http://jeremiahgrossman.blogspot.com/2006/11/browser-port-scanning-without.html).

After determining the device type, an attacker can try to force the user's browser to immediately send a request to change the settings. But such a request will only succeed if the user's browser already has an active authenticated session from the device. Having an open router management page at hand is a bad habit of many "advanced" users.

If there is no active session with the management interface, the attacker needs to pass authentication. If the device implements forms-based authentication, there are no problems. Using CSRF in POST, an authorization request is sent to the server, after which an image (or page) is loaded from it, accessible only to authenticated users. If the image was received, then authentication was successful, and you can proceed with further actions, otherwise, try another password.

If the attacked device implements authentication using the Basic method, the task becomes more complicated. Browser Internet Explorer does not support the ability to specify a username and password in a URL (for example, http://user: [email protected]). In this regard, the method with adding HTTP headers using Flash, described in the article, can be used to perform Basic authentication. However, this method is only suitable for old Flash versions which are becoming less and less common.

But other browsers, such as Firefox, allow you to specify a username and password in the URL, and can be used to authenticate to any server, and this can be done without generating an error message if the wrong password is chosen.

An example script for "silent" authentication using the Basic method, from the blog of Stefan Esser is given below.

Firefox HTTP Auth Bruteforcing

Rice. 5. Basic Authentication in Firefox

In a corporate environment where SSO mechanisms are often used, for example, based on an Active Directory domain and Kerberos and NTLM protocols, CSRF operation does not require additional efforts. The browser will automatically authenticate with the security context of the current user.

After authentication has been completed, the attacker uses JavaScript to send a request that changes arbitrary router settings, such as the DNS server address.

Protection methods

The first thing that comes to mind when it comes to protecting against CSRF is checking the value of the Referer header. Indeed, since HTTP request forgery consists of passing a request from a third site, controlling the origin page whose address is automatically added by the browser to the request headers can solve the problem.

However, this mechanism has several disadvantages. Firstly, the developer faces the question of processing requests that do not have a Referer header as such. Many personal firewalls and anonymizing proxies strip the Referer header as a potentially insecure header. Accordingly, if the server ignores such requests, the group of the most "paranoid" citizens will not be able to work with it.

Secondly, in some situations the Referer header can be spoofed, for example using the Flash trick already mentioned. If the user is using IE 6.0, then the contents of the request header can be modified using a bug in the XmlHttxmpquest implementation. The vulnerability lies in the possibility of using newlines in the HTTP method name, which allows changing headers and even injecting an additional request. This vulnerability was discovered by Amit Clein () in 2005 and reopened in 2007. The limitation of this method is that it only works if there is an HTTP proxy between the user and the server, or if the servers are located on the same IP address but with different domain names. names.

Another common technique is to add a unique parameter to each request, which is then checked by the server. A parameter can be added to the URL when using a GET request, such as in or as a hidden form parameter when using POST. The value of the parameter can be arbitrary, the main thing is that the attacker cannot predict it, for example, the value of the user's session.

Rice. 6. Protection against CSRF in Bitrix

To quickly add CSRF validation functionality to your application, you can use the following approach:

1. Add a small JavaScript to each generated page, adding an additional hidden parameter to all forms, which is assigned the Cookie value.

2. Check on the server that the data sent by the client using the POST method contains a value equal to the current Cookie value.

An example of such a client script is shown below:

A further development of this approach is to store the session identifier not in a Cookie, but as a hidden form parameter (for example, VIEWSTATE).

Various variants of Turing tests can be used as a method of counteracting CSRF, for example, well-known images - CAPTCHA. Another popular option is the need to enter a user password when changing critical settings.

Rice. 7. Protection against CSRF in mail.ru

Thus, Cross-Site Request Forgery is an attack directed at the client of the Web application and uses insufficient verification of the origin of the HTTP request. To protect against such attacks, additional control of the origin of the request based on the Referer header or an additional "random" parameter can be used.

Sergey Gordeychik is a system architect at Positive Technologies, where he specializes in application security, wireless and mobile technology. The author is also the lead developer of the Security wireless networks”, “Analysis and assessment of the security of Web applications” of the training center “Informzaschita” . Published dozens of articles in Windows IT Pro/RE, SecurityLab and other publications. He is a member of the Web Application Security Consortium (WASC) projects.