What is cross site request forgery? On the most basic level, it’s a type of cyberattack—one that bad actors perform to trick users into completing certain, desired browser requests on a web application. However, not all cross-site request forgery is the same. Both the strategies behind and the results of these attacks can vary based on the specific type of the attack and the unique target of it.
Defining Cross Site Request Forgery Attacks
A Cross Site Request Forgery (CSRF) is an attack through which a bad actor forces an end user to submit a malicious request. For the average web user, this request can be anything from transferring funds or purchasing items to changing their login password or email address. But cross site request forgery attacks can occur on a larger scale as well.. For administrative account victims, a cross site request forgery attack can compromise an entire web application in a single strike.
Still asking yourself, “what is cross site request forgery?” continue reading for a breakdown of how cross site request forgery attacks work, a look at different types of CSRF attacks, and CSRF attack prevention strategies.
Understanding How Cross Site Forgery Request Attacks Work
Typically, a cross site request forgery attack is completed with the help of social engineering. The attacker sends a link through text message, voicemail, or email, and either tricks the user into completing the action they desire or inherits the identity and authentication privileges of the user to perform the undesired function on their behalf.
The attacker doesn’t just take advantage of its victim in a cross site request forgery attack, it manipulates the site system as well. In the case of most sites, browser requests automatically include any credentials associated with the site—from the user’s session cookie to their IP address, Windows domain credentials, and more. When the targeted user is authenticated to the site at the time of the attack, the site has no way to determine what is a legitimate request and what is a forged one.
Beyond the basic cross site forgery request attack, bad actors can also perform something called a login CSRF. This is a special form of a cross site forgery request attack in which the attacker forces a non-authenticated user to login to an account the attacker controls. If the victim fails to realize they’ve been targeted, they’re at risk of adding private data—such as credit card information or bank account numbers—to their account, unknowingly putting sensitive information in the bad actor’s hands. The attacker can then log back into the account, obtain the personal data, and view the victim’s prior activity.
It’s worth noting that the negative effects of a successful attack are always limited to both the capabilities of the compromised system as well as the privileges of the victim. The more sophisticated and high-level a victim’s account privileges are, the bigger the impact of the attack will be.
How To Prevent A Cross Site Forgery Request Attack
One of the most dangerous aspects of a successful CSRF attack is that the victim tends not to know about it until it’s too late, and the unauthorized transaction has already been committed. To prevent a cross site request forgery attack, users will have to be proactive. Luckily, there are prevention methods that can help.
The first step to cross site forgery request attack prevention is to check if your system or web application framework has built-in CSRF protection. If it does, you should use it. If it doesn’t, you can use something called a CSRF token. A CSRF token is a secure, random token—for example, a synchronizer token or challenge token—that enables application servers to determine whether an HTTP request is legitimately generated through the application’s user interface, or if it is forged.
In order to work, a unique CSRF token must be assigned to every user session. As the user operates on their browser and submits various requests, the application server tracks whether each browser-generated request includes its associated CSRF token—verifying the legitimacy of the request. If an end-user request fails to match its designated CSRF token, the application server will reject it, preventing the CSRF attack altogether.
To learn more about how bad actors break into web application systems, check out SiteLock’s “What Is An Attack Vector?” blog.