Hurricane Wilma will be making her way to Southwest Florida during the evening hours and electricity could be iffy during Sunday evening through ?, so I thought I would post a few entries here on my blog before things go bad.
Microsoft's patterns and practices group recently published their ASP.NET 2.0 Security Best Practices. If you haven't read this document, I encourage you to do so as security is everyone's responsibility ( unfortunately ).
Given the anticipated release of .NET 2.0 in the upcoming weeks, I have been busy upgrading a number of my checklists, code generation templates, and personal best practices so I can embrace the new technology. You can also read this as “I don't want to look like an idiot in the developer community for not adopting the latest and greatest cool stuff.“
I have been going through the ASP.NET 2.0 Security Best Practices Document almost daily to verify I am up-to-date on any new practices and to make sure my code reflects the new changes. This ritual is spawning a number of posts on my favorite practices, the first being a post about using Principal Permission Attributes on classes requiring role or authenticated privileges:
ASP.NET Security Principal Permission Attributes - SecurityAction.Demand Authenticated = true - Application_Error
Cross-Site Scripting
Another of my favorite ASP.NET Security Best Practices is to eliminate cross-site scripting, which basically involves people who enter HTML and JavaScript code into web forms in an attempt to inject unexpected data and cause various problems.
To avoid cross-site scripting there are two things that need to be done:
- Verify Input - Constrain the acceptable range of input characters.
- Encode Input - Use HttpUtlitity.HtmlEncode when displaying input back to user
Verify Input - RegularExpressionValidator Control and Regex.IsMatch
ASP.NET has a RegularExpressionValidator Control that you can attach to ASP.NET TextBox Controls as your first line of defense.
<asp:RegularExpressionValidator
ID="regexpName" runat="server"
ErrorMessage="This expression does not validate."
ControlToValidate="txtName"
ValidationExpression="^[a-zA-Z'.\s]{1,40}$" />
A malicious hacker can also post back to your page not using the form, so you will also have to use the Regex static method of IsMatch in your code to assure nobody is playing games:
if (!Regex.IsMatch(txtName.Text,
@"^[a-zA-Z'.]{1,40}$"))
{
// Name does not match schema
}
For more information about validating input in your ASP.NET web applications I highly recommend the article, How To: Use Regular Expressions to Constrain Input in ASP.NET, found here on MSDN.
Encode Input using HttpUtility.HtmlEncode
Often you need to display the user input back to the user on a web page. This is when the HttpUtility.HtmlEncode method comes in handy, which is part of the .NET Framework.
Use the HttpUtility.HtmlEncode method to encode output if it contains input from the user, such as input from form fields, query strings, and cookies or from other sources, such as databases. Never just echo input back to the user without validating and/or encoding the data. The following example shows how to encode a form field.
Response.Write(HttpUtility.HtmlEncode(Request.Form["name"]));
HttpUtility.HtmlEncode essentially converts all HTML special characters to a version suitable for displaying on a browser, such as “<” to < This causes any scripts that were entered into web forms to be interpreted as text as opposed to JavaScript that could cause problems on your website.
Conclusion
Unfortunately we have to go through a lot of effort to assure our ASP.NET web applications are safe from “hackers” who want to cause problems with our application. Cross-Site Scripting is one of those issues. However, by verifying user input using regular expressions and encoding any input that is displayed back to users will keep your application safe if users attempt to add Javascript code where unexpected.
Written by David Hayden (Website / Blog )