A Word About Secure Database Access
Unfortunately, this database access code exhibits insecurities of its own. For example, you should never use the sa account (or an equivalent) to access databases from Web applications. Instead, use weak accounts that lack permission to drop tables, insert, update, and delete records, and the like. In addition, you should use stored procedures or parameterized commands in lieu of dynamic SQL commands for added protection against malicious input parameters. Finally, consider encrypting database connection strings to minimize the risk of information disclosure if your source code falls into the wrong hands. And note that truly paranoid ASP.NET programmers encrypt connection strings and store them in ACLed registry keys. When it comes to Web security, a little paranoia can be a good thing.

Don’t bother looking for syntax errors: functionally, this page is just fine. Type your name into the input field and click the “Click Me” button, and a personalized greeting appears on the page. But security-wise, this page is a disaster-despite the fact that it’s similar to countless sample pages found in books, magazine articles, and even the .NET Framework SDK.
Give yourself a pat on the back if you spotted the following flaws:
• The page neither constrains nor validates user input
• It echoes raw, unfiltered user input to the page

Download pdf Building a Defensive Perimeter Against Malicious User Input