cefyn:
Upgraded to 1.5.5e ok except admin/products_with_attributes_stock.php disappeared. And I just can't get it back in. Latest version of Stock_By_Attributes_Combined-master. Upload it with Filezilla, it disappears again, and again, and ...again. Tried the file upload in cpanel, and I get "The file you uploaded, products_with_attributes_stock.php, contains a virus so the upload was canceled: YARA.eval_post.UNOFFICIAL FOUND" I've done a scan on it, and of course, there's no virus.
I can only think it's a permissions issue, the file uploads at 664, I try to change it to 644 in Filezilla, refresh the file list and it disappears again. Everything else working ok. Ideas anyone ? Thanks.
There's a few things that look like might cause some sort of response like that, though the things I'm looking at seem to be there to exactly prevent issues/injection.
The first consideration is to remove some additional checks in some of the if statements. For example changing:
in line 54:
if (isset($_POST['products_id']) && is_numeric((int) $_POST['products_id'])) {
$products_id = (int) $_POST['products_id'];
}
to:
if (isset($_POST['products_id'])) {
$products_id = (int) $_POST['products_id'];
}
With similar at lines 114,
changing doubleval(nnn) type statements to type cast the value to float such as in line 184 from:
$products_id = doubleval($_POST['products_id']);
to:
$products_id = (float)$_POST['products_id'];
If those don't resolve the detection of evaluation of the content to appear as if there is an evaluation of the $_POSTed data, then a next possible revision is to remove the direct use of $_POST in some of the operations and first assign a variable to the value of $_POST and then let the function perform the operation on the variable, or in cases where the $db->bindVars or $db->getBindVarValue sanitization is used to instead cast the $_POSTed result to the same type.
For example changing:
line 128 from:
$quantity = $db->getBindVarValue($_POST['quantity'], 'float');
to:
$quantity = (float)$_POST['quantity'];
or beginning on line 428 from:
$query = 'delete from ' . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . ' where products_id= :products_id:';
$query = $db->bindVars($query, ':products_id:', $_POST['products_id'], 'integer');
$db->Execute($query);
to:
$query = $db->Execute('delete from ' . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . ' where products_id= ' . (int)$_POST['products_id']);
// $query = $db->bindVars($query, ':products_id:', $_POST['products_id'], 'integer');
// $db->Execute($query);
Which from recent discussions of PHP 7.1, concatenation of values with strings and type casting probably would have to be rewritten like:
$query = $db->Execute('delete from ' . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . ' where products_id= ' . (string)(int)$_POST['products_id']);
// $query = $db->bindVars($query, ':products_id:', $_POST['products_id'], 'integer');
// $db->Execute($query);
Another example line 444 from:
$query = 'delete from ' . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . ' where products_id= :products_id: and stock_attributes=:stock_attributes: limit 1';
$query = $db->bindVars($query, ':products_id:', $_POST['products_id'], 'integer');
$query = $db->bindVars($query, ':stock_attributes:', $_POST['attributes'], 'string');
$db->Execute($query);
to:
$db->Execute('delete from ' . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . ' where products_id= ' . (int)$_POST['products_id'] . ' and stock_attributes=\'' . (string)$_POST['attributes'] . '\' limit 1';
// $query = $db->bindVars($query, ':products_id:', $_POST['products_id'], 'integer');
// $query = $db->bindVars($query, ':stock_attributes:', $_POST['attributes'], 'string');
// $db->Execute($query);
Those are some ideas that might prevent the response that has been identified but maintain the same level of sanitization that has been incorporated to prevent the possible injection of malicious code. I would be very interested to know which of the above either individually or combined resolved the issue.
I do not know how/why the permission level was set to 664 instead of 644 upon upload. I would suggest looking at the permission level of the other files that are/were uploaded to see if they also are 664 or if they were uploaded to the expected 644 and then attempting to understand what it takes to otherwise upload with a permission level of 644.
