Come limitare lo SPAM su Magento 1

PREMESSA

Il problema di cui andremo a parlare oggi non riguarda solo Magento, la piattaforma di Ecommerce più diffusa nel mondo. E’ un problema che riguarda tutti i siti web con un FORM che permetta di interagire con il database sottostante, quindi SI, anche il form di Login per l’accesso all’area riservata.

Ma partiamo dall’inizio

Messaggio WhatsApp del cliente: “Ciao Gianluca, i clienti che ordinano sul sito non ricevono la conferma d’ordine per email” (si, l’ho presa parecchio larga, ma tant’è … nel mio lavoro capita piuttosto spesso che le cause di un problema sembrino slegate dai sintomi)

C’è da fare una doverosa premessa: questo cliente è un amico a cui ho installato e configurato Magento qualche anno fa e che gestisce in totale autonomia il sito, senza pagare alcun canone di assistenza, ma pagando soltanto l’hosting della piattaforma sui miei server e gli interventi di manutenzione straordinaria.

Seconda premessa: il suo sito di Ecommerce utilizza server SMTP ospitati da Zoho, che NON gestisco io … ma ho le sue credenziali perchè, da amico tecnico (e qui molti si riconosceranno) capita di dover risolvere dei problemi anche non direttamente inerenti i servizi che vengono offerti.

Qualcuno si chiederà:

ma perchè non offri ai tuoi clienti, facendolo pagare, anche il servizio di SMTP?

Perchè ognuno deve fare il suo lavoro: improvvisarsi sistemisti di server SMTP per far partire le email dai siti ospitati sui propri server può portare a conseguenze poco piacevoli. Le istanze EC2 di AWS non sono pensate per inviare email (si può fare, ma le procedure fanno perdere un sacco di tempo appresso a form e richieste ad Amazon per eliminare le limitazioni sull’invio delle email oltre che per gestire il reverse DNS), anche perchè Amazon ha il proprio servizio di invio che si chiama SES ed ha tutto l’interesse a fartelo usare…

Quindi?

Quindi esistono innumerevoli aziende che offrono il servizio di SMTP, gratuito o a pagamento. Preferisco che i clienti paghino qualcun altro per avere un servizio offerto da specialisti (spesso i piani gratuiti sono sufficienti) e poi configuro le applicazioni e i siti per poter utilizzare gli SMTP esterni. Magari farò un articolo a proposito in futuro….

CACCIA AL COLPEVOLE

Esistono due modi per cercare un bug in un sistema:

Approccio Brute Force: si va a mettere mani più o meno a caso qua e la e prima o poi (forse) ci si imbatterà nell’anomalia da correggere
Approccio di Dottor House: dopo anni di esperienza i sintomi ti portano come le briciole di pollicino alla diagnosi, che non sempre è la prima che ti viene in mente

L’esperienza degli sviluppatori si può pesare osservando il modo in cui cercano il bug a partire dal sintomo.

Qual’è il sintomo in questo caso?

I clienti NON ricevono per email la conferma dell’ordine

Per prima cosa, quando un cliente mi dice che c’è un problema VERIFICO che effettivamente quel problema esista: effettuo un ordine di test, la mail non arriva. Il problema ESISTE. Importante: il problema NON ESISTEVA, quindi non è un problema di cattiva configurazione iniziale.

Vediamo COME una mail generata da Magento arriva nella casella del cliente, in modo da capire dove può essersi annidato il problema.

MAGENTO =>SMTP del Cliente => Server vari => Server POP/IMAP utente => Client di posta utente =>

Ognuno degli STEP di questa catena, comprese le frecce che li collegano, possono essere la fonte del problema ma noi possiamo agire, in questo caso solo sui primi 2.

L’esperienza in questo caso mi fa risparmiare tempo e mi conduce subito al responsabile: Zoho SMTP. Il servizio prevede un piano gratuito con dei limiti piuttosto stretti inerenti il numero di email inviabili in un giorno (comunque sufficienti ad un sito ecommerce di medie dimensioni) e dei limiti ancora più stretti sul numero di email inviate in breve tempo (l’invio di una newsletter farebbe scattare un blocco immediato del servizio). Accedo al pannello di Zoho Mail e … BINGO: il servizio è sospeso per superamento dei limiti. Richiedo lo sblocco che avviene poco dopo e, PROBLEMA RISOLTO. … o forse NO

Perchè il server SMTP ci ha bloccati

Chiedo al cliente se per caso non abbiano inviato una Newsletter attraverso il sito. Mi risponde di no, ma…

Abbiamo solo attivato la possibilità di registrarsi alla newsletter.

Al dottor House comincia ad accendersi una lampadina…. accedo all’area riservata di Magento per testare che effettivamente adesso le email non abbiano problemi.

Sistema > Configurazione > ASCHRODER EXTENSIONS > Smtp Pro, il Plugin che uso per poter configurare i server utilizzati dal framework per l’invio delle mail, ha una utile funzione RUN SELF TEST sotto il pannello Logging and Debugging

Il risultato del test viene salvato nei Log che è possibile consultare da Sistema > Strumenti > SmtpPro – Email Log

E’ in questa schermata che ho capito quale fosse stato il problema:

… il test ha avuto successo (il server SMTP è stato effettivamente sbloccato), ma …

Chi è tutta questa gente che si è iscritta alla newsletter del sito (con email evidentemente NON italiane per un sito che al momento è solo in italiano)?

Verifico subito una configurazione: Sistema > Configurazione > Clienti > Newsletter

Questa configurazione consente l’iscrizione a chiunque, anche senza aver fatto alcuna registrazione, ma possibile che 800 persone si siano iscritte in un giorno solo perché il sito lo consente? No.

Lo SPAM

Quello che abbiamo appena scoperto è che qualcuno si diverte ad inserire email a caso nel nostro database degli utenti interessati alla nostra Newsletter, il sistema invia per ogni mail inserita, la conferma al proprietario della stessa email, e il server SMTP si arrabbia e ci impedisce di inviare altre email bloccando temporaneamente il nostro account ed impedendo al nostro Ecommerce di funzionare come dovrebbe.

In realtà quel “qualcuno” NON è umano (nel 99% dei casi): si tratta di BOT, software che scandagliano la rete alla ricerca di siti che presentino questo tipo di vulnerabilità. Non riguarda solo il form di iscrizione alla newsletter: riguarda tutti i form pensati per interagire con esseri umani. A qualcuno potrebbe sorgere la domanda

Perchè lo fanno? Cosa ci guadagnano?.

Le risposte sono molteplici come molteplici sono le vulnerabilità che possono essere rilevate. In questo caso l’utente riceve un generico “Benvenuto nella newsletter di XYZshop“. Avendo a disposizione 10.000 siti vulnerabili, si potrebbe utilizzarli a scopo malevolo per intasare la casella di posta elettronica di una vittima con email difficilmente filtrabili a monte perchè provenienti da tanti siti legittimi diversi. Ma pensiamo ad esempio ad i Form Contatti: spesso quando facciamo una richiesta su uno di questi form ad un sito, riceviamo per email una copia della nostra richiesta. Quindi se un form di questo tipo è vulnerabile, io potrei mandare una email pubblicitaria (SPAM) GRATUITAMENTE (perché uso server e risorse del sito bersaglio) a pincopallo@email.it semplicemente scrivendo un messaggio pubblicitario in uno di questi form, come se fosse una richiesta proveniente proprio da pincopallo@email.it. Se Pinco Pallo si arrabbia e segnala l’email per SPAM, sarà il server SMTP usato dal sito ad essere segnalato e penalizzato e non i server dello spammer.

Tutto chiaro?

La soluzione

Una delle soluzioni più diffusa per evitare questo tipo di problemi si chiama CAPTCHA. Sicuramente vi sarete imbattuti in qualche form contatti o form di iscrizione che al termine della procedura, prima di farvi inviare i dati di un form, vi richiedono di inserire una serie di caratteri riportati in un’immagine difficilmente leggibile. Magari vi sarete chiesti il perché di questa astrusità. Ora lo avete scoperto: quella serie di caratteri è decifrabile con poca difficoltà da un essere umano, ma è molto difficile che riesca ad essere decifrata da un BOT, un software di poche righe che non ha tempo da perdere con tecniche di interpretazione delle immagini che necessita di risorse (attraverso ad esempio il Machine Learning e l’intelligenza artificiale) quando fa prima a cercare altri form vulnerabili sparsi in miliardi di siti internet.

Google ha sviluppato un tool molto utile (e decisamente meno fastidioso per l’utente) per provare che dall’altra parte del monitor c’è un essere umano:

Google Recaptcha

Esistono diversi Plugin per Magento che permettono di integrare il controllo reCaptcha nei form della piattaforma. Hanno diversi prezzi e diverse modalità di installazione e configurazione: alcuni consentono di integrare il reCaptcha senza dover mettere mani al codice, ma in questo caso ho preferito un Plugin GRATUITO abbastanza semplice da installare e configurare. E’ possibile scaricarlo da questo indirizzo sul sito Magecomp e si chiama: Magento Google reCaptcha .

Nonostante sia gratuito, occorre seguire la normale procedura che si farebbe se fosse a pagamento: si mette nel carrello e si ordina. Ovviamente lo STEP del pagamento non verrà proposto e pochi secondi dopo l’acquisto si può scaricare il file zippato (con tar e gzip) contenente il Plugin.

Il file si trova facilmente cliccando su: My downloadable products nel menu di sinistra del sito.

Installazione e Configurazione

Per la navigazione su file e cartelle remote (sui server) uso spesso mc, Midnight Commander.

apt-get install mc su macchine Ubuntu / Debian

Per spostare il file del Plugin sul server ci sono tanti modi diversi (quando non è possibile scaricarlo direttamente dal sito di provenienza): è possibile usare FTP (saranno 20 anni che non installo FTP sui miei server, ma è un metodo abbastanza diffuso), oppure scp (dal terminale di Linux o del Mac) o ancora PSCP.EXE (se si usa Putty da macchine Windows). Io preferisco un metodo più pratico: sposto il file in una cartella dropbox che uso solo per lo scambio di file tra vari PC, poi Tasto Dx del mouse sul file e click su Condividi (con accanto l’icona di Dropbox). Compare la seguente finestra:

Cliccando su Crea link verrà generato un link di condivisione del file e compariranno due testi cliccabili: Impostazioni link e Copia Link. Premendo su questo secondo testo si avrà il link copiato in Clipboard.

A questo punto ci si collega in ssh sul server e si crea da qualche parte una cartella temporanea, ad esempio:

mkdir /tmp/plugins/

cd /tmp/plugins/

Scarichiamo il file (solitamente cliccando col tasto destro del mouse su una shell di linux, oppure con SHIFT + tasto destro si ottiene un INCOLLA del link appena copiato) con:

wget https://www.dropbox.com/s/blablabla/plugin.tgz?dl=<strong>1</strong> -O myplugin.tgz

ATTENZIONE: il link copiato riportera ?dl=0 che NON permette il download diretto, rimandandoti alla pagina Dropbox da cui scaricare il file. A noi basta cambiare ?dl=0 in ?dl=1 e il file verrà giù come una grandinata in Agosto.

ATTENZIONE BIS: prima di procedere da qui in avanti sarebbe opportuno effettuare un BACKUP del nostro sistema (lo si può fare dal pannello di amministrazione di Magento) perchè sbagliare è un’attimo… ripristinare senza avere un backup può essere piuttosto doloroso.

ATTENZIONE TRIS: prima di procedere è opportuno disabilitare la cache di Magento per poi riabilitarla a lavoro concluso. Sistema > Gestione della Cache > Seleziona tutto > Disattiva

Bene, il nostro file ora è sul server, è ora di aprire il nostro file manager digitando mc

Il File manager presenta la schermata divisa in 2 parti: sinistra e destra. In ognuna delle due parti è visualizzato il contenuto di una cartella. Ci spostiamo tra sinistra e destra col tasto di tabulazione TAB, mentre con il tasto INVIO si entra nella cartella evidenziata. Facciamo in modo da avere a sinistra la root directory del nostro sito di commercio elettronico e a destra la cartella temporanea con il plugin appena trasferito sul server. Mc ha la capacità di accedere anche a cartelle compresse per cui ci basterà spostarci sul file e cliccare su INVIO per ritrovarci a visualizzare la struttura del nostro plugin che dovrebbe essere quella visualizzata in figura sotto.

Ci spostiamo nella parte destra con TAB e con le frecce del cursore spostiamo la riga evidenziata su app: a questo punto premiamo il tasto funzione F5 (copia), e si aprirà una finestra che ci chiede quale sia la destinazione della copia. SE nel pannello di sinistra abbiamo già la destinazione (la root html del sito Magento) non occorrerà far altro che premere INVIO perché la destinazione preimpostata sarà già quella corretta. ATTENZIONE: mc ci chiederà se vogliamo SOVRASCRIVERE eventuali file già presenti (nel mio caso c’è solo un conflitto su style.css): la risposta è NO. Faremo la stessa cosa con la cartella skin.

Per chi usa un template diverso da quello standard occorre fare qualche operazione in più: occorre sovrascrivere i file html che contengono i form con quelli forniti dal Plugin:

LO SO! è brutto da farsi e non è cosa che faccio volentieri.

perché se un giorno cambiassi Template dovrei ricordarmi di rifare l’operazione e perché se il template venisse aggiornato (quello che ho comprato non ha avuto aggiornamenti negli ultimi 2 anni) dovrei riportare nuovamente le modifiche… MA, non si può avere la botte piena e la moglie ubriaca: questo è un plugin GRATUITO, la modifica richiesta è LOW LOW LOW budget (per cui non voglio impiegare un minuto più del necessario, risolvendo comunque il problema). Cosa dobbiamo sovrascrivere dunque?

in app/design/frontend/default/nomeDelTuoTema/layout occorrerà copiare il contenuto che troviamo nel plugin sotto > app/design/frontend/base/default/layout e in app/design/frontend/default/nomeDelTuoTema/template dovrai andare a sostituire i file che contengono i form che vuoi proteggere. Ad esempio nella directory app/design/frontend/default/nomeDelTuoTema/template/newsletter

c’è il file subscribe.phtml che per prima cosa backuppo (subscribe.theme.phtml) e poi sovrascrivo con il file che trovo in app/design/frontend/base/default/template/recaptcha/newsletter.

Se a questo punto andassimo a visualizzare i form, vedremmo già il recaptcha, ma non sarebbe attivo lato server: questo vuol dire che se l’utente riuscisse a inviare il form senza utilizzare il controllo, Magento accetterebbe i dati senza controlli ulteriori. Per fare in modo che il controllo venga effettuato anche lato server occorre configurare il plugin.

Per prima cosa occorre ottenere una Site key ed una Private key iscrivendosi al servizio su Google. Una volta inserito il dominio (è anche possibile utilizzare la stessa coppia di chiavi per più domini, se indicati) Google ci mostra le due chiavi da utilizzare in configurazione.

Se abbiamo installato correttamente il Plugin (potrebbe essere necessario un Logout + nuovo Login dall’area amministrativa di Magento per vederlo) possiamo configurarlo da Sistema > Configurazione > MageComp > Google Recaptcha.

La prima voce abilita il Plugin lato server, seconda e terza voce le abbiamo appena ottenute; il thema può essere Light (sfondo bianco) o Dark (sfondo grigio scuro); l’ultima scelta ci permette di attivare il Plugin selettivamente solo su alcuni form utilizzati.

Se abbiamo fatto tutto a modino quello che otteniamo è ad esempio questo:

Come si può notare entrambi i form della pagina presentano il Google Recaptcha. Un occhio attento noterà che la dimensione dei due box non è identica. Può capitare infatti che, per esigenze stilistiche, il box debba essere ridimensionato (in questo caso quello sotto il campo di iscrizione Newsletter era sensibilmente più lungo del campo sovrastante, quindi andava rimpicciolito). Non ci sono possibilità di stilizzazione del recaptcha, ma c’è un escamotage che si può utilizzare: andiamo ad aprire il file app/design/frontend/default/ilTuoTema/template/newsletter/subscribe.phtml (o qualunque altro form a noi interessi modificare). Andiamo ad individuare il blocco div che ha classe=”g-recaptcha” e gli affibbiamo questo stile:

style="transform:scale(0.89); -webkit-transform:scale(0.89); transform-origin:0 0; -webkit-transform-origin:0 0;"

Siamo quindi andati a scalare l’intero blocco per andare a matchare le dimensioni del campo superiore.

Qui sotto un’immagine che mostra il risultato della nostra modifica al codice:

PS. questa modifica può creare alcuni problemi di visualizzazione in alcuni template (fondamentalmente non si riesce a mettere il focus sul campo “email”). Personalmente ho dovuto spostare tutto il blocco condizionale (if () …) che contiene il codice in figura, qualche riga più in basso, al di sotto dei blocchi div che contengono il tasto SUBMIT.

Conclusioni

Con pochi passi abbiamo visto come proteggere i nostri Form dai BOT che setacciano la rete in modo sistematico. Avere qualche falso account può sembrare poca cosa, cosi come qualche falso iscritto alla Newsletter. Ma abbiamo visto che nel nostro caso l’iscrizione di circa 800 nominativi alla newsletter ha comportato il blocco di una funzionalità importante del nostro sito Ecommerce: l’invio delle mail di conferma dell’ordine. Se il BOT avesse voluto avere un impatto maggiore avrebbe potuto metterci fuori uso il sito iscrivendo molti più utenti in breve tempo. Il Google reCaptcha è un buon compromesso per l’utente perché non richiede l’interpretazione di scritte astruse che a volte risultano illegibili persino a noi. Ultima TIP: Magento presenta i suoi “anticorpi” a tentativi ripetuti di accesso all’area riservata (ci sono BOT che cercano con la forza bruta le nostre credenziali per l’area riservata) ma se si volesse aggiungere un livello di protezione in più, è possibile utilizzare il reCaptcha anche con questo scopo.