What do I need to do to protect my site if I choose to set ValidateRequest= false?

I've kind of just discovered that because ValidateRequest = true by default, that by default, you cannot enter "&开发者_Python百科lt;" or ">" into any input field.

Not knowing too much about XSS attacks, for me, that seems quite restrictive.

To get around that, I've realized I can use validateRequest = false, and to encode the user data. Obviously, Microsoft has a good reason to put validateRequest = true, so the problem now is I have a whole site with lots of pages, all with this "can't put < or > problem".

My question is do I only have two options?

1) Leave validateRequest = true and not allow the user to enter < or > at all 2) switch validateRequest = false and take preventative measures.

If for 2, am I meant to encode all data input? Like from text fields from logins and passwords to user text to search criterias? Or do I only need to do it to some of the input? If so, which fields should I target?

I ran into this same problem to and found the answer on Stack Overflow here:
A potentially dangerous Request.Form value was detected from the client

Read the high-ranked comment in the marked answer.
This is what I use in my Web.Config because I'm using the .net 4.0 framework:

<httpRuntime requestValidationMode="2.0" />

Then I add ValidateRequest="false" on a page-by-page basis:

<%@ Page Title="" Language="C#" MasterPageFile="~/MasterPages/Site.Master"
    AutoEventWireup="true" CodeBehind="ScheduleAppointment.aspx.cs"
    Inherits="DentalPower.Pages.Public.ScheduleAppointment"
    ValidateRequest="false" %>

It would be nice if Asp.net TexBoxes had a feature where I could set a ForceEncode property to true that would automatically encode input before sending. Maybe they will do that... someday.

Oh, and always encode all your input from web controls on the page you disable Validation.

To the best of my knowledge your are correct. Either leave validation on or do it manually yourself. The trouble is that the default validation is extremely strict and is not practical in a lot of situations (so many web apps I've seen just turn it off site-wide without much thought to the consequences).

For your reference, a great article on code escaping is http://wonko.com/post/html-escaping