1. Sofia, Bulgaria | 9-10 October Writing Secure Code for ASP.NET Stephen Forte CTO, Corzen Inc Microsoft Regional Director NY/NJ (USA) Stephen Forte CTO, Corzen Inc Microsoft Regional Director NY/NJ (USA)

2. Sofia, Bulgaria | 9-10 October 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 ●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

3. Sofia, Bulgaria | 9-10 October 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 ●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. Sofia, Bulgaria | 9-10 October What we won’t cover ●Administrative Security ●Authentication and Authorization from an Admin level ●Code Access Security from an Admin level ●Cryptology ●Administrative Security ●Authentication and Authorization from an Admin level ●Code Access Security from an Admin level ●Cryptology

5. Sofia, Bulgaria | 9-10 October 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 ●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. Sofia, Bulgaria | 9-10 October 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 ●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. Sofia, Bulgaria | 9-10 October 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 ●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. Sofia, Bulgaria | 9-10 October Input and Query String Validation ●All user input is evil! ●Not properly validating user input can lead to: ●SQL Injection ●XSS (Cross Site Scripting) ●All user input is evil! ●Not properly validating user input can lead to: ●SQL Injection ●XSS (Cross Site Scripting)

9. Sofia, Bulgaria | 9-10 October 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 ●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

10. Sofia, Bulgaria | 9-10 October 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 ●Client Side: ●Validation Controls ●Server Side: ●Regular Expressions (RegEx) are your friend ●Validate for TLRF: ●Type checks ●Length checks ●Range checks ●Format checks Validator.ValidationExpression = "\w+([-+.]\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*";

11. Sofia, Bulgaria | 9-10 October Proper Validation

12. Sofia, Bulgaria | 9-10 October 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 ●Why Care? ●Best Practices for Writing Secure Code ●Query String and Input Validation ●SQL Injection ●Storing Secret Data ●Exception Handling ●XSS and HTML Management

13. Sofia, Bulgaria | 9-10 October What is SQL Injection? ●What is SQL Injection? ●The process of adding SQL statements in user input ●Used by hackers to: ●Probe databases and call built-in stored procedures ●Bypass authorization (adding records into custom login tables) ●Execute multiple SQL statements to delete data or drop tables ●What is SQL Injection? ●The process of adding SQL statements in user input ●Used by hackers to: ●Probe databases and call built-in stored procedures ●Bypass authorization (adding records into custom login tables) ●Execute multiple SQL statements to delete data or drop tables

14. Sofia, Bulgaria | 9-10 October Examples of SQL Injection ●If the ID variable is read directly from a Windows form textbox, the user could enter any of the following: ●21001' or 1=1 -- ●21001' DROP TABLE OrderDetail -- ●21001' exec xp_cmdshell('fdisk.exe') -- ●If the ID variable is read directly from a Windows form textbox, the user could enter any of the following: ●21001' or 1=1 -- ●21001' DROP TABLE OrderDetail -- ●21001' exec xp_cmdshell('fdisk.exe') -- strSQL = "SELECT * FROM" + " Orders WHERE OrderID ='" + ID + "'";

15. Sofia, Bulgaria | 9-10 October Preventing SQL Injection ●All User Input is Evil! ●Validate all input twice ●Client side validation controls ●Server Side manual validation for Type, Length, Format, and Range using RegEx ●Use Stored Procedures! ●Run with least privilege ●Never execute as “sa” ●Consider two databases with 2 logins ●Remove access to all tables and restrict access to built-in stored procedures (reduces attack surface) ●All User Input is Evil! ●Validate all input twice ●Client side validation controls ●Server Side manual validation for Type, Length, Format, and Range using RegEx ●Use Stored Procedures! ●Run with least privilege ●Never execute as “sa” ●Consider two databases with 2 logins ●Remove access to all tables and restrict access to built-in stored procedures (reduces attack surface)

16. Sofia, Bulgaria | 9-10 October SQL Injection

17. Sofia, Bulgaria | 9-10 October 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 ●Why Care? ●Best Practices for Writing Secure Code ●Query String and Input Validation ●SQL Injection ●Storing Secret Data ●Exception Handling ●XSS and HTML Management

18. Sofia, Bulgaria | 9-10 October Storing Secret Data ●Your application should not store secret data (passwords, etc) ●If you must store secret data, do not encrypt it in the database ●Hackers may guess or get the key ●Store a hashed representation of the data ●Your application should not store secret data (passwords, etc) ●If you must store secret data, do not encrypt it in the database ●Hackers may guess or get the key ●Store a hashed representation of the data

19. Sofia, Bulgaria | 9-10 October What is a Hash? ●A mathematical formula that converts a message of any length into a unique fixed-length string of digits (typically 160 bits) known as "message digest" that represents the original message. ●A hash is a one-way function - that is, it is infeasible to reverse the process to determine the original message. ●A hash function will not produce the same message digest from two different inputs. ●The MD5 and SHA-1 algorithms are two of the most popular algorithms although any cryptosystem can be used to create a hash function (as, indeed, any cryptographically secure hash can be used to create a cryptosystem). ●A mathematical formula that converts a message of any length into a unique fixed-length string of digits (typically 160 bits) known as "message digest" that represents the original message. ●A hash is a one-way function - that is, it is infeasible to reverse the process to determine the original message. ●A hash function will not produce the same message digest from two different inputs. ●The MD5 and SHA-1 algorithms are two of the most popular algorithms although any cryptosystem can be used to create a hash function (as, indeed, any cryptographically secure hash can be used to create a cryptosystem).

20. Sofia, Bulgaria | 9-10 October Storing a Password Hash ●Will only store the message digest (hash) of the password in the database not the actual password. ●When a user comes back to the site they will have to provide the password and you will then recompute the hash of that password and compare them. ●So you are only storing the verifier in the database, not the actual password. ●Will only store the message digest (hash) of the password in the database not the actual password. ●When a user comes back to the site they will have to provide the password and you will then recompute the hash of that password and compare them. ●So you are only storing the verifier in the database, not the actual password.

21. Sofia, Bulgaria | 9-10 October Random Salting a Hash ●Problem: If you know the password of a user, and some other user happens to have the same hash, then you know both have the same password ●A hacker can exploit this with a dictionary attack ●To “salt” a hash, generate a random string and prefix it to the clear password before hashing it. ●Save both the salt and the hashed password in the Users table. ●Drastically diminishes a dictionary attack ●Problem: If you know the password of a user, and some other user happens to have the same hash, then you know both have the same password ●A hacker can exploit this with a dictionary attack ●To “salt” a hash, generate a random string and prefix it to the clear password before hashing it. ●Save both the salt and the hashed password in the Users table. ●Drastically diminishes a dictionary attack

22. Sofia, Bulgaria | 9-10 October Pros and Cons ●Pros: ●Easy to set up ●Protects against disgruntled corporate users ●If the database is cracked, the hacker will not have and passwords-the hash is useless (remember a Hash is 1 way) ●Cons: ●Cannot send a user their password if they forget, you will have to reset it for them ●Pros: ●Easy to set up ●Protects against disgruntled corporate users ●If the database is cracked, the hacker will not have and passwords-the hash is useless (remember a Hash is 1 way) ●Cons: ●Cannot send a user their password if they forget, you will have to reset it for them

23. Sofia, Bulgaria | 9-10 October Hashed Password Values

24. Sofia, Bulgaria | 9-10 October 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 ●Why Care? ●Best Practices for Writing Secure Code ●Query String and Input Validation ●SQL Injection ●Storing Secret Data ●Exception Handling ●XSS and HTML Management

25. Sofia, Bulgaria | 9-10 October Exception Handling ●Never ever show the default ASP.NET debug page ●Never show trace information ●Never reveal any debug information to the user ●Never ever show the default ASP.NET debug page ●Never show trace information ●Never reveal any debug information to the user

26. Sofia, Bulgaria | 9-10 October Audit Everything ●Make sure everything that happens on your site is reproducible ●Do not rely on IIS logs, audit your code ●Commercial products to do this ●Make sure everything that happens on your site is reproducible ●Do not rely on IIS logs, audit your code ●Commercial products to do this

27. Sofia, Bulgaria | 9-10 October Proper Exception Handling

28. Sofia, Bulgaria | 9-10 October 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 ●Why Care? ●Best Practices for Writing Secure Code ●Query String and Input Validation ●SQL Injection ●Storing Secret Data ●Exception Handling ●XSS and HTML Management

29. Sofia, Bulgaria | 9-10 October What Is Cross-Site Scripting? ●A technique that allows hackers to: ●Execute malicious script in a client’s Web browser ●Insert,,,, and tags ●Steal Web session information and authentication cookies ●Access the client computer ●A technique that allows hackers to: ●Execute malicious script in a client’s Web browser ●Insert,,,, and tags ●Steal Web session information and authentication cookies ●Access the client computer Any Web page that renders HTML containing user input is vulnerable

30. Sofia, Bulgaria | 9-10 October Two Common Exploits of Cross- Site Scripting ●Attacking Web-based e-mail platforms and discussion boards ●Using HTML tags to redirect private information ●Attacking Web-based e-mail platforms and discussion boards ●Using HTML tags to redirect private information

31. Sofia, Bulgaria | 9-10 October Form-Based Attacks (1 of 2) Response.Write("Welcome" & Request.QueryString("UserName"))

32. Sofia, Bulgaria | 9-10 October Form-Based Attacks (2 of 2) idForm.cookie.value=document.cookie; idForm.submit(); > here

33. Sofia, Bulgaria | 9-10 October Defending Against Cross-Site Scripting Attacks ●Do not: ●Trust user input ●Echo Web-based user input unless you have validated it ●Store secret information in cookies ●Do: ●Use the HttpOnly cookie option ●Use the security attribute ●Take advantage of ASP.NET features ●Do not: ●Trust user input ●Echo Web-based user input unless you have validated it ●Store secret information in cookies ●Do: ●Use the HttpOnly cookie option ●Use the security attribute ●Take advantage of ASP.NET features

34. Sofia, Bulgaria | 9-10 October Protection ●Use HTMLEncode and URLEncode ●Use RegEx to remove any script of HTML code from user input ●Use HTMLEncode and URLEncode ●Use RegEx to remove any script of HTML code from user input

35. Sofia, Bulgaria | 9-10 October Defending Against Cross-Site Scripting Attacks ●Do not: ●Trust user input ●Echo Web-based user input unless you have validated it ●Store secret information in cookies ●Do: ●Use the HttpOnly cookie option ●Use the security attribute ●Take advantage of ASP.NET features ●Do not: ●Trust user input ●Echo Web-based user input unless you have validated it ●Store secret information in cookies ●Do: ●Use the HttpOnly cookie option ●Use the security attribute ●Take advantage of ASP.NET features

36. Sofia, Bulgaria | 9-10 October Cross Site Scripting

37. Sofia, Bulgaria | 9-10 October Questions?

38. Sofia, Bulgaria | 9-10 October Thanks! ●Please fill out your evaluation form! ●stevef@orcsweb.comstevef@orcsweb.com ●Please put (Secure ASP.NET in the subject) ●Please fill out your evaluation form! ●stevef@orcsweb.comstevef@orcsweb.com ●Please put (Secure ASP.NET in the subject)