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

[Chi-teck]

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]

@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]

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

[Chi-teck]

@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]

@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]

That sounds like a really good idea!