PCI-DSS Security Vulnerability in .NET <all versions>

[b3n]

One of our clients has recently run into a problem with their scanning company, whereby a pre-existing vulnerability has been upgraded to a serious threat, which is causing Able to fail the PCI-DSS scan. Specifically, the vulnerability is with the ValidateRequest feature of ASP (see here, from 2008)

The scanning company has agreed with our diagnosis; there is no fix for this on a site running .NET 2/3/3.5 on Server 2003. They've therefore explained that they'll listen to the argument: Our site is not vulnerable because... And this is where I was hoping for some advice from an Able expert!

Any pointers from anyone? Anyone come across this since the acquiring bank who requested this flaw be upgraded to serious did so in March? The scanning company admits they're talking to a lot of angry customers because of this, so hopefully someone in the Able community has seen this.

[Logan Rhodehamel]

AbleCommerce by default does not even use the validateRequest parameter. It interferes with the needs of our application so if you look in the web.config file, we have disabled it site wide. Instead we have server side validation and sanitize all user inputs - we never trust users to give us something that can be used directly. In reading the post from the company, it appears that the failure is triggered simply by seeing the HTTP runtime version in the response header. It would not be possible to have a website on < .NET 4 pass a scan no matter how it was coded. Something about that doesn't seem very helpful to me.

To fix the scan from the forum you linked, it appears you can make a change to the web.config to hide the http runtime version from the output. That would make the scan not trigger the vulnerability.

You could also upgrade to .NET 4 if it's a more recent version of AbleCommerce where support for that framework was enabled.

[Logan Rhodehamel]

AbleCommerce by default does not even use the validateRequest parameter. It interferes with the needs of our application so if you look in the web.config file, we have disabled it site wide. Instead we have server side validation and sanitize all user inputs - we never trust users to give us something that can be used directly. In reading the post from the company, it appears that the failure is triggered simply by seeing the HTTP runtime version in the response header. It would not be possible to have a website on < .NET 4 pass a scan no matter how it was coded. Something about that doesn't seem very helpful to me.

To fix the scan from the forum you linked, it appears you can make a change to the web.config to hide the http runtime version from the output. That would make the scan not trigger the vulnerability.

You could also upgrade to .NET 4 if it's a more recent version of AbleCommerce where support for that framework was enabled.

[jmestep]

You can take out the runtime information in the header by changing the HTTP Reponse Header for you website in the IIS Manager.

[dgoranov]

From our experience with different PCI scanning vendors we found that each vendor has its own definition of which vulnerability is
critical and which can be treated as a non-critical warning. Almost all scanning vendors use the same Nessus scanning templates for
scanning and then based on the output generate pci-dss scanning reports.

http://www.tenable.com/products/nessus/ ... t-overview

There are more than 150 pci scanning vendors - McAfee and Comodo Hackerguardian are the most popular. Some merchant providers and merchant banks have
re-seller agreements and require the pci scan to performed from a specific scanning vendor, so they can get additional commissions.

https://www.pcisecuritystandards.org/ap ... endors.php

If your client is not required to use specific scanning vendor they can just use a different scanning vendor and get the same configuration certified with no server side changes.