My web application is built with ASP.Net MVC5. One of the method accept query string params. Security testing has reported that it accepts malicious query string and displays in the body without any modification.

the url including the Query parameters are added to the html output by the MVCContrib pager for pagination.

detailed description below

The name of an arbitrarily supplied URL parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 7dc29"style="behavior:url(#default#time2)"onbegin="alert(1)"2d524 was submitted in the name of an arbitrarily supplied URL parameter. This input was echoed unmodified in the application's response. This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response. The proof-of-concept attack demonstrated uses a dynamically evaluated expression with a style attribute to introduce arbitrary JavaScript into the document. Note that this technique is specific to Internet Explorer, and may not work on other browsers.

I have a QueryString filter looks for blacklist entries @"</?\w+((\s+\w+(\s*=\s*(?:"".*?""|'.*?'|[^'"">\s]+))?)+\s*|\s*)/?>", "<img", "<iframe", "\";", "¼script¾", "embed src"

also i do sanitize the param using Microsoft.Security.Application.Sanitizer.GetSafeHtmlFragment()

My question: Is it enough to secure the XSS attack? Or how can I remove the malicious query string?

You should not be removing the malicious query string, but you should be encoding it correctly when output in the page. Blacklists are rarely the way to go in security as things are always changing and there will always be a new way around the blacklist discovered.

For example, if outputting an untrusted value to HTML it should be HTML encoded (" becomes &quot;) or if outputting to JavaScript it should be hex entity encoded (" becomes \x22). By untrusted, read any value where you can't guarantee the source (this means query string, form values, headers or even data from your database which you might think is "safe", but a value is only safe when viewed in the context of its output).

Checkout the OWASP XSS Prevention Cheat Sheet for more details on how to appropriately encode per output context.

Don't use any self-implemented filter - the wheel is already invented...!

Filters like what you wrote has several hidden problems like character case. In addition, the White-List approach is always more preferred against the Black-List approach

Use AntiXSS library. It is now built-in in the .NET 4.5, but don't rely on that.Update the package via nuget because previous versions of AntiXSS can be bypassed...! See the following to know how it can be...

http://blog.watchfire.com/wfblog/2012/01/microsoft-anti-xss-library-bypass.html

After that, all you need to do is the following command:

Sanitizer.GetSafeHtmlFragment(suspiciousCode);

And it's enough to remove all tags and get you a clean text...

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.