If you are not already familiar with Cross-site Request Forgery (CSRF), we suggest you first read the article entitled: “What Is Cross-site Request Forgery (CSRF) ?“.
Detecting Cross-Site Request Forgery
Our goal in detecting Cross-site Request Forgery (CSRF) vulnerabilities within a web-application is to determine whether HTTP requests representing critical and significant transactions will be honored by the application even if they do not originate with the application’s client interface.
Following successful authentication, requests that meet the “significant transaction” and “transparent” criteria defined in “What Is Cross-Site Request Forgery (CSRF) ?” should be tested to see if they can be activated without the client interface.
It is for this reason that detecting Cross-site Request Forgery (CSRF) is greatly facilitated with the use of a web-proxy. A web-proxy is an application that we can run on the client to intercept, inspect, and potentially modify HTTP requests from a web-browser and the corresponding responses. Examples of web-proxys include Fiddler, Tamper Data (Firefox plugin), Tamper Chrome (Chrome plugin) and Burp Proxy (part of Burp Suite).
A web-proxy allows us to easily capture HTTP requests and resubmit them (i.e. replay them) to the application without interacting with the application’s client interface. The successful replay of an HTTP request that results in a significant transaction indicates a potential Cross-Site Request Forgery (CSRF). We stress “potential” because the ultimate determination of whether application behavior truly represents a Cross-Site Request Forgery (CSRF) vulnerability depends on the business impact of that type of transaction.
Some example transactions that would likely be considered security vulnerabilities were they deemed achievable through CSRF include:
- Change login credentials such as passwords, email, secret questions/answers etc.
- The execution of financial transactions
- Creating new users, enabling/disabling accounts or access, or modification of permissions
While other transactions that might NOT be considered security vulnerabilities (were they deemed achievable through CSRF) include:
- Changing user preferences such as colors, fonts, etc. (low impact)
- Retrieving a list of customers, widgets, inmates, etc. (attacker has no access to response)
In summary, our strategy for detecting Cross-site Request Forgery (CSRF) vulnerabilities boils down to the following steps:
- Determining which requests supported by the application meet the “critical” transaction requirement
- Determining which of those requests can be activated without using the application’s client interface
For insight into how to avoid and/or fix Cross-site Request Forgery (CSRF) vulnerabilities, see the article entitled: “How To Prevent Cross-site Request Forgery (CSRF)“.
About Affinity IT Security
We hope you found this article to be useful. Affinity IT Security is available to help you with your security testing and train your developers and testers. In fact, we train developers and IT staff how to hack applications and networks.
Perhaps it was a network scan or website vulnerability test that brought you here. If so, you are likely researching how to find, fix, or avoid a particular vulnerability. We urge you to be proactive and ensure that key individuals in your organization understand not only this issue, but also are more broadly aware of application security.
Contact us to learn how to better protect your enterprise.
Although every effort has been made to provide the most useful and highest quality information, it is unfortunate but inevitable that some errors, omissions, and typographical mistakes will appear in these articles. Consequently, Affinity IT Security will not be responsible for any loss or damages resulting directly or indirectly from any error, misunderstanding, software defect, example, or misuse of any content herein.