[wp-trac] [WordPress Trac] #23394: Remove version from readme.html / Upgrade core doesn't restore the file
WordPress Trac
noreply at wordpress.org
Sun Apr 10 15:38:00 UTC 2016
#23394: Remove version from readme.html / Upgrade core doesn't restore the file
---------------------------+-----------------------
Reporter: momo360modena | Owner:
Type: enhancement | Status: reopened
Priority: normal | Milestone:
Component: General | Version:
Severity: normal | Resolution:
Keywords: | Focuses:
---------------------------+-----------------------
Changes (by RedSand):
* status: closed => reopened
* resolution: invalid =>
Comment:
Replying to [comment:9 nacin]:
Give the [https://wpvulndb.com/wordpresses sheer number of security
vulnerabilities] that WordPress has had in the last two years, and changes
in cybersecurity and increasing occurrences of hacking that have happened
in the last 3 years, I think ''it's definitely time to reopen this
topic'', and to start taking a more aggressive approach to WordPress
security.
While not the most important security flaw, it is still a poor security
practice to reveal software version numbers in web software. If you want
to hack a site, the first thing you want is to get the type of software
and version number. This is known as fingerprinting.
The IETF (Internet Engineering Task Force) has this to say in
[http://www.ietf.org/rfc/rfc2068.txt RFC 2068]:
"Revealing the specific software version of the server may allow the
server machine to become more vulnerable to attacks against software that
is known to contain security holes."
Additionally, from
[https://www.owasp.org/index.php/Fingerprint_Web_Application_Framework_
(OTG-INFO-008) Fingerprint Web Application Framework (OTG-INFO-008)]:
> '''Web framework[*] fingerprinting is an important subtask of the''
information gathering process''. ''Knowing the type of framework can
automatically give a great advantage if such a framework has already been
tested by the penetration tester.'' It is not only the ''known
vulnerabilities in unpatched versions but specific misconfigurations'' in
the framework and known file structure that makes the fingerprinting
process so important....'''
> [*] Please note that this article makes no differentiation between Web
Application Frameworks (WAF) and Content Management Systems (CMS). This
has been done to make it convenient to fingerprint both of them in one
chapter. Furthermore, both categories are referenced as web frameworks.
And...
> '''Remove any unnecessary or unused files on the server. This implies
text files disclosing information about versions and installation too.'''
Which is exactly what we're asking for here...to remove the readme and
license files.
Rsponding to a couple of @nacin 's previous comments (granted, I realize
they are 3 years old, but this for others considering this issue now):
> With publicly accessible web application software, there is no way to
prevent version detection. The readme and generator versions are just the
fairly cheap ways to do it. My favorite is looking at publicly accessible
CSS and JS files, but there are many others.
Right...so let's fix that. If these are areas that can be used to find out
the software version, then why not remove it from them? In CSS and JS
files, the version numbers have no advantage over some type of hashed key.
> Script kiddies blindly attack sites. They don't sniff version numbers
first.
While that used to be true (in 2013 when your response was posted), that's
simply not the case anymore. In 2016, they absolutely do sniff version
numbers. With the sheer number of exploits out in the wild now, it's not
really practical to just attack blindly. That would be an easy way to be
detected, and not to mention it takes a lot of bandwidth for the hacker.
Sure, there are still bots employed by script kiddies that just try to hit
a site with a variety of common exploits. More often though, hackers set
bots to not try any attacks on their first pass...they are merely scanning
sites collecting data for a targeted attack in the next step. They are
building a list of sites that have specific vulnerable software versions.
They can either be hit again automatically right after the data is
collected. Or, the hacker employing the bot, can review the list manually
and single out interesting targets. Either way, the bots are sent again,
this time going for specific vulnerabilities and that's when they attack.
This has a much higher success rate, and is harder to catch.
> Even if they did, this means they're looking for core vulnerabilities.
(Of which there are few, and anything of note requires a user account
these days, at a minimum.)
That's absolutely not true anymore either...There have been exploits in
every version of WordPress released, as revealed over the last two years.
There is no such thing as 100% secure software. We have to assume that
sooner or later, a vulnerability will be found in every single version of
WordPress.
> So, you're either running an out of date version — don't hide the
version number, *update* — or you're running the latest (at which point,
that's on us, and no suppressing that version is going to help you).
Very true...but [https://wordpress.org/about/stats/ WordPress.org's own
usage stats] show that '''approximately 48% of WordPress users aren't even
updated to the 4.4 (current) branch''' so that leaves about half of
WordPress' users out of luck if a more proactive approach to security
isn't taken. 31% are still using PHP 5.2 and 5.3, so this shows pretty
clearly that a high percentage of users are not practicing good security.
So, we as developers need to help them out and make it as secure as
possible. Not everyone has expert security consultants helping them, or a
good working knowledge of security. (This can change if we educate users
but it will likely take years.) While I'm with you that people need to
upgrade (and believe me, I preach it), we can't lay all the responsibility
on users.
One idea for securing the readme and license files is to have it secured
somewhere in the admin with the relevant info. It could even be a link to
readme and license files hosted on WordPress.org for that particular
version. Or, if they were available on a page of the admin, the files/data
should only be accessible by .php, not .txt or .html, so no version
numbers would be revealed externally.
Regarding removing version numbers from CSS and JS files: As I mentioned
above, replace the version number with a salted hash (or other unique
random key) that changes each time the version is updated.
Regarding the version numbers in the page head...Code located in general-
template.php on line 3451 (v4.5-RC2) for example:
{{{
$gen = '<meta name="generator" content="WordPress ' . get_bloginfo(
'version' ) . '">';
}}}
One option would be to have WordPress but leave out the version
number....just cut
{{{
get_bloginfo( 'version' )
}}}
It really isn't necessary. Almost every security plugin removes this
generator code completely. (And that is not being over-aggressive.)
It's also being proposed to add the WP version number in Etags, and this
is already implemented in v4.5-RC2, which is also not a great idea. Please
see [https://core.trac.wordpress.org/ticket/28722#comment:25 my comments]
on the [https://core.trac.wordpress.org/ticket/28722#comment:27 ticket
here].
Not revealing version numbers is merely one aspect of following establshed
good security principles, so this shouldn't be seen as an odd request.
I've seen requests similar to this keep getting shut down over the years
and it makes me scratch my head.
'''If we can make some relatively easy changes to remove all the version
number leakage throughout WordPress, and reduce the number of successful
hacks (even if only by a small percent), for ''nearly half of WordPress
users'' that don't upgrade as quickly, doesn't it seem like that's
something we should do?'''
--
Ticket URL: <https://core.trac.wordpress.org/ticket/23394#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list