HTMLEncode and Cross Site Scripting Attacks – User Input is not always coming from the form!

One thing to consider when rendering output to the browser is to htmlencode any text that you are sending out to the browser. eg. label.text=htmlencode(mystring). It’s pretty obvious to do this with direct user input – for example a search form where you spit back “Your search for ‘dogs’ resulted in 23 articles”. But consider user input that has been stored in a database. That is STILL user input! Perhaps a user profile where “favorite color” = “<script>alert(‘you are SOL dude’)</script>”. So even though the text is not coming from a form input page, it is coming from your database, you still need to htmlencode.

HTMLEncode is not always going to be the solution, but you should use it by default and then decide not to use it if you have a reason. Here is a post by Jon Box where he has a similar conundrum.

Similarly, the Page object’s ValidateRequest (in ASP.NET 1.1) which is on by default, is not going to be helpful 100% of the time but you also need to be very thoughtful if you are going to turn it off. Here is some more info on that from Don Kiely.

  Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!  

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.