Allow For execution of code before login processing

[Another Guy]

The problem at hand is hardening and filtering people who are attempting to log into a wordpress site WITHOUT using htaccess and without invoking the full wordpress core. The issue comes from people making brute force attacks on a wordpress installation, either while attempting to post comments on a site that has "user must be logged in" checked, or who are just trying to gain access.

The underlying issues are cloudflare (and similar services) as well as the server load created in dealing with a brute force attack. The IP address of someone coming to your wordpress site cannot easily be checked at the htaccess level (as you will see only the cloudflare node serving them which is shared). They fix this by providing the origin IP in the headers, which can be accessed in PHP. This means, however, that htaccess is not an option for sites using cloudflare.

Second is the question of serverload. wp-login.php (as an example) immediately starts up pretty much the full of wordpress. That means that code is loaded, database connections are made, and so on. Get a few hundred (or a few thousand) requests a minute and your server melts and honest users cannot access your site.

Additionally, many wordpress installations are either maintained by a single person, small group of people, or from a single corporate location. It is the ultimate in good security to limit access to the login area to only those who need to use it.

My solution is adding code at line 10 in both wp-login.php and /admin/index.php to pre-check the IP address and to only permit the small group of people who are allowed on the site to even attempt to log in. All of the others are either sent to a "denied" page, forwarded to other locations, or sent to 127.0.0.1.

What I would like to suggest is that a hook is placed in these areas to a new file, called (say) wp-pre-login.php which would be called at line 10 in each case. This code could process ANYTHING that the site owner chooses to do before login and would happen before any wordpress code is actually executed, and before any database connections or other activities happen.

It may also be equally interesting to apply a similar system to comment processing. Currently, limiting comments by country or language is not very easy to achieve. it's also impossible to completely shut off comments. It would be extemely beneficial to allow for pre-comment processing to occur.

[chriscct7]

I think close as wontfix. The problem with adding a hook before WordPress loads is that WordPress isn't loaded, so you can't have a filter that does anything there. If you can't use htaccess because of a brute force protection, the brute force protection should be protecting against this exact behavior, and also could offer this feature to their users

[Another Guy]

Sadly, Cloudflare (and other similar services) generally will not allow you to outrightly block people, only require them to answer a captcha or similar to approve themselves. it's also almost impossible to automated it, requiring manual intervention.

Just to give you the scope of the issue, using a log file that logs a single line:

201.46.50.xx / 188.114.98.xx - ​http://domain.com/wp-login.php - wp-login detect

I have had to reset the log file twice, with over 50 MEG of log entries for a single MU installation. At about 10 entries per 1K of file size, you can start to understand the scale of the issues at hand. Being able to process that many requests BEFORE the core of wordpress is started (including all the database connections and all) has a significant positive impact on server load. So having those hooks available so that significantly hardened security can be put in place without having to hack core code is a very good and positive thing.

[chriscct7]

Replying to Another Guy:

So having those hooks available so that significantly hardened security can be put in place without having to hack core code is a very good and positive thing.

I don't think you understood the issue with this proposal. Without loading WordPress the actions and filters APIs don't exist. The only way to add a hook there would be to load WordPress first, which is the problem you're trying to solve in the first place. Its a circular issue.

At the end of the day this is a issue the service should deal with. With regular htaccess files you can deny from all except for a given set of ips.

[dd32]

One way of achieving the proposed idea is to simply put your custom code in your wp-config.php file.
For example, I've used similar code to the following before:

if ( '/wp-login.php' == $_SERVER['REQUEST_URI'] && isset( $_POST['log'] ) && 'admin' == $_POST['log'] ) {
   die();
}

[Another Guy]

DD32: Actually, that comes close to it, but still requires that some pre-processing is done. Also, it would still be in the nature of a "hack" rather than something properly sanctioned. Also, your code would be executed on every page load (every time config is loaded) rather than being restricted to only areas where interaction can take place (logins, comments, etc). While your solution is interesting, it's still a hack and not a proper application.

chriscct7: The point is that the code would be executed before any part of wordpress is loaded. I put it (as an exmaple) at line 10 in wp-login.php. That is before the bootstrap is called. That means I am dealing with the incoming connection, all of it's request headers, methods, and such, and I can choose to filter based on any and all of them - including the actual IP and not the cloudflare network IP provided.

As for htaccess, as I mentioned before, Cloudflare (and other cache services) replace the user IP and country with their own IP, which means you CANNOT use htaccess to control who can and cannot access different parts of your site. Those IPs are shared with many users, so you cannot block one without blocking many.

[chriscct7]

Forget about Cloudflare. Forget about why you even want a hook there. It doesn't matter.

For the purpose of this ticket, what Cloudflare does and does not offer, and what they do with htaccess files is irrelevant.

Please focus on the actual issue with your proposal which I pointed out in comment:1 and comment:3.

What are you asking for is simply impossible.

Replying to Another Guy:

chriscct7: The point is that the code would be executed before any part of wordpress is loaded. I put it (as an exmaple) at line 10 in wp-login.php. That is before the bootstrap is called.

Think about what this means. You want a hook before WordPress's bootstrap is loaded.

Before the bootstrap is loaded, WordPress's Actions and Hook APIs are not available. Which means we can add all the do_actions and add_filter's you want there, but they cannot be used (in fact they will fatal error because the function for both of those haven't been defined). In reading your responses, I'm not convinced you've grasped the problem with your proposal on this subject, and this is the reason your proposal cannot work.

The only way for you to do what you're seeking to do is exactly what DD32 suggested, because the wp-config file is loaded before the bootstrap and is not overridden on WordPress updates. That is your one, and your only option here.

What you've asked for, a hook before the bootstrap, simply cannot be done, and for that reason closing as suggested as invalid.

[Another Guy]

"Before the bootstrap is loaded, WordPress's Actions and Hook APIs are not available. Which means we can add all the do_actions and add_filter's you want there, but they cannot be used"

I guess I am not making this clear. I DON'T WANT TO USE WORDPRESS FUNCTIONS. I want to be able to execute code BEFORE wordpress runs, to allow for simple hardening and filtering of access to certain areas of an installation BEFORE wordpress is even started.

"The only way for you to do what you're seeking to do is exactly what DD32 suggested, because the wp-config file is loaded before the bootstrap and is not overridden on WordPress updates. That is your one, and your only option here."

And that is a "hack" and not generally supported. What I am proposing is a way to help secure a wordpress installation without having to first invoke all that comes with wordpress, at a level where someone with basic PHP knowledge can write clear and concise filters to control access to key areas of a wordpress installation. Want to limit logins to a single country? No problem. Want to limit access to your ISP only? No problem. Want only allow people using Firefox to login (say that's all you use in your office)? No problem. Want to keep people from countries not using the language of your blog from posting comments? No problem. Want to stop comments from certain countries, or only limit comments to your home country? No problem.

All of those things are POSSIBLE in htaccess, but require a skill level much higher than most people have, and one simple slip up in a regex can have the exact opposite effects.

Heck, Automattic could even get into the game by having code available for aksimet which could be added to pre-filter comments before they even have to be checked for spam. Why even let a known spammer have access?

There are plenty of things you could do. Sticking it in wp-config may be functional, but is a clear hack and not something that would be widely supported by wordpress. Moreover, it still requires that the process of starting the bootstrap occurs, which defeats the purpose, and would have this code run every time a page is accessed, even if it's NOT for a secured area, area of input (comments), and the like.

I don't have any intention of using wordpress functions. The entire point is to NOT invoke wordpress and not even allow bad actors the chance to get to the site unless you permit them.

[knutsp]

I think this enhancement proposal was closed for mostly wrong reasons or a misunderstanding, but why ...

The only way for you to do what you're seeking to do is exactly what DD32 suggested, because >> the wp-config file is loaded before the bootstrap and is not overridden on WordPress updates. >> That is your one, and your only option here.

And that is a "hack" and not generally supported.

... is that a hack and not generally supported?

Editing wp-config.php for your own needs is not a hack, it's encouraged for people with the necessary knowledge of PHP and WordPress. You can even include another php script. You can do the checks (like is wp-admin/ or wp-login.php requested?) and then do the request filtering.

I sometimes do such things in there because I find it too difficult to do in .htaccess. And on other server types I wouldn't have much clue.

In a very secure setup and a large organization I wouldn't allow wp-config.phpto be edited locally by every developer, and would place it in the folder above public_html, having it include a more freely editable php file in the public_html folder. Or vice versa, putting the secrets of wp-config.php in a special included file with edit restrictions.

In my view, you should be able to do anything on the php level from in there, knowing that wp-config.php is always included before the rest of WordPress.

[Another Guy]

@knutsp : wp-config is a configuration file, which is used to set variables and parameters. It's generally NOT where any real code is run. Moreover, it's loaded on every page load, which means that any additional security code or filtering code would be run by every visitor, every page. I tend to want to find the elegant solution that hits only the needs, and doesn't add any negatives to the rest of the system performance.

I guess what I was hoping for was a "wp-secured-areas.php" or similar included at the start of any code which has user input or interaction (process comments, logins, registration, etc) and not have to have that code pulled into every page view. Codifying it and making it exist as a standard piece would allow for new and different approaches related to securing a wordpress installation.

thanks