Gotta say, personally I think this was a mistake - it was effectively a breaking change - which meant work (not much, but still work) on existing sites to get them to work again - and for many sites retesting was required to ensure they still worked correctly. It would have been nice if this had not been enabled by default but had been included in the page definition in VS.NET and / or the default web.config. This actually stopped a number of clients upgrading to 1.1 - they had been told that it was likely their site would break due to the upgrade...

I don't agree with Scott on that point. I like the approach of software products enforcing security for non-security aware people.

That being said, the only "mistake" that I think the ASP.NET team made was to not make this feature extensible by devs, that is to be able to plug-in your own validation logic. Having a "closed" validation meant from the very beginning that -sooner or later- someone could break it and the whole feature would become useless.

-VGA

To be honest yes, it does have it's value - but my point is that it was a clear breaking change - even if it is introduced as a 'feature' - many sites just failed to work properly after this was introduced. XSS attacks were also a fairly minor problem in the majority of cases (e.g., banks tend not to allow users to post data, most forums already feature some form of tag stripping). Other 'request' attacks such as SQL Injection are potentially more destructive attack - problem is a 'lazy programmer' (e.g., http://weblogs.asp.net/erobillard/articles/3801.aspx) will tend to think that when request validation is 'on' then all incoming data can be considered 'safe'.
Point is, I don't personally feel that the responsibility for securing an app can be 'delegated' to the framework - especially when as you point out, know flaws exist - these flaws wil exist in ALL apps using the function as their primary form of protection rather than just the few who used their own means.

I agreed with Scott. This stuff broke down most of the sites I have in production, and I was looking like a moron when I have to explain why. I disabled this feature globally from all the sites I managed.
.Net 1.1 supposed to be an upgrade to 1.0, not breaking everything. something that was missing the point totally was the fact that some code sent from a page could be totally valid. an example ? This very .Net weblogs, where I remembered the editing function didn't worked at all for few days ! Because like many developers and I, ,Text use n embedded HTML editor.
Yes it should be a great idea to provide something like this turned off by default.

I fail to sympathize with those who complain about this feature. The breaking change was documented and so was the fix. Only those who upgraded with no research were surprised by the change.
Adding the change to the web.config file is trivial at worst. No re-compile, you didn't even need to break out VS.Net to make the change, notepad would handle it with ease.

Shannon, correct, it was documented but it was added not as a bug fix / some ultra-necessary change - it's just to help out lazy developers, all the apps which any concientious developer has worked on already had this type of validation in place.
To document a breaking change is far easier than fixing it (many sys admins have very limited experience of .NET and will not change web.configs necessitating getting the developers to do the fix - which can cost a fair bit for some companies)

Scott, I'm not sure I understand. You are saying that the upgrade from v1.0 to v1.1 was done by a Sys Admin with no .NET experience who requires an outside developer to change a web.config file? And that the guy didn't check with the developer(s) before doing the upgrade?

Just like the developers who deployed v1.1 on their production servers without research or testing, the Sys Admin you mention above experienced what you might call a "learning opportunity".

Yeah, I think this is a great feature for most, but I know here at Match.com we had issues with this in a web farm environment. We couldn't guarantee that we would be on the same server on the subsequent postback, so we quickly got flooded with these request validation errors, so had to quickly disable it across the site and take other measures to protect ourselves against this.

Though, I'd love to know if perhaps we needed to do something differently in our scenario, or if it's since been improved.

just for the record, I am not a fan of request validation at all. It is too stringent and lacks the control that I would like.

It is always a difficult tradeoff when you lock down functionality to create a more secure default. People who were using ASP.NET 1.0 before its release will surely remember what happened when we switched the default to run as the ASPNET user instead of the system account.

What we found was that many ASP.NET sites were suffering from problems in cross-site scripting, and many were not even aware of it. The change we made was intended to create a default that was safer. It was not intended to be a magic bullet people rely on to protect themselves, but a safety net for people who don't. It's also why we didn't make the feature very extensible, because we thought that people who wanted to do their own custom protection could easily write their own code in global.asax.

One thing we did learn is that it is painful to force sites to migrate from one version to another by default when installing, especially since there are so many ways people can install a new version on their system. In 2.0, we're planning to change the default to not migrate on install, and we're also adding UI to the IIS MMC tool to make it easy to change versions for individual apps. We'll also have a migration guide that shows people what to check out when migrating.

For Scott: Agreed, SQL injection is definitely a bigger problem. Although we can't easily protect against it automatically, we do have whitepapers and presentations that recommend how to avoid this by using programmatic parameterization. The new data controls we have in Whidbey will make this a lot easier too, by eliminating a lot of the code you have to write to create SQL queries for databinding today.

For Jason: I'd be curious to know how a web farm environment would have broken due to this feature, since it should not have any web farm dependencies. We did make additional changes to secure ASP.NET - to lock down forms auth, for example - but I'd love to hear what had broken, and how you had to fix it.

I respect the opinions of all writers comments above and having explored this issue in detail in DotNetNuke, I would like to offer my own perspective...

The requestValidation works at the Application or Page level to mitigate the chance of cross-site scripting attacks. Under the covers, I suspect it sniffs the Request stream for <script> tags and throws an error message if they exist ( apologies for my simplistic description of a potentially much more elaborate implementation ).

I suppose this works for some sites, but for sites using a common container ASPX page which inject User Controls dynamically ( ie. a portal ), this level of granularity is not enough. This is mostly related to User Controls where you actually want to permit the end user to enter HTML markup ( ie. a content editor ). Since requestValidation is an all or nothing proposition at the page level - it can not be used in this case.

In my case I explored the concept of enabling page level requestValidation by default and having a metadata flag for User Controls which allow for entry of HTML markup. If they were injected into the page then the requestValidation would become disabled. The problem is that there may be other User Controls on the same page which would then exposed to XSS.

Looking at requestValidation from a higher level, made me think of the use cases where it actually applies. If I review the entire collection of base ASP.NET web controls, I only find one which allows for free form user input - the TextBox control ( thats not saying that a hacker couldn't programmatically alter the Request object but it requires a much higher degree of sophistication ).

So my suggestion has 2 parts:

1. Expose a framework function called VerifyXSS(String) As Boolean which provides cross site scripting validation to the developer. You may even want to provide an Override where the developer could pass in an exclusion list of HTML tags.

2. Add a property to the TextBox control called VerifyXSS which defaults to True. Then when a developer retrieves the TextBox.Text value the underlying control code checks the value of the VerifyXSS property and either performs the validation or not. This provides the developer with the ability to disable the VerifyXSS at the control level which provides a higher degree of granularity.

I think that this solution would still show due diligence on the part of Microsoft in respect to XSS. Plus it provides backward compatibility and more granularity for the developer. The behaviour of applications and third party rich text editors would not be affected.

If I am missing the larger point, I apologize in advance - but I think this topic could use some constructive suggestions rather than pure criticism.

^_^,Pretty Good!

Just use this as a regular expression validator and restrict  the user so If they enter the html tag then shown an error.

Regular expression is  ^[^<^>]*$

Thanks

haha