View source for CRV2 FrameworkSpecIssuesASPNet

= ASP.NET Security =

= Protection against SQL injections =
The best solution a developer using ASP.NET can implement to avoid this OWASP #1 in the top ten list of security vulnerabilities is to use Parameterized queries .
Equivalent to these solution us the use if Stored procedures which are a form of parameterized queries, for example:

 // Build the query statement using parameterized query.
 string sql = "SELECT UserId FROM User WHERE " +
                "UserName = @UserName AND Password = @Password";
  
 using (SqlCommand cmd = new SqlCommand(sql))
  
 {
    // Create the parameter objects as specific as possible.
    cmd.Parameters.Add("@UserName", System.Data.SqlDbType.NVarChar, 50);
    cmd.Parameters.Add("@Password", System.Data.SqlDbType.NVarChar, 25);
  
    // Add the parameter values.  Validation should have already happened.
    cmd.Parameters["@UserName"].Value = UserName;
    cmd.Parameters["@Password"].Value = Password;
    cmd.Connection = connnection;
  
    try
    {
        cmd.Connection.Open();
        var userId = cmd.ExecuteScalar();
    }
    catch (SqlException sx)
    {
        // Handle exceptions before moving on.
    }
 }

Source:(Jardine, 2013) 

== Use an ORM(Object Relational Mapper) ==
ORM’s are a real blessing regarding protection against SQL injection. By default, the use of ORM will automatically send all SQL request as parameterized queries, however, it’s important to keep in mind that this from of security can be easily bypassed if the developer uses unparameterized HQL or Entity SQL queries dynamically with string concatenations

= Request Validation feature against XSS attacks =
ASP.NET comes with a built-in request validation feature, which examines an HTTP request and determines whether it contains potentially dangerous content. In this context, potentially dangerous content is any HTML markup or JavaScript code in the body, header, query string, or cookies of the request. ASP.NET performs this check because markup or code in the URL query string, cookies, or posted form values might have been added for malicious purposes. This feature was added in the ASP.NET version 1.1, in addition this feature is enabled by default. Once a malformed request containing any HTML tags in send, ASP.NET will simply display an error 

For example, if your site has a form where users enter comments, a malicious user could enter JavaScript code in a script element. When you display the comments page to other users, the browser executes the JavaScript code as if the code had been generated by your website. This exploit is typically referred to as a cross-site scripting (XSS) attack.

Request validation helps prevent this kind of attack. If ASP.NET detects any markup or code in a request, it throws a "potentially dangerous value was detected" error and stops page processing.(Schackow,2012)

Unfortunately, this inherent feature can also create issues when legitimate requests are sent by users who need to submit data containing certain kind of characters such as brackets, including harmless markup like < b > (bold) elements. Throwing an error under this circumstance can be a problem if you want your application to accept HTML markup. For example, if your site lets users add comments, you might want to let users add basic formatting by using HTML tags that put text in bold or italics. In cases like these, you can disable request validation and check for malicious content manually. 

Another disadvantage is that this does not avoid any attacks originated from other application or if stored in the database, neither will offer any protection when input is injected in HTML attributes.


= MVC’s CSFR anti-forgery system =
This is one handy feature found in .NET which contra rest the #8 owasp top 10 security issue.

== Use Anti-forgery Helpers ==
There are 2 methods which a developer can use to avoid CSFR attacks, these are Html.AntiForgeryToken() and the filter [ValidateAntiForgeryToken]. To use these features, call the AntiForgeryToken method from within your form, and add the ValidateAntiForgeryTokenAttribute to the action method you want to protect.
A combination between the Html.AntiForgeryToken() and Ajax.ActionLink is a recommended way to go in order to make sure that no attacker can send a false deletion request

 $.ajaxPrefilter(
       function (options, localOptions, jqXHR) {
           if (options.type !== "GET") {
               var token = GetAntiForgeryToken();
               if (token !== null) {
                   if (options.data.indexOf("X-Requested-With") === -1) {
                       options.data = "X-Requested-With=XMLHttpRequest" + (options.data === "") ? "" : "&" + options.data;
                   }
                   options.data = options.data + "&" + token.name + '=' + token.value;
               }
           }
       }
       );

=== Limitations ===

*Users must accept cookies otherwise the [ValidateAntiForgeryToken] will deny their form’s posts
*Works only with POST request 
*Can be bypassed if the application has XSS vulnerabilities since it will be possible to read _RequestVerificationToken value

= References =
Jardine, 2013.How to Fix SQL Injection Using Microsoft .Net Parameterized Queries, URL: http://software-security.sans.org/developer-how-to/fix-sql-injection-microsoft-.net-with-parameterized-queries</br>
Schackow,2012. Security Extensibility in ASP.NET 4, URL: http://archive.msdn.microsoft.com/Project/Download/FileDownload.aspx?ProjectName=aspnetmsdnexamples&DownloadId=15885
http://msdn.microsoft.com/en-us/library/hh882339.aspx