IL CMS HA MOLTO SUCCESSO ANCHE PER LA MAREA DI PLUG-IN CHE NE ESTENDONO LE FUNZIONALITÀ. MA UN BUG POTREBBE PERMETIE Al PIRATA L’ESECUZIONE DI UNA SQL INJECTION
Negli ultimi anni, l’e-commerce ha aumentato la propria diffusione in modo esponenziale. Soprattutto perché ormai non si vende più soltanto su Amazon, eBay o altre grosse piattaforme: chiunque può aprire un proprio sito Web e vendere ciò che desidera. Una buona parte del merito va ai CMS destinati alla costruzione di siti di e-commerce. I Content Management System sono applicazioni Web, solitamente scritte in PHP o ASP, che permettono anche ad un persona non esperta di programmazione la costruzione di un sito utilizzando una serie di schemi già pronti all’uso. I CMS per l’e-commerce esistono da molto tempo, ma solo recentemente sono diventati più semplici. Non soltanto: anche i normali CMS, quelli utilizzati per realizzare blog, hanno prodotto dei plug-in che permettono la vendita di prodotti o servizi. t il caso di WordPress, il CMS più diffuso: si calcola che WordPress sia utilizzato nel 20% di tutti i siti Web esistenti.
Tuttavia, dobbiamo ricordare che quasi il 70% dei siti non è costruito con un CMS (molti siti governativi, ad esempio, hanno piattaforme statiche).
Ciò significa che WordPress è il motore di due terzi di siti Web basati su CMS. Esistono diversi plug-in di WordPress che permettono di realizzare un sito di e-commerce ed uno dei più diffusi fino a qualche tempo fa era Product Catalog 8. Al momento, questo plug-in è stato sospeso perché lo sviluppatore non ha più il tempo di aggiornarlo e questo le rende un facile bersaglio per i pirati. Secondo le statistiche di WordPress, infatti, la maggior parte degli utenti non è particolarmente solerte nell’aggiornare il proprio CMS ed i relativi plugin.
Il risultato è che diversi siti rischiano di essere vulnerabili ai vari bug di questo plug-in.
UN’INIEZIONE SQL
C’è un bug che risalta fra tutti per la sua pericolosità, perché offre la possibilità di una SOL lnjection. Ma forse dobbiamo fare qualche passo indietro. WordPress è un’applicazione PHP basata su database SOL. Di solito si utilizza un server MySQL oppure PostgreSQL, ma si può anche ricorrere ad un file SQLite.
Ad ogni modo, è poco rilevante, perché in ciascun caso il risultato è che tutte le informazioni del sito Web vengono memorizzate nel database. Questo include i testi, la struttura delle pagine, l’interfaccia, e persino le immagini ed i file allegati (il loro URL). Ma, soprattutto, i dati sugli utenti, i commenti e le password di accesso, inclusa quelle di amministrazione.
Ciò significa che è sicuramente molto importante proteggere questo database ed impedire che qualche malintenzionato possa accedervi in lettura e, soprattutto, in scrittura. Perché potendo scrivere nel database un malintenzionato potrebbe, ad esempio, cancellare delle tabelle oppure anche modificare la password di un amministratore per accedere al sito per modificarlo a proprio piacimento. I database SOL sono molto comodi per i programmatori perché si basano su delle
query, owero dei comandi. Per fare qualche esempio, esiste un comando per leggere le tabelle, uno per crearle ed uno per distruggerle. Basta inviare tali comandi tramite PHP e si può manipolare il database. Siccome i comandi sono di fatto delle stringhe di testo, sono molto comode da realizzare e da adattare alle varie esigenze. li problema nasce quando un comando deve essere realizzato utilizzando delle informazioni fornite dall’utente.
Ad esempio, il comando “DROP TABLE gianni” prowede a cancellare la tabella chiamata “gianni”. Si può decidere di inserire in una pagina HTML una casella ditesto tramite la quale l’utente possa indicare il nome della tabella da eliminare. Poi PHP non deve far altro che concatenare “DROPTABLE “con il valore della casella di testo ed il gioco è fatto. li problema è che in questo modo se l’utente commette un errore, il comando può essere snaturato. Addirittura, se l’utente è malintenzionato, può scrivere nella casella di testo un codice che sostituisce il comando con un altro, in modo da “iniettare” nel server SOL un comando malevolo al posto di quello previsto originariamente. Per evitare che questo accada, si deve controllare ogni contributo dell’utente, per assicurarsi che non contenga caratteri speciali che possano modificare la query.
[amazon_link asins=’B019MSWC9W,B06XHGK94Y,B015DLBVJ4,B073STP8PC,B01J1LBQH4,B01MR6WKBB,B01CSFV3H8′ template=’ProductCarousel’ store=’giugio-21′ marketplace=’IT’ link_id=’05cc04ca-8968-11e7-84ba-ad798258bce3′]
IL CODICE
Questo controllo, però, non awiene nel codice del plug-in Product Catalog: quest’estensione è realizzata con una serie di file PHP. Tra questi, c’è il file includes/ajax-functions.php, che contiene una serie di funzioni. In particolare, si nota la funzione UpdateCategorylist, che può essere chiamata
fornendo alla pagina wp-admin/admin-ajax.php il suo nome nel campo action fornito tramite HTIP POST
è quindi sufficiente creare un semplice forma HTML contente questo codice:
<Input type=”text” name=”action” value=”UpdateCategorylist”>.
Il codice di questa funzione è il seguente:
function UpdateCategoryList() {
global $wpdb, $subcategories_ table;
global $wpdb;
$table = $subcategories_table;
$catld = $_POST[‘selectedCategory’];
lf($catid !==’O’) {
$get_ltems = $wpdb·>get_results( • SELECT *
FROM $table WHERE subcategor y_category =
, $catid ORDER BY subcategory_name ASC” );
echo json_encode( $get_ltems);
}
Si può immediatamente notare che la funzione riceve tramite HTIP POST un testo chiamato selectedCategory, che viene subito inserito nella variabile $catid. Il problema è che poi tale variabile viene Inserita direttamente nella query SQL, owero quel testo che inizia con il comando SELECT. Siccome non c’è alcun controllo sul contenuto della variabile $catid e non viene appliata alcuna funzione di escape per eliminare potenziali caratteri pericolosi. Ciò siginifica che un utente malintenzionato può facilmente sfruttare l’occasione per far eseguire a PHP una quesry a propria discrezione. In poche parole, ad un pirata è sufficiente scrivere questo codice:
else {
$get_items = “”;
echo json_encode($get_items);
}
cle();
}
per produrre un form tramite il quale inviare una query arbitraria.
Il pirata può quindi modificare parti sensibili del database, inclusi gli hash delle password degli utenti amministratori.
CORRERE AI RIPARI
Se questo plug-in è presente sulla nostra installazione di WordPress, la soluzione migliore consiste nel disabilitarlo e passare ad un altro plug-in simile ma costantemente aggiornato.
Questo caso ci insegna quanto sia importante mantenere aggiornato il nostro CMS, perché essere presi di mira dai pirati è dawero molto facile se si utilizzano applicazioni contenenti bug. Se siamo dei programmatori, invece, possiamo evitare le SQL lnjection in due modi. Il primo, e più semplice, consiste nel rìcorrere ad una funzione di escape, che rimuova tutti i simboli speciali che potrebbero modificare la natura della query che abbiamo scritto:
<form- method=”post” action=”http://www.sltoweb.com/wp·admin/admln-ajax.php”>
<Input type=”text”
name=”selectedCategory” value=”O UNION SELECT
1,2,3,4,5,6 FROM wp_terms WHERE term_id=l”>
<input type=”text” name=”actlon”
value=”UpdateCategoryLlst”>
<input type=”submit” value=”Send”>
</form>
La funzione di escape fornita da PHP si chiama mysql_real_escape_strlng, ed è valida nella maggioranza del casi. !.:alternativa, è rappresentata dall’uso delle funzioni MYSQL invece
della comuni MYSQL In particolare, le query possono essere “preparate” con una funzione chiamata, per l’appunto my-sql.prepare.