sqlpatch.php blocked by webhost
My webhost as part of improving security is now automatically preventing sqlpatch.php from running.
I ask them to remove that restriction and it works fine for a couple of weeks until the next update and its back again.
Just wanted to know if there is any downside to renaming this file to something else, (and the text file definitions also)?
It seems to run fine if renamed to something else?
Re: sqlpatch.php blocked by webhost
It's too bad that they've decided to block legitimate scripts instead of properly getting all the offending sites (running old insecure versions) to upgrade.
Yes you can easily rename it and its language file and its filename definition.
Re: sqlpatch.php blocked by webhost
Quote:
Originally Posted by
DrByte
instead of properly getting all the offending sites (running old insecure versions) to upgrade.
I can tell you, I wish it was that easy
Re: sqlpatch.php blocked by webhost
Quote:
Originally Posted by
Merlinpa1969
I can tell you, I wish it was that easy
Understood.
Alternate ideas that would be more effective than what the OP is being subjected to:
Instead of only blocking "sqlpatch.php" they could block a more specific pattern like:
- "/admin/sqlpatch.php" since that would catch nearly all the vulnerable sites fairly accurately, or at least those who've not obscured the foldername, and the ones that have obscured have probably done some patching anyway and aren't as vulnerable.
- "sqlpatch.php/forgotten_password.php" since it's a specific attack vector
- or any other combination of multiple ".php" mentions in the URI since it would be rare to have a valid use-case for that
There are LOTS of much smarter ways of specifically dealing with the problem rather than wimping out and blindly setting up a block which shows they've done little research to actually understand the issue at hand.
Or if they want to protect themselves by getting the offending customers who are using old software to stop using old software, they could take direct measures on sites that have traces of old versions lingering on their accounts:
- OBSOLETE SINCE 1.3.9a: /admin/includes/function/sessions.php
- OBSOLETE SINCE 1.3.9a: /extras/curltest.php
... and other similar evidences.
They could even apply a combination of both, ie: only apply the "blocking" rules on accounts that are clearly running the old software. That's likely to be less work (and probably easily automated) than dealing with all the support tickets that get logged because the account is suddenly unexpectedly blocked because of overzealous protections that aren't even relevant to the software being used by non-troublesome accounts.