Architettura della sicurezza di WordPress

Perché è importante comprendere l’architettura di sicurezza di WordPress?

Come ricercatore di vulnerabilità, probabilmente esaminerai molto codice prima di trovare una vulnerabilità.

Anche se potresti avere familiarità con il funzionamento delle applicazioni web, WordPress ha una sua architettura e convenzioni uniche che richiedono un approccio diverso.

A differenza dei tipici framework MVC (Model-View-Controller) con una netta separazione delle attività e un routing prevedibile, WordPress è costruito attorno a un sistema basato su hook.

Il codice viene eseguito proceduralmente, con azioni e filtri eseguiti in vari punti durante una richiesta.

Non ci sono controller che gestiscono percorsi o directory specifici dedicati alla logica dell’applicazione.

Invece, plugin, temi e core condividono tutti lo stesso ambiente globale e si agganciano allo stesso flusso di esecuzione.

Questo può rendere più difficili l’analisi statica e il monitoraggio del flusso di dati, poiché i percorsi di esecuzione del codice sono spesso indiretti e distribuiti su più file e componenti.

Se non hai mai sviluppato applicazioni WordPress, potresti imbatterti in funzioni e design pattern non familiari.

Questa guida ti aiuterà a riconoscere rapidamente i meccanismi di sicurezza di WordPress, consentendoti di filtrare il codice adeguatamente protetto e di concentrarti sulle aree che hanno maggiori probabilità di contenere vulnerabilità.

Oltre a comprendere quali funzioni di sicurezza esistono, imparerai anche come testarne l’implementazione per verificare se vengono applicate correttamente e se è possibile aggirarle.

Le vulnerabilità di WordPress solitamente comportano l’uso mancante o incompleto delle funzioni di sicurezza integrate.

Riconoscere questi schemi, sia tramite revisione statica del codice che tramite test dinamici, ti aiuterà a identificare rapidamente le vulnerabilità.

Etica della sicurezza di WordPress

Nella sua documentazione ufficiale, WordPress presenta una serie di idee fondamentali agli sviluppatori, incoraggiandoli ad adottare una mentalità orientata alla sicurezza durante il processo di sviluppo:

• Non fidarti di nessun dato.
• Affidati all’API di WordPress.
• Mantieni aggiornato il tuo codice.

Inoltre, vengono offerti una serie di principi guida più specifici:

• Non fidarti mai dell’input dell’utente.
• Escaping il più tardi possibile.
• Evita tutto ciò che proviene da fonti non attendibili (ad esempio, database e utenti), terze parti (ad esempio, Twitter), ecc.
• Non dare mai nulla per scontato.
• La sanificazione va bene, ma la validazione/rifiuto sono migliori.

Possiamo prendere questi principi di alto livello e invertirli per sviluppare una mentalità da ricercatore di vulnerabilità quando analizziamo il codice WordPress:

• Questa applicazione WordPress (plugin/tema) utilizza dati forniti dall’utente?
  Come vengono gestiti e per quale scopo vengono utilizzati?
• Questa applicazione WordPress utilizza le funzioni di WordPress e le utilizza correttamente?
  Tenta di implementare autonomamente funzionalità di convalida, sanificazione, escape o autorizzazione invece di usare le funzioni fornite da WordPress?
• Questa applicazione WordPress incorpora dipendenze di terze parti obsolete?
• Le funzioni di escape di WordPress vengono usate in tutto il sito? Sono usate correttamente?
• Vengono fatte delle ipotesi su come un utente fornirà input?
• Vengono usate le denylist invece delle allowlist?

Questo è solo un breve esempio di domande che puoi porti come ricercatore sulla sicurezza che si concentra su WordPress.