Best practice di sicurezza per sviluppatori di plugin e temi di WordPress
Pubblicato: 2020-12-09Come sviluppatore di WordPress, ci sono molte decisioni che devi prendere su cosa lavorare. Il tuo interesse principale e la tua priorità sono creare un tema o un plug-in straordinario e le misure di sicurezza spesso passano in secondo piano quando ti siedi al posto di guida per lavorare sul codice. Quando è stata l'ultima volta che ti sei seduto e hai esaminato il tuo codice per problemi di sicurezza? No, non la pensavo così
Questi suggerimenti si basano sulla mia esperienza sia nello sviluppo di plug-in in CleverPlugins sia nell'aiuto di innumerevoli clienti a riportare online i loro siti Web dopo essere stati violati. Lo sviluppo di un plug-in di sicurezza come WP Security Ninja non mi ha reso meno paranoico riguardo al codice di altre persone.
Il motivo più comune per i siti Web compromessi è ancora una pessima gestione delle password, ma questa non dovrebbe essere una scusa per utilizzare alcuni dei semplici modi in cui puoi proteggere il tuo codice.
Quando sviluppi un plugin o un tema, vuoi che diventi popolare e che sia installato su quanti più siti web possibili. Maggiore è il tuo successo, maggiori sono le possibilità che le persone cerchino di abusare del tuo lavoro per hackerare i siti Web dei tuoi utenti.
A causa della popolarità di WordPress, è diventato uno degli obiettivi più comuni per gli hacker. Se viene rilevata una vulnerabilità in un plug-in o in un tema, può significare che migliaia, se non centinaia di migliaia di siti Web sono aperti ad abusi.
Sfortunatamente, capita regolarmente che venga visualizzata una vulnerabilità in un prodotto noto, quindi vale la pena adottare alcune misure di sicurezza di base per proteggere il tuo codice per i tuoi utenti.
Che dire del team di revisione di WordPress.org?
Si potrebbe pensare che il team che esamina plugin e temi prima della pubblicazione nel repository ufficiale controlli tutti i tipi di problemi di sicurezza, ma il team è minuscolo ed è composto solo da poche persone. La coda di plugin e temi da controllare è in continua crescita, quindi il tempo che hanno per esaminarli è limitato.
Tuttavia, se trovano qualcosa, potrebbero chiudere automaticamente il tuo plug-in fino a quando non lo risolvi o inviarti un'e-mail di avviso che devi correggere una vulnerabilità prima di un certo periodo di tempo.
Il punto è che una volta che il tuo plugin o tema è elencato nel repository, puoi inviare gli aggiornamenti tramite il repository senza screening aggiuntivo, quindi una vulnerabilità può facilmente intrufolarsi in qualsiasi momento e passare inosservata per quasi ogni periodo di tempo.
Fondamentalmente, il rafforzamento delle misure di sicurezza dei plug-in dipende da te, quindi diamo un'occhiata ad alcuni modi in cui puoi proteggere il tuo prodotto WordPress ed evitare molti mal di testa e potenzialmente un impatto negativo sul tuo marchio.
Ecco cosa puoi fare per sviluppare in modo sicuro il tuo plugin o tema WordPress.
1. Pensa alla sicurezza da tutte le prospettive!
Non sai mai chi potrebbe utilizzare il tuo plugin o tema e quale livello di comprensione hanno sulla sicurezza, se non del tutto.
Non sai mai chi potrebbe utilizzare il tuo plugin o tema e quale livello di comprensione hanno sulla sicurezza, se non del tutto.Tweet
Amministratori, editori o utenti regolari sul sito Web di qualsiasi cliente potrebbero non utilizzare password sicure e i loro account potrebbero essere violati. Se il tuo prodotto non è protetto, questi account potrebbero essere utilizzati in modo improprio per ottenere un ulteriore accesso per installare codice dannoso sul sito Web del tuo cliente.
Non dovresti aspettarti che gli amministratori del server che hanno configurato il server su cui viene eseguito il sito Web sappiano abbastanza su come proteggere il tuo sito Web da altri siti sullo stesso server. Se il sito Web è ospitato da un grande provider, puoi aspettarti che il sito Web sia adeguatamente "separato", ma non sai dove verrà installato il tuo prodotto.
Suona paranoico? Forse. Ma, se e quando il tuo plugin o tema diventa super popolare, sarai felice di aver adottato un approccio paranoico alla sicurezza.
Se e quando il tuo plugin o tema diventerà super popolare, sarai felice di aver adottato un approccio paranoico alla sicurezza.Tweet
2. Prevenire gli attacchi XSS – Cross-Site Scripting
Questo sta diventando sempre più importante poiché WordPress sta diventando un progetto più guidato dal frontend con Gutenberg e ReactJS.
Uno degli errori più comuni per gli sviluppatori di WordPress è dimenticare di convalidare e disinfettare il proprio codice, lasciandolo aperto agli attacchi XSS. Esistono un paio di varianti di XSS, ma in generale si verifica un attacco XSS quando un hacker può iniettare codice nel server e quindi eseguirlo nel browser di un visitatore.
Immagina di avere un campo di input. Per semplicità, diciamo che è un campo di commento in cui utenti o visitatori possono inviare un commento a un post.
Un hacker tenterà di inviare un commento con "<script>alert('XSS');</script>" .
Ora, questo è solo un esempio di base che fa apparire un avviso sullo schermo dell'utente e nient'altro. Un vero hacker utilizzerà il campo dei commenti per iniettare il codice che carica il codice dal proprio sito che può rubare informazioni dal browser del visitatore e molto altro.
Possiamo impedire che ciò accada con la convalida, la sanificazione e la fuga.
La convalida consiste nel controllare i dati inviati prima di eseguire qualsiasi operazione, ad esempio archiviarli nel database. Ogni volta che i dati vengono inviati, puoi controllarli e assicurarti che siano accettabili. Se è un campo di quantità, ti aspetti un numero. Se non è un numero, è possibile restituire un messaggio di errore all'utente.
La sanificazione dei dati sta elaborando le informazioni inviate e assicurandosi che non contengano nulla che non vogliamo archiviare, come la rimozione di caratteri indesiderati. WordPress ha diverse funzioni integrate per aiutare con questo. Più sulla sanificazione tra un po'.
L'escape impedisce a qualsiasi codice dannoso di essere effettivamente eseguito nel browser. Diciamo che hai già un codice dannoso iniettato nel tuo sito web, o un altro plugin o tema permetta agli hacker di inserire codice nei dati che stai utilizzando: l'escape dei dati sullo schermo prima di mostrarli eviterà che diventi un problema.
Diamo un'occhiata allo stesso semplice esempio che abbiamo usato prima di "<script>alert('XSS');</script>"
Se non facciamo nulla con questo codice, il browser penserà che sia codice HTML. Il dettaglio importante qui sono i caratteri < > utilizzati per definire i tag HTML. Sfuggendo a questi, trasformiamo < in < e > in > Il browser ora comprende che questo non è un vero codice HTML e dovrebbe invece mostrare solo un segno minore di e maggiore di.
Convalidando, disinfettando ed evadendo tutti i dati che entrano ed escono dalla tua applicazione, proteggi i tuoi utenti da uno dei metodi di attacco più comuni.
3. Prestare attenzione alle iniezioni SQL
Come suggerisce il nome, un utente malintenzionato può utilizzare iniezioni SQL per fare in modo che il tuo sito Web elabori una query SQL ottimizzata e la utilizzi per ottenere l'accesso al tuo database.
A seconda dei dati che memorizzi sul tuo sito Web, la perdita di dati del tuo sito Web da un attacco SQL injection potrebbe passare dall'essere imbarazzante a devastare completamente la tua reputazione e il tuo business.
L'iniezione SQL è un vecchio modo per attaccare un sito Web, ma è ancora molto efficace e ci sono molte persone che cercano modi per utilizzare questa forma di attacco. Nell'ottobre 2020, il popolare plug-in Loginizer per WordPress ha annunciato di avere una vulnerabilità di SQL injection che ha lasciato a rischio oltre un milione di siti Web.
Nel 2019, hacker sconosciuti hanno rubato milioni di dati fiscali di bulgari tramite un attacco SQL injection e nel 2016 un gruppo di hacker russi ha estratto informazioni sugli elettori di circa 500.000 persone in Ohio. Questi tipi di attacchi sono ancora molto efficaci e puoi trovare molte informazioni su di essi.
Fonte: https://xkcd.com/327/
Il luogo più comune in cui si verifica un'iniezione SQL è in un campo del modulo che accetta l'input dell'utente, ad esempio un nome. L'attacco avviene inserendo parti di codice SQL nei campi di input, creando una query personalizzata che dà un risultato diverso da quello che ti aspetteresti.
Supponiamo che tu abbia un modulo che consente alle persone di cercare un nome particolare.
SELECT * FROM wp_postmeta WHERE meta_value = 'Henry' AND meta_key = 'celebrity_name';
Questo semplice esempio raccoglierebbe tutte le righe dalla meta tabella dei post con tutte le righe che hanno il nome Henry e una chiave specifica, celebrity_name : in questo modo, non restituiamo l'intero database e solo le righe particolari di cui abbiamo bisogno.
Un utente malintenzionato tenterà di analizzare un valore diverso, ad esempio 'Henry' OR 1=1--
La query ora restituirà tutte le righe con il nostro valore specifico o qualsiasi altra cosa, poiché OR 1=1 in SQL è sempre vero.
C'è di peggio, però. La nostra query SQL richiedeva solo risultati in cui la meta_key corrisponde al valore particolare che stiamo cercando, quindi non restituiremmo tutto. Questo dovrebbe limitare l'impatto dell'attacco SQL injection, giusto?
Beh, non è così. In SQL, il doppio trattino è un indicatore di commento, quindi tutto ciò che viene dopo viene commentato.
SELECT * FROM wp_postmeta WHERE meta_value = 'Henry' OR 1=1--' AND meta_key = 'celebrity_name';
Ciò significa che la query è simile a questa:
SELECT * FROM wp_postmeta WHERE meta_value = 'Henry' OR 1=1
La query ora restituisce essenzialmente tutto in quella tabella del database.
Questo era solo un semplice esempio. Esistono molti modi più complicati per accedere alla maggior parte, se non a tutte, le informazioni in un database. Un utente malintenzionato sarebbe in grado di provare attacchi SQL injection alla cieca, il che significa eseguire codice sul database, aggiungendo un nuovo amministratore, rimuovendo tutti i dati e così via.
La maggior parte degli attacchi sarebbe sotto forma di stringhe di query casuali contenenti parti di SQL inviate ai moduli del tuo sito web. Gli script automatici rileverebbero eventuali modifiche all'output del tuo sito Web e quindi rileverebbero il potenziale attacco.
Un modo semplice ed efficace è inviare un apostrofo ' come input e vedere se cambia qualcosa, si verifica un errore o vengono restituiti più risultati.
WordPress in soccorso
Invece di interagire direttamente con il database, qualsiasi sviluppatore dovrebbe utilizzare la classe di astrazione del database integrata in WordPress, $wpdb .
La classe $wpdb in WordPress ha tutte le funzionalità CRUD necessarie per interagire con il database in modo sicuro e puoi persino utilizzare la classe per interagire con le tue tabelle del database se il tuo plugin o tema lo richiede.
Puoi risolvere il problema anticipando che tipo di dati dovrebbe essere ragionevolmente inserito in ogni modulo di input. Nel nostro esempio precedente, abbiamo cercato un nome. Potremmo disinfettare l'input per assicurarci di accettare solo lettere. Se hai una casella di selezione o un gruppo radio che contiene solo poche opzioni, puoi controllare i dati per assicurarti che sia solo una delle scelte consentite.
La cosa più importante che puoi fare per risolvere il problema è preparare i tuoi dati con la $wpdb->prepare() .
Questa funzione accetta una stringa di query preparata e una matrice degli argomenti che si desidera aggiungere alla query SQL.
$meta_key = 'celebrity_name';
$meta_val = 'Henry'
$allhenrys = $wpdb->get_results(
$wpdb->prepare(
"SELECT * FROM $wpdb->postmeta WHERE meta_key = %s AND meta_value = %s",
$meta_key,
$meta_val
)
);
Tutto il lavoro si svolge all'interno della funzione prepare() . Il primo parametro, la query preparata, contiene il segnaposto %s invece dei valori effettivi. Questo è sostituito dalle altre variabili analizzate, $meta_key e $meta_val .
Nota: è importante non avere un apostrofo nella query che circonda i segnaposto, poiché la funzione li aggiungerà per te.
Questo è un esempio semplificato, ma lo stesso processo può essere utilizzato per qualsiasi query di database ed è possibile utilizzare %s per le stringhe, %d per i numeri interi e %f per i float.
Ci sono anche funzioni per situazioni specifiche, come l'aggiunta di una nuova riga al database. A questo scopo puoi usare $wpdb->insert() .
$wpdb->insert(
"{$wpdb->prefix}my_custom_table",
array(
'name' => 'Henry',
'userid' => 123,
'score' => 10,
),
array(
'%s',
'%d',
'%d',
)
);
L'uso della funzione di preparazione può aiutare a prevenire la maggior parte dei tentativi di iniezione SQL contro il prodotto.
Ricordati di controllare la documentazione di $wpdb. Alcune funzioni sfuggiranno all'input per te; altri si aspettano che tu esca dall'input prima di analizzare i dati nella funzione.
4. Usa i nonce per proteggere le tue richieste
L'uso del sistema nonce in WordPress può aiutarti a prevenire molti attacchi. Un nonce in termini di sicurezza è un numero utilizzato una sola volta. L'idea è di aggiungere questo numero univoco a tutte le richieste che fai dal tuo codice all'installazione di WordPress come un modo per verificare che questa richiesta sia legittima.
È un po' come avere una password segreta che devi dare al buttafuori per entrare in un club
Tuttavia, i nonce in WordPress sono leggermente diversi: non sono né un numero né il nonce viene utilizzato una sola volta.
Tecnicamente i nonce in WordPress possono contenere sia lettere minuscole che numeri, e invece di essere utilizzati una sola volta , vengono rigenerati dopo un periodo di tempo.
Il modo in cui usi un nonce è che il codice PHP che registra i tuoi file JavaScript genera una piccola combinazione univoca di numeri e lettere e li analizza insieme in modo che il tuo codice JS possa leggerlo.
Ogni volta che il codice JavaScript invia una richiesta al tuo sito Web, invia quel pezzo di codice e, se il codice non corrisponde, il tuo codice dovrebbe ignorare completamente la richiesta.
È sempre un po' più semplice con un esempio, quindi vediamo un modo semplice per caricare un file .js nel tuo plugin seguendo questi passaggi:
Utilizzo di nonces in un plugin per WordPress
add_action('wp_enqueue_scripts', 'load_my_plugin_script');
function load_my_plugin_script() {
// Register the script with all details and ensures it is loaded after jQuery
wp_register_script('secure-plugin', plugin_dir_url( __FILE__ ). 'js/secure-plugin.js', array( 'jquery' ) );
// Here happens the magic, we add some details to an object that we can later reference and read from in our JS code.
wp_localize_script(
'secure-plugin',
'plugin_ajax_object',
array(
'nonce' => wp_create_nonce('secure-plugin-nonce')
)
);
// Once that is done, we can now enqueue the script
wp_enqueue_script('secure-plugin');
}
In questa funzione, diciamo a WordPress di caricare un file JavaScript. Innanzitutto, registriamo il file che vogliamo caricare con wp_register_script() .
Quindi usiamo wp_localize_script() per analizzare un array di dati, in particolare "nonce" che contiene il nonce univoco che vogliamo usare nel nostro codice JS. Ricorda, puoi inviare anche tutti i tipi di altre informazioni in quell'array, ma in questo esempio lo stiamo semplificando.
Quando invii una richiesta dal tuo file JavaScript, devi includere quel nonce univoco. Farlo è facile:
Utilizzo di nonce dal plug-in di WordPress in un file JavaScript
jQuery(document).ready(function($) {
$.ajax({
url: ajaxurl, // WP variable, contains URL pointing to admin-ajax.php
type: 'POST',
data: {
'action': 'get_custom_data',
'_ajax_nonce': plugin_ajax_object.nonce,
'user_data': 'Some input from a user'
},
success: function( response ) {
// Here we do what happens if all is good - update the interface with a success message!?
},
error: function( response ) {
// Whooops, something went wrong!
// console.log(response);
}
});
});
Poiché abbiamo usato wp_localize_script() , possiamo usare la variabile plugin_ajax_object in JavaScript. Inviamo il nonce come variabile, _ajax_nonce .
Controlla e verifica un nonce in un plug-in WordPress dal codice JavaScript
add_action('wp_ajax_get_custom_data', 'get_custom_data');
function get_custom_data() {
// Ready for the magic to protect your code?
check_ajax_referer('secure-plugin-nonce');
/**
* That's it - the check_ajax_referer function verifies the nonce is correct or it dies and stops code execution if it fails.
*
* If you want to customize the error handling and perhaps return an error to your JS code, you could change the code to something like:
* if ( ! check_ajax_referer( 'secure-plugin-nonce', false, false ) ) {
* wp_send_json_error( 'Invalid nonce' );
* }
*/
$sanitized_user_data = sanitize_text_field( $_POST['user_data'] );
// ... continue with the rest of your plugin's function code ...
}
La magia si verifica con la funzione check_ajax_referer() che controlla il nonce e semplicemente fallisce e interrompe qualsiasi ulteriore esecuzione di codice se il nonce non corrisponde a quanto previsto.
È possibile personalizzare ulteriormente il codice per restituire all'utente informazioni specifiche sull'accaduto.
L'uso di nonces nel codice è un modo rapido, semplice ed efficace per prevenire molti tipi di tentativi di hacking. Ciò non significa che puoi saltare tutte le altre misure di sicurezza, ma aiuta a ridurre i problemi peggiori.
Ricordi cosa ho detto sul non fidarsi mai di nessuno? Questo ci porta a un altro modo per proteggere il tuo codice: la sanificazione.
Iscriviti e prendi una copia gratuita del nostro libro
11 tecniche comprovate per aumentare le controversie con la carta di credito Tasso di successo del 740%
Condividi con un amico
Inserisci l'indirizzo email del tuo amico. Gli invieremo solo questo libro via email, onore dello scout.
Grazie per aver condiviso
Fantastico: una copia di "11 tecniche comprovate per aumentare la percentuale di successo delle controversie con la carta di credito del 740%" è stata appena inviata a . Vuoi aiutarci a spargere la voce ancora di più? Vai avanti, condividi il libro con i tuoi amici e colleghi.
Grazie per esserti iscritto!
- abbiamo appena inviato la tua copia di "11 tecniche comprovate per aumentare la percentuale di successo delle controversie con la carta di credito del 740%" a .
Hai un errore di battitura nella tua email? clicca qui per modificare l'indirizzo email e inviare nuovamente.
5. Disinfetta l'input dell'utente
Nell'esempio precedente, abbiamo incluso un ulteriore pezzo di dati inviato da JS a PHP. Ogni volta che inserisci dati nel tuo codice dovresti aspettarti che non siano sicuri.
'user_data':'Some input from a user'
In questo esempio, è una semplice stringa, ma poiché stiamo inviando i dati a PHP, dobbiamo assicurarci che l'input non contenga alcun codice che potrebbe essere sfruttato nel nostro ambiente PHP o essere archiviato nel database consentendo ulteriori abusi.
Arriva la sanificazione. WordPress ha una gamma di funzioni che accetta qualsiasi input tu gli dai e pulisce i dati prima di restituirli a te.
In questo esempio, abbiamo utilizzato la funzione sanitize_text_field() , ma WordPress include molte funzioni di sanificazione adatte a diversi tipi di dati.
Ci sono molte altre fantastiche funzioni e metodi integrati in WordPress che puoi utilizzare per proteggere il tuo codice e prevenire abusi.
Non dovresti mai e poi mai utilizzare i dati inviati al tuo codice senza prima disinfettarlo. Dai un'occhiata a questo articolo sugli errori comuni degli sviluppatori di WordPress con maggiori dettagli sulla sanificazione e altri ottimi suggerimenti pratici.
E questo mi porta al suggerimento successivo, che la maggior parte degli sviluppatori di WordPress ha sperimentato:
6. Ricorda che is_admin() non è quello che pensi
Quando inizi a pensare per la prima volta a proteggere il tuo codice dal male, probabilmente ti imbatterai nella funzione is_admin() , e dal nome, sembra essere tutto ciò di cui hai bisogno, e tutto ciò che devi fare è avvolgere il tuo codice con quello, e tutto andrà bene.
No, sfortunatamente no. La funzione is_admin() rileva solo se il codice viene eseguito sul lato di amministrazione del sito web. Non fa nulla per rilevare se il tuo codice viene eseguito da un normale utente o amministratore.
Non te ne accorgerai mai se inserisci semplicemente il codice nel tuo plug-in perché molto probabilmente stai eseguendo il codice nell'interfaccia di amministrazione, e ciò significa che il codice valuterà semplicemente come true , e smetterai di pensarci e passerai a qualcosa altro.
Il modo corretto per verificare se un utente è un amministratore è verificare la capacità dell'utente:
if ( current_user_can( 'activate_plugins' ) ) {
// Do your code here
}
Esistono diverse funzionalità per diversi ruoli utente, quindi hai un controllo molto più granulare. Nella maggior parte dei casi, 'activate_plugins' è ciò di cui hai bisogno solo per gli amministratori.
Se vuoi un modo per consentire sia agli amministratori che agli editor di fare qualcosa, dovresti testare la funzionalità 'edit_pages' .
7. Aggiungi rel="noopener" o rel="noreferrer" ai tuoi link
Il collegamento a risorse esterne è abbastanza normale e il metodo della vecchia scuola per aggiungere target="_blank" a quei collegamenti ha senso perché non vuoi che i tuoi utenti lascino la tua pagina del plugin/tema.
Tuttavia, questo ti apre a quello che viene chiamato Tabnabbing. Questo è un problema di sicurezza in cui codice JavaScript dannoso può rubare informazioni ai tuoi utenti abusando della funzione JavaScript window.opener .
Prevenire ciò può essere semplice come aggiungere rel="noopener" ai tuoi link. La pagina a cui ti colleghi oggi potrebbe andare bene, ma potrebbe cambiare in futuro.
rel=noopener significa che la pagina a cui ti colleghi non può accedere alle informazioni o ottenere alcun controllo sulla tua pagina.
rel=noreferrer fa lo stesso e indica anche al browser di non trasmettere alcuna informazione di riferimento tramite l'intestazione Referrer. L'aggiunta rel="noreferrer" significa che la pagina a cui ti colleghi non sa da dove proviene il tuo visitatore.
Nota: queste due proprietà non devono essere confuse con rel=nofollow , che è correlato alla SEO.
8. Usa HTTPS e token di sicurezza con API di terze parti
Come sviluppatore, dovrai spesso integrare le API ed è fondamentale farlo in modo sicuro per proteggere i dati che stai inviando avanti e indietro.
Fortunatamente, ci sono già degli standard stabiliti su come farlo in sicurezza; uno di questi è HTTPS. L'utilizzo di HTTPS introduce un livello di sicurezza in cui tutti i dati trasmessi vengono crittografati.
Tuttavia, per garantire che i tuoi dati siano protetti da occhi spia, l'utilizzo di HTTPS non è sufficiente.
Come spiega questo articolo di Ars Technica, "HTTPS non significa che i tuoi dati siano al sicuro, significa solo che la tua connessione è sicura".
Token sicuri – JWT
Uno standard sicuro per gestire la comunicazione e le integrazioni API è l'utilizzo di JSON Web Tokens, JWT.
Un token sicuro viene creato effettuando una richiesta a un server che convalida i dettagli di accesso di un utente e genera un token, un piccolo pezzo di stringa che contiene dati, come nome utente, ID e così via.
Quando invii richieste successive al server, includi quel token nella richiesta. Questo token dimostra che sei autenticato e hai accesso. Se il token è valido e non è scaduto, il server utilizzerà i dettagli utente contenuti nel token e estrarrà i dati richiesti.
Il server può elaborare rapidamente le richieste in questo modo, rispetto all'utilizzo di una chiave API, che richiederebbe di cercare l'utente tramite quella chiave prima di decidere di elaborare i dati. Utilizzando un token, puoi includere i dati all'interno del token sull'utente e salvare più query del database.
Con il modo in cui un token sicuro viene generato e successivamente utilizzato, non è possibile creare token falsi o manipolare il contenuto di un token. È possibile creare un token valido solo conoscendo una chiave segreta, che l'azienda dietro la piattaforma terrà ben nascosta.
Una nota molto importante da ricordare è che i dati all'interno di un token non sono crittografati. È impossibile manomettere il contenuto del token senza invalidarlo, ma i dati all'interno di un token possono essere letti facilmente da chiunque, quindi non è un buon posto per archiviare dati sensibili.
Una buona risorsa se vuoi approfondire i token e come funzionano è l'Introduzione ai token Web JSON.
9. Non utilizzare librerie esterne da CDN
Anche se può essere allettante includere tutte le librerie di cui potresti aver bisogno tramite cdnjs.com o altri CDN globali gratuiti, ci sono alcune cadute.
Prima di tutto, non hai alcun controllo sulle librerie e su qualsiasi codice dannoso che si insinua nei file che includi.
Sebbene le CDN siano generalmente stabili e veloci per definizione, sono anche soggette a più attacchi. Se il tuo codice si basa su una libreria JS su una CDN sotto attacco, il tuo plug-in e il tema verranno caricati molto lentamente o non verranno caricati affatto.
Ciò è accaduto a un sito Web di un cliente in cui la CDN pubblica utilizzata da un plug-in in quel momento era scaduta per gli utenti in alcune regioni, rendendo l'interfaccia inutilizzabile. Alla fine, ho dovuto cambiare il plug-in per utilizzare una copia locale dello script JS invece come soluzione rapida.
Anche l'utilizzo di una fonte di terze parti esterna potrebbe compromettere la privacy. Sarà possibile per la CDN registrare tutti gli IP dei tuoi utenti: assicurati di controllare la politica GDPR e informa i tuoi clienti.
In generale, se utilizzi provider CDN di terze parti affidabili, non incontrerai alcun problema, ma l'approccio più semplice e affidabile consiste nel distribuire la libreria JS inclusa nel tuo prodotto.
Lo sapevate? WordPress viene fornito con diverse librerie JS incluse. Molte delle librerie JS più comuni che potresti voler utilizzare sono incluse in WordPress. Queste librerie copriranno la maggior parte delle tue esigenze di base.
Suggerimento per gli sviluppatori: carica i file JS e CSS aggiuntivi solo nelle pagine specifiche di cui hai bisogno. Come sviluppatore e utente, non mi piacciono molto i plugin che rallentano l'amministratore caricando file JS e CSS non necessari su ogni pagina. Non solo rallenta altre pagine di amministrazione, ma può anche rovinare il layout visivo e rendere quasi inutilizzabili alcune pagine di amministrazione. Per favore
Ci sono anche alcuni strumenti là fuori che possono aiutarti a proteggere il tuo codice e un ottimo strumento che puoi usare gratuitamente è Coderisk.
sta assumendo 
10. Usa strumenti e servizi per analizzare il tuo codice
Coderisk
Esistono molti servizi automatizzati per aiutare a identificare i problemi di codice. Exakat, SonarSource e PHPStan solo per citarne alcuni e uno dei miei preferiti - Coderisk.com - Un modo semplice per trovare alcuni degli errori di sicurezza più evidenti nel codice.
Questa azienda esegue la scansione di tutti i plugin di WordPress dal repository pubblico di WordPress.org. Il loro software è in grado di scansionare e identificare centinaia di diversi tipi di problemi di sicurezza in base a diversi standard di codifica.
Secondo le loro stesse statistiche, finora hanno scansionato oltre 4 miliardi di righe di codice pubblico e ci sono molti problemi anche con i migliori plugin.
Iscriversi al loro servizio gratuito è abbastanza semplice: puoi creare un account gratuito e quindi iniziare a richiedere i tuoi plug-in. Richiedere un plug-in è semplice come prendere una singola riga di codice che inserisci nel tuo readme.txt la prossima volta che distribuisci una nuova versione.
Ciò ti consente di accedere alla loro ultima scansione del tuo plug-in e all'interno hanno informazioni e dettagli specifici su ogni problema, con collegamenti direttamente al tuo codice.
Tieni presente che questo è un servizio gratuito, quindi potrebbero non aggiornare la scansione del tuo plug-in così spesso, ma una volta ricevuta una notifica, vale la pena controllare il tuo codice, poiché potresti aver introdotto un errore dall'ultima volta che hai recensito il tuo codice.
L'interfaccia è abbastanza facile da navigare una volta presa la mano, e il sistema è molto utile, fornendoti istruzioni molto facili da capire su cosa c'è che non va che ti aiuta a rintracciare l'errore.
Esistono anche molti modi per filtrare i bug e puoi contrassegnare ogni problema come risolto o molte altre opzioni per aiutarti a ottenere rapidamente una panoramica di tutti i problemi.
Nota: se non esegui mai Coderisk (o qualsiasi altro strumento nella sua categoria) sul tuo codice, non preoccuparti del numero di problemi sospetti di cui verrai avvisato. Questi strumenti possono generare una buona quantità di falsi positivi poiché analizzano solo il codice senza comprendere la logica aziendale. Usa l'output dello strumento come un solido elenco di partenza di elementi da rivedere.
PHP_CodeSniffer
Un altro ottimo strumento per controllare il codice è PHP_CodeSniffer. Il PHPCS è costituito da due script, PHPCS che controlla il tuo codice e segnala gli errori a te e PHPCBF che può risolvere automaticamente una vasta gamma di problemi identificati da PHPCS.
L'uso di PHPCS è molto facile da usare dalla riga di comando una volta installato. Questo strumento non impedirà la comparsa di problemi di sicurezza nel codice, ma è possibile eliminare semplici errori di codifica che rendono molto più difficile abusare di problemi più grandi.
È anche possibile integrare PHPCS direttamente nel tuo editor, come Sublime Text e Visual Code. In questo modo puoi facilmente vedere eventuali errori e correggerli rapidamente nel tuo IDE.
Non importa se lavori in un team o come un singolo sviluppatore, vale la pena utilizzare un sistema automatizzato in quanto è un modo semplice per eliminare i problemi di sicurezza di base che altrimenti potresti perdere.
L'utilizzo di un sistema automatizzato per scansionare il codice alla ricerca di problemi di sicurezza non è un metodo sicuro per catturare tutti i bug, ma può aiutarti a individuare gli errori più evidenti.
11. Non copiare e incollare il codice dal web senza un'adeguata revisione
Mantenere il tuo prodotto WP il più sicuro possibile dovrebbe essere un processo continuo, non solo una volta ogni tanto. Quando introduci nuove funzionalità o rimuovi codice, puoi anche introdurre nuovi problemi di sicurezza.
Google non è sempre tuo amico. Come sviluppatore, sei abituato a controllare il grande Internet alla ricerca di esempi di codice che ti ispirino o semplicemente riscrivere frammenti qua e là se sei pigro.
La maggior parte dei pezzi di codice che trovi su Internet sono raramente pronti per l'uso in un ambiente di produzione sicuro e sono intesi come un esempio di qualsiasi problema di codifica che stai cercando di risolvere. L'uso di queste parti di codice alla cieca e senza revisione può introdurre problemi molto rapidamente.
C'è molto da fare come sviluppatore di WordPress e risolvere un problema di sicurezza urgente nel tuo plug-in con migliaia di installazioni non dovrebbe essere uno di questi.
Tieni presente che è in gioco la tua reputazione
Se non presti attenzione alla sicurezza del tuo plugin o tema, stai mettendo in gioco i tuoi utenti, le loro attività, la tua attività e la tua reputazione. Questo è un sacco di tempo e denaro potenzialmente sprecati!
Le vulnerabilità della sicurezza possono avere un impatto enorme sulla fiducia che i clienti ripongono nel tuo marchio o nei tuoi prodotti. L'esempio di Loginizer sopra mostra che anche le vulnerabilità di sicurezza più imbarazzanti possono capitare agli stessi sviluppatori di plugin di sicurezza! E gli altri esempi di frode elettorale e hack del governo ci dicono che chiunque è vulnerabile.
Se e quando scopri una vulnerabilità, agisci rapidamente per risolverla e segui le migliori pratiche per annunciare pubblicamente il problema (se necessario) e rilasciare una correzione.
Se rimani all'avanguardia quando si tratta di comunicazione e problemi di "relazioni pubbliche" che potrebbero derivare da una vulnerabilità, puoi evitare alcuni enormi mal di testa e aumentare la tua reputazione invece di danneggiarla.
Grazie per aver letto!
Può essere scoraggiante esaminare tutte le cose che devi fare quando non sai cosa cercare per cominciare e può essere difficile trovare le informazioni giuste. Se non hai la più pallida idea da dove cominciare, dovresti considerare di far recensire il tuo prodotto da un esperto di sicurezza di WP (anche io eseguo revisioni di sicurezza).
Si è tentati di risparmiare denaro o tempo per una revisione della sicurezza, ma il costo di non proteggere il più possibile il prodotto può essere ancora più alto a lungo termine.
Questi sono solo alcuni dei modi in cui puoi e dovresti proteggere il tuo prodotto WordPress da abusi. Se hai qualche dubbio, ricorda solo: non fidarti di nessuno