[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 23:25:11 UTC 2016
#23394: Remove version from readme.html / Upgrade core doesn't restore the file
---------------------------+----------------------
Reporter: momo360modena | Owner:
Type: enhancement | Status: closed
Priority: normal | Milestone:
Component: General | Version:
Severity: normal | Resolution: wontfix
Keywords: | Focuses:
---------------------------+----------------------
Changes (by chriscct7):
* status: reopened => closed
* resolution: => wontfix
Comment:
IETF's recommendation 14.39 in RFC 2038 refers to a header that was
previously used for intra-network communication for use in identifying the
processing software or for general use server surveys. This specific
header would contain information about a level that is higher than the
application layer of WordPress, and thus should not be construed as
guidance to projects like WordPress or other software that runs at the
same layer as WordPress. An example of data previously contained in this
header was:
> CERN/3.0 libwww/2.17
This header no longer exists. In fact the RFC you referenced was written
in 1997, and was itself invalidated and supersceded by RFC 2616 in 1999.
As of the 1999 RFC, no RFCs since, about the HTTP protocol have contained
similar guidance, partially because the header in question doesn't exist
beginning in RFC 2616.
The license.txt file contains the GPL license text which is a component of
the GPL license which WordPress uses.
> 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.
This would break backwards compatibility that plugins can rely on, and it
doesn't solve the problem that it's just as easy to compare the contents
of the file as it is to parse the version out of the url.
Moreover, there appears to be a suggestion that even if you remove these
files, hide the meta generator tag, and randomize the version appended to
strings, somehow that will plug all of your version concerns. However, if
one really wants the version number you can simply run a string comparison
on the outputted css or js files. Moreover, the WordPress REST API
framework requires versioning, which inherently must be public in order
for the feature to use, and that versioning can be directly mapped to
versions of WordPress. That itself cannot be prevented.
> We have to assume that sooner or later, a vulnerability will be found in
every single version of WordPress.
Using a version detection library attached to a standard exploit library
set such as metasploit, one can simply just run through all
vulnerabilities ever found for WordPress just as quickly as detecting the
version on a site that's done what you've prescribed. The fact of the
matter is that security by obscurity (version hiding being an example),
does not make the site any more or less secure (as pointed out in the
OWASP). In actuality in certain penetration software it makes it faster.
Many frameworks, upon being unable to deduce a version number of an
application, simply iterate over all vulnerabilities anyways.
> Very true...but 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.
This is a soon to be obsolete argument. WordPress is moving towards
Chromium style updates, where major versions are done automatically.
Existing tail end WordPress installs are automatically being updated major
versions now, even if they were not previously by a combination of
WordPress outreach to major web hosting companies and other relevant
parties. As this continues to occur, the number of sites on the current
major version in perpetuity will continue to grow. It wouldn't surprise me
if after 2 years, that's up to 85-90% of all installs always on the
current major version.
Furthermore, on sites where WordPress has autoupdate minor releases (all
sites since 3.7, so about 80%+ of all WP installs), any newly discovered
vulnerabilities can be pushed and patched in real time. Hiding versions
does not in any way, shape or form help make any site newer than 3.7 more
secure than they already were.
> 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].
That's not a proposal, it's a merged feature that will ship with WordPress
4.5 in 2 days.
> 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?'''
These are only successful because either users fail to upgrade major
versions (something that again will not be as significant if at all an
issue in the future) or have something else that's vulnerable, generally a
plugin, which does not in any way have anything to do with WordPress
version number "leakage". In the meantime, the users who don't upgrade
will never see this update to remove the version numbers, so in the end,
this type of thing provides a net benefit of helping no one. A site is
either up to date and thus secure via security releases, or doesn't update
and will never see this update anyway.
Note, I'm going to reclose this ticket, however, a closed ticket does not
mean discussion has to stop. You (and others) can continue commenting on
the ticket while it is closed.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/23394#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list