Contromisure e tecniche per previnire le infezioni ai sistemi RFID

Contromisure e tecniche per previnire le infezioni ai sistemi RFID

In questo articolo informatico sulle Contromisure lato middleware ad infezioni RFID vedremo come dobbiamo comportarci, nel caso in cui ci dovessimo trovare faccia a faccia con la configurazione di un sistema RFID, per prevenire possibili attacchi informatici al sistema.

Contromisure e tecniche per previnire le infezioni ai sistemi RFID

Controllo dei limiti

Il controllo dei limiti può prevenire attacchi di tipo Buffer Overflow, individuando o meno un indice che si trova entro i limiti dell’array. Solitamente questa operazione viene fatta del compilatore, in modo da non indurre a ritardi di runtime: linguaggi di programmazione come Visual Basic, Java e C# non hanno bisogno di questo controllo. In ogni caso, sistemi middleware RFID scritti in altri linguaggi come C o C++ dovrebbero essere compilati con questo controllo se possibile, ci sono comunque tools che possono fare questo automaticamente con Valgrind e Electric Fence. I tools di analisi statstica del codice sorgente non rappresentano, e non vanno considerati, una panacea: dopo tutto sono sempre usati ed i loro risultati interpretati dall’essere umano, il quale molte volte puo’ sbagliare. Un esempio clamoroso fu il bug dell’anno scorso su OpenSSL nelle distro Debian-based, dove il maintainer della libreria, interpreto’ in modo non corretto l’output di Valgrind riducendo enormemente l’entropia nel Pseudo Random Number Generator di OpenSSL.

Limitare l’input

Attacchi di tipo Code Insertion e SQL Injection possono essere facilmente neutralizzabili limitando i possibili caratteri in input: un modo per ovviare al problema potrebbe essere quello di proibire tutti i possibili caratteri speciali, ma solitamente è più semplice cercare di accettare solo dati contenenti caratteri alfanumerici standard (0-9, a-z, A-Z). Comunque non è sempre possibile eliminare tutti i caratteri speciali perchè ad esempio, se un tag RFID su un libro contiene il nome dell’editore che ha nel nome il carattere ‘ (come ad esempio O’Reilly) non possiamo escluderlo! Anche se proviamo a sostituire le quote con i backslash, non sempre questo può essere d’aiuto perchè il simbolo ‘ può essere rappresentato in Unicode per esempio. Solitamente è più sicuro utilizzare le funzioni di limitazione dei dati integrate nei databases, come mysql_real_escape_string() in MySQL;

Disabilitare i linguaggi degli script di back-end

Le strutture middleware RFID che usano l’ HTTP possono diminuire la possibilità di subire un attacco di Sql Injection eliminando la possibilità di attivare script da parte del client, questo potrebbe includere anche la possibilità di disabilitare entrambi i linguaggi sia dal lato client (come Javascript, Java, VBScript, ActiveX e Flash)  che dal lato server;

Limitare i permessi dei databases

Le connessioni verso il database dovrebbero avere un numero molto ristretto di permessi possibili: le tabelle dovrebbero essere solo read- only o addirittura inaccessibili, perchè in questo modo si riuscirebbe a limitare possibili Sql Injections. Inoltre anche disabilitare la possibilità di eseguire SQL multipli in una singola query potrebbe diminuire la possibilità d’attacco;

Utilizzare parametri vincolanti

Creare costrutti dinamici SQL “on-the-fly” è abbastanza rischioso, invece è meglio utilizzare le procedure contenute nel DB con un parametro vincolante. Questo parametro in pratica non viene trattato come un valore, rendendo gli attacchi SQL più difficili;

Isolare il server RFID della struttura middleware

Non deve essere possibile l’accesso a tutta l’infrastruttura di back-end solamente perchè sia stato compromesso il server RFID della struttura middleware: le confugurazioni della rete interna dovrebbero limitare questa possibilità;

Controllare il codice sorgente

Ovviamente, i codici sorgente delle strutture middleware RFID più vengono controllati e più diminuirà la possibilità di bugs sfruttabili. Le strutture middleware RFID fatte in casa dovrebbero essere controllate in modo abbastanza approfondito, mentre solitamente le soluzioni commerciali RFID-based o open-source RFID hanno un contenuto minore di bugs.

 

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *