You can’t throw a stick into the WordPress community without finding a lot of information about security. Hack this, exploit that, the list goes on. Every WordCamp has a session on security. And companies like Sucuri do a bang-up job of fixing the problem if one does arrive. But what about preventative measures?
The Codex has a great write up on a lot of aspects surrounding security. But a close friend of mine was looking to accomplish something specific: restrict access to the login page to help circumvent brute force attacks. So after looking at core, I realized there is a login_head hook that acts similar to wp_head hook that we’ve all used. The below snippet checks for a specific query string, and if it either isn’t present or doesn’t have the correct variable, the page redirects.
**UPDATE**
After a conversation with a few folks, we realized that if your host doesn’t have output buffering enabled, this will fail. So the function has been modified to use the init hook along with a global $pagenow to check that you are on the login page. Also, there can be some quirks with the logout function itself.
**UPDATE AGAIN**
Apparently I didn’t review the core file close enough, since there is indeed a login_init hook to use, thus avoiding the entire global $pagenow issue all together.
Will this prevent all possible exploits? Nope. Will this alleviate the need to keep core and plugins up to date, and use only secure, well written code? Not in the least bit. But it’s an additional layer that may be useful for some cases.
The Frosty
Not bad, could also do this on init and the
global $pagenowglobal $pagenow;
if ( $pagenow == 'wp-login.php' ) {
//do somthing
}
Norcross
You’re correct. And that also takes care of the issue of output buffering not being enabled.
The Frosty
Thanks for fixing my code. Used to “code” as inline-block and “pre” as block code..
Norcross
No problem. I should probably update the markup to do that.