Lizamoon: will lessons be learned?

The recent massive SQL injection attack was a stark reminder of how slack coding practices can have sometimes devastating consequences

Lizamoon, the mass SQL injection attack, has reached epidemic proportions in recent weeks, with the malware infecting about four million web sites and returning more than 1.4 million results on Google at the time of writing. It has been hailed as the most widespread attack of its kind to date, and has even infiltrated iTunes, although it has so far been unable to infect users of Apple's flagship music store.

Its purpose is to spread a rogue anti-virus programme, which claims to find malware on its victim's PC. Once the user gives away his or her credit card details, the phantom problems are reduced, as is their bank balance.

As a form of attack, SQL injection has been around since at least 2005, and has been responsible for countless data breaches affecting organisations including the Royal Navy, MySQL.com and security firm HBGary, among others.

This is a form of cyber threat that has seen enduring success by attacking a wide variety of public and private bodies, so you would expect it to be a sophisticated attack requiring a skilled hacker.

But it isn't and it can be stopped with some fairly simple web coding, for example by automatically filtering user input.

As Vincent Delaroche, chairman and chief executive of software analysis and measurement firm CAST explains: "It's not difficult to code to prevent SQL injections. You just need to check the syntax of the user entry."

A hacker could look at a standard webform asking for his name and address in order to, say, subscribe to a magazine. But instead of writing "Jeremy Hacker, Moscow", he writes (or injects) a few lines of code. This code could for instance ask the database to email him a complete list of the usernames and passwords it manages.
Computer code tends not to resemble human language very closely.

It doesn't take DeepBlue to distinguish between:

"$query = sprintf("SELECT * FROM `Users` WHERE UserName='%s' AND Password='%s'","

And:

"Hello, my name's Jeremy"

So why is SQL injection arguably more potent than ever before? Are coders increasingly inept or lazy? Or does the problem lie further up the management chain?

Delaroche believes that the problem rests with the senior levels of IT management.

"Look at large companies in banking, retail or telecoms. Management doesn't ask the coders to code well because on the whole, management doesn't care," he says.
Delaroche explains that CIOs are more interested in functionality. Does the application work? They are not concerned with the details of the coding itself, even though those details may affect performance and security in the long run.

David Norton, research director at analyst Gartner, thinks this is only one side of the story, and that time and training play their part as much as management not being interested in coding. "The issue with software development is that coders do not have the time, or often the skills, to spot vulnerabilities or errors," he says.

Norton also blames waterfall-based project management methodologies, such as Prince 2, in which the testing phase is separate and distinct from that of development.

Norton suggests that an adoption of the agile methodology, in which testing is done after every coding change, would be a step in the right direction.

But he adds that errors will persist if teams are not given time to properly "sanity check" their work. He recommends two steps to improve code quality.

• Developers need to be trained in good design, and in spotting coding errors.

• Teams need to be allowed time both to spot and fix errors and vulnerabilities.
Delaroche also warns that poor coding can cost CIOs their jobs if improvements are not made.

"If a CIO goes in front of the CEO for the second time to say that a key project is delayed due to poor coding, they might well be asked to leave. The average tenure of a CIO is under two years."

And his point overall is that CIOs need to recognise that coding matters. He cites the example of AT&T, which was losing about £300,000 per hour each time its web site went down due to coding errors. Using CAST's tools to analyse its code, AT&T was able to more carefully describe its requirements to its outsourced coders.

To improve matters across the industry, he recommends that clearly defined rules are published and enforced, in much the same way as the financial sector is regulated now by the Financial Services Authority.

Second, coders need to be trained and given incentives.

"If a CIO introduced a bonus for abiding by these coding rules, developers would be more focused in their efforts to produce good code," he argues.