Cross Site Request Forgery, or CSRF / XSRF for short, is primarily aimed at users of web applications or websites.
The web application can be manipulated in such a way that unwanted transactions are carried out in favor of the attacker. It is important that the victim is logged in (authenticated) within the web application. More functionalities are available in the authenticated state than in the unauthenticated state. The attacker takes advantage of this situation with cross-site request forgery.
Concrete CSRF use case in reality
A cross-site request forgery is usually carried out using a form (e.g. an input field for a search or registration on a website). This is manipulated in advance by the attacker in such a way that the information entered is sent to another recipient via an HTTP request. If the victim has a current user session of a web application and is also an administrator, a user account can be created on a sensitive system on behalf of the victim. Another variant of the CSRF is the execution of system commands on the respective web server (target system). The problem lies in the fact that the origin of the request cannot be identified by the browser or the application. Exactly this endeavor is a weakness of today’s browsers.
Further effects of these HTTP requests can, for example, result in an extension of user rights. Commands can be executed that were previously inaccessible or entire user sessions of a web application can fall into the hands of the attacker (session hijacking / session riding). The commands, controlled by the attacker and executed by the victim, are mostly executed in the background, so that the victim does not notice these actions.
In addition, cross site request forgery cannot be executed directly on the computer system, such as an exploit (vulnerability of a service or computer system). This requires further attack methods.
The following variants can be classified as CSRF attack methods:
CSRF in connection with social engineering attacks
Phishingmail:
The attacker can make a manipulated HTTP request, in other words: create a link and try to coax this into the victim. The infected link is usually linked to the URL with prepared parameters via a so-called Phishingmail (Social Engineering) sent to the victim. The complete link or part of a link with parameters can be obscured by URL spoofing without the victim noticing. If the victim now clicks on the link received, the desired action in favor of the attacker (Cross Site Request Forgery) is carried out.
An infected link to create a new user on a web application by the victim could look like this:
www.targetsystem.com/adminpanel.php?action=createUser&username=hacker&password=hacker
Phishing Seite:
Based on a phishing mail, the attacker can also direct the victim to an infected website. This does not necessarily require a manipulation of the parameters in a URL request (GET parameter manipulation), but elements that have already been manipulated in advance, such as an image, can have been implemented on the target page with a hidden CSRF command that is activated when clicking the victim carries out the desired action of the attacker in the background. Another use case for CSRF can be an already manipulated form field which does not send the data to the actual target but to the attacker in order to initiate the compromise of a user account.
Session-Riding:
Session data are stored in the browser’s cache. It is up to the application how this data is handled. When the browser is closed, the cache is usually cleared, but at best by the application. Session data represent a state within a web application, such as the progress on a shop page (shopping cart entries) or whether a user is logged in or not. The attacker specifically focuses on the most important data. A certain amount of know-how about the target system must be available in order to subsequently carry out a successful CSRF attack. The attacker aims at this cache data in order to be able to log into the web application as a user (victim) if necessary.
The following browser caches are available:
- Session Storage
- Local Storage
- Cookie Storage
- Cache Storage
- Indexed DB
CSRF in connection with Cross Site Scripting (XSS)
On the other hand, based on an existing vulnerability in a web application called “Cross Site Scripting”, a Cross Site Request Forgery attack can follow. Cross site scripting essentially describes the execution of JavaScript code (programming language in web development) on the client side of the victim, is supported by current browsers and is initially active in every browser. JavaScript can be used to program instructions that build on one another, which make it possible to implement more complex tasks within a web application and have them carried out for the benefit of the attacker. Here, after executing XSS (Cross Site Scripting), the desired action can be implemented by CSRF on the victim’s side. As an example, a registration form or user profile with payment data can be manipulated in such a way that the data is not sent to the actual target, but rather sent to the attacker.
CSRF in connection with exploits
Computer systems and the services running on them can contain security gaps which, through exploitation, allow the attacker to gain full access to the system. Once this step has been taken, the attacker has an easy job and then has to install malware on the system in order to carry out the desired action the next time they use the browser. This attack can also be carried out, for example, by installing an infected browser plugin. The effects can be the same as described in the points above.