ASP.NET Web Site Security Vulnerability Cheat Sheet

"I tried to learn .NET by taking boot camp classes that cost me $6,000. After taking the classes, I discovered tons of free (and very cheap) videos on the internet created by experts in the field. I found the videos to be much better than the classrooms. The videos were presented by Microsoft presenters that knew the material backwards and forwards, and they were much cheaper and better than the classroom teachers. I have spent the last three years organizing and hunting down the videos for my own use and decided that all could benefit by sharing what I found." - Wade Harvey

Click Here for Free 24 hour pass to lynda.com.
I AM VERY EXCITED ABOUT THIS AMAZING NEW DISCOVERY
Over 40,000 Top-Notch Video Tutorials (or 3,452 hours) on Lynda.com
I had stumbled across Lynda.com many times before, but never stopped to try it out. I recently took the plunge and started using Lynda.com to help me improve my javascript skills (See Javascript Essential Training 2007 by Dori Smith). It has revolutionized my understanding of the language! I love the fact that the exercise files allow you to follow along in real time with what the instructor is saying. Learning by doing is an extremely powerful technique. I have to give the site an A+ for both quality and content.

I am planning on using Lynda Videos to help me improve in:

1. HTML
2. CSS
3. Classic ASP
4. .NET (included in ASP section)
5. AJAX
6. Silverlight (in Microsoft Section)
7. SharePoint (in Microsoft Section)
8. Web Design
9. Blogging
10. SEO
11. and much more

You can learn more about Lynda.com by watching the 5-minute video at About Lynda.com. If you are only focusing on .NET, you are missing out on the "big picture" and on many of the underlying fundamentals! To be an Ideal Programmer, you need to have the largest knowledge base possible.

Looking for premium .NET Training Videos? The best premium .NET Videos that I have found are at Learn Visual Studio. Those videos are only about 50 cents per hour, as compared to $25 per hour that other sites charge!

LearnVisualStudio is currently having a 25% off sale ($50 savings) and giving away a free membership to TrainingSpot ($60 value) when LVS Lifetime Membership is purchased.

  
  

Limited Time Offer: Free Lifetime Membership to Progress Monitor ($24.95 value) when you purchase any membership at Learn Visual Studio, Lynda Videos or any hosting account at DiscountASP - just forward order confirmation to harvey007@sbcglobal.net

ASP.NET Web Site Security Vulnerability Cheat Sheet:

1. To avoid SQL Injection, replace all SQL Commands with parameterized queries or stored procedures (using LINQ to SQL exclusively will also totally eliminate SQL Injection).

2. To avoid packet-sniffing and session hijacking, always use https when sending cookies

3. To avoid Cross-Site Scripting problems, use httpOnly when setting cookies

 Here is a summary of the information in the articles I read that led me to the above “cheat sheet”:

=========================================

How to Prevent SQL Injection:

Explanation of Vulnerability: SQL Injection occurs when someone enters a part of a SQL Command as part of user input, querystring, or cookie.  For example, if person enters " or '1' = '1' in a password textbox, that might be interpreted as part of the sql command and cause the password to always be accepted.

 Approach #1: Replace SQL Commands with Parameterized queries

 One way to prevent sql injection 100% of the time is by replacing all SQL Commands with parameterized queries.  The queries can be stored procedures, but they do not have to be. Stored procedures are a little more efficient because they optimize execution plan, but parameterized queries that are not stored procedures are also safe with regard to sql injection.  The information in the parameterized fields is always treated as a literal by sql server and can never be executed as part of the sql instruction itself.  Using parameterized queries in all SQL Commands in an application prevents sql injection through: 1) user input; 2) query strings; and 3) cookies. The work involved in implementing it would require that every SQL Command that uses input from user, query string, or cookie be converted to parameterized query.

 Approach #2: Replace SQL Commands with LINQ to SQL

 LINQ to SQL, when used exclusively for data access, eliminates the possibility of SQL injection in your application for one simple reason: every SQL query that LINQ executes on your behalf is parameterized.

 Approach #3: Create "Blacklist" of special characters and words

 Here is a shortlist of five predefined entities in xml that people often try to santitize (remove) from user input:

1. quot "
2. amp  &
3. apos '
4. lt   <
5. gt   > 

Here is another example blacklist:

public static string[] blackList = {"–",";–",";","/*","*/","@@","@",
                                     "char","nchar","varchar","nvarchar",
                                     "alter","begin","cast","create","cursor",
                                     "declare","delete","drop","end","exec","execute",
                                     "fetch","insert","kill","open",
                                     "select", "sys","sysobjects","syscolumns",
                                     "table","update"};

Two drawbacks of SQL Injection "Blacklists" of special characters or words: 

1) Blacklisted words and characters change over time. For example, => (lambda) is new C# expression that was recently introduced.

2) Frustrates users trying to enter real data. For example, a user will become frustrated if the quote mark they enter in a textbox mysteriously vanishes each time they enter it.

How to Prevent JavaScript Injection:

 Explanation of the Vulnerability: If someone enters javascript in a textbox they can possibly attach an event to a submit button that will execute whenever anyone presses submit. The event can be used to send private information to the attacker.

 JavaScript injection is automatically prevented by the Request Validation feature of ASP.NET, which is always set to being on by default.

How to Prevent Cookie Vulnerabilities:

1. Only use https when sending cookies

Explanation of the Vulnerability: Packet Sniffing –  Hijacking Cookies that are sent over sessions that are not https

Cookies can be stolen via packet sniffing in an attack called session hijacking. Traffic on a network can be intercepted and read by computers on the network other than its sender and its receiver (particularly on unencrypted public Wi-Fi networks). This traffic includes cookies sent on ordinary unencrypted http sessions. Where network traffic is not encrypted, malicious users can therefore read the communications of other users on the network, including their cookies, using programs called packet sniffers.

This issue can be overcome by securing the communication between the user's computer and the server by employing Transport Layer Security (https protocol) to encrypt the connection. A server can specify the secure flag while setting a cookie; the browser will then send it only over a secure channel, such as an SSL connection.

However a large number of websites, although using encrypted https communication for user authentication (i.e. the login page), subsequently send session cookies and other data over ordinary, unencrypted http connections for performance reasons. Attackers can therefore easily intercept the cookies of other users and impersonate them on the relevant websites or use them in a cookiemonster attack.

2. Always Use httpOnly when setting cookies

Explanation of the Vulnerability: Cross-site scripting (xss) attacks on cookies

Your own site may be secure from Javascript injection, but another web site may not be. If a user goes to your site and logs in and then goes to a bad site while logged in to your site.  The bad site can execute javascript that will send the cookies for your good site to the attacker.  The way to prevent this is by using HttpOnly flag when setting cookies.  HttpOnly says that the cookies from your good site can only be accessed from the server – not from javascript that executes on the client.  Since the cookies cannot be read from client-side javascript, the cookies are safe from cross-site scripting even when someone visits a bad site while logged into your good one.

References:

http://www.mikesdotnetting.com/Article/113/Preventing-SQL-Injection-in-ASP.NET

http://www.owasp.org/index.php/HTTPOnly

http://en.wikipedia.org/wiki/HTTP_cookie#Drawbacks_of_cookies

http://www.devx.com/dotnet/Article/34653

Related posts:

1. ASP.NET Security (3 Hours) – Authentication,Membership, and Login Controls Here are over 3 hours of asp.net security video tutorials....
2. Programmer Downloads, Tools, Resources, and 100 Cheat Sheets Over 20 resources and tools that will help one to...
3. "GoLive" – How To Use DiscountASP to Connect Web Site to Database Exact steps you need to take to golive when using...

Related posts brought to you by Yet Another Related Posts Plugin.