Im not exactly sure about that page itself, but BV5 SP7 is PCI compliant. You should check out in updating to that version.

I'm not sure how the contact form would be vulnerable to a cross-site scripting attack. One thing I can tell you is that those scans are always right.

A XSS attack occurs when a value input into a form is displayed on the site and isn't HTML encoded. So for example, if the user inputs a <script> tag in the description field of the form and their answer is displayed it will execute the <script> from the user.

Since you said that your site is heavily customized it is very possible that one of the customizations created an XSS vulnerability.

You'll need to pay a programmer to walk through you customized code to find and resolve the issue. There is no way for us to evaluate the code since it has been customized and is many service packs old.

Most likely you will need to filter your form post yourself or have someone do it for you.
Wondering how ScanAlert would even know if script was injected since what is typed in the form is not displayed unless page has been modified.
Also when you get the the email in stock form all script tags are removed.

They are stating that this page (Contact Us with the form fields) is vulnerable to XSS attacks and cannot be disputed. Is this version of BV supposed to be protecting agains XSS attacks? Here is what they are testing. Any suggestions would be helpful. Thanks.


Cross-Site Scripting (XSS)
Cross-site scripting is a term used to describe problems which arise
when maliciously crafted user data causes a web application to redirect
an unsuspecting web browser to an undesired site. It was
possible to send strings with special HTML characters ( < > " ' )
to your web application, and see them rendered in the response.
Since these characters were not encoded by the web application,
it may be possible to inject HTML scripting code into the rendered
page. The injections can occur in your HTML body, Title, Scripting,
or even commented out portions of the document. Note: Due to the
potential negative impact on this web server's resources that could
result from attacking a large number of cross-site scripting attack
vectors, TrustKeeper abandons this test after it has found at least three
instances where user input is not being properly sanitized. Therefore,
it is possible that the reported findings associated with this vulnerability
are only a subset of all possible attack vectors.
Note: All Cross-Site Scripting vulnerabilities are considered noncompliant
by PCI.
Service: (80) Microsoft-IIS/6.0
Evidence:
• HTTP Request Mode: GET
• HTTP Status Code: 200
• Test Input String: %3CScRipT%20%3Ealert%28%27test
%27%29%3B%3C%2FScRipT%20%3E
• Search Pattern: <ScRipT >alert('test');</ScRipT >
• Pattern Match: <ScRipT >alert('test');</ScRipT >
• Vulnerable Parameter: policyid
• Vulnerable Parameter: linktext
• Vulnerable Parameter: columnname

• HTTP Request Mode: GET
• HTTP Status Code: 200
• Test Input String: %22%3E%27%3E%3CIfRaME%3E
• Search Pattern: (?i)">'><IfRaME>
• Pattern Match: ">'><IfRaME>
Vulnerable Parameter: policyid
• Vulnerable Parameter: linktext
• Vulnerable Parameter: columnname

[3]This just started happening on our site as well, and I have a solution. It is important to understand that PCI is not a fixed set of rules, but a security policy that changes over time and not all PCI scanners are updated at the same time with the latest vulnerability detection (and as pointed out, there are sometimes bugs).[/3]

[3]However, this is definitely a problem with BVC5 (we are using 5.6).[/3]

[3]The issue is due to the fact that request validation has been turned off in the ContactUs.aspx page. However, it was turned off because there is some text being written to the form outside of the context of ASP.NET and therefore postbacks are not allowed without disabling request validation. ASP.NET automatically keeps track of all of the HTML and javascript that is output into the page and keeps a hash of the page<SPAN lang=EN>. When the page is posted back, it checks the HTML in the post against this hash to ensure it hasn't been tampered with by the end user.[/3]

<SPAN lang=EN>[3]However, this automatic tracking of HTML and javascript only happens if controls in the System.Web.UI.WebControls namespace are used. In the ContactUs.aspx page, there is a control used from the System.Web.UI.HtmlControls namespace that needs to be changed.[/3]

<SPAN lang=EN>[3]To fix this problem, change the following:[/3]

<SPAN lang=EN>[3]File: ContactUs.aspx[/3]

<SPAN lang=EN><SPAN lang=EN>[3]Remove the ValidateRequest="false" attribute from the @Page directive at the top of the page.[/3]

<SPAN lang=EN><SPAN lang=EN>[3]Find this lines[/3]

<SPAN lang=EN><SPAN lang=EN>[3] &lt;div id="contactUsInfo" runat="server"&gt;
&lt;/div&gt;[/3]

<SPAN lang=EN><SPAN lang=EN>[3]and change it to be[/3]

<SPAN lang=EN><SPAN lang=EN>[3] &lt;div&gt;
&lt;asp:Literal ID="contactUsInfo" runat="server"/&gt;
&lt;/div&gt;[/3]

<SPAN lang=EN><SPAN lang=EN>[3]File: ContactUs.aspx.vb[/3]

<SPAN lang=EN><SPAN lang=EN>[3]Find the line[/3]

<SPAN lang=EN><SPAN lang=EN>[3] contactUsInfo.InnerHtml += block.Description[/3]

<SPAN lang=EN><SPAN lang=EN>[3]and change it to be[/3]

<SPAN lang=EN><SPAN lang=EN>[3] contactUsInfo.Text += block.Description[/3]

[3]<SPAN lang=EN>
[/3]
[3]No doubt, someone else will need this info and will be scratching their head trying to figure out what is causing this. The scanner provides "detailed" information on the problem, but it isn't always that helpful.[/3]

[3][/3]

[3]NOTE: ValidateRequest is also turned off in many of the BVAdmin pages. Fortunately, because they are behind a login the scanner can't access them. However, if in the future they decide that they will want to scan password protected pages as well, there will be a lot of changes necessary to become PCI compliant again.[/3]