Nella directory principale di ogni sito WordPress c’\u00e8 un file xmlrpc.php che in realt\u00e0 esiste da prima di WordPress stesso. Prima di WordPress, al tempo di b2 (se qualcuno lo conosce), questo file \u00e8 stato creato per dare ai siti un modo per comunicare tra loro e per consentire ad altre applicazioni di comunicare con il blog stesso.<\/p>\n\n\n\n
Il nome ti dice tutto ci\u00f2 che devi sapere sulla sua funzionalit\u00e0.<\/p>\n\n\n\n
XML<\/strong> – \u00e8 stato progettato per accettare payload in XML. In questi giorni JSON \u00e8 un formato molto pi\u00f9 comune, ma XMLRPC precede JSON di un bel po’.<\/p>\n\n\n\n RPC<\/strong> \u2013 sta per Remote Procedure Call. Era uno standard in base al quale un sistema poteva chiedere a un altro sistema di fare qualcosa. In questi giorni usiamo le API (REST o Graph API) per fare la stessa cosa ma, prima che esistessero, RPC era uno dei modi per eseguire queste procedure.<\/p>\n\n\n\n Per fare in modo che XMLRPC.php faccia qualcosa, devi fare una richiesta POST. Se non conosci il funzionamento dei browser, questo passaggio \u00e8 fondamentalmente come cliccare sul pulsante Invia in un modulo, che solitamente avvia proprio una richiesta POST.<\/p>\n\n\n\n Se fai una richiesta POST a tuodominio.tld\/xmlrpc.php e gli dai un payload XML correttamente formattato, puoi fare cose come creare un post sul tuo sito.<\/p>\n\n\n\n Una delle cose per cui XMLRPC veniva usato molto in passato erano i “pingback”. Quei commenti che vedi sui post che mostrano che qualcun altro si lo ha linkato sul proprio blog.<\/p>\n\n\n\n Per molto tempo XMLRPC \u00e8 stato uno strumento utile. Oggi non \u00e8 pi\u00f9 cos\u00ec. Al giorno d’oggi tutte le funzionalit\u00e0 per cui veniva utilizzato XMLRPC sono gestite dalle API REST integrate. Tuttavia, anche se non \u00e8 pi\u00f9 utilizzato \u00e8 ancora in giro. Chi ha nostalgia di queste cose lo vede e sorride, ma chi \u00e8 attento alla sicurezza lo teme.<\/p>\n\n\n\n XMLRPC pone un paio di rischi per la sicurezza dei siti WordPress che possono provocare gravi attacchi XMLRPC.<\/p>\n\n\n\n Il primo tipo di attacco XMLRPC \u00e8 un semplice Brute-Force. Poich\u00e9 parte del payload XML che viene passato a WordPress contiene il login e la password dell’utente che vuole intraprendere l’azione, \u00e8 facile che gli hacker provino diverse combinazioni per individuare le credenziali. Molti proprietari di siti limitano il numero di tentativi di login che un utente pu\u00f2 effettuare prima di essere bloccato, ma non si preoccuperanno di bloccare le richieste XMLRPC, lasciando cos\u00ec una backdoor aperta agli hacker per cercare di trovare un modo per entrare.<\/p>\n\n\n\n Una volta che un hacker trova le credenziali corrette, \u00e8 libero di compromettere il tuo sito inserendo contenuti nel database del tuo sito. Che si tratti di post, pagine o solo commenti, il risultato finale \u00e8 lo stesso. Il contenuto che non hai approvato e che molto probabilmente non desideri viene pubblicato sul tuo sito.<\/p>\n\n\n\n Nella migliore delle ipotesi, questo significa commenti e post di spam. Nel peggiore dei casi, potrebbero essere post o commenti all’apparenza normali ma nei quali a cui \u00e8 stato inserito un malware.<\/p>\n\n\n\n Poich\u00e9 uno dei modi in cui veniva utilizzato XMLRPC era il pingback, gli hacker possono usarlo per sopraffare il tuo server emettendo molte richieste tutte in una volta.<\/p>\n\n\n\n Un pingback scrive un record nel tuo database. Scrivere nel database \u00e8 un’attivit\u00e0 costosa, in termini di risorse. Mentre un singolo pingback non danneggia le prestazioni del tuo sito, centinaia o addirittura migliaia di essi contemporaneamente possono mettere in ginocchio anche il server pi\u00f9 robusto.<\/p>\n\n\n\n Questo \u00e8 chiamato attacco DDos o Distributed Denial of Service. “Distribuito” perch\u00e9 di solito non \u00e8 una singola macchina a fare tutte le richieste, di solito \u00e8 un intero gruppo di macchine sparse ovunque.<\/p>\n\n\n\n [subscribe_cta]<\/p>\n\n\n\n Ci sono alcuni modi per disabilitare XMLRPC. Consiglio vivamente di farlo perch\u00e9 onestamente non ne hai bisogno.<\/p>\n\n\n\n Se hai familiarit\u00e0 nel bloccare le richieste tramite i file di configurazione del tuo webserver e se hai accesso a questi file, \u00e8 il miglior modo per disabilitare XMLRPC. Per Apache, puoi aggiungere questo codice al file .htaccess nella directory principale del tuo sito.<\/p>\n\n\n\n <Files xmlrpc.php><\/p>\n\n\n\n order deny,allow<\/p>\n\n\n\n deny from all<\/p>\n\n\n\n <\/Files><\/p>\n\n\n\n Questo lo bloccher\u00e0 subito.<\/p>\n\n\n\n Se non hai familiarit\u00e0 con i file di configurazione del tuo webserver, puoi aggiungere una singola riga di codice al file functions.php del tuo tema.<\/p>\n\n\n\n add_filter( \u2018xmlrpc_enabled\u2019, \u2018__return_false\u2019 );<\/p>\n\n\n\n Assicurati di farlo correttamente, ci sono 2 underscore prima della parola “return”. Questo dir\u00e0 a WordPress che non vuoi accettare richieste XMLRPC.<\/p>\n\n\n\n Infine, se non vuoi preoccuparti di aggiungere codice al functions.php del tuo tema, puoi disabilitare XMLRPC in WordPress installando un plugin. (nota: il plug fa esattamente la stessa cosa del suggerimento precedente). Ci sono diversi buoni plugin gratuiti che lo fanno e potresti gi\u00e0 avere questa funzionalit\u00e0 se hai installato un plugin di Application Firewall.<\/p>\n\n\n\n<\/span>Come funziona XMLRPC?<\/span><\/h2>\n\n\n\n
<\/span>Potenziali minacce alla sicurezza provenienti da XMLRPC di WordPress<\/span><\/h2>\n\n\n\n
Attacchi di brute-force tramite XMLRPC<\/h4>\n\n\n\n
Attacchi DDoS tramite XMLRPC<\/h4>\n\n\n\n
<\/span>Come disabilitare XMLRPC in WordPress<\/span><\/h2>\n\n\n\n
File di configurazione del tuo webserver<\/h4>\n\n\n\n
File functions.php del tuo tema<\/h4>\n\n\n\n
Installa un plugin<\/h4>\n\n\n\n