Make sure Console files are not vulnerable when loading through web.

hechoendrupal / drupal-console

The Drupal CLI. A tool to generate boilerplate code, interact with and debug Drupal.

http://drupalconsole.com

GNU General Public License v2.0

940 stars 559 forks source link

Make sure Console files are not vulnerable when loading through web. #3238

Open Chi-teck opened 7 years ago

Chi-teck commented 7 years ago

Drupal Console recently has changed the way of installation. Rather than installing as a global CLI executable it turned to a local composer package. Unfortunately Drupal vendor directory is situated inside document root which makes it public accessible through the web. Since those files was never meant to be started by web server I propose we inspect all of them to prevent possible security issues.

Drupal forbids execution of PHP files in sub directories by means of .htaccess file however this does not work when a site is running by Nginx web server.

I suppose Drupal console is also responsible for all dependencies it brings to Drupal vendor directory.

For instance gabordemooij/redbean project exposes a few not protected PHP files with some potentially danger code (file_put_contents, database functions, etc).

jmolivas commented 7 years ago

@Chi-teck we should definitely pay attention to this. Having the vendor directory on the public web directory should be avoided by the project itself I mean for Drupal composer template.

This issue could be addressed by using a project template like drupal-composer/drupal-project but a practice like this will take time to be adopted, but for sure we need to check the project dependencies DrupalConsole provide.

What we can do to have this fixed.

Replace gabordemooij/redbead for another PHP library to interact with different DBs.
Remove library and implement Drupal functionality.
Review and define which dependencies like gabordemooij/redbead should not be deployed to production and have the on the require-dev section of the project and document how to use composer require --no-dev option.

pfrenssen commented 7 years ago

Why would you install Drupal console on a production server? It is a development tool.

Chi-teck commented 7 years ago

@pfrenssen Some commands like cache:rebuild, cron:execute or site:status make sense on production environment as well. The same is true for custom commands built on top of Drupal console API.

jmolivas commented 7 years ago

@pfrenssen totally agree with @Chi-teck most of the debug commands router:debug container:debug config:debug are useful on production.

My short term goal is to extract generate:* commands as an external project and define at the require-dev since those commands should not be deployed to production.

pfrenssen commented 7 years ago

That sounds like a really good idea!