Page auto-complete stopped working

MarkE · November 28, 2019

Page auto-complete has just stopped working on my site. It is still working on my dev machine (with the same code) - I've copied the live database to the dev machine and it works there. All the other page-select methods work OK, so my temporary work-round is to change the selection method for the affected fields - but this is rather messy for fields where there are a great many pages to choose from.

Any ideas? I'm wondering if my hosting service might have changed something to do this, but I can't think what. There are no error messages or logs - the field is just unresponsive when I type into it.

I'd be most grateful for any clues or suggested lines of enquiry.

dragan · November 28, 2019

1 minute ago, MarkE said:

There are no error messages or logs

Did you check your browser JS console as well? Keep an eye on the network tab as well (you can filter by XHR).

MarkE · November 28, 2019

3 minutes ago, dragan said:

Did you check your browser JS console as well

I have now!

Failed to load resource: the server responded with a status of 403 ()

(for address ncorchards.co.uk/admin123/page/search/for?..........etc)

MarkE · November 28, 2019

Playing around with the url which gets the 403, it works until I get to the parameter

&get={firstname}%20{lastname}%20-%20{email}

In other words, the following is not forbidden:

https://ncorchards.co.uk/admin123/page/search/for?&templates_id=64&status<2048&limit=50&format_name=autocomplete_list_members

but adding the &get=... parameter results in the 403

dragan · November 28, 2019

Well, that's strange. Seems like your hoster prohibits a query with "get" (?).

When you said "logs": did you refere only to PW-logs, or also Apache logfiles? Check both.

You could also add ?get={firstname}%20{lastname}%20-%20{email} to any other PW page (FE + BE) and see if the same happens.

MarkE · November 28, 2019

It seems like its the %20 that's causing the problem - but it never has before - I wonder what they can have done. Nothing in any logs.

netcarver · November 28, 2019

Try posting the same URL but with the '%20's replaced with a '+'.

Have you - or the hoster - added any rules to the htaccess file, or enabled any security modules?

MarkE · November 28, 2019

It's not at all clear what's causing it. Removing the %20s or replacing them with + doesn't work. Here is a list of tests:

?abc=abc&get={xxx}%20{xxx} - forbidden
?abc=abc&get={xxx}{xxx} - OK
?abc=abc&get=xxx%20xxx - OK
?abc=abc&get={xxx}%20xxx - forbidden
?abc=abc&get={xxx}+{xxx} - OK
/search/for?&templates_id=64&status%3C2048&limit=50&format_name=autocomplete_list_members - OK
/search/for?&templates_id=64&status<2048&limit=50&format_name=autocomplete_list_members&get={firstname} - forbidden
/search/for?&templates_id=64&status<2048&limit=50&format_name=autocomplete_list_members&get=firstname - OK
/search/for?&get={firstname} - OK

(%3C gets replaced by < in browser URL)

?

I haven't touched .htaccess or any settings on cPanel. The .htaccess file on the live site just differs from the website because cPanel adds the php7.2 settings:

# php -- BEGIN cPanel-generated handler, do not edit
# Set the “ea-php72” package as the default “PHP” programming language.
<IfModule mime_module>
  AddHandler application/x-httpd-ea-php72 .php .php7 .phtml
</IfModule>
# php -- END cPanel-generated handler, do not edit

# BEGIN cPanel-generated php ini directives, do not edit
# Manual editing of this file may result in unexpected behavior.
# To make changes to this file, use the cPanel MultiPHP INI Editor (Home >> Software >> MultiPHP INI Editor)
# For more information, read our documentation (https://go.cpanel.net/EA4ModifyINI)
<IfModule php7_module>
   php_flag display_errors Off
   php_value max_execution_time 120
   php_value max_input_time 480
   php_value max_input_vars 1000
   php_value memory_limit 128M
   php_value post_max_size 20M
   php_value session.gc_maxlifetime 1440
   php_value session.save_path "/var/cpanel/php/sessions/ea-php72"
   php_value upload_max_filesize 20M
   php_flag zlib.output_compression Off
</IfModule>
<IfModule lsapi_module>
   php_flag display_errors Off
   php_value max_execution_time 120
   php_value max_input_time 480
   php_value max_input_vars 1000
   php_value memory_limit 128M
   php_value post_max_size 20M
   php_value session.gc_maxlifetime 1440
   php_value session.save_path "/var/cpanel/php/sessions/ea-php72"
   php_value upload_max_filesize 20M
   php_flag zlib.output_compression Off
</IfModule>
# END cPanel-generated php ini directives, do not edit

Looks like I need to raise an issue with the hoster?

MarkE · November 28, 2019

Looks like my friendly hosting provider installed new security without telling the customers:

"This site is hitting a firewall security rule: COMODO WAF: URL Encoding Abuse Attack Attempt"

I got them to disable it, but I wonder whether others might hit the same issue? @netcarverDoes it raise questions about PW's use of url parameters?

Quote from hoster:

"We automatically update our firewalls with the latest security rules provided by multiple vendors to ensure they are as effective as possible."

Macrura · November 29, 2019

I have this problem on at least 2 sites, and i knew it was the security rules doing it.

We're migrating these off to VPS so hopefully it won't be an issue;

In the meantime we just don't use the custom field format for the display of the selected pages, and that fixes the issue because it doesn't use those params.

netcarver · November 29, 2019

Just noticed this post on the issues-repo that might happen to fix the above as it contains a space -> "+" mapping.

Untested, might be worth a shot.

dragan · November 29, 2019

19 hours ago, MarkE said:

"This site is hitting a firewall security rule: COMODO WAF: URL Encoding Abuse Attack Attempt"

A quick search for this COMODO stuff returned this interesting result: https://help.comodo.com/topic-212-1-514-5943-.html

Apparently, you can fine-tune which rules to activate or not. Perhaps it's possible to narrow down the firewall rule*, and de-activate it on PW-admin pages / URLs. Whether your hoster allows this, is of course another question...

* I guess it's #950107 from https://www.netnea.com/cms/2016/01/17/most-frequent-false-positives-triggered-by-owasp-modsecurity-core-rules-2-2-x/

MarkE · November 30, 2019

7 hours ago, netcarver said:

Just noticed this post on the issues-repo that might happen to fix the above as it contains a space -> "+" mapping.

That's useful to know about, but my tests showed that a simple %20 -> + fix would still have got a 403. Exactly how the rule operates, and therefore what if any replacement might defeat it, is not clear to me.

MarkE · September 13, 2021

Seems like the best fix for this is to add

<IfModule mod_security.c>
  SecRuleEngine Off
  SecRequestBodyAccess Off
</IfModule>

to the .htaccess file.

I wonder if this should be provided (commented out) in the default PW file?

Pasta Gronkomatic · September 16, 2021

On 9/13/2021 at 8:43 PM, MarkE said:
Seems like the best fix for this is to add
<IfModule mod_security.c>
  SecRuleEngine Off
  SecRequestBodyAccess Off
</IfModule>
to the .htaccess file.

Can confirm this resolved the issue for me.

Any thoughts on security implications?

Sign In

Page auto-complete stopped working

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Create an account or sign in to comment

Create an account

Sign in

Recently Browsing 0 members