testing a PCI patch for 139h

[justlost]

Hello community!

We are in the process of upgrading to zen cart v1.5.0 from 1.3.9h.
Since our upgrade will take some time due to extensive customization done to the cart and due to the fact we are currently failing our PCI scan due to two vulnerability issues I went ahead and wrote a small patch for v1.3.9h to try to make us compliant while in the process of upgrading.

The vulnerabilities we are trying to covers are: CVE-2011-4567 and CVE-2011-4547
NOTE! this has only been tested on one zencart installation and is in no way extensively tested! So I'm posting this here in hopes other devs might want to try it out and test it?. We have yet to pass the PCI scan and are waiting to see if they take our request for an exception using this patch, but I figure I would share this for those of you in the same boat that would like to try and test this.

To apply the patch create a new file at : <zencart root>/includes/extra_configures/pci_patch_custom.php

The code is as follows:

// BOF - Resolves CVE-2011-4567
// see: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4567
if ( pci_key_is_set('message', $_POST) ) {
    $_POST['message'] = pci_sanitizeXSSInput($_POST['message']);
}
// EOF - Resolves CVE-2011-4567

// BOF - Resolves CVE-2011-4547
// see: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4547
if ( pci_key_is_set('main_page', $_GET) || pci_key_is_set('main_page', $GLOBALS)) {
    $_GET['main_page'] = pci_sanitizeXSSInput($_GET['main_page']);
    $GLOBALS['main_page'] = pci_sanitizeXSSInput($GLOBALS['main_page']);
}
if ( pci_key_is_set('PHP_SELF', $_GET)) {
    $_GET['PHP_SELF'] = pci_sanitizeXSSInput($_GET['PHP_SELF']);
}
// EOF - Resolves CVE-2011-4547

function pci_key_is_set($key, &$array) {
    return array_key_exists($key, &$array) && $array[$key] != null && strlen($array[$key]) > 0;
}

function pci_sanitizeXSSInput($input) {
    
    if ( !pci_utf8_validate($input) ) {
        return '';
    }

    // remove NULL characters
    $input = str_replace(chr(0), '', $input);
    // make sure no html entities remain valid
    $input = str_replace('&', '&', $input);
    // remove all tags
    $input = strip_tags($input);
    
    return $input;
}

// borrowed from DRUPAL drupal_validate_utf8
// https://api.drupal.org/api/drupal/includes%21bootstrap.inc/function/drupal_validate_utf8/7
function pci_utf8_validate($input) {
    if ( strlen($input) == 0 ) {
        return true;
    }
    
    // With the PCRE_UTF8 modifier 'u', preg_match() fails silently on strings
    // containing invalid UTF-8 byte sequences. It does not reject character
    // codes above U+10FFFF (represented by 4 or more octets), though.
    return (preg_match('/^./us', $input) == 1);
} 

I would love to hear your suggestions, angry letters, whatever.

[DrByte]

Easier fix:

CVE-2011-4567
Simply replace tpl_gv_send_default.php with the one from v1.5.0 or v1.5.1
The 1.5.x tpl_gv_send_default.php file is backwards-compatible with 1.3.9h, so simply unzipping 1.5.0 and replacing that one file addresses this issue.

CVE-2011-4547
Simply delete the obsolete unused debug file /includes/templates/template_default/common/tpl_header_test_info.php (was never used by any production code ... could only be exploited if someone having server access were to specifically recode their template to use that file, or if .htaccess protections were not in place). The file was never needed for normal use, so simply deleting it is the instant fix.

[justlost]

Ah DrByte!

Yes, those are indeed a lot easier, but we weren't sure if $_POST['message'], etc... were used in the same manner anywhere else. Thus the short patch should take care of anything not seen. But I do agree just deleting/replacing the files is way simpler.