This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "CRV2 FrameworkSpecIssuesdotNetMVC"

From OWASP
Jump to: navigation, search
Line 8: Line 8:
  
 
== Protection against SQL injections ==
 
== Protection against SQL injections ==
The best solution  to avoid this OWASP #1 in the top ten list of security vulnerabilities is to use Parameterized queries .Equivalent to these solution, the use the use of Stored procedures is also a form of parameterized queries.
+
The best solution  to avoid this OWASP #1 in the top ten list of security vulnerabilities is to use Parameterized queries .Equivalent to this solution, the use of Stored procedures is also a form of parameterized queries.
 +
 
 +
Parameter collections such as SqlParameterCollection provide type checking and length validation. If you use a parameters collection, input is treated as a literal value, and SQL Server does not treat it as executable code, and therefore the payload can not be injected. Using a parameters collection lets you enforce type and length checks. Values outside of the range trigger an exception. Make sure you handle the exception correctly. Example of the SqlParameterCollection:
 +
 
 +
using System.Data;
 +
using System.Data.SqlClient;
 +
using (SqlConnection conn = new SqlConnection(connectionString))
 +
{
 +
  DataSet dataObj = new DataSet();
 +
  SqlDataAdapter sqlAdapter = new SqlDataAdapter( "StoredProc", conn);
 +
  sqlAdapter.SelectCommand.CommandType = CommandType.StoredProcedure;
 +
  //specify param type
 +
  sqlAdapter.SelectCommand.Parameters.Add("@usrId", SqlDbType.VarChar, 15);
 +
  sqlAdapter.SelectCommand.Parameters["@usrId "].Value = UID.Text; // Add data from user
 +
  sqlAdapter.Fill(dataObj); // populate and execute proc
 +
}
 +
 
 +
=== Stored procedures don’t always protect against SQL injection ===
 +
CREATE PROCEDURE dbo.RunAnyQuery
 +
@parameter NVARCHAR(50)
 +
AS
 +
EXEC sp_executesql @parameter
 +
GO
 +
 
 +
The above procedure shall execute any SQL you pass to it. The directive sp_executesql is a system stored procedure in Microsoft® SQL Server™
 +
Lets pass it.
 +
 
 +
DROP TABLE ORDERS;
 +
 
 +
Guess what happens? So we must be careful of not falling into the “We’re secure, we are using stored procedures” trap!
  
 
=== Use an ORM(Object Relational Mapper) ===
 
=== Use an ORM(Object Relational Mapper) ===

Revision as of 16:52, 2 July 2013

ASP.NET Security in MVC

Traditional ASP.NET applications do not suffer from XSS attacks, contrary to MVC ASP.NET applications. When MVC web apps are exposed to malicious XSS code, they will not throw an error . To avoid this vulnerability, make sure that use use the following code snippet:

<%server.HtmlEncode(stringValue)%>

The HTMLEncode method applies HTML encoding to a specified string. This is useful as a quick method of encoding form data and other client request data before using it in your Web application. Encoding data converts potentially unsafe characters to their HTML-encoded equivalent.(MSDN,2013)

Protection against SQL injections

The best solution to avoid this OWASP #1 in the top ten list of security vulnerabilities is to use Parameterized queries .Equivalent to this solution, the use of Stored procedures is also a form of parameterized queries.

Parameter collections such as SqlParameterCollection provide type checking and length validation. If you use a parameters collection, input is treated as a literal value, and SQL Server does not treat it as executable code, and therefore the payload can not be injected. Using a parameters collection lets you enforce type and length checks. Values outside of the range trigger an exception. Make sure you handle the exception correctly. Example of the SqlParameterCollection:

using System.Data; 
using System.Data.SqlClient; 
using (SqlConnection conn = new SqlConnection(connectionString)) 
{ 
 DataSet dataObj = new DataSet(); 
 SqlDataAdapter sqlAdapter = new SqlDataAdapter( "StoredProc", conn); 
 sqlAdapter.SelectCommand.CommandType = CommandType.StoredProcedure; 
 //specify param type 
 sqlAdapter.SelectCommand.Parameters.Add("@usrId", SqlDbType.VarChar, 15); 
 sqlAdapter.SelectCommand.Parameters["@usrId "].Value = UID.Text; // Add data from user 
 sqlAdapter.Fill(dataObj); // populate and execute proc 
} 

Stored procedures don’t always protect against SQL injection

CREATE PROCEDURE dbo.RunAnyQuery 
@parameter NVARCHAR(50) 
AS 
EXEC sp_executesql @parameter 
GO 

The above procedure shall execute any SQL you pass to it. The directive sp_executesql is a system stored procedure in Microsoft® SQL Server™ Lets pass it.

DROP TABLE ORDERS; 

Guess what happens? So we must be careful of not falling into the “We’re secure, we are using stored procedures” trap!

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 form 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. 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 as shown in the following figure

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. 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

MSDN, 2013 - Server.HTMLEncode Method available at http://msdn.microsoft.com/en-us/library/ms525347%28v=vs.90%29.aspx (last viewed: 2nd July, 2013)