Cross-Site Request Forgery (CSRF)
Overview
A cross-site request forgery (CSRF) attempts to execute an action rather than trying to steal personal data. Once an attack is executed there is no way for the attacker to directly monitor the result so attackers often execute multiple forgeries.
The attack can come from malicious emails, websites, or blogs, and targets another open website that a user has already logged into. When a basic user is targeted, the goal for the attacker is usually changing a password or transferring currency. When an administrative user is targeted, a successful CSRF attack can compromise an entire web application. How to Defend Against CSRF
How to Defend Against CSRF
A majority of requests will include an origin header and/or a reference header. Without a cross-site scripting vulnerability, these are extremely difficult to spoof. Ensuring the origin header does, in fact, match the origin site is a quick and simple first step, but this is not enough of a defense on its own.
There are two approaches by which Cross-site Request Forgery (CSRF)
1.Double Submit Cookie
When a user logs in to a web application the site generates a random value and sets it as a cookie. A double submits cookie sends this value as a cookie but also as a request parameter. The server then confirms that the cookie value and the request parameter value match before executing a transaction request. An attacker cannot change a cookie value with a CSRF attack, so even if the request parameter is manipulated the malicious request will not execute.
When the user logs in to the system, the site creates the session id as well as the CSRF token for the user. Then instead of saving the CSRF token, it sends both session id and CSRF token back to the client as cookies where it is saved in the client side.
Suppose the user then requests the page to change the password.
The server sends that particular HTML page. Inside it is a script that reads the CSRF cookie and embeds it as the value of a hidden field in the HTML page on page load.
User then should continue to change their password and submit that page.
The CSRF cookie is sent via the header and the hidden field value along with the rest of the form data is sent in the body of the post request to the server side.
The server checks whether the sent cookie value is as same as the hidden field value it received in the request body. If they are the same, the server goes ahead and changes the user’s password and sends to the user that it's successful if it fails, the system sends the user an error message.
2.Synchronizer Tokens
Synchronizer tokens are often referred to as “challenge” tokens. These challenge tokens are included within an HTML form and associated with sensitive server-side tasks. When a user wants to execute a sensitive operation the request needs to include the challenge token.? On the server side, the web application verifies that the request includes the token. If it does not, the server rejects the request. Note that this method does require a server-side state to be stored and quickly accessible. It is currently considered the best way to prevent CSRF attacks.
When a user logs into a site, a website who implements synchronizer token pattern creates a CSRF token ans saves it with them together with the SessionID of the user.
This token is then embedded in a hidden field of a genuine request.
User then should continue to change their password and submit that page.
Finally, the website sees whether the csrf token value sent via a hidden field is the same as what is stored with them.If they are the same, the server goes ahead and changes the users password and sends to the user that it's successful if it fails, the system sends the user an error message.
References
Comments
Post a Comment