Microsoft ASP.NET Request Filtering Bypass Cross-Site Scripting Vulnerability

Reply

manzoo1979 Posted: 06-08-2009 9:29 AM

rated by 0 users

"Microsoft ASP.NET Request Filtering Bypass Cross-Site Scripting Vulnerability"

Following high security vulnerability is being detected for one of my web site in the production. We need to fix the issue immediately. When I went through the Fix section of the report, it say to handle it in the code using HttpUtility.HtmlEncode() function. Will using   HttpUtility.HtmlEncode()  remove the Vulnerability or will it just ensure safety and still Vulnerability will persist? Is there any other way of handling it? Here is the piece of code that is throwing this exception. What is the best way to handle it?

    function fnModelDetails(varId)
    {
      
        var filepath = 'ModalBox.aspx?modelfileid=' + varId +'&mod=30&page=Associated Model Names';       
        var screenSettings = 'help:off;status:off;resizable:no;dialogHeight:' + 400 + 'px;dialogWidth:' + 400 + 'px;';
        window.showModalDialog(filepath,'',screenSettings);
        return false;
    }

Any help on this will be be great.

Thanks in advance.

Manjunath

Reply

Chris Sullo replied on 06-25-2009 8:42 PM

rated by 0 users

Manjunath--

If I understand your question completely, you have a few options with what you could do here.

1. use HttpUtility.HtmlEncode() which will encode the potentially dangerous characters with HTML-encoding. See the Microsoft documentation on it for more information. This will preserve whatever the use entered, but make it "safe" for HTML (so cross-site scripting should no longer work). If it is decoded at any point, it could return to a dangerous string depending on how it is used (in page output, sql queries, etc.).
2. White-list and reject the request. If your varId is well defined (i.e., it can only be numeric), you could check its value before calling fnModelDetails() and if it contains non-numeric values, reject the value entirely and do something like send an erorr or redirect the user.
3. White-list and filter the request. Again, if varId is well defined, you can remove any characters that do not meet the criteria. However, you can then process the request as normal, though the results may not be as the user expected.

I can't stress enough that you don't want to black-list (that is, remove "dangerous" characters), as that is never a complete solution.  See tons of Google results for discussions on white-list vs black-list filtering, if you need more information.

Reply

brite_crawler replied on 06-26-2009 1:46 PM

rated by 0 users

I would definitely say whitelist and reject rather and try to filter.  Plus, as already said, HTML encode HTML output if it came from user input, database, or a file and URL encode any URL strings that are returned.  Microsoft has a good [sic] article on this titled, "How To: Prevent Cross-Site Scripting in ASP.NET":

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

Reply

whips04r replied on 06-30-2009 12:29 AM

rated by 0 users

Keep in mind that care needs to be taken when escaping outputs depending on the output context. The OWASP XSS prevention cheatsheet explains this very well:

http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

As you can see, ESAPI provides a few methods to adequately encode for various output contexts:

encodeForHtml

encodeForHtmlAttribute

encodeForJavaScript

encodeForCSS

encodeForURL

In your case (as per the code you provided), you are not just outputting into HTML but into a URL within HTML.

There's an alpha release available of OWASP ESAPI for Classic ASP: http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Classic_ASP