CSRF or XSRF stands for Cross Site Request Forgery and refers to the Forging cross-site requests. With this method, attackers manipulate web applications by exploiting the rights of authenticated users. In this article we explain how they do this, what variants there are and how attackers can combine CSRF with XSS (Cross Site Scripting).
CSRF primarily targets users of web applications or websites. Using this method, attackers can create a WManipulate the eb application in such a way that unwanted transactions are carried out on the victim for the benefit of the attacker.
For CSRF to work, The victim must be in a logged in state (authenticated) within the web application. More functionality is available in the authenticated state than in the unauthenticated state. The attacker takes advantage of this situation with cross site request forgery.
Attackers usually use a cross site request forgery Form (e.g. an input field for a search or registration on a website). They manipulated this field in advance so that the information entered was about a HTTP request be sent to another recipient. In this attack they target victims, the one current user session the web application and ideally Administrator rights have.
Alternatively, attackers use CSRF to System commands on the respective web server (target system). This works because the browser or application cannot identify the actual origin of the request. This is a weakness of today's browsers.
If the victim has a current user session of a web application and is also an administrator, then attackers can, for example, do a Create a user account on a sensitive system.
Another possible impact of intercepted HTTP requests is one User rights extension be. This allows attackers to execute commands that were previously inaccessible. In addition, entire user sessions of a web application can fall into the hands of the attacker (Session Hijacking/Session Riding).
The victims often do not notice such an attack because the commands controlled by the attacker are usually in the background be executed. However, it is not possible for the attackers Execute CSRF directly on the computer system. This requires additional attack methods.
The attacker can do one manipulated HTTP request (read: a link) and try to foist this link on the victim. He then sends this infected link, usually linked to the URL with prepared parameters, via a so-called Phishing mail (Social Engineering) to the victim. He can see the complete link or suspicious parts of a link with parameters URL spoofing disguise without the victim noticing. If the victim now clicks on the link in the phishing email, the desired action is carried out in favor of the attacker (Cross Site Request Forgery).
An infected link to create a new user on a web application by the victim might look like this:
www.zielsystem.de/adminpanel.php?action=createUser&username= hacker&password=hacker
Based on a phishing email, the attacker can also direct the victim to one infected website lead. This does not necessarily require manipulating the parameters in a URL request (GET parameter manipulation). It is also possible in advance manipulated elements to implement on the website. An example is a Image with a hidden CSRF command, which when clicked in the background causes the victim to carry out the attacker's desired action.
Another use case for CSRF can already be manipulated form field be that sends the data not to the actual target, but to the attacker. This is how the attacker initiates the compromise of a user account.
Session data is in the browser's cache. It is up to the application how this data is handled. When you close the browser, the cache is usually cleared. At best, this happens through the application.
Session data represent a state within a web application. This includes, for example, the progress on a shop page (shopping cart entries) or information about whether a user is logged in or not. The attacker focuses specifically on the most important data.
A certain level of know-how about the target system is necessary to carry out a successful CSRF attack. The attacker targets the cache data described above in order to be able to log in to the web application as a user (victim).
The following browser caches exist:
Another variant of CSRF builds on an existing vulnerability in a web application: the Cross Site Scripting (XSS).
XSS essentially describes this Execute JavaScript code (programming language in web development) on the victim client side, is supported by current browsers and is initially active in every browser. JavaScript can be used to program instructions that build on one another, making it possible to implement more complex tasks within a web application and execute them for the benefit of the attacker. After executing XSS, the desired action can be implemented by CSRF on the victim side.
A concrete example: By combining CSRF and
Computer systems and services running on them may contain security vulnerabilities that allow the attacker to exploit them full access to the system to obtain. Once this step has been taken, the attacker has an easy time of it and then has to install malware on the system in order to carry out the desired action the next time the browser is used.
This attack can e.g. This can also be done by installing an infected browser plugin. The effects can be the same as in the previously described variants.
