Network News

X My Profile
View More Activity

Free Tools to Secure Your Web Site

Over the past six months, millions of Web pages have been hacked and seeded with malicious software, and in a great many cases the sites were hacked because their curators failed to put in place even basic database security measures.

In most of these compromises, the hackers broke in using an attack called SQL injection. Rather than attacking specific software security vulnerabilities, SQL injection attacks target configuration weaknesses in the database layer of the site's Web application, be it ASP, CGI, or PHP.

While most SQL attacks are automated with the help of scanning tools, SQL attacks can be carried out using nothing more than a Web browser. An injection vulnerability most commonly exists when a site accepts input from a visitor -- such as through a search or login box -- but fails to filter out potentially harmful instructions, non-standard characters or computer code.

Successful SQL attacks can force a site's database to cough up configuration settings, user names and passwords, or sensitive data that can help an attacker inject content onto the site.

There are several tools available to help protect Web sites from these types of attacks. One, a slimmed down version of a vulnerability scanner from HP called "HP Scrawlr," can give users an indication of whether their sites are susceptible to SQL injection. That tool is available via HP's site (free registration required).

A second piece of software, "UrlScan version 3.0 Beta," is a Microsoft tool that restricts the types of Web requests that Microsoft's Internet Information Services (IIS) Web server will process. The tool and more information about it can be found here.

The third tool is a Microsoft creation that can be used to sift through ASP code for avenues of potential SQL attack. You can learn more and download it at this link here.

Remember, even if your Web server and Web applications are fully up-to-date on the latest security patches, your site can still be victimized by a SQL attack. Also, most SQL attacks are nothing personal -- they're automated and opportunistic. So, if you run a Web site, consider learning about and using some of these tools to better secure your little corner of the Web.

By Brian Krebs  |  June 26, 2008; 1:54 PM ET
Categories:  Latest Warnings , Safety Tips  
Save & Share:  Send E-mail   Facebook   Twitter   Digg   Yahoo Buzz   Del.icio.us   StumbleUpon   Technorati   Google Buzz   Previous: Security Update for Adobe Reader, Acrobat
Next: Taming Internet Explorer Browser Plug-Ins

Comments

On my site using PHP and MySQL, I exclusively use prepared statements (using mysqli) for all database queries. These are immune to SQL injection attacks (AFAIK), saving the programmer from having to remember to escape any data input by the user.

Posted by: Greg | June 26, 2008 3:11 PM | Report abuse

As two of the three tools concern issues with Microsoft web 'technologies' is it fair to say it's mostly sites run by these Microsoft technologies that are getting hacked? I thought Microsoft's market share here was gratefully depleting towards zero, thank you. I for one would never run any Microsoft software online. It's an open invitation to the black hats. The GAO stated years ago government offices should not use Microsoft software online, claiming it was 'beyond repair'. I certainly agree.

Posted by: Rick | June 26, 2008 9:12 PM | Report abuse

Wordpress users (which is MySQL based) may find use for the Wordpress Exploit Scanner - http://ocaoimh.ie/exploit-scanner/ - which checks for dodgy looking code in the critical files of a WP install.

I'll be reviewing it on www.sciencetext.com soon, but would like to hear from anyone who has already tried it.

db

Posted by: David Bradley | June 27, 2008 4:38 AM | Report abuse

@Rick
SQL injection has nothing to do with the underlying technology. It's because of lazy or sloppy coders who concatenate text received from the user with the rest of their database requests, and pass it directly to the database. It's allowing anyone to run arbitrary queries against your database. Here's a recent example of SQL injection with some real world consequences:

http://thedailywtf.com/Articles/Oklahoma-Leaks-Tens-of-Thousands-of-Social-Security-Numbers,-Other-Sensitive-Data.aspx

..and the obligatory comic reference:
http://xkcd.com/327/

Posted by: Matt | June 27, 2008 7:16 AM | Report abuse

Any penetration testers... Fast-Track from SecureState is an awesome tool. It includes an automated SQL Injector that gains the attacker full remote root access over the affected underlying system, incorporates ease of use with integration into Metasploit's AutoPwn and creates a new client side attack utilizing iframes to launch a slew of exploits to unsuspecting visitors. Its available for download at http://www.securestate.com/Pages/Fast-Track.aspx

Posted by: Car Ramrod | June 27, 2008 9:40 AM | Report abuse

Any penetration testers... Fast-Track from SecureState is an awesome tool. It includes an automated SQL Injector that gains the attacker full remote root access over the affected underlying system, incorporates ease of use with integration into Metasploit's AutoPwn and creates a new client side attack utilizing iframes to launch a slew of exploits to unsuspecting visitors. Its available for download at http://www.securestate.com/Pages/Fast-Track.aspx

Posted by: Car Ramrod | June 27, 2008 9:40 AM | Report abuse

Gosh... I guess I'm just an old fashioned html kind of guy. My two web sites are straight up HTML and XML with the only possible response allowed from a visitor is "email me" - which obviously doesn't give access to the site itself.

If I were an online retailer, I'd be using some serious security - but I'm not.

Posted by: nofluer | June 27, 2008 10:00 AM | Report abuse

I agree with Car Ramrod, the automated scan tools are limited in ensuring true application security. Fast-Track(http://www.securestate.com/Pages/Fast-Track.aspx), for example in the hands of an experienced penetration-tester is magnitudes more effective.

Posted by: Jenkem | June 27, 2008 10:03 AM | Report abuse

Thanks for the other recommendations, people. Please keep them coming.

Posted by: Bk | June 27, 2008 10:54 AM | Report abuse

Matt> SQL injection has nothing to do with the underlying technology.

Unfortunately, however, the consequences of SQL injection on Windows are typically much more profound than on other platforms, thanks to the xp_cmdshell() function provided by MS SQL Server and variants.

Posted by: antibozo | June 27, 2008 4:13 PM | Report abuse

These tools are a must first step. They do protect against a majority of scanning tools. The seconds step I would say is to maintain active vigilance against hackers. You can get those steps from http://www.paloneks.ca to help you protect yourself against a root kit. But the tools described here are a first step in maintaining a good security policy. The beauty of these tools is not that they are free, but its the fact that they eliminate anywhere between 60% to 90% of automated scans. Excellent article, good work. Palonek http://www.paloneks.ca/ Palonek's security

Posted by: Palonek | June 28, 2008 12:37 AM | Report abuse

The problem with these automated scanners is similiar to the problem with spell-checkers. Spell-checkers, instead of improving people's writing, attempt, often incorrectly, to clean up spelling nits without cleaning up structure. This is bad because spelling errors tend to signify places in the text where the writer was inattentive, or committed an incomplete edit. These are the areas where one should examine the entire context more closely, but once a spell-checker has been run, the markers for these areas have been removed (unless you are lucky enough to spot an incorrect replacement word chosen by the spell-checker). Where the misspellings are actually the result of poor spelling, as opposed to typographical accident, the poor speller doesn't learn anything; spell-checkers just encourage poor spellers to go on being poor spellers.

As a code auditor, I have to look at a lot of bad code. When I see code written by someone who clearly doesn't understand basic principles of secure coding, I simply stop and tell the developers either to get some training or to go find someone else to rewrite the code. There's no point in my spending precious time enumerating vulnerabilities in these cases.

But if the developers use an automated scanner, they are likely to have fixed a lot of the blindingly obvious mistakes. You might think these means less work for me, but in practice what I end up seeing is code that is just as bad as before in terms of poor architecture, high level of redundancy, inadequate commenting, lack of data abstraction, etc., yet is curiously absent of the common injection vectors. This is worse for me as an auditor because such code is just as much work to go through as if it still had all the obvious problems, yet I can't as easily tell the developers to simply start over and do it properly.

Analogously, imagine the editor who has to deal with a lot of writers who have spell-checkers. Many of them make gigantic structural and syntactic errors in their writing, or just write badly, but they fix most of the spelling errors using a spell-checker. The editor still has to reject the work, but it takes a lot more examination to reach that conclusion if all of the spelling errors have been removed.

The sorts of problems that automated tools, especially scanners, find in code are almost universally trivial for a good programmer to spot on his or her own. There is a place for these tools, but when overused they just lower the bar on code quality rather than teaching people to be genuinely better programmers. Writing good code is difficult. In my experience, perhaps 20% of the programmers out there are capable of it, and even those often take foolish shortcuts instead of doing things the way they know is correct.

The best use of these tools is in the hands of an independent assessor who runs the tool and then provides a minimal report of the findings to the developer, without providing precise details of the successful attack vectors. This assures that the developer constantly strengthens his or her skill at identifying injection vectors; it's like telling a writer that there is a spelling error in paragraph three, but not exactly where, so that the writer has to proofread the context.

Posted by: antibozo | June 29, 2008 3:49 PM | Report abuse

The comments to this entry are closed.

 
 
RSS Feed
Subscribe to The Post

© 2010 The Washington Post Company