WordPress ha rilasciato una lista di vulnerabilità ad alto rischio scoperte dal team di sviluppo principale.
WordPress ha risolto quattro vulnerabilità che sono state valutate come un 8 su una scala da uno a dieci. I problemi esistono nel core di WordPress e sono stati introdotti dal team di sviluppo di WordPress.
Quattro vulnerabilità L’annuncio di WordPress
Il rilascio di WordPress era a corto di dati sulla gravità delle vulnerabilità, e i dettagli che sono stati forniti erano scarsi.
Tuttavia, il National Vulnerability Database del governo degli Stati Uniti, che registra e pubblicizza le vulnerabilità, ha classificato le vulnerabilità fino a 8.0 su una scala da uno a dieci, con dieci che indica il massimo livello di minaccia.
Le quattro debolezze sono le seguenti:
- A causa di una mancanza di sanificazione dei dati in WP Meta Query, si verifica l’iniezione SQL (livello di gravità valutato alto, 7.4)
- Iniezione di oggetti multisito autenticata (livello di gravità valutato medio 6.6)
- Gli utenti autenticati sono vulnerabili al Cross Site Scripting (XSS) memorizzato (livello di gravità valutato alto, 8.0)
- A causa della scarsa sanitizzazione, si verifica l’SQL Injection via WP Query (livello di gravità valutato alto, 8.0)
Gli esperti di sicurezza hanno identificato tre delle quattro vulnerabilità al di fuori di WordPress. WordPress era completamente all’oscuro della situazione fino a quando non sono stati contattati.
Le vulnerabilità sono state fornite a WordPress in modo segreto, permettendo all’azienda di affrontare i problemi prima che diventassero generalmente noti.
Lo sviluppo di WordPress viene affrettato in modo rischioso?
Poiché non sono stati in grado di concludere il lavoro sulla versione più recente, la 5.9, lo sviluppo di WordPress si è bloccato nel 2021, e quella versione di WordPress è stata rimandata alla fine del 2022.
C’è stata una discussione all’interno di WordPress sul rallentamento dello sviluppo a causa delle preoccupazioni sulla capacità di tenere il passo.Alla fine del 2021, gli stessi sviluppatori del core di WordPress hanno evidenziato le preoccupazioni per la velocità di sviluppo, chiedendo più tempo.
Uno degli sviluppatori ha lanciato un avvertimento al riguardo:
“Nel complesso, mi sembra che in questo momento stiamo affrettando le cose in modo pericoloso”.
Dato che WordPress non può rispettare il suo programma di rilascio e sta discutendo di ridimensionare il suo calendario di rilascio del 2022 da quattro versioni a tre, si deve mettere in discussione il ritmo di sviluppo di WordPress e se si dovrebbe fare più sforzo per assicurare che le vulnerabilità non siano inavvertitamente rilasciate al pubblico.
Dato che WordPress non è in grado di rispettare il suo programma di rilascio e sta considerando di ridimensionare il suo calendario di rilascio per il 2022 da quattro a tre versioni, è necessario discutere il ritmo di sviluppo di WordPress e se è necessario un maggiore sforzo per garantire che le vulnerabilità non siano inavvertitamente divulgate al pubblico.
Difficoltà di sanificazione dei dati in WordPress
La sanificazione dei dati è un metodo per determinare quale tipo di dati viene inviato attraverso l’input e memorizzato nel database. Il database è la raccolta di informazioni sul sito, tra cui password, nomi utente, informazioni sugli utenti, contenuti e altre informazioni necessarie per il funzionamento del sito.
La documentazione di WordPress ha descritto la sanificazione dei dati:
“Il processo di sanificazione o screening dei dati in ingresso è noto come sanificazione. Quando non si sa cosa prevedere o non si vuole essere troppo severi con la convalida dei dati, si impiega la sanificazione, sia che i dati provengano da un utente, un’API o un servizio web”.
Secondo la documentazione, WordPress ha dei metodi di assistenza integrati per difendersi dagli input malevoli, e che l’utilizzo di queste funzioni di aiuto è semplice.
WordPress prevede sedici diversi tipi di vulnerabilità di input e offre strategie per mitigarle.Di conseguenza, è notevole che i problemi di sanitizzazione dell’input persistano nel codice di base di WordPress.
C’erano un paio di vulnerabilità di alto livello legate alla sanificazione scorretta:
- Iniezione SQL in WordPress a causa di un’errata sanificazione in WP Meta Query
C’è il rischio di una cieca SQL Injection in WP Meta Query a causa di una mancanza di sanificazione adeguata. - Iniezione SQL attraverso WP Query in WordPress
A causa di una mancanza di sanitizzazione in WP Query, l’iniezione SQL può essere possibile attraverso plugin o temi che lo utilizzano in un certo modo. - L’iniezione SQL è uno degli hack più devastanti che possono avere un impatto sul tuo sito aziendale e portare alla perdita di informazioni sensibili dal tuo database all’hacker. Avete le seguenti domande in mente, allora questo articolo è un must da leggere per voi.
Le altre vulnerabilità sono:
- Iniezione autenticata di oggetti in WordPress Multisites
Gli utenti con la posizione Super Admin su un multisito possono utilizzare l’iniezione di oggetti per aggirare l’hardening esplicito/aggiuntivo in determinati scenari. - XSS è stato memorizzato in WordPress da utenti autorizzati.
Nel core di WordPress, gli utenti autorizzati con bassi privilegi (come l’autore) possono eseguire JavaScript/eseguire un attacco XSS memorizzato, che può colpire gli utenti con alti privilegi.
Come identificare l’attacco SQL Injection
Ci sono vari modi per effettuare un attacco SQL injection, ma in questo post, vi mostreremo le tecniche più semplici per identificarne uno. Diciamo che abbiamo un modulo di login standard che chiede un indirizzo email e una password per confermare l’utente e garantirgli l’accesso a servizi online aggiuntivi.
Se volessimo iniettare del codice SQL, potremmo riempire il primo campo con un indirizzo email, come XYZ@myemail.com, e il secondo campo, che richiede una password, con il seguente valore: ‘Per esempio, 1 = 1′
Se eseguiamo una query SQL per vedere se quell’utente esiste, otteniamo quanto segue:
SELECT * FROM users WHERE email = 'XYZ@myemail.com' and password = ' ' or 1 = 1 -
Nella query precedente, abbiamo indicato in grassetto l’iniezione SQL che abbiamo appena elaborato. Questa iniezione disattiverebbe l’istruzione aggiungendo un operatore logico o più un confronto di uguaglianza che è vero 1 = 1.
Questo paragone disattiverebbe il resto della query a sinistra e fornirebbe un’operazione logica vera che, come risultato, ci porterebbe i valori del database, dando accesso finale all’applicazione.
WordPress raccomanda di aggiornare il sito immediatamente
Poiché le vulnerabilità sono ora allo scoperto, è importante che gli utenti di WordPress si siano assicurati che la loro installazione di WordPress sia aggiornata all’ultima versione, attualmente 5.8.3
