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.