This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Reviewing code for Cross-Site Request Forgery issues"
(New page: OWASP Code Review Guide Table of Contents__TOC__ == Introduction == Cross-Site Request Forgery (CSRF) attacks are considered useful if the attacked knows the target is authenticated t...) |
|||
| Line 15: | Line 15: | ||
==How to locate the potentially vulnerable code== | ==How to locate the potentially vulnerable code== | ||
| + | This issue is simple to detect but there may be compensating controls around the functionality of the application which may alert the user to a CSRF attempt. | ||
| + | As long as the application accepts a well formed HTTP request and the request adheres to some business logic of the application CSRF shall work (From now on we assume the target user is logged into the system to be attacked). | ||
| + | |||
| + | By checking the page rendering we need to see if any unique identifiers are appended to the links rendered by the application in the users browser. (more on this later). | ||
| + | |||
==Vulnerable Patterns for CSRF== | ==Vulnerable Patterns for CSRF== | ||
Revision as of 09:02, 1 August 2007
OWASP Code Review Guide Table of ContentsIntroduction
Cross-Site Request Forgery (CSRF) attacks are considered useful if the attacked knows the target is authenticated to a web based system. They dont work unless the target is logged into the system and therefore have a small attack footprint. In effect CSRF attacks are used by an attacker to make a target system perform a function via the targets browser without knowledge of the target user, at least until the unauthorised function has been comitted.
How they work:
See:
for a more detailed explaination but the main issue is the sending of a rogue HTTP request from an authenticated users browser to the application which shall commit a transaction without authorisation given by the target user. As long as the user is authenticated and a menaingful HTTP request is sent by the users browser to a target application the application does not know if origin of the request be it a valid transaction or a link clicked by the user (that was say, in an email) whilst the user is authenticated to the applications. So, as an example, using CSRF an attacker make the victim perform actions that they didn't intend to, such as logout, purchase item, change account information, or any other function provided by the vulnerable website.
How to locate the potentially vulnerable code
This issue is simple to detect but there may be compensating controls around the functionality of the application which may alert the user to a CSRF attempt. As long as the application accepts a well formed HTTP request and the request adheres to some business logic of the application CSRF shall work (From now on we assume the target user is logged into the system to be attacked).
By checking the page rendering we need to see if any unique identifiers are appended to the links rendered by the application in the users browser. (more on this later).
