[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