Security Think Tank: No quick fix to SQLi attacks

Opinion

Security Think Tank: No quick fix to SQLi attacks

In considering why SQL injection remains a successful way of attacking web applications, the answer is, as always, both simple and complex. Simple because it is nothing more nor less than poor coding practices. The more complex answer arises from answering the question: Why do so many web sites/applications suffer from poor coding practices?

From my own company’s experience, the issue of poor coding practices is not limited to the small and medium-sized enterprise (SME) web application development companies but is, sadly, across the board.  A lot of the errors lie in data input by a user not being effectively boundary checked or filtered. I suspect that there are very few web sites, if any, that need to accept user-entered data that include SQL commands and even fewer sites that need to accept an unlimited number of characters in an input string. The sad thing here is that many of the modern and well-used development tools include call-able routines that can undertake data bounding and filtering.

So where do we go from here? Unfortunately I don’t see a single answer nor do I see a quick fix. Some of the answers as I see them include:

• Training institutions should ensure that secure coding techniques are not just included in their course material, but that the reasoning behind the need for secure coding is also included.

• At the contract-letting stage, that is, when an organisation orders a web development from a third party, contracts should include clauses calling for code to be developed in accordance with Open Web Application Security Project (OWASP) or similar secure coding practices.

• Payment for developments should be done in stages such that a final payment will be dependent on a web development passing an IT Security Health check carried out by a specialist company with current Tiger or similar registration. But note that, to avoid disputes, the contractual clause should state that the delivered code should be free of known vulnerabilities at a point x working days before the agreed delivery date or agreed “go-live” date (where x could be, for example, five working days).

• Where an organisation is big enough to run its own development group, developers should be put through OWASP or similar secure-coding training.

• In-house developed code should be subject to detailed security testing preferably conducted by specialist companies with current recognised industry registration (e.g. Tiger or similar)

• All web sites should be subject to detailed security testing at least every six months and preferably more frequently. There are a number of specialist companies that offer automated testing that can be run daily or weekly. But even if these automated services are used, a specialist company should be engaged to run detailed security tests at least every 12 months (preferably every six months).


Peter Wenham is a committee member of the BCS Security Forum strategic panel and director of information assurance consultancy Trusted Management.

Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in September 2012

 

COMMENTS powered by Disqus  //  Commenting policy