New Core Sitemap DISCLOSES USER IDs
-
I updated one of my sites with WP 5.5 only to discover the horrificly BAD DECISIONS that were made implementing this.
1. There are NO SETTINGS. Which means if I have secret categories (used to manage post placements, say, in a slider for instance), they are disclosed and I can’t do anything about it. If there are categories I reserve for my LOGGED IN users or any specific category of users, they are disclosed with a simple sitemap request. OH MY GOD! Someone didn’t think this through!
2. The USER ID’S ARE DISCLOSED!!!!!!!! That’s half the way for any hacker trying to pry in. I typically use the Stop User Enumeration plugin on my sites, but now, WP Sitemap discloses those to anyone requesting the sitemap HOW STUPID IS THAT? 2000% STUPID.
So now: When are you going to give us a settings interface and, MORE IMPORTANTLY, a DISABLE option.
- This topic was modified 4 years, 3 months ago by MarieDi. Reason: typo
-
If you use an SEO plug (like Yoast, for exampe), you can control your sitemaps.
To turn off the core sitemap altogether, click “discourage search engines” under SETTINGS->READING. Note that it will block crawling by searchbots.
@mariedi There are filters to remove certain sitemaps (e.g. users): https://make.wordpress.org/core/2020/07/22/new-xml-sitemaps-functionality-in-wordpress-5-5/
Just to add a note. Checking “discourage search engines” do not block searchbots.
It only does two things – it places a directive for search engines not to crawl your site (but they can and some do disobey) and it stops Core from generating Sitemaps.Others have already indicated the three possible ways to disable sitemaps by Core, which are checking the “discourage search engines” setting (which is probably not the right choice for you, since you do want some items to be indexed, to overwrite the Sitemaps filter and / or to install an SEO plugin to allow you more granular control over your Sitemaps.
Usernames are not secrets. Disclosing them is not a legitimate security issue.
But, if you don’t want the user pages sitemap, then that’s easily done with a simple line of code:
add_filter( 'wp_sitemaps_add_provider', function ($provider, $name) { return ( $name == 'users' ) ? false : $provider; }, 10, 2);
I share your concern with WordPress exposing User IDs and User logins, but in the case of core sitemaps, I don’t think the concern is warranted.
The URLs in the users sitemap are the same as those used for “Author Archives” that are displayed by many themes.
By default, the “author archive” URL for a given user contains the
user_nicename
field of the user (sometimes called the “author slug”) and not the user login. If pretty permalinks are not enabled, then the URLs will contain User IDs. However, since the author slug defaults to the user login, in practice for many sites, the URLs will contain user logins.That’s why I always recommend setting the author slug to something other than the user login (and have done so long before sitemaps were added to core). A plugin such as Edit Author Slug can be used to change the author slug, although if you have a lot of users on your site doing that for each existing user can be time consuming.
There are also filters provided in core that can be used to set the author slug whenever new users are added, but I think that’s beyond the scope of this topic.
I hope this helps.
First, I don’t use Yoast and don’t plan to. Second… Are you serious? You are actually telling me to hide my sites from search engines? Seriously?
Maybe a DECENT core sitemap would have been in order before you enforced it on all of us without warning?I strongly disagree with you.
My themes NEVER show authors archives, and the core WP sitemap shows actual user IDs. I manage too many sites to go and manually change all of this.
This sitemap is horrible.
@otto42 and @carike, thanks, but this should have been thought out before WP rolled out a sitemap without settings. Access is made of UserID + Password. So User ID IS part of the security and removing it is bad. I have sites that are regularly under attack and the first thing they try to find is the User ID. So by default I install the Stop User Enumaration plugin to make it a bit more difficult for them. Now just asking for the sitemap will give a 4 y.o. access to all the User IDs.
@pidengmor, @otto42 and @carike: I’m NOT a coder. I DON’T WANT to touch code. MOST WP USERS use WP specifically BECAUSE they don’t have to touch code. And now v.5.5 has been rolled out WITHOUT ANY sitemap UI/settings except for coding. Even the instruction page you sent me to @pidengmor (thanks for that, it’s a good reference), assumes that I know WHERE to go for those codes. I don’t. MOST users don’t. Someone, somewhere, forgot that, apparently.
Add the code Otto suggested to your active theme’s
functions.php
file, or ideally that of a child theme so it doesn’t get overwritten on update. Or, you can use a plugin to add the code: https://wordpress.org/plugins/code-snippets/. Or, add a sitemap plugin for more granular support: https://wordpress.org/plugins/search/sitemap/- This reply was modified 4 years, 3 months ago by barnez.
I hope Barnez’ reply answers your question. If it doesn’t, let us know.
I really understand that you are upset and frustrated – and likely feeling that your concerns are not being heard.
The thing is, Steve was really just trying to help, as was everyone else in this thread.
Suggesting that you try Yoast is not an insult – it is a viable suggestion. If it isn’t one you want to take – that is okay too.
WordPress is a huge ecosystem. Not everyone involved in this discussion was involved in the discussions about Sitemaps – and not everyone who was involved agreed with the implementation. But who is who when it comes to that does not matter right now.
Please be courteous to volunteers here. Let’s try to focus on helping you to find a solution.@mariedi To address your point, no, username is not part of security.
The username is an identifier. It’s not a secret. The password is the secret, and the security lies there. Making your password stronger is far more important than having hard-to-find usernames.
I can explain this to you by example:
Imagine that username was to be considered secret. The general way people think about this is that two secrets are better than one. Twice as hard to login, right? Hackers must crack two fields instead of just one.
However, if two secrets are better, then we could say that instead of having secret usernames, we could keep the username not secret and simply add another password field. Usernames are already not stored hashed, and we find them useful for user listing pages and so on, so simply having a second password is the same thing as having both of them be secret. It’s the same security, since hackers still have to crack two fields.
But remembering two passwords is tricky, so we want password managers to be able to remember them for us. No password managers remember two password fields on a page. So for simplicity, let’s combine those two passwords into one field, so that it can be password1+password2. Then password managers can remember our long combined password and even put it in for us.
So, now we have one username field, and one big long password field. Voila, more secure. 🙂
See, having more secrets doesn’t help security any, because the existing password can be of any length. WordPress will take a password up to 4096 bytes long, so simply making it unguessably long isn’t that hard to do. Using a secure password manager means that it doesn’t need to be remembered either. And username, is thus, irrelevant.
Note that we’re not the only ones who feel this way. Your username here is that @name beside your posts. Your username on Twitter is right in your URL. Your username on reddit is your handle there. Your username for Facebook is in your URL, although Facebook, like Google, doesn’t really use usernames for logging in, they just use your email address to login. Is your email address also a secret? Because everybody who you send an email gets your email address, and you use it as part of the login on most sites nowadays.
Drupal feels the same way: https://www.drupal.org/drupal-security-team/security-team-procedures/disclosure-of-usernames-and-user-ids-is-not-considered
Basically, your password is the security. Make it long and strong. Making a system require multiple secrets doesn’t increase security. Adding a second type of security, like two factor does, can increase security, and there are two factor plugins you can use if you need that. We’ve been trying to build two factor into WordPress for a long time, but it’s complicated, so it’s not on the roadmap right now.
I hope that helps you to understand. If you want to remove the users sitemap, it’s three lines of code I already gave you. But removing it is *not* a security improvement.
@carike I didn’t mean to be discourteous to anyone and I thank everyone who answered.
However, this forum is the only place where we can voice to WordPress our concerns and issues.Suggesting to use Yoast or any other sitemap plugin is ok, but suggesting to check the “do not index this site” option is not a viable solution for any site whatsoever except during it’s development phase. That cannot be a serious suggestion for a solution.
So let me be clear. I firmly believe this update, just like the completely premature Gutenberg implementation, has been done without thinking of the ordinary end-user (who I’m guessing would be about 85% of users?) who is using WP specifically BECAUSE you don’t have to code.
Implementing a sitemap that discloses User IDs and all posts/pages without ANY control whatsoever is a ridiculous move. One that makes me look for another solution that wordpress because with over 80 installs to supervise, it is a nightmare, whatever solution I try to implement.
I just can’t understand why this has been implemented without a UI and optional settings. And if no one complains, it will never be fixed. So I voice my complaint. And I know I’m not the only one. Hopefully someone will step in and include in the core a UI so we can choose sitemap settings instead of having to either code or add yet another plugin.
- This reply was modified 4 years, 3 months ago by MarieDi.
I just can’t understand why this has been implemented without a UI and optional settings.
The basic sitemaps feature has no UI or settings because it doesn’t need one. I’m sure plugins will exist soon enough to let people customize them and adjust them and so on, but by and large, most users should not care about sitemaps. It’s not relevant to them.
Like the built-in RSS feeds and so on is intended for feed readers, the functionality of a sitemap is intended for search engines. It’s not meant for users to see or care about. WordPress makes a lot of pages and URLs that lead to those pages. Giving search engines a sitemap lets them index those pages faster and better, eliminating excessive crawling. The sitemap itself doesn’t even need to look pretty in a browser, that’s generally done for aesthetics only. It doesn’t need any configuration because people who write posts and publish them to their website should want search engines to see them.
If you are the kind of person who needs control over every detail, then plugins will exist for just that purpose. You will be able to pick and choose what is displayed using them, and you’ll have your choice of interfaces to do so. I’m sure that is coming very soon.
But for the basic core functionality of sitemaps existing, no custom settings are required or necessary.
The basic sitemaps feature has no UI or settings because it doesn’t need one. I’m sure plugins will exist soon enough to let people customize them and adjust them and so on, but by and large, most users should not care about sitemaps. It’s not relevant to them.
That’s your opinion. I beg to differ. You talk like a true coder, not a user. Drupal never became very popular because it is for coders, not for users. Joomla was becoming popular until it veered towards coders. WordPress did become popular because it used to be for users, not for coders. Something that, sometimes, seems to be slowly slipping away.
On many of my sites, I create categories I DO NOT want the public to see because they are for internal management. I create articles and pages that are private/reserved for certain users.
The sitemap discloses everything.And if the User ID isn’t a [small] part of security, then explain to me why we instruct everyone to NEVER use “Admin” as a User ID.
But hey, I was only voicing a user’s point of view. So thank you, but I’m afraid we’re not seeing eye to eye here and I don’t see the point of continuing this discussion with you if you don’t want to hear my point (which, I guess, is your right).
Using “Admin” as a user ID leaves installations open to certain exploits (or makes the impact of exploits worse). That does not apply to other user IDs.
Unfortunately, I can’t give a specific example here, because we do not share exploits on the forums (an imperfect solution, but motivated by some really good reasons).That having been said, I take measures against username enumeration myself.
That having been said, Otto is right that various projects (for valid reasons) do not consider it a security risk.Otto is a true coder 😉 That is the amazing thing about WordPress (and probably some other Open Source projects too). You get to speak to third or fourth (maybe fifth?) line support that you would have NEVER gotten to with paid proprietary solutions.
The thing is that the forums aren’t really the right place to express your opinion on this. This is the place to get support for your WordPress site. All volunteers focus on solutions here.
If you would like to express your frustration, then places like WP Tavern are the best place for that.
If you would like change, then Core Trac is the best place for that – but the ticket needs to be actionable.
So, it needs to include details like where to place a User Interface and what that should look like.@carike
Thank you so much for this complete and explanatory answer.
Duly noted, on all counts.
I wasn’t aware of Core Trac or WP Tavern. All I knew about was github which is way beyond my tech comfort zone 🙂
Have a great day!
- The topic ‘New Core Sitemap DISCLOSES USER IDs’ is closed to new replies.