Page auto-complete stopped working

[MarkE]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

 

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]

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]

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]

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?