Cross Site Request Forgery (CSRF) is a type of attack used to compromise web applications. It is just one of several attacks which have been identified by the Open Web Application Security Project (OWASP). Its full description is as follows:
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.
In short, this requires the attacker to construct a malicious URL and send it to his victim who then activates the hyperlink. This causes the hyperlink to be executed in the victim's browser without him/her realising it. Note that the term "currently authenticated" can mean one of two things depending on the authentication method:
Note that the cookie option may not actually work as the act of clicking on a URL in an email may open a new browser window instead of a new tab in the current window, and the cookies which are available in one browser window may not be available in a different window. This means that the malicious URL will never be able to piggyback onto an exiting authenticated session even if a valid session name, which points to a session ID in the cookie data, is known.
Note that the SSO option may still use a cookie to store the valid session ID, but even if the malicious URL does not piggyback on a current session and force the user through the logon screen, the logon processing will automatically create a valid session using the user's OS logon details. Depending on how the application is coded the script which is activated after the logon process may or may not be the script indicated in the URL which was bounced back to the logon screen. For example, a malicious URL attempts to run the "Invoice Payment" script, but this is rejected and bounced back to the logon screen, but after accepting the user's credentials the logon screen automatically activates the Home Page and not the script which caused the bounce.
Certain security measures were built into the RADICORE framework when it was first created, and these measures already help to avoid various attacks.
Nobody can access the application unless they first pass through the logon screen using valid credentials. This will cause a new session to be created with a unique id and a cookie name which is not the default 'PHPSESSID'. The session data contains the user's name and Role details so that only those tasks which are permitted by those roles can be activated.
It is not possible, even for an authenticated user, to bookmark a page and return to the same page later on. Unless a URL identifies a valid session, and that session contains data used by the script in that URL (see browser's address bar below), that URL will be rejected. Even though a URL may be captured from a valid session, once a session has been destroyed on the server any reference to it is no longer valid.
The application may contain hundreds or even thousands of tasks (user transactions), but the inbuilt Role Based Access Control (RBAC) mechanism restricts a user's access to a limited subset of the available tasks. This means that when the framework constructs the links in each page, any which point to a task which is not on the user's access list will be dropped from the display. Thus users will never see any options which they cannot access, and if they cannot see a link they cannot select it. Even if they try to enter the link in the browser's address bar the system will still check that the task is accessible by the user, and if not they will be kicked back to the logon screen.
A URL, such as that which can be typed into a browser's address bar, can only send a GET request to the server. All database updates use the POST method which uses a SUBMIT button within an HTML form, and this cannot be duplicated in a browser's address bar. Any operation activated by the GET method will retrieve data from the server and send it to the client's browser as an HTML form, a CSV file or a PDF document.
All operations which perform database inserts, updates or deletes are done in two steps. First, a GET method in which an HTML form is constructed on the server and sent to the client's browser. The user then reviews the form, makes any changes, then presses a SUBMIT button to send confirmation of the desired action to the server using the POST method.
The identities of any objects in the database, such as account numbers or names, are never exposed in any URL. This means that a URL such as
http://bank.com/transfer.do?acct=BOB&amount=100is never used and therefore cannot be spoofed. Whenever primary keys are passed from one script to another it is done in the session data on the server.
An operation such as "Pay Invoice" must first be given the identity of an invoice before it can proceed. This is done in several steps:
Once a user has started a valid session by passing through the logon screen onto the Home Page the only way to activate a new task is either via a menu button, a navigation button or a POPUP button. This will cause the current script to be reactivated so that it can create an area in the session data to hold parameters for the selected script before that script is activated.
When a script terminates its parameter area in the session data is destroyed so that it cannot be reactivated unless it is available from a new link in the current page. If the script is selected again a new parameter area will have to be created.
If a menu button is used in a non-menu web page, then that script is terminated. It will disappear from the "breadcrumbs" area and be replaced by the selected menu.
If a navigation button is used then the current script is suspended before control is passed to the requested child script. The identity of the child script will then be appended to the list in the "breadcrumbs" area.
When the child script terminates by using a button on the action bar its parent will be woken up from its suspended state, thus allowing it to continue from where it left off. Any pagination or scrolling options which were in force when the script was suspended will be reinstated.
If a script is currently visible in the "breadcrumbs" area of the menu bar it is suspended and can be reactivated. It will not require a new parameter area in the session data to be created as one will already exist.
Although the existing measures may seem adequate, there is no harm in going one step further. Consequently I have added code to version 2.07.0 of the framework to implement the solution described in Good Patterns and procedures to prevent CSRF by adding a new anti-CSRF token to each request. This token is not per-session, it is per-request, so even if an attacker could sniff the network traffic and extract the token from a valid request this token could never be used more than once.
For those controls which use the POST method a single token is supplied in the FORM element.
For those controls which use the GET method a separate token is supplied in the hyperlink.
All tokens are generated from a random sequence by the framework and built into each HTML form during the XSL Transformation process, and then stored in the session data. Note that as each new web page is displayed all stored tokens which were generated by previous pages are destroyed, thus making any links which use those tokens invalid. As each script is activated the token included in the URL is compared against the token for that script in the session data, and only if the two match is the script allowed to continue, otherwise it will be terminated and kicked back to the login screen.
All this activity is automatically performed by the framework, so there is nothing that the developer need do.