ASP.NET Web Site Security Vulnerability Cheat Sheet

Posted by asp.net videos on Thursday, October 8, 2009 · Leave a Comment

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.