Intervista con Code Risk: un servizio gratuito di analisi del codice sorgente per i plugin di WordPress

Le vulnerabilità nei plugin di WordPress sono state la causa di più hack del sito rispetto alle vulnerabilità nel core di WordPress. Uno dei motivi per cui ciò sta accadendo è la mancanza di risorse. Il software avrà sempre delle vulnerabilità, anche se il codice principale di WordPress è controllato da migliaia di persone. Inoltre, la fondazione dispone di risorse allocate per garantire che il codice sia il più sicuro possibile.

D'altra parte, molti sviluppatori di plugin non hanno le risorse disponibili per garantire che il codice dei loro plugin sia sicuro, specialmente se si tratta di un piccolo plugin. Anche se tutto cambierà, come spiega Hendrik Buchwald in questa intervista. Hendrik è ingegnere del software, ricercatore sulla sicurezza e co-fondatore di RIPS Technologies.

Cosa fa RIPS Technologies?

RIPS Technologies è un'azienda high-tech con sede a Bochum, in Germania. Forniamo analisi di sicurezza automatizzate per applicazioni PHP come installazione di software locale o servizio cloud altamente scalabile. I nostri innovativi algoritmi di analisi del codice, specificamente dedicati al linguaggio PHP, possono identificare vulnerabilità di sicurezza complesse nelle applicazioni moderne come nessun'altra soluzione. La nostra missione è fornire agli sviluppatori e ai professionisti della sicurezza l'analisi della sicurezza più accurata ed efficiente possibile.

Quale diresti sia l'errore di sicurezza più comune che fanno gli sviluppatori e quali sono le 3 principali vulnerabilità che vedi nei plugin di WordPress?

Non sorprende che i problemi più comuni siano le vulnerabilità di cross-site scripting (XSS) che si verificano ogni volta che l'input dell'utente viene stampato senza un'adeguata sanificazione nella pagina di risposta HTML. In primo luogo, questi problemi si verificano frequentemente perché l'output dei dati è l'operazione più comune delle applicazioni PHP e quindi più colpita da violazioni della sicurezza rispetto ad altre operazioni. E in secondo luogo, data la diversità dei contesti HTML e le sue insidie ​​nella sanificazione, questi problemi vengono introdotti facilmente. Le vulnerabilità del cross-site scripting (XSS) sono piuttosto gravi in ​​WordPress perché possono essere utilizzate, ad esempio, per iniettare codice PHP tramite l'editor di modelli. Fortunatamente, richiedono l'interazione con un amministratore.

Il secondo problema più comune sono le vulnerabilità di SQL injection. Le iniezioni SQL sono più gravi delle vulnerabilità di scripting cross-site perché nel peggiore dei casi possono essere utilizzate per estrarre informazioni riservate dal database, ad esempio le password, senza alcuna interazione da parte dell'utente. Di conseguenza possono essere utilizzati per attacchi dannosi completamente automatizzati.

Quanto è buono o cattivo diresti che è la posizione di sicurezza generale dei 1.000 plug-in più popolari/scaricati?

È difficile rispondere perché non ho esaminato in dettaglio i 1.000 plugin più popolari. Tali operazioni richiederebbero molti mesi per essere completate e, quando saremo pronti, dovremmo ricominciare da capo perché alcuni plugin vengono aggiornati molto frequentemente.

Ecco perché è importante utilizzare un servizio di sicurezza automatizzato come Code Risk. Sebbene dal punteggio CodeRisk, che viene generato dalle scansioni del codice sorgente automatizzate e non verificate che eseguiamo sul repository, posso dire che il codice della maggior parte non è male, sebbene ci siano anche plugin con un punteggio negativo. La maggior parte di questi plugin è molto grande e ha molte funzionalità. Questo aumenta automaticamente le possibilità di avere un bug da qualche parte. Dai nostri test manuali possiamo anche dire che i grandi plugin hanno spesso delle vulnerabilità logiche.

Puoi dirci qualcosa di ciò che offri agli sviluppatori di plugin per WordPress?

Il nostro ultimo progetto CodeRisk aiuta sviluppatori e utenti a valutare gratuitamente il rischio per la sicurezza del codice del loro plugin. Per ora questo è limitato ai plugin di WordPress che sono ospitati nel repository ufficiale di WordPress.

Stiamo recuperando automaticamente nuovi plugin dal repository di WordPress e li scansioniamo con il nostro scanner di sicurezza PHP RIPS. I risultati dettagliati di RIPS sono combinati in un valore di rischio di facile comprensione. Il valore tiene conto della gravità dello sfruttamento riuscito, della quantità di problemi rilevati in relazione alla dimensione del codice e della probabilità che un problema possa essere abusato da terzi.

Gli sviluppatori di plug-in possono richiedere i risultati dettagliati completi per i propri plug-in tramite un sistema automatizzato. Possono utilizzare le informazioni per correggere possibili vulnerabilità e per rafforzare il loro codice, rendendo così l'ecosistema WordPress più sicuro. L'idea alla base di CodeRisk è di consentire agli sviluppatori di plugin di trovare i problemi nel loro codice da soli, anche se non sono esperti di sicurezza. Mentre facciamo molte ricerche sulla sicurezza di WordPress e segnaliamo molte vulnerabilità agli sviluppatori, ci sono troppi plugin per analizzarli tutti manualmente.

Molti sviluppatori di plugin si iscrivono e utilizzano il tuo servizio gratuito di analisi del codice sorgente? Com'è la risposta della community di WordPress?

Attualmente ci sono alcune dozzine di sviluppatori di plugin che utilizzano CodeRisk per ridurre il rischio di vulnerabilità della sicurezza nei loro plugin. Finora abbiamo ricevuto molti buoni feedback e CodeRisk ha già aiutato a risolvere centinaia di problemi.

Gli scanner automatici tendono a segnalare falsi positivi e casi limite che potrebbero non essere sfruttabili. Considerando che molti sviluppatori non sono esperti di sicurezza, cosa stai facendo per aiutarli ed evitare falsi allarmi?

I nostri utenti devono essere consapevoli del fatto che evidenziamo il codice che rappresenta un rischio per la sicurezza. Tra le vulnerabilità di sicurezza non intenzionali, questo include anche altri risultati, ad esempio protezioni deboli che potrebbero diventare una minaccia in seguito.

Non è necessario sapere se e come un problema è sfruttabile per assicurarsi che non diventi una minaccia alla sicurezza in futuro. Ad esempio, se si stampa il valore restituito di una funzione, accertarsi di codificarlo correttamente per evitare vulnerabilità di scripting tra siti. Anche se il valore restituito non contiene ancora l'input dell'utente, questo potrebbe non essere il caso in futuro.

Dove vedi andare questo progetto WordPress gratuito? Hai dei piani per questo? Forse offrendo un servizio premium per tenere in mano gli sviluppatori, aiutarli a capire i risultati e trarne il meglio?

La prossima versione di CodeRisk aggiungerà il supporto per i temi WordPress poiché sono parte integrante della maggior parte dei blog e spesso contengono anche vulnerabilità. Ad un certo punto vorremmo estendere CodeRisk ad altri sistemi di gestione dei contenuti. Al momento non ci sono piani per un servizio premium, ma se c'è abbastanza domanda per questo, questo potrebbe cambiare.

Puoi fornire agli sviluppatori di WordPress due o tre best practice per lo sviluppo sicuro da seguire in modo che possano scrivere codice più sicuro?

Se vuoi scrivere un codice più sicuro, non fidarti mai ciecamente del codice esistente. Assumere sempre che le funzioni possano restituire l'input dell'utente e trattarle come tali. Per informazioni generali su come scrivere codice PHP sicuro, consulta The 2018 Guide to Building Secure PHP Software.

Visita il sito Web di CodeRisk per ulteriori informazioni sul servizio. E se sei uno sviluppatore di plugin per WordPress e il tuo plugin si trova nel repository di plugin di WordPress, registrati per un account gratuito per vedere quali vulnerabilità potrebbe avere il tuo plugin.