OWASP - User contributions [en]

ASP.NET Output Encoding

2014-11-12T14:32:10Z

Bricex: /* References */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
Cross-site scripting attacks exploit vulnerabilities in web page validation by injecting client-side script code. The script code embeds itself in response data, which is sent back to an unsuspecting user. In addition to validating input, any data retrieved from untrusted or shared sources should be encoded on output. For example: data retrieved from a database that may have had malicious input persisted to it.

==Encoding Output Values in Code==
Use <code>Server.HtmlEncode</code> to encode untrusted data for use in HTML output:
<pre>var encodedHtml = Server.HtmlEncode(untrustedData);</pre>

Use <code>Server.UrlEncode</code> to encode untrusted data for use in the key/value pairs of a URL query string.
<pre>var url = "https://www.bing.com/search?q=" + HttpUtility.UrlEncode(untrustedData);</pre>

==Encoding Output Values in HTML markup==
Starting with ASP.NET 4.0 you can HTML encode values in markup with the <code><%: %></code> syntax, as shown below.
<pre><span><%: untrustedData %></span></pre>

Or, in Razor syntax, you can HTML encode with <code>@</code>, as shown below.
<pre><span>@untrustedData</span></pre>

Starting with ASP.NET 4.5 you can also HTML encode the result of data-binding expressions. Just add a colon (:) to the end of the <%# prefix that marks the data-binding expression:
<pre>
<asp:TemplateField HeaderText="Name">
<ItemTemplate><%#: Item.Products.Name %></ItemTemplate>
</asp:TemplateField>
</pre>

==IHtmlString==
If you have model properties that are used to display raw HTML you should consider using the <code>HtmlString</code> and <code>MvcHtmlString</code> classes starting with .NET 4.0. These both implement the <code>IHtmlString</code> interface and will instruct ASP.NET to skip output encoding when using <code><%: model.Property %></code> or <code>@model.Property</code> in HTML markup. Converting a property on your view model from <code>String</code> to <code>MvcHtmlString</code> will instruct ASP.NET that HTML encoding has already been accounted for.

<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public MvcHtmlString Description { get; set; } // Output encoding is handled manually
}</pre>

==AntiXssEncoder==
By default the ASP.NET encoding methods use a black-listing technique that evaluates the string for a set of character combinations that may indicate presence of malicious script. A superior approach is to use a [[Input Validation Cheat Sheet#White_List_Input_Validation|white-listing technique]] for validation, which can be achieved using the Anti-Cross Site Scripting Library from Microsoft. Starting with ASP.NET 4.5 you can specify that the <code>AntiXssEncoder</code> from this library be used as the default encoder for you entire application using the <code>encoderType</code> setting in web.config as shown below.
<pre><httpRuntime encoderType="System.Web.Security.AntiXss.AntiXssEncoder" /></pre>

If you are using a version of .NET earlier than 4.5, you will need to download and include the library as a reference to your project, and then use the earlier library name for the encodeType setting as shown below.
<pre><httpRuntime encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" /></pre>

In addition to the common <code>HtmlEncode</code> and <code>UrlEncode</code> methods, the Anti-Cross Site Scripting Library provides the following <code>AntiXssEncoder</code> methods for more specialized output encoding needs:

===CssEncode===
Encodes the specified string for use in cascading style sheets (CSS). This method encodes all characters except those that are in the safe list, by using the CSS escape character (/) followed by up to six hexadecimal digits.
{| class="wikitable"
|<code>alert('XSS Attack!');</code>
|<code>alert\000028\000027XSS\000020Attack\000021\000027\000029\00003B</code>
|-
|<code>user@contoso.com</code>
|<code>user\000040contoso\00002Ecom</code>
|}

===HtmlFormUrlEncode===
Encodes the specified string for use in form submissions whose MIME type is "application/x-www-form-urlencoded". This method encodes all characters except those that are in the safe list. Characters are encoded by using %SINGLE_BYTE_HEX notation.
{| class="wikitable"
|<code>alert('XSS Attack!');</code>
|<code>alert%28%27XSS+Attack%21%27%29%3B</code>
|-
|<code>user@contoso.com</code>
|<code>user%40contoso.com</code>
|}

===XmlAttributeEncode===
Encodes the specified string for use in XML attributes, and is slightly more restrictive than XmlEncode below. This method encodes all characters except those that are in the safe list. Characters are encoded by using &#DECIMAL; notation.
{| class="wikitable"
|<code>alert('XSS Attack!');</code>
|<code>alert(&apos;XSS&#32;Attack!&apos;);</code>
|-
|<code><script>alert('XSSあAttack!');</script></code>
|<code>&lt;script&gt;alert(&apos;XSS&#12354;Attack!&apos;);&lt;/script&gt;</code>
|}

===XmlEncode===
Encodes the specified string for use in XML. This method encodes all characters except those that are in the safe list. Characters are encoded by using &#DECIMAL; notation.
{| class="wikitable"
|<code>alert('XSS Attack!');</code>
|<code>alert(&#39;XSS&#32;Attack!&#39;);;</code>
|-
|<code><script>alert('XSSあAttack!');</script></code>
|<code>&lt;script&gt;alert(&apos;XSS&#12354;Attack!&apos;);&lt;/script&gt;</code>
|}

==References==
*[http://blogs.msdn.com/b/cisg/archive/2008/08/28/output-encoding.aspx Output Encoding]
*[http://msdn.microsoft.com/en-us/library/System.Web.HttpUtility_methods(v=vs.110).aspx HttpUtility Methods]
*[http://blogs.msdn.com/b/sfaust/archive/2008/09/02/which-asp-net-controls-automatically-encodes.aspx Which ASP.NET Controls Automatically Encode?]
*[http://weblogs.asp.net/scottgu/new-lt-gt-syntax-for-html-encoding-output-in-asp-net-4-and-asp-net-mvc-2 New <%: %> Syntax for HTML Encoding Output in ASP.NET 4 (and ASP.NET MVC 2)]
*[http://www.asp.net/aspnet/overview/aspnet-and-visual-studio-2012/whats-new#_Toc318097391 HTML Encoded Data-Binding Expressions]
*[http://msdn.microsoft.com/en-us/library/system.web.ihtmlstring(v=vs.110).aspx IHtmlString Interface]
*[http://stackoverflow.com/questions/2293357/what-is-an-mvchtmlstring-and-when-should-i-use-it What is an MvcHtmlString and when should I use it?]
*[http://www.microsoft.com/en-sg/download/details.aspx?id=43126 Microsoft Anti-Cross Site Scripting Library V4.3]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder_methods(v=vs.110).aspx AntiXssEncoder Methods]
*[[ASP.NET Request Validation]]

[[Category:OWASP .NET Project]][[Category:Stub]]

ASP.NET Output Encoding

2014-11-08T18:39:37Z

Bricex: Including example inputs/outputs

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
Cross-site scripting attacks exploit vulnerabilities in web page validation by injecting client-side script code. The script code embeds itself in response data, which is sent back to an unsuspecting user. In addition to validating input, any data retrieved from untrusted or shared sources should be encoded on output. For example: data retrieved from a database that may have had malicious input persisted to it.

==Encoding Output Values in Code==
Use <code>Server.HtmlEncode</code> to encode untrusted data for use in HTML output:
<pre>var encodedHtml = Server.HtmlEncode(untrustedData);</pre>

Use <code>Server.UrlEncode</code> to encode untrusted data for use in the key/value pairs of a URL query string.
<pre>var url = "https://www.bing.com/search?q=" + HttpUtility.UrlEncode(untrustedData);</pre>

==Encoding Output Values in HTML markup==
Starting with ASP.NET 4.0 you can HTML encode values in markup with the <code><%: %></code> syntax, as shown below.
<pre><span><%: untrustedData %></span></pre>

Or, in Razor syntax, you can HTML encode with <code>@</code>, as shown below.
<pre><span>@untrustedData</span></pre>

Starting with ASP.NET 4.5 you can also HTML encode the result of data-binding expressions. Just add a colon (:) to the end of the <%# prefix that marks the data-binding expression:
<pre>
<asp:TemplateField HeaderText="Name">
<ItemTemplate><%#: Item.Products.Name %></ItemTemplate>
</asp:TemplateField>
</pre>

==IHtmlString==
If you have model properties that are used to display raw HTML you should consider using the <code>HtmlString</code> and <code>MvcHtmlString</code> classes starting with .NET 4.0. These both implement the <code>IHtmlString</code> interface and will instruct ASP.NET to skip output encoding when using <code><%: model.Property %></code> or <code>@model.Property</code> in HTML markup. Converting a property on your view model from <code>String</code> to <code>MvcHtmlString</code> will instruct ASP.NET that HTML encoding has already been accounted for.

<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public MvcHtmlString Description { get; set; } // Output encoding is handled manually
}</pre>

==AntiXssEncoder==
By default the ASP.NET encoding methods use a black-listing technique that evaluates the string for a set of character combinations that may indicate presence of malicious script. A superior approach is to use a [[Input Validation Cheat Sheet#White_List_Input_Validation|white-listing technique]] for validation, which can be achieved using the Anti-Cross Site Scripting Library from Microsoft. Starting with ASP.NET 4.5 you can specify that the <code>AntiXssEncoder</code> from this library be used as the default encoder for you entire application using the <code>encoderType</code> setting in web.config as shown below.
<pre><httpRuntime encoderType="System.Web.Security.AntiXss.AntiXssEncoder" /></pre>

If you are using a version of .NET earlier than 4.5, you will need to download and include the library as a reference to your project, and then use the earlier library name for the encodeType setting as shown below.
<pre><httpRuntime encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" /></pre>

In addition to the common <code>HtmlEncode</code> and <code>UrlEncode</code> methods, the Anti-Cross Site Scripting Library provides the following <code>AntiXssEncoder</code> methods for more specialized output encoding needs:

===CssEncode===
Encodes the specified string for use in cascading style sheets (CSS). This method encodes all characters except those that are in the safe list, by using the CSS escape character (/) followed by up to six hexadecimal digits.
{| class="wikitable"
|<code>alert('XSS Attack!');</code>
|<code>alert\000028\000027XSS\000020Attack\000021\000027\000029\00003B</code>
|-
|<code>user@contoso.com</code>
|<code>user\000040contoso\00002Ecom</code>
|}

===HtmlFormUrlEncode===
Encodes the specified string for use in form submissions whose MIME type is "application/x-www-form-urlencoded". This method encodes all characters except those that are in the safe list. Characters are encoded by using %SINGLE_BYTE_HEX notation.
{| class="wikitable"
|<code>alert('XSS Attack!');</code>
|<code>alert%28%27XSS+Attack%21%27%29%3B</code>
|-
|<code>user@contoso.com</code>
|<code>user%40contoso.com</code>
|}

===XmlAttributeEncode===
Encodes the specified string for use in XML attributes, and is slightly more restrictive than XmlEncode below. This method encodes all characters except those that are in the safe list. Characters are encoded by using &#DECIMAL; notation.
{| class="wikitable"
|<code>alert('XSS Attack!');</code>
|<code>alert(&apos;XSS&#32;Attack!&apos;);</code>
|-
|<code><script>alert('XSSあAttack!');</script></code>
|<code>&lt;script&gt;alert(&apos;XSS&#12354;Attack!&apos;);&lt;/script&gt;</code>
|}

===XmlEncode===
Encodes the specified string for use in XML. This method encodes all characters except those that are in the safe list. Characters are encoded by using &#DECIMAL; notation.
{| class="wikitable"
|<code>alert('XSS Attack!');</code>
|<code>alert(&#39;XSS&#32;Attack!&#39;);;</code>
|-
|<code><script>alert('XSSあAttack!');</script></code>
|<code>&lt;script&gt;alert(&apos;XSS&#12354;Attack!&apos;);&lt;/script&gt;</code>
|}

==References==
*[http://blogs.msdn.com/b/cisg/archive/2008/08/28/output-encoding.aspx Output Encoding]
*[http://msdn.microsoft.com/en-us/library/System.Web.HttpUtility_methods(v=vs.110).aspx HttpUtility Methods]
*[http://weblogs.asp.net/scottgu/new-lt-gt-syntax-for-html-encoding-output-in-asp-net-4-and-asp-net-mvc-2 New <%: %> Syntax for HTML Encoding Output in ASP.NET 4 (and ASP.NET MVC 2)]
*[http://www.asp.net/aspnet/overview/aspnet-and-visual-studio-2012/whats-new#_Toc318097391 HTML Encoded Data-Binding Expressions]
*[http://msdn.microsoft.com/en-us/library/system.web.ihtmlstring(v=vs.110).aspx IHtmlString Interface]
*[http://stackoverflow.com/questions/2293357/what-is-an-mvchtmlstring-and-when-should-i-use-it What is an MvcHtmlString and when should I use it?]
*[http://www.microsoft.com/en-sg/download/details.aspx?id=43126 Microsoft Anti-Cross Site Scripting Library V4.3]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder_methods(v=vs.110).aspx AntiXssEncoder Methods]
*[[ASP.NET Request Validation]]

[[Category:OWASP .NET Project]][[Category:Stub]]

ASP.NET Request Validation

2014-11-03T21:16:45Z

Bricex: /* Don't Rely on Request Validation for XSS Protection */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
''Request validation'' is a feature in ASP.NET that examines HTTP requests and determines whether they contain potentially dangerous content. This check adds protection from markup or code in the URL query string, cookies, or posted form values that might have been added for malicious purposes. This exploit is typically referred to as a ''cross-site scripting'' (XSS) attack. Request validation helps to prevent this kind of attack by throwing a "potentially dangerous value was detected" error and halting page processing if it detects input that may be malicious, such as markup or code in the request.

==Don't Rely on Request Validation for XSS Protection==
Request validation is generally desirable and should be left enabled for [[defense in depth]]. It should '''NOT''' be used as your sole method of XSS protection, and does not guarantee to catch every type of invalid input. There are known, documented bypasses (such as JSON requests) that will not be addressed in future releases, and the request validation feature is no longer provided in ASP.NET vNext.

Fully protecting your application from malicious input requires validating each field of user supplied data. This should start with [http://msdn.microsoft.com/en-us/library/debza5t0(v=vs.100).aspx ASP.NET Validation Controls] and/or [http://msdn.microsoft.com/en-us/library/ee256141(VS.100).aspx DataAnnotations attributes] to check for:
* Required fields
* Correct data type and length
* Data falls within an acceptable range
* Whitelist of allowed characters

Any string input that is returned to the client should be encoded using an appropriate method, such as those provided via [[ASP.NET Output Encoding#Enhanced_Encoding|AntiXssEncoder]].

<pre>var encodedInput = Server.HtmlEncode(userInput);</pre>

==Enabling Request Validation==
Request validation is enabled by default in ASP.NET. You can check to make sure it is enabled by reviewing the following areas:

{| class="wikitable"
|style="width: 20%;"|ASP.NET Web Forms (Global)
|Ensure that request validation is set to true (or not set at all) in web.config: <pre><pages validateRequest="true" /></pre>
|-
|ASP.NET Web Forms (Page Level)
|Check to make sure request validation is set to true (or not set at all) at the page level: <pre><@ Page ValidateRequest="false" %></pre>
|-
|ASP.NET 4.0+
|Starting with ASP.NET 4.0 request validation is performed for all requests, not just for .aspx page requests. To ensure this is configured correctly requestValidationMode should be set to "4.0" (or not set at all) in web.config: <pre><httpRuntime requestValidationMode="4.0" /></pre>
|-
|ASP.NET 4.5+
|There are enhancements added to request validation starting with ASP.NET 4.5 that include deferred ("lazy") validation, the ability to opt-out at the server control level, and the ability to access unvalidated data. In order to leverage these enhancements you will need to ensure that requestValidationMode has been set to "4.5" in web.config: <pre><httpRuntime requestValidationMode="4.5" targetFramework="4.5" /></pre>
|-
|ASP.NET Web API
|ASP.NET Web API does not utilize the request validation feature to sanitize user input. You will need to add this protection manually if any input will be used in HTML output. For example if user input is returned to the browser as the result from an AJAX request to a Web API method.
|}

==Selectively Disabling Request Validation==
In some cases you may need to accept input that will fail ASP.NET Request Validation, such as when receiving HTML markup from the end user. In these scenarios you should disable request validation for the smallest surface possible.

===ASP.NET Web Forms===
For ASP.NET Web Forms applications prior to v4.5, you will need to disable request validation at the page level. Be aware that when doing this all input values (cookies, query string, form elements) handled by this page will not be validated by ASP.NET.
<pre><@ Page ValidateRequest="false" %></pre>

Starting with ASP.NET 4.5 you can disable request validation at the individual server control level by setting <code>ValidateRequestMode</code> to "Disabled".
<pre><asp:TextBox ID="txtASPNet" ValidateRequestMode="Disabled" runat="server" /></pre>

===ASP.NET MVC===
To disable request validation for a specific MVC controller action, you can use the <code>[ValidateInput(false)]</code> attribute as shown below.
<pre>[ValidateInput(false)]
public ActionResult Update(int userId, string description)</pre>

Starting with ASP.NET MVC 3 you should use the <code>[AllowHtml]</code> attribute to decorate specific fields on your view model classes where request validation should not be applied:
<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public string Email { get; set; }
[AllowHtml]
public string Description { get; set; }
[AllowHtml]
public string Bio { get; set; }
}</pre>

==Extending Request Validation==
If you are using ASP.NET 4.0 or higher, you have the option of extending or replacing the Request Validation logic by providing your own class that descends from <code>System.Web.Util.RequestValidator</code>. By implementing this class, you can determine when validation occurs and what type of request data to perform validation on.
<pre>public class CustomRequestValidation : RequestValidator
{
protected override bool IsValidRequestString(
HttpContext context,
string value,
RequestValidationSource requestValidationSource,
string collectionKey,
out int validationFailureIndex)
{
validationFailureIndex = -1;

// This is just an example and should not
// be used for production code.
if (value.Contains("<%"))
{
return false;
}
else // Leave any further checks to ASP.NET.
{
return base.IsValidRequestString(
context,
value,
requestValidationSource,
collectionKey,
out validationFailureIndex);
}
}
}</pre>
This class is then registered in web.config using <code>requestValidationType</code>:
<pre>
<system.web>
<httpRuntime requestValidationType="CustomRequestValidation"/>
</system.web>
</pre>
==References==
*[http://msdn.microsoft.com/en-us/library/hh882339(v=vs.110).aspx Request Validation in ASP.NET]
*[http://msdn.microsoft.com/en-us/library/debza5t0(v=vs.100).aspx Validation ASP.NET Controls]
*[http://msdn.microsoft.com/en-us/library/ee256141(VS.100).aspx How to: Validate Model Data Using DataAnnotations Attributes]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder(v=vs.110).aspx AntiXssEncoder Class]
*[http://www.asp.net/aspnet/overview/aspnet-and-visual-studio-2012/whats-new#_Toc318097379 New ASP.NET Request Validation Features]
*[http://msdn.microsoft.com/en-us/library/system.web.ui.control.validaterequestmode(v=vs.110).aspx Control.ValidateRequestMode Property]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.validateinputattribute(v=vs.118).aspx ValidateInputAttribute Class]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.allowhtmlattribute(v=vs.118).aspx AllowHtmlAttribute Class]
*[http://msdn.microsoft.com/en-us/library/system.web.util.requestvalidator(v=vs.110).aspx RequestValidator Class]
*[[ASP.NET Output Encoding]]

[[Category:OWASP .NET Project]]

ASP.NET Output Encoding

2014-11-03T21:05:50Z

Bricex: /* Encoding Output Values in Code */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
Cross-site scripting attacks exploit vulnerabilities in web page validation by injecting client-side script code. The script code embeds itself in response data, which is sent back to an unsuspecting user. In addition to validating input, any data retrieved from untrusted or shared sources should be encoded on output. For example: data retrieved from a database that may have had malicious input persisted to it.

==Encoding Output Values in Code==
Use <code>Server.HtmlEncode</code> to encode untrusted data for use in HTML output:
<pre>var encodedHtml = Server.HtmlEncode(untrustedData);</pre>

Use <code>Server.UrlEncode</code> to encode untrusted data for use in the key/value pairs of a URL query string.
<pre>var url = "https://www.bing.com/search?q=" + HttpUtility.UrlEncode(untrustedData);</pre>

==Encoding Output Values in HTML markup==
Starting with ASP.NET 4.0 you can HTML encode values in markup with the <code><%: %></code> syntax, as shown below.
<pre><span><%: untrustedData %></span></pre>

Or, in Razor syntax, you can HTML encode with <code>@</code>, as shown below.
<pre><span>@untrustedData</span></pre>

Starting with ASP.NET 4.5 you can also HTML encode the result of data-binding expressions. Just add a colon (:) to the end of the <%# prefix that marks the data-binding expression:
<pre>
<asp:TemplateField HeaderText="Name">
<ItemTemplate><%#: Item.Products.Name %></ItemTemplate>
</asp:TemplateField>
</pre>

==IHtmlString==
If you have model properties that are used to display raw HTML you should consider using the <code>HtmlString</code> and <code>MvcHtmlString</code> classes starting with .NET 4.0. These both implement the <code>IHtmlString</code> interface and will instruct ASP.NET to skip output encoding when using <code><%: model.Property %></code> or <code>@model.Property</code> in HTML markup. Converting a property on your view model from <code>String</code> to <code>MvcHtmlString</code> will instruct ASP.NET that HTML encoding has already been accounted for.

<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public MvcHtmlString Description { get; set; } // Output encoding is handled manually
}</pre>

==Enhanced Encoding==
By default the ASP.NET encoding methods use a black-listing technique that evaluates the string for a set of character combinations that may indicate presence of malicious script. A superior approach is to use a [[Input Validation Cheat Sheet#White_List_Input_Validation|white-listing technique]] for validation, which can be achieved using the Anti-Cross Site Scripting Library from Microsoft. Starting with ASP.NET 4.5 you can specify that the <code>AntiXssEncoder</code> from this library be used as the default encoder for you entire application using the <code>encoderType</code> setting in web.config as shown below.
<pre><httpRuntime encoderType="System.Web.Security.AntiXss.AntiXssEncoder" /></pre>

If you are using a version of .NET earlier than 4.5, you will need to download and include the library as a reference to your project, and then use the earlier library name for the encodeType setting as shown below.
<pre><httpRuntime encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" /></pre>

In addition to the common <code>HtmlEncode</code> and <code>UrlEncode</code> methods, the Anti-Cross Site Scripting Library provides the following <code>AntiXssEncoder</code> methods for more specialized output encoding needs:

{| class="wikitable"
|CssEncode
|Encodes the specified string for use in cascading style sheets (CSS).
|-
|HeaderNameValueEncode
|Encodes a header name and value into a string that can be used as an HTTP header.
|-
|HtmlAttributeEncode
|Encodes and outputs the specified string for use in an HTML attribute.
|-
|HtmlFormUrlEncode
|Encodes the specified string for use in form submissions whose MIME type is "application/x-www-form-urlencoded".
|-
|JavaScriptStringEncode
|Encodes a string for use in JavaScript.
|-
|UrlPathEncode
|Encodes path strings for use in a URL.
|-
|XmlAttributeEncode
|Encodes the specified string for use in XML attributes.
|-
|XmlEncode
|Encodes the specified string for use in XML.
|}

==References==
*[http://blogs.msdn.com/b/cisg/archive/2008/08/28/output-encoding.aspx Output Encoding]
*[http://msdn.microsoft.com/en-us/library/System.Web.HttpUtility_methods(v=vs.110).aspx HttpUtility Methods]
*[http://weblogs.asp.net/scottgu/new-lt-gt-syntax-for-html-encoding-output-in-asp-net-4-and-asp-net-mvc-2 New <%: %> Syntax for HTML Encoding Output in ASP.NET 4 (and ASP.NET MVC 2)]
*[http://www.asp.net/aspnet/overview/aspnet-and-visual-studio-2012/whats-new#_Toc318097391 HTML Encoded Data-Binding Expressions]
*[http://msdn.microsoft.com/en-us/library/system.web.ihtmlstring(v=vs.110).aspx IHtmlString Interface]
*[http://stackoverflow.com/questions/2293357/what-is-an-mvchtmlstring-and-when-should-i-use-it What is an MvcHtmlString and when should I use it?]
*[http://www.microsoft.com/en-sg/download/details.aspx?id=43126 Microsoft Anti-Cross Site Scripting Library V4.3]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder_methods(v=vs.110).aspx AntiXssEncoder Methods]
*[[ASP.NET Request Validation]]

[[Category:OWASP .NET Project]][[Category:Stub]]

ASP.NET Output Encoding

2014-11-03T21:03:46Z

Bricex: /* Encoding Output Values in Code */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
Cross-site scripting attacks exploit vulnerabilities in web page validation by injecting client-side script code. The script code embeds itself in response data, which is sent back to an unsuspecting user. In addition to validating input, any data retrieved from untrusted or shared sources should be encoded on output. For example: data retrieved from a database that may have had malicious input persisted to it.

==Encoding Output Values in Code==
Use <code>Server.HtmlEncode</code> to encode untrusted data for use in HTML output:
<pre>var encodedHtml = Server.HtmlEncode(untrustedData);</pre>

Use <code>Server.UrlEncode</code> to encode untrusted data for use in the key/value pairs of a URL query string.
<pre>var encodedUrl = Server.UrlEncode(untrustedData);</pre>

==Encoding Output Values in HTML markup==
Starting with ASP.NET 4.0 you can HTML encode values in markup with the <code><%: %></code> syntax, as shown below.
<pre><span><%: untrustedData %></span></pre>

Or, in Razor syntax, you can HTML encode with <code>@</code>, as shown below.
<pre><span>@untrustedData</span></pre>

Starting with ASP.NET 4.5 you can also HTML encode the result of data-binding expressions. Just add a colon (:) to the end of the <%# prefix that marks the data-binding expression:
<pre>
<asp:TemplateField HeaderText="Name">
<ItemTemplate><%#: Item.Products.Name %></ItemTemplate>
</asp:TemplateField>
</pre>

==IHtmlString==
If you have model properties that are used to display raw HTML you should consider using the <code>HtmlString</code> and <code>MvcHtmlString</code> classes starting with .NET 4.0. These both implement the <code>IHtmlString</code> interface and will instruct ASP.NET to skip output encoding when using <code><%: model.Property %></code> or <code>@model.Property</code> in HTML markup. Converting a property on your view model from <code>String</code> to <code>MvcHtmlString</code> will instruct ASP.NET that HTML encoding has already been accounted for.

<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public MvcHtmlString Description { get; set; } // Output encoding is handled manually
}</pre>

==Enhanced Encoding==
By default the ASP.NET encoding methods use a black-listing technique that evaluates the string for a set of character combinations that may indicate presence of malicious script. A superior approach is to use a [[Input Validation Cheat Sheet#White_List_Input_Validation|white-listing technique]] for validation, which can be achieved using the Anti-Cross Site Scripting Library from Microsoft. Starting with ASP.NET 4.5 you can specify that the <code>AntiXssEncoder</code> from this library be used as the default encoder for you entire application using the <code>encoderType</code> setting in web.config as shown below.
<pre><httpRuntime encoderType="System.Web.Security.AntiXss.AntiXssEncoder" /></pre>

If you are using a version of .NET earlier than 4.5, you will need to download and include the library as a reference to your project, and then use the earlier library name for the encodeType setting as shown below.
<pre><httpRuntime encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" /></pre>

In addition to the common <code>HtmlEncode</code> and <code>UrlEncode</code> methods, the Anti-Cross Site Scripting Library provides the following <code>AntiXssEncoder</code> methods for more specialized output encoding needs:

{| class="wikitable"
|CssEncode
|Encodes the specified string for use in cascading style sheets (CSS).
|-
|HeaderNameValueEncode
|Encodes a header name and value into a string that can be used as an HTTP header.
|-
|HtmlAttributeEncode
|Encodes and outputs the specified string for use in an HTML attribute.
|-
|HtmlFormUrlEncode
|Encodes the specified string for use in form submissions whose MIME type is "application/x-www-form-urlencoded".
|-
|JavaScriptStringEncode
|Encodes a string for use in JavaScript.
|-
|UrlPathEncode
|Encodes path strings for use in a URL.
|-
|XmlAttributeEncode
|Encodes the specified string for use in XML attributes.
|-
|XmlEncode
|Encodes the specified string for use in XML.
|}

==References==
*[http://blogs.msdn.com/b/cisg/archive/2008/08/28/output-encoding.aspx Output Encoding]
*[http://msdn.microsoft.com/en-us/library/System.Web.HttpUtility_methods(v=vs.110).aspx HttpUtility Methods]
*[http://weblogs.asp.net/scottgu/new-lt-gt-syntax-for-html-encoding-output-in-asp-net-4-and-asp-net-mvc-2 New <%: %> Syntax for HTML Encoding Output in ASP.NET 4 (and ASP.NET MVC 2)]
*[http://www.asp.net/aspnet/overview/aspnet-and-visual-studio-2012/whats-new#_Toc318097391 HTML Encoded Data-Binding Expressions]
*[http://msdn.microsoft.com/en-us/library/system.web.ihtmlstring(v=vs.110).aspx IHtmlString Interface]
*[http://stackoverflow.com/questions/2293357/what-is-an-mvchtmlstring-and-when-should-i-use-it What is an MvcHtmlString and when should I use it?]
*[http://www.microsoft.com/en-sg/download/details.aspx?id=43126 Microsoft Anti-Cross Site Scripting Library V4.3]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder_methods(v=vs.110).aspx AntiXssEncoder Methods]
*[[ASP.NET Request Validation]]

[[Category:OWASP .NET Project]][[Category:Stub]]

ASP.NET Output Encoding

2014-11-03T20:55:02Z

Bricex: /* References */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
Cross-site scripting attacks exploit vulnerabilities in web page validation by injecting client-side script code. The script code embeds itself in response data, which is sent back to an unsuspecting user. In addition to validating input, any data retrieved from untrusted or shared sources should be encoded on output. For example: data retrieved from a database that may have had malicious input persisted to it.

==Encoding Output Values in Code==
Use <code>Server.HtmlEncode</code> to encode untrusted data for use in HTML output:
<pre>var encodedHtml = Server.HtmlEncode(untrustedData);</pre>

Use <code>Server.UrlEncode</code> to encode untrusted data for use in constructing URLs
<pre>var encodedUrl = Server.UrlEncode(untrustedData);</pre>

==Encoding Output Values in HTML markup==
Starting with ASP.NET 4.0 you can HTML encode values in markup with the <code><%: %></code> syntax, as shown below.
<pre><span><%: untrustedData %></span></pre>

Or, in Razor syntax, you can HTML encode with <code>@</code>, as shown below.
<pre><span>@untrustedData</span></pre>

Starting with ASP.NET 4.5 you can also HTML encode the result of data-binding expressions. Just add a colon (:) to the end of the <%# prefix that marks the data-binding expression:
<pre>
<asp:TemplateField HeaderText="Name">
<ItemTemplate><%#: Item.Products.Name %></ItemTemplate>
</asp:TemplateField>
</pre>

==IHtmlString==
If you have model properties that are used to display raw HTML you should consider using the <code>HtmlString</code> and <code>MvcHtmlString</code> classes starting with .NET 4.0. These both implement the <code>IHtmlString</code> interface and will instruct ASP.NET to skip output encoding when using <code><%: model.Property %></code> or <code>@model.Property</code> in HTML markup. Converting a property on your view model from <code>String</code> to <code>MvcHtmlString</code> will instruct ASP.NET that HTML encoding has already been accounted for.

<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public MvcHtmlString Description { get; set; } // Output encoding is handled manually
}</pre>

==Enhanced Encoding==
By default the ASP.NET encoding methods use a black-listing technique that evaluates the string for a set of character combinations that may indicate presence of malicious script. A superior approach is to use a [[Input Validation Cheat Sheet#White_List_Input_Validation|white-listing technique]] for validation, which can be achieved using the Anti-Cross Site Scripting Library from Microsoft. Starting with ASP.NET 4.5 you can specify that the <code>AntiXssEncoder</code> from this library be used as the default encoder for you entire application using the <code>encoderType</code> setting in web.config as shown below.
<pre><httpRuntime encoderType="System.Web.Security.AntiXss.AntiXssEncoder" /></pre>

If you are using a version of .NET earlier than 4.5, you will need to download and include the library as a reference to your project, and then use the earlier library name for the encodeType setting as shown below.
<pre><httpRuntime encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" /></pre>

In addition to the common <code>HtmlEncode</code> and <code>UrlEncode</code> methods, the Anti-Cross Site Scripting Library provides the following <code>AntiXssEncoder</code> methods for more specialized output encoding needs:

{| class="wikitable"
|CssEncode
|Encodes the specified string for use in cascading style sheets (CSS).
|-
|HeaderNameValueEncode
|Encodes a header name and value into a string that can be used as an HTTP header.
|-
|HtmlAttributeEncode
|Encodes and outputs the specified string for use in an HTML attribute.
|-
|HtmlFormUrlEncode
|Encodes the specified string for use in form submissions whose MIME type is "application/x-www-form-urlencoded".
|-
|JavaScriptStringEncode
|Encodes a string for use in JavaScript.
|-
|UrlPathEncode
|Encodes path strings for use in a URL.
|-
|XmlAttributeEncode
|Encodes the specified string for use in XML attributes.
|-
|XmlEncode
|Encodes the specified string for use in XML.
|}

==References==
*[http://blogs.msdn.com/b/cisg/archive/2008/08/28/output-encoding.aspx Output Encoding]
*[http://msdn.microsoft.com/en-us/library/System.Web.HttpUtility_methods(v=vs.110).aspx HttpUtility Methods]
*[http://weblogs.asp.net/scottgu/new-lt-gt-syntax-for-html-encoding-output-in-asp-net-4-and-asp-net-mvc-2 New <%: %> Syntax for HTML Encoding Output in ASP.NET 4 (and ASP.NET MVC 2)]
*[http://www.asp.net/aspnet/overview/aspnet-and-visual-studio-2012/whats-new#_Toc318097391 HTML Encoded Data-Binding Expressions]
*[http://msdn.microsoft.com/en-us/library/system.web.ihtmlstring(v=vs.110).aspx IHtmlString Interface]
*[http://stackoverflow.com/questions/2293357/what-is-an-mvchtmlstring-and-when-should-i-use-it What is an MvcHtmlString and when should I use it?]
*[http://www.microsoft.com/en-sg/download/details.aspx?id=43126 Microsoft Anti-Cross Site Scripting Library V4.3]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder_methods(v=vs.110).aspx AntiXssEncoder Methods]
*[[ASP.NET Request Validation]]

[[Category:OWASP .NET Project]][[Category:Stub]]

ASP.NET Output Encoding

2014-11-03T20:53:31Z

Bricex: Adding HTML encoding of data binding expressions in ASP.NET 4.5

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
Cross-site scripting attacks exploit vulnerabilities in web page validation by injecting client-side script code. The script code embeds itself in response data, which is sent back to an unsuspecting user. In addition to validating input, any data retrieved from untrusted or shared sources should be encoded on output. For example: data retrieved from a database that may have had malicious input persisted to it.

==Encoding Output Values in Code==
Use <code>Server.HtmlEncode</code> to encode untrusted data for use in HTML output:
<pre>var encodedHtml = Server.HtmlEncode(untrustedData);</pre>

Use <code>Server.UrlEncode</code> to encode untrusted data for use in constructing URLs
<pre>var encodedUrl = Server.UrlEncode(untrustedData);</pre>

==Encoding Output Values in HTML markup==
Starting with ASP.NET 4.0 you can HTML encode values in markup with the <code><%: %></code> syntax, as shown below.
<pre><span><%: untrustedData %></span></pre>

Or, in Razor syntax, you can HTML encode with <code>@</code>, as shown below.
<pre><span>@untrustedData</span></pre>

Starting with ASP.NET 4.5 you can also HTML encode the result of data-binding expressions. Just add a colon (:) to the end of the <%# prefix that marks the data-binding expression:
<pre>
<asp:TemplateField HeaderText="Name">
<ItemTemplate><%#: Item.Products.Name %></ItemTemplate>
</asp:TemplateField>
</pre>

==IHtmlString==
If you have model properties that are used to display raw HTML you should consider using the <code>HtmlString</code> and <code>MvcHtmlString</code> classes starting with .NET 4.0. These both implement the <code>IHtmlString</code> interface and will instruct ASP.NET to skip output encoding when using <code><%: model.Property %></code> or <code>@model.Property</code> in HTML markup. Converting a property on your view model from <code>String</code> to <code>MvcHtmlString</code> will instruct ASP.NET that HTML encoding has already been accounted for.

<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public MvcHtmlString Description { get; set; } // Output encoding is handled manually
}</pre>

==Enhanced Encoding==
By default the ASP.NET encoding methods use a black-listing technique that evaluates the string for a set of character combinations that may indicate presence of malicious script. A superior approach is to use a [[Input Validation Cheat Sheet#White_List_Input_Validation|white-listing technique]] for validation, which can be achieved using the Anti-Cross Site Scripting Library from Microsoft. Starting with ASP.NET 4.5 you can specify that the <code>AntiXssEncoder</code> from this library be used as the default encoder for you entire application using the <code>encoderType</code> setting in web.config as shown below.
<pre><httpRuntime encoderType="System.Web.Security.AntiXss.AntiXssEncoder" /></pre>

If you are using a version of .NET earlier than 4.5, you will need to download and include the library as a reference to your project, and then use the earlier library name for the encodeType setting as shown below.
<pre><httpRuntime encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" /></pre>

In addition to the common <code>HtmlEncode</code> and <code>UrlEncode</code> methods, the Anti-Cross Site Scripting Library provides the following <code>AntiXssEncoder</code> methods for more specialized output encoding needs:

{| class="wikitable"
|CssEncode
|Encodes the specified string for use in cascading style sheets (CSS).
|-
|HeaderNameValueEncode
|Encodes a header name and value into a string that can be used as an HTTP header.
|-
|HtmlAttributeEncode
|Encodes and outputs the specified string for use in an HTML attribute.
|-
|HtmlFormUrlEncode
|Encodes the specified string for use in form submissions whose MIME type is "application/x-www-form-urlencoded".
|-
|JavaScriptStringEncode
|Encodes a string for use in JavaScript.
|-
|UrlPathEncode
|Encodes path strings for use in a URL.
|-
|XmlAttributeEncode
|Encodes the specified string for use in XML attributes.
|-
|XmlEncode
|Encodes the specified string for use in XML.
|}

==References==
*[http://blogs.msdn.com/b/cisg/archive/2008/08/28/output-encoding.aspx Output Encoding]
*[http://msdn.microsoft.com/en-us/library/System.Web.HttpUtility_methods(v=vs.110).aspx HttpUtility Methods]
*[http://weblogs.asp.net/scottgu/new-lt-gt-syntax-for-html-encoding-output-in-asp-net-4-and-asp-net-mvc-2 New <%: %> Syntax for HTML Encoding Output in ASP.NET 4 (and ASP.NET MVC 2)]
*[http://msdn.microsoft.com/en-us/library/system.web.ihtmlstring(v=vs.110).aspx IHtmlString Interface]
*[http://stackoverflow.com/questions/2293357/what-is-an-mvchtmlstring-and-when-should-i-use-it What is an MvcHtmlString and when should I use it?]
*[http://www.microsoft.com/en-sg/download/details.aspx?id=43126 Microsoft Anti-Cross Site Scripting Library V4.3]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder_methods(v=vs.110).aspx AntiXssEncoder Methods]
*[[ASP.NET Request Validation]]

[[Category:OWASP .NET Project]][[Category:Stub]]

ASP.NET Output Encoding

2014-11-03T17:34:51Z

Bricex: /* Encoding Output Values in HTML markup */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
Cross-site scripting attacks exploit vulnerabilities in web page validation by injecting client-side script code. The script code embeds itself in response data, which is sent back to an unsuspecting user. In addition to validating input, any data retrieved from untrusted or shared sources should be encoded on output. For example: data retrieved from a database that may have had malicious input persisted to it.

==Encoding Output Values in Code==
Use <code>Server.HtmlEncode</code> to encode untrusted data for use in HTML output:
<pre>var encodedHtml = Server.HtmlEncode(untrustedData);</pre>

Use <code>Server.UrlEncode</code> to encode untrusted data for use in constructing URLs
<pre>var encodedUrl = Server.UrlEncode(untrustedData);</pre>

==Encoding Output Values in HTML markup==
You can HTML encode the value in markup with the <code><%: %></code> syntax, as shown below.
<pre><span><%: untrustedData %></span></pre>

Or, in Razor syntax, you can HTML encode with <code>@</code>, as shown below.
<pre><span>@untrustedData</span></pre>

==IHtmlString==
If you have model properties that are used to display raw HTML you should consider using the <code>HtmlString</code> and <code>MvcHtmlString</code> classes starting with .NET 4.0. These both implement the <code>IHtmlString</code> interface and will instruct ASP.NET to skip output encoding when using <code><%: model.Property %></code> or <code>@model.Property</code> in HTML markup. Converting a property on your view model from <code>String</code> to <code>MvcHtmlString</code> will instruct ASP.NET that HTML encoding has already been accounted for.

<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public MvcHtmlString Description { get; set; } // Output encoding is handled manually
}</pre>

==Enhanced Encoding==
By default the ASP.NET encoding methods use a black-listing technique that evaluates the string for a set of character combinations that may indicate presence of malicious script. A superior approach is to use a [[Input Validation Cheat Sheet#White_List_Input_Validation|white-listing technique]] for validation, which can be achieved using the Anti-Cross Site Scripting Library from Microsoft. Starting with ASP.NET 4.5 you can specify that the <code>AntiXssEncoder</code> from this library be used as the default encoder for you entire application using the <code>encoderType</code> setting in web.config as shown below.
<pre><httpRuntime encoderType="System.Web.Security.AntiXss.AntiXssEncoder" /></pre>

If you are using a version of .NET earlier than 4.5, you will need to download and include the library as a reference to your project, and then use the earlier library name for the encodeType setting as shown below.
<pre><httpRuntime encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" /></pre>

In addition to the common <code>HtmlEncode</code> and <code>UrlEncode</code> methods, the Anti-Cross Site Scripting Library provides the following <code>AntiXssEncoder</code> methods for more specialized output encoding needs:

{| class="wikitable"
|CssEncode
|Encodes the specified string for use in cascading style sheets (CSS).
|-
|HeaderNameValueEncode
|Encodes a header name and value into a string that can be used as an HTTP header.
|-
|HtmlAttributeEncode
|Encodes and outputs the specified string for use in an HTML attribute.
|-
|HtmlFormUrlEncode
|Encodes the specified string for use in form submissions whose MIME type is "application/x-www-form-urlencoded".
|-
|JavaScriptStringEncode
|Encodes a string for use in JavaScript.
|-
|UrlPathEncode
|Encodes path strings for use in a URL.
|-
|XmlAttributeEncode
|Encodes the specified string for use in XML attributes.
|-
|XmlEncode
|Encodes the specified string for use in XML.
|}

==References==
*[http://blogs.msdn.com/b/cisg/archive/2008/08/28/output-encoding.aspx Output Encoding]
*[http://msdn.microsoft.com/en-us/library/System.Web.HttpUtility_methods(v=vs.110).aspx HttpUtility Methods]
*[http://weblogs.asp.net/scottgu/new-lt-gt-syntax-for-html-encoding-output-in-asp-net-4-and-asp-net-mvc-2 New <%: %> Syntax for HTML Encoding Output in ASP.NET 4 (and ASP.NET MVC 2)]
*[http://msdn.microsoft.com/en-us/library/system.web.ihtmlstring(v=vs.110).aspx IHtmlString Interface]
*[http://stackoverflow.com/questions/2293357/what-is-an-mvchtmlstring-and-when-should-i-use-it What is an MvcHtmlString and when should I use it?]
*[http://www.microsoft.com/en-sg/download/details.aspx?id=43126 Microsoft Anti-Cross Site Scripting Library V4.3]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder_methods(v=vs.110).aspx AntiXssEncoder Methods]
*[[ASP.NET Request Validation]]

[[Category:OWASP .NET Project]][[Category:Stub]]

ASP.NET Output Encoding

2014-11-03T17:34:17Z

Bricex:

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
Cross-site scripting attacks exploit vulnerabilities in web page validation by injecting client-side script code. The script code embeds itself in response data, which is sent back to an unsuspecting user. In addition to validating input, any data retrieved from untrusted or shared sources should be encoded on output. For example: data retrieved from a database that may have had malicious input persisted to it.

==Encoding Output Values in Code==
Use <code>Server.HtmlEncode</code> to encode untrusted data for use in HTML output:
<pre>var encodedHtml = Server.HtmlEncode(untrustedData);</pre>

Use <code>Server.UrlEncode</code> to encode untrusted data for use in constructing URLs
<pre>var encodedUrl = Server.UrlEncode(untrustedData);</pre>

==Encoding Output Values in HTML markup==
You can HTML encode the value in markup with the <code><%: %></code> syntax, as shown below.
<pre><span><%: untrustedData%></span></pre>

Or, in Razor syntax, you can HTML encode with <code>@</code>, as shown below.
<pre><span>@untrustedData</span></pre>

==IHtmlString==
If you have model properties that are used to display raw HTML you should consider using the <code>HtmlString</code> and <code>MvcHtmlString</code> classes starting with .NET 4.0. These both implement the <code>IHtmlString</code> interface and will instruct ASP.NET to skip output encoding when using <code><%: model.Property %></code> or <code>@model.Property</code> in HTML markup. Converting a property on your view model from <code>String</code> to <code>MvcHtmlString</code> will instruct ASP.NET that HTML encoding has already been accounted for.

<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public MvcHtmlString Description { get; set; } // Output encoding is handled manually
}</pre>

==Enhanced Encoding==
By default the ASP.NET encoding methods use a black-listing technique that evaluates the string for a set of character combinations that may indicate presence of malicious script. A superior approach is to use a [[Input Validation Cheat Sheet#White_List_Input_Validation|white-listing technique]] for validation, which can be achieved using the Anti-Cross Site Scripting Library from Microsoft. Starting with ASP.NET 4.5 you can specify that the <code>AntiXssEncoder</code> from this library be used as the default encoder for you entire application using the <code>encoderType</code> setting in web.config as shown below.
<pre><httpRuntime encoderType="System.Web.Security.AntiXss.AntiXssEncoder" /></pre>

If you are using a version of .NET earlier than 4.5, you will need to download and include the library as a reference to your project, and then use the earlier library name for the encodeType setting as shown below.
<pre><httpRuntime encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" /></pre>

In addition to the common <code>HtmlEncode</code> and <code>UrlEncode</code> methods, the Anti-Cross Site Scripting Library provides the following <code>AntiXssEncoder</code> methods for more specialized output encoding needs:

{| class="wikitable"
|CssEncode
|Encodes the specified string for use in cascading style sheets (CSS).
|-
|HeaderNameValueEncode
|Encodes a header name and value into a string that can be used as an HTTP header.
|-
|HtmlAttributeEncode
|Encodes and outputs the specified string for use in an HTML attribute.
|-
|HtmlFormUrlEncode
|Encodes the specified string for use in form submissions whose MIME type is "application/x-www-form-urlencoded".
|-
|JavaScriptStringEncode
|Encodes a string for use in JavaScript.
|-
|UrlPathEncode
|Encodes path strings for use in a URL.
|-
|XmlAttributeEncode
|Encodes the specified string for use in XML attributes.
|-
|XmlEncode
|Encodes the specified string for use in XML.
|}

==References==
*[http://blogs.msdn.com/b/cisg/archive/2008/08/28/output-encoding.aspx Output Encoding]
*[http://msdn.microsoft.com/en-us/library/System.Web.HttpUtility_methods(v=vs.110).aspx HttpUtility Methods]
*[http://weblogs.asp.net/scottgu/new-lt-gt-syntax-for-html-encoding-output-in-asp-net-4-and-asp-net-mvc-2 New <%: %> Syntax for HTML Encoding Output in ASP.NET 4 (and ASP.NET MVC 2)]
*[http://msdn.microsoft.com/en-us/library/system.web.ihtmlstring(v=vs.110).aspx IHtmlString Interface]
*[http://stackoverflow.com/questions/2293357/what-is-an-mvchtmlstring-and-when-should-i-use-it What is an MvcHtmlString and when should I use it?]
*[http://www.microsoft.com/en-sg/download/details.aspx?id=43126 Microsoft Anti-Cross Site Scripting Library V4.3]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder_methods(v=vs.110).aspx AntiXssEncoder Methods]
*[[ASP.NET Request Validation]]

[[Category:OWASP .NET Project]][[Category:Stub]]

ASP.NET Request Validation

2014-11-03T14:56:42Z

Bricex: Adding - Extending Request Validation

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
''Request validation'' is a feature in ASP.NET that examines HTTP requests and determines whether they contain potentially dangerous content. This check adds protection from markup or code in the URL query string, cookies, or posted form values that might have been added for malicious purposes. This exploit is typically referred to as a ''cross-site scripting'' (XSS) attack. Request validation helps to prevent this kind of attack by throwing a "potentially dangerous value was detected" error and halting page processing if it detects input that may be malicious, such as markup or code in the request.

==Don't Rely on Request Validation for XSS Protection==
Request validation is generally desirable and should be left enabled for [[defense in depth]]. It should '''NOT''' be used as your sole method of XSS protection, and does not guarantee to catch every type of invalid input. There are known, documented bypasses (such as JSON requests) that will not be addressed in future releases, and the request validation feature is no longer provided in ASP.NET vNext.

Fully protecting your application from malicious input requires validating each field of user supplied data. This should start with [http://msdn.microsoft.com/en-us/library/debza5t0(v=vs.100).aspx ASP.NET Validation Controls] and/or [http://msdn.microsoft.com/en-us/library/ee256141(VS.100).aspx DataAnnotations attributes] to check for:
* Required fields
* Correct data type and length
* Data falls within an acceptable range
* Whitelist of allowed characters

Any string input that is stored, returned to the client, or interpreted should be encoded using an appropriate method, such as those provided via [[ASP.NET Output Encoding#Enhanced_Encoding|AntiXssEncoder]].

<pre>var encodedInput = Server.HtmlEncode(userInput);</pre>

==Enabling Request Validation==
Request validation is enabled by default in ASP.NET. You can check to make sure it is enabled by reviewing the following areas:

{| class="wikitable"
|style="width: 20%;"|ASP.NET Web Forms (Global)
|Ensure that request validation is set to true (or not set at all) in web.config: <pre><pages validateRequest="true" /></pre>
|-
|ASP.NET Web Forms (Page Level)
|Check to make sure request validation is set to true (or not set at all) at the page level: <pre><@ Page ValidateRequest="false" %></pre>
|-
|ASP.NET 4.0+
|Starting with ASP.NET 4.0 request validation is performed for all requests, not just for .aspx page requests. To ensure this is configured correctly requestValidationMode should be set to "4.0" (or not set at all) in web.config: <pre><httpRuntime requestValidationMode="4.0" /></pre>
|-
|ASP.NET 4.5+
|There are enhancements added to request validation starting with ASP.NET 4.5 that include deferred ("lazy") validation, the ability to opt-out at the server control level, and the ability to access unvalidated data. In order to leverage these enhancements you will need to ensure that requestValidationMode has been set to "4.5" in web.config: <pre><httpRuntime requestValidationMode="4.5" targetFramework="4.5" /></pre>
|-
|ASP.NET Web API
|ASP.NET Web API does not utilize the request validation feature to sanitize user input. You will need to add this protection manually if any input will be used in HTML output. For example if user input is returned to the browser as the result from an AJAX request to a Web API method.
|}

==Selectively Disabling Request Validation==
In some cases you may need to accept input that will fail ASP.NET Request Validation, such as when receiving HTML markup from the end user. In these scenarios you should disable request validation for the smallest surface possible.

===ASP.NET Web Forms===
For ASP.NET Web Forms applications prior to v4.5, you will need to disable request validation at the page level. Be aware that when doing this all input values (cookies, query string, form elements) handled by this page will not be validated by ASP.NET.
<pre><@ Page ValidateRequest="false" %></pre>

Starting with ASP.NET 4.5 you can disable request validation at the individual server control level by setting <code>ValidateRequestMode</code> to "Disabled".
<pre><asp:TextBox ID="txtASPNet" ValidateRequestMode="Disabled" runat="server" /></pre>

===ASP.NET MVC===
To disable request validation for a specific MVC controller action, you can use the <code>[ValidateInput(false)]</code> attribute as shown below.
<pre>[ValidateInput(false)]
public ActionResult Update(int userId, string description)</pre>

Starting with ASP.NET MVC 3 you should use the <code>[AllowHtml]</code> attribute to decorate specific fields on your view model classes where request validation should not be applied:
<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public string Email { get; set; }
[AllowHtml]
public string Description { get; set; }
[AllowHtml]
public string Bio { get; set; }
}</pre>

==Extending Request Validation==
If you are using ASP.NET 4.0 or higher, you have the option of extending or replacing the Request Validation logic by providing your own class that descends from <code>System.Web.Util.RequestValidator</code>. By implementing this class, you can determine when validation occurs and what type of request data to perform validation on.
<pre>public class CustomRequestValidation : RequestValidator
{
protected override bool IsValidRequestString(
HttpContext context,
string value,
RequestValidationSource requestValidationSource,
string collectionKey,
out int validationFailureIndex)
{
validationFailureIndex = -1;

// This is just an example and should not
// be used for production code.
if (value.Contains("<%"))
{
return false;
}
else // Leave any further checks to ASP.NET.
{
return base.IsValidRequestString(
context,
value,
requestValidationSource,
collectionKey,
out validationFailureIndex);
}
}
}</pre>
This class is then registered in web.config using <code>requestValidationType</code>:
<pre>
<system.web>
<httpRuntime requestValidationType="CustomRequestValidation"/>
</system.web>
</pre>
==References==
*[http://msdn.microsoft.com/en-us/library/hh882339(v=vs.110).aspx Request Validation in ASP.NET]
*[http://msdn.microsoft.com/en-us/library/debza5t0(v=vs.100).aspx Validation ASP.NET Controls]
*[http://msdn.microsoft.com/en-us/library/ee256141(VS.100).aspx How to: Validate Model Data Using DataAnnotations Attributes]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder(v=vs.110).aspx AntiXssEncoder Class]
*[http://www.asp.net/aspnet/overview/aspnet-and-visual-studio-2012/whats-new#_Toc318097379 New ASP.NET Request Validation Features]
*[http://msdn.microsoft.com/en-us/library/system.web.ui.control.validaterequestmode(v=vs.110).aspx Control.ValidateRequestMode Property]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.validateinputattribute(v=vs.118).aspx ValidateInputAttribute Class]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.allowhtmlattribute(v=vs.118).aspx AllowHtmlAttribute Class]
*[http://msdn.microsoft.com/en-us/library/system.web.util.requestvalidator(v=vs.110).aspx RequestValidator Class]
*[[ASP.NET Output Encoding]]

[[Category:OWASP .NET Project]]

ASP.NET Request Validation

2014-11-03T14:37:12Z

Bricex: /* Selectively Disabling Request Validation */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
''Request validation'' is a feature in ASP.NET that examines HTTP requests and determines whether they contain potentially dangerous content. This check adds protection from markup or code in the URL query string, cookies, or posted form values that might have been added for malicious purposes. This exploit is typically referred to as a ''cross-site scripting'' (XSS) attack. Request validation helps to prevent this kind of attack by throwing a "potentially dangerous value was detected" error and halting page processing if it detects input that may be malicious, such as markup or code in the request.

==Don't Rely on Request Validation for XSS Protection==
Request validation is generally desirable and should be left enabled for [[defense in depth]]. It should '''NOT''' be used as your sole method of XSS protection, and does not guarantee to catch every type of invalid input. There are known, documented bypasses (such as JSON requests) that will not be addressed in future releases, and the request validation feature is no longer provided in ASP.NET vNext.

Fully protecting your application from malicious input requires validating each field of user supplied data. This should start with [http://msdn.microsoft.com/en-us/library/debza5t0(v=vs.100).aspx ASP.NET Validation Controls] and/or [http://msdn.microsoft.com/en-us/library/ee256141(VS.100).aspx DataAnnotations attributes] to check for:
* Required fields
* Correct data type and length
* Data falls within an acceptable range
* Whitelist of allowed characters

Any string input that is stored, returned to the client, or interpreted should be encoded using an appropriate method, such as those provided via [[ASP.NET Output Encoding#Enhanced_Encoding|AntiXssEncoder]].

<pre>var encodedInput = Server.HtmlEncode(userInput);</pre>

==Enabling Request Validation==
Request validation is enabled by default in ASP.NET. You can check to make sure it is enabled by reviewing the following areas:

{| class="wikitable"
|style="width: 20%;"|ASP.NET Web Forms (Global)
|Ensure that request validation is set to true (or not set at all) in web.config: <pre><pages validateRequest="true" /></pre>
|-
|ASP.NET Web Forms (Page Level)
|Check to make sure request validation is set to true (or not set at all) at the page level: <pre><@ Page ValidateRequest="false" %></pre>
|-
|ASP.NET 4.0+
|Starting with ASP.NET 4.0 request validation is performed for all requests, not just for .aspx page requests. To ensure this is configured correctly requestValidationMode should be set to "4.0" (or not set at all) in web.config: <pre><httpRuntime requestValidationMode="4.0" /></pre>
|-
|ASP.NET 4.5+
|There are enhancements added to request validation starting with ASP.NET 4.5 that include deferred ("lazy") validation, the ability to opt-out at the server control level, and the ability to access unvalidated data. In order to leverage these enhancements you will need to ensure that requestValidationMode has been set to "4.5" in web.config: <pre><httpRuntime requestValidationMode="4.5" targetFramework="4.5" /></pre>
|-
|ASP.NET Web API
|ASP.NET Web API does not utilize the request validation feature to sanitize user input. You will need to add this protection manually if any input will be used in HTML output. For example if user input is returned to the browser as the result from an AJAX request to a Web API method.
|}

==Selectively Disabling Request Validation==
In some cases you may need to accept input that will fail ASP.NET Request Validation, such as when receiving HTML markup from the end user. In these scenarios you should disable request validation for the smallest surface possible.

===ASP.NET Web Forms===
For ASP.NET Web Forms applications prior to v4.5, you will need to disable request validation at the page level. Be aware that when doing this all input values (cookies, query string, form elements) handled by this page will not be validated by ASP.NET.
<pre><@ Page ValidateRequest="false" %></pre>

Starting with ASP.NET 4.5 you can disable request validation at the individual server control level by setting <code>ValidateRequestMode</code> to "Disabled".
<pre><asp:TextBox ID="txtASPNet" ValidateRequestMode="Disabled" runat="server" /></pre>

===ASP.NET MVC===
To disable request validation for a specific MVC controller action, you can use the <code>[ValidateInput(false)]</code> attribute as shown below.
<pre>[ValidateInput(false)]
public ActionResult Update(int userId, string description)</pre>

Starting with ASP.NET MVC 3 you should use the <code>[AllowHtml]</code> attribute to decorate specific fields on your view model classes where request validation should not be applied:
<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public string Email { get; set; }
[AllowHtml]
public string Description { get; set; }
[AllowHtml]
public string Bio { get; set; }
}</pre>

==References==
*[http://msdn.microsoft.com/en-us/library/hh882339(v=vs.110).aspx Request Validation in ASP.NET]
*[http://msdn.microsoft.com/en-us/library/debza5t0(v=vs.100).aspx Validation ASP.NET Controls]
*[http://msdn.microsoft.com/en-us/library/ee256141(VS.100).aspx How to: Validate Model Data Using DataAnnotations Attributes]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder(v=vs.110).aspx AntiXssEncoder Class]
*[http://www.asp.net/aspnet/overview/aspnet-and-visual-studio-2012/whats-new#_Toc318097379 New ASP.NET Request Validation Features]
*[http://msdn.microsoft.com/en-us/library/system.web.ui.control.validaterequestmode(v=vs.110).aspx Control.ValidateRequestMode Property]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.validateinputattribute(v=vs.118).aspx ValidateInputAttribute Class]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.allowhtmlattribute(v=vs.118).aspx AllowHtmlAttribute Class]
*[[ASP.NET Output Encoding]]

[[Category:OWASP .NET Project]]

ASP.NET Request Validation

2014-11-03T14:36:09Z

Bricex: /* Enabling Request Validation */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
''Request validation'' is a feature in ASP.NET that examines HTTP requests and determines whether they contain potentially dangerous content. This check adds protection from markup or code in the URL query string, cookies, or posted form values that might have been added for malicious purposes. This exploit is typically referred to as a ''cross-site scripting'' (XSS) attack. Request validation helps to prevent this kind of attack by throwing a "potentially dangerous value was detected" error and halting page processing if it detects input that may be malicious, such as markup or code in the request.

==Don't Rely on Request Validation for XSS Protection==
Request validation is generally desirable and should be left enabled for [[defense in depth]]. It should '''NOT''' be used as your sole method of XSS protection, and does not guarantee to catch every type of invalid input. There are known, documented bypasses (such as JSON requests) that will not be addressed in future releases, and the request validation feature is no longer provided in ASP.NET vNext.

Fully protecting your application from malicious input requires validating each field of user supplied data. This should start with [http://msdn.microsoft.com/en-us/library/debza5t0(v=vs.100).aspx ASP.NET Validation Controls] and/or [http://msdn.microsoft.com/en-us/library/ee256141(VS.100).aspx DataAnnotations attributes] to check for:
* Required fields
* Correct data type and length
* Data falls within an acceptable range
* Whitelist of allowed characters

Any string input that is stored, returned to the client, or interpreted should be encoded using an appropriate method, such as those provided via [[ASP.NET Output Encoding#Enhanced_Encoding|AntiXssEncoder]].

<pre>var encodedInput = Server.HtmlEncode(userInput);</pre>

==Enabling Request Validation==
Request validation is enabled by default in ASP.NET. You can check to make sure it is enabled by reviewing the following areas:

{| class="wikitable"
|style="width: 20%;"|ASP.NET Web Forms (Global)
|Ensure that request validation is set to true (or not set at all) in web.config: <pre><pages validateRequest="true" /></pre>
|-
|ASP.NET Web Forms (Page Level)
|Check to make sure request validation is set to true (or not set at all) at the page level: <pre><@ Page ValidateRequest="false" %></pre>
|-
|ASP.NET 4.0+
|Starting with ASP.NET 4.0 request validation is performed for all requests, not just for .aspx page requests. To ensure this is configured correctly requestValidationMode should be set to "4.0" (or not set at all) in web.config: <pre><httpRuntime requestValidationMode="4.0" /></pre>
|-
|ASP.NET 4.5+
|There are enhancements added to request validation starting with ASP.NET 4.5 that include deferred ("lazy") validation, the ability to opt-out at the server control level, and the ability to access unvalidated data. In order to leverage these enhancements you will need to ensure that requestValidationMode has been set to "4.5" in web.config: <pre><httpRuntime requestValidationMode="4.5" targetFramework="4.5" /></pre>
|-
|ASP.NET Web API
|ASP.NET Web API does not utilize the request validation feature to sanitize user input. You will need to add this protection manually if any input will be used in HTML output. For example if user input is returned to the browser as the result from an AJAX request to a Web API method.
|}

==Selectively Disabling Request Validation==
In some cases you may need to accept input that will fail ASP.NET Request Validation, such as when receiving HTML markup from the end user. In these scenarios you should disable request validation for the smallest surface possible and ensure you have implemented field level input validation.

===ASP.NET Web Forms===
For ASP.NET Web Forms applications prior to v4.5, you will need to disable request validation at the page level. Be aware that when doing this all input values (cookies, query string, form elements) handled by this page will not be validated by ASP.NET.
<pre><@ Page ValidateRequest="false" %></pre>

Starting with ASP.NET 4.5 you can disable request validation at the individual server control level by setting <code>ValidateRequestMode</code> to "Disabled".
<pre><asp:TextBox ID="txtASPNet" ValidateRequestMode="Disabled" runat="server" /></pre>

===ASP.NET MVC===
To disable request validation for a specific MVC controller action, you can use the <code>[ValidateInput(false)]</code> attribute as shown below.
<pre>[ValidateInput(false)]
public ActionResult Update(int userId, string description)</pre>

Starting with ASP.NET MVC 3 you should use the <code>[AllowHtml]</code> attribute to decorate specific fields on your view model classes where request validation should not be applied:
<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public string Email { get; set; }
[AllowHtml]
public string Description { get; set; }
[AllowHtml]
public string Bio { get; set; }
}</pre>

==References==
*[http://msdn.microsoft.com/en-us/library/hh882339(v=vs.110).aspx Request Validation in ASP.NET]
*[http://msdn.microsoft.com/en-us/library/debza5t0(v=vs.100).aspx Validation ASP.NET Controls]
*[http://msdn.microsoft.com/en-us/library/ee256141(VS.100).aspx How to: Validate Model Data Using DataAnnotations Attributes]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder(v=vs.110).aspx AntiXssEncoder Class]
*[http://www.asp.net/aspnet/overview/aspnet-and-visual-studio-2012/whats-new#_Toc318097379 New ASP.NET Request Validation Features]
*[http://msdn.microsoft.com/en-us/library/system.web.ui.control.validaterequestmode(v=vs.110).aspx Control.ValidateRequestMode Property]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.validateinputattribute(v=vs.118).aspx ValidateInputAttribute Class]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.allowhtmlattribute(v=vs.118).aspx AllowHtmlAttribute Class]
*[[ASP.NET Output Encoding]]

[[Category:OWASP .NET Project]]

ASP.NET Request Validation

2014-11-03T14:25:42Z

Bricex: /* Don't Rely on Request Validation for XSS Protection */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
''Request validation'' is a feature in ASP.NET that examines HTTP requests and determines whether they contain potentially dangerous content. This check adds protection from markup or code in the URL query string, cookies, or posted form values that might have been added for malicious purposes. This exploit is typically referred to as a ''cross-site scripting'' (XSS) attack. Request validation helps to prevent this kind of attack by throwing a "potentially dangerous value was detected" error and halting page processing if it detects input that may be malicious, such as markup or code in the request.

==Don't Rely on Request Validation for XSS Protection==
Request validation is generally desirable and should be left enabled for [[defense in depth]]. It should '''NOT''' be used as your sole method of XSS protection, and does not guarantee to catch every type of invalid input. There are known, documented bypasses (such as JSON requests) that will not be addressed in future releases, and the request validation feature is no longer provided in ASP.NET vNext.

Fully protecting your application from malicious input requires validating each field of user supplied data. This should start with [http://msdn.microsoft.com/en-us/library/debza5t0(v=vs.100).aspx ASP.NET Validation Controls] and/or [http://msdn.microsoft.com/en-us/library/ee256141(VS.100).aspx DataAnnotations attributes] to check for:
* Required fields
* Correct data type and length
* Data falls within an acceptable range
* Whitelist of allowed characters

Any string input that is stored, returned to the client, or interpreted should be encoded using an appropriate method, such as those provided via [[ASP.NET Output Encoding#Enhanced_Encoding|AntiXssEncoder]].

<pre>var encodedInput = Server.HtmlEncode(userInput);</pre>

==Enabling Request Validation==
Request validation is enabled by default in ASP.NET. You can check to make sure it is not disabled by reviewing he following areas:

{| class="wikitable"
|ASP.NET Web Forms (Global)
|Ensure that request validation has not been disabled in web.config: <code><pages validateRequest="false" /></code>
|-
|ASP.NET Web Forms (Page Level)
|Check to make sure request validation is not disabled at the page level: <code><@ Page ValidateRequest="false" %></code>
|-
|ASP.NET 4.0+
|Starting with ASP.NET 4.0 request validation is performed for all requests, not just for .aspx page requests. To ensure this is configured correctly look to see that it has '''NOT''' been set to 2.0: <code><httpRuntime requestValidationMode="2.0" /></code>
|}

===ASP.NET 4.5+===
There are enhancements added to request validation starting with ASP.NET 4.5 that include deferred ("lazy") validation, the ability to opt-out at the server control level, and the ability to access unvalidated data. In order to leverage these enhancements you will need to ensure that <code>requestValidationMode</code> has been set to "4.5".

<pre><httpRuntime requestValidationMode="4.5" targetFramework="4.5" /></pre>

===ASP.NET Web API===
ASP.NET Web API does not utilize the request validation feature to sanitize user input. You will need to add this protection manually if any input will be used in HTML output. For example if user input is returned to the browser as the result from an AJAX request to a Web API method.

==Selectively Disabling Request Validation==
In some cases you may need to accept input that will fail ASP.NET Request Validation, such as when receiving HTML markup from the end user. In these scenarios you should disable request validation for the smallest surface possible and ensure you have implemented field level input validation.

===ASP.NET Web Forms===
For ASP.NET Web Forms applications prior to v4.5, you will need to disable request validation at the page level. Be aware that when doing this all input values (cookies, query string, form elements) handled by this page will not be validated by ASP.NET.
<pre><@ Page ValidateRequest="false" %></pre>

Starting with ASP.NET 4.5 you can disable request validation at the individual server control level by setting <code>ValidateRequestMode</code> to "Disabled".
<pre><asp:TextBox ID="txtASPNet" ValidateRequestMode="Disabled" runat="server" /></pre>

===ASP.NET MVC===
To disable request validation for a specific MVC controller action, you can use the <code>[ValidateInput(false)]</code> attribute as shown below.
<pre>[ValidateInput(false)]
public ActionResult Update(int userId, string description)</pre>

Starting with ASP.NET MVC 3 you should use the <code>[AllowHtml]</code> attribute to decorate specific fields on your view model classes where request validation should not be applied:
<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public string Email { get; set; }
[AllowHtml]
public string Description { get; set; }
[AllowHtml]
public string Bio { get; set; }
}</pre>

==References==
*[http://msdn.microsoft.com/en-us/library/hh882339(v=vs.110).aspx Request Validation in ASP.NET]
*[http://msdn.microsoft.com/en-us/library/debza5t0(v=vs.100).aspx Validation ASP.NET Controls]
*[http://msdn.microsoft.com/en-us/library/ee256141(VS.100).aspx How to: Validate Model Data Using DataAnnotations Attributes]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder(v=vs.110).aspx AntiXssEncoder Class]
*[http://www.asp.net/aspnet/overview/aspnet-and-visual-studio-2012/whats-new#_Toc318097379 New ASP.NET Request Validation Features]
*[http://msdn.microsoft.com/en-us/library/system.web.ui.control.validaterequestmode(v=vs.110).aspx Control.ValidateRequestMode Property]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.validateinputattribute(v=vs.118).aspx ValidateInputAttribute Class]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.allowhtmlattribute(v=vs.118).aspx AllowHtmlAttribute Class]
*[[ASP.NET Output Encoding]]

[[Category:OWASP .NET Project]]

ASP.NET Output Encoding

2014-11-03T14:17:32Z

Bricex: Changing sub title

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
Cross-site scripting attacks exploit vulnerabilities in web page validation by injecting client-side script code. The script code embeds itself in response data, which is sent back to an unsuspecting user. In addition to validating input, any data retrieved from untrusted or shared sources should be encoded on output. For example: data retrieved from a database that may have had malicious input persisted to it.

==Validating Input==
See the [[ASP.NET Request Validation]] article for details on how request validation can be used to protect against malicious input.

==Encoding Output Values in Code==
Use <code>Server.HtmlEncode</code> to encode untrusted data for use in HTML output:
<pre>var encodedHtml = Server.HtmlEncode(untrustedData);</pre>

Use <code>Server.UrlEncode</code> to encode untrusted data for use in constructing URLs
<pre>var encodedUrl = Server.UrlEncode(untrustedData);</pre>

==Encoding Output Values in HTML markup==
You can HTML encode the value in markup with the <code><%: %></code> syntax, as shown below.
<pre><span><%: untrustedData%></span></pre>

Or, in Razor syntax, you can HTML encode with <code>@</code>, as shown below.
<pre><span>@untrustedData</span></pre>

==IHtmlString==
If you have model properties that are used to display raw HTML you should consider using the <code>HtmlString</code> and <code>MvcHtmlString</code> classes starting with .NET 4.0. These both implement the <code>IHtmlString</code> interface and will instruct ASP.NET to skip output encoding when using <code><%: model.Property %></code> or <code>@model.Property</code> in HTML markup. Converting a property on your view model from <code>String</code> to <code>MvcHtmlString</code> will instruct ASP.NET that HTML encoding has already been accounted for.

<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public MvcHtmlString Description { get; set; } // Output encoding is handled manually
}</pre>

==Enhanced Encoding==
By default the ASP.NET encoding methods use a black-listing technique that evaluates the string for a set of character combinations that may indicate presence of malicious script. A superior approach is to use a [[Input Validation Cheat Sheet#White_List_Input_Validation|white-listing technique]] for validation, which can be achieved using the Anti-Cross Site Scripting Library from Microsoft. Starting with ASP.NET 4.5 you can specify that the <code>AntiXssEncoder</code> from this library be used as the default encoder for you entire application using the <code>encoderType</code> setting in web.config as shown below.
<pre><httpRuntime encoderType="System.Web.Security.AntiXss.AntiXssEncoder" /></pre>

If you are using a version of .NET earlier than 4.5, you will need to download and include the library as a reference to your project, and then use the earlier library name for the encodeType setting as shown below.
<pre><httpRuntime encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" /></pre>

In addition to the common <code>HtmlEncode</code> and <code>UrlEncode</code> methods, the Anti-Cross Site Scripting Library provides the following <code>AntiXssEncoder</code> methods for more specialized output encoding needs:

{| class="wikitable"
|CssEncode
|Encodes the specified string for use in cascading style sheets (CSS).
|-
|HeaderNameValueEncode
|Encodes a header name and value into a string that can be used as an HTTP header.
|-
|HtmlAttributeEncode
|Encodes and outputs the specified string for use in an HTML attribute.
|-
|HtmlFormUrlEncode
|Encodes the specified string for use in form submissions whose MIME type is "application/x-www-form-urlencoded".
|-
|JavaScriptStringEncode
|Encodes a string for use in JavaScript.
|-
|UrlPathEncode
|Encodes path strings for use in a URL.
|-
|XmlAttributeEncode
|Encodes the specified string for use in XML attributes.
|-
|XmlEncode
|Encodes the specified string for use in XML.
|}

==References==
*[http://blogs.msdn.com/b/cisg/archive/2008/08/28/output-encoding.aspx Output Encoding]
*[http://msdn.microsoft.com/en-us/library/System.Web.HttpUtility_methods(v=vs.110).aspx HttpUtility Methods]
*[http://weblogs.asp.net/scottgu/new-lt-gt-syntax-for-html-encoding-output-in-asp-net-4-and-asp-net-mvc-2 New <%: %> Syntax for HTML Encoding Output in ASP.NET 4 (and ASP.NET MVC 2)]
*[http://msdn.microsoft.com/en-us/library/system.web.ihtmlstring(v=vs.110).aspx IHtmlString Interface]
*[http://stackoverflow.com/questions/2293357/what-is-an-mvchtmlstring-and-when-should-i-use-it What is an MvcHtmlString and when should I use it?]
*[http://www.microsoft.com/en-sg/download/details.aspx?id=43126 Microsoft Anti-Cross Site Scripting Library V4.3]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder_methods(v=vs.110).aspx AntiXssEncoder Methods]

[[Category:OWASP .NET Project]][[Category:Stub]]

ASP.NET Request Validation

2014-11-03T00:16:21Z

Bricex:

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
''Request validation'' is a feature in ASP.NET that examines HTTP requests and determines whether they contain potentially dangerous content. This check adds protection from markup or code in the URL query string, cookies, or posted form values that might have been added for malicious purposes. This exploit is typically referred to as a ''cross-site scripting'' (XSS) attack. Request validation helps to prevent this kind of attack by throwing a "potentially dangerous value was detected" error and halting page processing if it detects input that may be malicious, such as markup or code in the request.

==Don't Rely on Request Validation for XSS Protection==
Request validation is generally desirable and should be left enabled for [[defense in depth]]. It should '''NOT''' be used as your sole method of XSS protection, and does not guarantee to catch every type of invalid input. There are known, documented bypasses (such as JSON requests) that will not be addressed in future releases, and the request validation feature is no longer supported in ASP.NET vNext.

Fully protecting your application from malicious input involves validating each field of user supplied data. For Web Forms based applications this will start with [http://msdn.microsoft.com/en-us/library/debza5t0(v=vs.100).aspx ASP.NET Validation Controls]. ASP.NET MVC and Web API based applications should decorate model classes with [http://msdn.microsoft.com/en-us/library/ee256141(VS.100).aspx DataAnnotations attributes]. Any string input that is stored, returned to the client, or interpreted should be encoded using an appropriate method, such as those from [[ASP.NET Output Encoding#Enhanced_Encoding|AntiXssEncoder]].

<pre>var encodedInput = Server.HtmlEncode(userInput);</pre>

==Enabling Request Validation==
Request validation is enabled by default in ASP.NET. You can check to make sure it is not disabled by reviewing he following areas:

{| class="wikitable"
|ASP.NET Web Forms (Global)
|Ensure that request validation has not been disabled in web.config: <code><pages validateRequest="false" /></code>
|-
|ASP.NET Web Forms (Page Level)
|Check to make sure request validation is not disabled at the page level: <code><@ Page ValidateRequest="false" %></code>
|-
|ASP.NET 4.0+
|Starting with ASP.NET 4.0 request validation is performed for all requests, not just for .aspx page requests. To ensure this is configured correctly look to see that it has '''NOT''' been set to 2.0: <code><httpRuntime requestValidationMode="2.0" /></code>
|}

===ASP.NET 4.5+===
There are enhancements added to request validation starting with ASP.NET 4.5 that include deferred ("lazy") validation, the ability to opt-out at the server control level, and the ability to access unvalidated data. In order to leverage these enhancements you will need to ensure that <code>requestValidationMode</code> has been set to "4.5".

<pre><httpRuntime requestValidationMode="4.5" targetFramework="4.5" /></pre>

===ASP.NET Web API===
ASP.NET Web API does not utilize the request validation feature to sanitize user input. You will need to add this protection manually if any input will be used in HTML output. For example if user input is returned to the browser as the result from an AJAX request to a Web API method.

==Selectively Disabling Request Validation==
In some cases you may need to accept input that will fail ASP.NET Request Validation, such as when receiving HTML markup from the end user. In these scenarios you should disable request validation for the smallest surface possible and ensure you have implemented field level input validation.

===ASP.NET Web Forms===
For ASP.NET Web Forms applications prior to v4.5, you will need to disable request validation at the page level. Be aware that when doing this all input values (cookies, query string, form elements) handled by this page will not be validated by ASP.NET.
<pre><@ Page ValidateRequest="false" %></pre>

Starting with ASP.NET 4.5 you can disable request validation at the individual server control level by setting <code>ValidateRequestMode</code> to "Disabled".
<pre><asp:TextBox ID="txtASPNet" ValidateRequestMode="Disabled" runat="server" /></pre>

===ASP.NET MVC===
To disable request validation for a specific MVC controller action, you can use the <code>[ValidateInput(false)]</code> attribute as shown below.
<pre>[ValidateInput(false)]
public ActionResult Update(int userId, string description)</pre>

Starting with ASP.NET MVC 3 you should use the <code>[AllowHtml]</code> attribute to decorate specific fields on your view model classes where request validation should not be applied:
<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public string Email { get; set; }
[AllowHtml]
public string Description { get; set; }
[AllowHtml]
public string Bio { get; set; }
}</pre>

==References==
*[http://msdn.microsoft.com/en-us/library/hh882339(v=vs.110).aspx Request Validation in ASP.NET]
*[http://msdn.microsoft.com/en-us/library/debza5t0(v=vs.100).aspx Validation ASP.NET Controls]
*[http://msdn.microsoft.com/en-us/library/ee256141(VS.100).aspx How to: Validate Model Data Using DataAnnotations Attributes]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder(v=vs.110).aspx AntiXssEncoder Class]
*[http://www.asp.net/aspnet/overview/aspnet-and-visual-studio-2012/whats-new#_Toc318097379 New ASP.NET Request Validation Features]
*[http://msdn.microsoft.com/en-us/library/system.web.ui.control.validaterequestmode(v=vs.110).aspx Control.ValidateRequestMode Property]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.validateinputattribute(v=vs.118).aspx ValidateInputAttribute Class]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.allowhtmlattribute(v=vs.118).aspx AllowHtmlAttribute Class]
*[[ASP.NET Output Encoding]]

[[Category:OWASP .NET Project]]

ASP.NET Request Validation

2014-11-02T22:15:50Z

Bricex: /* Description */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
''Request validation'' is a feature in ASP.NET that examines HTTP requests and determines whether they contain potentially dangerous content. This check adds protection from markup or code in the URL query string, cookies, or posted form values that might have been added for malicious purposes. This exploit is typically referred to as a ''cross-site scripting'' (XSS) attack. Request validation helps to prevent this kind of attack by throwing a "potentially dangerous value was detected" error and halting page processing if it detects input that may be malicious, such as markup or code in the request.

===Don't Rely on Request Validation for XSS Protection===
Request validation is generally desirable and should be left enabled for [[defense in depth]]. It should '''not''' be used as your sole method of XSS protection, and does not guarantee to catch every type of invalid input. There are known, documented bypasses (such as JSON requests) that will not be addressed in future releases, and the request validation feature is no longer supported in ASP.NET vNext.

==Enabling Request Validation==
Request validation is enabled by default in ASP.NET. You can check to make sure it is not disabled at the page level by searching for any instances of:

<pre><@ Page ValidateRequest="false" %></pre>

You should also inspect the web.config file to ensure that request validation has not been disabled for the entire application:

<pre><pages validateRequest="false" /></pre>

Starting with ASP.NET 4.0 request validation is performed for all requests, not just for .aspx page requests. To ensure this is configured correctly look to see that <code>requestValidationMode</code> has '''NOT''' been set to 2.0.

<pre><httpRuntime requestValidationMode="2.0" /></pre>

===ASP.NET Web API===
ASP.NET Web API does not utilize the request validation feature to sanitize user input. You will need to add this protection manually if any input will be used in HTML output. For example if user input is returned to the browser as the result from an AJAX request to a Web API method.

==Validating User Input==
Even though request validation provides a good level of input protection, you should not fully rely on it for securing your application against cross-site scripting attacks. Instead, validate all input from users to ensure malicious code is not included.

Use <code>Server.HtmlEncode</code> to encode user input for use in HTML output:
<pre>var encodedHtmlInput = Server.HtmlEncode(userInput);</pre>

Use <code>Server.UrlEncode</code> to encode user input for use in constructing URLs
<pre>var encodedUrlInput = Server.UrlEncode(userInput);</pre>

===Enhanced Request Validation Encoding===
ASP.NET request validation uses a black-listing technique that evaluates the string for a set of character combinations that may indicate presence of malicious script. A superior approach is to use a [[Input Validation Cheat Sheet#White_List_Input_Validation|white-listing technique]] for input validation, which can be achieved using the Anti-Cross Site Scripting Library from Microsoft. Starting with ASP.NET 4.5 you can specify that the <code>AntiXssEncoder</code> from this library be used as the default encoder for you entire application using the <code>encoderType</code> setting in web.config as shown below.
<pre><httpRuntime encoderType="System.Web.Security.AntiXss.AntiXssEncoder" /></pre>

If you are using a version of .NET earlier than 4.5, you will need to download and include the library as a reference to your project, and then use the earlier library name for the encodeType setting as shown below.
<pre><httpRuntime encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" /></pre>

==Selectively Disabling Request Validation==
In some cases you may need to accept input that will fail ASP.NET Request Validation, such as when receiving HTML markup from the end user. In these scenarios you should disable request validation for the smallest surface possible, and replace it with your own custom input validation.

===ASP.NET Web Forms===
For ASP.NET Web Forms applications you will need to disable request validation at the page level. Be aware that when doing this all input values (cookies, query string, form elements) handled by this page will not be validated by ASP.NET.
<pre><@ Page ValidateRequest="false" %></pre>

===ASP.NET MVC===
To disable request validation for a specific MVC controller action, you can use the <code>[ValidateInput(false)]</code> attribute as shown below.
<pre>[ValidateInput(false)]
public ActionResult Update(int userId, string description)</pre>

Starting with ASP.NET MVC 3 you should use the <code>[AllowHtml]</code> attribute to decorate specific fields on your view model classes where request validation should not be applied:
<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public string Email { get; set; }
[AllowHtml]
public string Description { get; set; }
[AllowHtml]
public string Bio { get; set; }
}</pre>

==References==
*[http://msdn.microsoft.com/en-us/library/hh882339(v=vs.110).aspx Request Validation in ASP.NET]
*[http://msdn.microsoft.com/en-us/library/System.Web.HttpUtility_methods(v=vs.110).aspx HttpUtility Methods]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.validateinputattribute(v=vs.118).aspx ValidateInputAttribute Class]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.allowhtmlattribute(v=vs.118).aspx AllowHtmlAttribute Class]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder(v=vs.110).aspx AntiXssEncoder Class]
*[http://www.microsoft.com/en-sg/download/details.aspx?id=43126 Microsoft Anti-Cross Site Scripting Library V4.3]
*[[ASP.NET Output Encoding]]

[[Category:OWASP .NET Project]]

User:Bricex

2014-11-02T13:21:59Z

Bricex:

[[File:BriceWilliams.jpg|left|200px]] Brice Williams is an application security consultant with a focus on improving the state of information security within the software development life cycle. Brice brings over 17 years experience in the software security space, with a focus on the Microsoft technology stack. He is a member of the OWASP NYC chapter and a contributing author to the OWASP .NET Project.

Brice can be reached at brice.williams [at] owasp.org and on Twitter at [https://twitter.com/bricex @bricex].

File:BriceWilliams.jpg

2014-11-02T13:15:32Z

Bricex:

User:Bricex

2014-11-02T13:09:43Z

Bricex:

Brice Williams is an application security consultant with a focus on improving the state of information security within the software development life cycle. Brice brings over 17 years experience in the software security space, with a focus on the Microsoft technology stack. He is a member of the OWASP NYC chapter and a contributing author to the OWASP .NET Project.

ASP.NET Output Encoding

2014-10-30T19:25:30Z

Bricex: /* References */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
Cross-site scripting attacks exploit vulnerabilities in web page validation by injecting client-side script code. The script code embeds itself in response data, which is sent back to an unsuspecting user. In addition to validating input, any data retrieved from untrusted or shared sources should be encoded on output. For example: data retrieved from a database that may have had malicious input persisted to it.

==Validating Input==
See the [[ASP.NET Request Validation]] article for details on how request validation can be used to protect against malicious input.

==Encoding Output Values in Code==
Use <code>Server.HtmlEncode</code> to encode untrusted data for use in HTML output:
<pre>var encodedHtml = Server.HtmlEncode(untrustedData);</pre>

Use <code>Server.UrlEncode</code> to encode untrusted data for use in constructing URLs
<pre>var encodedUrl = Server.UrlEncode(untrustedData);</pre>

==Encoding Output Values in HTML markup==
You can HTML encode the value in markup with the <code><%: %></code> syntax, as shown below.
<pre><span><%: untrustedData%></span></pre>

Or, in Razor syntax, you can HTML encode with <code>@</code>, as shown below.
<pre><span>@untrustedData</span></pre>

==Preventing Double Encoding==
You may run into a scenario where encoding values results in them becoming double encoded on output. ASP.NET provides the <code>HtmlString</code> and <code>MvcHtmlString</code> classes starting with .NET 4.0 which are designed to help. These both implement the <code>IHtmlString</code> interface which will instruct ASP.NET to not apply encoding within HTML markup when using <code><%: untrustedData %></code> or <code>@untrustedData</code>. Converting a property on your view model from <code>String</code> to <code>MvcHtmlString</code> will instruct ASP.NET that HTML encoding has already been accounted for.

<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public MvcHtmlString Description { get; set; } // Output encoding is handled manually
}</pre>

==Enhanced Encoding==
By default the ASP.NET encoding methods use a black-listing technique that evaluates the string for a set of character combinations that may indicate presence of malicious script. A superior approach is to use a [[Input Validation Cheat Sheet#White_List_Input_Validation|white-listing technique]] for validation, which can be achieved using the Anti-Cross Site Scripting Library from Microsoft. Starting with ASP.NET 4.5 you can specify that the <code>AntiXssEncoder</code> from this library be used as the default encoder for you entire application using the <code>encoderType</code> setting in web.config as shown below.
<pre><httpRuntime encoderType="System.Web.Security.AntiXss.AntiXssEncoder" /></pre>

If you are using a version of .NET earlier than 4.5, you will need to download and include the library as a reference to your project, and then use the earlier library name for the encodeType setting as shown below.
<pre><httpRuntime encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" /></pre>

In addition to the common <code>HtmlEncode</code> and <code>UrlEncode</code> methods, the Anti-Cross Site Scripting Library provides the following <code>AntiXssEncoder</code> methods for more specialized output encoding needs:

{| class="wikitable"
|CssEncode
|Encodes the specified string for use in cascading style sheets (CSS).
|-
|HeaderNameValueEncode
|Encodes a header name and value into a string that can be used as an HTTP header.
|-
|HtmlAttributeEncode
|Encodes and outputs the specified string for use in an HTML attribute.
|-
|HtmlFormUrlEncode
|Encodes the specified string for use in form submissions whose MIME type is "application/x-www-form-urlencoded".
|-
|JavaScriptStringEncode
|Encodes a string for use in JavaScript.
|-
|UrlPathEncode
|Encodes path strings for use in a URL.
|-
|XmlAttributeEncode
|Encodes the specified string for use in XML attributes.
|-
|XmlEncode
|Encodes the specified string for use in XML.
|}

==References==
*[http://blogs.msdn.com/b/cisg/archive/2008/08/28/output-encoding.aspx Output Encoding]
*[http://msdn.microsoft.com/en-us/library/System.Web.HttpUtility_methods(v=vs.110).aspx HttpUtility Methods]
*[http://weblogs.asp.net/scottgu/new-lt-gt-syntax-for-html-encoding-output-in-asp-net-4-and-asp-net-mvc-2 New <%: %> Syntax for HTML Encoding Output in ASP.NET 4 (and ASP.NET MVC 2)]
*[http://msdn.microsoft.com/en-us/library/system.web.ihtmlstring(v=vs.110).aspx IHtmlString Interface]
*[http://stackoverflow.com/questions/2293357/what-is-an-mvchtmlstring-and-when-should-i-use-it What is an MvcHtmlString and when should I use it?]
*[http://www.microsoft.com/en-sg/download/details.aspx?id=43126 Microsoft Anti-Cross Site Scripting Library V4.3]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder_methods(v=vs.110).aspx AntiXssEncoder Methods]

[[Category:OWASP .NET Project]][[Category:Stub]]

ASP.NET Request Validation

2014-10-30T19:23:12Z

Bricex: /* Validating User Input */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
''Request validation'' is a feature in ASP.NET that examines HTTP requests and determines whether they contain potentially dangerous content. 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 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. Request validation is generally desirable and should be left enabled unless you have a specific need that would prevent it from being used.

==Enabling Request Validation==
Request validation is enabled by default in ASP.NET. You can check to make sure it is not disabled at the page level by searching for any instances of:

<pre><@ Page ValidateRequest="false" %></pre>

You should also inspect the web.config file to ensure that request validation has not been disabled for the entire application:

<pre><pages validateRequest="false" /></pre>

Starting with ASP.NET 4.0 request validation is performed for all requests, not just for .aspx page requests. To ensure this is configured correctly look to see that <code>requestValidationMode</code> has '''NOT''' been set to 2.0.

<pre><httpRuntime requestValidationMode="2.0" /></pre>

===ASP.NET Web API===
ASP.NET Web API does not utilize the request validation feature to sanitize user input. You will need to add this protection manually if any input will be used in HTML output. For example if user input is returned to the browser as the result from an AJAX request to a Web API method.

==Validating User Input==
Even though request validation provides a good level of input protection, you should not fully rely on it for securing your application against cross-site scripting attacks. Instead, validate all input from users to ensure malicious code is not included.

Use <code>Server.HtmlEncode</code> to encode user input for use in HTML output:
<pre>var encodedHtmlInput = Server.HtmlEncode(userInput);</pre>

Use <code>Server.UrlEncode</code> to encode user input for use in constructing URLs
<pre>var encodedUrlInput = Server.UrlEncode(userInput);</pre>

===Enhanced Request Validation Encoding===
ASP.NET request validation uses a black-listing technique that evaluates the string for a set of character combinations that may indicate presence of malicious script. A superior approach is to use a [[Input Validation Cheat Sheet#White_List_Input_Validation|white-listing technique]] for input validation, which can be achieved using the Anti-Cross Site Scripting Library from Microsoft. Starting with ASP.NET 4.5 you can specify that the <code>AntiXssEncoder</code> from this library be used as the default encoder for you entire application using the <code>encoderType</code> setting in web.config as shown below.
<pre><httpRuntime encoderType="System.Web.Security.AntiXss.AntiXssEncoder" /></pre>

If you are using a version of .NET earlier than 4.5, you will need to download and include the library as a reference to your project, and then use the earlier library name for the encodeType setting as shown below.
<pre><httpRuntime encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" /></pre>

==Selectively Disabling Request Validation==
In some cases you may need to accept input that will fail ASP.NET Request Validation, such as when receiving HTML markup from the end user. In these scenarios you should disable request validation for the smallest surface possible, and replace it with your own custom input validation.

===ASP.NET Web Forms===
For ASP.NET Web Forms applications you will need to disable request validation at the page level. Be aware that when doing this all input values (cookies, query string, form elements) handled by this page will not be validated by ASP.NET.
<pre><@ Page ValidateRequest="false" %></pre>

===ASP.NET MVC===
To disable request validation for a specific MVC controller action, you can use the <code>[ValidateInput(false)]</code> attribute as shown below.
<pre>[ValidateInput(false)]
public ActionResult Update(int userId, string description)</pre>

Starting with ASP.NET MVC 3 you should use the <code>[AllowHtml]</code> attribute to decorate specific fields on your view model classes where request validation should not be applied:
<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public string Email { get; set; }
[AllowHtml]
public string Description { get; set; }
[AllowHtml]
public string Bio { get; set; }
}</pre>

==References==
*[http://msdn.microsoft.com/en-us/library/hh882339(v=vs.110).aspx Request Validation in ASP.NET]
*[http://msdn.microsoft.com/en-us/library/System.Web.HttpUtility_methods(v=vs.110).aspx HttpUtility Methods]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.validateinputattribute(v=vs.118).aspx ValidateInputAttribute Class]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.allowhtmlattribute(v=vs.118).aspx AllowHtmlAttribute Class]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder(v=vs.110).aspx AntiXssEncoder Class]
*[http://www.microsoft.com/en-sg/download/details.aspx?id=43126 Microsoft Anti-Cross Site Scripting Library V4.3]
*[[ASP.NET Output Encoding]]

[[Category:OWASP .NET Project]]

ASP.NET Output Encoding

2014-10-30T19:22:54Z

Bricex: /* Encoding Output Values in Code */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
Cross-site scripting attacks exploit vulnerabilities in web page validation by injecting client-side script code. The script code embeds itself in response data, which is sent back to an unsuspecting user. In addition to validating input, any data retrieved from untrusted or shared sources should be encoded on output. For example: data retrieved from a database that may have had malicious input persisted to it.

==Validating Input==
See the [[ASP.NET Request Validation]] article for details on how request validation can be used to protect against malicious input.

==Encoding Output Values in Code==
Use <code>Server.HtmlEncode</code> to encode untrusted data for use in HTML output:
<pre>var encodedHtml = Server.HtmlEncode(untrustedData);</pre>

Use <code>Server.UrlEncode</code> to encode untrusted data for use in constructing URLs
<pre>var encodedUrl = Server.UrlEncode(untrustedData);</pre>

==Encoding Output Values in HTML markup==
You can HTML encode the value in markup with the <code><%: %></code> syntax, as shown below.
<pre><span><%: untrustedData%></span></pre>

Or, in Razor syntax, you can HTML encode with <code>@</code>, as shown below.
<pre><span>@untrustedData</span></pre>

==Preventing Double Encoding==
You may run into a scenario where encoding values results in them becoming double encoded on output. ASP.NET provides the <code>HtmlString</code> and <code>MvcHtmlString</code> classes starting with .NET 4.0 which are designed to help. These both implement the <code>IHtmlString</code> interface which will instruct ASP.NET to not apply encoding within HTML markup when using <code><%: untrustedData %></code> or <code>@untrustedData</code>. Converting a property on your view model from <code>String</code> to <code>MvcHtmlString</code> will instruct ASP.NET that HTML encoding has already been accounted for.

<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public MvcHtmlString Description { get; set; } // Output encoding is handled manually
}</pre>

==Enhanced Encoding==
By default the ASP.NET encoding methods use a black-listing technique that evaluates the string for a set of character combinations that may indicate presence of malicious script. A superior approach is to use a [[Input Validation Cheat Sheet#White_List_Input_Validation|white-listing technique]] for validation, which can be achieved using the Anti-Cross Site Scripting Library from Microsoft. Starting with ASP.NET 4.5 you can specify that the <code>AntiXssEncoder</code> from this library be used as the default encoder for you entire application using the <code>encoderType</code> setting in web.config as shown below.
<pre><httpRuntime encoderType="System.Web.Security.AntiXss.AntiXssEncoder" /></pre>

If you are using a version of .NET earlier than 4.5, you will need to download and include the library as a reference to your project, and then use the earlier library name for the encodeType setting as shown below.
<pre><httpRuntime encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" /></pre>

In addition to the common <code>HtmlEncode</code> and <code>UrlEncode</code> methods, the Anti-Cross Site Scripting Library provides the following <code>AntiXssEncoder</code> methods for more specialized output encoding needs:

{| class="wikitable"
|CssEncode
|Encodes the specified string for use in cascading style sheets (CSS).
|-
|HeaderNameValueEncode
|Encodes a header name and value into a string that can be used as an HTTP header.
|-
|HtmlAttributeEncode
|Encodes and outputs the specified string for use in an HTML attribute.
|-
|HtmlFormUrlEncode
|Encodes the specified string for use in form submissions whose MIME type is "application/x-www-form-urlencoded".
|-
|JavaScriptStringEncode
|Encodes a string for use in JavaScript.
|-
|UrlPathEncode
|Encodes path strings for use in a URL.
|-
|XmlAttributeEncode
|Encodes the specified string for use in XML attributes.
|-
|XmlEncode
|Encodes the specified string for use in XML.
|}

==References==
*[http://blogs.msdn.com/b/cisg/archive/2008/08/28/output-encoding.aspx Output Encoding]
*[http://weblogs.asp.net/scottgu/new-lt-gt-syntax-for-html-encoding-output-in-asp-net-4-and-asp-net-mvc-2 New <%: %> Syntax for HTML Encoding Output in ASP.NET 4 (and ASP.NET MVC 2)]
*[http://msdn.microsoft.com/en-us/library/system.web.ihtmlstring(v=vs.110).aspx IHtmlString Interface]
*[http://stackoverflow.com/questions/2293357/what-is-an-mvchtmlstring-and-when-should-i-use-it What is an MvcHtmlString and when should I use it?]
*[http://www.microsoft.com/en-sg/download/details.aspx?id=43126 Microsoft Anti-Cross Site Scripting Library V4.3]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder_methods(v=vs.110).aspx AntiXssEncoder Methods]

[[Category:OWASP .NET Project]][[Category:Stub]]

ASP.NET Output Encoding

2014-10-30T19:20:33Z

Bricex: /* Preventing Double Encoding */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
Cross-site scripting attacks exploit vulnerabilities in web page validation by injecting client-side script code. The script code embeds itself in response data, which is sent back to an unsuspecting user. In addition to validating input, any data retrieved from untrusted or shared sources should be encoded on output. For example: data retrieved from a database that may have had malicious input persisted to it.

==Validating Input==
See the [[ASP.NET Request Validation]] article for details on how request validation can be used to protect against malicious input.

==Encoding Output Values in Code==
Use <code>Server.HtmlEncode</code> to encode untrusted data for use in HTML output:
<pre>var encodedHtml = Server.HtmlEncode(untrustedData);</pre>

Use <code>Server.UrlEncode</code> to encode untrusted data for use in constructing URLs
<pre>var encodedUrl = Server.UrlEncode(untrustedData);</pre>

Use <code>Server.UrlTokenEncode</code> to encode untrusted data in byte array form for use as a URL parameter
<pre>var encodedUrlToken = Server.UrlTokenEncode(untrustedData);</pre>

==Encoding Output Values in HTML markup==
You can HTML encode the value in markup with the <code><%: %></code> syntax, as shown below.
<pre><span><%: untrustedData%></span></pre>

Or, in Razor syntax, you can HTML encode with <code>@</code>, as shown below.
<pre><span>@untrustedData</span></pre>

==Preventing Double Encoding==
You may run into a scenario where encoding values results in them becoming double encoded on output. ASP.NET provides the <code>HtmlString</code> and <code>MvcHtmlString</code> classes starting with .NET 4.0 which are designed to help. These both implement the <code>IHtmlString</code> interface which will instruct ASP.NET to not apply encoding within HTML markup when using <code><%: untrustedData %></code> or <code>@untrustedData</code>. Converting a property on your view model from <code>String</code> to <code>MvcHtmlString</code> will instruct ASP.NET that HTML encoding has already been accounted for.

<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public MvcHtmlString Description { get; set; } // Output encoding is handled manually
}</pre>

==Enhanced Encoding==
By default the ASP.NET encoding methods use a black-listing technique that evaluates the string for a set of character combinations that may indicate presence of malicious script. A superior approach is to use a [[Input Validation Cheat Sheet#White_List_Input_Validation|white-listing technique]] for validation, which can be achieved using the Anti-Cross Site Scripting Library from Microsoft. Starting with ASP.NET 4.5 you can specify that the <code>AntiXssEncoder</code> from this library be used as the default encoder for you entire application using the <code>encoderType</code> setting in web.config as shown below.
<pre><httpRuntime encoderType="System.Web.Security.AntiXss.AntiXssEncoder" /></pre>

If you are using a version of .NET earlier than 4.5, you will need to download and include the library as a reference to your project, and then use the earlier library name for the encodeType setting as shown below.
<pre><httpRuntime encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" /></pre>

In addition to the common <code>HtmlEncode</code> and <code>UrlEncode</code> methods, the Anti-Cross Site Scripting Library provides the following <code>AntiXssEncoder</code> methods for more specialized output encoding needs:

{| class="wikitable"
|CssEncode
|Encodes the specified string for use in cascading style sheets (CSS).
|-
|HeaderNameValueEncode
|Encodes a header name and value into a string that can be used as an HTTP header.
|-
|HtmlAttributeEncode
|Encodes and outputs the specified string for use in an HTML attribute.
|-
|HtmlFormUrlEncode
|Encodes the specified string for use in form submissions whose MIME type is "application/x-www-form-urlencoded".
|-
|JavaScriptStringEncode
|Encodes a string for use in JavaScript.
|-
|UrlPathEncode
|Encodes path strings for use in a URL.
|-
|XmlAttributeEncode
|Encodes the specified string for use in XML attributes.
|-
|XmlEncode
|Encodes the specified string for use in XML.
|}

==References==
*[http://blogs.msdn.com/b/cisg/archive/2008/08/28/output-encoding.aspx Output Encoding]
*[http://weblogs.asp.net/scottgu/new-lt-gt-syntax-for-html-encoding-output-in-asp-net-4-and-asp-net-mvc-2 New <%: %> Syntax for HTML Encoding Output in ASP.NET 4 (and ASP.NET MVC 2)]
*[http://msdn.microsoft.com/en-us/library/system.web.ihtmlstring(v=vs.110).aspx IHtmlString Interface]
*[http://stackoverflow.com/questions/2293357/what-is-an-mvchtmlstring-and-when-should-i-use-it What is an MvcHtmlString and when should I use it?]
*[http://www.microsoft.com/en-sg/download/details.aspx?id=43126 Microsoft Anti-Cross Site Scripting Library V4.3]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder_methods(v=vs.110).aspx AntiXssEncoder Methods]

[[Category:OWASP .NET Project]][[Category:Stub]]

ASP.NET Output Encoding

2014-10-30T19:20:10Z

Bricex: /* Preventing Double Encoding */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
Cross-site scripting attacks exploit vulnerabilities in web page validation by injecting client-side script code. The script code embeds itself in response data, which is sent back to an unsuspecting user. In addition to validating input, any data retrieved from untrusted or shared sources should be encoded on output. For example: data retrieved from a database that may have had malicious input persisted to it.

==Validating Input==
See the [[ASP.NET Request Validation]] article for details on how request validation can be used to protect against malicious input.

==Encoding Output Values in Code==
Use <code>Server.HtmlEncode</code> to encode untrusted data for use in HTML output:
<pre>var encodedHtml = Server.HtmlEncode(untrustedData);</pre>

Use <code>Server.UrlEncode</code> to encode untrusted data for use in constructing URLs
<pre>var encodedUrl = Server.UrlEncode(untrustedData);</pre>

Use <code>Server.UrlTokenEncode</code> to encode untrusted data in byte array form for use as a URL parameter
<pre>var encodedUrlToken = Server.UrlTokenEncode(untrustedData);</pre>

==Encoding Output Values in HTML markup==
You can HTML encode the value in markup with the <code><%: %></code> syntax, as shown below.
<pre><span><%: untrustedData%></span></pre>

Or, in Razor syntax, you can HTML encode with <code>@</code>, as shown below.
<pre><span>@untrustedData</span></pre>

==Preventing Double Encoding==
You may run into a scenario where encoding values results in them becoming double encoded on output. ASP.NET provides the <code>HtmlString</code> and <code>MvcHtmlString</code> classes starting with .NET 4.0 which are designed to help. These both implement the <code>IHtmlString</code> interface which will instruct ASP.NET to not apply encoding within HTML markup when using <code><%: untrustedData %></code> or <code>@untrustedData </code>. Converting a property on your view model from <code>String</code> to <code>MvcHtmlString</code> will instruct ASP.NET that HTML encoding has already been accounted for.

<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public MvcHtmlString Description { get; set; } // Output encoding is handled manually
}</pre>

==Enhanced Encoding==
By default the ASP.NET encoding methods use a black-listing technique that evaluates the string for a set of character combinations that may indicate presence of malicious script. A superior approach is to use a [[Input Validation Cheat Sheet#White_List_Input_Validation|white-listing technique]] for validation, which can be achieved using the Anti-Cross Site Scripting Library from Microsoft. Starting with ASP.NET 4.5 you can specify that the <code>AntiXssEncoder</code> from this library be used as the default encoder for you entire application using the <code>encoderType</code> setting in web.config as shown below.
<pre><httpRuntime encoderType="System.Web.Security.AntiXss.AntiXssEncoder" /></pre>

If you are using a version of .NET earlier than 4.5, you will need to download and include the library as a reference to your project, and then use the earlier library name for the encodeType setting as shown below.
<pre><httpRuntime encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" /></pre>

In addition to the common <code>HtmlEncode</code> and <code>UrlEncode</code> methods, the Anti-Cross Site Scripting Library provides the following <code>AntiXssEncoder</code> methods for more specialized output encoding needs:

{| class="wikitable"
|CssEncode
|Encodes the specified string for use in cascading style sheets (CSS).
|-
|HeaderNameValueEncode
|Encodes a header name and value into a string that can be used as an HTTP header.
|-
|HtmlAttributeEncode
|Encodes and outputs the specified string for use in an HTML attribute.
|-
|HtmlFormUrlEncode
|Encodes the specified string for use in form submissions whose MIME type is "application/x-www-form-urlencoded".
|-
|JavaScriptStringEncode
|Encodes a string for use in JavaScript.
|-
|UrlPathEncode
|Encodes path strings for use in a URL.
|-
|XmlAttributeEncode
|Encodes the specified string for use in XML attributes.
|-
|XmlEncode
|Encodes the specified string for use in XML.
|}

==References==
*[http://blogs.msdn.com/b/cisg/archive/2008/08/28/output-encoding.aspx Output Encoding]
*[http://weblogs.asp.net/scottgu/new-lt-gt-syntax-for-html-encoding-output-in-asp-net-4-and-asp-net-mvc-2 New <%: %> Syntax for HTML Encoding Output in ASP.NET 4 (and ASP.NET MVC 2)]
*[http://msdn.microsoft.com/en-us/library/system.web.ihtmlstring(v=vs.110).aspx IHtmlString Interface]
*[http://stackoverflow.com/questions/2293357/what-is-an-mvchtmlstring-and-when-should-i-use-it What is an MvcHtmlString and when should I use it?]
*[http://www.microsoft.com/en-sg/download/details.aspx?id=43126 Microsoft Anti-Cross Site Scripting Library V4.3]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder_methods(v=vs.110).aspx AntiXssEncoder Methods]

[[Category:OWASP .NET Project]][[Category:Stub]]

ASP.NET Output Encoding

2014-10-30T19:19:23Z

Bricex: Initial page content

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
Cross-site scripting attacks exploit vulnerabilities in web page validation by injecting client-side script code. The script code embeds itself in response data, which is sent back to an unsuspecting user. In addition to validating input, any data retrieved from untrusted or shared sources should be encoded on output. For example: data retrieved from a database that may have had malicious input persisted to it.

==Validating Input==
See the [[ASP.NET Request Validation]] article for details on how request validation can be used to protect against malicious input.

==Encoding Output Values in Code==
Use <code>Server.HtmlEncode</code> to encode untrusted data for use in HTML output:
<pre>var encodedHtml = Server.HtmlEncode(untrustedData);</pre>

Use <code>Server.UrlEncode</code> to encode untrusted data for use in constructing URLs
<pre>var encodedUrl = Server.UrlEncode(untrustedData);</pre>

Use <code>Server.UrlTokenEncode</code> to encode untrusted data in byte array form for use as a URL parameter
<pre>var encodedUrlToken = Server.UrlTokenEncode(untrustedData);</pre>

==Encoding Output Values in HTML markup==
You can HTML encode the value in markup with the <code><%: %></code> syntax, as shown below.
<pre><span><%: untrustedData%></span></pre>

Or, in Razor syntax, you can HTML encode with <code>@</code>, as shown below.
<pre><span>@untrustedData</span></pre>

==Preventing Double Encoding==
You may run into a scenario where encoding values results in them becoming double encoded on output. ASP.NET provides the <code>HtmlString</code> and <code>MvcHtmlString</code> classes starting with .NET 4.0 which are designed to help. These both implement the <code>IHtmlString</code> interface which will instruct ASP.NET to not apply encoding within HTML markup when using <code><%: userInput %></code> or <code>@userInput</code>. Converting a property on your view model from <code>String</code> to <code>MvcHtmlString</code> will instruct ASP.NET that HTML encoding has already been accounted for.

<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public MvcHtmlString Description { get; set; } // Output encoding is handled manually
}</pre>

==Enhanced Encoding==
By default the ASP.NET encoding methods use a black-listing technique that evaluates the string for a set of character combinations that may indicate presence of malicious script. A superior approach is to use a [[Input Validation Cheat Sheet#White_List_Input_Validation|white-listing technique]] for validation, which can be achieved using the Anti-Cross Site Scripting Library from Microsoft. Starting with ASP.NET 4.5 you can specify that the <code>AntiXssEncoder</code> from this library be used as the default encoder for you entire application using the <code>encoderType</code> setting in web.config as shown below.
<pre><httpRuntime encoderType="System.Web.Security.AntiXss.AntiXssEncoder" /></pre>

If you are using a version of .NET earlier than 4.5, you will need to download and include the library as a reference to your project, and then use the earlier library name for the encodeType setting as shown below.
<pre><httpRuntime encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" /></pre>

In addition to the common <code>HtmlEncode</code> and <code>UrlEncode</code> methods, the Anti-Cross Site Scripting Library provides the following <code>AntiXssEncoder</code> methods for more specialized output encoding needs:

{| class="wikitable"
|CssEncode
|Encodes the specified string for use in cascading style sheets (CSS).
|-
|HeaderNameValueEncode
|Encodes a header name and value into a string that can be used as an HTTP header.
|-
|HtmlAttributeEncode
|Encodes and outputs the specified string for use in an HTML attribute.
|-
|HtmlFormUrlEncode
|Encodes the specified string for use in form submissions whose MIME type is "application/x-www-form-urlencoded".
|-
|JavaScriptStringEncode
|Encodes a string for use in JavaScript.
|-
|UrlPathEncode
|Encodes path strings for use in a URL.
|-
|XmlAttributeEncode
|Encodes the specified string for use in XML attributes.
|-
|XmlEncode
|Encodes the specified string for use in XML.
|}

==References==
*[http://blogs.msdn.com/b/cisg/archive/2008/08/28/output-encoding.aspx Output Encoding]
*[http://weblogs.asp.net/scottgu/new-lt-gt-syntax-for-html-encoding-output-in-asp-net-4-and-asp-net-mvc-2 New <%: %> Syntax for HTML Encoding Output in ASP.NET 4 (and ASP.NET MVC 2)]
*[http://msdn.microsoft.com/en-us/library/system.web.ihtmlstring(v=vs.110).aspx IHtmlString Interface]
*[http://stackoverflow.com/questions/2293357/what-is-an-mvchtmlstring-and-when-should-i-use-it What is an MvcHtmlString and when should I use it?]
*[http://www.microsoft.com/en-sg/download/details.aspx?id=43126 Microsoft Anti-Cross Site Scripting Library V4.3]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder_methods(v=vs.110).aspx AntiXssEncoder Methods]

[[Category:OWASP .NET Project]][[Category:Stub]]

ASP.NET Request Validation

2014-10-30T19:04:51Z

Bricex: /* References */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
''Request validation'' is a feature in ASP.NET that examines HTTP requests and determines whether they contain potentially dangerous content. 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 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. Request validation is generally desirable and should be left enabled unless you have a specific need that would prevent it from being used.

==Enabling Request Validation==
Request validation is enabled by default in ASP.NET. You can check to make sure it is not disabled at the page level by searching for any instances of:

<pre><@ Page ValidateRequest="false" %></pre>

You should also inspect the web.config file to ensure that request validation has not been disabled for the entire application:

<pre><pages validateRequest="false" /></pre>

Starting with ASP.NET 4.0 request validation is performed for all requests, not just for .aspx page requests. To ensure this is configured correctly look to see that <code>requestValidationMode</code> has '''NOT''' been set to 2.0.

<pre><httpRuntime requestValidationMode="2.0" /></pre>

===ASP.NET Web API===
ASP.NET Web API does not utilize the request validation feature to sanitize user input. You will need to add this protection manually if any input will be used in HTML output. For example if user input is returned to the browser as the result from an AJAX request to a Web API method.

==Validating User Input==
Even though request validation provides a good level of input protection, you should not fully rely on it for securing your application against cross-site scripting attacks. Instead, validate all input from users to ensure malicious code is not included.

Use <code>Server.HtmlEncode</code> to encode user input for use in HTML output:
<pre>var encodedHtmlInput = Server.HtmlEncode(userInput);</pre>

Use <code>Server.UrlEncode</code> to encode user input for use in constructing URLs
<pre>var encodedUrlInput = Server.UrlEncode(userInput);</pre>

Use <code>Server.UrlTokenEncode</code> to encode user input in byte array form for use as a URL parameter
<pre>var encodedUrlTokenInput = Server.UrlTokenEncode(userInput);</pre>

===Enhanced Request Validation Encoding===
ASP.NET request validation uses a black-listing technique that evaluates the string for a set of character combinations that may indicate presence of malicious script. A superior approach is to use a [[Input Validation Cheat Sheet#White_List_Input_Validation|white-listing technique]] for input validation, which can be achieved using the Anti-Cross Site Scripting Library from Microsoft. Starting with ASP.NET 4.5 you can specify that the <code>AntiXssEncoder</code> from this library be used as the default encoder for you entire application using the <code>encoderType</code> setting in web.config as shown below.
<pre><httpRuntime encoderType="System.Web.Security.AntiXss.AntiXssEncoder" /></pre>

If you are using a version of .NET earlier than 4.5, you will need to download and include the library as a reference to your project, and then use the earlier library name for the encodeType setting as shown below.
<pre><httpRuntime encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" /></pre>

==Selectively Disabling Request Validation==
In some cases you may need to accept input that will fail ASP.NET Request Validation, such as when receiving HTML markup from the end user. In these scenarios you should disable request validation for the smallest surface possible, and replace it with your own custom input validation.

===ASP.NET Web Forms===
For ASP.NET Web Forms applications you will need to disable request validation at the page level. Be aware that when doing this all input values (cookies, query string, form elements) handled by this page will not be validated by ASP.NET.
<pre><@ Page ValidateRequest="false" %></pre>

===ASP.NET MVC===
To disable request validation for a specific MVC controller action, you can use the <code>[ValidateInput(false)]</code> attribute as shown below.
<pre>[ValidateInput(false)]
public ActionResult Update(int userId, string description)</pre>

Starting with ASP.NET MVC 3 you should use the <code>[AllowHtml]</code> attribute to decorate specific fields on your view model classes where request validation should not be applied:
<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public string Email { get; set; }
[AllowHtml]
public string Description { get; set; }
[AllowHtml]
public string Bio { get; set; }
}</pre>

==References==
*[http://msdn.microsoft.com/en-us/library/hh882339(v=vs.110).aspx Request Validation in ASP.NET]
*[http://msdn.microsoft.com/en-us/library/System.Web.HttpUtility_methods(v=vs.110).aspx HttpUtility Methods]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.validateinputattribute(v=vs.118).aspx ValidateInputAttribute Class]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.allowhtmlattribute(v=vs.118).aspx AllowHtmlAttribute Class]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder(v=vs.110).aspx AntiXssEncoder Class]
*[http://www.microsoft.com/en-sg/download/details.aspx?id=43126 Microsoft Anti-Cross Site Scripting Library V4.3]
*[[ASP.NET Output Encoding]]

[[Category:OWASP .NET Project]]

ASP.NET Request Validation

2014-10-30T18:47:53Z

Bricex: /* Validating User Input */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
''Request validation'' is a feature in ASP.NET that examines HTTP requests and determines whether they contain potentially dangerous content. 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 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. Request validation is generally desirable and should be left enabled unless you have a specific need that would prevent it from being used.

==Enabling Request Validation==
Request validation is enabled by default in ASP.NET. You can check to make sure it is not disabled at the page level by searching for any instances of:

<pre><@ Page ValidateRequest="false" %></pre>

You should also inspect the web.config file to ensure that request validation has not been disabled for the entire application:

<pre><pages validateRequest="false" /></pre>

Starting with ASP.NET 4.0 request validation is performed for all requests, not just for .aspx page requests. To ensure this is configured correctly look to see that <code>requestValidationMode</code> has '''NOT''' been set to 2.0.

<pre><httpRuntime requestValidationMode="2.0" /></pre>

===ASP.NET Web API===
ASP.NET Web API does not utilize the request validation feature to sanitize user input. You will need to add this protection manually if any input will be used in HTML output. For example if user input is returned to the browser as the result from an AJAX request to a Web API method.

==Validating User Input==
Even though request validation provides a good level of input protection, you should not fully rely on it for securing your application against cross-site scripting attacks. Instead, validate all input from users to ensure malicious code is not included.

Use <code>Server.HtmlEncode</code> to encode user input for use in HTML output:
<pre>var encodedHtmlInput = Server.HtmlEncode(userInput);</pre>

Use <code>Server.UrlEncode</code> to encode user input for use in constructing URLs
<pre>var encodedUrlInput = Server.UrlEncode(userInput);</pre>

Use <code>Server.UrlTokenEncode</code> to encode user input in byte array form for use as a URL parameter
<pre>var encodedUrlTokenInput = Server.UrlTokenEncode(userInput);</pre>

===Enhanced Request Validation Encoding===
ASP.NET request validation uses a black-listing technique that evaluates the string for a set of character combinations that may indicate presence of malicious script. A superior approach is to use a [[Input Validation Cheat Sheet#White_List_Input_Validation|white-listing technique]] for input validation, which can be achieved using the Anti-Cross Site Scripting Library from Microsoft. Starting with ASP.NET 4.5 you can specify that the <code>AntiXssEncoder</code> from this library be used as the default encoder for you entire application using the <code>encoderType</code> setting in web.config as shown below.
<pre><httpRuntime encoderType="System.Web.Security.AntiXss.AntiXssEncoder" /></pre>

If you are using a version of .NET earlier than 4.5, you will need to download and include the library as a reference to your project, and then use the earlier library name for the encodeType setting as shown below.
<pre><httpRuntime encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" /></pre>

==Selectively Disabling Request Validation==
In some cases you may need to accept input that will fail ASP.NET Request Validation, such as when receiving HTML markup from the end user. In these scenarios you should disable request validation for the smallest surface possible, and replace it with your own custom input validation.

===ASP.NET Web Forms===
For ASP.NET Web Forms applications you will need to disable request validation at the page level. Be aware that when doing this all input values (cookies, query string, form elements) handled by this page will not be validated by ASP.NET.
<pre><@ Page ValidateRequest="false" %></pre>

===ASP.NET MVC===
To disable request validation for a specific MVC controller action, you can use the <code>[ValidateInput(false)]</code> attribute as shown below.
<pre>[ValidateInput(false)]
public ActionResult Update(int userId, string description)</pre>

Starting with ASP.NET MVC 3 you should use the <code>[AllowHtml]</code> attribute to decorate specific fields on your view model classes where request validation should not be applied:
<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public string Email { get; set; }
[AllowHtml]
public string Description { get; set; }
[AllowHtml]
public string Bio { get; set; }
}</pre>

==References==
*[http://msdn.microsoft.com/en-us/library/hh882339(v=vs.110).aspx Request Validation in ASP.NET]
*[http://msdn.microsoft.com/en-us/library/System.Web.HttpUtility_methods(v=vs.110).aspx HttpUtility Methods]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder(v=vs.110).aspx AntiXssEncoder Class]
*[http://www.microsoft.com/en-sg/download/details.aspx?id=43126 Microsoft Anti-Cross Site Scripting Library V4.3]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.validateinputattribute(v=vs.118).aspx ValidateInputAttribute Class]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.allowhtmlattribute(v=vs.118).aspx AllowHtmlAttribute Class]
*[[ASP.NET Output Encoding]]

[[Category:OWASP .NET Project]]

ASP.NET Request Validation

2014-10-30T18:31:59Z

Bricex: /* References */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
''Request validation'' is a feature in ASP.NET that examines HTTP requests and determines whether they contain potentially dangerous content. 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 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. Request validation is generally desirable and should be left enabled unless you have a specific need that would prevent it from being used.

==Enabling Request Validation==
Request validation is enabled by default in ASP.NET. You can check to make sure it is not disabled at the page level by searching for any instances of:

<pre><@ Page ValidateRequest="false" %></pre>

You should also inspect the web.config file to ensure that request validation has not been disabled for the entire application:

<pre><pages validateRequest="false" /></pre>

Starting with ASP.NET 4.0 request validation is performed for all requests, not just for .aspx page requests. To ensure this is configured correctly look to see that <code>requestValidationMode</code> has '''NOT''' been set to 2.0.

<pre><httpRuntime requestValidationMode="2.0" /></pre>

===ASP.NET Web API===
ASP.NET Web API does not utilize the request validation feature to sanitize user input. You will need to add this protection manually if any input will be used in HTML output. For example if user input is returned to the browser as the result from an AJAX request to a Web API method.

==Validating User Input==
Even though request validation provides a good level of input protection, you should not fully rely on it for securing your application against cross-site scripting attacks. Instead, validate all input from users to ensure malicious code is not included.

===Encoding Input Values in Code-Behind===
Use <code>Server.HtmlEncode</code> to encode user input for use in HTML output:
<pre>var encodedHtmlInput = Server.HtmlEncode(userInput);</pre>

Use <code>Server.UrlEncode</code> to encode user input for use in constructing URLs
<pre>var encodedUrlInput = Server.UrlEncode(userInput);</pre>

Use <code>Server.UrlTokenEncode</code> to encode user input in byte array form for use as a URL parameter
<pre>var encodedUrlTokenInput = Server.UrlTokenEncode(userInput);</pre>

===Enhanced Request Validation Encoding===
ASP.NET request validation uses a black-listing technique that evaluates the string for a set of character combinations that may indicate presence of malicious script. A superior approach is to use a [[Input Validation Cheat Sheet#White_List_Input_Validation|white-listing technique]] for input validation, which can be achieved using the Anti-Cross Site Scripting Library from Microsoft. Starting with ASP.NET 4.5 you can specify that the <code>AntiXssEncoder</code> from this library be used as the default encoder for you entire application using the <code>encoderType</code> setting in web.config as shown below.
<pre><httpRuntime encoderType="System.Web.Security.AntiXss.AntiXssEncoder" /></pre>

If you are using a version of .NET earlier than 4.5, you will need to download and include the library as a reference to your project, and then use the earlier library name for the encodeType setting as shown below.
<pre><httpRuntime encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" /></pre>

==Selectively Disabling Request Validation==
In some cases you may need to accept input that will fail ASP.NET Request Validation, such as when receiving HTML markup from the end user. In these scenarios you should disable request validation for the smallest surface possible, and replace it with your own custom input validation.

===ASP.NET Web Forms===
For ASP.NET Web Forms applications you will need to disable request validation at the page level. Be aware that when doing this all input values (cookies, query string, form elements) handled by this page will not be validated by ASP.NET.
<pre><@ Page ValidateRequest="false" %></pre>

===ASP.NET MVC===
To disable request validation for a specific MVC controller action, you can use the <code>[ValidateInput(false)]</code> attribute as shown below.
<pre>[ValidateInput(false)]
public ActionResult Update(int userId, string description)</pre>

Starting with ASP.NET MVC 3 you should use the <code>[AllowHtml]</code> attribute to decorate specific fields on your view model classes where request validation should not be applied:
<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public string Email { get; set; }
[AllowHtml]
public string Description { get; set; }
[AllowHtml]
public string Bio { get; set; }
}</pre>

==References==
*[http://msdn.microsoft.com/en-us/library/hh882339(v=vs.110).aspx Request Validation in ASP.NET]
*[http://msdn.microsoft.com/en-us/library/System.Web.HttpUtility_methods(v=vs.110).aspx HttpUtility Methods]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder(v=vs.110).aspx AntiXssEncoder Class]
*[http://www.microsoft.com/en-sg/download/details.aspx?id=43126 Microsoft Anti-Cross Site Scripting Library V4.3]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.validateinputattribute(v=vs.118).aspx ValidateInputAttribute Class]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.allowhtmlattribute(v=vs.118).aspx AllowHtmlAttribute Class]
*[[ASP.NET Output Encoding]]

[[Category:OWASP .NET Project]]

ASP.NET Request Validation

2014-10-30T18:29:41Z

Bricex: /* References */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
''Request validation'' is a feature in ASP.NET that examines HTTP requests and determines whether they contain potentially dangerous content. 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 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. Request validation is generally desirable and should be left enabled unless you have a specific need that would prevent it from being used.

==Enabling Request Validation==
Request validation is enabled by default in ASP.NET. You can check to make sure it is not disabled at the page level by searching for any instances of:

<pre><@ Page ValidateRequest="false" %></pre>

You should also inspect the web.config file to ensure that request validation has not been disabled for the entire application:

<pre><pages validateRequest="false" /></pre>

Starting with ASP.NET 4.0 request validation is performed for all requests, not just for .aspx page requests. To ensure this is configured correctly look to see that <code>requestValidationMode</code> has '''NOT''' been set to 2.0.

<pre><httpRuntime requestValidationMode="2.0" /></pre>

===ASP.NET Web API===
ASP.NET Web API does not utilize the request validation feature to sanitize user input. You will need to add this protection manually if any input will be used in HTML output. For example if user input is returned to the browser as the result from an AJAX request to a Web API method.

==Validating User Input==
Even though request validation provides a good level of input protection, you should not fully rely on it for securing your application against cross-site scripting attacks. Instead, validate all input from users to ensure malicious code is not included.

===Encoding Input Values in Code-Behind===
Use <code>Server.HtmlEncode</code> to encode user input for use in HTML output:
<pre>var encodedHtmlInput = Server.HtmlEncode(userInput);</pre>

Use <code>Server.UrlEncode</code> to encode user input for use in constructing URLs
<pre>var encodedUrlInput = Server.UrlEncode(userInput);</pre>

Use <code>Server.UrlTokenEncode</code> to encode user input in byte array form for use as a URL parameter
<pre>var encodedUrlTokenInput = Server.UrlTokenEncode(userInput);</pre>

===Enhanced Request Validation Encoding===
ASP.NET request validation uses a black-listing technique that evaluates the string for a set of character combinations that may indicate presence of malicious script. A superior approach is to use a [[Input Validation Cheat Sheet#White_List_Input_Validation|white-listing technique]] for input validation, which can be achieved using the Anti-Cross Site Scripting Library from Microsoft. Starting with ASP.NET 4.5 you can specify that the <code>AntiXssEncoder</code> from this library be used as the default encoder for you entire application using the <code>encoderType</code> setting in web.config as shown below.
<pre><httpRuntime encoderType="System.Web.Security.AntiXss.AntiXssEncoder" /></pre>

If you are using a version of .NET earlier than 4.5, you will need to download and include the library as a reference to your project, and then use the earlier library name for the encodeType setting as shown below.
<pre><httpRuntime encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" /></pre>

==Selectively Disabling Request Validation==
In some cases you may need to accept input that will fail ASP.NET Request Validation, such as when receiving HTML markup from the end user. In these scenarios you should disable request validation for the smallest surface possible, and replace it with your own custom input validation.

===ASP.NET Web Forms===
For ASP.NET Web Forms applications you will need to disable request validation at the page level. Be aware that when doing this all input values (cookies, query string, form elements) handled by this page will not be validated by ASP.NET.
<pre><@ Page ValidateRequest="false" %></pre>

===ASP.NET MVC===
To disable request validation for a specific MVC controller action, you can use the <code>[ValidateInput(false)]</code> attribute as shown below.
<pre>[ValidateInput(false)]
public ActionResult Update(int userId, string description)</pre>

Starting with ASP.NET MVC 3 you should use the <code>[AllowHtml]</code> attribute to decorate specific fields on your view model classes where request validation should not be applied:
<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public string Email { get; set; }
[AllowHtml]
public string Description { get; set; }
[AllowHtml]
public string Bio { get; set; }
}</pre>

==References==
*[http://msdn.microsoft.com/en-us/library/hh882339(v=vs.110).aspx Request Validation in ASP.NET]
*[http://msdn.microsoft.com/en-us/library/System.Web.HttpUtility_methods(v=vs.110).aspx HttpUtility Methods]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder(v=vs.110).aspx AntiXssEncoder Class]
*[http://www.microsoft.com/en-sg/download/details.aspx?id=43126 Microsoft Anti-Cross Site Scripting Library V4.3]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.validateinputattribute(v=vs.118).aspx ValidateInputAttribute Class]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.allowhtmlattribute(v=vs.118).aspx AllowHtmlAttribute Class]

[[Category:OWASP .NET Project]]

ASP.NET Request Validation

2014-10-30T18:27:51Z

Bricex: /* Selectively Disabling Request Validation */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
''Request validation'' is a feature in ASP.NET that examines HTTP requests and determines whether they contain potentially dangerous content. 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 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. Request validation is generally desirable and should be left enabled unless you have a specific need that would prevent it from being used.

==Enabling Request Validation==
Request validation is enabled by default in ASP.NET. You can check to make sure it is not disabled at the page level by searching for any instances of:

<pre><@ Page ValidateRequest="false" %></pre>

You should also inspect the web.config file to ensure that request validation has not been disabled for the entire application:

<pre><pages validateRequest="false" /></pre>

Starting with ASP.NET 4.0 request validation is performed for all requests, not just for .aspx page requests. To ensure this is configured correctly look to see that <code>requestValidationMode</code> has '''NOT''' been set to 2.0.

<pre><httpRuntime requestValidationMode="2.0" /></pre>

===ASP.NET Web API===
ASP.NET Web API does not utilize the request validation feature to sanitize user input. You will need to add this protection manually if any input will be used in HTML output. For example if user input is returned to the browser as the result from an AJAX request to a Web API method.

==Validating User Input==
Even though request validation provides a good level of input protection, you should not fully rely on it for securing your application against cross-site scripting attacks. Instead, validate all input from users to ensure malicious code is not included.

===Encoding Input Values in Code-Behind===
Use <code>Server.HtmlEncode</code> to encode user input for use in HTML output:
<pre>var encodedHtmlInput = Server.HtmlEncode(userInput);</pre>

Use <code>Server.UrlEncode</code> to encode user input for use in constructing URLs
<pre>var encodedUrlInput = Server.UrlEncode(userInput);</pre>

Use <code>Server.UrlTokenEncode</code> to encode user input in byte array form for use as a URL parameter
<pre>var encodedUrlTokenInput = Server.UrlTokenEncode(userInput);</pre>

===Enhanced Request Validation Encoding===
ASP.NET request validation uses a black-listing technique that evaluates the string for a set of character combinations that may indicate presence of malicious script. A superior approach is to use a [[Input Validation Cheat Sheet#White_List_Input_Validation|white-listing technique]] for input validation, which can be achieved using the Anti-Cross Site Scripting Library from Microsoft. Starting with ASP.NET 4.5 you can specify that the <code>AntiXssEncoder</code> from this library be used as the default encoder for you entire application using the <code>encoderType</code> setting in web.config as shown below.
<pre><httpRuntime encoderType="System.Web.Security.AntiXss.AntiXssEncoder" /></pre>

If you are using a version of .NET earlier than 4.5, you will need to download and include the library as a reference to your project, and then use the earlier library name for the encodeType setting as shown below.
<pre><httpRuntime encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" /></pre>

==Selectively Disabling Request Validation==
In some cases you may need to accept input that will fail ASP.NET Request Validation, such as when receiving HTML markup from the end user. In these scenarios you should disable request validation for the smallest surface possible, and replace it with your own custom input validation.

===ASP.NET Web Forms===
For ASP.NET Web Forms applications you will need to disable request validation at the page level. Be aware that when doing this all input values (cookies, query string, form elements) handled by this page will not be validated by ASP.NET.
<pre><@ Page ValidateRequest="false" %></pre>

===ASP.NET MVC===
To disable request validation for a specific MVC controller action, you can use the <code>[ValidateInput(false)]</code> attribute as shown below.
<pre>[ValidateInput(false)]
public ActionResult Update(int userId, string description)</pre>

Starting with ASP.NET MVC 3 you should use the <code>[AllowHtml]</code> attribute to decorate specific fields on your view model classes where request validation should not be applied:
<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public string Email { get; set; }
[AllowHtml]
public string Description { get; set; }
[AllowHtml]
public string Bio { get; set; }
}</pre>

==References==
*[http://msdn.microsoft.com/en-us/library/hh882339(v=vs.110).aspx Request Validation in ASP.NET]
*[http://msdn.microsoft.com/en-us/library/System.Web.HttpUtility_methods(v=vs.110).aspx HttpUtility Methods]
*[http://weblogs.asp.net/scottgu/new-lt-gt-syntax-for-html-encoding-output-in-asp-net-4-and-asp-net-mvc-2 New <%: %> Syntax for HTML Encoding Output in ASP.NET 4 (and ASP.NET MVC 2)]
*[http://msdn.microsoft.com/en-us/library/system.web.ihtmlstring(v=vs.110).aspx IHtmlString Interface]
*[http://stackoverflow.com/questions/2293357/what-is-an-mvchtmlstring-and-when-should-i-use-it What is an MvcHtmlString and when should I use it?]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder(v=vs.110).aspx AntiXssEncoder Class]
*[http://www.microsoft.com/en-sg/download/details.aspx?id=43126 Microsoft Anti-Cross Site Scripting Library V4.3]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.validateinputattribute(v=vs.118).aspx ValidateInputAttribute Class]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.allowhtmlattribute(v=vs.118).aspx AllowHtmlAttribute Class]

[[Category:OWASP .NET Project]]

ASP.NET Request Validation

2014-10-30T18:26:36Z

Bricex: /* Validating User Input */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
''Request validation'' is a feature in ASP.NET that examines HTTP requests and determines whether they contain potentially dangerous content. 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 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. Request validation is generally desirable and should be left enabled unless you have a specific need that would prevent it from being used.

==Enabling Request Validation==
Request validation is enabled by default in ASP.NET. You can check to make sure it is not disabled at the page level by searching for any instances of:

<pre><@ Page ValidateRequest="false" %></pre>

You should also inspect the web.config file to ensure that request validation has not been disabled for the entire application:

<pre><pages validateRequest="false" /></pre>

Starting with ASP.NET 4.0 request validation is performed for all requests, not just for .aspx page requests. To ensure this is configured correctly look to see that <code>requestValidationMode</code> has '''NOT''' been set to 2.0.

<pre><httpRuntime requestValidationMode="2.0" /></pre>

===ASP.NET Web API===
ASP.NET Web API does not utilize the request validation feature to sanitize user input. You will need to add this protection manually if any input will be used in HTML output. For example if user input is returned to the browser as the result from an AJAX request to a Web API method.

==Validating User Input==
Even though request validation provides a good level of input protection, you should not fully rely on it for securing your application against cross-site scripting attacks. Instead, validate all input from users to ensure malicious code is not included.

===Encoding Input Values in Code-Behind===
Use <code>Server.HtmlEncode</code> to encode user input for use in HTML output:
<pre>var encodedHtmlInput = Server.HtmlEncode(userInput);</pre>

Use <code>Server.UrlEncode</code> to encode user input for use in constructing URLs
<pre>var encodedUrlInput = Server.UrlEncode(userInput);</pre>

Use <code>Server.UrlTokenEncode</code> to encode user input in byte array form for use as a URL parameter
<pre>var encodedUrlTokenInput = Server.UrlTokenEncode(userInput);</pre>

===Enhanced Request Validation Encoding===
ASP.NET request validation uses a black-listing technique that evaluates the string for a set of character combinations that may indicate presence of malicious script. A superior approach is to use a [[Input Validation Cheat Sheet#White_List_Input_Validation|white-listing technique]] for input validation, which can be achieved using the Anti-Cross Site Scripting Library from Microsoft. Starting with ASP.NET 4.5 you can specify that the <code>AntiXssEncoder</code> from this library be used as the default encoder for you entire application using the <code>encoderType</code> setting in web.config as shown below.
<pre><httpRuntime encoderType="System.Web.Security.AntiXss.AntiXssEncoder" /></pre>

If you are using a version of .NET earlier than 4.5, you will need to download and include the library as a reference to your project, and then use the earlier library name for the encodeType setting as shown below.
<pre><httpRuntime encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" /></pre>

==Selectively Disabling Request Validation==
In some cases you may need to accept input that will fail request validation, such as when receiving HTML markup from the end user. In these scenarios you should disable request validation for the smallest surface possible, and replace it with your own custom input validation.

===ASP.NET Web Forms===
For ASP.NET Web Forms applications you will need to disable request validation at the page level. Be aware that when doing this all input values (cookies, query string, form elements) handled by this page will not be validated by ASP.NET.
<pre><@ Page ValidateRequest="false" %></pre>

===ASP.NET MVC===
To disable request validation for a specific MVC controller action, you can use the <code>[ValidateInput(false)]</code> attribute as shown below.
<pre>[ValidateInput(false)]
public ActionResult Update(int userId, string description)</pre>

Starting with ASP.NET MVC 3 you should use the <code>[AllowHtml]</code> attribute to decorate specific fields on your view model classes where request validation should not be applied:
<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public string Email { get; set; }
[AllowHtml]
public string Description { get; set; }
[AllowHtml]
public string Bio { get; set; }
}</pre>

==References==
*[http://msdn.microsoft.com/en-us/library/hh882339(v=vs.110).aspx Request Validation in ASP.NET]
*[http://msdn.microsoft.com/en-us/library/System.Web.HttpUtility_methods(v=vs.110).aspx HttpUtility Methods]
*[http://weblogs.asp.net/scottgu/new-lt-gt-syntax-for-html-encoding-output-in-asp-net-4-and-asp-net-mvc-2 New <%: %> Syntax for HTML Encoding Output in ASP.NET 4 (and ASP.NET MVC 2)]
*[http://msdn.microsoft.com/en-us/library/system.web.ihtmlstring(v=vs.110).aspx IHtmlString Interface]
*[http://stackoverflow.com/questions/2293357/what-is-an-mvchtmlstring-and-when-should-i-use-it What is an MvcHtmlString and when should I use it?]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder(v=vs.110).aspx AntiXssEncoder Class]
*[http://www.microsoft.com/en-sg/download/details.aspx?id=43126 Microsoft Anti-Cross Site Scripting Library V4.3]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.validateinputattribute(v=vs.118).aspx ValidateInputAttribute Class]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.allowhtmlattribute(v=vs.118).aspx AllowHtmlAttribute Class]

[[Category:OWASP .NET Project]]

ASP.NET Request Validation

2014-10-30T18:25:15Z

Bricex: /* Validating User Input */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
''Request validation'' is a feature in ASP.NET that examines HTTP requests and determines whether they contain potentially dangerous content. 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 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. Request validation is generally desirable and should be left enabled unless you have a specific need that would prevent it from being used.

==Enabling Request Validation==
Request validation is enabled by default in ASP.NET. You can check to make sure it is not disabled at the page level by searching for any instances of:

<pre><@ Page ValidateRequest="false" %></pre>

You should also inspect the web.config file to ensure that request validation has not been disabled for the entire application:

<pre><pages validateRequest="false" /></pre>

Starting with ASP.NET 4.0 request validation is performed for all requests, not just for .aspx page requests. To ensure this is configured correctly look to see that <code>requestValidationMode</code> has '''NOT''' been set to 2.0.

<pre><httpRuntime requestValidationMode="2.0" /></pre>

===ASP.NET Web API===
ASP.NET Web API does not utilize the request validation feature to sanitize user input. You will need to add this protection manually if any input will be used in HTML output. For example if user input is returned to the browser as the result from an AJAX request to a Web API method.

==Validating User Input==
Even though request validation provides a good level of input protection, you should not fully rely on it for securing your application against cross-site scripting attacks. Instead, validate all input from users and encode the output to ensure malicious code is not included.

===Encoding Input Values in Code-Behind===
Use <code>Server.HtmlEncode</code> to encode user input for use in HTML output:
<pre>var encodedHtmlInput = Server.HtmlEncode(userInput);</pre>

Use <code>Server.UrlEncode</code> to encode user input for use in constructing URLs
<pre>var encodedUrlInput = Server.UrlEncode(userInput);</pre>

Use <code>Server.UrlTokenEncode</code> to encode user input in byte array form for use as a URL parameter
<pre>var encodedUrlTokenInput = Server.UrlTokenEncode(userInput);</pre>

===Enhanced Request Validation Encoding===
ASP.NET request validation uses a black-listing technique that evaluates the string for a set of character combinations that may indicate presence of malicious script. A superior approach is to use a [[Input Validation Cheat Sheet#White_List_Input_Validation|white-listing technique]] for input validation, which can be achieved using the Anti-Cross Site Scripting Library from Microsoft. Starting with ASP.NET 4.5 you can specify that the <code>AntiXssEncoder</code> from this library be used as the default encoder for you entire application using the <code>encoderType</code> setting in web.config as shown below.
<pre><httpRuntime encoderType="System.Web.Security.AntiXss.AntiXssEncoder" /></pre>

If you are using a version of .NET earlier than 4.5, you will need to download and include the library as a reference to your project, and then use the earlier library name for the encodeType setting as shown below.
<pre><httpRuntime encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" /></pre>

==Selectively Disabling Request Validation==
In some cases you may need to accept input that will fail request validation, such as when receiving HTML markup from the end user. In these scenarios you should disable request validation for the smallest surface possible, and replace it with your own custom input validation.

===ASP.NET Web Forms===
For ASP.NET Web Forms applications you will need to disable request validation at the page level. Be aware that when doing this all input values (cookies, query string, form elements) handled by this page will not be validated by ASP.NET.
<pre><@ Page ValidateRequest="false" %></pre>

===ASP.NET MVC===
To disable request validation for a specific MVC controller action, you can use the <code>[ValidateInput(false)]</code> attribute as shown below.
<pre>[ValidateInput(false)]
public ActionResult Update(int userId, string description)</pre>

Starting with ASP.NET MVC 3 you should use the <code>[AllowHtml]</code> attribute to decorate specific fields on your view model classes where request validation should not be applied:
<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public string Email { get; set; }
[AllowHtml]
public string Description { get; set; }
[AllowHtml]
public string Bio { get; set; }
}</pre>

==References==
*[http://msdn.microsoft.com/en-us/library/hh882339(v=vs.110).aspx Request Validation in ASP.NET]
*[http://msdn.microsoft.com/en-us/library/System.Web.HttpUtility_methods(v=vs.110).aspx HttpUtility Methods]
*[http://weblogs.asp.net/scottgu/new-lt-gt-syntax-for-html-encoding-output-in-asp-net-4-and-asp-net-mvc-2 New <%: %> Syntax for HTML Encoding Output in ASP.NET 4 (and ASP.NET MVC 2)]
*[http://msdn.microsoft.com/en-us/library/system.web.ihtmlstring(v=vs.110).aspx IHtmlString Interface]
*[http://stackoverflow.com/questions/2293357/what-is-an-mvchtmlstring-and-when-should-i-use-it What is an MvcHtmlString and when should I use it?]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder(v=vs.110).aspx AntiXssEncoder Class]
*[http://www.microsoft.com/en-sg/download/details.aspx?id=43126 Microsoft Anti-Cross Site Scripting Library V4.3]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.validateinputattribute(v=vs.118).aspx ValidateInputAttribute Class]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.allowhtmlattribute(v=vs.118).aspx AllowHtmlAttribute Class]

[[Category:OWASP .NET Project]]

ASP.NET Request Validation

2014-10-12T21:46:39Z

Bricex: /* Preventing Double Encoding */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
''Request validation'' is a feature in ASP.NET that examines HTTP requests and determines whether they contain potentially dangerous content. 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 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. Request validation is generally desirable and should be left enabled unless you have a specific need that would prevent it from being used.

==Enabling Request Validation==
Request validation is enabled by default in ASP.NET. You can check to make sure it is not disabled at the page level by searching for any instances of:

<pre><@ Page ValidateRequest="false" %></pre>

You should also inspect the web.config file to ensure that request validation has not been disabled for the entire application:

<pre><pages validateRequest="false" /></pre>

Starting with ASP.NET 4.0 request validation is performed for all requests, not just for .aspx page requests. To ensure this is configured correctly look to see that <code>requestValidationMode</code> has '''NOT''' been set to 2.0.

<pre><httpRuntime requestValidationMode="2.0" /></pre>

===ASP.NET Web API===
ASP.NET Web API does not utilize the request validation feature to sanitize user input. You will need to add this protection manually if any input will be used in HTML output. For example if user input is returned to the browser as the result from an AJAX request to a Web API method.

==Validating User Input==
Even though request validation provides a good level of input protection, do not fully rely on it for securing your application against cross-site scripting attacks. Instead, validate all input from users and encode the output to ensure malicious code is not included.

===Encoding Input Values in Code-Behind===
Use <code>Server.HtmlEncode</code> to encode user input for use in HTML output:
<pre>var encodedHtmlInput = Server.HtmlEncode(userInput);</pre>

Use <code>Server.UrlEncode</code> to encode user input for use in constructing URLs
<pre>var encodedUrlInput = Server.UrlEncode(userInput);</pre>

Use <code>Server.UrlTokenEncode</code> to encode user input in byte array form for use as a URL parameter
<pre>var encodedUrlTokenInput = Server.UrlTokenEncode(userInput);</pre>

===Encoding Output Values in HTML markup===
You can HTML encode the value in markup with the <code><%: %></code> syntax, as shown below.
<pre><span><%: userInput %></span></pre>

Or, in Razor syntax, you can HTML encode with <code>@</code>, as shown below.
<pre><span>@userInput</span></pre>

===Preventing Double Encoding===
You may run into a scenario where encoding values results in them becoming double encoded on output. ASP.NET provides the <code>HtmlString</code> and <code>MvcHtmlString</code> classes starting with .NET 4.0 which are designed to help. These both implement the <code>IHtmlString</code> interface which will instruct ASP.NET to not apply encoding within HTML markup when using <code><%: userInput %></code> or <code>@userInput</code>. Converting a property on your view model from <code>String</code> to <code>MvcHtmlString</code> will instruct ASP.NET that HTML encoding has already been accounted for.

<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public MvcHtmlString Description { get; set; } // Output encoding is handled manually
}</pre>

===Enhanced Request Validation Encoding===
ASP.NET request validation uses a black-listing technique that evaluates the string for a set of character combinations that may indicate presence of malicious script. A superior approach is to use a [[Input Validation Cheat Sheet#White_List_Input_Validation|white-listing technique]] for input validation, which can be achieved using the Anti-Cross Site Scripting Library from Microsoft. Starting with ASP.NET 4.5 you can specify that the <code>AntiXssEncoder</code> from this library be used as the default encoder for you entire application using the <code>encoderType</code> setting in web.config as shown below.
<pre><httpRuntime encoderType="System.Web.Security.AntiXss.AntiXssEncoder" /></pre>

If you are using a version of .NET earlier than 4.5, you will need to download and include the library as a reference to your project, and then use the earlier library name for the encodeType setting as shown below.
<pre><httpRuntime encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" /></pre>

==Selectively Disabling Request Validation==
In some cases you may need to accept input that will fail request validation, such as when receiving HTML markup from the end user. In these scenarios you should disable request validation for the smallest surface possible, and replace it with your own custom input validation.

===ASP.NET Web Forms===
For ASP.NET Web Forms applications you will need to disable request validation at the page level. Be aware that when doing this all input values (cookies, query string, form elements) handled by this page will not be validated by ASP.NET.
<pre><@ Page ValidateRequest="false" %></pre>

===ASP.NET MVC===
To disable request validation for a specific MVC controller action, you can use the <code>[ValidateInput(false)]</code> attribute as shown below.
<pre>[ValidateInput(false)]
public ActionResult Update(int userId, string description)</pre>

Starting with ASP.NET MVC 3 you should use the <code>[AllowHtml]</code> attribute to decorate specific fields on your view model classes where request validation should not be applied:
<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public string Email { get; set; }
[AllowHtml]
public string Description { get; set; }
[AllowHtml]
public string Bio { get; set; }
}</pre>

==References==
*[http://msdn.microsoft.com/en-us/library/hh882339(v=vs.110).aspx Request Validation in ASP.NET]
*[http://msdn.microsoft.com/en-us/library/System.Web.HttpUtility_methods(v=vs.110).aspx HttpUtility Methods]
*[http://weblogs.asp.net/scottgu/new-lt-gt-syntax-for-html-encoding-output-in-asp-net-4-and-asp-net-mvc-2 New <%: %> Syntax for HTML Encoding Output in ASP.NET 4 (and ASP.NET MVC 2)]
*[http://msdn.microsoft.com/en-us/library/system.web.ihtmlstring(v=vs.110).aspx IHtmlString Interface]
*[http://stackoverflow.com/questions/2293357/what-is-an-mvchtmlstring-and-when-should-i-use-it What is an MvcHtmlString and when should I use it?]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder(v=vs.110).aspx AntiXssEncoder Class]
*[http://www.microsoft.com/en-sg/download/details.aspx?id=43126 Microsoft Anti-Cross Site Scripting Library V4.3]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.validateinputattribute(v=vs.118).aspx ValidateInputAttribute Class]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.allowhtmlattribute(v=vs.118).aspx AllowHtmlAttribute Class]

[[Category:OWASP .NET Project]]

ASP.NET Request Validation

2014-10-12T21:45:30Z

Bricex: /* ASP.NET MVC */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
''Request validation'' is a feature in ASP.NET that examines HTTP requests and determines whether they contain potentially dangerous content. 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 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. Request validation is generally desirable and should be left enabled unless you have a specific need that would prevent it from being used.

==Enabling Request Validation==
Request validation is enabled by default in ASP.NET. You can check to make sure it is not disabled at the page level by searching for any instances of:

<pre><@ Page ValidateRequest="false" %></pre>

You should also inspect the web.config file to ensure that request validation has not been disabled for the entire application:

<pre><pages validateRequest="false" /></pre>

Starting with ASP.NET 4.0 request validation is performed for all requests, not just for .aspx page requests. To ensure this is configured correctly look to see that <code>requestValidationMode</code> has '''NOT''' been set to 2.0.

<pre><httpRuntime requestValidationMode="2.0" /></pre>

===ASP.NET Web API===
ASP.NET Web API does not utilize the request validation feature to sanitize user input. You will need to add this protection manually if any input will be used in HTML output. For example if user input is returned to the browser as the result from an AJAX request to a Web API method.

==Validating User Input==
Even though request validation provides a good level of input protection, do not fully rely on it for securing your application against cross-site scripting attacks. Instead, validate all input from users and encode the output to ensure malicious code is not included.

===Encoding Input Values in Code-Behind===
Use <code>Server.HtmlEncode</code> to encode user input for use in HTML output:
<pre>var encodedHtmlInput = Server.HtmlEncode(userInput);</pre>

Use <code>Server.UrlEncode</code> to encode user input for use in constructing URLs
<pre>var encodedUrlInput = Server.UrlEncode(userInput);</pre>

Use <code>Server.UrlTokenEncode</code> to encode user input in byte array form for use as a URL parameter
<pre>var encodedUrlTokenInput = Server.UrlTokenEncode(userInput);</pre>

===Encoding Output Values in HTML markup===
You can HTML encode the value in markup with the <code><%: %></code> syntax, as shown below.
<pre><span><%: userInput %></span></pre>

Or, in Razor syntax, you can HTML encode with <code>@</code>, as shown below.
<pre><span>@userInput</span></pre>

===Preventing Double Encoding===
You may run into a scenario where encoding values results in them becoming double encoded on output. ASP.NET provides the <code>HtmlString</code> and <code>MvcHtmlString</code> classes starting with .NET 4.0 which are designed to help. These both implement the <code>IHtmlString</code> interface which will instruct ASP.NET to not apply encoding within HTML markup when using <code><%: userInput %></code> or <code>@userInput</code>. Converting a property on your view model from <code>String</code> to <code>MvcHtmlString</code> will instruct ASP.NET that HTML encoding has already been accounted for.

===Enhanced Request Validation Encoding===
ASP.NET request validation uses a black-listing technique that evaluates the string for a set of character combinations that may indicate presence of malicious script. A superior approach is to use a [[Input Validation Cheat Sheet#White_List_Input_Validation|white-listing technique]] for input validation, which can be achieved using the Anti-Cross Site Scripting Library from Microsoft. Starting with ASP.NET 4.5 you can specify that the <code>AntiXssEncoder</code> from this library be used as the default encoder for you entire application using the <code>encoderType</code> setting in web.config as shown below.
<pre><httpRuntime encoderType="System.Web.Security.AntiXss.AntiXssEncoder" /></pre>

If you are using a version of .NET earlier than 4.5, you will need to download and include the library as a reference to your project, and then use the earlier library name for the encodeType setting as shown below.
<pre><httpRuntime encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" /></pre>

==Selectively Disabling Request Validation==
In some cases you may need to accept input that will fail request validation, such as when receiving HTML markup from the end user. In these scenarios you should disable request validation for the smallest surface possible, and replace it with your own custom input validation.

===ASP.NET Web Forms===
For ASP.NET Web Forms applications you will need to disable request validation at the page level. Be aware that when doing this all input values (cookies, query string, form elements) handled by this page will not be validated by ASP.NET.
<pre><@ Page ValidateRequest="false" %></pre>

===ASP.NET MVC===
To disable request validation for a specific MVC controller action, you can use the <code>[ValidateInput(false)]</code> attribute as shown below.
<pre>[ValidateInput(false)]
public ActionResult Update(int userId, string description)</pre>

Starting with ASP.NET MVC 3 you should use the <code>[AllowHtml]</code> attribute to decorate specific fields on your view model classes where request validation should not be applied:
<pre>public class User
{
public int Id { get; set; }
public string Name { get; set; }
public string Email { get; set; }
[AllowHtml]
public string Description { get; set; }
[AllowHtml]
public string Bio { get; set; }
}</pre>

==References==
*[http://msdn.microsoft.com/en-us/library/hh882339(v=vs.110).aspx Request Validation in ASP.NET]
*[http://msdn.microsoft.com/en-us/library/System.Web.HttpUtility_methods(v=vs.110).aspx HttpUtility Methods]
*[http://weblogs.asp.net/scottgu/new-lt-gt-syntax-for-html-encoding-output-in-asp-net-4-and-asp-net-mvc-2 New <%: %> Syntax for HTML Encoding Output in ASP.NET 4 (and ASP.NET MVC 2)]
*[http://msdn.microsoft.com/en-us/library/system.web.ihtmlstring(v=vs.110).aspx IHtmlString Interface]
*[http://stackoverflow.com/questions/2293357/what-is-an-mvchtmlstring-and-when-should-i-use-it What is an MvcHtmlString and when should I use it?]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder(v=vs.110).aspx AntiXssEncoder Class]
*[http://www.microsoft.com/en-sg/download/details.aspx?id=43126 Microsoft Anti-Cross Site Scripting Library V4.3]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.validateinputattribute(v=vs.118).aspx ValidateInputAttribute Class]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.allowhtmlattribute(v=vs.118).aspx AllowHtmlAttribute Class]

[[Category:OWASP .NET Project]]

ASP.NET Request Validation

2014-10-12T21:41:32Z

Bricex: /* ASP.NET Web API */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
''Request validation'' is a feature in ASP.NET that examines HTTP requests and determines whether they contain potentially dangerous content. 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 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. Request validation is generally desirable and should be left enabled unless you have a specific need that would prevent it from being used.

==Enabling Request Validation==
Request validation is enabled by default in ASP.NET. You can check to make sure it is not disabled at the page level by searching for any instances of:

<pre><@ Page ValidateRequest="false" %></pre>

You should also inspect the web.config file to ensure that request validation has not been disabled for the entire application:

<pre><pages validateRequest="false" /></pre>

Starting with ASP.NET 4.0 request validation is performed for all requests, not just for .aspx page requests. To ensure this is configured correctly look to see that <code>requestValidationMode</code> has '''NOT''' been set to 2.0.

<pre><httpRuntime requestValidationMode="2.0" /></pre>

===ASP.NET Web API===
ASP.NET Web API does not utilize the request validation feature to sanitize user input. You will need to add this protection manually if any input will be used in HTML output. For example if user input is returned to the browser as the result from an AJAX request to a Web API method.

==Validating User Input==
Even though request validation provides a good level of input protection, do not fully rely on it for securing your application against cross-site scripting attacks. Instead, validate all input from users and encode the output to ensure malicious code is not included.

===Encoding Input Values in Code-Behind===
Use <code>Server.HtmlEncode</code> to encode user input for use in HTML output:
<pre>var encodedHtmlInput = Server.HtmlEncode(userInput);</pre>

Use <code>Server.UrlEncode</code> to encode user input for use in constructing URLs
<pre>var encodedUrlInput = Server.UrlEncode(userInput);</pre>

Use <code>Server.UrlTokenEncode</code> to encode user input in byte array form for use as a URL parameter
<pre>var encodedUrlTokenInput = Server.UrlTokenEncode(userInput);</pre>

===Encoding Output Values in HTML markup===
You can HTML encode the value in markup with the <code><%: %></code> syntax, as shown below.
<pre><span><%: userInput %></span></pre>

Or, in Razor syntax, you can HTML encode with <code>@</code>, as shown below.
<pre><span>@userInput</span></pre>

===Preventing Double Encoding===
You may run into a scenario where encoding values results in them becoming double encoded on output. ASP.NET provides the <code>HtmlString</code> and <code>MvcHtmlString</code> classes starting with .NET 4.0 which are designed to help. These both implement the <code>IHtmlString</code> interface which will instruct ASP.NET to not apply encoding within HTML markup when using <code><%: userInput %></code> or <code>@userInput</code>. Converting a property on your view model from <code>String</code> to <code>MvcHtmlString</code> will instruct ASP.NET that HTML encoding has already been accounted for.

===Enhanced Request Validation Encoding===
ASP.NET request validation uses a black-listing technique that evaluates the string for a set of character combinations that may indicate presence of malicious script. A superior approach is to use a [[Input Validation Cheat Sheet#White_List_Input_Validation|white-listing technique]] for input validation, which can be achieved using the Anti-Cross Site Scripting Library from Microsoft. Starting with ASP.NET 4.5 you can specify that the <code>AntiXssEncoder</code> from this library be used as the default encoder for you entire application using the <code>encoderType</code> setting in web.config as shown below.
<pre><httpRuntime encoderType="System.Web.Security.AntiXss.AntiXssEncoder" /></pre>

If you are using a version of .NET earlier than 4.5, you will need to download and include the library as a reference to your project, and then use the earlier library name for the encodeType setting as shown below.
<pre><httpRuntime encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" /></pre>

==Selectively Disabling Request Validation==
In some cases you may need to accept input that will fail request validation, such as when receiving HTML markup from the end user. In these scenarios you should disable request validation for the smallest surface possible, and replace it with your own custom input validation.

===ASP.NET Web Forms===
For ASP.NET Web Forms applications you will need to disable request validation at the page level. Be aware that when doing this all input values (cookies, query string, form elements) handled by this page will not be validated by ASP.NET.
<pre><@ Page ValidateRequest="false" %></pre>

===ASP.NET MVC===
To disable request validation for a specific MVC controller action, you can use the <code>[ValidateInput(false)]</code> attribute as shown below.
<pre>[ValidateInput(false)]
public ActionResult Update(int userId, string description) {</pre>

Starting with ASP.NET MVC 3 you should use the <code>[AllowHtml]</code> attribute to decorate specific fields on your view model classes where request validation should not be applied:
<pre>public class User {
public int Id { get; set; }
public string Name { get; set; }
public string Email { get; set; }
[AllowHtml]
public string Description { get; set; }
[AllowHtml]
public string Bio { get; set; }
}</pre>

==References==
*[http://msdn.microsoft.com/en-us/library/hh882339(v=vs.110).aspx Request Validation in ASP.NET]
*[http://msdn.microsoft.com/en-us/library/System.Web.HttpUtility_methods(v=vs.110).aspx HttpUtility Methods]
*[http://weblogs.asp.net/scottgu/new-lt-gt-syntax-for-html-encoding-output-in-asp-net-4-and-asp-net-mvc-2 New <%: %> Syntax for HTML Encoding Output in ASP.NET 4 (and ASP.NET MVC 2)]
*[http://msdn.microsoft.com/en-us/library/system.web.ihtmlstring(v=vs.110).aspx IHtmlString Interface]
*[http://stackoverflow.com/questions/2293357/what-is-an-mvchtmlstring-and-when-should-i-use-it What is an MvcHtmlString and when should I use it?]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder(v=vs.110).aspx AntiXssEncoder Class]
*[http://www.microsoft.com/en-sg/download/details.aspx?id=43126 Microsoft Anti-Cross Site Scripting Library V4.3]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.validateinputattribute(v=vs.118).aspx ValidateInputAttribute Class]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.allowhtmlattribute(v=vs.118).aspx AllowHtmlAttribute Class]

[[Category:OWASP .NET Project]]

ASP.NET Request Validation

2014-10-12T21:40:45Z

Bricex: Page rewrite to capture advances in ASP.NET request validation

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
''Request validation'' is a feature in ASP.NET that examines HTTP requests and determines whether they contain potentially dangerous content. 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 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. Request validation is generally desirable and should be left enabled unless you have a specific need that would prevent it from being used.

==Enabling Request Validation==
Request validation is enabled by default in ASP.NET. You can check to make sure it is not disabled at the page level by searching for any instances of:

<pre><@ Page ValidateRequest="false" %></pre>

You should also inspect the web.config file to ensure that request validation has not been disabled for the entire application:

<pre><pages validateRequest="false" /></pre>

Starting with ASP.NET 4.0 request validation is performed for all requests, not just for .aspx page requests. To ensure this is configured correctly look to see that <code>requestValidationMode</code> has '''NOT''' been set to 2.0.

<pre><httpRuntime requestValidationMode="2.0" /></pre>

===ASP.NET Web API===
ASP.NET Web API does not utilize the request validation feature to sanitize user input. You will need to add this protection manually if this input will be used in HTML output. For example if user input is returned to the browser as the result from an AJAX request to a Web API method.

==Validating User Input==
Even though request validation provides a good level of input protection, do not fully rely on it for securing your application against cross-site scripting attacks. Instead, validate all input from users and encode the output to ensure malicious code is not included.

===Encoding Input Values in Code-Behind===
Use <code>Server.HtmlEncode</code> to encode user input for use in HTML output:
<pre>var encodedHtmlInput = Server.HtmlEncode(userInput);</pre>

Use <code>Server.UrlEncode</code> to encode user input for use in constructing URLs
<pre>var encodedUrlInput = Server.UrlEncode(userInput);</pre>

Use <code>Server.UrlTokenEncode</code> to encode user input in byte array form for use as a URL parameter
<pre>var encodedUrlTokenInput = Server.UrlTokenEncode(userInput);</pre>

===Encoding Output Values in HTML markup===
You can HTML encode the value in markup with the <code><%: %></code> syntax, as shown below.
<pre><span><%: userInput %></span></pre>

Or, in Razor syntax, you can HTML encode with <code>@</code>, as shown below.
<pre><span>@userInput</span></pre>

===Preventing Double Encoding===
You may run into a scenario where encoding values results in them becoming double encoded on output. ASP.NET provides the <code>HtmlString</code> and <code>MvcHtmlString</code> classes starting with .NET 4.0 which are designed to help. These both implement the <code>IHtmlString</code> interface which will instruct ASP.NET to not apply encoding within HTML markup when using <code><%: userInput %></code> or <code>@userInput</code>. Converting a property on your view model from <code>String</code> to <code>MvcHtmlString</code> will instruct ASP.NET that HTML encoding has already been accounted for.

===Enhanced Request Validation Encoding===
ASP.NET request validation uses a black-listing technique that evaluates the string for a set of character combinations that may indicate presence of malicious script. A superior approach is to use a [[Input Validation Cheat Sheet#White_List_Input_Validation|white-listing technique]] for input validation, which can be achieved using the Anti-Cross Site Scripting Library from Microsoft. Starting with ASP.NET 4.5 you can specify that the <code>AntiXssEncoder</code> from this library be used as the default encoder for you entire application using the <code>encoderType</code> setting in web.config as shown below.
<pre><httpRuntime encoderType="System.Web.Security.AntiXss.AntiXssEncoder" /></pre>

If you are using a version of .NET earlier than 4.5, you will need to download and include the library as a reference to your project, and then use the earlier library name for the encodeType setting as shown below.
<pre><httpRuntime encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" /></pre>

==Selectively Disabling Request Validation==
In some cases you may need to accept input that will fail request validation, such as when receiving HTML markup from the end user. In these scenarios you should disable request validation for the smallest surface possible, and replace it with your own custom input validation.

===ASP.NET Web Forms===
For ASP.NET Web Forms applications you will need to disable request validation at the page level. Be aware that when doing this all input values (cookies, query string, form elements) handled by this page will not be validated by ASP.NET.
<pre><@ Page ValidateRequest="false" %></pre>

===ASP.NET MVC===
To disable request validation for a specific MVC controller action, you can use the <code>[ValidateInput(false)]</code> attribute as shown below.
<pre>[ValidateInput(false)]
public ActionResult Update(int userId, string description) {</pre>

Starting with ASP.NET MVC 3 you should use the <code>[AllowHtml]</code> attribute to decorate specific fields on your view model classes where request validation should not be applied:
<pre>public class User {
public int Id { get; set; }
public string Name { get; set; }
public string Email { get; set; }
[AllowHtml]
public string Description { get; set; }
[AllowHtml]
public string Bio { get; set; }
}</pre>

==References==
*[http://msdn.microsoft.com/en-us/library/hh882339(v=vs.110).aspx Request Validation in ASP.NET]
*[http://msdn.microsoft.com/en-us/library/System.Web.HttpUtility_methods(v=vs.110).aspx HttpUtility Methods]
*[http://weblogs.asp.net/scottgu/new-lt-gt-syntax-for-html-encoding-output-in-asp-net-4-and-asp-net-mvc-2 New <%: %> Syntax for HTML Encoding Output in ASP.NET 4 (and ASP.NET MVC 2)]
*[http://msdn.microsoft.com/en-us/library/system.web.ihtmlstring(v=vs.110).aspx IHtmlString Interface]
*[http://stackoverflow.com/questions/2293357/what-is-an-mvchtmlstring-and-when-should-i-use-it What is an MvcHtmlString and when should I use it?]
*[http://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder(v=vs.110).aspx AntiXssEncoder Class]
*[http://www.microsoft.com/en-sg/download/details.aspx?id=43126 Microsoft Anti-Cross Site Scripting Library V4.3]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.validateinputattribute(v=vs.118).aspx ValidateInputAttribute Class]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.allowhtmlattribute(v=vs.118).aspx AllowHtmlAttribute Class]

[[Category:OWASP .NET Project]]

Exception Handling

2014-10-03T16:53:36Z

Bricex: /* Where to Catch Exceptions */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
An exception is any error condition or unexpected behavior that is encountered by your application. There are several key security concerns to be aware of when handling exceptions in .NET web applications:
*Preventing system information leakage that could aid a malicious user.
*Ensuring the application fails securely under all circumstances, both expected and not expected.
*Using a centralized error strategy to reduce points of failure and promote consistency.
*Log when exceptions are thrown and include sufficient detail for security auditing.

==Displaying Errors==
When your application displays error messages, it should not give away information that a malicious user might find helpful in attacking your system. For example, if your application fails while attempting to connect to a database, it should not display an error message that includes the connection string being used.

The default display mechanism for unhandled exceptions in ASP.NET is controlled via the ''<customErrors>'' element in the web.config file. This element includes a ''mode'' attribute that can be set to: ''Off'', ''On'', or ''RemoteOnly''. This mode setting should never be set to ''Off'' in a production environment because it will cause exception details to be displayed to the end user which may include sensitive information about the system.

<pre><customErrors mode="RemoteOnly" defaultRedirect="/Error">
<error statusCode="404" redirect="/Error?id=404" />
<error statusCode="403" redirect="/Error?id=403" />
</customErrors></pre>

===HTTP Status Codes===
When reviewing error responses be careful that a malicious user is not able to glean any potentially sensitive information about the system from the status code returned. For example: an API search that takes a tenant ID parameter and returns an HTTP 404 response for no results, and an HTTP 500 response if the tenant ID does not exist. An attacker could potentially leverage this information to determine if a tenant ID is valid or not. One solution would be to catch the exception thrown when a supplied tenant ID does not exist, and return an HTTP 404 status code with the error response.

==Where to Catch Exceptions==
There are a variety of places within a typical web application where exceptions can be caught and logged. First and foremost you want to catch exceptions at an application level and ensure they are handled properly. Often this may be the only location necessary to catch exceptions. In addition to this, handling exceptions at lower levels in the application will give you more control and may provide you with more detailed contextual information.

If you use try/catch blocks to handle exceptions be aware of two concerns:

#Avoid using the ''Exception'' class but instead use a descendant class that is the most applicable to the condition you are expecting.
#Be careful not to just catch an exception and continue processing. Always use the ''throw'' statement to re-throw the exception unless you are certain that this will not leave the application in an unexpected and potentially vulnerable state.

<pre>try
{
Emailer.SendNewUserActivation(this)
}
catch (SmtpException ex)
{
this.Delete();
throw;
}</pre>

==Logging Exception Details==
Logging exception details is important when you need to properly diagnose error conditions with the system. You don't want this detail to be displayed on an error page because it may inadvertently aid a malicious user in an attack. Logging allows your error pages to display a simple generic message alerting end users that an error has occurred, with possibly some options for contacting support. The detail you need for assisting with these issues will be kept securely in the log store.

You can use several methods to log exception events, including popular third party libraries: log4net, nlog, Common.Logging, etc. An out-of-the-box solution included with .NET is System.Diagnostics Tracing as shown in the code examples in this article. These trace messages can then be written out using trace listeners such as the ''TextWriterTraceListener'' configured here.

<pre><system.diagnostics>
<trace autoflush="true">
<listeners>
<add name="EventTracer"
type="System.Diagnostics.TextWriterTraceListener, System, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
initializeData="<app root directory>\eventtrace.log" />
</listeners>
</trace>
</system.diagnostics></pre>

One benefit to using System.Diagnostics Tracing in your code is that most logging frameworks already support including these events and writing them to a variety of output types.

For detailed security guidance specific to logging see [[Reviewing Code for Logging Issues]].

===Application Level===
The following code example shows how to create an error handler in the Global.asax.cs file that will catch and log all unhandled ASP.NET errors at the application level. Unhandled exceptions must be logged within ''Application_Error'' rather than in a subsequent page defined by ''<customErrors>'', because the exception details are only available at this point.

<pre>void Application_Error(object sender, EventArgs e)
{
// Get the exception object.
var exception = Server.GetLastError();

// Log exception details. Be sure to include items like client IP
// address and current authenticated user if applicable.
System.Diagnostics.Trace.TraceError(exception.ToString());
}</pre>

===Server.ClearError===
Use the ''Server.ClearError()'' method with caution when handling exceptions. This method will clear the exception state and allow execution to continue rather than displaying an error message to the end user. There are valid scenarios where this is needed, but in general you should avoid this as it could allow a malicious user to bypass security controls if they are somehow able to force an error condition.

===ASP.NET Web Forms===
ASP.NET web form pages provide the ability to capture exceptions at the page level in a similar fashion to the application level. This may be useful if you need to perform failure handling logic or log additional detail unique to the page.

<pre>void Page_Error(object sender, EventArgs e)
{
// Get the exception object.
var exception = Server.GetLastError();

// Log exception details. Be sure to include items like client IP
// address and current authenticated user if applicable.
System.Diagnostics.Trace.TraceError(exception.ToString());
}</pre>

===ASP.NET MVC===
The MVC Controller class provides an ''OnException'' method similar to the ''Page_Error'' method in ASP.NET Web Forms. It allows you to process all unhandled exceptions thrown by actions of the controller. One option for implementing exception logging is to create a base controller class and defining the ''OnException'' method in this one central location.

<pre>protected override void OnException(ExceptionContext filterContext)
{
base.OnException(filterContext);
System.Diagnostics.Trace.TraceError(filterContext.Exception.ToString());
}</pre>

A second (and arguably better) approach is to utilize the ''System.Web.Mvc.HandleErrorAttribute'' which can be used to handle exceptions at the application, controller, or action level. To apply this at the application level you add an instance of ''HandleErrorAttribute'' to the ''GlobalFilterCollection'' at application startup. This takes affect before the ''Application_Error'' method in Global.asax.cs, and by default will redirect to the ''Error'' view in the ~/Views/Shared folder. This will bypass any custom error pages defined via the ''<customErrors>'' element in web.config.

<pre>public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new HandleErrorAttribute());
}</pre>

You can log the exception details right within the ''Error.cshtml'' view using properties from the view model which is of type ''System.Web.Mvc.HandleErrorInfo''.

<pre>@model System.Web.Mvc.HandleErrorInfo

@{
ViewBag.Title = "Error";

// Log exception details
System.Diagnostics.Trace.TraceError(Model.Exception.ToString());
}

<h1 class="text-danger">Error.</h1>
<h2 class="text-danger">An error occurred while processing your request.</h2></pre>

===ASP.NET Web API===
When handling exceptions for your API endpoints you generally want to return a JSON or XML response rather than redirect to an HTML page. ASP.NET Web API provides exception filters to customize how exceptions are handled. A good way of adding exception logging is to derive your own class from ''System.Web.Http.Filters.ExceptionFilterAttribute'' and override the ''OnException'' method as shown.

<pre>public class LogExceptionFilterAttribute : ExceptionFilterAttribute
{
public override void OnException(HttpActionExecutedContext context)
{
System.Diagnostics.Trace.TraceError(context.Exception.ToString());
base.OnException(context);
}
}</pre>

You can apply the ''[LogExceptionFilter]'' attribute to any ''ApiController'', or add it at a global level using the following code at application startup.

<pre>System.Web.Http.GlobalConfiguration.Configuration.Filters.Add(new LogExceptionFilterAttribute());</pre>

====HttpResponseException====
By default any exception thrown within Web API will return an HTTP response status code of 500 (Internal Server Error). For more control over the response you can use ''HttpResponseException'' as shown.

<pre>public Product GetProduct(int id)
{
Product item = repository.Get(id);
if (item == null)
{
throw new HttpResponseException(HttpStatusCode.NotFound)
{
Content = new StringContent(string.Format("No product with ID = {0}", id)),
ReasonPhrase = "Product ID Not Found"
};
}
return item;
}</pre>

====Web API Global Error Handling (Added in Web API 2.1)====
There are a number of cases in Web API where an exception can occur that falls outside of what exception filters can handle. These include exceptions in controller construction, message handlers, routing, and response content serialization. To handle these exceptions you will need to register a class that implements the ''IExceptionLogger'' interface, or derives from the ''ExceptionLogger'' base class.

<pre>public interface IExceptionLogger
{
Task LogAsync(ExceptionLoggerContext context, CancellationToken cancellationToken);
}</pre>

You then register your class at application startup to ensure that all exceptions raised during a Web API request life cycle are captured and logged.

<pre>System.Web.Http.GlobalConfiguration.Services.Add(typeof(IExceptionLogger), new MyExceptionLogger());</pre>

==Logging Sensitive Data==
Be careful when logging exception details that you do not inadvertently expose sensitive data to a logging system or external reports that may have relaxed access controls compared to the primary system. For example if a ''SqlException'' is thrown and the details contain a connection string, you may want to mask the password attribute before logging the event. Use care when logging exception details that may contain the following types of data:

*Passwords
*Authentication tokens
*Personally identifiable information (PII)
*Personal health information (PHI)
*Credit card data

==References==
*[http://www.asp.net/web-forms/tutorials/deployment/deploying-web-site-projects/displaying-a-custom-error-page-cs Displaying a Custom Error Page]
*[http://msdn.microsoft.com/en-us/library/h0hfz6fc(v=vs.100).aspx customErrors Element (ASP.NET Settings Schema)]
*[http://msdn.microsoft.com/en-us/library/system.diagnostics.trace(v=vs.110).aspx Trace Class]
*[http://msdn.microsoft.com/en-us/library/ed577840(v=vs.100).aspx How to: Handle Page-Level Errors]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.controller.onexception(v=vs.118).aspx Controller.OnException Method]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.handleerrorattribute(v=vs.118).aspx HandleErrorAtttribute Class]
*[http://www.asp.net/web-api/overview/testing-and-debugging/exception-handling Exception Handling in ASP.NET Web API]
*[http://www.asp.net/web-api/overview/testing-and-debugging/web-api-global-error-handling Web API 2 .1 Global Error Handling]

[[Category:OWASP .NET Project]][[Category:Stub]]

Exception Handling

2014-10-03T16:44:48Z

Bricex: /* Web API Global Error Handling (Added in Web API 2.1) */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
An exception is any error condition or unexpected behavior that is encountered by your application. There are several key security concerns to be aware of when handling exceptions in .NET web applications:
*Preventing system information leakage that could aid a malicious user.
*Ensuring the application fails securely under all circumstances, both expected and not expected.
*Using a centralized error strategy to reduce points of failure and promote consistency.
*Log when exceptions are thrown and include sufficient detail for security auditing.

==Displaying Errors==
When your application displays error messages, it should not give away information that a malicious user might find helpful in attacking your system. For example, if your application fails while attempting to connect to a database, it should not display an error message that includes the connection string being used.

The default display mechanism for unhandled exceptions in ASP.NET is controlled via the ''<customErrors>'' element in the web.config file. This element includes a ''mode'' attribute that can be set to: ''Off'', ''On'', or ''RemoteOnly''. This mode setting should never be set to ''Off'' in a production environment because it will cause exception details to be displayed to the end user which may include sensitive information about the system.

<pre><customErrors mode="RemoteOnly" defaultRedirect="/Error">
<error statusCode="404" redirect="/Error?id=404" />
<error statusCode="403" redirect="/Error?id=403" />
</customErrors></pre>

===HTTP Status Codes===
When reviewing error responses be careful that a malicious user is not able to glean any potentially sensitive information about the system from the status code returned. For example: an API search that takes a tenant ID parameter and returns an HTTP 404 response for no results, and an HTTP 500 response if the tenant ID does not exist. An attacker could potentially leverage this information to determine if a tenant ID is valid or not. One solution would be to catch the exception thrown when a supplied tenant ID does not exist, and return an HTTP 404 status code with the error response.

==Where to Catch Exceptions==
There are a variety of places within a typical web application where exceptions can be caught and logged. First and foremost you want to catch exceptions at an application level and ensure they are handled properly. Often this may be the only location necessary to catch exceptions. In addition to this, handling exceptions at lower levels in the application will give you more control and may provide you with more detailed contextual information.

If you use try/catch blocks to handle exceptions be aware of two concerns:

#Avoid using the ''Exception'' class but instead use a descendant class this the most applicable to the condition you are expecting. This may require you to write your own descendant class.
#Be careful not to catch an exception and continue processing. Always use the ''throw'' statement to re-throw the exception unless you are certain that this will not leave the application in an unexpected and potentially vulnerable state.

<pre>try
{
Emailer.SendNewUserActivation(this)
}
catch (SmtpException ex)
{
this.Delete();
throw;
}</pre>

==Logging Exception Details==
Logging exception details is important when you need to properly diagnose error conditions with the system. You don't want this detail to be displayed on an error page because it may inadvertently aid a malicious user in an attack. Logging allows your error pages to display a simple generic message alerting end users that an error has occurred, with possibly some options for contacting support. The detail you need for assisting with these issues will be kept securely in the log store.

You can use several methods to log exception events, including popular third party libraries: log4net, nlog, Common.Logging, etc. An out-of-the-box solution included with .NET is System.Diagnostics Tracing as shown in the code examples in this article. These trace messages can then be written out using trace listeners such as the ''TextWriterTraceListener'' configured here.

<pre><system.diagnostics>
<trace autoflush="true">
<listeners>
<add name="EventTracer"
type="System.Diagnostics.TextWriterTraceListener, System, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
initializeData="<app root directory>\eventtrace.log" />
</listeners>
</trace>
</system.diagnostics></pre>

One benefit to using System.Diagnostics Tracing in your code is that most logging frameworks already support including these events and writing them to a variety of output types.

For detailed security guidance specific to logging see [[Reviewing Code for Logging Issues]].

===Application Level===
The following code example shows how to create an error handler in the Global.asax.cs file that will catch and log all unhandled ASP.NET errors at the application level. Unhandled exceptions must be logged within ''Application_Error'' rather than in a subsequent page defined by ''<customErrors>'', because the exception details are only available at this point.

<pre>void Application_Error(object sender, EventArgs e)
{
// Get the exception object.
var exception = Server.GetLastError();

// Log exception details. Be sure to include items like client IP
// address and current authenticated user if applicable.
System.Diagnostics.Trace.TraceError(exception.ToString());
}</pre>

===Server.ClearError===
Use the ''Server.ClearError()'' method with caution when handling exceptions. This method will clear the exception state and allow execution to continue rather than displaying an error message to the end user. There are valid scenarios where this is needed, but in general you should avoid this as it could allow a malicious user to bypass security controls if they are somehow able to force an error condition.

===ASP.NET Web Forms===
ASP.NET web form pages provide the ability to capture exceptions at the page level in a similar fashion to the application level. This may be useful if you need to perform failure handling logic or log additional detail unique to the page.

<pre>void Page_Error(object sender, EventArgs e)
{
// Get the exception object.
var exception = Server.GetLastError();

// Log exception details. Be sure to include items like client IP
// address and current authenticated user if applicable.
System.Diagnostics.Trace.TraceError(exception.ToString());
}</pre>

===ASP.NET MVC===
The MVC Controller class provides an ''OnException'' method similar to the ''Page_Error'' method in ASP.NET Web Forms. It allows you to process all unhandled exceptions thrown by actions of the controller. One option for implementing exception logging is to create a base controller class and defining the ''OnException'' method in this one central location.

<pre>protected override void OnException(ExceptionContext filterContext)
{
base.OnException(filterContext);
System.Diagnostics.Trace.TraceError(filterContext.Exception.ToString());
}</pre>

A second (and arguably better) approach is to utilize the ''System.Web.Mvc.HandleErrorAttribute'' which can be used to handle exceptions at the application, controller, or action level. To apply this at the application level you add an instance of ''HandleErrorAttribute'' to the ''GlobalFilterCollection'' at application startup. This takes affect before the ''Application_Error'' method in Global.asax.cs, and by default will redirect to the ''Error'' view in the ~/Views/Shared folder. This will bypass any custom error pages defined via the ''<customErrors>'' element in web.config.

<pre>public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new HandleErrorAttribute());
}</pre>

You can log the exception details right within the ''Error.cshtml'' view using properties from the view model which is of type ''System.Web.Mvc.HandleErrorInfo''.

<pre>@model System.Web.Mvc.HandleErrorInfo

@{
ViewBag.Title = "Error";

// Log exception details
System.Diagnostics.Trace.TraceError(Model.Exception.ToString());
}

<h1 class="text-danger">Error.</h1>
<h2 class="text-danger">An error occurred while processing your request.</h2></pre>

===ASP.NET Web API===
When handling exceptions for your API endpoints you generally want to return a JSON or XML response rather than redirect to an HTML page. ASP.NET Web API provides exception filters to customize how exceptions are handled. A good way of adding exception logging is to derive your own class from ''System.Web.Http.Filters.ExceptionFilterAttribute'' and override the ''OnException'' method as shown.

<pre>public class LogExceptionFilterAttribute : ExceptionFilterAttribute
{
public override void OnException(HttpActionExecutedContext context)
{
System.Diagnostics.Trace.TraceError(context.Exception.ToString());
base.OnException(context);
}
}</pre>

You can apply the ''[LogExceptionFilter]'' attribute to any ''ApiController'', or add it at a global level using the following code at application startup.

<pre>System.Web.Http.GlobalConfiguration.Configuration.Filters.Add(new LogExceptionFilterAttribute());</pre>

====HttpResponseException====
By default any exception thrown within Web API will return an HTTP response status code of 500 (Internal Server Error). For more control over the response you can use ''HttpResponseException'' as shown.

<pre>public Product GetProduct(int id)
{
Product item = repository.Get(id);
if (item == null)
{
throw new HttpResponseException(HttpStatusCode.NotFound)
{
Content = new StringContent(string.Format("No product with ID = {0}", id)),
ReasonPhrase = "Product ID Not Found"
};
}
return item;
}</pre>

====Web API Global Error Handling (Added in Web API 2.1)====
There are a number of cases in Web API where an exception can occur that falls outside of what exception filters can handle. These include exceptions in controller construction, message handlers, routing, and response content serialization. To handle these exceptions you will need to register a class that implements the ''IExceptionLogger'' interface, or derives from the ''ExceptionLogger'' base class.

<pre>public interface IExceptionLogger
{
Task LogAsync(ExceptionLoggerContext context, CancellationToken cancellationToken);
}</pre>

You then register your class at application startup to ensure that all exceptions raised during a Web API request life cycle are captured and logged.

<pre>System.Web.Http.GlobalConfiguration.Services.Add(typeof(IExceptionLogger), new MyExceptionLogger());</pre>

==Logging Sensitive Data==
Be careful when logging exception details that you do not inadvertently expose sensitive data to a logging system or external reports that may have relaxed access controls compared to the primary system. For example if a ''SqlException'' is thrown and the details contain a connection string, you may want to mask the password attribute before logging the event. Use care when logging exception details that may contain the following types of data:

*Passwords
*Authentication tokens
*Personally identifiable information (PII)
*Personal health information (PHI)
*Credit card data

==References==
*[http://www.asp.net/web-forms/tutorials/deployment/deploying-web-site-projects/displaying-a-custom-error-page-cs Displaying a Custom Error Page]
*[http://msdn.microsoft.com/en-us/library/h0hfz6fc(v=vs.100).aspx customErrors Element (ASP.NET Settings Schema)]
*[http://msdn.microsoft.com/en-us/library/system.diagnostics.trace(v=vs.110).aspx Trace Class]
*[http://msdn.microsoft.com/en-us/library/ed577840(v=vs.100).aspx How to: Handle Page-Level Errors]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.controller.onexception(v=vs.118).aspx Controller.OnException Method]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.handleerrorattribute(v=vs.118).aspx HandleErrorAtttribute Class]
*[http://www.asp.net/web-api/overview/testing-and-debugging/exception-handling Exception Handling in ASP.NET Web API]
*[http://www.asp.net/web-api/overview/testing-and-debugging/web-api-global-error-handling Web API 2 .1 Global Error Handling]

[[Category:OWASP .NET Project]][[Category:Stub]]

Exception Handling

2014-10-03T16:44:14Z

Bricex: /* ASP.NET Web API */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
An exception is any error condition or unexpected behavior that is encountered by your application. There are several key security concerns to be aware of when handling exceptions in .NET web applications:
*Preventing system information leakage that could aid a malicious user.
*Ensuring the application fails securely under all circumstances, both expected and not expected.
*Using a centralized error strategy to reduce points of failure and promote consistency.
*Log when exceptions are thrown and include sufficient detail for security auditing.

==Displaying Errors==
When your application displays error messages, it should not give away information that a malicious user might find helpful in attacking your system. For example, if your application fails while attempting to connect to a database, it should not display an error message that includes the connection string being used.

The default display mechanism for unhandled exceptions in ASP.NET is controlled via the ''<customErrors>'' element in the web.config file. This element includes a ''mode'' attribute that can be set to: ''Off'', ''On'', or ''RemoteOnly''. This mode setting should never be set to ''Off'' in a production environment because it will cause exception details to be displayed to the end user which may include sensitive information about the system.

<pre><customErrors mode="RemoteOnly" defaultRedirect="/Error">
<error statusCode="404" redirect="/Error?id=404" />
<error statusCode="403" redirect="/Error?id=403" />
</customErrors></pre>

===HTTP Status Codes===
When reviewing error responses be careful that a malicious user is not able to glean any potentially sensitive information about the system from the status code returned. For example: an API search that takes a tenant ID parameter and returns an HTTP 404 response for no results, and an HTTP 500 response if the tenant ID does not exist. An attacker could potentially leverage this information to determine if a tenant ID is valid or not. One solution would be to catch the exception thrown when a supplied tenant ID does not exist, and return an HTTP 404 status code with the error response.

==Where to Catch Exceptions==
There are a variety of places within a typical web application where exceptions can be caught and logged. First and foremost you want to catch exceptions at an application level and ensure they are handled properly. Often this may be the only location necessary to catch exceptions. In addition to this, handling exceptions at lower levels in the application will give you more control and may provide you with more detailed contextual information.

If you use try/catch blocks to handle exceptions be aware of two concerns:

#Avoid using the ''Exception'' class but instead use a descendant class this the most applicable to the condition you are expecting. This may require you to write your own descendant class.
#Be careful not to catch an exception and continue processing. Always use the ''throw'' statement to re-throw the exception unless you are certain that this will not leave the application in an unexpected and potentially vulnerable state.

<pre>try
{
Emailer.SendNewUserActivation(this)
}
catch (SmtpException ex)
{
this.Delete();
throw;
}</pre>

==Logging Exception Details==
Logging exception details is important when you need to properly diagnose error conditions with the system. You don't want this detail to be displayed on an error page because it may inadvertently aid a malicious user in an attack. Logging allows your error pages to display a simple generic message alerting end users that an error has occurred, with possibly some options for contacting support. The detail you need for assisting with these issues will be kept securely in the log store.

You can use several methods to log exception events, including popular third party libraries: log4net, nlog, Common.Logging, etc. An out-of-the-box solution included with .NET is System.Diagnostics Tracing as shown in the code examples in this article. These trace messages can then be written out using trace listeners such as the ''TextWriterTraceListener'' configured here.

<pre><system.diagnostics>
<trace autoflush="true">
<listeners>
<add name="EventTracer"
type="System.Diagnostics.TextWriterTraceListener, System, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
initializeData="<app root directory>\eventtrace.log" />
</listeners>
</trace>
</system.diagnostics></pre>

One benefit to using System.Diagnostics Tracing in your code is that most logging frameworks already support including these events and writing them to a variety of output types.

For detailed security guidance specific to logging see [[Reviewing Code for Logging Issues]].

===Application Level===
The following code example shows how to create an error handler in the Global.asax.cs file that will catch and log all unhandled ASP.NET errors at the application level. Unhandled exceptions must be logged within ''Application_Error'' rather than in a subsequent page defined by ''<customErrors>'', because the exception details are only available at this point.

<pre>void Application_Error(object sender, EventArgs e)
{
// Get the exception object.
var exception = Server.GetLastError();

// Log exception details. Be sure to include items like client IP
// address and current authenticated user if applicable.
System.Diagnostics.Trace.TraceError(exception.ToString());
}</pre>

===Server.ClearError===
Use the ''Server.ClearError()'' method with caution when handling exceptions. This method will clear the exception state and allow execution to continue rather than displaying an error message to the end user. There are valid scenarios where this is needed, but in general you should avoid this as it could allow a malicious user to bypass security controls if they are somehow able to force an error condition.

===ASP.NET Web Forms===
ASP.NET web form pages provide the ability to capture exceptions at the page level in a similar fashion to the application level. This may be useful if you need to perform failure handling logic or log additional detail unique to the page.

<pre>void Page_Error(object sender, EventArgs e)
{
// Get the exception object.
var exception = Server.GetLastError();

// Log exception details. Be sure to include items like client IP
// address and current authenticated user if applicable.
System.Diagnostics.Trace.TraceError(exception.ToString());
}</pre>

===ASP.NET MVC===
The MVC Controller class provides an ''OnException'' method similar to the ''Page_Error'' method in ASP.NET Web Forms. It allows you to process all unhandled exceptions thrown by actions of the controller. One option for implementing exception logging is to create a base controller class and defining the ''OnException'' method in this one central location.

<pre>protected override void OnException(ExceptionContext filterContext)
{
base.OnException(filterContext);
System.Diagnostics.Trace.TraceError(filterContext.Exception.ToString());
}</pre>

A second (and arguably better) approach is to utilize the ''System.Web.Mvc.HandleErrorAttribute'' which can be used to handle exceptions at the application, controller, or action level. To apply this at the application level you add an instance of ''HandleErrorAttribute'' to the ''GlobalFilterCollection'' at application startup. This takes affect before the ''Application_Error'' method in Global.asax.cs, and by default will redirect to the ''Error'' view in the ~/Views/Shared folder. This will bypass any custom error pages defined via the ''<customErrors>'' element in web.config.

<pre>public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new HandleErrorAttribute());
}</pre>

You can log the exception details right within the ''Error.cshtml'' view using properties from the view model which is of type ''System.Web.Mvc.HandleErrorInfo''.

<pre>@model System.Web.Mvc.HandleErrorInfo

@{
ViewBag.Title = "Error";

// Log exception details
System.Diagnostics.Trace.TraceError(Model.Exception.ToString());
}

<h1 class="text-danger">Error.</h1>
<h2 class="text-danger">An error occurred while processing your request.</h2></pre>

===ASP.NET Web API===
When handling exceptions for your API endpoints you generally want to return a JSON or XML response rather than redirect to an HTML page. ASP.NET Web API provides exception filters to customize how exceptions are handled. A good way of adding exception logging is to derive your own class from ''System.Web.Http.Filters.ExceptionFilterAttribute'' and override the ''OnException'' method as shown.

<pre>public class LogExceptionFilterAttribute : ExceptionFilterAttribute
{
public override void OnException(HttpActionExecutedContext context)
{
System.Diagnostics.Trace.TraceError(context.Exception.ToString());
base.OnException(context);
}
}</pre>

You can apply the ''[LogExceptionFilter]'' attribute to any ''ApiController'', or add it at a global level using the following code at application startup.

<pre>System.Web.Http.GlobalConfiguration.Configuration.Filters.Add(new LogExceptionFilterAttribute());</pre>

====HttpResponseException====
By default any exception thrown within Web API will return an HTTP response status code of 500 (Internal Server Error). For more control over the response you can use ''HttpResponseException'' as shown.

<pre>public Product GetProduct(int id)
{
Product item = repository.Get(id);
if (item == null)
{
throw new HttpResponseException(HttpStatusCode.NotFound)
{
Content = new StringContent(string.Format("No product with ID = {0}", id)),
ReasonPhrase = "Product ID Not Found"
};
}
return item;
}</pre>

===Web API Global Error Handling (Added in Web API 2.1)===
There are a number of cases in Web API where an exception can occur that falls outside of what exception filters can handle. These include exceptions in controller construction, message handlers, routing, and response content serialization. To handle these exceptions you will need to register a class that implements the ''IExceptionLogger'' interface, or derives from the ''ExceptionLogger'' base class.

<pre>public interface IExceptionLogger
{
Task LogAsync(ExceptionLoggerContext context, CancellationToken cancellationToken);
}</pre>

You then register your class at application startup to ensure that all exceptions raised during a Web API request life cycle are captured and logged.

<pre>System.Web.Http.GlobalConfiguration.Services.Add(typeof(IExceptionLogger), new MyExceptionLogger());</pre>

==Logging Sensitive Data==
Be careful when logging exception details that you do not inadvertently expose sensitive data to a logging system or external reports that may have relaxed access controls compared to the primary system. For example if a ''SqlException'' is thrown and the details contain a connection string, you may want to mask the password attribute before logging the event. Use care when logging exception details that may contain the following types of data:

*Passwords
*Authentication tokens
*Personally identifiable information (PII)
*Personal health information (PHI)
*Credit card data

==References==
*[http://www.asp.net/web-forms/tutorials/deployment/deploying-web-site-projects/displaying-a-custom-error-page-cs Displaying a Custom Error Page]
*[http://msdn.microsoft.com/en-us/library/h0hfz6fc(v=vs.100).aspx customErrors Element (ASP.NET Settings Schema)]
*[http://msdn.microsoft.com/en-us/library/system.diagnostics.trace(v=vs.110).aspx Trace Class]
*[http://msdn.microsoft.com/en-us/library/ed577840(v=vs.100).aspx How to: Handle Page-Level Errors]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.controller.onexception(v=vs.118).aspx Controller.OnException Method]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.handleerrorattribute(v=vs.118).aspx HandleErrorAtttribute Class]
*[http://www.asp.net/web-api/overview/testing-and-debugging/exception-handling Exception Handling in ASP.NET Web API]
*[http://www.asp.net/web-api/overview/testing-and-debugging/web-api-global-error-handling Web API 2 .1 Global Error Handling]

[[Category:OWASP .NET Project]][[Category:Stub]]

Exception Handling

2014-10-03T16:24:00Z

Bricex: Including "Where to Catch Exceptions" section

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
An exception is any error condition or unexpected behavior that is encountered by your application. There are several key security concerns to be aware of when handling exceptions in .NET web applications:
*Preventing system information leakage that could aid a malicious user.
*Ensuring the application fails securely under all circumstances, both expected and not expected.
*Using a centralized error strategy to reduce points of failure and promote consistency.
*Log when exceptions are thrown and include sufficient detail for security auditing.

==Displaying Errors==
When your application displays error messages, it should not give away information that a malicious user might find helpful in attacking your system. For example, if your application fails while attempting to connect to a database, it should not display an error message that includes the connection string being used.

The default display mechanism for unhandled exceptions in ASP.NET is controlled via the ''<customErrors>'' element in the web.config file. This element includes a ''mode'' attribute that can be set to: ''Off'', ''On'', or ''RemoteOnly''. This mode setting should never be set to ''Off'' in a production environment because it will cause exception details to be displayed to the end user which may include sensitive information about the system.

<pre><customErrors mode="RemoteOnly" defaultRedirect="/Error">
<error statusCode="404" redirect="/Error?id=404" />
<error statusCode="403" redirect="/Error?id=403" />
</customErrors></pre>

===HTTP Status Codes===
When reviewing error responses be careful that a malicious user is not able to glean any potentially sensitive information about the system from the status code returned. For example: an API search that takes a tenant ID parameter and returns an HTTP 404 response for no results, and an HTTP 500 response if the tenant ID does not exist. An attacker could potentially leverage this information to determine if a tenant ID is valid or not. One solution would be to catch the exception thrown when a supplied tenant ID does not exist, and return an HTTP 404 status code with the error response.

==Where to Catch Exceptions==
There are a variety of places within a typical web application where exceptions can be caught and logged. First and foremost you want to catch exceptions at an application level and ensure they are handled properly. Often this may be the only location necessary to catch exceptions. In addition to this, handling exceptions at lower levels in the application will give you more control and may provide you with more detailed contextual information.

If you use try/catch blocks to handle exceptions be aware of two concerns:

#Avoid using the ''Exception'' class but instead use a descendant class this the most applicable to the condition you are expecting. This may require you to write your own descendant class.
#Be careful not to catch an exception and continue processing. Always use the ''throw'' statement to re-throw the exception unless you are certain that this will not leave the application in an unexpected and potentially vulnerable state.

<pre>try
{
Emailer.SendNewUserActivation(this)
}
catch (SmtpException ex)
{
this.Delete();
throw;
}</pre>

==Logging Exception Details==
Logging exception details is important when you need to properly diagnose error conditions with the system. You don't want this detail to be displayed on an error page because it may inadvertently aid a malicious user in an attack. Logging allows your error pages to display a simple generic message alerting end users that an error has occurred, with possibly some options for contacting support. The detail you need for assisting with these issues will be kept securely in the log store.

You can use several methods to log exception events, including popular third party libraries: log4net, nlog, Common.Logging, etc. An out-of-the-box solution included with .NET is System.Diagnostics Tracing as shown in the code examples in this article. These trace messages can then be written out using trace listeners such as the ''TextWriterTraceListener'' configured here.

<pre><system.diagnostics>
<trace autoflush="true">
<listeners>
<add name="EventTracer"
type="System.Diagnostics.TextWriterTraceListener, System, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
initializeData="<app root directory>\eventtrace.log" />
</listeners>
</trace>
</system.diagnostics></pre>

One benefit to using System.Diagnostics Tracing in your code is that most logging frameworks already support including these events and writing them to a variety of output types.

For detailed security guidance specific to logging see [[Reviewing Code for Logging Issues]].

===Application Level===
The following code example shows how to create an error handler in the Global.asax.cs file that will catch and log all unhandled ASP.NET errors at the application level. Unhandled exceptions must be logged within ''Application_Error'' rather than in a subsequent page defined by ''<customErrors>'', because the exception details are only available at this point.

<pre>void Application_Error(object sender, EventArgs e)
{
// Get the exception object.
var exception = Server.GetLastError();

// Log exception details. Be sure to include items like client IP
// address and current authenticated user if applicable.
System.Diagnostics.Trace.TraceError(exception.ToString());
}</pre>

===Server.ClearError===
Use the ''Server.ClearError()'' method with caution when handling exceptions. This method will clear the exception state and allow execution to continue rather than displaying an error message to the end user. There are valid scenarios where this is needed, but in general you should avoid this as it could allow a malicious user to bypass security controls if they are somehow able to force an error condition.

===ASP.NET Web Forms===
ASP.NET web form pages provide the ability to capture exceptions at the page level in a similar fashion to the application level. This may be useful if you need to perform failure handling logic or log additional detail unique to the page.

<pre>void Page_Error(object sender, EventArgs e)
{
// Get the exception object.
var exception = Server.GetLastError();

// Log exception details. Be sure to include items like client IP
// address and current authenticated user if applicable.
System.Diagnostics.Trace.TraceError(exception.ToString());
}</pre>

===ASP.NET MVC===
The MVC Controller class provides an ''OnException'' method similar to the ''Page_Error'' method in ASP.NET Web Forms. It allows you to process all unhandled exceptions thrown by actions of the controller. One option for implementing exception logging is to create a base controller class and defining the ''OnException'' method in this one central location.

<pre>protected override void OnException(ExceptionContext filterContext)
{
base.OnException(filterContext);
System.Diagnostics.Trace.TraceError(filterContext.Exception.ToString());
}</pre>

A second (and arguably better) approach is to utilize the ''System.Web.Mvc.HandleErrorAttribute'' which can be used to handle exceptions at the application, controller, or action level. To apply this at the application level you add an instance of ''HandleErrorAttribute'' to the ''GlobalFilterCollection'' at application startup. This takes affect before the ''Application_Error'' method in Global.asax.cs, and by default will redirect to the ''Error'' view in the ~/Views/Shared folder. This will bypass any custom error pages defined via the ''<customErrors>'' element in web.config.

<pre>public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new HandleErrorAttribute());
}</pre>

You can log the exception details right within the ''Error.cshtml'' view using properties from the view model which is of type ''System.Web.Mvc.HandleErrorInfo''.

<pre>@model System.Web.Mvc.HandleErrorInfo

@{
ViewBag.Title = "Error";

// Log exception details
System.Diagnostics.Trace.TraceError(Model.Exception.ToString());
}

<h1 class="text-danger">Error.</h1>
<h2 class="text-danger">An error occurred while processing your request.</h2></pre>

===ASP.NET Web API===
When handling exceptions for your API endpoints you generally want to return a JSON or XML response rather than redirect to an HTML page. ASP.NET Web API provides exception filters to customize how exceptions are handled. A good way of adding exception logging is to derive your own class from ''System.Web.Http.Filters.ExceptionFilterAttribute'' and override the ''OnException'' method as shown.

<pre>public class LogExceptionFilterAttribute : ExceptionFilterAttribute
{
public override void OnException(HttpActionExecutedContext context)
{
System.Diagnostics.Trace.TraceError(context.Exception.ToString());
base.OnException(context);
}
}</pre>

You can apply the ''[LogExceptionFilter]'' attribute to any ''ApiController'', or add it at a global level using the following code at application startup.

<pre>System.Web.Http.GlobalConfiguration.Configuration.Filters.Add(new LogExceptionFilterAttribute());</pre>

===Web API Global Error Handling (Added in Web API 2.1)===
There are a number of cases in Web API where an exception can occur that falls outside of what exception filters can handle. These include exceptions in controller construction, message handlers, routing, and response content serialization. To handle these exceptions you will need to register a class that implements the ''IExceptionLogger'' interface, or derives from the ''ExceptionLogger'' base class.

<pre>public interface IExceptionLogger
{
Task LogAsync(ExceptionLoggerContext context, CancellationToken cancellationToken);
}</pre>

You then register your class at application startup to ensure that all exceptions raised during a Web API request life cycle are captured and logged.

<pre>System.Web.Http.GlobalConfiguration.Services.Add(typeof(IExceptionLogger), new MyExceptionLogger());</pre>

==Logging Sensitive Data==
Be careful when logging exception details that you do not inadvertently expose sensitive data to a logging system or external reports that may have relaxed access controls compared to the primary system. For example if a ''SqlException'' is thrown and the details contain a connection string, you may want to mask the password attribute before logging the event. Use care when logging exception details that may contain the following types of data:

*Passwords
*Authentication tokens
*Personally identifiable information (PII)
*Personal health information (PHI)
*Credit card data

==References==
*[http://www.asp.net/web-forms/tutorials/deployment/deploying-web-site-projects/displaying-a-custom-error-page-cs Displaying a Custom Error Page]
*[http://msdn.microsoft.com/en-us/library/h0hfz6fc(v=vs.100).aspx customErrors Element (ASP.NET Settings Schema)]
*[http://msdn.microsoft.com/en-us/library/system.diagnostics.trace(v=vs.110).aspx Trace Class]
*[http://msdn.microsoft.com/en-us/library/ed577840(v=vs.100).aspx How to: Handle Page-Level Errors]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.controller.onexception(v=vs.118).aspx Controller.OnException Method]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.handleerrorattribute(v=vs.118).aspx HandleErrorAtttribute Class]
*[http://www.asp.net/web-api/overview/testing-and-debugging/exception-handling Exception Handling in ASP.NET Web API]
*[http://www.asp.net/web-api/overview/testing-and-debugging/web-api-global-error-handling Web API 2 .1 Global Error Handling]

[[Category:OWASP .NET Project]][[Category:Stub]]

Exception Handling

2014-10-03T15:41:57Z

Bricex: /* Displaying Errors */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
An exception is any error condition or unexpected behavior that is encountered by your application. There are several key security concerns to be aware of when handling exceptions in .NET web applications:
*Preventing system information leakage that could aid a malicious user.
*Ensuring the application fails securely under all circumstances, both expected and not expected.
*Using a centralized error strategy to reduce points of failure and promote consistency.
*Log when exceptions are thrown and include sufficient detail for security auditing.

==Displaying Errors==
When your application displays error messages, it should not give away information that a malicious user might find helpful in attacking your system. For example, if your application fails while attempting to connect to a database, it should not display an error message that includes the connection string being used.

The default display mechanism for unhandled exceptions in ASP.NET is controlled via the ''<customErrors>'' element in the web.config file. This element includes a ''mode'' attribute that can be set to: ''Off'', ''On'', or ''RemoteOnly''. This mode setting should never be set to ''Off'' in a production environment because it will cause exception details to be displayed to the end user which may include sensitive information about the system.

<pre><customErrors mode="RemoteOnly" defaultRedirect="/Error">
<error statusCode="404" redirect="/Error?id=404" />
<error statusCode="403" redirect="/Error?id=403" />
</customErrors></pre>

===HTTP Status Codes===
When reviewing error responses be careful that a malicious user is not able to glean any potentially sensitive information about the system from the status code returned. For example: an API search that takes a tenant ID parameter and returns an HTTP 404 response for no results, and an HTTP 500 response if the tenant ID does not exist. An attacker could potentially leverage this information to determine if a tenant ID is valid or not. One solution would be to catch the exception thrown when a supplied tenant ID does not exist, and return an HTTP 404 status code with the error response.

==Logging Exception Details==
There are a variety of places within a typical web application where exceptions can be caught and logged. Ideally, you should handle exceptions in as many of the locations described in this section that are applicable to your application. You can use several methods to log exception events, including popular third party libraries: log4net, nlog, Common.Logging, etc. An out-of-the-box solution included with .NET is System.Diagnostics Tracing as shown in the code examples in this article. These trace messages can then be written out using ''trace listeners'' such as the TextWriterTraceListener configured here.

<pre><system.diagnostics>
<trace autoflush="true">
<listeners>
<add name="EventTracer"
type="System.Diagnostics.TextWriterTraceListener, System, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
initializeData="<app root directory>\eventtrace.log" />
</listeners>
</trace>
</system.diagnostics></pre>

One benefit to using System.Diagnostics Tracing in your code is that most logging frameworks already support including these events and writing them to a variety of output types.

For detailed security guidance specific to logging see [[Reviewing Code for Logging Issues]].

===Application Level===
The following code example shows how to create an error handler in the Global.asax.cs file that will catch and log all unhandled ASP.NET errors at the application level. Unhandled exceptions must be logged within ''Application_Error'' rather than in a subsequent page defined by ''<customErrors>'', because the exception details are only available at this point.

<pre>void Application_Error(object sender, EventArgs e)
{
// Get the exception object.
var exception = Server.GetLastError();

// Log exception details. Be sure to include items like client IP
// address and current authenticated user if applicable.
System.Diagnostics.Trace.TraceError(exception.ToString());
}</pre>

===Server.ClearError===
Use the ''Server.ClearError()'' method with caution when handling exceptions. This method will clear the exception state and allow execution to continue rather than displaying an error message to the end user. There are valid scenarios where this is needed, but in general you should avoid this as it could allow a malicious user to bypass security controls if they are somehow able to force an error condition.

===ASP.NET Web Forms===
ASP.NET web form pages provide the ability to capture exceptions at the page level in a similar fashion to the application level. This may be useful if you need to perform failure handling logic or log additional detail unique to the page.

<pre>void Page_Error(object sender, EventArgs e)
{
// Get the exception object.
var exception = Server.GetLastError();

// Log exception details. Be sure to include items like client IP
// address and current authenticated user if applicable.
System.Diagnostics.Trace.TraceError(exception.ToString());
}</pre>

===ASP.NET MVC===
The MVC Controller class provides an ''OnException'' method similar to the ''Page_Error'' method in ASP.NET Web Forms. It allows you to process all unhandled exceptions thrown by actions of the controller. One option for implementing exception logging is to create a base controller class and defining the ''OnException'' method in this one central location.

<pre>protected override void OnException(ExceptionContext filterContext)
{
base.OnException(filterContext);
System.Diagnostics.Trace.TraceError(filterContext.Exception.ToString());
}</pre>

A second (and arguably better) approach is to utilize the ''System.Web.Mvc.HandleErrorAttribute'' which can be used to handle exceptions at the application, controller, or action level. To apply this at the application level you add an instance of ''HandleErrorAttribute'' to the ''GlobalFilterCollection'' at application startup. This takes affect before the ''Application_Error'' method in Global.asax.cs, and by default will redirect to the ''Error'' view in the ~/Views/Shared folder. This will bypass any custom error pages defined via the ''<customErrors>'' element in web.config.

<pre>public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new HandleErrorAttribute());
}</pre>

You can log the exception details right within the ''Error.cshtml'' view using properties from the view model which is of type ''System.Web.Mvc.HandleErrorInfo''.

<pre>@model System.Web.Mvc.HandleErrorInfo

@{
ViewBag.Title = "Error";

// Log exception details
System.Diagnostics.Trace.TraceError(Model.Exception.ToString());
}

<h1 class="text-danger">Error.</h1>
<h2 class="text-danger">An error occurred while processing your request.</h2></pre>

===ASP.NET Web API===
When handling exceptions for your API endpoints you generally want to return a JSON or XML response rather than redirect to an HTML page. ASP.NET Web API provides exception filters to customize how exceptions are handled. A good way of adding exception logging is to derive your own class from ''System.Web.Http.Filters.ExceptionFilterAttribute'' and override the ''OnException'' method as shown.

<pre>public class LogExceptionFilterAttribute : ExceptionFilterAttribute
{
public override void OnException(HttpActionExecutedContext context)
{
System.Diagnostics.Trace.TraceError(context.Exception.ToString());
base.OnException(context);
}
}</pre>

You can apply the ''[LogExceptionFilter]'' attribute to any ''ApiController'', or add it at a global level using the following code at application startup.

<pre>System.Web.Http.GlobalConfiguration.Configuration.Filters.Add(new LogExceptionFilterAttribute());</pre>

===Web API Global Error Handling (Added in Web API 2.1)===
There are a number of cases in Web API where an exception can occur that falls outside of what exception filters can handle. These include exceptions in controller construction, message handlers, routing, and response content serialization. To handle these exceptions you will need to register a class that implements the ''IExceptionLogger'' interface, or derives from the ''ExceptionLogger'' base class.

<pre>public interface IExceptionLogger
{
Task LogAsync(ExceptionLoggerContext context, CancellationToken cancellationToken);
}</pre>

You then register your class at application startup to ensure that all exceptions raised during a Web API request life cycle are captured and logged.

<pre>System.Web.Http.GlobalConfiguration.Services.Add(typeof(IExceptionLogger), new MyExceptionLogger());</pre>

==Logging Sensitive Data==
Be careful when logging exception details that you do not inadvertently expose sensitive data to a logging system or external reports that may have relaxed access controls compared to the primary system. For example if a ''SqlException'' is thrown and the details contain a connection string, you may want to mask the password attribute before logging the event. Use care when logging exception details that may contain the following types of data:

*Passwords
*Authentication tokens
*Personally identifiable information (PII)
*Personal health information (PHI)
*Credit card data

==References==
*[http://www.asp.net/web-forms/tutorials/deployment/deploying-web-site-projects/displaying-a-custom-error-page-cs Displaying a Custom Error Page]
*[http://msdn.microsoft.com/en-us/library/h0hfz6fc(v=vs.100).aspx customErrors Element (ASP.NET Settings Schema)]
*[http://msdn.microsoft.com/en-us/library/system.diagnostics.trace(v=vs.110).aspx Trace Class]
*[http://msdn.microsoft.com/en-us/library/ed577840(v=vs.100).aspx How to: Handle Page-Level Errors]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.controller.onexception(v=vs.118).aspx Controller.OnException Method]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.handleerrorattribute(v=vs.118).aspx HandleErrorAtttribute Class]
*[http://www.asp.net/web-api/overview/testing-and-debugging/exception-handling Exception Handling in ASP.NET Web API]
*[http://www.asp.net/web-api/overview/testing-and-debugging/web-api-global-error-handling Web API 2 .1 Global Error Handling]

[[Category:OWASP .NET Project]][[Category:Stub]]

Exception Handling

2014-10-03T15:39:30Z

Bricex: /* References */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
An exception is any error condition or unexpected behavior that is encountered by your application. There are several key security concerns to be aware of when handling exceptions in .NET web applications:
*Preventing system information leakage that could aid a malicious user.
*Ensuring the application fails securely under all circumstances, both expected and not expected.
*Using a centralized error strategy to reduce points of failure and promote consistency.
*Log when exceptions are thrown and include sufficient detail for security auditing.

==Displaying Errors==
When your application displays error messages, it should not give away information that a malicious user might find helpful in attacking your system. For example, if your application unsuccessfully tries to log in to a database, it should not display an error message that includes the connection string being used.

The default display mechanism for unhandled exceptions in ASP.NET is controlled via the ''<customErrors>'' element in the web.config file. This element includes a ''mode'' attribute that can be set to: ''Off'', ''On'', or ''RemoteOnly''. This mode setting should never be set to ''Off'' in a production environment because it will cause exception details to be displayed to the end user which may include sensitive information about the system.

<pre><customErrors mode="RemoteOnly" defaultRedirect="/Error">
<error statusCode="404" redirect="/Error?id=404" />
<error statusCode="403" redirect="/Error?id=403" />
</customErrors></pre>

===HTTP Status Codes===
When reviewing error responses be careful that a malicious user is not able to glean any potentially sensitive information about the system from the status code returned. For example: an API search that takes a tenant ID parameter and returns an HTTP 404 response for no results, and an HTTP 500 response if the tenant ID does not exist. An attacker could potentially leverage this information to determine if a tenant ID is valid or not. One solution would be to catch the exception thrown when a supplied tenant ID does not exist, and return an HTTP 404 status code with the error response.

==Logging Exception Details==
There are a variety of places within a typical web application where exceptions can be caught and logged. Ideally, you should handle exceptions in as many of the locations described in this section that are applicable to your application. You can use several methods to log exception events, including popular third party libraries: log4net, nlog, Common.Logging, etc. An out-of-the-box solution included with .NET is System.Diagnostics Tracing as shown in the code examples in this article. These trace messages can then be written out using ''trace listeners'' such as the TextWriterTraceListener configured here.

<pre><system.diagnostics>
<trace autoflush="true">
<listeners>
<add name="EventTracer"
type="System.Diagnostics.TextWriterTraceListener, System, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
initializeData="<app root directory>\eventtrace.log" />
</listeners>
</trace>
</system.diagnostics></pre>

One benefit to using System.Diagnostics Tracing in your code is that most logging frameworks already support including these events and writing them to a variety of output types.

For detailed security guidance specific to logging see [[Reviewing Code for Logging Issues]].

===Application Level===
The following code example shows how to create an error handler in the Global.asax.cs file that will catch and log all unhandled ASP.NET errors at the application level. Unhandled exceptions must be logged within ''Application_Error'' rather than in a subsequent page defined by ''<customErrors>'', because the exception details are only available at this point.

<pre>void Application_Error(object sender, EventArgs e)
{
// Get the exception object.
var exception = Server.GetLastError();

// Log exception details. Be sure to include items like client IP
// address and current authenticated user if applicable.
System.Diagnostics.Trace.TraceError(exception.ToString());
}</pre>

===Server.ClearError===
Use the ''Server.ClearError()'' method with caution when handling exceptions. This method will clear the exception state and allow execution to continue rather than displaying an error message to the end user. There are valid scenarios where this is needed, but in general you should avoid this as it could allow a malicious user to bypass security controls if they are somehow able to force an error condition.

===ASP.NET Web Forms===
ASP.NET web form pages provide the ability to capture exceptions at the page level in a similar fashion to the application level. This may be useful if you need to perform failure handling logic or log additional detail unique to the page.

<pre>void Page_Error(object sender, EventArgs e)
{
// Get the exception object.
var exception = Server.GetLastError();

// Log exception details. Be sure to include items like client IP
// address and current authenticated user if applicable.
System.Diagnostics.Trace.TraceError(exception.ToString());
}</pre>

===ASP.NET MVC===
The MVC Controller class provides an ''OnException'' method similar to the ''Page_Error'' method in ASP.NET Web Forms. It allows you to process all unhandled exceptions thrown by actions of the controller. One option for implementing exception logging is to create a base controller class and defining the ''OnException'' method in this one central location.

<pre>protected override void OnException(ExceptionContext filterContext)
{
base.OnException(filterContext);
System.Diagnostics.Trace.TraceError(filterContext.Exception.ToString());
}</pre>

A second (and arguably better) approach is to utilize the ''System.Web.Mvc.HandleErrorAttribute'' which can be used to handle exceptions at the application, controller, or action level. To apply this at the application level you add an instance of ''HandleErrorAttribute'' to the ''GlobalFilterCollection'' at application startup. This takes affect before the ''Application_Error'' method in Global.asax.cs, and by default will redirect to the ''Error'' view in the ~/Views/Shared folder. This will bypass any custom error pages defined via the ''<customErrors>'' element in web.config.

<pre>public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new HandleErrorAttribute());
}</pre>

You can log the exception details right within the ''Error.cshtml'' view using properties from the view model which is of type ''System.Web.Mvc.HandleErrorInfo''.

<pre>@model System.Web.Mvc.HandleErrorInfo

@{
ViewBag.Title = "Error";

// Log exception details
System.Diagnostics.Trace.TraceError(Model.Exception.ToString());
}

<h1 class="text-danger">Error.</h1>
<h2 class="text-danger">An error occurred while processing your request.</h2></pre>

===ASP.NET Web API===
When handling exceptions for your API endpoints you generally want to return a JSON or XML response rather than redirect to an HTML page. ASP.NET Web API provides exception filters to customize how exceptions are handled. A good way of adding exception logging is to derive your own class from ''System.Web.Http.Filters.ExceptionFilterAttribute'' and override the ''OnException'' method as shown.

<pre>public class LogExceptionFilterAttribute : ExceptionFilterAttribute
{
public override void OnException(HttpActionExecutedContext context)
{
System.Diagnostics.Trace.TraceError(context.Exception.ToString());
base.OnException(context);
}
}</pre>

You can apply the ''[LogExceptionFilter]'' attribute to any ''ApiController'', or add it at a global level using the following code at application startup.

<pre>System.Web.Http.GlobalConfiguration.Configuration.Filters.Add(new LogExceptionFilterAttribute());</pre>

===Web API Global Error Handling (Added in Web API 2.1)===
There are a number of cases in Web API where an exception can occur that falls outside of what exception filters can handle. These include exceptions in controller construction, message handlers, routing, and response content serialization. To handle these exceptions you will need to register a class that implements the ''IExceptionLogger'' interface, or derives from the ''ExceptionLogger'' base class.

<pre>public interface IExceptionLogger
{
Task LogAsync(ExceptionLoggerContext context, CancellationToken cancellationToken);
}</pre>

You then register your class at application startup to ensure that all exceptions raised during a Web API request life cycle are captured and logged.

<pre>System.Web.Http.GlobalConfiguration.Services.Add(typeof(IExceptionLogger), new MyExceptionLogger());</pre>

==Logging Sensitive Data==
Be careful when logging exception details that you do not inadvertently expose sensitive data to a logging system or external reports that may have relaxed access controls compared to the primary system. For example if a ''SqlException'' is thrown and the details contain a connection string, you may want to mask the password attribute before logging the event. Use care when logging exception details that may contain the following types of data:

*Passwords
*Authentication tokens
*Personally identifiable information (PII)
*Personal health information (PHI)
*Credit card data

==References==
*[http://www.asp.net/web-forms/tutorials/deployment/deploying-web-site-projects/displaying-a-custom-error-page-cs Displaying a Custom Error Page]
*[http://msdn.microsoft.com/en-us/library/h0hfz6fc(v=vs.100).aspx customErrors Element (ASP.NET Settings Schema)]
*[http://msdn.microsoft.com/en-us/library/system.diagnostics.trace(v=vs.110).aspx Trace Class]
*[http://msdn.microsoft.com/en-us/library/ed577840(v=vs.100).aspx How to: Handle Page-Level Errors]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.controller.onexception(v=vs.118).aspx Controller.OnException Method]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.handleerrorattribute(v=vs.118).aspx HandleErrorAtttribute Class]
*[http://www.asp.net/web-api/overview/testing-and-debugging/exception-handling Exception Handling in ASP.NET Web API]
*[http://www.asp.net/web-api/overview/testing-and-debugging/web-api-global-error-handling Web API 2 .1 Global Error Handling]

[[Category:OWASP .NET Project]][[Category:Stub]]

Exception Handling

2014-10-03T15:36:28Z

Bricex: /* Logging Exception Details */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
An exception is any error condition or unexpected behavior that is encountered by your application. There are several key security concerns to be aware of when handling exceptions in .NET web applications:
*Preventing system information leakage that could aid a malicious user.
*Ensuring the application fails securely under all circumstances, both expected and not expected.
*Using a centralized error strategy to reduce points of failure and promote consistency.
*Log when exceptions are thrown and include sufficient detail for security auditing.

==Displaying Errors==
When your application displays error messages, it should not give away information that a malicious user might find helpful in attacking your system. For example, if your application unsuccessfully tries to log in to a database, it should not display an error message that includes the connection string being used.

The default display mechanism for unhandled exceptions in ASP.NET is controlled via the ''<customErrors>'' element in the web.config file. This element includes a ''mode'' attribute that can be set to: ''Off'', ''On'', or ''RemoteOnly''. This mode setting should never be set to ''Off'' in a production environment because it will cause exception details to be displayed to the end user which may include sensitive information about the system.

<pre><customErrors mode="RemoteOnly" defaultRedirect="/Error">
<error statusCode="404" redirect="/Error?id=404" />
<error statusCode="403" redirect="/Error?id=403" />
</customErrors></pre>

===HTTP Status Codes===
When reviewing error responses be careful that a malicious user is not able to glean any potentially sensitive information about the system from the status code returned. For example: an API search that takes a tenant ID parameter and returns an HTTP 404 response for no results, and an HTTP 500 response if the tenant ID does not exist. An attacker could potentially leverage this information to determine if a tenant ID is valid or not. One solution would be to catch the exception thrown when a supplied tenant ID does not exist, and return an HTTP 404 status code with the error response.

==Logging Exception Details==
There are a variety of places within a typical web application where exceptions can be caught and logged. Ideally, you should handle exceptions in as many of the locations described in this section that are applicable to your application. You can use several methods to log exception events, including popular third party libraries: log4net, nlog, Common.Logging, etc. An out-of-the-box solution included with .NET is System.Diagnostics Tracing as shown in the code examples in this article. These trace messages can then be written out using ''trace listeners'' such as the TextWriterTraceListener configured here.

<pre><system.diagnostics>
<trace autoflush="true">
<listeners>
<add name="EventTracer"
type="System.Diagnostics.TextWriterTraceListener, System, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
initializeData="<app root directory>\eventtrace.log" />
</listeners>
</trace>
</system.diagnostics></pre>

One benefit to using System.Diagnostics Tracing in your code is that most logging frameworks already support including these events and writing them to a variety of output types.

For detailed security guidance specific to logging see [[Reviewing Code for Logging Issues]].

===Application Level===
The following code example shows how to create an error handler in the Global.asax.cs file that will catch and log all unhandled ASP.NET errors at the application level. Unhandled exceptions must be logged within ''Application_Error'' rather than in a subsequent page defined by ''<customErrors>'', because the exception details are only available at this point.

<pre>void Application_Error(object sender, EventArgs e)
{
// Get the exception object.
var exception = Server.GetLastError();

// Log exception details. Be sure to include items like client IP
// address and current authenticated user if applicable.
System.Diagnostics.Trace.TraceError(exception.ToString());
}</pre>

===Server.ClearError===
Use the ''Server.ClearError()'' method with caution when handling exceptions. This method will clear the exception state and allow execution to continue rather than displaying an error message to the end user. There are valid scenarios where this is needed, but in general you should avoid this as it could allow a malicious user to bypass security controls if they are somehow able to force an error condition.

===ASP.NET Web Forms===
ASP.NET web form pages provide the ability to capture exceptions at the page level in a similar fashion to the application level. This may be useful if you need to perform failure handling logic or log additional detail unique to the page.

<pre>void Page_Error(object sender, EventArgs e)
{
// Get the exception object.
var exception = Server.GetLastError();

// Log exception details. Be sure to include items like client IP
// address and current authenticated user if applicable.
System.Diagnostics.Trace.TraceError(exception.ToString());
}</pre>

===ASP.NET MVC===
The MVC Controller class provides an ''OnException'' method similar to the ''Page_Error'' method in ASP.NET Web Forms. It allows you to process all unhandled exceptions thrown by actions of the controller. One option for implementing exception logging is to create a base controller class and defining the ''OnException'' method in this one central location.

<pre>protected override void OnException(ExceptionContext filterContext)
{
base.OnException(filterContext);
System.Diagnostics.Trace.TraceError(filterContext.Exception.ToString());
}</pre>

A second (and arguably better) approach is to utilize the ''System.Web.Mvc.HandleErrorAttribute'' which can be used to handle exceptions at the application, controller, or action level. To apply this at the application level you add an instance of ''HandleErrorAttribute'' to the ''GlobalFilterCollection'' at application startup. This takes affect before the ''Application_Error'' method in Global.asax.cs, and by default will redirect to the ''Error'' view in the ~/Views/Shared folder. This will bypass any custom error pages defined via the ''<customErrors>'' element in web.config.

<pre>public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new HandleErrorAttribute());
}</pre>

You can log the exception details right within the ''Error.cshtml'' view using properties from the view model which is of type ''System.Web.Mvc.HandleErrorInfo''.

<pre>@model System.Web.Mvc.HandleErrorInfo

@{
ViewBag.Title = "Error";

// Log exception details
System.Diagnostics.Trace.TraceError(Model.Exception.ToString());
}

<h1 class="text-danger">Error.</h1>
<h2 class="text-danger">An error occurred while processing your request.</h2></pre>

===ASP.NET Web API===
When handling exceptions for your API endpoints you generally want to return a JSON or XML response rather than redirect to an HTML page. ASP.NET Web API provides exception filters to customize how exceptions are handled. A good way of adding exception logging is to derive your own class from ''System.Web.Http.Filters.ExceptionFilterAttribute'' and override the ''OnException'' method as shown.

<pre>public class LogExceptionFilterAttribute : ExceptionFilterAttribute
{
public override void OnException(HttpActionExecutedContext context)
{
System.Diagnostics.Trace.TraceError(context.Exception.ToString());
base.OnException(context);
}
}</pre>

You can apply the ''[LogExceptionFilter]'' attribute to any ''ApiController'', or add it at a global level using the following code at application startup.

<pre>System.Web.Http.GlobalConfiguration.Configuration.Filters.Add(new LogExceptionFilterAttribute());</pre>

===Web API Global Error Handling (Added in Web API 2.1)===
There are a number of cases in Web API where an exception can occur that falls outside of what exception filters can handle. These include exceptions in controller construction, message handlers, routing, and response content serialization. To handle these exceptions you will need to register a class that implements the ''IExceptionLogger'' interface, or derives from the ''ExceptionLogger'' base class.

<pre>public interface IExceptionLogger
{
Task LogAsync(ExceptionLoggerContext context, CancellationToken cancellationToken);
}</pre>

You then register your class at application startup to ensure that all exceptions raised during a Web API request life cycle are captured and logged.

<pre>System.Web.Http.GlobalConfiguration.Services.Add(typeof(IExceptionLogger), new MyExceptionLogger());</pre>

==Logging Sensitive Data==
Be careful when logging exception details that you do not inadvertently expose sensitive data to a logging system or external reports that may have relaxed access controls compared to the primary system. For example if a ''SqlException'' is thrown and the details contain a connection string, you may want to mask the password attribute before logging the event. Use care when logging exception details that may contain the following types of data:

*Passwords
*Authentication tokens
*Personally identifiable information (PII)
*Personal health information (PHI)
*Credit card data

==References==
*[http://www.asp.net/web-forms/tutorials/deployment/deploying-web-site-projects/displaying-a-custom-error-page-cs Displaying a Custom Error Page]
*[http://msdn.microsoft.com/en-us/library/h0hfz6fc(v=vs.100).aspx customErrors Element (ASP.NET Settings Schema)]
*[http://msdn.microsoft.com/en-us/library/ed577840(v=vs.100).aspx How to: Handle Page-Level Errors]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.controller.onexception(v=vs.118).aspx Controller.OnException Method]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.handleerrorattribute(v=vs.118).aspx HandleErrorAtttribute Class]
*[http://www.asp.net/web-api/overview/testing-and-debugging/exception-handling Exception Handling in ASP.NET Web API]
*[http://www.asp.net/web-api/overview/testing-and-debugging/web-api-global-error-handling Web API 2 .1 Global Error Handling]

[[Category:OWASP .NET Project]][[Category:Stub]]

Exception Handling

2014-10-03T14:34:00Z

Bricex: Include warning on use of Server.ClearError

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
An exception is any error condition or unexpected behavior that is encountered by your application. There are several key security concerns to be aware of when handling exceptions in .NET web applications:
*Preventing system information leakage that could aid a malicious user.
*Ensuring the application fails securely under all circumstances, both expected and not expected.
*Using a centralized error strategy to reduce points of failure and promote consistency.
*Log when exceptions are thrown and include sufficient detail for security auditing.

==Displaying Errors==
When your application displays error messages, it should not give away information that a malicious user might find helpful in attacking your system. For example, if your application unsuccessfully tries to log in to a database, it should not display an error message that includes the connection string being used.

The default display mechanism for unhandled exceptions in ASP.NET is controlled via the ''<customErrors>'' element in the web.config file. This element includes a ''mode'' attribute that can be set to: ''Off'', ''On'', or ''RemoteOnly''. This mode setting should never be set to ''Off'' in a production environment because it will cause exception details to be displayed to the end user which may include sensitive information about the system.

<pre><customErrors mode="RemoteOnly" defaultRedirect="/Error">
<error statusCode="404" redirect="/Error?id=404" />
<error statusCode="403" redirect="/Error?id=403" />
</customErrors></pre>

===HTTP Status Codes===
When reviewing error responses be careful that a malicious user is not able to glean any potentially sensitive information about the system from the status code returned. For example: an API search that takes a tenant ID parameter and returns an HTTP 404 response for no results, and an HTTP 500 response if the tenant ID does not exist. An attacker could potentially leverage this information to determine if a tenant ID is valid or not. One solution would be to catch the exception thrown when a supplied tenant ID does not exist, and return an HTTP 404 status code with the error response.

==Logging Exception Details==
There are a variety of places within a typical web application where exceptions can be caught and logged. Ideally, you should handle exceptions in as many of the locations described below as are applicable to your application.

===Application Level===
The following code example shows how to create an error handler in the Global.asax.cs file that will catch and log all unhandled ASP.NET errors at the application level. Unhandled exceptions must be logged within ''Application_Error'' rather than in a subsequent page defined by ''<customErrors>'', because the exception details are only available at this point.

<pre>void Application_Error(object sender, EventArgs e)
{
// Get the exception object.
var exception = Server.GetLastError();

// Log exception details. Be sure to include items like client IP
// address and current authenticated user if applicable.
System.Diagnostics.Trace.TraceError(exception.ToString());
}</pre>

===Server.ClearError===
Use the ''Server.ClearError()'' method with caution when handling exceptions. This method will clear the exception state and allow execution to continue rather than displaying an error message to the end user. There are valid scenarios where this is needed, but in general you should avoid this as it could allow a malicious user to bypass security controls if they are somehow able to force an error condition.

===ASP.NET Web Forms===
ASP.NET web form pages provide the ability to capture exceptions at the page level in a similar fashion to the application level. This may be useful if you need to perform failure handling logic or log additional detail unique to the page.

<pre>void Page_Error(object sender, EventArgs e)
{
// Get the exception object.
var exception = Server.GetLastError();

// Log exception details. Be sure to include items like client IP
// address and current authenticated user if applicable.
System.Diagnostics.Trace.TraceError(exception.ToString());
}</pre>

===ASP.NET MVC===
The MVC Controller class provides an ''OnException'' method similar to the ''Page_Error'' method in ASP.NET Web Forms. It allows you to process all unhandled exceptions thrown by actions of the controller. One option for implementing exception logging is to create a base controller class and defining the ''OnException'' method in this one central location.

<pre>protected override void OnException(ExceptionContext filterContext)
{
base.OnException(filterContext);
System.Diagnostics.Trace.TraceError(filterContext.Exception.ToString());
}</pre>

A second (and arguably better) approach is to utilize the ''System.Web.Mvc.HandleErrorAttribute'' which can be used to handle exceptions at the application, controller, or action level. To apply this at the application level you add an instance of ''HandleErrorAttribute'' to the ''GlobalFilterCollection'' at application startup. This takes affect before the ''Application_Error'' method in Global.asax.cs, and by default will redirect to the ''Error'' view in the ~/Views/Shared folder. This will bypass any custom error pages defined via the ''<customErrors>'' element in web.config.

<pre>public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new HandleErrorAttribute());
}</pre>

You can log the exception details right within the ''Error.cshtml'' view using properties from the view model which is of type ''System.Web.Mvc.HandleErrorInfo''.

<pre>@model System.Web.Mvc.HandleErrorInfo

@{
ViewBag.Title = "Error";

// Log exception details
System.Diagnostics.Trace.TraceError(Model.Exception.ToString());
}

<h1 class="text-danger">Error.</h1>
<h2 class="text-danger">An error occurred while processing your request.</h2></pre>

===ASP.NET Web API===
When handling exceptions for your API endpoints you generally want to return a JSON or XML response rather than redirect to an HTML page. ASP.NET Web API provides exception filters to customize how exceptions are handled. A good way of adding exception logging is to derive your own class from ''System.Web.Http.Filters.ExceptionFilterAttribute'' and override the ''OnException'' method as shown.

<pre>public class LogExceptionFilterAttribute : ExceptionFilterAttribute
{
public override void OnException(HttpActionExecutedContext context)
{
System.Diagnostics.Trace.TraceError(context.Exception.ToString());
base.OnException(context);
}
}</pre>

You can apply the ''[LogExceptionFilter]'' attribute to any ''ApiController'', or add it at a global level using the following code at application startup.

<pre>System.Web.Http.GlobalConfiguration.Configuration.Filters.Add(new LogExceptionFilterAttribute());</pre>

===Web API Global Error Handling (Added in Web API 2.1)===
There are a number of cases in Web API where an exception can occur that falls outside of what exception filters can handle. These include exceptions in controller construction, message handlers, routing, and response content serialization. To handle these exceptions you will need to register a class that implements the ''IExceptionLogger'' interface, or derives from the ''ExceptionLogger'' base class.

<pre>public interface IExceptionLogger
{
Task LogAsync(ExceptionLoggerContext context, CancellationToken cancellationToken);
}</pre>

You then register your class at application startup to ensure that all exceptions raised during a Web API request life cycle are captured and logged.

<pre>System.Web.Http.GlobalConfiguration.Services.Add(typeof(IExceptionLogger), new MyExceptionLogger());</pre>

==Logging Sensitive Data==
Be careful when logging exception details that you do not inadvertently expose sensitive data to a logging system or external reports that may have relaxed access controls compared to the primary system. For example if a ''SqlException'' is thrown and the details contain a connection string, you may want to mask the password attribute before logging the event. Use care when logging exception details that may contain the following types of data:

*Passwords
*Authentication tokens
*Personally identifiable information (PII)
*Personal health information (PHI)
*Credit card data

==References==
*[http://www.asp.net/web-forms/tutorials/deployment/deploying-web-site-projects/displaying-a-custom-error-page-cs Displaying a Custom Error Page]
*[http://msdn.microsoft.com/en-us/library/h0hfz6fc(v=vs.100).aspx customErrors Element (ASP.NET Settings Schema)]
*[http://msdn.microsoft.com/en-us/library/ed577840(v=vs.100).aspx How to: Handle Page-Level Errors]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.controller.onexception(v=vs.118).aspx Controller.OnException Method]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.handleerrorattribute(v=vs.118).aspx HandleErrorAtttribute Class]
*[http://www.asp.net/web-api/overview/testing-and-debugging/exception-handling Exception Handling in ASP.NET Web API]
*[http://www.asp.net/web-api/overview/testing-and-debugging/web-api-global-error-handling Web API 2 .1 Global Error Handling]

[[Category:OWASP .NET Project]][[Category:Stub]]

Exception Handling

2014-10-02T13:59:48Z

Bricex: /* Application Level */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
An exception is any error condition or unexpected behavior that is encountered by your application. There are several key security concerns to be aware of when handling exceptions in .NET web applications:
*Preventing system information leakage that could aid a malicious user.
*Ensuring the application fails securely under all circumstances, both expected and not expected.
*Using a centralized error strategy to reduce points of failure and promote consistency.
*Log when exceptions are thrown and include sufficient detail for security auditing.

==Displaying Errors==
When your application displays error messages, it should not give away information that a malicious user might find helpful in attacking your system. For example, if your application unsuccessfully tries to log in to a database, it should not display an error message that includes the connection string being used.

The default display mechanism for unhandled exceptions in ASP.NET is controlled via the ''<customErrors>'' element in the web.config file. This element includes a ''mode'' attribute that can be set to: ''Off'', ''On'', or ''RemoteOnly''. This mode setting should never be set to ''Off'' in a production environment because it will cause exception details to be displayed to the end user which may include sensitive information about the system.

<pre><customErrors mode="RemoteOnly" defaultRedirect="/Error">
<error statusCode="404" redirect="/Error?id=404" />
<error statusCode="403" redirect="/Error?id=403" />
</customErrors></pre>

===HTTP Status Codes===
When reviewing error responses be careful that a malicious user is not able to glean any potentially sensitive information about the system from the status code returned. For example: an API search that takes a tenant ID parameter and returns an HTTP 404 response for no results, and an HTTP 500 response if the tenant ID does not exist. An attacker could potentially leverage this information to determine if a tenant ID is valid or not. One solution would be to catch the exception thrown when a supplied tenant ID does not exist, and return an HTTP 404 status code with the error response.

==Logging Exception Details==
There are a variety of places within a typical web application where exceptions can be caught and logged. Ideally, you should handle exceptions in as many of the locations described below as are applicable to your application.

===Application Level===
The following code example shows how to create an error handler in the Global.asax.cs file that will catch and log all unhandled ASP.NET errors at the application level. In this example ''Server.ClearError()'' is not called so that the exception will continue to be processed by the error display mechanism defined by the ''<customErrors>'' element in web.config. Unhandled exceptions must be logged within ''Application_Error'' rather than in a subsequent page defined by ''<customErrors>'', because the exception details are only available at this point.

<pre>void Application_Error(object sender, EventArgs e)
{
// Get the exception object.
var exception = Server.GetLastError();

// Log exception details. Be sure to include items like client IP
// address and current authenticated user if applicable.
System.Diagnostics.Trace.TraceError(exception.ToString());
}</pre>

===ASP.NET Web Forms===
ASP.NET web form pages provide the ability to capture exceptions at the page level in a similar fashion to the application level. This may be useful if you need to perform failure handling logic or log additional detail unique to the page.

<pre>void Page_Error(object sender, EventArgs e)
{
// Get the exception object.
var exception = Server.GetLastError();

// Log exception details. Be sure to include items like client IP
// address and current authenticated user if applicable.
System.Diagnostics.Trace.TraceError(exception.ToString());

// Calling Server.ClearError allows the page to continue processing,
// otherwise control is passed to application level error handling.
Server.ClearError();
}</pre>

===ASP.NET MVC===
The MVC Controller class provides an ''OnException'' method similar to the ''Page_Error'' method in ASP.NET Web Forms. It allows you to process all unhandled exceptions thrown by actions of the controller. One option for implementing exception logging is to create a base controller class and defining the ''OnException'' method in this one central location.

<pre>protected override void OnException(ExceptionContext filterContext)
{
base.OnException(filterContext);
System.Diagnostics.Trace.TraceError(filterContext.Exception.ToString());
}</pre>

A second (and arguably better) approach is to utilize the ''System.Web.Mvc.HandleErrorAttribute'' which can be used to handle exceptions at the application, controller, or action level. To apply this at the application level you add an instance of ''HandleErrorAttribute'' to the ''GlobalFilterCollection'' at application startup. This takes affect before the ''Application_Error'' method in Global.asax.cs, and by default will redirect to the ''Error'' view in the ~/Views/Shared folder. This will bypass any custom error pages defined via the ''<customErrors>'' element in web.config.

<pre>public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new HandleErrorAttribute());
}</pre>

You can log the exception details right within the ''Error.cshtml'' view using properties from the view model which is of type ''System.Web.Mvc.HandleErrorInfo''.

<pre>@model System.Web.Mvc.HandleErrorInfo

@{
ViewBag.Title = "Error";

// Log exception details
System.Diagnostics.Trace.TraceError(Model.Exception.ToString());
}

<h1 class="text-danger">Error.</h1>
<h2 class="text-danger">An error occurred while processing your request.</h2></pre>

===ASP.NET Web API===
When handling exceptions for your API endpoints you generally want to return a JSON or XML response rather than redirect to an HTML page. ASP.NET Web API provides exception filters to customize how exceptions are handled. A good way of adding exception logging is to derive your own class from ''System.Web.Http.Filters.ExceptionFilterAttribute'' and override the ''OnException'' method as shown.

<pre>public class LogExceptionFilterAttribute : ExceptionFilterAttribute
{
public override void OnException(HttpActionExecutedContext context)
{
System.Diagnostics.Trace.TraceError(context.Exception.ToString());
base.OnException(context);
}
}</pre>

You can apply the ''[LogExceptionFilter]'' attribute to any ''ApiController'', or add it at a global level using the following code at application startup.

<pre>System.Web.Http.GlobalConfiguration.Configuration.Filters.Add(new LogExceptionFilterAttribute());</pre>

===Web API Global Error Handling (Added in Web API 2.1)===
There are a number of cases in Web API where an exception can occur that falls outside of what exception filters can handle. These include exceptions in controller construction, message handlers, routing, and response content serialization. To handle these exceptions you will need to register a class that implements the ''IExceptionLogger'' interface, or derives from the ''ExceptionLogger'' base class.

<pre>public interface IExceptionLogger
{
Task LogAsync(ExceptionLoggerContext context, CancellationToken cancellationToken);
}</pre>

You then register your class at application startup to ensure that all exceptions raised during a Web API request life cycle are captured and logged.

<pre>System.Web.Http.GlobalConfiguration.Services.Add(typeof(IExceptionLogger), new MyExceptionLogger());</pre>

==Logging Sensitive Data==
Be careful when logging exception details that you do not inadvertently expose sensitive data to a logging system or external reports that may have relaxed access controls compared to the primary system. For example if a ''SqlException'' is thrown and the details contain a connection string, you may want to mask the password attribute before logging the event. Use care when logging exception details that may contain the following types of data:

*Passwords
*Authentication tokens
*Personally identifiable information (PII)
*Personal health information (PHI)
*Credit card data

==References==
*[http://www.asp.net/web-forms/tutorials/deployment/deploying-web-site-projects/displaying-a-custom-error-page-cs Displaying a Custom Error Page]
*[http://msdn.microsoft.com/en-us/library/h0hfz6fc(v=vs.100).aspx customErrors Element (ASP.NET Settings Schema)]
*[http://msdn.microsoft.com/en-us/library/ed577840(v=vs.100).aspx How to: Handle Page-Level Errors]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.controller.onexception(v=vs.118).aspx Controller.OnException Method]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.handleerrorattribute(v=vs.118).aspx HandleErrorAtttribute Class]
*[http://www.asp.net/web-api/overview/testing-and-debugging/exception-handling Exception Handling in ASP.NET Web API]
*[http://www.asp.net/web-api/overview/testing-and-debugging/web-api-global-error-handling Web API 2 .1 Global Error Handling]

[[Category:OWASP .NET Project]][[Category:Stub]]

Exception Handling

2014-10-02T13:58:23Z

Bricex: /* HTTP Status Codes */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
An exception is any error condition or unexpected behavior that is encountered by your application. There are several key security concerns to be aware of when handling exceptions in .NET web applications:
*Preventing system information leakage that could aid a malicious user.
*Ensuring the application fails securely under all circumstances, both expected and not expected.
*Using a centralized error strategy to reduce points of failure and promote consistency.
*Log when exceptions are thrown and include sufficient detail for security auditing.

==Displaying Errors==
When your application displays error messages, it should not give away information that a malicious user might find helpful in attacking your system. For example, if your application unsuccessfully tries to log in to a database, it should not display an error message that includes the connection string being used.

The default display mechanism for unhandled exceptions in ASP.NET is controlled via the ''<customErrors>'' element in the web.config file. This element includes a ''mode'' attribute that can be set to: ''Off'', ''On'', or ''RemoteOnly''. This mode setting should never be set to ''Off'' in a production environment because it will cause exception details to be displayed to the end user which may include sensitive information about the system.

<pre><customErrors mode="RemoteOnly" defaultRedirect="/Error">
<error statusCode="404" redirect="/Error?id=404" />
<error statusCode="403" redirect="/Error?id=403" />
</customErrors></pre>

===HTTP Status Codes===
When reviewing error responses be careful that a malicious user is not able to glean any potentially sensitive information about the system from the status code returned. For example: an API search that takes a tenant ID parameter and returns an HTTP 404 response for no results, and an HTTP 500 response if the tenant ID does not exist. An attacker could potentially leverage this information to determine if a tenant ID is valid or not. One solution would be to catch the exception thrown when a supplied tenant ID does not exist, and return an HTTP 404 status code with the error response.

==Logging Exception Details==
There are a variety of places within a typical web application where exceptions can be caught and logged. Ideally, you should handle exceptions in as many of the locations described below as are applicable to your application.

===Application Level===
The following code example shows how to create an error handler in the Global.asax file that will catch and log all unhandled ASP.NET errors at the application level. In this example ''Server.ClearError()'' is not called so that the exception will continue to be processed by the error display mechanism defined by the ''<customErrors>'' element in web.config. Unhandled exceptions must be logged within ''Application_Error'' rather than in a subsequent page defined by ''<customErrors>'', because the exception details are only available at this point.

<pre>void Application_Error(object sender, EventArgs e)
{
// Get the exception object.
var exception = Server.GetLastError();

// Log exception details. Be sure to include items like client IP
// address and current authenticated user if applicable.
System.Diagnostics.Trace.TraceError(exception.ToString());
}</pre>

===ASP.NET Web Forms===
ASP.NET web form pages provide the ability to capture exceptions at the page level in a similar fashion to the application level. This may be useful if you need to perform failure handling logic or log additional detail unique to the page.

<pre>void Page_Error(object sender, EventArgs e)
{
// Get the exception object.
var exception = Server.GetLastError();

// Log exception details. Be sure to include items like client IP
// address and current authenticated user if applicable.
System.Diagnostics.Trace.TraceError(exception.ToString());

// Calling Server.ClearError allows the page to continue processing,
// otherwise control is passed to application level error handling.
Server.ClearError();
}</pre>

===ASP.NET MVC===
The MVC Controller class provides an ''OnException'' method similar to the ''Page_Error'' method in ASP.NET Web Forms. It allows you to process all unhandled exceptions thrown by actions of the controller. One option for implementing exception logging is to create a base controller class and defining the ''OnException'' method in this one central location.

<pre>protected override void OnException(ExceptionContext filterContext)
{
base.OnException(filterContext);
System.Diagnostics.Trace.TraceError(filterContext.Exception.ToString());
}</pre>

A second (and arguably better) approach is to utilize the ''System.Web.Mvc.HandleErrorAttribute'' which can be used to handle exceptions at the application, controller, or action level. To apply this at the application level you add an instance of ''HandleErrorAttribute'' to the ''GlobalFilterCollection'' at application startup. This takes affect before the ''Application_Error'' method in Global.asax.cs, and by default will redirect to the ''Error'' view in the ~/Views/Shared folder. This will bypass any custom error pages defined via the ''<customErrors>'' element in web.config.

<pre>public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new HandleErrorAttribute());
}</pre>

You can log the exception details right within the ''Error.cshtml'' view using properties from the view model which is of type ''System.Web.Mvc.HandleErrorInfo''.

<pre>@model System.Web.Mvc.HandleErrorInfo

@{
ViewBag.Title = "Error";

// Log exception details
System.Diagnostics.Trace.TraceError(Model.Exception.ToString());
}

<h1 class="text-danger">Error.</h1>
<h2 class="text-danger">An error occurred while processing your request.</h2></pre>

===ASP.NET Web API===
When handling exceptions for your API endpoints you generally want to return a JSON or XML response rather than redirect to an HTML page. ASP.NET Web API provides exception filters to customize how exceptions are handled. A good way of adding exception logging is to derive your own class from ''System.Web.Http.Filters.ExceptionFilterAttribute'' and override the ''OnException'' method as shown.

<pre>public class LogExceptionFilterAttribute : ExceptionFilterAttribute
{
public override void OnException(HttpActionExecutedContext context)
{
System.Diagnostics.Trace.TraceError(context.Exception.ToString());
base.OnException(context);
}
}</pre>

You can apply the ''[LogExceptionFilter]'' attribute to any ''ApiController'', or add it at a global level using the following code at application startup.

<pre>System.Web.Http.GlobalConfiguration.Configuration.Filters.Add(new LogExceptionFilterAttribute());</pre>

===Web API Global Error Handling (Added in Web API 2.1)===
There are a number of cases in Web API where an exception can occur that falls outside of what exception filters can handle. These include exceptions in controller construction, message handlers, routing, and response content serialization. To handle these exceptions you will need to register a class that implements the ''IExceptionLogger'' interface, or derives from the ''ExceptionLogger'' base class.

<pre>public interface IExceptionLogger
{
Task LogAsync(ExceptionLoggerContext context, CancellationToken cancellationToken);
}</pre>

You then register your class at application startup to ensure that all exceptions raised during a Web API request life cycle are captured and logged.

<pre>System.Web.Http.GlobalConfiguration.Services.Add(typeof(IExceptionLogger), new MyExceptionLogger());</pre>

==Logging Sensitive Data==
Be careful when logging exception details that you do not inadvertently expose sensitive data to a logging system or external reports that may have relaxed access controls compared to the primary system. For example if a ''SqlException'' is thrown and the details contain a connection string, you may want to mask the password attribute before logging the event. Use care when logging exception details that may contain the following types of data:

*Passwords
*Authentication tokens
*Personally identifiable information (PII)
*Personal health information (PHI)
*Credit card data

==References==
*[http://www.asp.net/web-forms/tutorials/deployment/deploying-web-site-projects/displaying-a-custom-error-page-cs Displaying a Custom Error Page]
*[http://msdn.microsoft.com/en-us/library/h0hfz6fc(v=vs.100).aspx customErrors Element (ASP.NET Settings Schema)]
*[http://msdn.microsoft.com/en-us/library/ed577840(v=vs.100).aspx How to: Handle Page-Level Errors]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.controller.onexception(v=vs.118).aspx Controller.OnException Method]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.handleerrorattribute(v=vs.118).aspx HandleErrorAtttribute Class]
*[http://www.asp.net/web-api/overview/testing-and-debugging/exception-handling Exception Handling in ASP.NET Web API]
*[http://www.asp.net/web-api/overview/testing-and-debugging/web-api-global-error-handling Web API 2 .1 Global Error Handling]

[[Category:OWASP .NET Project]][[Category:Stub]]

Exception Handling

2014-10-02T13:51:56Z

Bricex: /* HTTP Status Codes */

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
An exception is any error condition or unexpected behavior that is encountered by your application. There are several key security concerns to be aware of when handling exceptions in .NET web applications:
*Preventing system information leakage that could aid a malicious user.
*Ensuring the application fails securely under all circumstances, both expected and not expected.
*Using a centralized error strategy to reduce points of failure and promote consistency.
*Log when exceptions are thrown and include sufficient detail for security auditing.

==Displaying Errors==
When your application displays error messages, it should not give away information that a malicious user might find helpful in attacking your system. For example, if your application unsuccessfully tries to log in to a database, it should not display an error message that includes the connection string being used.

The default display mechanism for unhandled exceptions in ASP.NET is controlled via the ''<customErrors>'' element in the web.config file. This element includes a ''mode'' attribute that can be set to: ''Off'', ''On'', or ''RemoteOnly''. This mode setting should never be set to ''Off'' in a production environment because it will cause exception details to be displayed to the end user which may include sensitive information about the system.

<pre><customErrors mode="RemoteOnly" defaultRedirect="/Error">
<error statusCode="404" redirect="/Error?id=404" />
<error statusCode="403" redirect="/Error?id=403" />
</customErrors></pre>

===HTTP Status Codes===
When reviewing error responses be careful that a malicious user is not able to glean any potentially sensitive information about the system from the status code returned. For example: an API search that takes a tenant ID parameter and returns a HTTP 404 response for no results, and an HTTP 500 response if the tenant ID does not exist. An attacker could potentially leverage this information to determine if a tenant ID is valid or not. One solution would be to catch the exception thrown when a supplied tenant ID does not exist, and return an HTTP 404 status code with the error response.

==Logging Exception Details==
There are a variety of places within a typical web application where exceptions can be caught and logged. Ideally, you should handle exceptions in as many of the locations described below as are applicable to your application.

===Application Level===
The following code example shows how to create an error handler in the Global.asax file that will catch and log all unhandled ASP.NET errors at the application level. In this example ''Server.ClearError()'' is not called so that the exception will continue to be processed by the error display mechanism defined by the ''<customErrors>'' element in web.config. Unhandled exceptions must be logged within ''Application_Error'' rather than in a subsequent page defined by ''<customErrors>'', because the exception details are only available at this point.

<pre>void Application_Error(object sender, EventArgs e)
{
// Get the exception object.
var exception = Server.GetLastError();

// Log exception details. Be sure to include items like client IP
// address and current authenticated user if applicable.
System.Diagnostics.Trace.TraceError(exception.ToString());
}</pre>

===ASP.NET Web Forms===
ASP.NET web form pages provide the ability to capture exceptions at the page level in a similar fashion to the application level. This may be useful if you need to perform failure handling logic or log additional detail unique to the page.

<pre>void Page_Error(object sender, EventArgs e)
{
// Get the exception object.
var exception = Server.GetLastError();

// Log exception details. Be sure to include items like client IP
// address and current authenticated user if applicable.
System.Diagnostics.Trace.TraceError(exception.ToString());

// Calling Server.ClearError allows the page to continue processing,
// otherwise control is passed to application level error handling.
Server.ClearError();
}</pre>

===ASP.NET MVC===
The MVC Controller class provides an ''OnException'' method similar to the ''Page_Error'' method in ASP.NET Web Forms. It allows you to process all unhandled exceptions thrown by actions of the controller. One option for implementing exception logging is to create a base controller class and defining the ''OnException'' method in this one central location.

<pre>protected override void OnException(ExceptionContext filterContext)
{
base.OnException(filterContext);
System.Diagnostics.Trace.TraceError(filterContext.Exception.ToString());
}</pre>

A second (and arguably better) approach is to utilize the ''System.Web.Mvc.HandleErrorAttribute'' which can be used to handle exceptions at the application, controller, or action level. To apply this at the application level you add an instance of ''HandleErrorAttribute'' to the ''GlobalFilterCollection'' at application startup. This takes affect before the ''Application_Error'' method in Global.asax.cs, and by default will redirect to the ''Error'' view in the ~/Views/Shared folder. This will bypass any custom error pages defined via the ''<customErrors>'' element in web.config.

<pre>public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new HandleErrorAttribute());
}</pre>

You can log the exception details right within the ''Error.cshtml'' view using properties from the view model which is of type ''System.Web.Mvc.HandleErrorInfo''.

<pre>@model System.Web.Mvc.HandleErrorInfo

@{
ViewBag.Title = "Error";

// Log exception details
System.Diagnostics.Trace.TraceError(Model.Exception.ToString());
}

<h1 class="text-danger">Error.</h1>
<h2 class="text-danger">An error occurred while processing your request.</h2></pre>

===ASP.NET Web API===
When handling exceptions for your API endpoints you generally want to return a JSON or XML response rather than redirect to an HTML page. ASP.NET Web API provides exception filters to customize how exceptions are handled. A good way of adding exception logging is to derive your own class from ''System.Web.Http.Filters.ExceptionFilterAttribute'' and override the ''OnException'' method as shown.

<pre>public class LogExceptionFilterAttribute : ExceptionFilterAttribute
{
public override void OnException(HttpActionExecutedContext context)
{
System.Diagnostics.Trace.TraceError(context.Exception.ToString());
base.OnException(context);
}
}</pre>

You can apply the ''[LogExceptionFilter]'' attribute to any ''ApiController'', or add it at a global level using the following code at application startup.

<pre>System.Web.Http.GlobalConfiguration.Configuration.Filters.Add(new LogExceptionFilterAttribute());</pre>

===Web API Global Error Handling (Added in Web API 2.1)===
There are a number of cases in Web API where an exception can occur that falls outside of what exception filters can handle. These include exceptions in controller construction, message handlers, routing, and response content serialization. To handle these exceptions you will need to register a class that implements the ''IExceptionLogger'' interface, or derives from the ''ExceptionLogger'' base class.

<pre>public interface IExceptionLogger
{
Task LogAsync(ExceptionLoggerContext context, CancellationToken cancellationToken);
}</pre>

You then register your class at application startup to ensure that all exceptions raised during a Web API request life cycle are captured and logged.

<pre>System.Web.Http.GlobalConfiguration.Services.Add(typeof(IExceptionLogger), new MyExceptionLogger());</pre>

==Logging Sensitive Data==
Be careful when logging exception details that you do not inadvertently expose sensitive data to a logging system or external reports that may have relaxed access controls compared to the primary system. For example if a ''SqlException'' is thrown and the details contain a connection string, you may want to mask the password attribute before logging the event. Use care when logging exception details that may contain the following types of data:

*Passwords
*Authentication tokens
*Personally identifiable information (PII)
*Personal health information (PHI)
*Credit card data

==References==
*[http://www.asp.net/web-forms/tutorials/deployment/deploying-web-site-projects/displaying-a-custom-error-page-cs Displaying a Custom Error Page]
*[http://msdn.microsoft.com/en-us/library/h0hfz6fc(v=vs.100).aspx customErrors Element (ASP.NET Settings Schema)]
*[http://msdn.microsoft.com/en-us/library/ed577840(v=vs.100).aspx How to: Handle Page-Level Errors]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.controller.onexception(v=vs.118).aspx Controller.OnException Method]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.handleerrorattribute(v=vs.118).aspx HandleErrorAtttribute Class]
*[http://www.asp.net/web-api/overview/testing-and-debugging/exception-handling Exception Handling in ASP.NET Web API]
*[http://www.asp.net/web-api/overview/testing-and-debugging/web-api-global-error-handling Web API 2 .1 Global Error Handling]

[[Category:OWASP .NET Project]][[Category:Stub]]

Exception Handling

2014-10-02T13:50:17Z

Bricex:

= DRAFT DOCUMENT - WORK IN PROGRESS =

==Description==
An exception is any error condition or unexpected behavior that is encountered by your application. There are several key security concerns to be aware of when handling exceptions in .NET web applications:
*Preventing system information leakage that could aid a malicious user.
*Ensuring the application fails securely under all circumstances, both expected and not expected.
*Using a centralized error strategy to reduce points of failure and promote consistency.
*Log when exceptions are thrown and include sufficient detail for security auditing.

==Displaying Errors==
When your application displays error messages, it should not give away information that a malicious user might find helpful in attacking your system. For example, if your application unsuccessfully tries to log in to a database, it should not display an error message that includes the connection string being used.

The default display mechanism for unhandled exceptions in ASP.NET is controlled via the ''<customErrors>'' element in the web.config file. This element includes a ''mode'' attribute that can be set to: ''Off'', ''On'', or ''RemoteOnly''. This mode setting should never be set to ''Off'' in a production environment because it will cause exception details to be displayed to the end user which may include sensitive information about the system.

<pre><customErrors mode="RemoteOnly" defaultRedirect="/Error">
<error statusCode="404" redirect="/Error?id=404" />
<error statusCode="403" redirect="/Error?id=403" />
</customErrors></pre>

===HTTP Status Codes===
When reviewing error responses, be careful that a malicious user is not able to glean any potentially sensitive information about the system from the status code returned. For example: an API search that takes a tenant ID parameter that returns a HTTP 404 response for no results, and an HTTP 500 response if the tenant ID does not exist. An attacker could potentially leverage this information to determine if a tenant ID is valid or not. For this scenario one solution would be to catch the exception thrown when a supplied tenant ID does not exist, and return an HTTP 404 status code with the error response.

==Logging Exception Details==
There are a variety of places within a typical web application where exceptions can be caught and logged. Ideally, you should handle exceptions in as many of the locations described below as are applicable to your application.

===Application Level===
The following code example shows how to create an error handler in the Global.asax file that will catch and log all unhandled ASP.NET errors at the application level. In this example ''Server.ClearError()'' is not called so that the exception will continue to be processed by the error display mechanism defined by the ''<customErrors>'' element in web.config. Unhandled exceptions must be logged within ''Application_Error'' rather than in a subsequent page defined by ''<customErrors>'', because the exception details are only available at this point.

<pre>void Application_Error(object sender, EventArgs e)
{
// Get the exception object.
var exception = Server.GetLastError();

// Log exception details. Be sure to include items like client IP
// address and current authenticated user if applicable.
System.Diagnostics.Trace.TraceError(exception.ToString());
}</pre>

===ASP.NET Web Forms===
ASP.NET web form pages provide the ability to capture exceptions at the page level in a similar fashion to the application level. This may be useful if you need to perform failure handling logic or log additional detail unique to the page.

<pre>void Page_Error(object sender, EventArgs e)
{
// Get the exception object.
var exception = Server.GetLastError();

// Log exception details. Be sure to include items like client IP
// address and current authenticated user if applicable.
System.Diagnostics.Trace.TraceError(exception.ToString());

// Calling Server.ClearError allows the page to continue processing,
// otherwise control is passed to application level error handling.
Server.ClearError();
}</pre>

===ASP.NET MVC===
The MVC Controller class provides an ''OnException'' method similar to the ''Page_Error'' method in ASP.NET Web Forms. It allows you to process all unhandled exceptions thrown by actions of the controller. One option for implementing exception logging is to create a base controller class and defining the ''OnException'' method in this one central location.

<pre>protected override void OnException(ExceptionContext filterContext)
{
base.OnException(filterContext);
System.Diagnostics.Trace.TraceError(filterContext.Exception.ToString());
}</pre>

A second (and arguably better) approach is to utilize the ''System.Web.Mvc.HandleErrorAttribute'' which can be used to handle exceptions at the application, controller, or action level. To apply this at the application level you add an instance of ''HandleErrorAttribute'' to the ''GlobalFilterCollection'' at application startup. This takes affect before the ''Application_Error'' method in Global.asax.cs, and by default will redirect to the ''Error'' view in the ~/Views/Shared folder. This will bypass any custom error pages defined via the ''<customErrors>'' element in web.config.

<pre>public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new HandleErrorAttribute());
}</pre>

You can log the exception details right within the ''Error.cshtml'' view using properties from the view model which is of type ''System.Web.Mvc.HandleErrorInfo''.

<pre>@model System.Web.Mvc.HandleErrorInfo

@{
ViewBag.Title = "Error";

// Log exception details
System.Diagnostics.Trace.TraceError(Model.Exception.ToString());
}

<h1 class="text-danger">Error.</h1>
<h2 class="text-danger">An error occurred while processing your request.</h2></pre>

===ASP.NET Web API===
When handling exceptions for your API endpoints you generally want to return a JSON or XML response rather than redirect to an HTML page. ASP.NET Web API provides exception filters to customize how exceptions are handled. A good way of adding exception logging is to derive your own class from ''System.Web.Http.Filters.ExceptionFilterAttribute'' and override the ''OnException'' method as shown.

<pre>public class LogExceptionFilterAttribute : ExceptionFilterAttribute
{
public override void OnException(HttpActionExecutedContext context)
{
System.Diagnostics.Trace.TraceError(context.Exception.ToString());
base.OnException(context);
}
}</pre>

You can apply the ''[LogExceptionFilter]'' attribute to any ''ApiController'', or add it at a global level using the following code at application startup.

<pre>System.Web.Http.GlobalConfiguration.Configuration.Filters.Add(new LogExceptionFilterAttribute());</pre>

===Web API Global Error Handling (Added in Web API 2.1)===
There are a number of cases in Web API where an exception can occur that falls outside of what exception filters can handle. These include exceptions in controller construction, message handlers, routing, and response content serialization. To handle these exceptions you will need to register a class that implements the ''IExceptionLogger'' interface, or derives from the ''ExceptionLogger'' base class.

<pre>public interface IExceptionLogger
{
Task LogAsync(ExceptionLoggerContext context, CancellationToken cancellationToken);
}</pre>

You then register your class at application startup to ensure that all exceptions raised during a Web API request life cycle are captured and logged.

<pre>System.Web.Http.GlobalConfiguration.Services.Add(typeof(IExceptionLogger), new MyExceptionLogger());</pre>

==Logging Sensitive Data==
Be careful when logging exception details that you do not inadvertently expose sensitive data to a logging system or external reports that may have relaxed access controls compared to the primary system. For example if a ''SqlException'' is thrown and the details contain a connection string, you may want to mask the password attribute before logging the event. Use care when logging exception details that may contain the following types of data:

*Passwords
*Authentication tokens
*Personally identifiable information (PII)
*Personal health information (PHI)
*Credit card data

==References==
*[http://www.asp.net/web-forms/tutorials/deployment/deploying-web-site-projects/displaying-a-custom-error-page-cs Displaying a Custom Error Page]
*[http://msdn.microsoft.com/en-us/library/h0hfz6fc(v=vs.100).aspx customErrors Element (ASP.NET Settings Schema)]
*[http://msdn.microsoft.com/en-us/library/ed577840(v=vs.100).aspx How to: Handle Page-Level Errors]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.controller.onexception(v=vs.118).aspx Controller.OnException Method]
*[http://msdn.microsoft.com/en-us/library/system.web.mvc.handleerrorattribute(v=vs.118).aspx HandleErrorAtttribute Class]
*[http://www.asp.net/web-api/overview/testing-and-debugging/exception-handling Exception Handling in ASP.NET Web API]
*[http://www.asp.net/web-api/overview/testing-and-debugging/web-api-global-error-handling Web API 2 .1 Global Error Handling]

[[Category:OWASP .NET Project]][[Category:Stub]]