Security

With static code analysis tools like SonarPHP it's possible to automatically detect some security vulnerabilities.

Github also provides a tool (dependabot) to check for vulnerabilities in dependencies. Not sure if Gitlab has a similar solution?

This probably a question/task for the infrastructure team but before we start implementing solutions I'd like to discuss and document some best practices.

What type of tools are there (static code analysis for Php/javascript etc, dependency checks,...)
What tools are out there?
How well do they play with Drupal?

I have recently upgraded a site into Drupal 8 and choose the Nexus theme as my starting point. The security team recently released a security advisory on this theme (https://www.drupal.org/sa-contrib-2019-078) of critical and unsupported. It is recommended to uninstall. The theme does not offer an uninstall option. Is any Drupal 8 install (~13k) that used the Nexus theme now permanently insecure?

I am having a hard time figuring out what the unresolved security issue is with the Nexus theme. I have read through the issue queues, but assume it is not listed there to prevent exploits.

I would like to know if there are any pending XSS security fix releases. I don't need to know the specifics of core or modules.

I guessing the answer is "we can't say" but I'll give it a shot.

In Various 3rd Party Vulnerabilities - PSA-2019年09月04日 the Drupal Security Team has clarified that 3rd party vulnerabilities will generally not make announcements about vulnerabilities in 3rd party code that is depended on by modules or themes that are hosted on drupal.org.

How can it be checked?

How to check javascript libraries?

Currently, the message that you get when you to do https://www.drupal.org/project/{project}/report-security-issue
is this one:

This project is not covered by the Drupal Security Team’s advisory policy. Security issues do not need to be privately reported for the {PROJECT} project.

When a contributed project gets approved for security advisory coverage (background info: https://www.drupal.org/drupalorg/blog/goodbye-project-applications-hello... ) then we sometimes find security issues in existing stable releases that the module has already made. The current unofficial policy of the security team is to not release a security advisory for them if they contain a security issue. I would like to change that policy to always create security advisories for stable releases in projects with security advisory coverage.

Example:

Register Here

The Event

Join us for 3 days this summer in Ann Arbor, Michigan, for the 2019 Midwest Drupal Summit.

For this year’s Summit, we’ll gather on the beautiful University of Michigan campus for three days of code sprints, working on issues such as porting modules and writing, updating documentation and informal presentations. We will start around 10AM and finish around 5PM each day.

Food

Lunch, Coffee and Snacks will be provided each day.

What you can expect:

There's a regular discussion about how it is difficult for people in different parts of the world to know when Drupal's security releases will happen, e.g.:

https://twitter.com/xjmdrupal/status/1092537927341670401

How about we set up a public calendar that shows the security windows, they could subscribe to it and let their respective calendar programs adjust the timezone. We would then publicize this calendar on d.o/security and other locations, and keep it current for when release windows are changed.

Hi all. I have a quick question about the official Drupal Docker images on Docker Hub.

We’re currently upgrading from D7 to D8, and are using Docker and Kubernetes to build our new system. Are the official Drupal images on Docker Hub updated as soon as security releases are made available for Drupal core?

Various media outlets are reporting that a large number of Drupal sites are still vulnerable to the recent highly critical core vulnerabilities SA-CORE-2018-002 and SA-CORE-2018-004.

Those reports are all based on the same source. The source investigated the contents of CHANGELOG.txt of a large number of sites and assumed all sites reporting a version lower than 7.58 to be vulnerable.

Security releases are a tricky problem, for basically all organizations. They present extra challenges in internet-facing software, used around the globe, and supported by an open source community that's a mix of volunteers and paid or partially funded people. Feedback in Drupal is basically always welcome, whether as an issue in a queue, a comment on social media, a presentation at a meetup/camp/conference, or some other channel. In the spirit of constant improvement, I'm posting here to explicitly solicit feedback about what elements of the Drupal Security process could be improved.

How many sites are likely affected?

Drupal 8, 7, and 6 sites are affected. According to the Drupal project usage information this represents over one million sites or about 9% of sites that are running a known CMS according to Builtwith.

How dangerous is this issue?

There appears to be an increase in malicious requests performing automated password reset on accounts. These automated requests seem to be requesting password reset for commonly used usernames like admin, moderator, etc.

Triggering a password reset email is not a security risk, directly. Site owners should check all accounts with elevated rights and confirm that the associated email address are correct. This automated attack maybe trying to take advantage of a previously compromised account having its email changed.

Hi all,

Summary: Additional links about security review process and severity determination would be beneficial to the average subscriber of security alerts.

Long story:
Yesterday there was a security notice around updating the backup & migrate module that sparked some needed conversations. This link is essentially the email that was sent out https://www.drupal.org/sa-contrib-2018-004

The chromium project blog post about meltdown/spectre has some advice for web applications to increase their security in case a client has not upgraded.

Quoting the 3 main bullet points:

1. Where possible, prevent cookies from entering the renderer process' memory by using the SameSite and HTTPOnly cookie attributes, and by avoiding reading from document.cookie.

I have questions about Drupal distributions and their security coverage. If a Drupal distribution has security coverage and modules contained in the distribution do not:

1. Do the distribution's maintainers accept security coverage responsibility for the non-covered module?
2. What are the other implications and gotchas in this scenario?

Thanks!
shrop

Hi Team,

Our security team used Fortify tool to do a static code of Drupal 8.3.7 code base and found some issues. Mostly json injection, XSS etc

How are these threats perceived by the community? Are there any security drupal patches available which fixes these issues?

Cross-Site Scripting: DOM
1. backbone.js, line 1678 (Cross-Site Scripting: DOM)
The method start() in backbone.js sends unvalidated data to a web browser on line
1678, which can result in the browser executing malicious code.

1. backbone-min.js, line 1 (Cross-Site Scripting: DOM)

Hi all

I'm running more and more sites on D7 and D8 and nedd a way to automatically check if all the hundreds modules these sites are running are safe (to me it means stable version, enough installs, actively maintained, no known vulnerabilities).
By now I haven't found a way to do so other tha uglyly parsing html found on https://www.drupal.org/security and https://www.drupal.org/project/project_module

Has anyone tried before?

Maybe the Drupal security team (as they have it all in their DB) could provide these data through a Rest API or at leas a csv file.

Symfony contacted the Drupal Security team about today's Symfony security release addressing an issue in UserPasswordValidator. This announcement is to reassure the Drupal community that Drupal 8 is not affected by this fix, as it does not make use of this security component. There is no Drupal 8 release scheduled for this, and there is no action you need to take on your Drupal site(s).

I could not find an official policy over whether PSAs are to be made regarding security notices for vendor code that doesn't directly affect Drupal, though I'm sure this has happened lots of times over the years and will continue to happen in the future.

I suggest we over-communicate to the community and take the effort to release a PSA that states Drupal core is not affected on situations where vendor security updates do not affect Drupal. We could even have a template message to publish for these scenarios, then just update the specifics and it's done.

Rationale

<

ol>