C# – a good way to prevent websites from xss attacks

asp.netcSecuritywebformsxss

I am using C# web forms with asp.net 4.0. This website needs to be secure and is going through a security audit now. I am just wondering what needs to be done to best prevent XSS attacks to my website.

I know that there is encoding avaliable for the output of the site. I have also looked into antixsslibrary.dll from microsoft but this seems outdated to me. Does asp.net have any built in prevention of xss attacks? I am lead to think that it does since I am trying to create and xss attack on my own website and I get the error:

Server Error in '/GNB.DPS.MVAD.Presentation.Web' Application.

A potentially dangerous Request.Form value was detected from the
client (ctl00$cphListBody$tbXSS="alert('XSS V…").
Description: Request Validation has detected a potentially dangerous
client input value, and processing of the request has been aborted.
This value may indicate an attempt to compromise the security of your
application, such as a cross-site scripting attack. To allow pages to
override application request validation settings, set the
requestValidationMode attribute in the httpRuntime configuration
section to requestValidationMode="2.0". Example: . After setting this value, you can then
disable request validation by setting validateRequest="false" in the
Page directive or in the configuration section. However, it is
strongly recommended that your application explicitly check all inputs
in this case. For more information, see
http://go.microsoft.com/fwlink/?LinkId=153133.

Exception Details: System.Web.HttpRequestValidationException: A
potentially dangerous Request.Form value was detected from the client
(ctl00$cphListBody$tbXSS="alert('XSS V…").

Best Answer

There are tools provided by ASP.NET that allow you to defend against XSS attacks, but not automatically. You need to know what the attacks are, and how to use the tools to defend against them.

The error you showed is a default setting that attempts to block bad user input as it is coming in to the web app. That's a nice step, but don't let if give you a false sense of security. There are other ways for bad input to get into your data and therefore make your site vulnerable.

For example, say your website is driven by user data. The data entry screens you wrote may block "potentially dangerous content" but there's nothing to prevent someone from using another interface to enter the data - their own interface, SQL Server Management Studio, etc. If they get bad scripts in there, your website will happily present those dangerous scripts to users.

The only way to protect against XSS is to sanitize data as it is being put out to the browser, NOT as it is coming in.

The most basic method is to use the buil-in Server.HtmlEncode() function to clean all strings that come from untrusted sources. (Untrusted meaning anything other than strings you've hard-coded yourself. Databases, files, and web services are NOT trusted sources.)

There are limitations to what Server.HtmnlEncode can do. I personally like to use the Microsoft Anti-Xss library, as it does a better job (whitelist vs. blacklist filtering) and offers more functions (like GetSafehtmlFragment()).

There are tons of resources on the web for this. I'd start here:

https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet

and then specifically here for .NET:

http://msdn.microsoft.com/en-us/library/aa973813.aspx

Edit - added

The primary issue at hand here seems to be a misunderstanding about the difference between input filtering and output filtering. This article does a good job of explaining the difference and uses better than I could here:

http://jeremiahgrossman.blogspot.com/2007/01/input-validation-or-output-filtering.html

Final edit and then I'll stop.

Even Microsoft acknowledges what I'm saying above. See this article: http://msdn.microsoft.com/en-us/library/ms998274.aspx

from the article:

Do Not Rely on Input Sanitization

A common practice is for code to attempt to sanitize input by filtering out known unsafe characters. Do not rely on this approach because malicious users can usually find an alternative means of bypassing your validation. Instead, your code should check for known secure, safe input. Table 1 shows various safe ways to represent some common characters.

Input validaiton is one tool in your defence arsenal, but alone it is not sufficient.

Related Topic