WordPress.org

Make WordPress Core

#50590 closed feature request (duplicate)

.htaccess deny from all auto-blocker if plugin got deactivated + WordPress internal firewall

Reported by: KestutisIT Owned by:
Milestone: Priority: normal
Severity: normal Version: 5.4.2
Component: Security Keywords:
Focuses: coding-standards Cc:

Description

So, from discussion in forums, it appears,
that website may also be hacked via deactivated plugin. So I suggest,
that after a plugin has been deactivated, WordPress would automatically create .htaccess file in plugin's folder with "deny from all" content. That would prevent from non-updated deactivated plugin vulnerability, as often people believes, that they are safe if they got deactivated suspicions plugin, of they tested something and left that plugin on the server as deactivated for years.
Also, there should be WordPress internal firewall, that should show BIG RED WARNING in all WP Admin that WordPress was not able to create .htaccess blocker for some plugin, and that user has to create that file with that content manually.

This would boost WordPress security level to next class.

Change History (6)

#1 follow-up: @carike
17 months ago

:wave:
That could probably work with very low "investment" (time) required, but that would only cover Apache users, correct?
Windows servers allow for a similar file, so that *should be possible too.
What about Nginx servers?

#2 in reply to: ↑ description @jdembowski
17 months ago

Replying to KestutisIT:

So, from discussion in forums, it appears,
that website may also be hacked via deactivated plugin. So I suggest,
that after a plugin has been deactivated, WordPress would automatically create .htaccess file in plugin's folder with "deny from all" content. That would prevent from non-updated deactivated plugin vulnerability, as often people believes, that they are safe if they got deactivated suspicions plugin, of they tested something and left that plugin on the server as deactivated for years.
Also, there should be WordPress internal firewall, that should show BIG RED WARNING in all WP Admin that WordPress was not able to create .htaccess blocker for some plugin, and that user has to create that file with that content manually.

This would boost WordPress security level to next class.

This does not sound like a good proposal as it's not effective for a significant proportion of WordPress installations.

What about the many WordPress installations that use nginx or others that completely ignore .htaccess files? That's just not a comprehensive solution.

#3 in reply to: ↑ 1 @KestutisIT
17 months ago

Replying to carike:

:wave:
That could probably work with very low "investment" (time) required, but that would only cover Apache users, correct?
Windows servers allow for a similar file, so that *should be possible too.
What about Nginx servers?

There is Apache to NGIX converter. Maybe there has to be IF/ELSE case. In case A - .htaccess file is created, on case B - NGIX directive has been created.

There is Apache's .htaccess to NGIX directives converer:
https://winginx.com/en/htaccess#:~:text=About%20the%20htaccess%20to%20nginx,ported%20from%20Apache%20to%20nginx.
It gives 'deny all' directive for NGIX.

#4 @carike
17 months ago

Users on a shared server (which accounts for a very large percentage of the WordPress userbase) do not generally have shell access / do not have the necessary permissions to set NGINX directives.
Do you have a proposal as to how those can be dealt with?

#5 @KestutisIT
17 months ago

Yes, I have. With PHP script you can check if you have access to that 'X' folder or not.
If you still have it, and you see it's NGIX, you put a red warning text saying.

Please immediately contact your server administrator to add this NGIX directive:

/../x-user/.../.../x-plugin/ deny all

The red warning message will help a lot. Also user will always have an option to remove that plugin from server, and red warning will disappear.

#6 @SergeyBiryukov
17 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Hi there, thanks for the ticket!

This was previously discussed in #26273, let's continue the discussion there.

Note: See TracTickets for help on using tickets.