Data Management

Is your site safe from SQL injection attacks?

Microsoft and HP announced yesterday that they are providing free tools to help network administrators to deal with the increase in SQL injection attacks over the last six months.

Microsoft and HP announced yesterday that they are providing free tools to help network administrators deal with the increase in SQL injection attacks over the last six months.

"We released two new tools, and HP has released one, to help administrators discover flaws so that they can mitigate attacks," said Mark Miller, director of Microsoft's Trustworthy Computing product management.

The problem lies in hackers' ability to create malformed database requests that end up "injecting" SQL commands where only usernames and passwords should be. Although Microsoft claimed that their IIS software is not vulnerable, they cautioned developers to follow their guidelines when designing sites that use back-end databases. Thankfully, the new tools should help developers identify problems in the sites they design before the vulnerabilities are exposed on the internet.

Microsoft, HP Ship Free Tools to Protect Web Sites from Hackers (Computerworld)

Programmers have the ability to avoid SQL injection attacks by requiring "strongly typed" usernames and passwords in order to avoid the malformed login information. Unfortunately, it appears that many developers do not write their code in this way, given the large number of sites that have been compromised, including the United Nations' Web site. The major problem is that these attacks allow hackers to hijack legitimate Web sites to deliver their malware, bypassing suspicions that most users have of sites that are not well known.

SQL Injection Remains Scary Back-Door Security Threat (InformationWeek)

Michael Howard on SQL Injection and My Concerns on the Most Recent Attacks (ZDNet)

'Legit' Website Compromises Reach Epidemic Proportions (Channel Register)

These attacks seem to follow the same pattern as most problems with vulnerable software. Most of the time, it is not zero-day attacks, or attacks based on brand-new vulnerabilities, that cause the biggest problems. Usually, it is attacks based on vulnerabilities that have been known and sometimes patched months before. I remember when the SQL Slammer worm hit, because I was on vacation in Las Vegas at the time, but my systems were safe because that attack was based on a vulnerability for which a patch was released nine months earlier. Have you looked at your systems to see if you are vulnerable to a SQL injection attack?

14 comments
Jaqui
Jaqui

since ANY decent programmer / site developer would take the simple steps needed to do so by implementing one policy in their code: trust no user input. but with the increasing reliance on client side processing, they forget to test for that on either client or server side. until all site scripts treat all input as untrusted we won't get away from these attacks.

Andy J. Moon
Andy J. Moon

Does your site depend on a database? If so, have you done what is necessary to mitigate these kinds of attacks?

Justin James
Justin James

Anyone who leaves a SQL injection hole in their application should first be fired, and then entered into a public registry, like a sex offender registry, but for "programming safety". All employers should be able to check this registry and see if the person they are interviewing is dumb enough to leave one of these holes in their code. J.Ja

Tony Hopkinson
Tony Hopkinson

securing yourself against this type of attack is trivial. Unfortunately it's academia and shake and bake guides that still fall into this trap more often than not. A lot more ignorance than stupidity involved.

Neon Samurai
Neon Samurai

That's pretty harsh but I guess it's not like vetting field entries before post/get is all that hard is it. I may have suggested it simply be become required company practice to test against SQL injection before code goes live but it's not like that's working out so well currently; injection keeps happening after all.

Justin James
Justin James

... defending against this is not a drop more difficult. A *huge* part of the problem are the 3rd party libraries (often found in AJAX libraries). Because they are designed to be deployed with minimum effort, they tend to not use stored procedures, which means that you are then counting on the library to not have any "SQL Statement Building" occuring in it, and to use the languages parameterization tools. There's nothing wring with that, of course. But my experience has been that just because someone can put together a snazzy Web UI widget does not mean that they "get" security or SQL. The fact that I've found SQL injection attacks in WordPress *just by using it like an ordinary user* goes a long way in showing just how bad a lot of programmers are. In terms of bulnerability testing, a lot of them use tools like WebSense or similar tools. WebSense is surprisingly thorough, and quite good at finding the common, run of the mill mistakes like cross site scripting and SQL injection. Its not perfect, I've seen software pass its test that I knew of tons of security holes, but it definitely catches a lot. J.Ja

Tony Hopkinson
Tony Hopkinson

They don't know that parameterised queries are a defense against injection attacks, so they don't see any reason to use them in preference to building a command string from user input...

robo_dev
robo_dev

If everybody were developing simple html pages, then good programming habits and testing can snuff SQL injection out. The issue, in my mind, is that more advanced and complex techniques, such as Ajax, or more powerful tools such as content management systems that can put a horribly complex website into the hands of a moderately competent developer, present a moving target from a web app vulnerability standpoint. The bigger issue is how companies do their web app vuln testing? Manually with tools, using automation, hiring others? I have done a lot of both, and each approach has it's merits. Good article on SQL injection http://www.acunetix.com/websitesecurity/sql-injection2.htm

Justin James
Justin James

I actually think that this is one area that the shake 'n bake programmers do well. After all, someone hammered into their head to use parameters, and we know how they can't deviate from what they were taught. :) To me, the problem are the people who got started in places without string mentoring. That is a hallmark of off shore development from what I have seen, no mentoring. So what you get is 200 programmers making rookie mistakes all of the time, and there might be 3 people in there who know what they are doing but they won't share it with anyone else. :( J.Ja

Neon Samurai
Neon Samurai

One of the best and probably almost mythical buffer overflow stories I've read is the storey of Mel. Even if it's completely fabricated, it's a pretty clear description of the results if not the cause. http://www.catb.org/jargon/html/story-of-mel.html In terms of SQL. I'm guilty. I know enough of it to use a visual editor then adjust it by hand. Long ago I wrote simple queries for use behind forms used internally at a reselling and hosting company. If I could go back, I'd be curious to know how open that code really was. These days, I don't end up writing too much SQL but doing all the preflight checks in the PHP is important. While I can write some basic queries, I've seen what a real DBA can do with it; way above my level. I see the difference between the two you speak of though. While some programming languages do much better to avoid overflows, it can happen as a quick mistake on a coding binge or when rushing to meet a deadline. With injection, the ideal is not touching the database unless your the DBA. The minimum due diligence should be validating all form input. The middle ground may be to have the DBA write the SQL for the developer writing the form code.

Justin James
Justin James

... is that a buffer overflow can be created by a "fat finger" mistake, or simply miscalculating something in your head, or changing the size of one thing without changing a loop somewhere else if the length was supposed to be hardcoded. Even the most expert of programmers fall into these pitfalls. SQL injection attacks, on the other hand, require a deliberate decision at the architecture level (even if it is just the architecture of 10 lines of code) to enable. The best solution that I have found is to have the DBA remove all SELECT, INSERT, DELETE, UPDATE, etc. access to the app's user, and *only* allow that user to run stored procedures. For bonus credit, edit the DB so that only the DBA (who actually *knows* SQL instead of using some lame visual SQL designer, which is how too many programmers generate SQL since it is not their specialty) is allowed to create stored procedures. Yes, it creates a Dilbert level of beuracracy (having to go to the DBA for every little stored proc), but it ensures that everyone is properly parameterizing everything and that the queries and such are not total garbage that will crush the server (see: programmers forgetting to use "nolock"). J.Ja

Neon Samurai
Neon Samurai

It's not that they are new, it's that they won't seem to go away. Sure, at one time you could make valid use of a buffer overflow too end a loop instead of "endif" or similar but today both are just too easy to fix.

Justin James
Justin James

Yeah, it's not like I suggested it for people who, say, create race conditions only when the semaphone that controls the number of concurrent threads reaches the maximumn size for an integer, or something equally tricky to work with. I mean, this is something that I was hearing about in 1998 or so, when I first started working with Web apps in earnest. And I am sure that people were talking about it before then! J.Ja