[wp-meta] [Making WordPress.org] #6939: Reporting Security vulnerabilities in plugins

Making WordPress.org noreply at wordpress.org
Thu Apr 20 04:45:09 UTC 2023


#6939: Reporting Security vulnerabilities in plugins
------------------------------+--------------------
 Reporter:  dd32              |      Owner:  (none)
     Type:  enhancement       |     Status:  new
 Priority:  normal            |  Milestone:
Component:  Plugin Directory  |   Keywords:
------------------------------+--------------------
 Currently there are two main ways to report security issues to plugin
 authors:
 1. Scour the plugin page for a Security reporting link and failing that,
 look for a company/personal contact, reach out via their contact form or
 email address, convince them to resolve the issue.
 2. Email the plugins team with a report, have them forward the report on
 to the author(s) of the plugin, and let the plugins team choose to
 withdraw the plugin from the repository or not (Note: Most plugins are
 withdrawn upon a security notice, as currently there isn't a better way to
 manage whether things get fixed or not).

 Neither of these are ideal solutions, In the first, security vendors often
 find that their reports are missed, ignored, or simply not able to find a
 contact method for the author. That then causes them to use the second
 option.
 In the second, it requires time from a human reviewer to review the
 security report, determine if it appears legitimate, determine the plugin
 it relates to, check to see if the plugin has released a newer version,
 copy-paste the report to the plugin author, manage the communication with
 the author + explain the issue, likely close the plugin to keep track of
 the security issue, etc.

 Quite simply, neither is an optimal scenario, and with the number of
 plugins on the directory growing, and the number of security researchers
 who are invested in responsible disclosure growing, the human time
 required to manage this simply increases.

 There are likely a few ways we can resolve this, but, after discussing
 this with a few community members, plugins reviewers, and a few select
 security vendors, I'd like to propose one solution.

 **The proposal**
  - Each plugin gets a `Report Security Issue` button, that links to..
  - A form on WordPress.org, likely at a location such as `/plugins/report-
 security-issue/?plugin=example-plugin-slug-here`
  - That form requests all the pertinent details, Plugin Version, Type of
 issue, Severity, Description, POC, Possible patch(es), Security Vendor
 details.
  - That form creates an 'security incident' CPT entry, The details are
 emailed to the plugin author for action.

 From there, there are a few options, but I believe the above would suffice
 as an MVP, to streamline the process of getting security reports to the
 authors.
 Ideally however, We'd then...
  - A security incident is created, and accessible via a private URL to the
 plugin committers, security vendor, and plugins team, at a url such as
 `/plugins/security-report/{UUID}/`
  - Communication between the Security Vendor and Plugin Author can take
 place via comments on that page, instead of ad-hoc email. (Notifications
 of comments would still trigger an email)
  - The Plugin authors details (email, etc) can remain private, likewise
 the security vendor could remain private. Perhaps it links with their 5ftf
 pledge and it's "This is a report from <username> from <Security Vendor>".
  - Plugin Reviewers can see and comment if required.
  - The incident can be marked as resolved in a given version (by any
 involved)

 Of course, as noted above, there are some issues around how to ensure
 things get fixed appropriately, but also that false reports or by-design
 doesn't impact the plugin.
  - If the plugin author doesn't ACK the issue, the plugin is closed within
 a certain timeframe, this encourages authors to resolve the issue.
  - If the plugin author does resolve the issue within a time limit, and
 the security vendor is satisfied, the plugin is never closed. This
 benefits the Plugin author and end-users.
  - If the plugin author believes the reported issue is not valid, or the
 Security vendor believes the author is not making a reasonable attempt at
 resolving the issue, it can be escalated to the plugins team to make a
 decision.

 **Potential Issues / Caveats**
 1. Not everyone understands what a Security vulnerability is.
   - Requesting specific fields may increase the barrier to reporting,
 making it less likely to be problematic.
   - Reports could still go via the plugins team for the initial report,
 only once a reviewer confirms it, would it (And future reports from the
 author?) then be forwarded on to the author. In other words; trusted
 reporters go straight through, not-yet-trusted gets moderated.
 2. Security vendors have their own tools they may wish to use, asking them
 to use our system might be a challenge. Most should be at willing to use
 ours for submitting it though.
 3. Plugin authors may already have a system in place, such as HackerOne or
 BugCrowd. Ideally we'd somehow integrate with those, but initially we
 could just disable ours if a security-reporting url is provided by the
 author.
 4. Disclosure, Ideally issues would get disclosed at some point, for now
 this would be better left to the existing indexes of plugin
 vulnerabilities and we wouldn't be creating a disclosure index for now. At
 a later date it might be good to then use this data to say "Versions less
 than 1.2.3 are known insecure" and integrate that into core somehow.

 **Outcomes**

  - This would also provide the plugins team a greater view into the
 security issues affecting plugins, trends of what they need to keep an eye
 out on in plugin reviews, what needs better documentation, etc.
  - Would also allow the plugins security team to be aware "sooner" of
 high-severity issues that may warrant a security auto-update, or to be
 escalated to the team when that's going to be needed.
  - Plugin authors can be assured that they'll get notified about security
 issues, no longer have their plugin closed for re-review unless no effort
 is made
  - Security vendors no longer need to hunt around for a contact email
 address or contact form, unsure if the issue will get to the correct
 person.
  - Security reporters would be able to get a trackable event on their
 profile, "Reported a security issue on a plugin."
  - Plugin reviewers would no longer need to manually process every
 security report email
  - Plugin reviewers might be able to offload some of the re-
 review/verification of the security fix onto the security reporter, as
 currently it's 'easier' for the reviewers to review it than go back to the
 initial reporter to get it checked
  - Plugin Security Team time could be more targeted to supporting and
 reviewing issues as needed, and working on supporting plugin authors and
 security items rather than emails.

-- 
Ticket URL: <https://meta.trac.wordpress.org/ticket/6939>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org


More information about the wp-meta mailing list