Skip navigation
Currently Being Moderated

QID 90780 FAQ: Microsoft ASP.NET ValidateRequest Filters Bypass Cross-Site Scripting Vulnerability

Created by kb-author-1 on May 4, 2012 5:57 PM - Last modified by Joe Gregory on Dec 4, 2012 2:17 PM

Vulnerability Title: Microsoft ASP.NET ValidateRequest Filters Bypass Cross-Site Scripting Vulnerability

 

CVE ID: CVE-2008-3842 CVE-2008-3843

 

 

When did QID 90780 become a PCI Failing Vulnerability?

It was added to QualysGuard on March 14, 2012 as an urgent request by a large Acquiring Institution and was listed as a PCI Failure immediately.

 

What versions of Microsoft ASP.NET are vulnerable?

Microsoft has confirmed that ASP.NET versions 1 and 2 are both vulnerable.

 

Additionally, Qualys has confirmed that ASP.NET version 3 is also vulnerable, as it includes the vulnerable component from version 2 by default. We have tested this in our Labs and confirmed the exploit works on a fully patched version 3.

 

What versions of Microsoft ASP.NET are not vulnerable?

ASP.NET version 4 is not vulnerable, as it does not use the vulnerable ‘ValidateRequest’ Filter.

 

Applications that have been securely coded, and have custom filtering in place above and beyond the ValidateRequest Filter, may not be vulnerable.

 

How does this vulnerability work?

If you have built a website using one of the above vulnerable ASP.NET Framework versions, and relied solely on the included ValidateRequest Filter for Input Sanitization, then you may be vulnerable.

 

If, however, you securely coded your website, and employed additional custom filtering techniques, then you are likely not vulnerable, since sole reliance on the ValidateRequest Filter for input sanitization is the main risk.

 

It should be noted that Microsoft has stated in their ASP.NET documentation (http://msdn.microsoft.com/en-us/library/ff647397.aspx) that the ValidateRequest Filter should not be used on its own as a security boundary, but should be part of a Defense-In-Depth approach, and that developers should spend the time to securely code their website with additional custom filtering as required.

 

How is Qualys detecting / reporting this vulnerability?

If Qualys detects a vulnerable version of ASP.NET Framework running on the target device, we will report this vulnerability. Typically the Scan Results will show “X-AspNet-Version: 1.1.4322“ for vulnerable v.1 installations, and “X-AspNet-Version: 2.0.50727” for vulnerable v.2 or v.3 installations.

 

Since this is being detected based upon the .NET Framework Version, shouldn’t this be reported as a Potential Vulnerability?

After an in-depth investigation, including discussions with the original publisher, the vendor, and a thorough review of the two published CVE's, we have decided that QID 90780 would be better represented as a Potential Vulnerability, and so we have reclassified it as such.

 

Our detection is based on the remote capability to identify the active framework running on the system. While this does accurately validate the framework version, it does not accurately confirm the presence of XSS, which applies to a higher layer and would be dependent upon several other factors such as web application coding practices, input sanitization, form submissions, etc.

 

In many cases, although someone may be running the vulnerable framework, they may have additional custom built filters in place which mitigate the risk and ensure that XSS is not possible on the target system.

 

In summary, the presence of the Vulnerable Framework actively running is the basis of this vulnerability, which could potentially allow additional attacks such as cross-site scripting. However, this detection is not actively confirming the presence of cross-site scripting, and so we believe this is most accurately marked as a Potential Vulnerability.

 

As a side note, since PCI Requires that both Actual & Potential Vulnerabilities be remediated the same, this is still a PCI Failing Vulnerability.

 

How do we fix this?

The standard solution would be to upgrade to a non-vulnerable framework, such as ASP.NET version 4. ASP.NET version 1 is 10 years old, and version 2 is 7 years old, and so it probably does make sense to migrate to a more current framework for your Internet Facing PCI Infrastructure, which should be kept up to date with the latest versions and security patches.

 

I need to fix this for PCI Compliance, but I can’t upgrade to ASP.NETversion 4. What else can I do?

PCI Compliance is focused on the Real World Risk to Cardholder Data, which in this case is the risk that an application was built without using secure coding practices.  If you have securely coded your application and applied appropriate filtering techniques in relation to input sanitization, this issue may not affect you. A statement confirming that secure coding practices are in use, along with additional filtering above and beyond the ValidateRequest Filter, should allow this to be accepted as a PCI false positive exception.

 

Additionally, as you should already be performing web application specific testing on any applications in the Cardholder Data Environment to satisfy the PCI-DSS Section 6 requirements, Qualys can accept this Web Application specific testing as proof that QID 90780 is not exploitable, and thereby approve this as a False Positive Exception. You can then submit this via the standard False Positive Request Workflow, and then reply to the ticket with your additional proof attached. Acceptable proof could include one or more of the following:

Web Application Scan

Penetration Test

Code Review

Audit

Other

 

My Compliance Report is already due, and I don't have time to address this. What can I do?

You can reach out to your Acquiring Institution and request an Exception. You can submit your PCI Report, and let your Acquirer know you are working to remediate this new issue but you need some additional time to fully address it, and that you expect to have it remediated by your next quarterly report (for example). Reasonable Exception Requests are typically granted by Acquiring Institutions, who understand that PCI Compliance is an on-going process, and it’s not always possible to be 100% compliant all of the time. However, ultimately the decision, and any associated timeline, will be between you and your Acquiring Institution.

 

What if I have a large number of systems with this vulnerability reported? Do I need to provide “Proof” for all of them?

As mentioned above, a statement of compliance and/or proof can be used to accept this as a False Positive submission for PCI Compliance.

 

In the interests of security, we do highly recommend that complete and thorough testing be employed wherever possible. If you are not currently performing Web Application specific testing (a requirement of the PCI Standards), we would encourage you to speak to your QualysGuard Technical Account Manager (TAM) to explore available solutions.

 

What if I have additional questions?

For additional questions please contact your QualysGuard Technical Account Manager (TAM), or Qualys Support at 1-866-801-6161 or support@qualys.com.

Comments (1)