[wp-trac] [WordPress Trac] #23394: Remove version from readme.html / Upgrade core doesn't restore the file

[WordPress Trac]

#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:
---------------------------+----------------------

Comment (by RedSand):

 Replying to [comment:13 chriscct7]:

 Hey Chris,

 Good discussion. Thanks for sharing your thoughts. :)

 I'm glad that you all are open to discussion even if this is closed for
 now. Let's keep the discussion going.

 However, I do have to say that I am a bit disappointed by your response
 though, as it seems to immediately dismiss what I'm saying. It really
 seems that the WordPress core dev team is (and has been) resistant (in
 general) to user suggestions about certain security issues. '''I would
 understand this if people were making suggestions that are not good
 security practices, but this is an established security best-practice, and
 no security best-practice should be ignored, however seemingly small.'''

 I would think that with the discovery of security flaws in nearly every
 WordPress release for the past two years, the global rise in hacking,
 malware, etc, that you all would start to make hardening WordPress a
 bigger priority. I hope this becomes true. If you need recent examples in
 the news...just look at the Panama Papers scandal for example.
 Granted...they were using outdated plugins, so it is squarely on them, but
 please hear my overall point here. WordPress is becoming a bigger and
 bigger part of the whole global cybersecurity scene. Some of the security
 issues that arose in the last couple years with WordPress were predictable
 because WordPress did not follow good security practices 100%. Seemingly
 small things that seemed like an unlikely attack vector got ignored. And
 unless something was an immediate critical threat, users were often shut
 down, which discouraged them from reporting security issues altogether.

 Even if a user quotes a credible source to back up the point, it is
 ignored and shut down. However, when one of the WordPress core dev team
 members responds, instead of quoting a credible source to back up their
 point, it is with usually with one of these types of arguments:
 * "That's the way it's always been done..."
 * "That will break stuff..."
 * "That's not a real security issue..."
 * "Well, you can always find that info another way..."

 These are circular arguments, and end up sounding like "the company line"
 because almost everyone gets some version of the same few responses. I
 know for a fact that you all are good people, and do not intend things to
 come off this way.

 '''Don't get me wrong, I have a ''ton of respect and love for you all'',
 and the WordPress community in general. WordPress is by far the best CMS
 out there, and I am glad to see it's influence on the web increase as it
 has.''' (I hope that I can be a positive contributor in this community.)

 For years, users have been requesting that version numbers be removed from
 the front-facing side of WordPress, and the core team has shut down each
 of these requests...''for years''. There is definitely a disconnect
 between the core team and users in this area. Being a plugin developer I'm
 caught in between. I understand both points of view. I've been developing
 plugins for 10 years, but have not gotten into contributing to the core
 until now, but I'm definitely changing that moving forward.

 '''WordPress core definitely needs some hardening.''' I've spent years
 dealing with security issues in both the military (here in the US and
 deployed in combat zones) and civilian sectors, and not just web/IT, but
 physical security, and COMSEC (communications security) as well, which
 give you some interesting insight into security issues and hacking that
 you don't get if you only work with web/IT security.

 '''So, to continue the discussion, I'll respond to some points you
 made.'''

 If you would allow me to make an observation based on your responses:
 '''You're thinking like a ''developer'', not a ''hacker''.''' When dealing
 with security issues, you need to think like a hacker. (And it's not just
 you, so I'm not trying to make that any kind of insult.)

 > 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.

 Actually, I think you may have misread that...14.39 actually references
 the "Server" header which is still a standard header in use. The rest of
 what you mentioned wanders a bit off the topic as the full reference
 actually was: "Example: '''''Server:''' CERN/3.0 libwww/2.17''", which was
 merely an example of ''server header revealing version numbers''.

 Additionally, I was not specifically referencing section 14.39, as this
 quote is mentioned again in section 15.4:

   '''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.'''

 '''Substitute the word "server" for "software", "application", "web
 application", "web application framework", "Content Management System",
 etc, and the more generalized principle becomes clear.'''

 Take a step back for a second and look at the overall picture of what I'm
 saying here...I think you had focused a bit too much on one detail, and
 were missing my overall point. :)

 The point wasn't about the specifics or the RFC itself...'''it was about
 the general security principle'''. '''The Internet Engineering Task Force
 (IETF) are making a clear point that web server/software version numbers
 should not be revealed.''' This is a '''general security principle,''' and
 '''whether an RFC is updated or replaced, doesn't affect that.''' The IETF
 are merely one example, and I quoted them because of their role in the
 development of the web and standards. (ie... the man, Tim Berners-Lee...)

 '''Again, it's about a security principle, not the RFC.'''

 > > 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.

 '''Exactly what backward compatibility would be broken?'''

 * The only purpose for the query string is cache-busting.
 * The particular string that's used is not relevant. The way it is
 currently implemented, it just needs to be unique and stay the same until
 the site updates to the next WordPress version.
 * CSS (.css) files don't access the WordPress database, so they don't know
 what the string is that's attached to the URL. Nothing would break here
 unless it's poorly coded.
 * JS (.js) files don't directly access the WordPress database either, so
 even if they detect the query string on their URL, they have nothing to
 compare it against, meaning they don't care what the particular string is
 either.

 I'm intimately familiar with WordPress, have worked intensely with
 WordPress site development, security, speed optimization, theme
 development, and plugin development for 10 years (plus an additional 10
 years before that in web development as well), and have not seen where
 this would be true, and that it would break anything.

 WordPress is adding the query string to the .js and .css be a cache
 buster, so that when a site is updated to the next version of WordPress,
 it can update the CSS and JS scripts, and break any existing caches in a
 user's browser. It's not necessary for the query string to reference the
 WordPress version number in that query string: '''It could be any unique
 string that changes when the site is updated.''' Easy fix! There a million
 ways to create a unique random string that would stay the same until the
 site is updated.

 '''However, that's ignoring the website speed performance issues created
 by adding query strings to .css and .js URLs,''' because it specifcally
 '''makes the files uncacheable by browsers'''. I realize that's the
 intention, but these query strings are added to every script and style
 that is run through the enqueuing process.

 So, '''instead of using these cache busting query strings, use alternate
 methods, which are better practices anyhow.''' Caching can be completely
 managed by headers: Cache-Control, Surrogate-Control, Expires, Last-
 Modified, Vary, and Etag Headers, and should be done that way instead of
 adding query strings.

 A major principle in WordPress speed optimization is to concatenate and
 minify CSS and JS scripts, along with [https://gtmetrix.com/remove-query-
 strings-from-static-resources.html removing query strings from static
 resources], which renders that whole argument invalid. If you have a
 specific example of a plugin that it would break, please share it.

 '''Your argument:'''
 > This would break backwards compatibility that plugins can rely on...
 '''Argument busted.''' I've provided you with more than one alternative
 and shown that this is not a web development best practice, and not only
 that, it has a negative impact on website's performance by preventing CSS
 and JS files from being cached.

 > 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.

 The WordPress version info needs to be entirely scrubbed from the front
 facing side of WordPress. The areas I've mentioned include (but are not
 limited to):

 * The Meta Generator
 * Query Strings (or remove these altogether)
 * Readme/License File
 * Etag headers being added in v4.5 to the load-scripts.php and load-
 styles.php files:
 {{{
 header("Etag: $wp_version");
 }}}
 * Code comments in .js (I found 5 doing a quick grep of the .js files)
 * REST API
 * If there is anything I'm not aware of or have left out, then let's add
 it to the list, set up a project and get it done!

 '''Your argument:'''
 > 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...
 '''Argument busted.''' This is not a reason not to fix things. As I've
 shown, if my list isn't complete, then let's make a complete list of
 things and fix the entrie issue. It's not that huge a project. Sign me up.

 > However, if one really wants the version number you can simply run a
 string comparison on the outputted css or js files.

 * That's not how hacking with bots works. They don't want to hit a lot of
 files on your site when they are scanning. They don't want to use a lot of
 bandwidth or set off red flags. If there isn't a generator tag with a
 number, or something easy like .css/.js. URLs (or Etags) that they can
 glean, they move on to the next. If they are doing a deep scan of your
 site it can make it easy to get caught, even by newbs. (This is the same
 reason they don't scan for an entire library of exploits...there are far
 too many now, so it would take too much bandwith, and could trigger red
 flags.)
 * We're not talking about the combination of James Bond/NSA/Navy Seals
 trying to break into your site. If someone wants to compare files against
 a repository to see if the file signatures match, that's a whole different
 different ballgame and not what you're dealing in 99.9999% of cases.
 (Again, that would take a lot of bandwith, and be noticeable.)
 * '''That's an easy fix: Remove the version number from the comments in
 the .js files. Or better yet, remove the comments altogether. Good
 minification/concatenation plugins do this anyway.'''

 '''Your argument:'''
 > However, if one really wants the version number you can simply run a
 string comparison on the outputted css or js files...
 '''Argument busted.''' We're not talking about pro-level hackers trying to
 break into your site. I'm talking about the obvious stuff: Don't make it
 easy.

 > 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.

 * That's not really a valid argument. There is nothing about REST
 principles that requires the software version be exposed.
 * Even if it did, then why accept that flaw? Why not create an improved
 API and fix the issue?
 * REST principles are not set in stone yet, and there is room for change,
 modification, etc. WordPress should lead the way.
 * In web development, we don't just accept that a poor security practice
 is necessary because something uses it...that's faulty logic. We fix the
 system so it doesn't require poor security practices.

 '''Your argument:'''
 > 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....
 '''Argument busted.''' Simply not accurate.

 '''Most of the arguments you've used so far are circular arguments. You
 haven't quoted any security experts that promote revealing version numbers
 as a good idea, or any web development best practices as to why it should
 be done.''' If the WordPress core dev team is going to be so staunchly
 ''for'' revealing and using version numbers, then there should be some
 really solid reasons why. I'm happy to hear them.

 Again, I'm ''not'' attacking you guys...I truly do love you all, and think
 you all are incredibly talented, brilliant people who are making an
 incredible contribution to the world. I just am hoping that some of these
 points help spark a different way of looking at things.

 If you're worried about the amount of effort to fix it, I will be happy to
 help! I will be happy to contribute my time, and I'm sure many others
 would as well.

 > 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.

 Have you actually ever tracked how hacks happen? I have. Tracking bot
 activity and hacking patterns is something we do, and have been for a long
 time. We've studied hack attempts happening in real time. What you're
 saying is commonly repeated info, but not how it actually works.

 > 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.

 SMH. '''That's not what "Security by Obscurity" means.''' That phrase gets
 thrown around a lot in online forums, in the WordPress community, and by
 word of mouth, without people understanding the actual principle.

 The security principle you are incorrectly referencing is: "Avoid Security
 by Obscurity".
 * What it actually means: '''Do not make obscurity ''your only security
 method''.''' - I cannot say this enough: '''YOUR ONLY METHOD.''' Example:
 Using a unique file url ''instead of'' a login to protect something
 sensitive. That's overly basic but you get the idea.
 * What it ''does not'' mean:''' Don't bother ''using obscurity as part
 of'' your security strategy.'''

 The security principle: "Defense in Depth" supercedes this and means:
 * Use a robust layered security strategy.
 * By all means, use obscurity in your layers! Why make it easier for the
 hacker? Restrict info from those who do not need it.
 * Use redundant measures so that if one fails during an attack, another
 can backstop it.
 * And a lot more...

 You mention this:
 > ...[version hiding being an example], does not make the site any more or
 less secure (as pointed out in the OWASP).

 If using version hiding was your only "security" measure, then that would
 be ridiculous, and would fit the true definition of trying to use
 "security by obscurity". But, no one is suggesting that. I don't think
 anyone reading my comments who is being honest would interpret what I've
 written to say that that's what I'm suggesting.

 Again, you have to think like a hacker my friend, not like a developer.

 And where exactly is this quoted in OWASP? That's not what it says
 anywhere in OWASP.

 > > 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.

 That's assuming a lot. What defines soon? It's not going to obsolete for
 at least a few years, and there are plenty of hacks to be had in that
 time.

 > 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.

 That's fantastic...and very exciting. But, that's assuming that users
 don't disable the auto-updating. Not everyone wants to update right away.
 Should they? Yes, I think so. Will they? Not in my experience.

 >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.

 I hope you're right, but that would seem to be overly optimistic.

 > 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.

 Again, that's assuming that auto-update is not manually disabled.
 Unfortunately, we've run across many who don't want to update.

 In my experience, it's really only the users on the most recent branch
 that are even ''close'' to up-to-date on the minor versions. Stats back
 this up. We'll take a look at some stats in a minute.

 > Hiding versions does not in any way, shape or form help make any site
 newer than 3.7 more secure than they already were.

 '''I'm sorry, but you are flat out incorrect when you say this.'''
 Statements like that demonstrate a complete lack of understanding of
 security. When you hear me say that ''something is a security risk'', I
 think you think I'm saying that that revealing the version number is like
 giving someone a password to your site or key to your house. That's not
 what I mean at all. '''Revealing version number does not directly enable
 the act of penetrating a site.''' That's where you guys seem to be
 assuming that if something doesn't directly enable access to a site, that
 means everything is secure. Nothing could be farther from the truth.
 That's like saying, "Hey, if someone doesn't have the key to my house,
 then it's secure." Sure, '''if the only way in is a door, or they're
 polite enough to not kick your door in.''' But there are a million ways
 into a house (just like a website), thieves/hackers and the ilk are
 anything but polite. '''Security is complex scale of
 skill/motivation/resources vs difficulty.''' That's where you have to
 understand that some seemingly peripheral things like this are security
 risks. '''Security encompasses a lot more than just the single act of
 penetrating a site.'''

 '''Before a hacker breaks into a site, they gather data and pick their
 targets. Revealing site software versions makes it really easy for hackers
 to target sites with specific version/vulnerability combinations.'''

 Hacking doesn't start and end with someone breaking into your site. A
 direct quote from the One of OWASP's guides on fingerprinting during the
 information gathering process -
 [https://www.owasp.org/index.php/Fingerprint_Web_Application_(OTG-
 INFO-009) Fingerprint Web Application (OTG-INFO-009)]:

   '''Test Objectives:
   __Identify the web application and version__ to determine __known
 vulnerabilities__ and the __appropriate exploits__ to use during
 testing.'''

 I'll use key points from an OWASP guide to give you the basics, so you all
 can see why you need to stop saying, "That's not a real security issue
 when people point out why WordPress should not be revealing version
 numbers".

 The basic process:
 * It starts with research, aka
 [https://www.owasp.org/index.php/Testing_Information_Gathering Information
 Gathering]. I'm going just give a little info about each point. Read the
 guides for more info.
   * Use search engines to gather data -
 [https://www.owasp.org/index.php/Conduct_search_engine_discovery/reconnaissance_for_information_leakage_
 (OTG-INFO-001) 4.2.1 Conduct Search Engine Discovery and Reconnaissance
 for Information Leakage (OTG-INFO-001)] - I'll show you a quick trick in a
 second here.
   * Fingerprint (build a profile on) your target
      * [https://www.owasp.org/index.php/Fingerprint_Web_Server_(OTG-
 INFO-002) Fingerprint Web Server (OTG-INFO-002)] - Get the details of the
 server. Headers give out a wealth of info.
      *
 [https://www.owasp.org/index.php/Fingerprint_Web_Application_Framework_
 (OTG-INFO-008) Fingerprint Web Application Framework (OTG-INFO-008)] - In
 this case, Web Application Framework is synonymous with CMS. Basically,
 get the details of the CMS or framework. Specifically mentions mitigating
 some of this by removing install files like the WordPress readme and
 license, as well as removing code comments (ie the comments in WordPress'
 JS files that contain version number, and META generator tags.
      * [https://www.owasp.org/index.php/Fingerprint_Web_Application_(OTG-
 INFO-009) Fingerprint Web Application (OTG-INFO-009)] - This involves
 getting the application's details, including version number, and
 '''WordPress is specifically used as one of the examples''', and they
 specifically reference the META GENERATOR tag used in WordPress:
 {{{
 <meta name="generator" content="WordPress 3.9.2" />
 }}}
 *[https://www.owasp.org/index.php/Enumerate_Applications_on_Webserver_
 (OTG-INFO-004) Enumerate Applications on Webserver (OTG-INFO-004)] -
 Basically, figure out what apps are running, versions, and determine
 vulnerabilities. Regarding WordPress, this would relate specifically to
 plugins. "A paramount step in testing for web application vulnerabilities
 is to find out which particular applications are hosted on a web server.
 Many applications have known vulnerabilities and known attack strategies
 that can be exploited in order to gain remote control or to exploit data.
 In addition, many applications are often misconfigured or not updated..."
 * After the information gathering stage is finished, move on the
 hacking/penetration.

 Let me show you a brutally simple, and low-skill way to gather a list of
 sites that have vulnerable versions.

 * Use search engines to find targets.
 * Pick one of 63+ vulnerable versions to build a list for. I'll pick
 4.3.1.
 * Enter a query like this into Google:
 {{{
 inurl:.js?ver=4.3.1
 }}}
 * You'll get a quick list of sites that are using vulnerable version
 4.3.1.
 * From there, just import the data into your target list, and run your
 bot.
 * The better way is to employ a bot that will criuse through sites and
 build a list for you of sites with the specific version you're looking
 for, but like I said, using Google requires no skill, and anyone can do
 it.

 '''Now, each one of those sites is a potential target for hackers, even
 low-skill ones, ''so tell me again how that is not a security risk?'''''


 '''Ok, now let's take a look at some stats.''' The following are the
 percentage of WordPress users on each major branch (4.2, 4.3, 4.4, etc)
 that are using versions with security vulnerabilities:
 * WordPress 4.4 branch using vulnerable versions: Approx 3.1% | Approx
 1.5% of total WP user base
   * Reference: [http://w3techs.com/technologies/details/cm-
 wordpress/4.4/all]
   * Vulnerable versions: [https://wpvulndb.com/wordpresses/44 4.4 (3)] |
 [https://wpvulndb.com/wordpresses/441 4.4.1 (2)] <-- Version (# exploits)
 * WordPress 4.3 branch using vulnerable versions: Approx 26.6% | Approx
 4.2% of total WP user base
   * Reference: [http://w3techs.com/technologies/details/cm-
 wordpress/4.3/all]
   * Vulnerable versions: [https://wpvulndb.com/wordpresses/43 4.3 (6)] |
 [https://wpvulndb.com/wordpresses/431 4.3.1 (4)] |
 [https://wpvulndb.com/wordpresses/432 4.3.2 (2)]
 * WordPress 4.2 branch using vulnerable versions: Approx 30.9% | Approx
 3.3% of total WP user base
   * Reference: [http://w3techs.com/technologies/details/cm-
 wordpress/4.2/all]
   *  Vulnerable versions: [https://wpvulndb.com/wordpresses/42 4.2 (14)] |
 [https://wpvulndb.com/wordpresses/421 4.2.1 (13)] |
 [https://wpvulndb.com/wordpresses/422 4.2.2 (12)] |
 [https://wpvulndb.com/wordpresses/423 4.2.3 (11)] |
 [https://wpvulndb.com/wordpresses/424 4.2.4 (6)] |
 [https://wpvulndb.com/wordpresses/425 4.2.5 (4)] |
 [https://wpvulndb.com/wordpresses/426 4.2.6 (2)]
 * WordPress 4.1 branch using vulnerable versions: Approx 26% | Approx 1.6%
 of total WP user base
   * Reference: [http://w3techs.com/technologies/details/cm-
 wordpress/4.1/all]
   *  Vulnerable versions: [https://wpvulndb.com/wordpresses/41 4.1 (16)] |
 [https://wpvulndb.com/wordpresses/411 4.1.1 (17)] |
 [https://wpvulndb.com/wordpresses/412 4.1.2 (14)] |
 [https://wpvulndb.com/wordpresses/413 4.1.3 (13)] |
 [https://wpvulndb.com/wordpresses/414 4.1.4 (13)] |
 [https://wpvulndb.com/wordpresses/415 4.1.5 (12)] |
 [https://wpvulndb.com/wordpresses/416 4.1.6 (11)] |
 [https://wpvulndb.com/wordpresses/417 4.1.7 (6)] |
 [https://wpvulndb.com/wordpresses/418 4.1.8 (4)] |
 [https://wpvulndb.com/wordpresses/419 4.1.9 (2)]
 * WordPress 4.0 branch using vulnerable versions: Approx 23.6% | Approx
 0.9% of total WP user base
   * Reference: [http://w3techs.com/technologies/details/cm-
 wordpress/4.0/all]
   *  Vulnerable versions: [https://wpvulndb.com/wordpresses/40 4.0 (18)] |
 [https://wpvulndb.com/wordpresses/401 4.0.1 (14)] |
 [https://wpvulndb.com/wordpresses/402 4.0.2 (12)] |
 [https://wpvulndb.com/wordpresses/403 4.0.3 (12)] |
 [https://wpvulndb.com/wordpresses/404 4.0.4 (12)] |
 [https://wpvulndb.com/wordpresses/405 4.0.5 (12)] |
 [https://wpvulndb.com/wordpresses/406 4.0.6 (11)] |
 [https://wpvulndb.com/wordpresses/407 4.0.7 (6)] |
 [https://wpvulndb.com/wordpresses/408 4.0.8 (4)] |
 [https://wpvulndb.com/wordpresses/409 4.0.9 (2)]
 * WordPress 3.9 branch using vulnerable versions: Approx 35.1% | Approx
 1.3% of total WP user base
   * Reference: [http://w3techs.com/technologies/details/cm-
 wordpress/3.9/all]
   *  Vulnerable versions: [https://wpvulndb.com/wordpresses/39 3.9 (23)] |
 [https://wpvulndb.com/wordpresses/391 3.9.1 (22)] |
 [https://wpvulndb.com/wordpresses/392 3.9.2 (19)] |
 [https://wpvulndb.com/wordpresses/393 3.9.3 (13)] |
 [https://wpvulndb.com/wordpresses/394 3.9.4 (12)] |
 [https://wpvulndb.com/wordpresses/395 3.9.5 (12)] |
 [https://wpvulndb.com/wordpresses/396 3.9.6 (12)] |
 [https://wpvulndb.com/wordpresses/397 3.9.7 (11)] |
 [https://wpvulndb.com/wordpresses/398 3.9.8 (6)] |
 [https://wpvulndb.com/wordpresses/399 3.9.9 (4)] |
 [https://wpvulndb.com/wordpresses/3910 3.9.10 (2)]
 * WordPress 3.8 branch using vulnerable versions: Approx 35.6% | Approx
 0.8% of total WP user base
   * Reference: [http://w3techs.com/technologies/details/cm-
 wordpress/3.8/all]
   *  Vulnerable versions: [https://wpvulndb.com/wordpresses/38 3.8 (22)] |
 [https://wpvulndb.com/wordpresses/381 3.8.1 (25)] |
 [https://wpvulndb.com/wordpresses/382 3.8.2 (20)] |
 [https://wpvulndb.com/wordpresses/383 3.8.3 (20)] |
 [https://wpvulndb.com/wordpresses/384 3.8.4 (13)] |
 [https://wpvulndb.com/wordpresses/385 3.8.5 (12)] |
 [https://wpvulndb.com/wordpresses/386 3.8.6 (12)] |
 [https://wpvulndb.com/wordpresses/387 3.8.7 (12)] |
 [https://wpvulndb.com/wordpresses/388 3.8.8 (12)] |
 [https://wpvulndb.com/wordpresses/389 3.8.9 (11)] |
 [https://wpvulndb.com/wordpresses/3810 3.8.10 (6)] |
 [https://wpvulndb.com/wordpresses/3811 3.8.11 (4)] |
 [https://wpvulndb.com/wordpresses/3812 3.8.12 (2)]
 * WordPress 3.7 branch using vulnerable versions: Approx 40.3% | Approx
 0.3% of total WP user base
   * Reference: [http://w3techs.com/technologies/details/cm-
 wordpress/3.7/all]
   *  Vulnerable versions: [https://wpvulndb.com/wordpresses/37 3.7 (20)] |
 [https://wpvulndb.com/wordpresses/371 3.7.1 (25)] |
 [https://wpvulndb.com/wordpresses/372 3.7.2 (11)] |
 [https://wpvulndb.com/wordpresses/373 3.7.3 (11)] |
 [https://wpvulndb.com/wordpresses/374 3.7.4 (13)] |
 [https://wpvulndb.com/wordpresses/375 3.7.5 (12)] |
 [https://wpvulndb.com/wordpresses/376 3.7.6 (12)] |
 [https://wpvulndb.com/wordpresses/377 3.7.7 (12)] |
 [https://wpvulndb.com/wordpresses/378 3.7.8 (12)] |
 [https://wpvulndb.com/wordpresses/379 3.7.9 (11)] |
 [https://wpvulndb.com/wordpresses/3710 3.7.10 (8)] |
 [https://wpvulndb.com/wordpresses/3711 3.7.11 (3)] |
 [https://wpvulndb.com/wordpresses/3712 3.7.12 (2)]

 '''So based on this, if we're only counting users on branches 3.7-4.4+,
 approximately 14% of your total user base is using one of ''63 WordPress
 versions with known vulnerabilities''.''' But, we need to add in the
 rest...so adding in users on the branches below that as well, then'''
 approximately 20%+ of the WordPress' user base is using a version that has
 known vulnerabilities.''' That's 1 in 5. '''1 in 5.'''

 '''If WordPress powers 26% of the web, then that means that roughly 5% of
 the world's websites are a WordPress site using a version with a known
 vulnerability.''' (Well, from 1-25+ vulnerabilities to be specific.)
 That's of course, not counting potential plugin security issues, which
 would increase that percentage dramatically.

 At the time I wrote this, there are [http://www.internetlivestats.com
 /total-number-of-websites/ 1,013,194,710 websites and counting]. So, if
 that's true, then 26% of that is '''263,430,625 sites powered by
 WordPress.''' Yes, 263 million.

 20% of those: '''52,686,125 websites using versions of WordPress with a
 known vulnerability.''' (Again, not counting plugins.)
 '''50...million...websites. With major security flaws.'''

 '''No offense, but while ''you guys are excellent developers'', you are
 ''not security experts,'' and you need to be realistic about that.''' The
 WordPress core dev team should really not be shutting people down so
 quickly about these security issues that users are pointing out. '''The
 overall security of WordPress needs to be taken a bit more seriously.'''

 Let's look at things another way...real life examples.

 '''Real life Physical Security principles that apply to web security:'''
 * '''According to law enforcemenet and FBI statistics, what is the # 1 way
 to prevent auto break ins?'''
   * ''Don't put your valuables in plain sight.''
   * If you have a load of awesome, valuable stuff, like cameras, stereo,
 TV, high-end jewelry or anything else desirable, you can lock your doors
 all you want, but you are giving the thief huge motivation, and if they
 really want your stuff, they will go to almost any length to get it. Locks
 aren't going to stop them.
   * Notice, the # 1 way is NOT to simply lock your door, or get an alarm
 system. Should you lock your door? Of course! That's a no-brainer. Should
 you get an alarm? Probably a good idea. But if you create enough
 motivation in a potential thief, they will find a way...even a fairly
 unskilled thief. They'll get a backhoe and smash it up if they have to.
   * The same holds true of websites.
 * If you're securing a physical building containing a safe holding
 millions of dollars, would you lock the doors, and turn on the alarm
 system, but then post a notice on the front door with a map showing how to
 get to the safe, what model the safe was, and what the model of the
 security system was?
   * No, you would not, because that would be ridiculous.
     * With that info, an average skill-level thief could research how to
 disable that specific alarm system, crack that specific safe model, and
 they would have a map to the goods.
     * Without that info, a thief is not going to up to your building, and
 attempt to try hacks for every type of alarm system out there. That would
 take forever, and trigger alarms. They will move on to an easier target
 that they know more about.
   * That is essentially the exact same thing is being done by not hiding
 version numbers. It's essentially the WordPress model number.
     * What would make it seem that this is safe thing to do with WordPress
 websites?
 * When someone points out to you guys that the version numbers are
 revealed by readme files, or meta generator, or anything else you all keep
 saying saying, "Well, it's not like they couldn't get that info another
 way."
   * That's like saying, "Well, the other 2 doors to my house are unlocked,
 so why bother locking any of them." That's a ridiculous way of thinking.
 Just go lock all the doors.

 Obviously, these points are oversimplified...but they get the point
 across.

 '''Security is about reducing risk, and lowering the statistical
 probability of a successful attack.''' You can never eliminate risk fully,
 and there is no such thing as 100% impenetrable security, even with the
 best measures in place.

 By increasing the the level of security for your site or application, you
 are shrinking the pool of hackers that have the
 [skill|experience|time|resources|desire] to hack your site. In most
 criminal acts, it's about following the path of least resistance — if you
 increase the difficulty of success then often the hacker will go somewhere
 else. That's why every percentage of security improvement really does make
 a difference. (There still needs to be a robust layered security
 strategy...not saying to skip any of that.)

 You can often cut things off right at the beginning by removing any
 potential data leakage. '''That prevents a hacker from making your site a
 target during the initial information gathering stage.'''

 '''This is why version number leakage needs to be removed from
 WordPress.'''

 I really hope that no one takes any of what I've said as an insult or
 offense to the WordPress core dev team, because that is not my intent. My
 intent is to spark more of a wake-up call regarding WordPress security and
 hardening.

 You all are awesome, and I have much respect for your skills and
 contributions.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/23394#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform