Request Validation flaw

I've long been a big proponent of the new Request Validation feature of ASP.NET v1.1 as a first level of defense against cross-site scripting attacks on your web applications, and have advocated leaving this feature enabled (it's on by default) unless you explicitly provide filtering and/or HTML encoding of all input to your application.

Well, a flaw has been reported in the implementation of this feature, such that it can be bypassed by specially malformed tags. The report was brought to my attention by a post from Kirk Allen Evans, who saw it on a Developmentor list. Since I've been a vocal advocate of the use of this feature, I thought it important to note the flaw.

One of the things that this highlights is that RequestValidation should only be considered (as I mention above) a first line of defense, not a complete security solution. As Scott Guthrie and others have consistently recommended, you should always HTML encode any and all text input that you accept from users that will (or may) be stored and/or displayed later. You should also consider using regular expressions (in conjunction with the RegularExpressionValidator control) to limit input to solely those characters or character sequences that are appropriate for any given input field. Taking such a multilevel approach to processing input can help protect you from a flaw in any single input filtering technique.

A fix for this flaw is available, and was made available as part of the ASP.NET 1.1 June 2003 Hotfix Rollup Package. Unfortunately, it appears that that rollup can only be obtained by contacting Product Support Services. However, a later rollup that also includes this fix can be downloaded from Microsoft. Note that hotfixes generally have not undergone the same level of testing as official patches, so if you are not directly affected by this (if your applications do not accept input, or if you've already got input filtering in place), you may want to wait for the next service pack for the .NET Framework, which will include this fix.

Bottom line is that although a fix is available for this flaw, you should always treat input appropriately, regardless of any built-in features. This means always providing your own filtering and/or (preferably and) encoding of input your application accepts.

5 Comments

  • Well I'm subscribed to the ASP.NET RSS feed and I haven't seen anything come accross that talks about this hotfix or the other download.



    I misstated when I said "official", I meant "one-stop shopping" like windowsupdate.microsoft.com is for the platform. It would be nice if I could automatically check for ASP.NET updates, especially security related ones, and have a service notify my system admins that one is available.

  • Scott, I believe the reason that this isn't more heavily publicized is because right now the fix is only classified as a hotfix, and hotfixes haven't been as heavily regression tested. OTOH, I agree that more people should know about it, which is why I'm publicizing it here. People do, however, need to evaluate for themselves the risk associated with the flaw versus the potential risk of a hotfix causing an unrelated problem, which is not unheard of. As I said above, those who want a more stable solution should wait for the next service pack for the fix.



    As long as you're using good filtering and encoding practices, this flaw will not really effect you. Another reason to spread the word about proper input processing!

  • To my anonymous poster,



    If you'd like to post something more substantive, I'll leave your comment up, but my blog isn't the place for anonymous profanity, so I've deleted your recent comment.

  • Hello all

    How I can change avatar in this forum?

  • Snx for you job!
    It has very much helped me!

Comments have been disabled for this content.