Writing Secure Code for ASP

1. Writing Secure Code for ASP .NET Stephen Forte CTO, Corzen Inc Microsoft Regional Director NY/NJ (USA)

2. Speaker.Bio.ToString() CTO and co-Founder of Corzen, Inc Microsoft MVP and INETA Speaker International Conference Speaker for 9+ Years Wrote a few books on databases and development Co-moderator & founder of NYC .NET Developers Group http://www.nycdotnetdev.com Former CTO of Zagat Survey Steve is cool.Steve is cool.

3. Agenda Why Care? Best Practices for Writing Secure Code Query String and Input Validation SQL Injection Storing Secret Data Exception Handling XSS and HTML Management

4. What we won�t cover Administrative Security Authentication and Authorization from an Admin level Code Access Security from an Admin level Cryptology

5. Agenda Why Care? Best Practices for Writing Secure Code Query String and Input Validation SQL Injection Storing Secret Data Exception Handling XSS and HTML Management

6. Writing Secure Code Developers usually think that security is an administrative problem, not a coding problem While several security issues are administrative in nature, you can write secure code to protect your application Some simple changes to your coding style can result in massive security holes closed

7. Agenda Why Care? Best Practices for Writing Secure Code Query String and Input Validation SQL Injection Storing Secret Data Exception Handling XSS and HTML Management

8. Input and Query String Validation All user input is evil! Not properly validating user input can lead to: SQL Injection XSS (Cross Site Scripting)

9. Do Not Trust User Input Validate all input Guilty until proven innocent: assume all input is bad until you prove otherwise Look for valid data and reject everything else Don�t assume that your client validations were applied, revalidate on the server (a hacker can bypass your client scripting) Avoid Query Strings altogether if possible Consider all user input as harmful until proven otherwise. Look for valid input and deny everything else. Do not do the opposite and look for invalid data, reject it, and then let everything else in. Hackers can circumvent client-side validation. Consider performing validation often and close to the threats. For example, validate data on the server before committing it to a database. Invalidate input that is too large. Invalidate input that contains dangerous characters or keywords, such as scripting elements (<script>, <object>), reserved SQL characters and keywords (- -, INSERT, xp_cmdshell), or file traversal characters (..\). Use the mantra: Constrain, Reject, and Sanitize. One of the most powerful ways to constrain data input is through validation controls and regular expressions. The example regular expression ( \w+([-+.]\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)* ) checks that the input string is of the correct form for an Internet e-mail address.Consider all user input as harmful until proven otherwise. Look for valid input and deny everything else. Do not do the opposite and look for invalid data, reject it, and then let everything else in. Hackers can circumvent client-side validation. Consider performing validation often and close to the threats. For example, validate data on the server before committing it to a database. Invalidate input that is too large. Invalidate input that contains dangerous characters or keywords, such as scripting elements (<script>, <object>), reserved SQL characters and keywords (- -, INSERT, xp_cmdshell), or file traversal characters (..\). Use the mantra: Constrain, Reject, and Sanitize. One of the most powerful ways to constrain data input is through validation controls and regular expressions. The example regular expression ( \w+([-+.]\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)* ) checks that the input string is of the correct form for an Internet e-mail address.

10. Ways to Validate Input Client Side: Validation Controls Server Side: Regular Expressions (RegEx) are your friend Validate for TLRF: Type checks Length checks Range checks Format checks