I plugin di WordPress sono sicuri da usare?
Pubblicato: 2020-04-16Nel corso degli anni, la ricerca ha identificato che oltre il 20% dei 50 plugin WordPress più popolari sono vulnerabili ai comuni attacchi Web. Inoltre, una ricerca mirata sui plug-in di e-commerce ha scoperto che 7 dei 10 plug-in di e-commerce più popolari contengono vulnerabilità. Sfortunatamente, gli hacker in genere sfruttano queste applicazioni vulnerabili per accedere a informazioni sensibili come cartelle cliniche e dettagli finanziari. In altri casi, le vulnerabilità consentono agli hacker di deturpare i siti o di reindirizzarli ad altri siti controllati dagli aggressori.

In casi più recenti, abbiamo visto plug-in WordPress dannosi utilizzati non solo per mantenere l'accesso a server compromessi, ma anche per estrarre criptovaluta. Quindi, questo pone una domanda su quanto siano sicuri i plugin di WordPress.
In questo blog, ci concentreremo profondamente sui plugin di WordPress come potenziali fonti di violazioni della sicurezza.
Sviluppo Web basato su plug-in.
In generale, WordPress è il Content Management System (CMS) più popolare al mondo poiché alimenta oltre il 30% del Web.
Detto questo, il punto di forza principale di WordPress risiede nella sua capacità di consentire la personalizzazione dei siti attraverso la sua vasta offerta di decine di migliaia di plugin e temi. Questi plug-in variano per tipo e funzionalità, dall'aggiunta di un modulo di contatto al sito all'ottimizzazione di un blog per la SEO o persino alla pubblicazione automatica di nuovi post su Facebook.
Sviluppo di terze parti.
L'idea principale alla base dello sviluppo basato su plug-in è quella di offrire funzionalità aggiuntive per estendere le funzionalità principali di un sistema. In sostanza, il nucleo dell'applicazione è in genere gestito da un insieme di sviluppatori a lungo termine, mentre terze parti creano una serie di plug-in attorno al nucleo dell'applicazione
Questo processo è vantaggioso sia per il provider dell'applicazione che per il provider del plug-in poiché il provider dell'applicazione può concentrarsi maggiormente sulla funzionalità di base mentre il provider del plug-in non deve preoccuparsi dell'infrastruttura del plug-in, fornita dalla funzionalità principale dell'applicazione. In generale, WordPress è supportato anche da una comunità globale di migliaia di sviluppatori e appassionati di software commerciali e open source.
Nessuna linea guida di sicurezza
Nel complesso, sebbene esistano alcune serie di standard e raccomandazioni di codifica, tecnicamente non esistono linee guida di sicurezza né requisiti standard a cui uno sviluppatore di plug-in deve attenersi rigorosamente. Ciò significa che una vulnerabilità in un plug-in può propagarsi su milioni di siti Web.
E poiché WordPress è ampiamente utilizzato, è di conseguenza un bersaglio popolare per gli attacchi. Quindi, in sostanza, un hacker che sfrutta la vulnerabilità di un plugin può infettare migliaia di siti. Uno scenario che è già stato assistito da molti blogger.
Sfortunatamente, anche le vulnerabilità relative ai plug-in tendono ad essere ricorrenti, sfruttabili e difficili da rilevare. Pertanto, è necessario comprendere ulteriormente tali vulnerabilità per mitigare eventuali minacce alla sicurezza rilevanti. Scaviamo più a fondo, vero?

WordPress è davvero sicuro?
Per prima cosa, rispondiamo a questa domanda. Per la maggior parte, WordPress come ecosistema grezzo è molto sicuro purché vengano rispettate le migliori pratiche di sicurezza di WordPress. In media, ogni giorno sul web vengono hackerati circa 30.000 nuovi siti web. Questi hacker tendono a prendere di mira i siti Web WordPress a causa delle vulnerabilità dei plug-in, delle password deboli e del software obsoleto. Quindi, ottenere la migliore sicurezza richiede un livello di intenzionalità, il che significa seguire alcune best practice di base per la sicurezza di WordPress per ridurre la tua vulnerabilità agli attacchi.
Leggi di più: 11 modi efficaci per aumentare il tuo sito Web WordPress per un traffico elevato
Da dove vengono queste vulnerabilità?
Un recente rapporto di wpscan.org ha rivelato che WordPress ha quasi 4.000 vulnerabilità di sicurezza note. La maggior parte di queste vulnerabilità sono state causate dai plugin. E mentre alcune di queste vulnerabilità relative ai plug-in possono avere gravi conseguenze, molte rimangono inosservate per anni prima di essere risolte. Nella maggior parte dei casi, possono essere comunemente corretti con modifiche piccole e localizzate al codice sorgente.
Tuttavia, prima di anticipare noi stessi, facciamo un passo indietro.
Cosa sono i plugin?
Fondamentalmente, i plugin sono estensioni software che integrano le applicazioni con nuove funzionalità e comportamenti personalizzati. In particolare, WordPress offre migliaia di plugin (più di 52.000), che sono stati utilizzati per creare migliaia di applicazioni web personalizzate.
Poiché le applicazioni Web basate su plug-in sono diventate più mainstream, più sviluppatori hanno rivolto la loro attenzione all'esplorazione del loro potenziale per reimmaginare le applicazioni Web componendo, configurando ed estendendo diversi plug-in con funzionalità all'avanguardia.
Implicazioni dello sviluppo dei plugin
Detto questo, la possibilità di sfruttare i plugin per estendere i sistemi web con funzionalità aggiuntive e personalizzate ha implicazioni sia positive che negative per gli sviluppatori. In primo luogo, una nota positiva, ci sono normalmente più opzioni di personalizzazione tra cui scegliere, dando agli sviluppatori la possibilità di creare rapidamente e facilmente applicazioni Web personalizzate in base alle esigenze degli utenti. Pertanto, facilitando la prototipazione rapida e lo sviluppo.
Tuttavia, sul lato negativo, un'applicazione Web può finire per essere una composizione complessa di più plug-in da fonti diverse. Il che alla fine pone preoccupazioni relative alla sicurezza dei plugin. Ad esempio, TimThumb, un plug-in utilizzato da milioni di applicazioni basate su WordPress, secondo quanto riferito, era aperto a un exploit in cui gli aggressori potevano eseguire deliberatamente codice remoto.
In effetti, circa il 15% delle vulnerabilità nei sistemi web può essere considerato critico secondo il National Vulnerability Database (NVD) degli Stati Uniti, di cui quasi il 35% è costituito da vulnerabilità facilmente sfruttabili.
Quali sono le conseguenze dei plugin compromessi?
A parte gli utenti che perdono informazioni finanziarie o addirittura la loro cartella clinica è compromessa, più grave è una vulnerabilità, maggiore è l'impatto finanziario sulle società di software. Inoltre, ciò è ulteriormente esacerbato se gli sviluppatori non riescono a rilasciare un percorso praticabile al momento della divulgazione. Pertanto, i fornitori di plug-in in genere si sforzano di creare applicazioni più sicure
Esaminiamo ora alcune vulnerabilità di sicurezza che si trovano in genere nei plug-in per ottenere una comprensione più ampia delle loro conseguenze e implicazioni.
Vulnerabilità di sicurezza
Come abbiamo raccolto, le vulnerabilità aprono opportunità per il potenziale uso improprio dei sistemi software. In definitiva, poiché WordPress consente a milioni di sviluppatori in tutto il mondo di creare i propri plug-in, non è realistico aspettarsi che si verifichi un livello di compromissione nei plug-in.
Di conseguenza, la sicurezza può essere violata da interazioni impreviste dei plug-in con il sistema principale, portando a vulnerabilità che possono essere potenzialmente sfruttate dagli aggressori. Ciò implica quindi che la sicurezza dei sistemi Web dipende dal tenere sotto controllo sia il sistema principale che le vulnerabilità dei plug-in.
Complessità di WordPress
A causa della complessità di WordPress, a volte tende ad essere afflitto da vulnerabilità. Ad esempio, WordPress fornisce un'infrastruttura intuitiva a cui i plug-in possono contribuire con nuove funzionalità modificando lo stato globale condiviso o eseguendo una funzione in un punto specifico dell'esecuzione del core del sistema. Di conseguenza, una vulnerabilità del plug-in può emergere quando il plug-in invia dati di input dannosi ai componenti principali senza un'adeguata sanificazione o convalida dell'input.
Esempi di vulnerabilità dei plugin
In definitiva, le vulnerabilità dei plug-in più comuni sono lo scripting tra siti, SQL Injection e Richieste contraffatte tra siti. Nel complesso, il tipo di vulnerabilità più pericoloso che può essere facilmente sfruttato dagli aggressori è SQL Injection. Tuttavia, esistono altre vulnerabilità, fonti di violazione e compromissioni, vale a dire:
- Errori nell'elaborazione dei dati
- Convalida dell'input errata
- Esposizione alle informazioni
- Attraversamento del sentiero
- Caratteristiche di sicurezza
- Controlli di accesso
- Controllo degli accessi improprio
- Autorizzazione impropria
- Autenticazione impropria
- Falsificazione di richieste tra siti
- Caricamento illimitato di file
- File accessibili a soggetti esterni
- Collegamento seguente
- Apri Reindirizzamento
- Iniezione di comando
- Iniezione del comando del sistema operativo
- Cross Site Scripting
- SQL Injection
- Iniezione di codice

Per più contesto, esploriamo gli attacchi e le vulnerabilità più comuni.
- · Iniezione SQL: le iniezioni SQL si verificano in genere quando un utente malintenzionato ottiene l'accesso al database WordPress di un utente ea tutti i dati del suo sito Web. Le iniezioni SQL possono essere utilizzate anche per inserire nuovi dati in un database, inclusi collegamenti a siti Web dannosi o spam.
Le iniezioni SQL consentono l'esecuzione di comandi sul server back-end, come l'estrazione di informazioni riservate. In un ambiente ospitato, un attacco SQL Injection può essere ulteriormente utilizzato come trampolino di lancio per attacchi contro siti non vulnerabili.
- · Cross-Site Scripting: questo attacco consente l'esecuzione di uno script sul client per aggirare i controlli di accesso. In genere si rivolge a tutti i visitatori di un sito. In un ambiente ospitato, un tale attacco può essere utilizzato per rubare i cookie di sessione dell'amministratore del sito, consentendo all'attaccante di fingere di essere l'amministratore.
- · Falsificazione di richieste tra siti: questa vulnerabilità consente all'hacker di eseguire una transazione a livello di applicazione per conto della vittima. In un ambiente ospitato, un utente malintenzionato può accedere al sito per conto dell'amministratore ed eseguire attività dannose come reindirizzare gli utenti o eseguire transazioni amministrative.
Comuni nei plugin di WordPress, le vulnerabilità di scripting tra siti funzionano in questo modo: un utente malintenzionato trova un modo per convincere una vittima a caricare pagine Web con script JavaScript non sicuri.

Dove compaiono la maggior parte delle vulnerabilità?
Uno studio tecnico ha scoperto che la maggior parte delle vulnerabilità (circa il 92%) compare nel codice del plugin. Inoltre, secondo i risultati, vulnerabilità come Cross-site Scripting e Cross-site Request Forgery erano più comuni nel codice del plug-in, mentre altre vulnerabilità erano più prevalenti nel codice principale. Allo stesso modo, lo studio ha rivelato che la qualità dei plug-in variava e che non esisteva alcuna correlazione tra le valutazioni dei plug-in e il numero di vulnerabilità riscontrate in essi.

Il processo di scrittura del codice PHP
Il processo di scrittura del codice potrebbe essere la genesi di qualsiasi vulnerabilità o compromesso. In generale, PHP è noto per supportare l'esecuzione di codice arbitrario sul lato server senza invocare direttamente il sistema operativo host. Detto questo, ogni volta che gli sviluppatori sono negligenti durante il processo di scrittura del codice, aumenta la possibilità dell'introduzione di vulnerabilità di Cross-site Scripting nel codice del plug-in.
D'altra parte, per quanto riguarda SQL Injection è una vulnerabilità comune perché può essere facilmente rilevata e sfruttata. Ironia della sorte, è probabile che anche un sito Web con una piccola base di utenti sia soggetto a un tentativo di attacco di SQL Injection.
Parte dell'esposizione alle vulnerabilità deriva dagli sviluppatori che utilizzano risorse non sicure. Allo stesso modo, una corretta convalida dell'input è ancora una sfida importante per gli sviluppatori di plug-in perché molti dei plug-in sviluppati di recente sono stati creati da sviluppatori meno esperti
Le vulnerabilità causate dai plugin di WordPress sono critiche?
Tutte le cose considerate; una vulnerabilità può influenzare negativamente il sistema web in diversi modi. Ad esempio, lo sfruttamento riuscito di una vulnerabilità può portare a una completa perdita di riservatezza, anche se senza perdita di disponibilità.
Come è stato notato, SQL Injection sembra essere il tipo di vulnerabilità più pericoloso, sebbene influisca solo parzialmente sull'integrità, la disponibilità e la riservatezza del sistema. Tuttavia, una tale vulnerabilità ha il potenziale per consentire agli aggressori l'accesso illimitato a file o informazioni.
Pertanto, inavvertitamente, la maggior parte delle vulnerabilità può potenzialmente portare a violazioni dei dati, mentre alcune vulnerabilità non espongono necessariamente le applicazioni Web a seri rischi per la sicurezza. In entrambi i casi, è importante evitare di correre rischi con tali probabilità.
Per quanto tempo può sopravvivere una vulnerabilità nel codice di un plugin di WordPress?
Normalmente, le vulnerabilità nel codice tendono a transitare attraverso stati distinti, variando dall'introduzione, passando per la divulgazione, fino al rilascio di una patch che risolve la minaccia alla sicurezza.
In genere, una vulnerabilità viene rivelata quando lo scopritore rivela i dettagli della minaccia alla sicurezza a un pubblico più ampio. Alla fine, la vulnerabilità viene risolta quando lo sviluppatore rilascia una patch che corregge la minaccia alla sicurezza sottostante. Tuttavia, a volte una vulnerabilità rimane inosservata in un'applicazione Web per anni prima di essere identificata e quindi risolta.
Possibili mitigazioni e metodi di rilevamento
Prevenire è meglio che curare, come dice la maggior parte delle persone. Quindi, se gli sviluppatori di plug-in sono in grado di comprendere, rilevare ed eliminare completamente gli scripting tra siti, SQL Injection e Richieste contraffatte tra siti, è possibile che avremo plug-in con il 75% di vulnerabilità in meno.
Tuttavia, vale la pena notare che queste tre vulnerabilità non sono le uniche che possono essere sfruttate dagli aggressori. Ma piuttosto, sono le vulnerabilità più comuni.
Pertanto, sebbene queste strategie di mitigazione proposte non garantiscano che un determinato plug-in sia completamente sicuro, tuttavia stabiliscono buoni principi per la prevenzione delle vulnerabilità. Per esempio:
- Comprendi come vengono utilizzati i dati e la codifica prevista dalle parti principali di WordPress. In questo caso, gli sviluppatori dovrebbero sempre presumere che tutti gli input siano dannosi e rifiutare qualsiasi input che non sia strettamente conforme al modello di codifica richiesto o trasformarlo in un input valido.
- Per proteggere i database dall'iniezione di SQL, gli sviluppatori dovrebbero utilizzare istruzioni SQL parametrizzate separando il codice dalla manipolazione dei dati. Inoltre, controlla sempre le intestazioni per verificare se la richiesta proviene dalla stessa origine. Inoltre, potrebbe anche essere utile evitare di esporre i dati ad aggressori non autenticati.
- Una buona pratica consiste nell'evitare il metodo GET per qualsiasi richiesta che attivi un cambio di stato.
Rilevamento vulnerabilità
Sfortunatamente, non esiste un metodo coerente per rilevare i punti deboli del codice più comuni con il 100% di precisione e copertura. Sfortunatamente, anche le tecniche moderne che utilizzano l'analisi del flusso di dati per rilevare gli script cross-site, a volte danno falsi positivi.
Al contrario, i metodi di analisi manuale come le revisioni del codice tendono ad essere più efficaci dei metodi completamente automatizzati, soprattutto per le vulnerabilità legate alla progettazione. Ad esempio, la falsificazione delle richieste tra siti è particolarmente difficile da rilevare in modo affidabile utilizzando metodi automatizzati perché ogni applicazione ha la propria politica di sicurezza e modalità per indicare quali richieste richiedono una forte certezza che l'utente intenda effettuare la richiesta.
Tuttavia, d'altra parte, l'analisi manuale può essere utile per trovare SQL injection, anche se potrebbe non ottenere la copertura del codice desiderata entro limiti di tempo limitati. Questo può diventare difficile per i punti deboli che devono essere considerati per tutti gli input, poiché la superficie di attacco può essere eccessivamente ampia.
Di conseguenza, alcune organizzazioni sottolineano l'importanza di un approccio equilibrato che includa sia revisioni manuali che analisi automatizzate che comprendano tutte le fasi del processo di sviluppo del sistema web.
Migliori pratiche per proteggere la tua applicazione WordPress
- Scarica i plug-in solo da fonti affidabili come WordPress.org: poiché chiunque può sviluppare un plug-in per WordPress, notoriamente gli hacker sfruttano questa vulnerabilità per nascondere i propri plug-in dannosi. Un mercato rispettabile potrebbe non garantire completamente l'accesso a plug-in innocui, ma è consigliato come pratica attenuante.
- Assicurati sempre che tutti i tuoi plugin siano aggiornati: gli utenti di WordPress in genere ricevono e-mail di notifica che spesso ignorano. Assicurati di impostare i tuoi plug-in in modo che si aggiornino automaticamente, o almeno aggiornali manualmente tu stesso.
- Verifica lo stato di sicurezza del plug-in scansionandolo per problemi di sicurezza: la maggior parte dei plug-in sono open source, il che significa che il loro codice sorgente è disponibile. Quindi, assicurati di utilizzare uno strumento di analisi del codice sorgente statico che ti fornirà il "certificato di salute" del plug-in. Alcuni scanner avanzati possono persino indicarti i consigli di correzione ottimali e più rapidi.
- Rimuovere tutti i plug-in inutilizzati: sfortunatamente, il codice dei plug-in vecchi e inutilizzati in genere rimane sul server, anche quando i plug-in sono inattivi. Quindi, assicurati di rimuovere sempre i plug-in inutilizzati come parte della manutenzione del tuo sito WordPress
Raccomandazioni per gli sviluppatori di plugin
- Incorpora sempre la sicurezza durante lo sviluppo del plug-in: le vulnerabilità comportano un costo maggiore per essere risolte in un secondo momento, quindi integra sempre la sicurezza nello sviluppo del plug-in come parte del processo sicuro del ciclo di vita dello sviluppo del software (SDLC).
- Esegui il plug-in attraverso uno scanner di codici per assicurarti che sia all'altezza degli ultimi standard di sicurezza. Assicurati di condurre un test completo di analisi del codice sorgente durante lo sviluppo e prima del rilascio.
Sviluppo di plugin sicuri
Come è stato notato, gli sviluppatori di plugin devono sforzarsi di scrivere codice sicuro. Sfortunatamente, molti sviluppatori non sanno ancora come farlo, poiché non sono così abili. In particolare, data la natura delle vulnerabilità più comuni sopra citate, è chiaro che molti sviluppatori non comprendono gli attacchi comuni, le funzioni di sicurezza fornite dal linguaggio e dalla piattaforma che utilizzano e come utilizzare le pratiche applicabili per mitigare i problemi di sicurezza.
Quindi, la nostra raccomandazione a Creole Studios è che forse nuove metodologie dovrebbero essere sviluppate su misura per gli sviluppatori di plugin. Tali metodologie dovrebbero promuovere la sicurezza nei requisiti e nelle fasi di progettazione poiché gli sviluppatori sono le entità più importanti nella sicurezza del software.
Pensieri finali
Per riassumere l'argomento, i plug-in di WordPress possono essere compromessi, con le vulnerabilità più comuni che sono cross-site Scripting, SQL Injection e Cross-site Request Forgery.
Sfortunatamente, la ricerca sembra suggerire che la frequenza con cui si verificano queste vulnerabilità non sembra diminuire nel tempo. È lecito ritenere che la ragione principale di ciò sia che la maggior parte degli sviluppatori di plugin per WordPress rimane un po' poco qualificata per quanto riguarda la programmazione sicura.
Detto questo, la prima linea di difesa dovrebbe essere il team di sviluppo! E crediamo che una volta attuate le migliori pratiche di sicurezza, gli utenti possano dormire meglio la notte, sapendo di essere protetti dai criminali informatici.
Per ulteriori informazioni sulle nostre pratiche di sicurezza di WordPress, assicurati di contattare gentilmente una consulenza.