Le più comuni Web 2.0 Security Vulnerabilities come ad esempio: Cross Site Scripting (XSS), Cross Site Request Forgery (CSRF), Phishing, SQL injection etc. e le Principali tecniche di difesa.
Su Internet viaggiano tantissime informazioni non solo immagazzinate nei siti web, ma anche con e-mail, chatting, ecc. Sotto questo punto di vista Internet si caratterizza attualmente come una rete fondamentalmente ultrademocratica dove ciascun singolo utente può veicolare informazioni di qualunque tipo ai propri scopi e spesso in maniera del tutto anonima.
Tale fatto se da una parte rappresenta una delle ragioni principali del successo della rete come potente strumento di comunicazione di massa, dall’altra, ovvero nel rovescio della medaglia, evidenzia debolezze e vulnerabilità intrinseche dovute sostanzialmente al fatto che il “potere” è demandato al mittente e a chi eventualmente “controlla” la rete: molte sono infatti le tipologie di attacco alla sicurezza informatica attuabili a mezzo della rete stessa da parte di pirati informatici (cracker) con intenzioni malevoli quali ad esempio attacchi di negazione del servizio e furto di dati personali dell’utente (password e codici di autenticazione, clonazione delle carte di credito, ecc.) nonché truffe dirette ai danni dei consumatori ad esempio tramite false e-mail.
Il Cross-site scripting (XSS) è una vulnerabilità che affligge siti web dinamici che impiegano un insufficiente controllo dell’input nei form. Un XSS permette ad un Cracker di inserire o eseguire codice lato client al fine di attuare un insieme variegato di attacchi quali ad esempio: raccolta, manipolazione e reindirizzamento di informazioni riservate, visualizzazione e modifica di dati presenti sui server, alterazione del comportamento dinamico delle pagine web ecc. Nell’accezione odierna, la tecnica ricomprende l’utilizzo di qualsiasi linguaggio di scripting lato client tra i quali JavaScript, VBScript, Flash, HTML. Il loro effetto può variare da un piccolo fastidio a un significativo rischio per la sicurezza, a seconda della sensibilità dei dati trattati nel sito vulnerabile e dalla natura delle strategie di sicurezza implementate dai proprietari del sito web.
La maggior parte degli esperti distingue almeno due principali tipi di vulnerabilità XSS: non persistente e persistente. Alcune fonti dividono ulteriormente questi due gruppi in tradizionale (causate da problemi nel codice lato server) e DOM-based (nel codice lato client).
Le vulnerabilità cross-site scripting di tipo reflected sono sicuramente le più comuni. È possibile sfruttarle quando i dati forniti dall’utente (di solito tramite form HTML) sono usati immediatamente dallo scripts lato server per costruire le pagine risultanti senza controllare la correttezza della richiesta.
Dato che i documenti HTML hanno uno struttura piatta in cui sono mescolate istruzioni di controllo, di formattazione e di contenuto effettivo, se tutti i dati forniti dall’utente non validati sono inclusi nella pagina risultante senza un’adeguata codifica HTML, questo può portare a iniezione di codice di markup[8] . Un esempio classico di un potenziale vettore è il motore di ricerca del sito: se si cerca una stringa, in genere questa verrà visualizzata di nuovo nella pagina dei risultati per indicare cosa si è cercato. Se questa risposta non evita o rigetta i caratteri di controllo HTML si consegue che è vulnerabile ad attacchi cross-site scripting.
Un attacco non persistente è tipicamente inviato via mail o da un sito web neutrale. L’esca è un URL dall’aspetto innocente, che punta a un sito attendibile ma che contiene un vettore XSS. Se il sito affidabile è vulnerabile a quel vettore, il click sul link può causare l’esecuzione di script iniettato nel browser della vittima.
Una vulnerabilità XSS persistente (o stored) è una variante più devastante di cross-site scripting: si verifica quando i dati forniti dall’attaccante vengono salvati sul server, e quindi visualizzati in modo permanente sulle pagine normalmente fornite agli utenti durante la normale navigazione, senza aver eliminato dai messaggi visualizzati dagli altri utenti la formattazione HTML.
Ad esempio, supponiamo che ci sia un sito di incontri in cui i membri visionano i profili degli altri membri per cercare interessi comuni. Per motivi di privacy, questo sito nasconde a tutti il vero nome e la mail degli utenti. Queste informazioni sono tenute segrete dal server. L’unico momento in cui il nome reale e l’email sono visualizzati è quando il membro si autentica, non potendo vedere comunque i dati di chiunque altro.
Supponiamo che un attaccante si colleghi al sito e vuole capire i veri nomi delle persone che vede sul sito. Per fare ciò scrive uno script progettato per essere eseguito dal browser delle altre persone quando visitano il suo profilo. Lo script invia un breve messaggio al suo server che raccoglie queste informazioni.
Per fare questo, per il quesito “Descrivi il tuo primo appuntamento ideale”, l’attaccante dà una risposta breve (dall’aspetto consueto) ma il testo alla fine della risposta è lo script per rubare i nomi e le mail. Se lo script è racchiuso all’interno di un elemento <script> non verrà visualizzato a schermo. Quindi supponiamo che Bob, membro del sito di incontri, raggiunga il profilo dell’attaccante, dove viene visualizzata la risposta alla domanda riguardo al primo appuntamento ideale. Lo script viene automaticamente eseguito dal browser e ruba il nome reale e la mail di Bob direttamente dalla sua macchina.
Le vulnerabilità XSS di tipo persistente possono essere molto più significative rispetto alle altre perché lo script dannoso dell’attaccante è fornito automaticamente senza la necessità di indirizzare la vittima o attirarla nel sito di terze parti. In particolare nel caso di siti di social-network, il codice potrebbe essere progettato per propagarsi autonomamente tra gli account, creando un tipo di worm lato client. I metodi di iniezione possono variare tantissimo, in alcuni casi l’attaccante non ha nemmeno bisogno di interagire con le funzionalità web per sfruttare una falla. Tutti i dati ricevuti da una applicazione web (via email, log di sistema, messaggistica istantanea, ecc.) che possono essere controllati da un utente malintenzionato potrebbero diventare vettore di iniezione.
Storicamente le vulnerabilità XSS sono state trovate in applicazioni che svolgevano tutto il processamento dei dati lato server. L’input dell’utente (tra cui un vettore XSS) sarebbe stato inviato al server per poi essere rimandato indietro come una pagina web. La necessità di migliorare la user experience ha dato popolarità ad applicazioni che avevano una logica di presentazione (scritta in JavaScript) che inviava i dati, su richiesta, al server usando AJAX.
Mentre il codice JavaScript processa anche gli input dell’utente e li visualizza nella pagina web, la nuova sottoclasse di attacchi XSS di tipo reflected ha iniziato ad apparire ed è stata chiamata DOM-based cross-site scripting. Negli attacchi XSS DOM-based, i dati malevoli non sono toccati dal server web, piuttosto, sono riflessi dal codice JavaScript interamente sul lato client.
Un esempio di vulnerabilità XSS DOM-based è un bug trovato nel 2011 in una serie di plugin JQuery. Le strategie di prevenzione per gli attacchi XSS DOM-based includono misure molto simili alle strategie tradizionali di prevenzione XSS, ma implementante in codice JavaScript e incluse nelle pagine. Alcuni framework JavaScript hanno creato contromisure contro questi e altri tipi di attacchi — ad esempio Angular.js.
In un attacco Universal Cross-Site Scripting (UXSS, o Universal XSS) vengono sfruttate le vulnerabilità del browser stesso, piuttosto che le vulnerabilità nei siti web, come per gli attacchi XSS. Tali attacchi sono comunemente usati da Anonymous, insieme a DDoS, compromettendo il controllo della rete.
Diverse classi di vulnerabilità o tecniche di attacco sono legate a XSS: i cross-zone scripting permettono l’esecuzione di codice con maggiori privilegi in alcuni browser. HTTP header injection può essere usato per creare le condizioni necessarie per il cross-site scripting sfuggendo a problemi di HTTP protocol level (oltre a consentire attacchi come il HTTP response splitting).
Cross-site request forgery (CSRF/XSRF) è quasi l’opposto del XSS, nel senso che invece di sfruttare la fiducia degli utenti in un sito, l’attaccante e la sua pagina malevola, sfrutta la fiducia del sito nel software del client, facendo richieste che il sito ritiene azioni consapevoli e intenzionali di un utente autenticato. Vulnerabilità XSS (anche in altre applicazioni in esecuzione nello stesso dominio) consentono agli aggressori di bypassare gli sforzi di prevenzione CSRF .
Covert Redirect sfrutta client di terze parti suscettibili ad attacchi XSS o Open Redirect. Covert Redirect è stato scoperto dal dottorato di ricerca dello studente Wang Jing del Nanyang Technological University, in Singapore. “Tentativi di normale phishing possono essere facilmente individuati, perché l’URL della pagina malevola è di solito diversa al massimo un paio di lettere rispetto a quella del sito vero e proprio. La differenza con Covert Redirect è che un utente malintenzionato potrebbe utilizzare il sito web vero e proprio anziché violare il sito web con un pop-up di login dannoso.”
Infine, SQL injection sfrutta una vulnerabilità nel livello di database dell’applicazione. Quando l’input dell’utente non viene filtrato in modo corretto, possono essere eseguite dall’applicazione tutte le istruzioni SQL.
Il phishing è un tipo di truffa effettuata su Internet attraverso la quale un malintenzionato cerca di ingannare la vittima convincendola a fornire informazioni personali, dati finanziari o codici di accesso, fingendosi un ente affidabile in una comunicazione digitale.
Si tratta di una attività illegale che sfrutta una tecnica di ingegneria sociale: il malintenzionato effettua un invio massivo di messaggi di posta elettronica che imitano, nell’aspetto e nel contenuto, messaggi legittimi di fornitori di servizi; tali messaggi fraudolenti richiedono di fornire informazioni riservate come, ad esempio, il numero della carta di credito o la password per accedere ad un determinato servizio. Per la maggior parte è una truffa perpetrata usando la posta elettronica, ma non mancano casi simili che sfruttano altri mezzi, quali i messaggi SMS.
Il phishing è una minaccia attuale, il rischio è ancora maggiore nei social media come Facebook, Twitter, e Google+. Degli hacker potrebbero infatti creare un clone del sito e chiedere all’utente di inserire le sue informazioni personali. Gli hacker comunemente traggono vantaggio dal fatto che questi siti vengono utilizzati a casa, al lavoro e nei luoghi pubblici per ottenere le informazioni personali o aziendali.
Il termine phishing è una variante di fishing (letteralmente “pescare” in lingua inglese),probabilmente influenzato da phreaking e allude all’uso di tecniche sempre più sofisticate per “pescare” dati finanziari e password di un utente. La parola può anche essere collegata al linguaggio leet, nel quale la lettera f è comunemente sostituita con ph. La teoria popolare è che si tratti di un portmanteau di password harvesting, è un esempio di pseudoetimologia.
L’Information Leakage è una “Perdita di informazioni” ogni volta che un sistema che è stato progettato per essere “chiuso” ed un intercettatore rivela alcune informazioni a persone non autorizzate. Ad esempio, quando si progetta una rete di messaggistica istantanea crittografata, un ingegnere di rete senza la capacità di decifrare i codici di crittografia potrebbe vedere quando vengono trasmessi i messaggi, anche se non poteva leggerli.
L’injection flaw permette ad un hacker di veicolare il codice diretto da un’applicazione Web ad un altro sistema. Questo tipo di attacco include delle chiamate al S.O. (Sistema Operativo) attraverso system call e l’uso di programmi esterni utilizzando dei comandi shell. E’ infatti possibile, ad esempio, effettuare chiamate al database nel backend attraverso SQL (Structured Query Language), realizzando un SQL injection (iniezione di codice SQL).
SQL injection è una tecnica di code injection, usata per attaccare applicazioni di gestione dati, con la quale vengono inseriti delle stringhe di codice SQL malevole all’interno di campi di input in modo che vengano eseguiti (es. per fare inviare il contenuto del database all’attaccante). L’SQL injection sfrutta le vulnerabilità di sicurezza del codice di un’applicazione, ad esempio quando l’input dell’utente non è correttamente filtrato da ‘caratteri di escape’ contenuti nelle stringhe SQL oppure non è fortemente tipizzato e viene eseguito inaspettatamente. L’SQL injection è più conosciuto come attacco per i siti web, ma è anche usato per attaccare qualsiasi tipo di database SQL.
L’SQL injection permette agli attaccanti di effettuare spoof identify, modificare dati esistenti, causare repudiation issues come l’annullamento di transazioni o la modifica dei bilanci, permette di ottenere tutti i dati sul sistema, eliminare dati oppure fare in modo che non siano accessibili, e diventare amministratori del database server.
In uno studio del 2012, è stato osservato che in media le applicazioni web ricevono 4 attacchi al mese, ed i rivenditori ricevono il doppio degli attacchi rispetto alle industrie.
L’SQL injection (SQLI) è considerata da Open Web Application Security Project una delle 10 maggiori vulnerabilità delle applicazioni web. Nel 2013 SQLI è stato considerato il numero uno degli attacchi sulla OWASP top 10. Ci sono quattro principali sotto classi di SQL injection:
L’SQL injection è un attacco molto conosciuto e facilmente evitabile con semplici misure. Dopo quello che si pensa fosse stato un attacco di SQL injection su Talktalk, la BBC ha riportato come gli esperti di sicurezza fossero stupiti che una così grande compagnia fosse vulnerabile a questo tipo di attacco.
'
) in un parametro deve essere sostituito con due apostrofi (‘ ‘) per ottenere una stringa SQL di letterali valida. Per esempio, in PHP di solito si evitano i caratteri speciali nei parametri utilizzando la funzione mysqli_real_escape_string();
prima di inviare a query SQL:$mysqli=newmysqli('hostname','db_username','db_password','db_name');
$query=sprintf("SELECT * FROM `Users` WHERE UserName='%s' AND Password='%s'",
$mysqli->real_escape_string($username),
$mysqli->real_escape_string($password));
$mysqli->query($query);
denyselectonsys.sysobjectstowebdatabaselogon;
denyselectonsys.objectstowebdatabaselogon;
denyselectonsys.tablestowebdatabaselogon;
denyselectonsys.viewstowebdatabaselogon;
denyselectonsys.packagestowebdatabaselogon;
SELECT*FROMmyTableWHEREid=unhex('32');
Se convertissimo la stringa con unhex() in semplice testo diventerebbe:
SELECT*FROMmyTableWHEREid=2;
La conversione esadecimale elimina gli attacchi di SQL injection perché la stringa esadecimale inviata alla funzione unhex() viene ritornata come stringa già utilizzata e non viene interpretata.
File: test.php
<?php
include_once"dosql.php";
#
# Metti le informazioni sul tuo database qui. Stò usando i dati del mio file di log.
#
$hostname="myhost";
$username="myUser";
$password="myPassword";
$database="myDatabase";
$mysqli=newmysqli($hostname,$username,$password,$database);
if($mysqli->connect_errno){
echo"Failed to connect to MySQL: (",$mysqli->connect_errno,") ",$mysqli->connect_error;
exit;
}
echo"SQL INJECTION - Plain\n";
$sql="SELECT * FROM log WHERE log_id='2' OR 1=1; #'";
$res=dosql($sql);
foreach($res[0]as$k=>$v){
echo"RES[$k] = $v\n";
}
echo"\n\nSQL INJECTION = Hexadecimal\n";
$sql="SELECT * FROM log WHERE log_id=unhex('".bin2hex("2' or 1=1; #'")."')";
$res=dosql($sql);
foreach($res[0]as$k=>$v){
echo"RES[$k] = $v\n";
}
exit;
?>
File: dosql.php
<?php
################################################################################
# dosql(). Do the SQL command.
################################################################################
functiondosql($sql)
{
global$mysqli;
$cmd="INSERT INTO log (date,entry) VALUES (NOW(), unhex('".bin2hex($sql)."'))";
$res=$mysqli->query($cmd);
$res=$mysqli->query($sql);
if(!$res){
$array=debug_backtrace();
if(isset($array[1])){$a=$array[1]['line'];}
elseif(isset($array[0])){$a=$array[0]['line'];}
else{$a="???";}
echo"ERROR @ ",$a," : (",$mysqli->errno,")\n",$mysqli->error,"\n\n";
echo"SQL = $sql\n";
exit;
}
if(preg_match("/INSERT/i",$sql)){return$mysqli->insert_id;}
if(preg_match("/DELETE/i",$sql)){returnnull;}
if(!is_object($res)){returnnull;}
$count=-1;
$array=array();
$res->data_seek(0);
while($row=$res->fetch_assoc()){
$count++;
foreach($rowas$k=>$v){$array[$count][$k]=$v;}
}
return$array;
}
Identificare e gestire i rischi associati all’impiego e alla protezione della risorsa più preziosa di aziende ed utenti: l’informazione. Il concetto di Integrità dell’Informazione, nasce con l’obiettivo di rispondere all’esigenza delle aziende di operare con continuità, al meglio delle loro possibilità, anche in presenza di gravi minacce Internet o altri potenziali ostacoli al normale svolgimento delle attività.
“L’informazione digitale è, ormai, un fenomeno di portata globale”, ha affermato John W. Thompson, Chairman e CEO di Symantec. “Molti ritengono che una parte sostanziale dell’economia mondiale ruoti attorno all’uso, all’archiviazione e alla trasmissione delle informazioni digitali. Si tratta quindi di una potente leva economica, ma, al contempo, devono essere necessariamente assicurate la protezione e la disponibilità di queste informazioni”.
Credits: