What is CSRF ?
This type of attack, also known as CSRF or XSRF, Cross-Site Reference Forgery, Hostile Linking, and others, allows an attacker to execute actions (requests) within an application in which a user is currently logged in. It is "cross-site" or "cross-origin" because it uses different websites or elements to interfere, i.e., to send requests within an application that originate elsewhere.
To accomplish its goal, a CSRF sends an HTTP request whenever a user visits a website that contains malicious code. The code is embedded in such a way that no further user action is required.
This type of attack is common in spam emails. The attack begins without the user's knowledge by clicking on a malicious URL and forges actions. HTTP requests sent without the user's knowledge have the potential to access, modify, or delete sensitive data.
While most CSRF attacks occur in users' browsers, they can also be carried out in any file that allows scripting, such as word and XML documents, RSS feeds, and others.
How does CSRF work ?
An attacker gains access to a victim's browser – typically via a malicious link – to perform CSRF. This access is then used to send a malicious request to any application that has an active session in which the user is authenticated because the attacker has access to the browser, requests sent from it are interpreted as legitimate by applications because they are sent with the session cookie that enables the request to occur.
Several conditions must be met for a CSRF to have an effect and be meaningful:
1.) There must be an action that the attacker wishes to carry out on behalf of the victim that will benefit the attacker (for example, gaining access to and changing a victim's password).
2.) To authenticate the user's request, the application must use session cookies.
3.) The attacker is aware of the parameters of the requests he wishes to carry out.
CSRF GET request:-
<a href="http://hackermag.com/best_hacker/vote/48576">View PDF</a><img src="http://hackermag.com/best_hacker/vote/48576" /><img src="https://bank.com/transfer?amount=10000&to_account=2468013579" />CSRF POST request attack:-
The primary distinction between a GET and a POST request for a CSRF is how the request is submitted. Because state-changing requests in applications are frequently made in this manner, attackers use HTTP POST.
With a POST request, the victim's browser sends the desired values through the request body, as opposed to a GET request, where the attack is accomplished through a URL containing the request. Typically, these are encoded in the form of a query string.
An attacker could use the element to submit this request, forcing the user to submit it manually. This is accomplished by duping the victim into clicking a button on the malicious website to which they are directed.
How to prevent CSRF:-
To prevent CSRF injection attacks, ensure that an attacker cannot create an arbitrary request that runs in the security context of another user and is sent from a different website. This is one of the most important prerequisites for a successful CSRF attack. By disrupting this condition, the possibility of such an attack is eliminated.
Using a CSRF token is the most common mitigation technique for cross-site request forgery attacks (also known as a synchronizer token or anti-CSRF token). These session tokens are random and distinct values generated by the application and sent to the client. Following that, they are included in the client's request to the server, which verifies the request.
This introduces an unknown element that effectively neutralizes the CSRF attack. Any request that does not originate from the original form will not contain the correct CSRF token value and will be easily discarded.
Common CSRF token vulnerabilities:-
1.) Tokens are validated and used only when making POST requests, not when making GET requests.
2.) Validation takes place only if the session token is present; if it is missing, validation is also skipped.
3.) Tokens are not tied to the current user session, but are compared to tokens issued by the application at any time.
4.) Tokens are associated with a cookie, but not one used to track the current session.
5.) Tokens are not kept in applications; instead, they are included in cookies, and the application verifies that the token in the request matches the one in the cookie.
0 Comments