[Resolved] Change to URL Query String on Invalid Login

[Author]

Posts

[leeF-2]

I've noticed that when we use the "User Login" form to allow users to login - and the user enters an invalid email, the query string passed to the next page includes the error that includes the email and that it is invalid.

This seems like a huge security issue - allowing the user to confirm that an email is not valid... even though the error displayed on the login page after redirection back to it says "ERROR: Unknown error".

There may be a way to stop this from happening that I am unaware of. But I am suggesting that this be removed to make it harder for hackers to learn why a login has failed.

Otherwise, providing a method to capture that error and then redirect or take other action that keeps the URL string from containing that data would be a smarter way to handle it.

Thanks.

[leeF-2]

Here is a screenshot of what I am talking about.

[Beda]

I understand, but it's not that WordPress handles this any different.
Let's log in to a vanilla WordPress site with a Wrong Email, and a correct password and you'll see what I grabbed in the Screenshot.
It says, the email is invalid.

Hiding this is relatively simple with:

function no_wordpress_errors(){
  return 'Something is wrong!';
}
add_filter( 'login_errors', 'no_wordpress_errors' );

Since Toolset basically uses the native WordPress log in mechanisms and offers the native filters as well, it's expected that with Toolset you would not get different result.

Now, to avoid having the URL parameter as you show it in the report, there is currently no setting or method publicly documented to achieve this within Toolset itself.

In our code, if the redirect is set, which is set anyway if the login fails for some reason, then we add the URL parameter with:

$redirect_url = add_query_arg(
			array(
				'username' => $username,
				'fail_reason' => $user->get_error_code()
			),
			$redirect_url
		);

We seem to not add any filters there to stop that (for example, so it could listen to the "no_wordpress_errors" function above and optionally strip those values).

I am not sure if we can offer that as I do not know what for we actually need those details in the URL.

I will check this with the DEV and feedback to you.

[leeF-2]

Hello Beda,

Thanks for that great explanation. And yes, that would be awesome if there was a way to strip the URL Query String. I did try a redirect back to the main URL (with no query string) if it saw one - but that yielded an infinite loop for some reason.

Thanks for following up on this. I would think in today's "hacker filled" world, we'd like to give them ZERO information to go on, in order to make it tougher for them to find a way to get in.

Thanks again!

[leeF-2]

Hello Beda,

I also noticed something - the above function to disable (or change) login errors only works on the "wp-config.php" page. If one uses a custom login page, this filter does not seem to fire. I added it to my functions.php file, and then tested again in a new incognito window, and the result was the same as originally shown. Reading the hook information on the WP Codex page about this hook, it says that it works on that page - presumably ONLY on that page from what I can see.

Since I'm using a custom page for front-end logging in, it appears to ignore that hook.

[Beda]

I did not test that, I will, during the coming debug process, or my colleagues will.

We will find some solution and decide if we can implement this

Thanks!