Batch Add triggering ModSecurity

[axel621]

I'm having an issue with using Batch Add at my hosting provider, running under shared Windows hosting, with CPG 1.5.48.
The issue is not with CPG per-se, but with the ModSecurity rules at the provider, which they refuse to change.
I think I have a workaround, but I'm not sure if I might be creating other problems by doing so.

The issue is in loading the minibrowser.php file, when called from searchnew.php for Batch Add (not tested under any other conditions).
The hosting provider has been no help whatsoever, but my testing indicates their ModSecurity rules are kicking in and blocking the page (HTTP 406 error) due to the Query Parameters "startfolder" and "limitfolder".
My guess is that they don't like the local file paths.

I'm not a webdev by any means, but I've found line 640 in searchnew.php where it appears to build the request URL for minibrowswer.php:

Code Select Expand


echo '<iframe src="minibrowser.php?startfolder='.$iframe_startfolder.'&amp;parentform=choosefolder&amp;formelementname=startdir&amp;no_popup=1&amp;limitfolder='.$iframe_startfolder.'&amp;linktarget='.$CPG_PHP_SELF.'&amp;searchnew_php=1&amp;radio=0" width="95%" height="400" name="popup_in_a_box"></iframe>'.$LINEBREAK;


I've tested by removing the two noted parameters, and it then nominally appears to work, even starting at the correct \albums\ location.
However, I'm a big fan of Chesterton's Fence, so I'm concerned that I may be creating a problem I can't foresee here.

Can anyone comment on my issue, or my proposed resolution?

[ron4mac]

You could try url encoding the folder path where it is set just above the 640 line area:

Code Select Expand

    $iframe_startfolder = urlencode(str_replace('searchnew.php', '', __FILE__) . rtrim($CONFIG['fullpath'],'/') . $folder_sep);

Please let us know if that makes a difference.

I also recommend that you upgrade to CPG1.6.x and use its upgraded file upload methods.

[axel621]

Thanks for the suggestion, ron4mac. Unfortunately, it didn't work.
I could see the altered URLs resulting from the change, but the host still rejected it due to ModSecurity.

Could a relative path be used instead of an absolute one, and could that make a difference?
The values for the two parameters are e.g. X:\folder1\folder2\domain\httpdocs\gallery\albums\ currently.

[ron4mac]

Relative paths would, indeed, probably avoid the mod_security trigger and it should likely have been coded that way from the beginning. Most of the batch upload code is quite old .. written a long time before I became involved with CPG. I've never been a fan of the batch upload feature but I did some wading through the code. I feel both the 'startfolder' and 'limitfolder' parameters can be eliminated from the url with no negative effect now nor in the future. The 'startfolder' is actually not used for anything.

I am not maintaining CPG 1.5 but I have removed those parameters for the next release of CPG (1.6.13).

Thanks much for your excellent feedback and problem resolving!

[axel621]

Awesome, thanks ron4mac, that sounds good enough to me.
Moving to 1.6 will be the next project after getting this migration finished

Thank you for your kind words, and much appreciate your time and efforts!

[axel621]

For record completeness, in case this occurs for anyone else, I was finally able to get (partial) confirmation from the technically incompetent provider (Reseller Club) that my guesses were correct.
They are using Atomicorp's web application firewall, and the rule being triggered is WAF 340009, due to a "protected path" being in the URL or arguments:
https://wiki.atomicorp.com/wiki/index.php/WAF_340009

I did some quick testing, and it appeared to be only due to the word "inetpub" being present (the location didn't seem to matter, nor the presence of drive letters).
I would assume you might see the same issue for other installs, including Linux, from other default path names the rule checks.

I updated the searchnew.php file to remove the startfolder and limitfolder query parameters, and all seems to be fine!