This post originated from an RSS feed registered with .NET Buzz by Duncan Mackenzie. Original Post: Solutions at a Glance... great for all .NET developers interested in security... Feed Title: Code/Tea/Etc... Feed URL: /msdnerror.htm?aspxerrorpath=/duncanma/rss.aspx Feed Description: Duncan is the Visual Basic Content Strategist at MSDN, the editor of the Visual Basic Developer Center (http://msdn.microsoft.com/vbasic), and the author of the "Coding 4 Fun" column on MSDN (http://msdn.microsoft.com/vbasic/using/columns/code4fun/default.aspx). While typically Visual Basic focused, his blogs sometimes wanders off of the technical path and into various musing of his troubled mind. Latest .NET Buzz Posts Latest .NET Buzz Posts by Duncan Mackenzie Latest Posts From Code/Tea/Etc...

I was just talking with J.D. Meier (from PAG) about the Improving Application Security book and he pointed out a great page to me... the "Solutions At A Glance" list... this page lists a ton of very frequently asked questions around .NET security and provides links deep into all that great PAG security info.

Some examples;

• How to write secure managed code

  Use strong names to digitally sign your assemblies and to make them tamperproof. At the same time you need to be aware of strong name issues when you use strong name assemblies with ASP.NET. Reduce your assembly attack profile by adhering to solid object oriented design principles, and then use code access security to further restrict which code can call your code. Use structured exception handling to prevent sensitive information from propagating beyond your current trust boundary and to develop more robust code. Avoid canonicalization issues, particularly with input file names and URLs.

  For information about how to improve the security of your managed code, see Chapter 7, "Building Secure Assemblies." For more information about how to use code access security effectively to further improve security, see Chapter 8, "Code Access Security in Practice." For information about performing managed code reviews, see Chapter 21, "Code Review."

and

• How to prevent SQL injection

  Use parameterized stored procedures for data access. The use of parameters ensures that input values are checked for type and length. Parameters are also treated as safe literal values and not executable code within the database. If you cannot use stored procedures, use SQL statements with parameters. Do not build SQL statements by concatenating input values with SQL commands. Also, ensure that your application uses a least privileged database login to constrain its capabilities in the database.

  For more information about SQL injection and for further countermeasures, see "SQL Injection" in Chapter 14, "Building Secure Data Access."

For a ton more questions and answers, you can check out the entire page here