Cross-Site Request Forgery (CSRF), also known as Session Riding is a type of web threat that manipulates the web browser into performing an unwanted action on the application or website to which a user is currently logged in.
A successful CSRF attack can lead to serious consequences e.g. loss of business reputation and customer confidence, a performance of unauthorized activities e.g. funds transfer, identity theft or password modifications. In some cases, the attackers also stole the session cookies information.
How does cross-site request forgery work?
The attacker can target any website but the potential victims are those websites where the attackers have the capacity for data alteration. An attacker typically uses a social engineering method for its ill purposes. For example, he can use an email or an attractive link that can trick the user in sending a forged request to the server. There are different types of CSRF attacks, but they generally share the same characters:
- They exploit websites that rely on a user’s identity
- They trick the user’s browser into sending HTTP requests to the targeted site
- They involve using HTTP requests that have side effects and do not have the proper CSRF protections in place
Mitigating cross-site request forgery
The best practice is to use unique and randomized Anti-CSRF tokens for every session request and to double check those from the server before allowing access. Via a randomly generated token, the possibility of an attack will be unlikely.
- Synchronizer token pattern – When a user visits a site, take a bank website has money transfer function as an example, the bank’s website embeds a randomly generated token into the form. When a user submits the form, the bank will check whether the token submitted matches. If it does, the action occurs.
- Cookie-to-header token – This method involves issuing a cookie to the user’s browser that with a random token. JavaScript operating on the client side will read the value of the token in the cookie and copy it into an HTTP header that will be sent with each request. If a genuine request is sent from the user, the value in the header can be verified by the server. Any other instances will fail, mitigating a successful attack.
By using custom rules through aweb application firewall, users are able to help prevent certain CSRF attacks. mlytics Enhanced Security includes WAF that allows custom rules configuration.