Hide Backend

same issue here, i enabled the “Hide Backend feature” but i’m able to access via

mysite.com/wp-login.php

while the feature should prevent it…or i’m wrong? How you have fixed it?

Why the topic is set as Resolved?

• This reply was modified 6 years, 1 month ago by acu80.

Having the same issue here. Really don want the wp-admin.php file accessible.

• This reply was modified 6 years, 1 month ago by bbyford.

According to the 6.3.0 Changelog:

Important: The way that Hide Backend functions changes in this release. Previously, if your Hide Backend Login Slug was wplogin, going to example.com/wplogin would result in the URL remaining example.com/wplogin. The new implementation of this feature results in a redirect to a URL that looks as follows: example.com/wp-login.php?itsec-hb-token=wplogin. While this may not be desireable for some users, this change was necessary to fix longstanding compatibility issues with other plugins. Once you access the login page using the Login Slug page, a cookie is set with an expiration time of one hour. As long as the cookie remains, you can access example.com/wp-login.php without having to access the Hide Backend Login Slug first. If you wish to confirm that Hide Backend is working properly on your site, opening up a private browsing window is a quick way to test without having to log out and clear cookies.

I’m using 7.2.0 on one of my client’s sites and it’s letting me access the login page with wp-login.php. I was able to in incognito mode in Chrome, private mode in Firefox and I’m still seeing bots access the page in the logs.

It seems to work fine on all other sites, but not this one for some reason. I’ve deactivated all plugins that have anything to do with member, access and redirects. Just basic plugins like CF7, Yoast, Custom Post Type UI, ACF, etc.

What’s interesting is going to /admin and /wp-admin.php do redirect to the “not found” page but wp-login.php still works for everyone.

@sgarcia513
What happens when you try https://www.domain.com/wp-login (without .php) ?

Oh, and what web server and what version of that web server are you using ?

• This reply was modified 6 years, 1 month ago by nlpro.

Hi nlpro,
Going to /wp-login (withoug .php) redirects to the not_found page so it looks to be specific to only wp-login.php.

Server info:
PHP 7.0.33
Litespeed 7.2
MySQL 5.0.12

This is one of about 25 WordPress sites on the server all running iThemes with backend hidden. Only this site is having issues with it. Unfortunately, this is site that’s being marketing worldwide so it gets a lot of brute force attacks which is why I’m trying to limit it to save our server.

Ok, I see.
So it must be something specific for that site.

You are sure the brute force attacks are coming in through the wp-login.php page ?
It’s not brute force through xmlrpc.php ?
You can see this in the iTSec plugin Logs page (Details link).

Yes, I’ve already diasabled xmlrpc a few months ago, all logs are showing wp-login.php.

I didn’t originally change the back-end URL at that time as we have quite a few editors on the site and I was already having them change the way they were writing they’re posts so adding a new URL probably would have spurred a revolt.

Is there a debug I can enable to see where it may be failing or getting overridden?

Is there a debug I can enable to see where it may be failing or getting overridden?

I think the best thing to do is to look at the line of code where the iTSec plugin Hide Backend feature is supposed to block any wp-login.php request. Been there before so here it is:

87 } else if ( in_array( $request_path, array( 'wp-login', 'wp-login.php' ) ) ) {
88	   $this->handle_canonical_login_page();
89 } else if ( 'wp-admin' === $request_path || 'wp-admin/' === substr( $request_path, 0, 9 ) ) {
90	   $this->handle_wp_admin_page();

(The code above is from the handle_specific_page_requests() method in the better-wp-security/core/modules/hide-backend/class-itsec-hide-backend.php file)

I’ve included 2 extra lines of code, which helps in comparing the conditional statement for wp-login.php with the ones for wp-admin (yes these are handled separately). As you can see the wp-login.php condition (which is processed first) makes use of the php in_array() function while the wp-admin condition does 2 string comparisons. All conditions compare with the content of the $request_path variable.

So if you can check the content of the $request_path variable before these conditions are evaluated then you might (theoretically) be able to see why the wp-login.php condition is not met (while the wp-admin condition is met). Then take it from there.

One extra observation. The handle_specific_page_requests() method is hooked into the WordPress init hook at priority 1000 … which is kind of late. The default is 10. Don’t really think its relevant since the wp-admin condition works fine but still wanted to mention it for the complete picture.

Thanks for the info!

I added a simple print_r($request_path) on line 88 and visited the page and it came back with wp-login.php.

That tells me two things, the conditional is being met and that it’s returning with a single matched value.

I looked further down at the handle_canonical_login_page() function to see if I get any value for $action and it doesn’t return anything.

Took a look at the block_access function to see if I get any kind of data within it. Tried to echo out $this->settings[‘theme_compat’] and $this->settings[‘theme_compat_slug’] to see if those exist. I’m not getting anything returning in that function. Just trying to echo out ‘test’ brought nothing.

**Edit: spoke too soon. I put the echo line on line 195, but it had returned out one if statement earlier at 191. Here’s what gets echo’d out:

echo $this->settings[‘theme_compat’].” : “.$this->settings[‘theme_compat_slug’];
1 : not_found

Not sure if that’s a proper test or not, but just trying to find where the hang-up is.

Thanks

• This reply was modified 6 years, 1 month ago by sgarcia513.
• This reply was modified 6 years, 1 month ago by sgarcia513.

Ok, I see.

Try and disable the Enable Redirection setting in the Hide Backend module through the plugin ui.

If that resolves the issue accessing wp-login.php should now result in:

This has been disabled.

Got it. There’s some strange caching going on in the site so it took a while for it to change even in Chrome Incognito mode but it looks like it’s showing “This has been disabled”

That should be enough, we don’t need it redirecting as long as it keeps attacks, the error page will work.

Thanks for your help!

@nlpro, your explanation of the cookie, and why wp-login.php was accessible is correct. I was seeing it because I checked the login slug just before, and hence that file is accessible. Thank you!