Home News Drupal 8 e le novità sulla sicurezza
Drupal 8 e le novità sulla sicurezza PDF Stampa E-mail
Martedì 05 Maggio 2015 11:27

Drupal 8 e le novità sulla sicurezza

Sta per uscire la nuova release del CMS Drupal, la versione 8, che introdurrà più di 200 aggiornamenti tra novità e migliorie. Le innovazioni hanno interessato tanti fronti, tra i quali proprio quello della sicurezza. Si tratta di un aspetto particolarmente curato in questa nuova release, che ha avuto come obiettivo non soltanto quello di colmare le lacune delle versioni precedenti, ma anche quello di migliorare e perfezionare la sicurezza dei siti basati su questo CMS.

Qualche giorno fa Opensourse.com ha intervistato due personaggi che hanno lavorato alla sicurezza di Drupal 8. Si tratta di Greg Knaddison, direttore della divisione Engineering di CARD.com e membro del consiglio consultivo di Drupal Assosiation (ex leader di Drupal Secutity team), e Michael Hess attuale leader del Drupal Security Team. I due hanno affrontato durante l’intervista il tema sicurezza di Drupal, soffermandosi in particolare sulla gestione degli avvisi di sicurezza da parte di librerie esterne, sugli aggiornamenti automatizzati e sulla revisione del codice, anticipando quali sono le novità a riguardo in Drupal 8.

Per quanto concerne gli avvisi di sicurezza delle librerie esterne incorporate in Drupal, i due hanno affermato che ci sono due differenti strategie. La politica generale di Drupal vuole che il codice di terze parti non debba essere incluso direttamente nei repository Drupal.org, pertanto la prima strategia è quella di consigliare ai proprietari dei siti internet di verificare personalmente eventuali aggiornamenti di codici di terze parti. D’altro canto, gli sviluppatori potranno inserire un hook_requiriments per verificare se la versione della libreria installata dall’utente è aggiornata e in caso contrario inviare un avviso.

La seconda strategia riguarda le eccezioni, ad esempio i casi in cui le librerie sono integrate nel core Drupal. In tal caso il team di sicurezza ha scelto di lavorare a stretto contatto con gli autori delle librerie per risolvere i problemi e dettare delle linee guida. È questo il caso ad esempio di Symfony, i cui avvisi di sicurezza saranno attivati a partire dalla versione di Drupal 8.

Drupal e gli aggiornamenti di sicurezza automatici

Come confermato dai due team leader della sicurezza di Drupal, spesso gli aggiornamenti al codice richiedono delle modifiche manuali che non possono essere eseguite tramite automazione. In ogni caso esistono delle soluzioni alternative che sollevano i proprietari dei siti Internet dal dover apportare delle modifiche al codice. Una tra tutte è quella di affidarsi a provider che forniscono hosting Drupal, i quali incorporano nei loro piani delle funzionalità che consentono di testare e aggiornare con facilità gli aggiornamenti per la sicurezza.

Altra soluzione è quella di affidarsi ad aziende di consulenza, che possono occuparsi di monitorare gli aggiornamenti e apportare modifiche al codice se necessario. Esiste anche un servizio di terze parti, Drop Guard, che si integra con gli hosting e si occupa di fornire una sorta di aggiornamenti automatizzati.

A partire dalla versione Drupal 8 saranno abilitate le revisioni automatizzate del codice in base al modulo Coder. Tuttavia sarà possibile gestire solo alcuni dei più comuni problemi che si riscontrano facilmente con il pattern matching, mentre mancheranno questioni più complesse e potenzialmente dannose. In ogni caso i team leader della sicurezza si augurano che questo controllo integrato sulla qualità del codice possa comunque ridurre il numero di problemi legati sicurezza.

I risultati dei test di automazione al momento introducono tanti falsi positivi, facendo perdere di vista delle problematiche reali. In ogni caso questo strumento può essere utile agli esperti di codice per avere una base di revisione da cui partire.

Le funzionalità sulla sicurezza di Drupal 8

Drupal 8 userà un nuovo linguaggio di template chiamato Twig che sostituisce il precedente Drupal-specific PHP template system. Ciò significa che non si avrà più linguaggio PHP nei template. Twig introduce anche la funzione di auto-escaping per evitare vulnerabilità XSS nei temi.

In Drupal 8, l’editor WYSIWYG è stato costruito in modo tale da diminuire la probabilità che uno sviluppatore di siti web possa utilizzare accidentalmente il formato di testo Full HTML e introdurre un vettore per XSS.

Il modulo PHP è stato rimosso dal core di Drupal. Le motivazioni che hanno portato a questo cambiamento sono due. La prima è stata quella di evitare che l’amministratore del sistema consenta erroneamente l’esecuzione del PHP a utenti non attendibili. La seconda è quella di evitare che un utente malintenzionato, che ha ottenuto l’accesso come account amministrativo, possa utilizzare il modulo PHP per eseguire codice arbitrario.

Chiunque volesse approfondire l’argomento, potrà leggere l’intervista per Opensource.com in lingua originale che vi riproponiamo di seguito.

How do you manage security advisories from external libraries incorporated into Drupal?

We have two strategies. First, our general policy is that third-party code should not be included directly into the Drupal.org repositories, so our advice since 2011is that individual site owners should be aware of their own updates to third-party code. One thing that Drupal module maintainers can do is add ahook_requirements to check if the installed version of the external library is insecure and then show a message to the site admin letting them know to upgrade.

Second, when exceptions are made (e.g. Drupal core), we work with the authors of the libraries to fix issues and coordinate releases. For example, we have a working relationship with the Symfony project’s security team to fix issues in a coordinated manner. Since Drupal 8 is not yet generally available, we don’t include any security advisories for issues in Symfony just yet, but we will as soon as Drupal 8.0.0 is released.

Are there any plans for automated security updates in Drupal?

It is something the community is talking about. Of course, by automating security updates you add a different set of risks. Updating Drupal code sometimes requires manual changes and that can not be done via automation. We as a community continue to explore this.

Some alternative solutions exist to achieve that goal in ways that might be more secure and reliable. For example, some of the Drupal-focused hosting companies incorporate features into their hosting plans that make it very easy to test and deploy security releases. There are also consulting companies who can be hired to monitor the security releases for you and update your site. And a relatively novel solution is Drop Guard, a rules-based third-party service that integrates with existing hosting and deployment tools to automated security updates. For more details comparing these hosting companies and service providers, see this Wiki page list of service providers who keep Drupal sites up to date.

For those interested in building something similar for themselves who are running an unmodified version of core/contrib; and who are comfortable with a little shell scripting, just do drush up -y inside of a cronjob. An obvious improvement would be to do that same drush up -y inside of a test environment, run automated tests, and only deploy if the tests pass.

What are your thoughts on automated code reviews and penetration testing?

Automated code reviews based on the Coder module will be enabled for all projects some time this year. However, it will only catch some of the most common issues that are easily found with pattern matching. It will miss more complex and potentially more damaging issues. Broadly, we hope this integrated code quality check will reduce the number of security issues in modules hosted on drupal.org (making the project safer and reducing work for the security team). We’re excited to see what improvements will be made to Coder once it’s more tightly integrated to drupal.org.

Automated penetration testing results tend to include a lot of false positives and miss real issues. The Drupal Security Team gets PDFs emailed on a regular basis showing the results of popular tools and, so far, I haven’t seen one that I really loved. That said, they are often a cost effective tool as part of a more complete audit.

The most valuable results come from a in-depth review from an expert who reads the code, understands the purposes, uses a reproduction of the real site, and can provide advice on how to fix or mitigate the issue.

What new security features can we expect in Drupal 8?

This is a topic we plan to cover in depth during our session Building secure sites with Drupal at DrupalCon Los Angeles.

Drupal 8 will use a template language called Twig that replaces the Drupal-specific PHP template system. This means that we don’t have PHP code in templates. Twig also provides an auto-escaping feature to prevent XSS vulnerabilities in themes.

In Drupal 7 and before, manual integrations of third-party WYSIWYG on many sites allowed the untrusted content editors to to use the “full HTML” text format, creating a cross site scripting vulnerability. In Drupal 8, WYSIWYG is built in with good defaults in a way that keeps the WYSIWYG buttons in synch with the input format. This decreases the likelihood of a site builder accidentally using the Full HTML text format to “make things work” and introduce a vector for XSS.

The PHP module has been removed from core. There were two big motivations for this change. First, this module makes it just a little too easy for a site admin to mistakenly open PHP execution to untrusted users. Second, if an attacker were to gain access to an administrative account (by sniffing sessions or guessing a weak password) then the attacker could use the PHP module to execute arbitrary PHP code. Drupal 8 sites will have fewer potential ways to be compromised.

Drupal 8 has CSRF tokens built in to the routing system for Drupal 8. Ever since Drupal 4.6, there have been simple functions for preventing CSRF:drupal_get_token and drupal_valid_token. Those functions are still available in Drupal 8 if some code requires it, but now it’s even easier to protect a URL from CSRF: the declaration for a route includes a parameter saying whether it should be protected or not—very easy.

What advice would you give new site owners implementing a Drupal project with regards to security?

Keep your site up to date. Subscribe to the security advisories RSS and mailing list or follow @drupalsecurity. Security releases are made on Wednesdays, so make sure your team has a plan and time allocated for doing security upgrades after the site is live. Check your permissions page and consider using a tool likeSecurity Review to audit your site’s configuration.

And, of course, there are dozens more little things that we’ll cover at our session,Building secure sites with Drupal at DrupalCon Los Angeles. If you can’t make the event directly, video will be posted to the site shortly after the event.

 

Tutorial

Vuoi approfondire degli argomenti specifici? Segui i miei tutorial, per dubbi o domande contattami.

Vai ai tutorial

Flickr

Guarda le mie foto su Flickr. Hai bisogno di foto particolari? Vuoi imparare a fotografare? Contattami
flickr_logo

Servizi Online

Vuoi predisporre il tuo sito web personalizzato? Hai bisogno di aiuto o consulenza?

Acquista i servizi online

Contattami

Per approfondimenti o informazioni su corsi di formazione o lavori contattami.

Richiedi uno scambio link con il mio sito.