My site:
1.39c
clean install
PHP 5.3.2
PCI Scanner: Trustwave
One of my stores was scanned yesterday, while still at 1.39b, following result:

• Virtual Host: https://www.jerkynet.com
• Date: 2010-05-19 09:47:52.92
• Vulnerable Page:
http://38.113.114.131:80/

store/index.php?main_page=contact_u
s&action=send&zenid=8a3482c20d34fa03da9ed1e8da5021d1
• HTTP Request Mode: post
• HTTP Status Code: 200
• Test Input String: %22%3E%27%3E%3CIfRaME%3E
• Search Pattern: (?i)(?<!")>'><IfRaME>
• Pattern Match: >'><IfRaME>
• Referrer Page:
http://www.jerkynet.com/

store/index.php?main_page=contact_us
&zenid=ed5b5ff24318ed527d3fdf1bdbb20e26
• Vulnerable Parameter: contactname

• Vulnerable Parameter: email

I double checked the patches in extra_configures, all seems to be present there:

771 May 8 08:54 email_use_8bit.php
1972 May 8 08:54 enable_error_logging.php
432 May 8 08:54 media_manager.php
855 May 8 08:54 pci_patch_13x_search.php
2022 May 8 08:54 security_patch_v138_20080919.php

I then updated to 1.39c, and the second store was scanned last night and caught the same PCI MED fail on scripting..... details here:

Evidence:
• Virtual Host: https://www.newgrowth.com
• Date: 2010-05-20 07:54:51.007
• Vulnerable Page:
http://38.113.114.130:80/
ng/index.php?main_page=contact_us&a
ction=send&zenid=f5a36dd26b85b3e8b4abc6af4941708b

• HTTP Request Mode: post
• 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 >
• Referrer Page:
http://www.newgrowth.com/
ng/index.php?main_page=contact_us&a
mp;zenid=4d6e4f5d077b8098e028e376ce500a3d

• Vulnerable Parameter: contactname
• Vulnerable Parameter: email

I also checked that the patch originally found here:
http://www.zen-cart.com/forum/showthread.php?t=125636
is still active and included in my template file.....

Question is, obviously, looking at the result of this scan and running myself, , this is a false pos,, actual email sent looks like this:

From: _ScRipT alert('test');/ScRipT _
Email: [email protected]

alert('test');

Office Use Only:
From: _ScRipT alert('test');/ScRipT _
Email: [email protected]
Login Name: Not logged in
Login Email: Not logged in
IP Address: 66.78.86.78 - 66.78.86.78
Host Address: 66.78.86.78
Date and Time: Thu May 20 2010 6:39:07 PDT

===========
Were we expecting this false pos after 1.39c?
Thought I should bring it here, in the event it meant something to one of you guys......
If there is something I have missed, please let me know.
Thanks!
Dave.......

Thanks. We'll look into it.

jerkynet:

Question is, obviously, looking at the result of this scan and running myself, , this is a false pos,, actual email sent looks like this:

From: _ScRipT alert('test');/ScRipT _
Email: [email protected]

---

alert('test');

---

Office Use Only:
From: _ScRipT alert('test');/ScRipT _
Email: [email protected]
Login Name: Not logged in
Login Email: Not logged in
IP Address: 66.78.86.78 - 66.78.86.78
Host Address: 66.78.86.78
Date and Time: Thu May 20 2010 6:39:07 PDT

===========
Were we expecting this false pos after 1.39c?
Thought I should bring it here, in the event it meant something to one of you guys......
If there is something I have missed, please let me know.
Thanks!
Dave.......
As you have rightfully observed, the content is being sanitized correctly.
So, while the email that is sent/received is undesirable in terms of its content, it is "clean" insomuch as the risks for which the PCI Scan are concerned ... are mitigated already by the cleanup.
However, it's probably reporting a false positive simply because the "SCRIPT" text still shows up, both on-screen and in the sent email. Their scanning is probably looking to see whether "SCRIPT" shows up on the second page. But in reality it should be testing for <SCRIPT ... and in such case it would not throw a warning because we already properly sanitize <SCRIPT as _SCRIPT, which makes it useless as far as XSS risks are concerned.

That said, v1.3.9d is being prepared and has a few updates to avoid a couple new false-positives that are suddenly showing up of late. This release will likely happen within a couple weeks.

In the meantime, you can unzip the attached file and upload the changed files to your v1.3.9c site and ask your scanning company to scan again. I'd be interested in the results, esp whether it raises another false positive or not.

Unable to d/l the zip

jerkynet, you do not have permission to access this page. This could be due to one of several reasons:

1. Your user account may not have sufficient privileges to access this page. Are you trying to edit someone else's post, access administrative features or some other privileged system?
2. If you are trying to post, the administrator may have disabled your account, or it may be awaiting activation.

Grr ... security/privacy protections in this section of the forum are creating limitations.
You can download it here instead: https://www.zen-cart.com/download/139c-pci-fixes-beta.zip

Sorry about the delay, have been putting out fires all week (non zen-cart), by the time I got your d/l, had already submitted for review with trustwave on a "false pos" (if we are all correct, and seems we are) this would mean trustwave (site wide) would put in an allow for the zen-cart result we are seeing, and it will never pop again.....
So, was waiting for them to cruise thru, and after they give me go/no go, will patch the zip, and rescan (if fail), will keep you posted!
Again, sorry for the slow reply!
Dave

Sorry, meant to ask if zen OK w MySQL 5.1.46, thinking about updating server this weekend......

Didn't find any negative on the forums, so assume all is well there, but being in the middle of things, was holding off, not wanting to introduce anything new.

I run ZC on MySQL 5.1.44 without issues.

Not sure this is of much help to anyone, since we all seem to agree this IS a false pos, Trustwave pounded two sites on this server trying to come up with the fail (real fail) and could't, so the appeal was repealed on both. All their tests had all the html sp. characters stripped, so not sure.....note the note on the repeal, seems a bit "open ended odd"

I installed your 1.3.9d patch and the result coming thru was identical.......so question is, if we don't get any html chars thru, what else are we looking for? or they sensing?

Scan DateMay 19, 2010Vulnerability:Cross-Site Scripting (XSS)Severity:MediumDescription:Cross-site scripting is a term used to describe problems which arise when maliciously crafted user data causes a web application to re-direct 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. Services 38.113.114.131: 80 Appeal DateMay 20, 2010 by David Taylor Appeal Category:False PositiveExplanation/Evidence:This file was patched months ago, to aleiviate this issue. Script now nolonger passes <script> tags, or any other dangerous possiblities. ========== Result from me running YOUR tags thru the contact form this am: ========== From: _ScRipT alert('test');/ScRipT _ Email: [email protected] ------------------------------------------------------ alert('test'); ------------------------------------------------------ Office Use Only: From: _ScRipT alert('test');/ScRipT _ Email: [email protected] Login Name: Not logged in Login Email: Not logged in IP Address: 216.99.214.129 - 216.99.214.129 Host Address: 216-99-214-129.static.dsl.aracnet.com Date and Time: Thu Nov 19 2009 8:15:54 PST Also, please see: http://www.zen-cart.com/forum/showthread.php?t=125636&highlight=cross+site+scripting This will show what used to be happening with this form, and the resultant patch that fixed the FALSE POSITIVE. Please remove from my findings, and show as a PASS Please advise????????Response DateJun 1, 2010 Appeal/Repeal Status:RepealedResponse:Based on the information you've provided, we have repealed this vulnerability; please note though that the remediation not fully verified by Trustwave.