MSDN Magazine November 2006 - Yearly Security Issue

• Secure Habits: 8 Simple Rules For Developing More Secure Code (Michael Howard)


• Threat Modeling: Uncover Security Design Flaws Using The STRIDE Approach (Shawn Hernan, Scott Lambert, Tomasz Ostwald, Adam Shostack)


• Single Sign-On: A Developer's Introduction To Active Directory Federation Services (Keith Brown)


• Smart Storage: Protect Your Data Via Managed Code And The Windows Vista Smart Card APIs (Dan Griffin)


• Extending SDL: Documenting And Evaluating The Security Guarantees Of Your Apps (Mark Pustilnik)


• SQL Security: New SQL Truncation Attacks And How To Avoid Them (Bala Neerumalla)

Exploits using SQL injection have drawn a lot of attention for their ability to get through firewalls and intrusion detection systems to compromise your data layers. Whether it's a first-order or second-order injection, if you look at the basic code pattern, it is similar to any other injection issue where you use untrusted data in the construction of a statement. Most developers have started mitigating these vulnerabilities in Web front ends by using parameterized SQL queries in conjunction with stored procedures at the back end, but there are some instances where developers still use dynamically constructed SQL, like in the construction of Data Definition Language (DDL) statements based on user input or for apps written in C/C++.

In this article I will discuss some new ideas that can result in either modifying SQL statements or injecting SQL code even if the code has escaped the delimiting characters. I will start with some best practices for constructing delimited identifiers and SQL literals, and then I'll show you new ways attackers can inject SQL code in order to help you protect your applications...