Cross Site Request Forgery

from Wikipedia, the free encyclopedia

A cross-site request forgery (usually CSRF or XSRF abbreviated German about site cross-company request forgery ) is an attack on a computer system , in which the attacker a transaction in a web application performs. This does not happen directly. Instead, the attacker uses a victim who must already be logged on to a web application. A malicious HTTP request is slipped into the victim's web browser without their knowledge . The attacker chooses the request in such a way that when it is called, the web application takes the action desired by the attacker.

The security problem is due to the statelessness of the HTTP protocol, since after a one-time authentication the browser implicitly sends its session data to the server every time. If the web application does not take any measures against CSRF attacks, it is vulnerable.

While CSRF refers to any form of data change using HTTP requests, session riding refers to the manipulation of data using a valid session of the victim. Session riding is a special case of CSRF with the condition that the session identifier is transported using basic / digest authentication or a cookie .

In the article here, the term cookie is used in a simplified manner when referring to a session (especially a session identifier). However, CSRF occurs not only with (HTTP) form-based, but also with basic or digest authentication.

history

Already in October 1988 Norm Hardy published a document in which he discussed the issue of trust at the application level and called it "a Confused Deputy". In 2000, the Bugtraq security mailing list discussed how ZOPE was affected by a confused-deputy issue that would now be classified as a CSRF vulnerability. Later, in 2001, Peter Watkins published a contribution to the discussion “The Dangers of Allowing Users to Post Images” on Bugtraq, with which he used the expression “Cross-Site -Request-Forgery “.

Examples

A fairly harmless example of a CSRF would be a link on the attacker's website to the logout function on Wikipedia 

http://de.wikipedia.org/w/index.php?title=Spezial:Userlogout

If a user registered in Wikipedia is slipped this link so that his browser issues this request, he will be logged out of Wikipedia without any action on his part, provided the web application on Wikipedia has no protection against CSRF attacks.

Such a URL would be more serious for the user administration of a non-public page. For example, the attacker could be with 

http://www.example.com/admin.php?action=new_user&name=baduser&password=geheim

create a new user and thus gain unauthorized access to the corresponding web application if he manages to pass this HTTP request on to the administrator of the web application and he is logged on.

Attack vectors

In order for the attacker to be able to carry out a cross-site request forgery, he must get the victim's web browser to carry out one or more HTTP requests manipulated by the attacker. There are several attack vectors for this :

Cross site scripting

Here, the attacker first transmits the selected HTML code to the web application. This saves the code and attaches it to later requests from other users without masking the HTML code. This vulnerability is known as cross-site scripting (XSS). The cross-site request forgery is how the victim's web browser handles the HTML. This consists, for example, of an img tag with which a web browser is instructed to automatically reload a graphic for the page. Instead of the URL under which the graphic can be found, the attacker will insert the manipulated request here. As soon as the victim's web browser calls up the URL, the manipulated request is sent and processed by the web application as if it were authorized by the victim. Instead of an img tag with a manipulated URL, the attacker can also insert JavaScript code into the page. This could also be used to subvert the defensive measure of a shared secret described below .

Sliding the URL

In addition to the possibility of automating the call of the manipulated URL via cross-site scripting, the attacker can also choose from a number of other possibilities to induce the victim to call up a manipulated URL. The URL is usually either sent to the victim by email or can be found on a website that does not even need to be part of the web application concerned. In contrast to cross-site scripting, the attacker has to use persuasion (depending on the victim's good faith) to persuade the victim to call up the URL, which is also known as social engineering . For purposes of deception, the manipulated URL can either be alienated by means of URL spoofing or disguised by a short URL service . If the attacker chooses e-mail as the medium, he can also use mail spoofing to gain the victim's trust, for example by posing as the administrator of the web application concerned.

If the attacker wants to prevent the victim from finding out about the process after the attack has been successful, the attacker can also first enter the URL of their own page that contains, for example, a funny picture. However, the attacker will then build a hidden frame into this page in which the manipulated URL is called. If the victim uses an e-mail program which, without being asked, reloads images embedded in the e-mail from the Internet via the web browser, this attack method could also be exploited without having to rely on the active cooperation of the victim.

However, all these methods require that the user is already logged in to the web application concerned, has saved his access data in a cookie or complies with the request to authenticate himself to the web application. While the latter case is rather unlikely with a healthy amount of common sense, the first situation in particular represents a real chance of success for the attacker, as many web applications offer the user to save his access data in his web browser for reasons of convenience.

Local exploit

If the attacker has control of the victim's computer through malware running there , he can also execute a CSRF. To do this, the malware simply has to instruct the browser to call up the manipulated URL, which is not a hurdle with little programming knowledge. Rather, the difficulty with this attack is installing malware that is suitable for the attack on the victim's computer. However, since this is not specific to the attack described here, it will not be discussed in any more detail here.

Defense measures

Depending on the attack vector, either the user is responsible for the client-side or the operator of the web application for server-side countermeasures against cross-site request forgery.

Server side

Each web application transaction must be provided with additional secret information shared by the browser and the web application.

Synchronizer Token Pattern (STP)

With STP, a so-called page token, usually a number or a character string, is integrated in a hidden field on the page. 

<input type="hidden" name="csrftoken" value="KbyUmhTLMpYj7CD2di7JKP1P3qmLlkPt" />

Without further gaps in the web application, this hidden field cannot be read by the attacker. However, an XSS vulnerability in particular can negate the CSRF protection. The latter applies even if the XSS vulnerability only exists in another application on the same domain.

How the field is set depends on the framework used.

Example in ASP.NET MVC

In ASP.NET MVC , all forms are automatically provided with a hidden field with the anti-CSRF token: 

@using (Html.BeginForm("ChangePassword", "Manage"))
{
    // ...
}

Alternatively, this can also be set manually: 

<form action="/" method="post">
    @Html.AntiForgeryToken()
</form>

In ASP.NET Core there is also Microsoft.AspNetCore.Antiforgerythe option to configure the token globally: 

services.AddAntiforgery(options => {
    options.FormFieldName = "csrftoken";
    options.RequireSsl = true;
});

The token must be validated on all MVC controllers or methods that have a side effect. Three filters are used for this, which can be set as attributes on the corresponding controllers or methods:

attribute function
[ValidateAntiForgeryToken] Validates the CSRF token
[AutoValidateAntiforgeryToken] Validates the CSRF token for all HTTP methods except GET, HEAD, OPTIONS, TRACE. The corresponding methods must be implemented in accordance with the standards.
[IgnoreAntiforgeryToken] No validation

Filters on the methods overwrite the filters on the controllers.

Cookie

The CSRF token can also be stored in a cookie . This is declared in the HTTP header: 

Set-Cookie: Csrf-token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; expires=Thu, 23-Jul-2017 10:25:33 GMT; Max-Age=31449600; Path=/

The flag httpOnlyis not permitted here because the token must be processed in the browser by a JavaScript script.

Certain frameworks enforce a specific naming for the CSRF cookie. For example, the token must for $httpservice in Angular with XSRF-TOKENbe named. The token is then X-XSRF-TOKENtransmitted in the -HTTP header.

Example in ASP.NET MVC

With Microsoft.AspNetCore.Antiforgerythe cookie can be set as follows: 

services.AddAntiforgery(options => {
    options.CookieName = "Csrf-Token";
    options.CookiePath = "/";
    options.CookieDomain = "example.com";
    options.RequireSsl = true;
});

HTTP headers

Another method of transmitting the token is the HTTP header . The header is X-Csrf-Tokenused for this. However, some frameworks also use non-standard headers.

Examples of frameworks with non-standardized CSRF headers
Header Framework
X-XSRF-TOKEN Angular
X-Requested-With jQuery
X-Requested-By jersey
Example in ASP.NET MVC

With Microsoft.AspNetCore.Antiforgerythe token in the HTTP header can be set as follows: 

services.AddAntiforgery(options => {
    options.HeaderName = "X-Csrf-Token";
    options.RequireSsl = true;
});

Handling of XMLHttpRequests

In the case of old browsers that XMLHttpRequestallow s from different Origin domains, XMLHttpRequests must be rejected if the domain entered in the Origin HTTP header is not part of the permitted CORS domains.

Client side

The user of a web application must ensure that their computer is free from malware . Any countermeasure against a program that is executed in the context of the user on the client is pointless.

The following notes are unnecessary if server-side security is guaranteed. Since the user can never guarantee this, they are listed for the sake of completeness:

Many web applications, such as Wikipedia, offer their users the option of being permanently logged in. Technically, the session identifier stored in a cookie is usually not deleted at the end of a session. However, this convenience function also increases the attack surface, since the attacker no longer needs to monitor a point in time when the victim is logged on to the web application. Not using this function consequently increases the hurdles that the attacker must overcome.

If the attacker wants to exploit an XSS vulnerability to circumvent the security precaution of a shared secret , he has to rely on JavaScript or JScript being activated in the victim's browser . Deactivating it can consequently also reduce the attack surface; however, as a rule, many web applications use these client-side scripting languages ​​themselves, so this is not possible.

Inadequate defense measures

Some measures to prevent CSRF attacks are insufficient to ensure adequate protection. At best, they are suitable for lifting the hurdle a little higher for the attacker, and at worst they lull the operator of a web application into sham security.

Accept HTTP mail only

A CSRF attack cannot be prevented by only accepting requests that lead to a change in data via HTTP POST . A fake request can also easily be sent via HTTP POST. To do this, the attacker creates a page to which he lures the victim. There, the manipulated request is either generated using a client-side scripting language such as JavaScript , or the attacker gets the victim to click on a button or an image, which sends the request. If the attacker selects an invisible frame or inline frame as the target parameter of the form , the chances of the victim noticing the attack are also slim here.

HTTP referrer check

Checking the HTTP referrer header offers a certain level of protection against pure CSRF attacks, as fake requests that were triggered by an attacker by deceiving the victim on an external website can be partially blocked. However, the web application is well advised not to rely on the protection of the referrer: Many browser plugins allow you to send inquiries with any referrer, e.g. B. the widespread Adobe Flash (in slightly older versions). In addition, for data protection reasons, users or proxy servers can prevent the referrer from being transmitted or enter a different value in a targeted manner, which means that the web application is no longer open to all legitimate users ( false positives ). For reasons of usability of a web application, you should not use the referrer header for an HTTP request at all.

Web links

Individual evidence

  1. ^ Peter Watkins: Cross-Site Request Forgeries (Re: The Dangers of Allowing Users to Post Images). (No longer available online.) Bugtraq, June 13, 2001, archived from the original on July 9, 2012 ; accessed on July 26, 2012 (English).
  2. ^ Christian Schneider: CSRF and Same-Origin XSS. February 25, 2012. Retrieved December 13, 2014.
  3. ^ Guarding against Cross-Site Request Forgery. In: Angular.io. Google, accessed May 15, 2017 .
  4. ↑ "(...) it's possible to send requests from a Flash object to any URL, with almost any HTTP headers the attacker needs"