Address CSRF vulnerability in WSO2 Products and Solutions
What is CSRF vulnerability
“Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data since the attacker has no way to see the response to the forged request. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state-changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account,CSRF can compromise the entire web application.” - OWASP definition
In brief, CSRF is an attack happens when you are browsing a website, it is typical for that website to request data from another website on your behalf. So that an attacker is able to trick a victim into making a request that the victim did not intend to make.
To address security vulnerabilities such as CSRF, The OWASP (Open Web Application Security Project) has come up with standards. OWASP is an organization that provides unbiased and practical, cost-effective information about computer and Internet applications. Project members include a variety of security experts from around the world who share their knowledge of vulnerabilities, threats, attacks, and countermeasures.
How it can be affected by CSRF vulnerability
Tricking Victims Into a CSRF Attack
How can attackers trick their victims into a CSRF attack? Let’s go with an example. Assume the attacker publishes the form on https://cloudmgt.cloud.wso2.com/cloudmgt/site/pages/signup.jag. All he/she needs to do is trick the user to navigate to that URL.
So once the victim visits https://cloudmgt.cloud.wso2.com/cloudmgt/site/pages/signup.jag the form submission is triggered. The vulnerable website https://example.com accepts the request and the mail is changed to abc@attacker.com, since to the web application it seems like the victim submitted the form, because of the session cookie.
Now all an attacker has to do is use the “password reset” functionality to send a password reset mail. Since the email was changed to abc@attacker.com, Attacker will receive the email and can easily change the Victim’s password. Therefore attacker completely took over the account and even locked the victim out.
Hiding the CSRF Attack From the Victim
For the victim not to notice the CSRF attack, the attacker can create another web page called info.html, which contains information about a topic the victim is interested in. However, the web page can contain a hidden iframe pointing to https://attacker.com/csrf.html, so once the victim visits info.html, the form on csrf.html is automatically triggered, without any visible indicator to the victim.
Attackers typically use CSRF attacks on password or email change forms, to hijack their victims’ accounts, or to create a new admin user on a web application.
Since in WSO2 products and solutions also, we deal with customer’s some of the sensitive data and some valuable information such as billing information. Therefore addressing CSRF vulnerabilities are important.
Prevention Techniques to address the Vulnerability
All the security standards we are following in WSO2 are listed in this Secure Engineering Guide.
To address CSRF vulnerability mainly there are two popular mechanisms which are standardized in OWASP. Those are:
- Synchronizer Token Pattern
- Double Submit Cookie Pattern
Synchronizer Token Pattern
With Synchronizer Token Pattern, any state-changing operation requires a secure random token which is generally known as CSRF Token. CSRF Token is generated with a unique large random string generated per user session, using a secure pseudorandom number generator.
Once user session is created, per-session CSRF Token should be added to the server session as well. Basically, the storage of CSRF Token happens in the server session.
Generated CSRF Token should be added to all the forms, generating requests for state-changing operations, as a hidden input. The server should do additional validation and reject the request if the CSRF Token sent in the request does not match with the token available in the user session. In addition to forms, AJAX requests for state-changing operations should also include the CSRF Token.
Ultimately, the attacker will not be able to make a form submission to a protected application, since the attacker will need to know the per-session CSRF Token value which is stored in the server in advance, to craft an attack.
Double Submit Cookie
The difference between “Double Submit Cookie” and “Synchronizer Token Pattern” is that “Synchronizer Token Pattern” uses server session for storing CSRF Token, whereas “Double Submit Cookie” approach uses cookies to store the CSRF Token.
Upon user login, per-session CSRF token value should be generated and it should be sent to the browser as a cookie. The server may decide not to store the CSRF token value.
When rendering HTML pages with forms, client-side JavaScript should read the CSRF Token cookie value and inject the value all forms. In addition, AJAX requests should be modified to send the same value with AJAX requests.
When an application sends an HTTP request for a state changing operation (over HTTP method other than GET), the server should compare the CSRF Token received over the request cookies, with the CSRF Token value received in request payload (query parameter/post data). If values are not matching, the request can be identified as a possible CSRF attack.
If an attacker creates a forged HTTP request with the intention of performing a CSRF attack, correct CSRF Token value will still be sent in the cookie, but he will not have required cross-domain access to read the token value and inject same into the HTML forms.
How we have handled CSRF vulnerability in WSO2 products and solutions
We have followed WSO2 Secure Guidelines when addressing the vulnerability. WSO2 has mostly used Synchronizer Token Pattern as the prevention technique. But we had to add some customizations to the implementation method due to the Jaggery limitations faced with existing implementations.
In the code implementation, CSRF Token is generated with a unique large random string generated per user session, using a secure pseudorandom number generator. Then the CSRF Token is added to the server session as well as to the response cookie. Basically, the storage of CSRF Token happens in the server session.
Generated CSRF Token should be added to all the forms, as a hidden input. The server should do additional validation and reject the request if the CSRF Token sent in the request does not match with the token available in the user session. In addition to forms, AJAX requests for state-changing operations should also include the CSRF Token.
When all the pages are rendered, a CSRF token is generated (only if it’s already not available in the session) and set to the session as well as to the response cookie. When sending the request, we have done a custom implementation to intercept all the requests/form submissions and inject CSRF token to all the form submissions (with a hidden input field) as well as into AJAX POST requests using the value stored in the cookie.
When server-side receives requests, it validates those requests comparing the CSRF token value stored in the session with the value received from the request parameter. Requests are allowed to proceed further only if those values are matched. If not requests will be blocked and error messages will be generated.
References
https://www.owasp.org/index.php/Main_Page
https://wso2.com/technical-reports/wso2-secure-engineering-guidelines
