Security Advisory Update (XSRF issues)

[Chris Travers <..hidden..>]

Hi all:

Secunia has listed the XSRF issues (which are systematic in the legacy codebase) as "partially fixed."  I want to take a moment to explain what their concern is, what mitigating measures can be taken in production versions, and what the risks are.  I will also explain what we are doing in the future to address the issue.

Status:
 * Easily exploited cases are fixed in latest patch.
 * Very complex to attack
 * Successful attack is fairly severe
 * Risk can be mitigated to a large extent.

XSRF is a type of attack where a third party web page fools a browser into making requests to the application that appear to be valid.

The general risk is that an individual in a bookkeeping department, colluding with someone with substantial technical knowledge and either working on a company intranet site OR compromising an important third party web site could use this to falsify financial data by tricking other users into entering information for them.  This could then be used to cover embezzlement activities and the like.  Any vulnerabilities that are of this nature we consider substantial given the nature of this program.  Unfortunately a fix isn't trivial and would probably break things.  Nevertheless, I will probably create a referrer-checking patch that can be optionally installed to prevent this sort of attack absent unusual circumstances.  I also expect we will make full fixes for the issue (described below) required for 1.3.

The general requirements for an attack of this sort is to create a malicious web site that members of the accounting department come back to visit for an extended period of time.  It also requires deep insider knowledge of the internals of the accounting database (for example, which id numbers correspond to which entries).  For this reason, the complexity involved in a successful attack is really very high.  Web mail programs might provide some additional vectors, but even there, with proper configuration, the chance of such a sustained attack being both successful and undetected would be far lower.

For this reason, we consider the vulnerability to be a substantial problem but not one sufficiently severe that everyone should be overly worried at this point.

For versions of 1.2, my recommendation is to set the timeout value for each user to the minimum practical value (perhaps 60, 120, or 180, timing the session out after 1, 2, or 3 minutes respectively).  This can be done from the admin page or the psql prompt.  This is important because a successful attack would require many successful exploits of this vulnerability.  If any significant set fails, then, in all likelihood, routine accounting audits and reconciliation will pick up the misbehavior.  Please stay tuned for a referer-checking patch, as well.

This is not (generally) an exploit that could be exploited by customers seeking to record bogus payments and would really require inside access to be a problem.

Combined with standard accounting controls, a low timeout should be sufficient to prevent problems arising from this vulnerability.

For versions of 1.3, we expect to resolve this issue the following way:
1)  All forms will have a 'form_id' attached which will be pseudo-randomly generated.
2)  When a form is submitted, the form_id will be checked against what's stored in the db for that user and if authenticated will be processed normally.  If the form can be double-submitted (for example, to print an invoice as opposed to posting it), the form will be left associated with the user.  If the form cannot be, it will be deleted from the db when the form is processed.  This will make XSRF impossible in a reliable way because it will require guessing the form value.
3)  When a session times out, the associated forms will be lost.
4)  If the form submitted is not associated in the db, a message is logged, and the form is updated with a new form_id and sent back to the browser.

If anyone has specific concerns, feel free to email me.

Best Wishes,
Chris Travers