May 31, 2008 | SQL Server

More on the recent rash of SQL injection attacks (update 6/3)

Fellow MVP Steve Kass and Microsoft's Buck Woody have some links and advice about preventing SQL injection attacks not only from affecting your data but also from affecting your users.  You can see the information here:

http://stevekass.com/blog/2008/05/31/read-this-if-you-serve-up-web-pages-from-sql-data/

And here:

http://blogs.msdn.com/buckwoody/archive/2008/05/30/sql-injection-attacks.aspx

I agree with Steve wholeheartedly here.  Having your data compromised is one thing… you learn from it, you fix it, you move on.  But aiding in the distribution of whatever payload is in all of these <script> files that you are unwittingly unleashing on your viewers is something you should try to avoid at all costs.  Unless you are storing your actual HTML content and layout in the database (which is usually a no-no), there is no reason you should ever blindly throw data from the database into a web page without first making sure that all HTML tags (like <BR>) are replaced with characters that make them non-rendering (like &lt;BR&gt;).

Another excellent resource is the following article:

http://blogs.technet.com/swi/archive/2008/05/29/sql-injection-attack.aspx

5 comments on this post

    • Madhivanan - June 5, 2008, 9:18 PM

      Aaron
      I get The page cannot be found error when I open Steve kass artile

    • AaronBertrand - June 29, 2008, 9:34 PM

      Madhivanan, it's weird.  If I go straight to stevekass.com, the article I talk about is the very first one.  If I click on the headline, I go to the exact same URL as mentioned above, and it works.  I have sent a note to Steve, as maybe he can spot what is going on (my best guess so far is some kind of redirect blocking if the referrer is not stevekass.com/*).

    • AaronBertrand - June 30, 2008, 8:02 AM

      Should work now.  
      A

    • Peter W. DeBetta - July 1, 2008, 10:00 AM
    • Brent Jenkins - September 22, 2008, 11:52 PM

      I have a situation where I must use embedded sql only.
      That means NO store procedures, parameterized queries, etc are allowed – period.
      In other words, my hands are tied!
      Anyhow, I wrote this routine to prevent SQL Injection.
      I think this routine is bullet proof.
      Can anybody break it?
      Function getSafeValue(ByVal userInput As String) As String
       userInput = Trim(userInput)
       userInput = userInput.Replace("'", """)
       userInput = userInput.Replace("""", """)
       Return IIf(userInput = "", "NULL", "'" & userInput & "'")
      End Function

Comments are closed.