Sicurezza

Scopri di più sulla sicurezza del software del core di WordPress in questo libro bianco gratuito. Puoi anche scaricarlo in formato PDF.

Panoramica

Questo documento è un'analisi e una spiegazione dello sviluppo del software core di WordPress e dei relativi processi in merito alla sicurezza, è inoltre un esame dell'intrinseca sicurezza sviluppata direttamente nel software. Chi sta valutando WordPress come sistema di gestione dei contenuti o framework per applicazioni web dovrebbe utilizzare questo documento nella sua analisi e nel suo processo decisionale e gli sviluppatori dovrebbero prenderlo come riferimento per familiarizzare con i componenti di sicurezza e con le best practice.

Le informazioni di questo documento sono relative alla versione stabile del software, WordPress 4.7 alla data di pubblicazione, ma dovrebbe essere considerato pertinente anche per le versioni più recenti del software in quanto la compatibilità con le versioni precedenti è un punto su cui il team di sviluppo di WordPress si concentra molto. Di provvedimenti e modifiche di sicurezza specifici sarà indicata la specifica versione in cui sono stati aggiunti al core. È fortemente raccomandato l'uso dell'ultima versione stabile di WordPress per garantire la più sicura esperienza possibile.

Sintesi

WordPress è un sistema di gestione dei contenuti dinamico e open source utilizzato da un sacco di siti web, applicazioni web, blog e forum. Attualmente alimenta il 38% dei 10 milioni di realtà più importanti di Internet. L'usabilità, l'espandibilità e la competente comunità di sviluppo, lo rendono una scelta popolare, sicura e ricorrente, per siti web di tutte le dimensioni.

Fin dal suo inizio nel 2003, WordPress è stato sottoposto a un rafforzamento continuo affinché il software del core potesse affrontare e mitigare le più comuni minacce di sicurezza, inclusa la lista Top 10 riconosciuta dall'Open Web Application Security Project (OWASP) come le vulnerabilità di sicurezza più comuni, discusse in questo documento.

Il team della sicurezza di WordPress, in collaborazione col team principale del Core di WordPress e sostenuto dalla comunità globale di WordPress, lavora per identificare e risolvere problemi di sicurezza del software core disponibile in WordPress.org per la distribuzione e l'installazione, come anche per raccomandare e documentare le migliori pratiche nell'ambito della sicurezza per gli autori di plugin e temi di terze parti.

Gli sviluppatori e gli amministratori di siti dovrebbero porre particolare attenzione al corretto uso delle API del core e alla configurazione del server sottostante che sono fonte di vulnerabilità comuni, come anche assicurarsi che tutti gli utenti utilizzino password forti per accedere a WordPress.

Una panoramica di WordPress

WordPress è un sistema di gestione dei contenuti (CMS) gratuito e open source. È il software CMS più utilizzato al mondo e alimenta più del 38% dei 10 milioni di siti web1 più importanti, regalandogli una quota di mercato stimata nel 62% di tutti i siti che utilizzano un CMS.

WordPress è concesso in licenza sotto la General Public License (GPLv2 o successiva) che offre quattro libertà fondamentali, e può essere considerata come la dichiarazione dei diritti WordPress:

  1. La libertà di eseguire il programma, per qualsiasi scopo.
  2. La libertà di studiare come funziona il programma e cambiarlo per fargli fare ciò che desideri.
  3. La libertà di ridistribuire.
  4. La libertà di distribuire copie delle versioni modificate ad altri.

Il team principale del Core di WordPress

Il progetto WordPress è meritocratico, gestito da un team direttivo e guidato dal suo co-creatore e sviluppatore principale, Matt Mullenweg. Il team amministra ogni aspetto del progetto, inclusi lo sviluppo del core, WordPress.org e le iniziative della comunità.

Il team direttivo è composto da Matt Mullenweg, cinque sviluppatori principali e più di una dozzina di sviluppatori del core con accesso permanente per le commit. Questi sviluppatori prendono le decisioni tecniche finali, guidano le discussioni sull'architettura e i lavori per le implementazioni.

WordPress ha diversi sviluppatori che contribuiscono. Alcuni sono i primi o attuali sviluppatori con permesso di commit, altri lo potrebbero essere in futuro. Questi sono sviluppatori fidati e veterani che contribuiscono a WordPress e hanno guadagnato un ampio rispetto dai loro pari. Al bisogno, WordPress ha anche sviluppatori ospiti con permesso di commit, persone a cui è dato un permesso di accesso per le commit, qualche volta per un specifico componente, su base temporanea o su periodo di prova.

Gli sviluppatori del core e coloro che contribuiscono, principalmente guidano lo sviluppo di WordPress. Ad ogni versione centinaia di sviluppatori contribuiscono al codice di WordPress. Chi collabora allo sviluppo del core è un volontario che in qualsiasi modo contribuisce al codice base del core.

Il ciclo di rilascio di WordPress

Ogni ciclo di rilascio di WordPress è guidato da uno o più sviluppatori del core di WordPress. Un ciclo di rilascio di solito dura circa 4 mesi dalla riunione di scoping iniziale per il lancio della versione.

Un ciclo di rilascio segue il seguente schema2:

  • Fase 1: pianificare e scegliere i capi progetto. Viene fatto nella chat #core in Slack. I capi progetto discutono le funzionalità della prossima versione di WordPress. I contributori di WordPress vengono coinvolti in tali discussioni. I capi progetto della nuova versione identificano i capi progetto per ciascuna funzionalità.
  • Fase 2: i lavori di sviluppo iniziano. I capi progetto mettono insieme i team e lavorano sulle funzionalità loro assegnate. Chat periodiche vengono programmate per assicurarsi che lo sviluppo proceda.
  • Fase 3: beta. Le beta vengono rilasciate e ai beta tester viene richiesto di segnalare i bug. Da questo momento non vengono presi impegni per nessun altro nuovo miglioramento o funzionalità. Gli autori di plugin e temi di terze parti sono esortati a testare il loro codice sulle modifiche in arrivo.
  • Fase 4: versione Candidata. Da questo momento le stringhe sono bloccate a favore delle traduzioni. Il lavoro si concentra solo sulla verifica di regressione e i blocchi.
  • Fase 5: lancio. La nuova versione di WordPress esce ed è resa disponibile nell'area amministrativa degli aggiornamenti di WordPress.

Numerazione della versione e rilasci di sicurezza

Una versione di WordPress è indicata dalle prime due serie di numeri. Ad esempio 5.0 è una versione principale (major release), come anche 4.9. Un aggiornamento è indicato dalle prime tre serie di numeri. Ad esempio 5.0.1 è una versione di aggiornamento (update release), come anche 4.9.9. Non ci sono versioni “WordPress 5” o “WordPress 4” e ci si riferisce ad ogni versione principale in base alla sua numerazione, ad esempio “WordPress 5.0.”

Le versioni principali possono aggiungere nuove funzionalità e API per sviluppatori. Sebbene nel mondo del software una versione “principale” può causare incompatibilità con le versioni precedenti, WordPress si sforza di evitarlo. La compatibilità con le versioni precedenti è uno dei punti più importanti della filosofia del progetto, assieme all'obiettivo di preparare aggiornamenti più facili per gli utenti come anche per gli sviluppatori.

Una versione minore di WordPress è indicata dalle prime tre serie di cifre. La versione 3.5.1 è una versione minore come anche la 3.4.23. Una versione minore è riservata solo alla correzione di vulnerabilità di sicurezza e di bug critici. Poiché le nuove versioni di WordPress sono rilasciate frequentemente — l'obiettivo è una versione maggiore ogni 4-5 mesi — c'è necessità solo di versioni maggiori e minori.

Compatibilità con le versioni precedenti

Il progetto WordPress si impegna fortemente nel mantenere la compatibilità con le versioni precedenti. Questo impegno implica che temi, plugin e codice personalizzato continueranno a funzionare quando il core di WordPress sarà aggiornato, incoraggiando così i proprietari di siti a mantenere allineata la loro versione di WordPress all'ultima versione con modifiche per la sicurezza.

WordPress e Sicurezza

Il team di sicurezza di WordPress

Il team di sicurezza di WordPress è composto all'incirca da 50 esperti e include i principali sviluppatori e ricercatori nel campo della sicurezza — circa la metà sono impiegati in Automattic (proprietaria di WordPress.com, la prima è più grande piattaforma di host del web) e diversi lavorano nel campo della sicurezza web. Il team si consulta con conosciuti e fidati ricercatori e aziende di hosting3.

Il team Sicurezza di WordPress collabora spesso con altri team sulla sicurezza per affrontare i problemi comuni delle dipendenze, come ad esempio risolvere le vulnerabilità nel parser XML PHP, utilizzato dalle API XML-RPC che accompagnano WordPress, in WordPress 3.9.24. La risoluzione di queste vulnerabilità sono il risultato di uno sforzo congiunto dei team di sicurezza di WordPress e Drupal.

Rischi, processi, e storia della sicurezza di WordPress

Il team Sicurezza di WordPress crede nella divulgazione responsabile e allerta immediatamente i team della sicurezza su qualsiasi potenziale vulnerabilità. Potenziale vulnerabilità di sicurezza possono essere segnalati al team Sicurezza tramite WordPress HackerOne5. Il team Sicurezza comunica al suo interno tramite un canale Slack privato e lavora su un Trac privato e isolato per tracciare, testare e correggere bug e problemi di sicurezza.

Ogni report di sicurezza è segnalato da una comunicazione di ricevimento e il team lavora per determinare la vulnerabilità e il suo grado di severità. Se confermata, il team di sicurezza pianifica la patch per correggere il problema, questa può essere inclusa nella prossima versione di WordPress o può essere proposta immediatamente come versione di sicurezza, a seconda del grado di severità del problema.

Per una versione di sicurezza da applicare il prima possibile, un avviso con i dettagli delle modifiche è pubblicato dal team Sicurezza nelle News del sito6 di WordPress.org. Nell'avviso sono riportati i riconoscimenti per chi ha segnalato la vulnerabilità al fine di incoraggiare e rafforzare la continuità di future segnalazioni responsabili.

Quando una nuova versione è disponibile gli amministratori del software di WordPress vedono una notifica di aggiornamento nella bacheca del loro sito, eseguendo l'aggiornamento manuale gli utenti sono reindirizzati alla schermata di Benvenuto di WordPress che descrive le modifiche. Se gli amministratori hanno abilitato gli aggiornamenti automatici in background, riceveranno un'email quando l'aggiornamento è completato.

Aggiornamenti automatici in background per le versioni di sicurezza

A partire dalla versione 3.7 WordPress ha introdotto gli aggiornamenti automatici in background per tutte le versioni minori7, come ad esempio 3.7.1 e 3.7.2. Il team Sicurezza di WordPress può identificare, correggere e forzare miglioramenti di sicurezza per WordPress senza che i proprietari dei siti debbano fare nulla e gli aggiornamenti di sicurezza si installeranno automaticamente.

Quando un aggiornamento di sicurezza è distribuito per la versione corrente e stabile di WordPress, il team del core distribuisce aggiornamenti per tutte le versioni abilitate agli aggiornamenti automatici in background (da WordPress 3.7 in poi), così anche le versioni più vecchie, ma ancora recenti di WordPress riceveranno gli aggiornamenti di sicurezza.

I proprietari dei siti possono rimuovere gli aggiornamenti automatici in background grazie a una semplice modifica del file di configurazione, ma tenere tale funzionalità è altamente raccomandato dal team del core, come anche eseguire sempre l'ultima versione stabile di WordPress.

2013 OWASP Top 10

L'Open Web Application Security Project (OWASP) è una comunità online dedicata alla sicurezza delle applicazioni web. L'elenco8 Top 10 dell'OWASP è concentrato sull'identificazione dei più severi rischi di sicurezza delle applicazioni per una vasta serie di organizzazioni. Le voci della Top 10 sono selezionate e ne viene fissata la priorità in base alle stime di exploit, rilevamento e impatto.

Le seguenti sezioni trattano le API, le risorse, e le politiche utilizzate da WordPress per rafforzare il software di base, i plugin, e i temi di terze parti, contro questi potenziali rischi.

A1 - Iniezione

In WordPress sono disponibili una serie di funzioni e API per aiutare gli sviluppatori ad evitare l'iniezione di codice non autorizzato e per validare e sanificare i dati immessi. Sono disponibili9 best practice e documentazione su come utilizzare queste API per proteggere, validare e sanificare i dati in input e output in HTML, URL, header HTTP e durante l'interazione col database e col filesystem. Gli amministratori, tramite filtri, possono inoltre restringere ulteriormente i tipi di file che possono essere caricati.

A2 - Autenticazione e gestione delle sessioni interrotta

Gli account utente, l'autenticazione, dettagli come l'ID utente, nome e password sono gestiti dal core di WordPress e le password sono gestite lato server come anche i cookie di autenticazione. Le password sono protette nel database utilizzando tecniche standard di salting e stretching. Dopo la versione 4.0 di WordPress le sessioni esistenti sono cancellate alla disconnessione.

A3 - Cross Site Scripting (XSS)

WordPress fornisce una serie di funzioni per assicurarsi che i dati inseriti dagli utenti siano sicuri10. Gli utenti fidati, che sono amministratori ed editori nelle installazioni standard di WordPress e amministratori di rete nelle installazioni multisito, al bisogno possono pubblicare HTML o JavaScript non filtrati, come ad esempio all'interno di articoli o pagine. Gli utenti non fidati e i contenuti inviati dagli utenti sono filtrati in modo predefinito per rimuovere entities dannose, utilizzando la libreria KSES tramite la funzione wp_kses.

Ad esempio il team del core di WordPress core team ha notato che prima della versione 2.3 di WordPress 2.3 la funzione the_search_query() veniva utilizzata male dalla maggior parte degli autori di temi, che non sottoponevano ad escape l'output della funzione poi utilizzato in HTML. In questo caso estremamente raro di leggera non compatibilità con le versioni precedenti, l'output della funzione è stato modificato in WordPress 2.3 per essere pre-sottoposto ad escape.

A4 - Riferimento oggetto diretto non sicuro

WordPress fornisce spesso riferimenti diretti agli oggetti, come gli identificatori numerici univoci degli account utente o i contenuti disponibili negli URL o nei campi dei moduli. Ma sebbene questi identificatori svelano informazioni dirette del sistema, l'esteso sistema di controllo delle autorizzazioni e degli accessi di WordPress impedisce richieste non autorizzate.

A5 - Configurazione errata della sicurezza

La maggior parte delle opzioni di configurazione della sicurezza di WordPress è circoscritta ad un solo amministratore autorizzato. Le impostazioni predefinite di WordPress sono costantemente valutate dal team del core di WordPress, questo fornisce documentazione e buone pratiche per rafforzare la configurazione di sicurezza dei server per l'esecuzione di un sito11 WordPress.

A6 - Esposizione dei dati sensibili

Le password degli account utente di WordPress sono sottoposte a salting e hashing tramite il framework12 Portable PHP Password Hashing. Il sistema di autorizzazioni di WordPress è utilizzato per controllare gli accessi a informazioni private come gli utenti PII registrati, gli indirizzi email di chi commenta, contenuto privato pubblicato, ecc. Nel core di WordPress 3.7 è stato introdotto un misuratore di robustezza delle password che fornisce agli utenti ulteriori informazioni sulle loro password e fornisce suggerimenti su come aumentarne la robustezza. Nella configurazione di WordPress c'è inoltre un'impostazione opzionale per richiedere forzatamente HTTPS.

A7 - Controllo di accesso a livello di funzione mancante

Per ogni funzione di accesso WordPress verifica che ci siano i permessi e le autorizzazioni appropriate prima che l'azione sia eseguita. Il controllo dell'accesso o della visualizzazione di URL amministrativi, menu e pagine senza gli appropriati permessi è fortemente integrato nel sistema di autenticazione per prevenire gli accessi di utenti non autorizzati.

A8 - Cross Site Request Forgery (CSRF)

WordPress utilizza token crittografati, chiamati nonce13, per convalidare lo scopo delle richieste di utenti autorizzati e proteggere da potenziali minacce di CSRF. WordPress fornisce un'API per la generazione di questi token, per la creazione e verifica di token temporanei univoci e i token sono limitati a un specifico utente, una specifica azione, un specifico oggetto e uno specifico periodo di tempo, che possono essere aggiunti a moduli e URL al bisogno. Inoltre tutti i token sono annullati alla disconnessione.

A9 - Utilizzo di componenti con vulnerabilità note

Il team del core di WordPress monitora attentamente le poche librerie e framework inclusi in WordPress per le funzionalità del core. In passato il team del core ha contribuito a diversi componenti di terze parti per renderli più sicuri, come nell'aggiornamento di correzione della vulnerabilità cross-site di TinyMice in WordPress 3.5.214.

Se necessario il team del core può decidere di fare un fork o di sostituire componenti esterni critici, come nel caso della libreria SWFUpload ufficialmente sostituita dalla libreria Plupload nella 3.5.2 e un fork sicuro di SWFUpload è stato reso disponibile dal team15 della sicurezza per quei plugin che nel breve periodo avrebbero continuato ad utilizzare SWFUpload.

A10 - Reindirizzamenti ed inoltri non convalidati

Il sistema interno di WordPress per il controllo dell'autenticazione e degli accessi protegge gli utenti dal reindirizzamento non voluto, indesiderato, o automatico, a scopo fraudolento. Questa funzionalità è resa disponibile anche agli sviluppatori di plugin tramite questa API wp_safe_redirect()16.

Ulteriori rischi e preoccupazioni per la sicurezza

XXE (XML eXternal Entity) elaborazione degli attacchi

Quando elabora l'XML, WordPress disabilita il caricamento di entities XML personalizzate per prevenire attacchi External Entity ed Entity Expansion. Oltre le funzioni PHP del core, WordPress non fornisce agli autori di plugin ulteriori API per il trattamento sicuro di XML.

Attacchi SSRF (Server Side Request Forgery)

Le richieste HTTP emesse da WordPress sono filtrate per impedire l'accesso agli indirizzi IP privati e di loopback. Inoltre l'accesso è consentito solo a specifiche porte HTTP standard.

Sicurezza dei Plugin e dei Temi di WordPress

Il Tema Predefinito

WordPress ha bisogno di un tema attivo per poter mostrare del contenuto in frontend. Il tema predefinito distribuito con il core di WordPress (attualmente "Twenty Twenty") è stato esaminato e testato con grande impegno sia dal team dei Theme Developers che dal team del Core Development.

Il tema predefinito può essere un ottimo punto di partenza per lo sviluppo di un tema personale. Gli sviluppatori web possono creare temi child che includano alcune personalizzazioni facendo affidamento sul tema predefinito per la maggior parte delle funzionalità e della sicurezza. Se non utilizzato il tema predefinito può essere facilmente rimosso da un amministratore.

Directory dei Temi e dei Plugin di WordPress

Sono presenti approssimativamente 50.000+ plugin e 5.000+ temi sul sito WordPress.org. Questi temi e plugin vengono proposti per l'inclusione e valutati manualmente da volontari prima di renderli disponibili nel repository.

L'inclusione di plugin e temi nel repository non è un'automatica garanzia di assenza di vulnerabilità. Agli autori dei plugin vengono fornite linee guida da consultare prima d'inviare una richiesta di inclusione nel repository17 e una documentazione estesa su come affrontare lo sviluppo18 di un tema WordPress è a disposizione sul sito WordPress.org.

Ogni plugin e tema ha la possibilità di essere sviluppato in continuazione dal suo propietario. Ciascuna correzione o caratteristica di sviluppo aggiunta successivamente può essere caricata nel repository e resa disponibile agli utenti che hanno installato quel plugin o quel tema fornendo una descrizione delle modifiche apportate. Gli amministratori di un sito vengono notificati dei plugin che necessitano di un aggiornamento nella loro bacheca di amministrazione.

Quando la vulnerabilità di un plugin è scoperta dal Team Security di WordPress l'autore del plugin viene contattato e si lavora assieme per correggere e rilasciare una versione sicura del plugin. In assenza di una risposta da parte dell'autore del plugin o in base alla serietà della vulnerabilità scoperta il plugin/tema è rimosso dalla directory pubblica e, in alcuni casi, corretto e aggiornato direttamente dal Security Team.

Il team di revisione dei temi

Il team della revisione dei temi è un gruppo di volontari guidato da consolidati membri chiave della comunità di WordPress, revisiona e approva i temi presentati per l'inclusione nella directory ufficiale dei temi di WordPress. Il team della revisione dei temi mantiene le linee guida19 ufficiali per la revisione dei temi, i dati20 degli unit test, il plugin Theme Check21 e cerca di coinvolgere ed educare la comunità di sviluppatori di temi per WordPress alle best practice nello sviluppo. Le integrazioni nel gruppo sono moderate dagli sviluppatori con facoltà di commit del team di sviluppo di WordPress.

Il ruolo dell'hosting provider nella sicurezza di WordPress

WordPress può essere installato su una moltitudine di piattaforme. Sebbene il software del core di WordPress fornisca diverse misure per mettere in funzione un'applicazione web sicura, elencate in questo documento, la configurazione del sistema operativo e del server web che ospita il software è ugualmente importante per tenere le applicazioni di WordPress al sicuro.

Nota sulla sicurezza di WordPress e WordPress.com

WordPress.com è la più grande installazione di WordPress al mondo ed è sotto il possesso e la gestione di Automattic Inc., fondata da Matt Mullenweg, il co-creatore del progetto WordPress. WordPress.com funziona sul core del software di WordPress e ha le proprie prassi di sicurezza, rischi e soluzioni22. Questo documento fa riferimento al software WordPress autonomo e open source scaricabile da WordPress.org e installabile su qualsiasi server al mondo.

Appendice

Core WordPress APIs

La Core Application Programming Interface (API) di WordPress è costituita da un insieme di API23, ognuna delle quali comprende un dato insieme di funzionalità e il loro utilizzo. Insieme formano l'interfaccia del progetto che permette a plugin e temi di interagire, modificare ed estendere le funzionalità del core di WordPress in modo sicuro e senza rischi.

Mentre ogni API di WordPress fornisce le migliori pratiche e i metodi standardizzati per interagire e estendere il software del core di WordPress, le seguenti API di WordPress sono le più pertinenti per rafforzare e temprare la sicurezza di WordPress:

Database API

L'API del database24, aggiunta in WordPress 0.71, fornisce il metodo corretto per accedere ai dati come valori nominali che sono memorizzati a livello di database.

Filesystem API

Le API per il Filesystem25, aggiunte in WordPress 2.626, sono state originariamente create per le funzionalità di aggiornamento automatico di WordPress stesso. Le API per il Filesystem astraggono le funzionalità necessarie per scrivere e leggere file locali nel filesystem, per farlo in modo sicuro su vari di tipi di host.

Lo si può fare grazie alla classe WP_Filesystem_Base e diverse sottoclassi che implementano modi diversi di collegarsi al filesystem locale, in base al supporto proprio dell'host. Qualsiasi tema o plugin che ha bisogno di scrivere file localmente lo dovrebbe fare utilizzando la famiglia di classi WP_Filesystem.

HTTP API

Le HTTP API27 introdotte in WordPress 2.728 ed estese in WordPress 2.8, rendono standard le richieste HTTP di WordPress. Le API gestiscono cookie, gzip codifica e decodifica, decodifica chunk (per HTTP 1.1) e varie altre implementazioni del protocollo HTTP. Le API rendono standard le richieste, testano ogni metodo prima di spedire e, in base alla configurazione del tuo server, utilizzano i metodi appropriati per eseguire le richieste.

Autorizzazioni e API utente

Le autorizzazioni e le API29 utente sono un insieme di funzioni che servono alla verifica delle autorizzazioni e dei permessi di ogni songolo utente per eseguire le attività e le operazioni richieste per proteggere il sistema dagli accessi non autorizzati o dall'esecuzione di funzioni non consentite o permesse oltre le proprie capacità.

Licenza per contenuti cartacei

Il testo di questo documento (non include il logo o il marchio di WordPress) è distribuito con licenza CC0 1.0 Universal (CC0 1.0) Donazione al Pubblico Dominio. Puoi copiare, modificare, distribuire ed esibire l'opera, anche per scopi commerciali, tutto questo senza chiedere l'autorizzazione.

Un ringraziamento speciale al libro bianco sulla sicurezza, che ha fornito spunti di ispirazione.

Letture aggiuntive

Scritto da Sara Rosso

Contribuzioni di Barry Abrahamson, Michael Adams, Jon Cave, Helen Hou-Sandí, Dion Hulse, Mo Jangda, Paul Maiorana

Versione 1.0 March 2015

Note a piè di pagina