SQL injection vulnerability fixed

Some of you might be already aware, that over the Christmas break we have been notified by Rory O'Connor from the Erasmus University Rotterdam as part of a security sweep of the application about vulnerability in the tool. In this brief blog post, we explain what the issue was, that we fixed very quickly and l want to re-assure all that none of our users’ data has been at risk here.  

As is normal in websites, we check the input from forms etc for sanity and integrity to make sure they make sense and that there is nothing harmful in them. It was discovered that the sort_field parameter used in many of the tables on the site was not as tightly checked as we would have liked. The sort_field parameter should be of the form "tablename.columnname" e.g. "template.title" or "plan.updated_at". The actual validation was checking the "tablename.c" part but not checking all that was there. Because of the looseness of the check someone malicious could insert something else along with the sort_field. This is referred to as an SQL Injection attack. This can be quite serious but in this case because of the vulnerability was in a sort parameter, that makes it harder to launch a damaging attack. The parameter is now properly secured and so this vulnerability is no longer there. We have checked our logs thoroughly and found no evidence of this vulnerability having ever been used. But it's good to get it uncovered and fixed. 

What has been done during the fix is that our main software engineer tried exploiting the vulnerability on one of our test servers and he could at best cause a delay the query which would only affect the person making the query and cause the query to time out. He could not come up with an example which extracted data from the database or damaged data in the database. This doesn't mean it isn't possible but given the lack of evidence that the exploit had been used and the failure to come up with an example that did harm, we are reassured that this potential exploit has not been used for harm. 

In addition to the above we are undertaking a sweep of the codebase to look for any other similar examples of potential vulnerabilities. While we have regular checks for parameters in place, they left a possible hole by not tethering a regular expression to the end of the parameter. We will be reviewing this, our existing checks and any further issues with form submission we can find. 

We would like to say thank you to Rory for notifying us about the vulnerability as well to Ray Carrick for working hard over the Christmas break to test and fix the issue.  

Should you have any further questions please do not hesitate to get in touch with us at dmponline@dcc.ac.uk  

Yours

DMPonline Team