Paddy
Paddy

Reputation: 33867

ASP.net XSS request validation not firing

I have a slight problem with an ASP.net application - the XSS request validation (i.e. the one that throws 'a potentially dangerous request.form value...' exception), does not seem to be working correctly for us.

I have the following simple test form in our site:

<%@ Page Language="VB" AutoEventWireup="false" CodeFile="Test2.aspx.vb" 
      Inherits="Test2" %>

<form id="form1" runat="server">

    <asp:textbox ID="Textbox1" runat="server" ></asp:textbox>

    <asp:Button ID="btnSubmit" runat="server" Text="Uh oh" />

</form>

And the following in our web.config for the httpRuntime element:

<httpRuntime maxRequestLength="8192" />

If I enter the following text into the textbox:

<script>alert('XSS!');</script>

The form posts with no error, where I would expect it to error out, complaining about the 'potentially dangerous... etc.'. I put an click event handler in for the button and call Request.ValidateInputs() and still no problems. Watching the Request variable, I can see a property call ValidateInputCalled, which is true even before my explicit call...

We are targeting v4.0 of the framework and I have found that if I edit the httpRuntime element like so:

<httpRuntime maxRequestLength="8192" requestValidationMode="2.0" />

Then the page request validation starts to work like I would expect (but I don't think that this should be necessary). The only other thing in the configuration like this is a set of rules such as this:

<location path="Admin/News.aspx">
     <system.web>
       <httpRuntime requestValidationMode="2.0"/>
     </system.web>
 </location>

Which we use to allow us to turn off the validation for a select set of pages (turned off at page level), where the user is permitted to submit a select set of HTML tags in their text.

This was definitely working previously. Does anybody know why this may not be working now? I don't want to have to revert to v2.0 request validation mode for the entire site.


Just tried a new web site project, single page, same as above and the request validation error IS firing. Our web.config for the original site is quite large - does anyone know of other properties within this file that can affect the request validation? The pages node in the config file looks like the following:

<pages enableEventValidation="false" enableSessionState="true" 
     enableViewStateMac="true"
     viewStateEncryptionMode="Always" 
     controlRenderingCompatibilityVersion="3.5" 
     clientIDMode="AutoID">

Upvotes: 1

Views: 947

Answers (4)

NickG
NickG

Reputation: 9830

I've found the same problem if you install Glimpse

The following line in web.config totally stops request validation from happening - no matter what your Glimpse settings are:

<system.webServer>
    <modules runAllManagedModulesForAllRequests="true">
        <add name="Glimpse" type="Glimpse.AspNet.HttpModule, Glimpse.AspNet" preCondition="integratedMode" />
    </modules>
</system.webServer>

Upvotes: 1

jamshehan
jamshehan

Reputation: 1511

I stumbled on this question while tracking down a similar issue. Mine turned out to be the fact that the page in question was POSTing its data as JSON, and the default JSON model binder does not perform the ASP.NET request validation. I eventually found a blog post by Imran Baloch describing this known behavior and a work around for it: http://forums.asp.net/t/1682096.aspx?MVC3+JSON+Security.

I know this wasn't the OP's issue, but maybe others will find it useful.

Upvotes: 1

Contra
Contra

Reputation: 2783

I also had the same problem, but in my case it was a try-catch in global.asax's Application_BeginRequest which caught the error when accessing HttpContext.Current.Request.Form and then just swollowed it. Had something to do with a cookie fix for uploadify

Upvotes: 1

Paddy
Paddy

Reputation: 33867

OK. We took our configuration file to a brand new site with a single page, and systematically started removing sections until we found the problem.

We use a third party library for some of the controls in our site, and we found that removing this section:

<httpModules>
    <add name="CallbackManager" 
      type="Dart.PowerWEB.LiveControls.CallbackManager,Dart.PowerWEB.LiveControls"/>
</httpModules>

Fixes the problem for us (but gives us a few issues elsewhere).

Upvotes: 0

Related Questions