Microsoft SQL Injection Prevention Strategy

Published: 2008-06-24
Last Updated: 2008-06-24 22:17:41 UTC
by Jason Lam (Version: 1)
2 comment(s)

Microsoft released a security advisory today in reaction to the mass SQL injection exploitation on the Internet. Unlike most other Microsoft's security bulletins and advisories, this one isn't about Microsoft products. In the advisory, "These SQL injection attacks do not exploit a specific software vulnerability, but instead target Web sites that do not follow secure coding practices for accessing and manipulating data stored in a relational database." 

Aside from providing links to information on SQL Injection, Microsoft recommends three approaches to help mitigate SQL Injection.

1. Runtime scanning

HP trimmed down a version of the WebInspect scanner to look for SQL injection vulnerabilities on a running website. Please note this scanner is very basic and should be used for a quick inspection only. I like the fact that the scanner has ability to dump table names, helps eliminate false positives.

2. URLScan

Microsoft's basic Web App Firewall solution. It has capabilities to block unwanted requests. This should only be used as a proactive measure or as emergency fix (short term) for SQL injection vulnerabilities.

3. Code Scanning

MS released a nice ASP source code scanning tool to look for SQL injection flaws. It is focused on SQL injection and seems to produce very few false positives which could be a problem with a lot of code scanners.

You may ask, runtime or code? The answer is both if you can do it. For example, if the ASP file calls a store procedure in the database and then the store procedure perform an exec and concatenate strings to run SQL within the database, code scanning will not flag this problem because the ASP code looks fine (only the store procedure is the problem). Conversely, runtime scanning can miss some portions of the site because this specific version of scanner do not follow Javascript and do not submit POST request during spider process.

Kudo to Microsoft for releasing the tools and information to help developers fix their apps. Also appreciate the free scanner from HP.


2 comment(s)

Podcast Episode Seven Record Notice

Published: 2008-06-24
Last Updated: 2008-06-24 21:20:43 UTC
by Joel Esler (Version: 1)
0 comment(s)
Hey all, just to let you all know Johannes, Paul Asadoorian, (Of PaulDotCom Security Weekly fame) and I will be recording the Internet Storm Center Podcast (Episode 7) tonight at 7:30 pm EDT. 

I'll be broadcasting it live on Stickam (Ustream seems to be having issues today):

Paul, Johannes, and I all have stickam accounts and we will all have live video and audio during the podcast, so you will be able to see and interact with all of us!

See you there if you can make it, we want to see if we can get a good amount of live listeners when we do the podcasts, stickam has a chat interface so you can give us LIVE feedback on the topics we are discussing on the podcast.

If you don't want to sign up for an account on Stickam, don't forget our IRC channel on, #dshield.  So come and hang out, talk with us about topics, live!


Joel Esler

Keywords: podcast
0 comment(s)

SQL Injection mitigation in ASP

Published: 2008-06-24
Last Updated: 2008-06-24 21:20:22 UTC
by Jason Lam (Version: 1)
0 comment(s)

With the recent SQL injection attacks on ASP pages. A lot of our readers are scrambling to find fixes for their applications. ASP is an older generation Web scripting language would require a bit more work to prevent SQL injection from happening. One of our reader Brian Erman has written a function to filter out the SQL keywords and also escape some the metacharacters in SQL to prevent SQL injection. from happening.

I have been asked a few times recently just how safe is escaping data before passing to SQL server. The answer is safe but it's not fool-proof, some of the issues have been documented by Chris Anley in his Advanced SQL Injection In SQL Server Application paper. Essentially, escaping input is making bad input less bad, so it's not ideal.

To stop SQL injection at the root, we have to understand that SQL injection happens because the database cannot effectively distinguish between static portion of the SQL statement and the user input. If there is a way we can tell the database - this is static SQL statement and this is user input, SQL injection could be stopped easily.

In actual fact, such mechanism exists, it is called parameterized query. The user input are passed to the SQL server as an argument (sort of like calling a function in programming language), the SQL server during query execution have a way to identify what part of the statement is static control, and which part is user input.

Parameterized queries have been widely publicized, examples are here and here. In classic ASP, parameterized query is possible if you use ADO command object, an example is here. Parameterized query is available on most other web scripting platforms, now is the time to review all your web app before the automated SQL injection exploitation spreads to other language platforms (PHP, CFM, PL)

Want to learn more about SQL injection mitigations? At SANSFIRE,, we will debut our new class, SEC522 "Defending Web Applications". Its an updated version of SEC519 ("Web Application Security") and now covers web services and other new topics.




0 comment(s)

Adobe Reader and Acrobat 8.1.2 Security Update

Published: 2008-06-24
Last Updated: 2008-06-24 02:59:26 UTC
by Jason Lam (Version: 1)
2 comment(s)

Adobe released a security update today for Acrobat and Reader 8.1.2. It fixes a vulnerability which allows remote attacker to execute malicious code. This is likely to appear in a malware spreading website near you soon given the track record of the botnet operators. Suggest update this one as soon as possible,


Keywords: Acrobat
2 comment(s)


Diary Archives