Preventing XSS attacks across site

329 views Asked by At

I need to review quite a large .Net 4.0 project and re-factor to prevent XSS attacks. The first thing I did was to turn on requestValidation for the site, is there anything else I can do at a global level or is this going to be a case of trawling through every page, validating input and html encoding the output.

There are lots of pages, and probably 300 classic asp pages still in use.

Is HtmlEncode() safe to use or do I need to install Microsofts AntiXSS package.

1

There are 1 answers

0
gmaran23 On BEST ANSWER

requestValidation is a good approach.

  1. At a global level one more thing I can think of is enabling X-XSS-Protection header at all http responses. It is easy to implement and gives you some native defences that the browser (IE 8+, Chrome) has to offer based on xss patterns. X-XSS-Protection: 1; mode=block

  2. You may look at Content-Security-Policy, but I think in your scenario it may be a big roll out for the entire site.

Those are something I could think of from a HTTP header based XSS mitigations. They are generic and does not apply just to ASP.Net.

Answering your other question Is HtmlEncode() safe to use or do I need to install Microsofts AntiXSS package from What is the benefit to make encoderType to AntiXssEncoder in a MVC application?

AntiXssEncoder uses a whitelist approach to identify malicious inputs [Inputs that result in Cross Site Scripting (XSS)].

The default encoder in ASP.Net uses a blacklist approach.

Both do output encoding on the data. From a security standpoint a whitelist based approach should always be preferred over blacklist approach for identifying malice.

Excerpt from http://weblogs.asp.net/jongalloway/using-antixss-4-1-beta-as-the-default-encoder-in-asp-net

1.AntiXSS is inherently more secure due to using a whitelist approach. Many security audits and certifications will require you to use a whitelist XSS encoder because a blacklist is always potentially vulnerable to unknown attacks.

2.Newer browsers have better XSS filtering built in, but there are vulnerabilities in older browser (e.g. UTF-7 charset switch) which wouldn't be detected picked up by the ASP.NET default encoder.