ASP.NET Event Validation and “Invalid Callback Or Postback Argument” - Part II

ASP.NET Event Validation and “Invalid Callback Or Postback Argument” : Part II

In the last post we looked at the job event validation performs, and how we can trigger a validation error with some innocent JavaScript. If we receive exceptions because of event validation, we have to disable the feature, or learn how to work with the event validation.
Disable Event Validation

Pros: Easy to do
Cons: Less secure

Bertrand Le Roy wrote a post back in 2004: “Please, please, please, learn about injection attacks!”. Event validation is a feature designed to help prevent injection attacks (of course it can't prevent attacks all by itself).

We can disable event validation for an entire site in the web.config file.





Alternatively, we can disable validation for a single page.

<%@ Page EnableEventValidation="false" ... %>

Register For Event Validation

Pros: Feel validated
Cons: We need to register all the legal post values before the page is sent to the client - this isn't always possible or practical

When we last left our application, we had a DropDownList with three legal values: “1”, “2”, or “3”. The problem was that client side script was adding a 4th option: “4”. If the user selected the 4th option and posted the form to the server, the server would throw an exception because it didn’t know “4” was a legal value.

The key to passing validation is to let ASP.NET know the value “4” is legal with the RegisterForEventValidation method of the ClientScriptManager class.

RegisterForEventValidation must be called during the rendering phase, so we need to override a Render method. We could start by overriding the Render method of our web form. Plug the following code right below the Page_Load method from the previous post.

protected override void Render(HtmlTextWriter writer)
{
ClientScript.RegisterForEventValidation(
_recipeList.UniqueID,
"4"
);

base.Render(writer);
}

Remember event validation works by combining the hash of a control’s UniqueID property and a hash of each legal value for that control. The RegisterForEventValidation method accepts both of the calculation inputs as parameters. The method stores the result in a dictionary, and the page adds saves the dictionary as a hidden field on the client.

Adding the RegisterForEventValidation responsibility to the Page class is less than ideal, as the web form suddenly has to know about the DropDownList and its event validation problems. An alternate solution would be to build our own control.

using System;
using System.Web.UI.WebControls;
using System.Web.UI;

namespace OdeToCode.Web.UI.Controls
{
[SupportsEventValidation]
public class DynamicDropDownList : DropDownList
{
protected override void Render(System.Web.UI.HtmlTextWriter writer)
{
Page.ClientScript.RegisterForEventValidation(
this.UniqueID,
"4"
);
base.Render(writer);
}
}
}

A crucial step in the code is to add the SupportsEventValidation attribute to the class. If this attribute is not present, all the RegisterForEventValidation work is in vain. The runtime does not validate events for controls that do not have the SupportsEventValidation attribute present, nor does the runtime does look at the custom attributes of the control’s base class. The table of controls supporting event validation that appeared in the last post was output by a simple program that looped through all the Types in the System.Web assembly looking for the SupportsEventValidationAttribute.

In our example, we knew we only had one additional legal value – the value “4”. We need to call RegisterForEventValidation for every legal value the control might postback. This raises a couple issues because we may not know all of the legal values the control can take. AJAX might populate the control with values from a web service call that is bridged to a third party. Another issue is that the number of legal values might be extremely large.

Unfortunately, ASP.NET doesn’t expose a property to disable event validation for a single control – this would be a nice feature to have. However, if we create a custom control and leave off the SupportsEventValidation attribute, we’ll effectively disable event validation for instances of that class.
source:http://odetocode.com/Blogs/scott/archive/2006/03/21/3153.aspx

ASP.NET Event Validation and “Invalid Callback Or Postback Argument” - Part I

ASP.NET Event Validation and “Invalid Callback Or Postback Argument” : Part I

ASP.NET 2.0 added a feature called event validation. Event validation checks the incoming values in a POST to ensure the values are known, good values. If the runtime sees a value it doesn’t know about, it throws an exception.

Invalid postback or callback argument. Event validation is enabled using in configuration or <%@ page enableeventvalidation="true" %> in a page. For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them. If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation.

The error message is a bit wierd and could use some editing, but if someone is trying to attack the application by spoofing a postback, the event validation exception is a good thing. Event validation can help prevent injection attacks from malicious users who are trying to POST data that doesn’t belong.

If we see this exception during the normal execution of an application, the exception is a bad thing. Let’s look at one scenario where the exception can occur after a legitimate postback, and talk about the implementation of event validation. A future post will discuss possible solutions.

Cause

Imagine we’ve been given the task of writing a web form with a DropDownList, and the DropDownList contains three selections.

<h3>Pick Your Favorite Recipeh3>
<asp:DropDownList runat="server" ID="_recipeList">
<asp:ListItem Value="1">
Amy's Wasabi Encrusted Tuna
asp:ListItem>
<asp:ListItem Value="2">
Big Al's Five Bean Burrito
asp:ListItem>
<asp:ListItem Value="3">
Scott's Chocolate Carmel Cheesecake Cookies
asp:ListItem>
asp:DropDownList>

Now, it’s a fairly common scenario for client script to populate the contents of a drop down based upon the value of some other control on the page. For example, a list of states may appear after the user selects a specific country. Let’s simulate that scenario by registering some JavaScript which adds a 4th option to the list.

protected void Page_Load(object sender, EventArgs e)
{
ClientScript.RegisterStartupScript(
GetType(),
"AddToList",
script.Replace("{_recipeListID}", _recipeList.ClientID),
true
);
}

string script =
@"
var d = document.getElementById('{_recipeListID}');
d.options[3] = new Option('George\'s Recipe For Disaster', '4');
";

As long as the user selects recipe 1, 2, or 3, the form will postback without errors. If the user selects option 4, George's Recipe For Disaster, the runtime throws an event validation exception. Disaster indeed!

When ASP.NET rendered the DropDownList it recorded all the possible postback values for the control, It does so by looping through the 3 available ListItems and recording each value. When I say “recorded”, I mean for each item in the list the runtime takes a hash of the control’s UniqueID property, and a hash of the ListItem’s Value property, and XORs the two hash values together. The result of this computation is kept in a list with other allowable hashed values, and the list persists itself as a hidden field in the page.

<input type="hidden"
name="__EVENTVALIDATION"
id="__EVENTVALIDATION"
value="/wEWBQKGg9abDQKd9sHMBgKc9s........"
/>

If the user selects George's Recipe, the browser posts back with a value of “4” for the DropDownList. The runtime will perform the same calculation described earlier: hash(_recipieList.UniqueID XOR hash(“4”)). The runtime will try to find the result of this calculation in the list of allowable values de-serialized from the __EVENTVALIDATION field. The runtime won’t find this value, and will sound the alarm by throwing an exception.

To summarize: the runtime threw an exception because the browser posted a value of “4” for the DropDownList. The runtime thinks the only allowable values are “1”, “2”, and “3”. We added the value “4” as an option using client-side script, so ASP.NET did not know it was legal. ASP.NET calculates the allowable postback values at the last possible moment (inside the Render method of the control).

Source(http://odetocode.com/Blogs/scott/archive/2006/03/20/3145.aspx)