This is sort of the source for preventing XSS in ASP.NET (at least from Microsoft):

How To: Prevent Cross-Site Scripting in ASP.NET

Some important things to glean from the article specific to your question:

• Use the HttpUtility.HtmlEncode method to encode output if it contains input from the user or from other sources such as databases.

• use HttpUtility.UrlEncode to encode output URLs if they are constructed from input.

Regarding HTMLAttributeEncode:

• The HtmlAttributeEncode method converts only quotation marks ("), ampersands (&), and left angle brackets (<) to equivalent character entities. It is considerably faster than the HtmlEncode method.

• The string result from the HtmlAttributeEncode method should be used only for double-quoted attributes. Security issues might arise when using the HtmlAttributeEncode method with single-quoted attributes.

And finally, with UriEscapeString, use that if what you are escaping is a URI. This SO question discusses the difference between UriEscapeString and UriEscapeDataString.

No.

Putting aside the subject of allowing some tags (not really the point of the question), HtmlEncode simply does NOT cover all XSS attacks.

For instance, consider server-generated client-side javascript - the server dynamically outputs htmlencoded values directly into the client-side javascript, htmlencode will not stop injected script from executing.

Next, consider the following pseudocode:

<input value=<%= HtmlEncode(somevar) %> id=textbox>

Now, in case its not immediately obvious, if somevar (sent by the user, of course) is set for example to

a onclick=alert(document.cookie)

the resulting output is

<input value=a onclick=alert(document.cookie) id=textbox>

which would clearly work. Obviously, this can be (almost) any other script... and HtmlEncode would not help much.

There are a few additional vectors to be considered... including the third flavor of XSS, called DOM-based XSS (wherein the malicious script is generated dynamically on the client, e.g. based on # values).

Also don't forget about UTF-7 type attacks - where the attack looks like

+ADw-script+AD4-alert(document.cookie)+ADw-/script+AD4-

Nothing much to encode there...

The solution, of course (in addition to proper and restrictive white-list input validation), is to perform context-sensitive encoding: HtmlEncoding is great IF you're output context IS HTML, or maybe you need JavaScriptEncoding, or VBScriptEncoding, or AttributeValueEncoding, or... etc.

If you're using MS ASP.NET, you can use their Anti-XSS Library, which provides all of the necessary context-encoding methods.

Note that all encoding should not be restricted to user input, but also stored values from the database, text files, etc.

Oh, and don't forget to explicitly set the charset, both in the HTTP header AND the META tag, otherwise you'll still have UTF-7 vulnerabilities...

Some more information, and a pretty definitive list (constantly updated), check out RSnake's Cheat Sheet: http://ha.ckers.org/xss.html

You encode data (strictly speaking, only data that might include user input, but many times it's just easier to apply to all data) right before it gets inserted into the page DOM. In different scenarios this means different things, and that results in a lot of confusion.

To answer one of your questions directly, you do not encode data before sending it to the server, or before inserting it into a database or something. You don't encode data on the request side in general. The reason is that in a complex application, you don't know where and in what context your data will be rendered, and for different contexts you will potentially need different encodings. Your input layer has nothing to do with that, but this is not just an architectural question, you have no way to select an encoding until you know how you want to render that data.

Of course this does not mean you don't encode it to whatever "output" it gets right into, during the request. For example you apply encoding to prevent SQL injection if you have an SQL database, but that is done automatically by using proper data access layers, parameterized queries and so on. You also apply an appropriate xml encoding if it gets into an XML during the request and so on. But that is not about XSS, it's about preventing other injection vulnerabilities, and these things are likely done by your language or framework mostly automatically, unless you are doing something unusual or less frequent.

You also apply input validation to any input, you can validate for format (in case of say an email address or a date), or you can validate for desired character set and so on.

But in general, there is nothing wrong with storing data as you received it from the client, without any actual encoding. In fact, this is the right thing to do in most cases (see below for the exception).

Then whenever that data gets output in any way, rendered in HTML, used in a backend query (which can be LDAP or SMTP or SQL or whatever else), you apply the appropriate encoding, according to this context you are using your data in. For html you apply html encoding, but for example for javascript (html can contain javascript blocks, where this also applies!) you apply javascript encoding. This is an output thing in general.

Having said that, there are a few... well, let's call them special cases.

Modern javascript applications (like single page frontends) might manage a lot of data without talking to a server. User input sometimes gets written all over the place and so on. In that case it's the job of the SPA to apply appropriate encoding whenever it inserts stuff into the page DOM. This mostly means using secure facilities of your chosen framework, most modern frameworks are quite good at this by default, but you need to be aware what and how will actually be encoded an dinserted to prevent XSS. This is not at all straightforward in a complex SPA. Probably the most complex case is when you want to deliberately receive html from the client (say you have a html editor widget), save it to a server, and display it in the SPA again, possibly with a preview feature while editing, but this is a separate (large) topic, just something to be careful with.

One exception to the "not enconding stuff in the database" rule might be large, complex legacy applications. Sometimes you cannot guarantee that all (legacy) frontends to your data will apply proper encoding, so you might decide to encode data before writing it to the database. The problem with this is that then you cannot even write new code properly, because if you apply encoding again, data will be double encoded, which is also wrong.