Clever Geek Handbook

How to handle encoded inputs that need to be edited?

Using Microsoft AntiXssLibrary, how do you handle input that needs to be edited later?

For example:

The user enters:   <i>title</i>

Saved in the database as:  <i>title</i>

The edit page displays the following in the textbox    &lt;i&gt;title&lt;/i&gt;

because I coded it before displaying it in the textbox.

The user doesn't like this.

Is it ok to code when writing to an input control?

Update:

I am still trying to figure it out. The answers below say to decode the string before displaying it, but wouldn't that allow XSS attacks?

One user who said decoding a string in an input field value is ok was downvoted.

0


source to share


5 answers


It looks like you are coding it more than once. In ASP.NET, using Microsoft AntiXss Library, you can use the HtmlAttributeEncode method to encode untrusted input:

<input type="text" value="<%= AntiXss.HtmlAttributeEncode("<i>title</i>") %>" />

As a result 



<input type="text" value="&#60;i&#62;title&#60;&#47;i&#62;" />
in the rendered markup of the page and renders correctly as <i>title</i>

an input field.
+2


source


Your problem is double coding; The HTML has to be escaped once (so it can be inserted into the HTML on the page without issue), but twice causes the encoded version to appear literally.



+1


source


You can call HTTPUtility.HTMLDecode (MyString) to return the text to an unregistered form.

0


source


If you allow users to enter HTML, which will then be displayed on the site, you need to do more than just encode and decode it.

Using AntiXss prevents attacks by converting script and markup to text. It does nothing to "clean up" the markup to be displayed directly. You will have to manually remove script tags etc. From user input to be completely protected in this scenario.

You will need to strip out script tags as well as JavaScript attributes for legal elements. For example, an attacker could inject malicious code into the onclick or onmouseover attributes.

0


source


Yes, the code inside the input fields is safe from scripting attacks and doesn't need to be encoded.

-4


source






More articles:


All Articles