What is a good way to prevent websites from xss attacks

I am using C# web forms with asp.net 4.0. This website needs to be secure and is go开发者_开发百科ing 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...").

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.

You could take a look at the Microsoft Web Protection Library on CodePlex. You can also have a look at the XSS page on OWASP as well as the cheat sheet.

In addition to the previous answers: The message you got was produced by the RequestValidation feature of ASP.NET. It tries to filter malicious content for example in the QueryString.

While it is a good start, it is not secure enough for you not to worry about scripting attacks anymore.

Also note that RequestValidation is disabled by default in ASP.NET 4.0: http://geekswithblogs.net/bbastiaensen/archive/2010/12/13/request-validation-in-asp.net-4.0.aspx

Personally, I don't like the RequestValidation feature. Basically, it's guessing whether or not a string of text entered by the user might be harmful. You can't count on it catching every possible attack string. This could also result in errors when the user types in legitimate values in your form.

Here's the problem. Let's suppose that your web site displays rows of text that are input by visitors.

I, as a malicious user, type in <script>window.location='http://www.grossout.com'></script>.

If this text is output directly to the browser the next time someone visits your web site, they will be redirected to www.grossout.com.

On the other hand, a friendly visitor might type in This is a cool web site <:-).

The next time someone visits your web site, they will receive malformed html because of the < character.

In this example, the best solution is probably to use the Server.HtmlEncode() method which will escape the < character so that it will display correctly without breaking your page.

If you are using JavaScript, you can use the jQuery .text method to escape the < character.

I believe that both solutions are superior to using the RequestValidation because they allow for any text to be displayed without causing the user to see an error message.