I am using v1.3.8.a and my client used trustkeeper scan service.
It is failing on Cross Site Scripting beacuse of the contact_us page.
Any Suggestions?![]()
I am using v1.3.8.a and my client used trustkeeper scan service.
It is failing on Cross Site Scripting beacuse of the contact_us page.
Any Suggestions?![]()
Hi,
This has been reported before as a false positive. Although the form does make use directly of a $_POST variable (which will trigger some scanners) its is sufficiently sanitized in that the email validity check will catch any XSS attempts.
However to bypass the false positive you can change the line in the template
includes/templates/template_default/templates/tpl_contact_us_default.php
withPHP Code:<?php echo zen_draw_input_field('email', ($error ? $_POST['email'] : $email), ' size="40" id="email-address"') . '<span class="alert">' . ENTRY_REQUIRED_SYMBOL . '</span>'; ?>
PHP Code:<?php echo zen_draw_input_field('email', ($error ? $email_address : $email), ' size="40" id="email-address"') . '<span class="alert">' . ENTRY_REQUIRED_SYMBOL . '</span>'; ?>
Note if you have overriden that template. you will need to change the file in
/includes/templates/YOUR_TEMPLATE_NAME/templates/tpl_contact_us_default.php
HTH
Will that only take care of the e-mail field?
the report says:
• 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 >
• Vulnerable Parameter: contactname
• Vulnerable Parameter: email
Thanks
As wilt said, what you're getting is a false-positive. The logic which processes the data already sanitizes the content before sending the emails, meaning that any attempt to insert <script> tags will be thwarted. You can see it just by trying it yourself ... you'll see that the < and > symbols are stripped and replaced when entered in the contactname field, and the email field data is rejected since it doesn't actually contain an email address of the correct form. Making the change suggested by wilt will provide a slight amount of additional visual comfort, but is not strictly necessary since there are additional sanitizations that catch the problem.
That said, the change wilt suggested is incorporated into both the upcoming v1.3.9 and v2.0.0 releases.
In the meantime, report the false positive to your scanning company, and if they don't listen to you, get them to prove the vulnerability manually and supply the exact details of actual risk ... because what you've shared thus far is not a real risk.
And, if you *do* have a real risk, you need to report it in the Security Concerns section of the forum, not the Bug Reports area.
.
Zen Cart - putting the dream of business ownership within reach of anyone!
Donate to: DrByte directly or to the Zen Cart team as a whole
Remember: Any code suggestions you see here are merely suggestions. You assume full responsibility for your use of any such suggestions, including any impact ANY alterations you make to your site may have on your PCI compliance.
Furthermore, any advice you see here about PCI matters is merely an opinion, and should not be relied upon as "official". Official PCI information should be obtained from the PCI Security Council directly or from one of their authorized Assessors.
Thanks for the help guys. wilt's suggestion fixed it and I passed the second scan. I really appreciate the help and quick responses.![]()