News

Web Developers Left Holding the Bag on SQL Injection Attacks

• By Jabulani Leffall
• April 29, 2008

"The attacks are facilitated by SQL injection exploits and are not issues related to IIS 6.0, ASP, ASP.Net, or Microsoft SQL technologies," wrote Bill Sisk, a communications manager at Microsoft, in a blog post late Friday night. "SQL injection attacks enable malicious users to execute commands in an application's database."

Sisk wrote further that to stave off such attacks against the SQL app, developers should "follow secure coding practices," which to some observers implied that many Web developers had not been employing such methods.

Whatever the case may be, the continued delicate nature of security around SQL underscores what IT security pros have been saying for the last 12 months: rather than the operating system, it's all about protecting the applications that sit on it and by extension the data contained therein.

Similarly the industry's database giant, Oracle chimed in on the subject on Monday when it identified similar vulnerabilities affecting its enterprise resource planning and database programs. The problem was described by Eric Maurice, manager of Oracle's Global Technology Unit, in a blog post on Monday.

"In simple terms, SQL injection attacks are designed to leverage improper coding of database-powered applications that, in the absence of proper input validation, allow a malicious attacker to insert string input to an application," he wrote.

Maurice surmised that in each individual case, the attacker injects or pushes through commands that will be executed on the back-end database. The commands either muck up the front end interface -- what the end user sees on the screen -- or make the data unusable and perhaps even crash the system.

"The consequences of successful SQL injections can be severe," he wrote.

Identifying the problem as a "code issue" is the easy part, but fixing it won't be a cakewalk for developers, according to security experts and software company officials.

"These attacks really show the need for properly securing the SQL Server and for following secure SQL coding techniques," said Eric Schultze, chief technology officer of St. Paul, Minn.-based Shavlik Technologies. "Unfortunately, secure SQL coding techniques are not for the faint of heart. Microsoft and others provide guidance on how to code against these types of attacks. However, it's not a simple set of steps."

The problem lies not with the Web servers or middleware application servers. It's in the custom application code, which varies in any given enterprise and which may connect with multiple applications.

Developers need to understand that it's a brave new world, according to Andrew Storms, director of security operations at nCircle Inc. in San Francisco.

"The early days of writing Web applications, what we called CGIs back in the early 90s, we always lived by a single simple truth -- never trust user input," Storms said. "It seems now that Web application developers have forgotten this golden rule and have been lazy, allowing sanity and security checking to be performed by some other library or module. Combine this with fancy Web applications and Web services and the result is what we see today."

For this reason, Storms and others argue, there are loads of Web sites vulnerable to any number of Web-based attacks, such as SQL injection, cross-site scripting and cross-site request forgery.

The variety of potential problems adds to the mystery.

"At this point we really don't know exactly if the problem at hand [this week] is due to a Microsoft bug or poorly written application code," Storms said. "The more likely answer is that the attack vector of these Web sites varies just enough from each site that it's making things difficult to pinpoint a single root cause."

IT pros may need to ramp up IT risk management and application-level access controls, experts say. Such a process involves continuous vulnerability assessment, as well as Web application risk profiling. It's best to start such a process from the beginning of code development all the way into preproduction, scanning Web applications for potential risks.

The amount of at-risk Web sites cited this week -- somewhere between 200,000 and 500,000 Web sites -- is an "egregious number," according to Storms. Such figures are not as imposing as numbers "like one million to ten million storm worm bots back in 2007," Storms said, adding that "these SQL incursions are an entirely different breed."

The attacks are sobering news, he added.

"The reason for such controversy here is that this instance is a difficult fact to swallow," he said. "To the average unsuspecting Web surfer, the risk that they could be hit by some drive-by malware has now increased significantly. We used to tell our older relatives to only surf trusted Web sites and don't click on e-mail links, but that kind of advice is becoming less and less foolproof."