Don't include generator tags by default

[scribu]

The <meta name="generator" content="WordPress 3.0-alpha" /> should be removed because:

• the information is already collected through the automatic upgrade feature, introduced in WP 2.7

• it gives out sensitive information that can be used for attacking the site

[scribu]

remove generator tags from default-filters.php

[scribu]

Not much to test here :)

[dd32]

• the information is already collected through the automatic upgrade feature, introduced in WP 2.7

Keeping it in there allows non-WordPress scans to detect what the publisher of the content is.

it gives out sensitive information that can be used for attacking the site

Whilst the information may seem sensitive, it really isnt all that revealing, or at least, not more than any other method

1. Anything automated will try every attack known to man
2. Anyone who wants to know the exact version, and/or revision of a WordPress install can do so by checking the filesize of any publically accessable css or js file.
3. Anyone who feels its sensitive information to them can install one of the many plugins to disable it. Moving it to hooks allowed for that (Instead of it being hard coded)

[markmcwilliams]

Well what about just having <meta name="generator" content="WordPress" /> as default then, without the version number, which will allow for what dd32 says?

[nacin]

Not convinced on this either.

[dd32]

Well what about just having <meta name="generator" content="WordPress" /> as default then, without the version number

Which removes useful data for random surveys, and doesnt fit with the normal Generator tags (being Application/Version). Removing it still serves no purpose given its easy to figure out.

[hakre]

Replying to dd32:

Removing it still serves no purpose given its easy to figure out.

Removing the whole string serves the purpose to not provide that information any longer (especially the version number has implications with security).

Is there some other area the version number is displayed publicly?

For standard setups I would not care, if you want to harden a setup, such information shoulde be removed or tainted, e.g. making it a 2.6.1 wanna-bee.

[dd32]

Is there some other area the version number is displayed publicly?

No, Just the generator tags.

That does not mean the exact revision cannot be infered, As i said, by the size of the various JS/CSS files, and the existance of certain files.

I have seen a few exploit scripts which checked for the existance of a file before attempting an attack, and modifying it slightly for an earlier version.

My point remains that to me, Removing it doesnt make sense, It only appears to make it more secure, it doesnt infact do that at all. If someone doesnt want that information publically available in the page source, they just need to remove the generator lines.

[filosofo]

Replying to dd32:

My point remains that to me, Removing it doesnt make sense, It only appears to make it more secure, it doesnt infact do that at all.

I agree. Removing the generator only hurts the good guys. Quite frequently I'll take a look at source to see the version of WP used by the blog I'm commenting on, and then I'll send a quick email to the site owner if it's really old.

Most of the time I wouldn't bother trying to deduce the version from features, but from server logs I've seen, going after features seems to be a continual attack vector: bots don't always bother figuring out the version, they just hit the site with all known attacks.

[jane]

Agree with dd32 and filosofo. I do the same thing, emailing if I see someone is running an old version to spur them to upgrade.

[nacin]

Other things not mentioned: the CSS version numbers on wp-login.php.

And, my favorite: Simply try to hit a wp-admin or wp-includes file that was introduced after a certain version, and check to see whether you get a 200 or 404.

Setting to worksforme, as a plugin can remove generator tags. Otherwise, wontfix.

[markjaquith]

I've seen a lot of WP exploit scripts over the years. Not a single one of them checked the version. They probed the vulnerability they were exploiting, using the success or failure of that to determine whether or not to proceed with the payload. Or they just try the payload blindly.