I came in need of an ASP.NET text box control that allows the user to enter rich text. Quickly enough I found FreeTextBox, an awesome control that is widely used in several well-known projects (such as Community Server, which hosts the blog you’re currently reading). And, as it name suggests, the basic version of the control (which is more than enough for my needs) is free.
So I started playing around with it a bit, throwing it in a web-page, editing some HTML and posting the page. Boom.
…A potentially dangerous Request.Form value was detected from
Well, of course. ASP.NET was smart enough to detect that some HTML was posted in the form, and it thought to itself “Hmm, that could also be a script. Shouldn’t let that happen.” And it was right, too. Still, I do want to let my users edit HTML, don’t I?
If you google that error, you will get one of two solutions:
- Set validateRequest=”false” on the <pages> element in your web.config. This, will in turn cancel all request validation in all the pages in your application.
- Set ValidateRequest=”false” on the <%Page…%> directive in the page you’re using your FreeTextBox. This will cancel request validation only for the specific page.
The first suggestion is a big no-no, as it can seriously harm security on your web-site, allowing malicious users to inject scripts to your sites, and cause some serious damage (unless, of course, you validate all of your input yourself with regular expressions, which most people don’t).
The second suggestion is better, as it exposes you to danger only in the page you have the FreeTextBox. There you’ll have to be extra careful. First, if you have the HTML-mode enabled, allowing the user to enter raw HTML, the user can just put in <script> tags and post the form. So you might think that turning off HTML-mode, allowing only the design mode which creates HTML for you, you’re off the hook.
Well, that won’t be very smart of you. I showed here how any client-side validation turns to dust with a simple tool as the FireBug debugger for Firefox. With the same technique, you could go to the console view of Firebug, and hit the following:
-document.getElementById(‘FreeTextBox1’).value = ‘<script> alert(‘hi!’); </script>’;
So any method that tries to prevent the user to enter malicious data on the client is rather worthless. Luckily, FreeTextBox has a property StripAllScripting that removes all the scripts on the server-side, so no client-side hacks can help you there. I am not 100% sure this is a bullet-proof solution, but it seems to work well.
You should also be extra careful with any other fields you have on the same page that are not FreeTextBoxes. You don’t get any request validation for them neither, so you should remember to validate them with regular-expressions, or simply Server.HtmlEncode their ass. Why couldn’t we HTML-Encode our FreeTextBox input as well, you might ask? Well, that would kind of ruin the point of letting our users enter rich HTML content, wouldn’t it? If we let them edit text with HTML, we would probably want to display their text as rich text, and not as a series of <htmlTags/>.
FreeTextBox really is a great control, just be careful not to leave huge security holes in your application while you’re using it.