5
votes

I am working on a ASP.Net C# + jQuery ajax website project. I am trying to prevent xss attacks and I know below is not the full approach, but this is at the least what I should do - to use HtmlEncode when accepting free string input from users). And I really someone to kindly check if I am doing the right thing.

So let's say we have a scenario for which one of the page control is a "Description" text box and users can enter "free" string used to describe their product. To prevent from getting xss attacking inputs, on the server side Page Method, I wrapped up the "Description" text using HtmlUtility.HtmlEncode(), so the string will be interpreted as pure text before going into database i.e. <script> becomes &gt;script&lt;.

The part that follows is what i am in doubt - how to handle the html encoded text before returning it back to the user?

When the user wants to view the Description text entered, the website retrieved from database and prints it out.

Is it logical to perform html decode on the description so the user will not see those wierd &gt;&lt; characters? Will it defeat the purpose of using HtmlEncode in the first place? And if yes, is this the correct jQuery line to decode and print the text back to the users???

$("#txtDescription").val($(this).html(obj.Description).text();

Thank you very very much

3

3 Answers

1
votes

You need to keep in mind the content type of each string you deal with and where it came from - whether from a safe source or an untrusted source, and also know when concatenating two strings that both are strings of the same content-type and trust-level.

I wrapped up the "Description" text using HtmlUtility.HtmlEncode(), so the string will be interpreted as pure text before going into database i.e. <script> becomes &gt;script&lt;.

Here it sounds like you're saying the description field is a string of plain text and what you're storing in the database is a string of safe HTML (since HtmlEncode's output is guaranteed not to contain dangerous code).

This shows the first problem with prematurely encoding content. If you're composing a SQL string to send to the server, pre-encoding as HTML does not protect you from SQL injection. Using a SQL prepared statement is a good way to overcome this for SQL, but pre-encoding does not render a string safe in all contexts.

The part that follows is what i am in doubt - how to handle the html encoded text before returning it back to the user?

When the user wants to view the Description text entered, the website retrieved from database and prints it out.

If the user is receiving safe HTML, and you have a string of safe HTML, you can just send that to the user.

If the user is receiving a plain text email, then you need to convert the safe HTML stored in the database to plain text.

If the user is receiving RSS, then you need to make sure you compose your RSS using substrings of XML.

Contextual auto-escaping can help you make sure values are properly encoded on output.

6
votes

Do NOT encode text going into the database. Store it in its raw, unfiltered form. Only encode HTML chracters when the string if being output into an HTML-capable context (such as output to the browser).

0
votes

It is a good idea to use AntiXss library instead of httputility.htmlencode. Consider reading the documentation for more clarity. You have wider options in AntiXSS library w.r.t input encoding. It follows a more secure white list based approach as mentioned in this discussion.