Are textboxes considered to be safe from cross site scripting attacks?  Is there ever a time when I need to validate output that is directed into a textbox?

 Thanks!

The value attribute for ASP.NET server controls is HTML encoded on output, which means that any dodgy HTML should be caught and rendered as text (e.g. < will appear as &lt; etc.)

For multiline mode textboxes (which render as textarea elements), there is an explicit call to HttpUtility.Encode() in the Render method.

You should be using it in all the other places where you would want to do encoding. Whatever you do, though, be careful that you don't double encode data as it can look a lot weird.

For example (and this is mentioned in the AntiXss docs), if you use Microsoft.Security.Application.AntiXss.HtmlAttributeEncode() on "Hello, Microsoft!" and then assign that into the Text property of an ASP.NET TextBox, you end up with (not quite total, but pretty much) rubbish.

On the other hand, if you're into raw HTML, then it's great with things like this:

Of course, if you mark the <input> control with runat=server and then assign it to its value in codebehind, you'll end up with double encoded output.

To sum up, you should use AntiXss when producing output and where the server-side controls don't already encode the output.

The first rule of Information security says "Never trust the user input". You must always check and sanitize the user input whether you are directing it to a html label or textbox.

 Its always safe to encode HTML characters such as "<",">" to "&gt;", "&lt;". Again, All these checking must be performed on server side.

 
The microsoft anti-cross site scripting library is very helpful for a .NET project. You can find more info on this library at http://msdn2.microsoft.com/en-us/security/aa973814.aspx

Thanks

 
 Find more information security info at Web Information Security
 

DMW:

You should be using it in all the other places where you would want to do encoding. Whatever you do, though, be careful that you don't double encode data as it can look a lot weird.

For example (and this is mentioned in the AntiXss docs), if you use Microsoft.Security.Application.AntiXss.HtmlAttributeEncode() on "Hello, Microsoft!" and then assign that into the Text property of an ASP.NET TextBox, you end up with (not quite total, but pretty much) rubbish.

On the other hand, if you're into raw HTML, then it's great with things like this:

<

input type="text" value='<%= Microsoft.Security.Application.AntiXss.HtmlAttributeEncode( "Hello, Microsoft 999!" ) %>' />

Of course, if you mark the <input> control with runat=server and then assign it to its value in codebehind, you'll end up with double encoded output.

To sum up, you should use AntiXss when producing output and where the server-side controls don't already encode the output.

Okay, so if I test a control (textbox, etc...) with data I purposefully injected a script into, and it encodes it on its own, then I should be okay?  Is there any further testing that I might want to do? 

For input validation, right now, all I'm doing is making sure that the input is not larger than the field can accept.  All information taken in is done so through parameters to help prevent sql-injection attacks (plus the user the web app connects with only has privileges to access the stored procedures).  Inserting html encoded text into my database doesn't seem like a good way to go since some controls automatically encode the data themselves, and I'll end up with some controls displaying jibberish, and others looking fine.  Plus other types of processes might not decode the text either (reports, etc...).  What other types of validation can anyone recommend?  How much validation needs to be done with numbers, or other non-string datatypes to prevent stuff like buffer overrun attacks?

 Thanks for all the help!  I think I'm getting the hang of it, I just want to be double sure so I don't have to go back through my site and recode half of it because I left security holes open.

dacoolthings, 

Whilst I totally endorse the sentiment that you should never trust user input, it is incorrect to assert that it is "always safe" to encode HTML characters such as "<", ">", etc.

For example, imagine that the user can enter code samples (and that you have turned off ASP.NET's ValidateRequest mechanism. So the user enters a code snippet such as this

if( x < y )

which you decide to write back to the user in an ASP.NET TextBox in multiline mode (actually, the mode is irrelevant, but it reflects a more likely scenario).

If you take that input text and encode it with either Server.HtmlEncode or an appropriate AntiXss encode method, and then assign it to the Text property of the TextBox the user will see either

if( x &lt; y )   - this is the Server.HtmlEncode version

or

if&#40;&#32;x&#32;&#60;&#32;y&#32;&#41;   - this is the AntiXss.HtmlAttributeEncode version

So, clearly, it is not always safe to encode, at least not in code, but is is clear that output should always be encoded. Appropriate encoding is the key, which I believe was the point of the original question, and this is made clear in the AntiXss documentation.

ryarbrou

You should always test, especially for malicious input, so I'd go with that as a very solid approach.

One thing that I like to do is to model the data flow (from a security perspective), document it and explain what action has been taken to protect the application/data from being compromised. This becomes doubly important as you move forward into the world of AJAX, where data might be being downloaded via Web Services without going via the normal, server-side page presentation controls.

But there are a number of things that you should do, if possible:

1. Make sure that ASP.NET's request validation is turned on. If the user enters malicious code an exception will occur and you can then ask them (politely) not to enter garbage.

2. Use all appropriate validation controls. RangeValidation, CompareValidator and RegularExpressionValidator are awesome, remembering that they won't necessarily check for empty fields. Always use them where you can.

3. Encoding all input that you put into a database might not be desirable. Just make a note of the fact (in your data dictionary, perhaps) what has and has not been encoded. That way, other developers will know.

4. Controversial, I know, but consider banning things like Response.Write*, arbitrary <%# %> blocks and also enforce the use of server-side controls.

* There are a few cases where you might need to use this, but document the steps that you've taken to protect the data/app and explain why it had to be used. 

But thorough security reviews (with other developers) and solid testing are the key to this.