1

I have an HTTP Handler set up in the HttpHandlers section of my web.config as follows:

<add path="myNamespace.myHandler.axd" verb="*" type="myNamespace.myHandler, myNamespace" validate="false"/>

A PCI scan has highlighted a vulnerability within this handler, which opens it up to XSS attacks. Basically you can pass a tag in via the querystring and the httphandler dumps the tag straight into the response in its raw format - ouch!

I don't have access to the source code for this handler, so I have been trying to close this vulnerability using asp.net with the following tag:

<location path="myNamespace.myHandler.axd">
    <system.web>
        <pages validateRequest="true">
        </pages>
    </system.web>
</location>

This however is not working. The querystring is not being validated, and the tags are still getting through.

I am running IIS7 with asp.net 3.5.

Can anyone help?

Cheers, Pat

Pat C
  • 351
  • 2
  • 4
  • Just to close this off, in the end I just upgraded by application to asp.net 4.0. That seemed the easiest approach. – Pat C Jun 16 '11 at 11:26

1 Answers1

0

As far as I know, there is no easy way to enable request validation for a generic http handler in asp.net 3.5 using configuration settings. There are however some validation methods introduced in .net 1.1 which I believe (not 100% sure of this) are the same criteria used in default request validation.

4.0 introduced default request validation across the board with the option to revert to 2.0 settings.

As I see it you have two options:

  • manually handling the validation somewhere in code
  • upgrade to .net 4.0 and receive the benefit of default request validation
agradl
  • 3,536
  • 2
  • 18
  • 16
  • Just a thought. Would it be possible to develop a sort of generic 'wrapper' HttpHandler that provides this kind of request validation for HttpHandlers in asp.net 3.5. You would then remove the original HttpHandler from web.config, and put the wrapper in its place. When the wrapper is requested, it would validate the request, then instantiate the original HttpHandler on the fly fire the request through to it, then redirect the response back to the end user. – Pat C May 04 '11 at 07:10
  • Honestly I've never attempted anything like that, but it sounds like a reasonable solution given your circumstances. – agradl May 04 '11 at 15:33