CSRF is an attack that forces the victim user to execute unwanted actions on a web application that they are currently authenticated to. This attack specifically targets state-changing requests, such as Create, Read, Update and Delete requests, from the legitimate user on the application. Applications that have any kind of form fills are susceptible to this attack. A successful attack can enable the attacker to manipulate user data, alter user privileges, or even compromise an entire application. And while the OWASP Top 10 has not included Cross-Site Request Forgery in its latest (2017) list, we still believe that CSRF is a key flaw in many apps that we test.CSRF flaws are patched in many ways depending on the application architecture or tech-stack. But, there are three approaches that are most commonly practiced by developers that are not as effective as it appears; namely the Encrypted token, CORS Headers usage, and using Viewstate as CSRF token.
The Encrypted Token Pattern is one of the common remedies against CSRF attacks. However, if this is not implemented properly, with the right configurations, the approach becomes in effective.
Encrypted Token pattern uses an encryption validation method to authenticate requests rather than multiple tokens. After successful authentication by the user, the server creates a unique token comprised of the user's ID, a timestamp, and a unique key available only on the server. This Token is returned to the client and embedded in a hidden field. On receipt of this request, the server reads and decrypts the Token value with the same key used to create the Token. Inability to correctly decrypt indicates an intrusion attempt. For instance, a developer might choose to use HMAC-SHA1 to sign the user-generated values and generate the token.
Example:
CSRF Token = HMAC-SHA-1(‘secret key’ + user ID + timestamp)However, the security for this method relies heavily on multiple variables:
The cryptographic function used to create the token needs to be of a high quality. We have often observed that developers use simplistic Base64 encoding to generate what they believe to be “high-entropy” tokens. This can be devastating, as attackers can now easily compromise the authentication system using forged tokens. If hash functions are being used, then its highly recommended to use SHA2 and above with salts.
If encryption or HMAC is used to generate the token, one should ensure that the key is a strong, pseudo-random value that is not easily guessable. Once the attacker identifies the key used to generate tokens, it is trivial for the attacker to forge tokens.
Several developers also believe that Cross-Origin Resource Sharing (CORS) headers are another way to completely mitigate CSRF attacks. Cross-Origin Resource Sharing is a method that allows a web page to access resources outside the domain from which the page is being loaded. It defines how browsers and server can interact to determine whether or not it is safe to allow the cross-origin request. If the header is set by the server in its HTTP response, modern browsers are designed to honor the Header by ensuring that requests from outside the specified URIs cannot make requests to the application.
Developers commonly implement CORS as means to defend against CSRF attacks. It is done so, under the assumption that the browser header validations of requests are enough to mitigate such attacks. This is implemented without giving enough attention to properly configuring the CORS Header. While CORS headers usage does reduce the attack surface, the misconfigured implementation of CORS is powerless against a CSRF attack.
Image 1
Image source - mozilla.org
In the given image, for example, the response with “Access-Control-Allow-Origin: *” to a simple request shows the header configuration is set so that the domain can cross-sharing from all domains which includes a potential request from a malicious site.
The best way to go about mitigating CSRF through CORS headers is to whitelist domains and also validate the referrer header. For example, configuring headers to “Access-Control-Allow-Origin: examplesite.com” will restrict the application from cross-sharing with any other domains than examplesite.com.For proper implementation of CORS, please check the below image
(image 2). Image 2
Image source - mozilla.org
For web applications that are developed on ASP.NET technology, many developers usually use the ASP.NET ViewState as a token to mitigate the CSRF vulnerability. The ViewState Token is a mechanism built into the ASP.NET platform for persisting user related and sensitive data. Per this mechanism, the data is serialized and transmitted in a hidden field to the request origin, where it is then deserialized before the application fetches the data. This gives a certain layer of security due to the serialization of data during transmission.
VIEWState by itself does not prevent CSRF Attacks. This is usually aggravated when developers fail to turn on the VIEWStateMAC property that validates the signature of the token on the server-side. With the VIEWStateMAC disabled, attackers can forge the data in the VIEWState
The Best approach to deal with this flaw is proper configuration. In the web forms, you should use ViewstateUserKey properties to store unique token value, which is unique per session. You should also enable the ViewstateMAC along with the antiforgery token. The ViewstateMAC should be enabled. Viewstate must be unique to every Session object on the Server-side. In addition, Viewstate must use strong encryptions that cannot be easily guessable.
In the midst of fixing and enhancing features of an Application, developers can fall into the trap eas-to-fix solutions. This can be futile since improper configurations and settings on the fixes can keep the application vulnerable. Cross-Site Request Forgery is a serious flaw and has the potential to compromise your whole application. It is essential to fix it and fix it properly.
The above mentioned three common mistakes are simple, yet necessary to take into account to successfully deter against CSRF attacks.
