Feature request

Andreas,

https://mydomain.com/?author=2

should normally redirect to:

https://mydomain.com/NICKNAME

Assuming there is a Nickname specified (that is not equal to the username) for the user profile with ID 2.
If author pages redirect correctly there really is no need for your feature request.

Also the iTSec plugin already offers 2 settings in the WordPress Tweaks section of the Settings page that more or less deals with this topic.
These settings are “Force Unique Nickname” and “Disable Extra User Archives”.

dwinden

hi dwinden,
i double checked it: sadly wordpress does not redirect to /author/nickname (if provided), it redirects to the real username

so
“Force Unique Nickname” does not help

and
“Disable Extra User Archives” only kicks in, if an author did not write any posts.

“Disable Extra User Archives” would be the right option for eliminating this security risk, but it would be necessary to add a “disable archive even if author did write posts” checkbox.

or easier and better: “disable user archive if the url is called with user id”. meaning:
author urls with ids (like ?author=1) would get blocked, author urls with (nick)names like /author/nickname would pass.

would it be possible, that this feature gets into iThemes security?

best regards

Ok let’s dig a little bit deeper …

Do you have permalinks enabled ?

Did you test in a standard WP 4.2.2 env using a default theme (like Twentyfifteen) and no plugins ? (I did).

I guess your result comes from your website which is using theme x and probably several plugins …
Oh, did you buy your theme or was it a free download from somewhere on the internet ?

Could be your theme or a plugin is messing with the author URL using the author_link filter …

Have a look at the WP core code of the get_author_posts_url() method in the includes/author_template.php file.

The get_author_posts_url() method returns the author URL … after the author_link filter is applied …

Find out why your author URL redirects to REALUSERNAME, fix that and then forget about this feature request.

dwinden

– i installed a fresh copy of wordpress 4.2.2
– i did not install any plugin
– i did not change or install a theme (it’s the preselected Twentyfifteen)
– i changed the permalinks to /%postname%/
– i created a new user “testuser”
– after saving i changed the nickname and public name of “testuser” to “testuser-nick”
– i logged in with the testuser
– i created a new article
– in the frontend i browsed to the new article.
– in the meta data, i see “testuser-nick” as the author => that’s ok
– BUT: it links to /author/testuser (should be /author/testuser-nick)
– Additionally if i visit /?author=2 i get redirected to /author/testuser (should be /author/testuser-nick)

did you try to create a new user? does it really work for you in a plain/clean wp install?

i checked the database and the problem seems to be, that the urls /author/username are generated through the field value of the wp_users table field “user_nicename”!!!
and this is wrong, because you can’t change the user_nicename filed, only the display_name field.

so it’s a wordpress problem!

the user_nicename must be regenerated every time the nickname changes. but wp is missing this.
i’ll write a plugin and report the issue

… or maybe this could be the new feature added to iThemes Security? ??

I think the “Force Unique Nickname” setting of the iTSec plugin is already taking care of this …
So this setting actually does more than what one would expect based on just its name …
(Rechecking my testing env also revealed I was not testing in a clean WP env as I thought. iTSec plugin was installed and activated … apologies for the confusion).

Check the code behind the “Force Unique Nickname” setting in the force_unique_nicename() function of the class-itsec-tweaks.php file.
Also notice the name of the function:

force_unique_nicename()

So in a nutshell:

Author page redirect is using user_nicename field value from wp_user table.
WordPress is not updating the user_nicename field in the wp_user table
when updating a user profile (not in sync with nickname).
However the iTSec “Force Unique Nickname” setting seems to take care of this … again apologies for the confusion.

dwinden

One last important detail (actually 2):

wp_user.user_nicename = sanitize_title(wp_usermeta.nickname)

So this is not (always) true:

wp_user.user_nicename = wp_usermeta.nickname

Example:

nickname = ‘bla bla’
user_nicename = ‘bla-bla’

Also note that as there is no nickname input field in the create new user form the iTSec plugin “Force Unique Nickname” setting makes the Firstname
and Lastname fields REQUIRED.
The values of these 2 fields are then used to create a nickname (and
user_nicename).

dwinden

hi dwinden,
thanks for the info.
and that’s great news, that iTSec is fixing the wordpress security hole in this case and nearly a perfect solution.

however: i’ll try to contact wordpress. i can’t believe they leave such a great security risk open to hackers for easy username gathering.

best regards,
andreas

I totally agree with you that such security issue should be fixed in WP core.

BUT … take the WP Dashboard login screen as an example …
There are (and have been for quite some time) some serious security issues there … which still are not addressed by WP core code.

The thing is WP core code is so flexible that all these issues can be solved using plugins and extend\correct\improve the WP core code.

So allthough I totally agree with you I doubt whether you should put any time or energy into this … just my thoughts

Anyway I think we can wrap this topic up. If you agree please mark the topic as ‘resolved’.

dwinden

i wrote an email to the wp security team. because this issue appears to be present and known since years, like you i don’t think that they will change anything.
but i wanted to give them a chance to respond and fix this issue before i’ll spread it in the net and call attention to it by all wordpress users who don’t know about it.

surely plugins can be used for this. but i can’t believe wordpress is shipping with security holes and propagating the use of plugins to fix them.

each plugin itself could be a security risk, each plugin makes the site slower and harder to maintain. each plugin could have side effects.

i see we both agree with each other, but i have to try getting this one fixed at least ??

@dwinden,
i must add this one to this topic:

today i received the answer to my email to wordpress.com. please sit down before reading:

“
WordPress does not consider usernames to be secret, and as you’ve pointed out, actively uses them in URL slugs such as /author/realusername. For this reason we do not consider username enumeration via /?author=1, /?author=2, etc to be a security vulnerability. If you would like to change this behaviour, plugins are available in the repository to block such requests.
“

it’s unbelievable. wordpress is responsible for about 60% of all open CMS in the world.
and they are shipping security holes with the intention to be fixed by third party plugins (which themselves could lead to other security holes).

i’m speechless….

The complete opposite to wordpress’ point of view (ship with security holes, let users deal with it), seems to be the new drupal 8:

https://www.drupal.org/drupal8-security-bounty

there the “User enumeration” is clearly on the list. A huge list and the involvement of the community.
That’s how it should be …

Indeed an uncommon point of view.

Basically what they are saying is that WP accounts are only protected by a password. So where generally speaking strong passwords are important for security, for WP it is even more important …
And as the WP login screen allows endless login attempts no wonder the most popular attack vector for WP CMS is brute forcing …

If my bank told me there is only a password between internet criminals and my bank account (no matter how strong the password) I would go and switch to another bank immediately … ??

dwinden