Forums / Installing on a Linux/Unix Server / AdminRequestSanitizer Error Log

AdminRequestSanitizer Error Log

Views: 82,959

Results 21 to 40 of 78
31 Mar 2016, 9:24 AM
#21
swguy avatar

swguy

Administrator

Join Date:
Feb 2006
Location:
Tampa Bay, Florida
Posts:
10,725
Plugin Contributions:
56

AdminRequestSanitizer Error Log

cvhainb:

Add this code on top of edit_order.php

define('DO_STRICT_SANITIZATION', false);


Fixes have been posted; apply them.  DO NOT turn off the XSS patches.

That Software Guy. My Store: Zen Cart Support
Available for hire - See my ad in Services
Plugin Moderator, Documentation Curator, Chief Cook and Bottle-Washer.
Do you benefit from Zen Cart? Then please support the project.

31 Mar 2016, 8:42 PM
#22
lat9 avatar

lat9

Administrator

Join Date:
Sep 2009
Location:
Stuart, FL
Posts:
14,116
Plugin Contributions:
56

Re: AdminRequestSanitizer Error Log

swguy:

Fixes have been posted; apply them. DO NOT turn off the XSS patches.
As I posted in the Edit Orders support thread (https://www.zen-cart.com/showthread.php?200407-Edit-Orders-v4-0-Support-Thread&p=1307492#post1307492), the fix is necessary but insufficient. If you use EO and add a product with attributes, the issue persists.

31 Mar 2016, 11:41 PM
#23
carlwhat avatar

carlwhat

zennedOut

Join Date:
Nov 2005
Location:
los angeles
Posts:
2,972
Plugin Contributions:
8

Re: AdminRequestSanitizer Error Log

i have watched this thread for a bit. i find it amusing/sad that the dev team is forced to change CORE code to make it work with a plug-in; not the other way around.

it would not be so amusing to me if the plugin was good. but as i have expressed in the past, i feel EO is a necessary evil; it is a bloated add-on that sucks to debug; and frankly i do not agree with many of the design choices made in its coding. and to the people who choose to maintain and help others with this plugin, you are far braver than me.

PLEASE PLEASE PLEASE include this functionality in the core for v1.6 so that we can put EO out of its misery.

author of square Webpay, now with Apple Pay and Google Pay.
mXworks
donations: venmo or paypal accepted.
premium consistent excellent support. available for hire.

31 Mar 2016, 11:51 PM
#24
swguy avatar

swguy

Administrator

Join Date:
Feb 2006
Location:
Tampa Bay, Florida
Posts:
10,725
Plugin Contributions:
56

Re: AdminRequestSanitizer Error Log

lat9:

As I posted in the Edit Orders support thread (https://www.zen-cart.com/showthread.php?200407-Edit-Orders-v4-0-Support-Thread&p=1307492#post1307492), the fix is necessary but insufficient. If you use EO and add a product with attributes, the issue persists.

Edit Orders 4 adding a product with attributes doesn't seem to work perfectly whether or not you have this change. I have not been able to get the attributes to show up in the order either way.

That Software Guy. My Store: Zen Cart Support
Available for hire - See my ad in Services
Plugin Moderator, Documentation Curator, Chief Cook and Bottle-Washer.
Do you benefit from Zen Cart? Then please support the project.

1 Apr 2016, 12:05 AM
#25
swguy avatar

swguy

Administrator

Join Date:
Feb 2006
Location:
Tampa Bay, Florida
Posts:
10,725
Plugin Contributions:
56

Re: AdminRequestSanitizer Error Log

carlwhat:

PLEASE PLEASE PLEASE include this functionality in the core for v1.6 so that we can put EO out of its misery.

Changes like this happen because volunteers do the work and submit PRs. Perhaps you?

That Software Guy. My Store: Zen Cart Support
Available for hire - See my ad in Services
Plugin Moderator, Documentation Curator, Chief Cook and Bottle-Washer.
Do you benefit from Zen Cart? Then please support the project.

1 Apr 2016, 12:43 AM
#26
carlwhat avatar

carlwhat

zennedOut

Join Date:
Nov 2005
Location:
los angeles
Posts:
2,972
Plugin Contributions:
8

Re: AdminRequestSanitizer Error Log

swguy:

Changes like this happen because volunteers do the work and submit PRs. Perhaps you?

perhaps... i am trying to spend more time looking as well as following the activity... still have other things on my plate...

author of square Webpay, now with Apple Pay and Google Pay.
mXworks
donations: venmo or paypal accepted.
premium consistent excellent support. available for hire.

1 Apr 2016, 1:00 PM
#27
lat9 avatar

lat9

Administrator

Join Date:
Sep 2009
Location:
Stuart, FL
Posts:
14,116
Plugin Contributions:
56

Re: AdminRequestSanitizer Error Log

swguy:

Edit Orders 4 adding a product with attributes doesn't seem to work perfectly whether or not you have this change. I have not been able to get the attributes to show up in the order either way.
I've got a bunch of clients using EO 4.1.4 on stores with heavy attribute usage and there's never been a problem (before). Perhaps you could add a post to the EO support thread mentioning that you're seeing this behavior and we could help you correct your installation.

Is your posting meant to indicate that all's been done that's going to be done to end EO's misery in the presence of this Zen Cart 1.5.5 change?

1 Apr 2016, 3:33 PM
#28
swguy avatar

swguy

Administrator

Join Date:
Feb 2006
Location:
Tampa Bay, Florida
Posts:
10,725
Plugin Contributions:
56

Re: AdminRequestSanitizer Error Log

lat9:

Is your posting meant to indicate that all's been done that's going to be done to end EO's misery in the presence of this Zen Cart 1.5.5 change?

Your faith in my ability to prognosticate is tragically misplaced. Anyone, at any time, is free to post a patch, submit a PR, update a mod, or submit a new mod. Impossible to predict, the future is.

ATTENTION ALL DEVELOPERS: Please feel free to jump into the fray if you think you have a solution.

That Software Guy. My Store: Zen Cart Support
Available for hire - See my ad in Services
Plugin Moderator, Documentation Curator, Chief Cook and Bottle-Washer.
Do you benefit from Zen Cart? Then please support the project.

1 Apr 2016, 3:36 PM
#29
swguy avatar

swguy

Administrator

Join Date:
Feb 2006
Location:
Tampa Bay, Florida
Posts:
10,725
Plugin Contributions:
56

Re: AdminRequestSanitizer Error Log

lat9:

I've got a bunch of clients using EO 4.1.4 on stores with heavy attribute usage and there's never been a problem (before). Perhaps you could add a post to the EO support thread mentioning that you're seeing this behavior and we could help you correct your installation.

Appreciate the offer. Let me dup the issue on a pristine 1.5.5 + EO test cart to be sure it's not a bad interaction with another change.

Meanwhile, anything you could do relating to the "over preparation" issue in EO as described in the thread below, it would be great.
https://www.zen-cart.com/showthread.php?200407-Edit-Orders-v4-0-Support-Thread&p=1307494#post1307494

That Software Guy. My Store: Zen Cart Support
Available for hire - See my ad in Services
Plugin Moderator, Documentation Curator, Chief Cook and Bottle-Washer.
Do you benefit from Zen Cart? Then please support the project.

1 Apr 2016, 3:57 PM
#30
mc12345678 avatar

mc12345678

Totally Zenned

Join Date:
Jul 2012
Posts:
16,908
Plugin Contributions:
2

Re: AdminRequestSanitizer Error Log

carlwhat:

i have watched this thread for a bit. i find it amusing/sad that the dev team is forced to change CORE code to make it work with a plug-in; not the other way around.

it would not be so amusing to me if the plugin was good. but as i have expressed in the past, i feel EO is a necessary evil; it is a bloated add-on that sucks to debug; and frankly i do not agree with many of the design choices made in its coding. and to the people who choose to maintain and help others with this plugin, you are far braver than me.

PLEASE PLEASE PLEASE include this functionality in the core for v1.6 so that we can put EO out of its misery.

Well, what's somewhat interesting about the situation is that the issue being addressed, is the security of the admin side which through "normal" routes would not be accessible to the problem being addressed by the sanitizer. But regardless of the one plugin, there are likely others that are similarly affected. The effort put forth just goes to show the level of concern to security and applying it to all aspects of ZC. I wouldn't consider addressing this as just trying to get EO to work, but security to work within the routine processes of PHP programming. To date that I know of there has not been a "you may not use the following code/data formats with ZC because ZC doesn't know how to handle that" instruction...

ZC Installation/Maintenance Support <- Site
Contribution for contributions welcome...

1 Apr 2016, 4:17 PM
#31
mc12345678 avatar

mc12345678

Totally Zenned

Join Date:
Jul 2012
Posts:
16,908
Plugin Contributions:
2

Re: AdminRequestSanitizer Error Log

wilt:

Hi

I do have a pending commit that uses recursion.
https://github.com/zencart/zencart/pull/886/files

Doesn't the foreach depend on $item being array, but it seems that there is no check either upon entry into traverseStricSanitize or before/as a part of calling traverseStricSanitize. Ie, is it possiblethat $item could be empty I guess? I can't seem to think where either $_GET or $_POST would specifically equal a value and not some formof an array... Hmmm... Now that I say that though... Use of Super Globals while watching the store front, add a product to the cart, and $_POST which at some point had data is now "empty". Wondering if the issue is similar/related... Otherwise if $item is not an array, could throw it into one?

I haven't been able to test related to this, but it has me curious...

ZC Installation/Maintenance Support <- Site
Contribution for contributions welcome...

1 Apr 2016, 6:07 PM
#32
wilt avatar

wilt

Oji-san

Join Date:
Jun 2003
Location:
Newcastle UK
Posts:
1,927
Plugin Contributions:
3

Re: AdminRequestSanitizer Error Log

The traverseStricSanitize function passes $item by reference, and for the initial entry point uses either $_POST or $_GET and these will always be arrays whether empty or not.

The problem is that something like Edit Orders passes a multi dimension array, where child entries need their own sanitization, rather than using the default strict sanitization and the current admin sanitizer class doesn't support that.

I am working on code at the moment that will allow for defining validation at a more granular level, and hope to have a PR soon

mc12345678:

Doesn't the foreach depend on $item being array, but it seems that there is no check either upon entry into traverseStricSanitize or before/as a part of calling traverseStricSanitize. Ie, is it possiblethat $item could be empty I guess? I can't seem to think where either $_GET or $_POST would specifically equal a value and not some formof an array... Hmmm... Now that I say that though... Use of Super Globals while watching the store front, add a product to the cart, and $_POST which at some point had data is now "empty". Wondering if the issue is similar/related... Otherwise if $item is not an array, could throw it into one?

I haven't been able to test related to this, but it has me curious...

1 Apr 2016, 6:19 PM
#33
wilt avatar

wilt

Oji-san

Join Date:
Jun 2003
Location:
Newcastle UK
Posts:
1,927
Plugin Contributions:
3

Re: AdminRequestSanitizer Error Log

i have watched this thread for a bit. i find it amusing/sad that the dev team is forced to change CORE code to make it work with a plug-in; not the other way around.

This is not what is happening

We are not going to put code into core that adds sanitization for specific Edit Order code parameters
Although I might suggest how EO might work better with core.

The problem is that currently core code does not have sufficient hooks to allow some thing like EO to use our sanitizer correclty.
Thats not EO's problem

1 Apr 2016, 7:55 PM
#34
mc12345678 avatar

mc12345678

Totally Zenned

Join Date:
Jul 2012
Posts:
16,908
Plugin Contributions:
2

Re: AdminRequestSanitizer Error Log

wilt:

The traverseStricSanitize function passes $item by reference, and for the initial entry point uses either $_POST or $_GET and these will always be arrays whether empty or not.

The problem is that something like Edit Orders passes a multi dimension array, where child entries need their own sanitization, rather than using the default strict sanitization and the current admin sanitizer class doesn't support that.

I am working on code at the moment that will allow for defining validation at a more granular level, and hope to have a PR soon

Yeah, I saw the by reference style and when the original reason of not working was identified (multi-dimension array), I was half expecting something along the lines of the following (doesn't use pass-by-reference) and not trying to derail existing coding path:

function return_array_combinations($arrMain, $intVars, $currentLoop = array(), $currentIntVar = 0) {
  $arrNew = array();

  for ($currentLoop[$currentIntVar] = 0; $currentLoop[$currentIntVar] < sizeof($arrMain[$currentIntVar]); $currentLoop[$currentIntVar]++) {
    if ($intVars == $currentIntVar + 1) {
      $arrNew2 = array();
      for ($i = 0; $i<$intVars;$i++) {
        $arrNew2[] = $arrMain[$i][$currentLoop[$i]];  // This is a place where an evaluation could be made to do something unique with a single component that is to be assigned to a single combination as this assigment is for one of the arrays to be combined for one record. If the goal would be not to add anything having this array, then could call continue 2 to escape this for loop and move on to the next outer for loop.  If just want to not add the one array/component to the combination then place the above assignment so that it is bypassed when not to be added. 
      }
      if (zen_not_null($arrNew2) && sizeof($arrNew2) > 0) { // This is a place where an evaluation could be made to do something unique with an array or component as this assigment is one of all arrays combined for one record.  //Still something about this test doesn't seem quite right, but it's the concept that is important, as long as there is something to evaluate/assign that is not nothing, then do the assignment.
        $arrNew[] = $arrNew2;
      }
    } else {
      $arrNew = array_merge($arrNew, return_array_combinations($arrMain, $intVars, $currentLoop, $currentIntVar + 1));
    }
  }

  return $arrNew;
}

It's initiated by passing the array and the number of initial components of the main array, probably could be simplified that small amount further to not need to pass the number of array elements, but when that solution was found for the problem at hand, that was that as it worked and I didn't want to mess it up. :)

It doesn't have/use the additional feature of logging/identifying the "starting" point of the "unrecognized" key, but I thought I would offer some code that has been developed to dig into the depths of an array of an array of an array, etc... recursively.

This was developed to accomplish something similar to the array of array situation, though the conditions are/were a little different as far as the earlier build of action based on condition to perform the next/same action with the next group... The problem being addressed/resolved was:

          if ($intVars >= 1) {
          //adds array combinations
          // there are X variables / arrays
          // so, you need that many arrays
          // then, you have to loop through EACH ONE
          // if it is the LAST variable / array
          // you need to add that variable / array VALUE
          // and ALL PREVIOUS VALUES to the multi-dimensional array
          // below supports up to 7 variables / arrays
          // to add more, just copy and paste into the last for loop and go up from $n is the last one
          for ($i = 0;$i < sizeof($arrMain[0]);$i++) {
          if ($intVars >= 2) {
          for ($j = 0;$j < sizeof($arrMain[1]);$j++) {
          if ($intVars >= 3) {
          for ($k = 0;$k < sizeof($arrMain[2]);$k++) {
          if ($intVars >= 4) {
          for ($l = 0;$l < sizeof($arrMain[3]);$l++) {
          if ($intVars >= 5) {
          for ($m = 0;$m < sizeof($arrMain[4]);$m++) {
          if ($intVars >= 6) {
          for ($n = 0;$n < sizeof($arrMain[5]);$n++) {
          if ($intVars >= 7){
          for ($o = 0; $o < sizeof($arrMain[6]); $o++) {
          $arrNew[] = array($arrMain[0][$i], $arrMain[1][$j], $arrMain[2][$k], $arrMain[3][$l], $arrMain[4][$m], $arrMain[5][$n], $arrMain[6][$o]);
          }
          } else {
          $arrNew[] = array($arrMain[0][$i], $arrMain[1][$j], $arrMain[2][$k], $arrMain[3][$l], $arrMain[4][$m], $arrMain[5][$n]);
          }
          }
          } else {
          $arrNew[] = array($arrMain[0][$i], $arrMain[1][$j], $arrMain[2][$k], $arrMain[3][$l], $arrMain[4][$m]);
          }
          }
          } else {
          $arrNew[] = array($arrMain[0][$i], $arrMain[1][$j], $arrMain[2][$k], $arrMain[3][$l]);
          }
          }
          } else {
          $arrNew[] = array($arrMain[0][$i], $arrMain[1][$j], $arrMain[2][$k]);
          }
          }
          } else {
          $arrNew[] = array($arrMain[0][$i], $arrMain[1][$j]);
          }
          }
          } else {
          $arrNew[] = array($arrMain[0][$i]);
          }
          }

ultimately, every combination of the original array is addressed; however, the original variable was a single depth array each item having one set of keys with a matching value, but ultimately an array of arrays is built. Don't know if it helps at all... I'm not in a position to tie into the file being addressed here.

ZC Installation/Maintenance Support <- Site
Contribution for contributions welcome...

2 Apr 2016, 11:46 AM
#35
wilt avatar

wilt

Oji-san

Join Date:
Jun 2003
Location:
Newcastle UK
Posts:
1,927
Plugin Contributions:
3

Re: AdminRequestSanitizer Error Log

So one of the reasons Edit Orders is broken with reference to the sanitizer
is when attempting to add a new product to the order(as has been mentioned elsewhere in the thread) .

It breaks because EO uses a post parameter called 'id' to pass a multi-dimensional array.
However the sanitizer already adds the 'id' parameter to a Sanitization Group that converts the parameter to an integer, which obviously destroys the
array structure in EO.

I mentioned in the [documentation](https://docs.zen-cart.com/Developer_Documentation/v1.5.5/code_docs/admin_sanitization#parameter-naming) for the Sanitizer the need for developers to be careful with parameter naming.

However, I also realize that forcing developers to have to rewrite code to address parameter naming could be onerous and likely to introduce bugs initially, and could delay store owners in adopting v1.5.5, if popular contributions are not updated.

As I mentioned previously, I am working on a rewrite of the sanitizer to make it more granular, and I’m also exploring some changes to the data structures that would allow contributions to override sanitizing of a parameter on a per page basis.
2 Apr 2016, 1:03 PM
#36
lat9 avatar

lat9

Administrator

Join Date:
Sep 2009
Location:
Stuart, FL
Posts:
14,116
Plugin Contributions:
56

Re: AdminRequestSanitizer Error Log

@wilt, I'm in the process of incorporating various bug-fixes into Edit Orders. Would changing that 'id' parameter to have some other name be enough to "pass" the sanitizer?

2 Apr 2016, 9:45 PM
#37
lat9 avatar

lat9

Administrator

Join Date:
Sep 2009
Location:
Stuart, FL
Posts:
14,116
Plugin Contributions:
56

Re: AdminRequestSanitizer Error Log

lat9:

@wilt, I'm in the process of incorporating various bug-fixes into Edit Orders. Would changing that 'id' parameter to have some other name be enough to "pass" the sanitizer?
I'll answer my own question: Yes.

I've got an updated version of EO on GitHub (https://github.com/lat9/edit_orders) that includes that work-around.

5 Apr 2016, 1:55 PM
#38
wilt avatar

wilt

Oji-san

Join Date:
Jun 2003
Location:
Newcastle UK
Posts:
1,927
Plugin Contributions:
3

Re: AdminRequestSanitizer Error Log

Hi.

In one way, yes it would.

Changing the parameter name to something that does not already have a sanitizer assigned will force that parameter to be sanitized
by the filterStrictSanitizeValues (if strict sanitize has not been disabled)

For the id parameter (renamed attr_info in your github) this is probably OK.

However here's another gotcha

In edit_orders, I can edit the product name and on submit this uses the
$_POST[update_products] field
Because this has no sanitizer ascribed to it, it gets the recursive filterStrictSanitizeValues applied
However we normally allow some html in product names, which filterStrictSanitizeValues will break

@wilt, I'm in the process of incorporating various bug-fixes into Edit Orders. Would changing that 'id' parameter to have some other name be enough to "pass" the sanitizer?
lat9:

I'll answer my own question: Yes.

I've got an updated version of EO on GitHub (https://github.com/lat9/edit_orders) that includes that work-around.

5 Apr 2016, 2:26 PM
#39
lat9 avatar

lat9

Administrator

Join Date:
Sep 2009
Location:
Stuart, FL
Posts:
14,116
Plugin Contributions:
56

Re: AdminRequestSanitizer Error Log

@wilt, thanks for the update. In thinking about the id => attr_info name, it occurred to me that there might be additional gremlins that are brought out in that renaming, since EO tries to keep in the storefront naming (i.e. the attributes are POST'd in the id variable) there might be additional issues with that renaming.

I'll see what I can do using the sanitizer overrides ...

5 Apr 2016, 2:32 PM
#40
lat9 avatar

lat9

Administrator

Join Date:
Sep 2009
Location:
Stuart, FL
Posts:
14,116
Plugin Contributions:
56

Re: AdminRequestSanitizer Error Log

lat9:

@wilt, thanks for the update. In thinking about the ***id ***=> attr_info name, it occurred to me that there might be additional gremlins that are brought out in that renaming, since EO tries to keep in the storefront naming (i.e. the attributes are POST'd in the id variable) there might be additional issues with that renaming.

I'll see what I can do using the sanitizer overrides ...
... reading the documentation, it looks like I'm :censored:

if you are writing a plugin and use a parameter name that already exists in Zen Cart that parameter will be sanitized according to the group it is already assigned to in core code

Since the ***id ***parameter is already sanitized, is there no hope?