Prosegue l'esplorazione nel mondo dell' Ethical Hacking, la branca della sicurezza informatica che si occupa di effettuare test attivi su ambienti in produzione.

L'aspetto di cui si occupa quest'articolo e' l'SQL Injection e come un Security Probe  possa  evidenziare tale problema prima che sia causa di spiacevoli inconvenienti o di vere e proprie frodi.

Un  SQL Injection è un attacco teso a colpire applicazioni pubbliche supportate da un databse SQL con l'obbiettivo di ottenere il controllo del databse stesso.
Questa vulnerabilità è legata ad una scorretta programmazione dell'applicazione pubblica e per questo motivo e' difficilmente arginata dai normali sistemi di protezione come Firewall e IDS.

La maggior parte dei siti  web presenti su internet fa ormai uso di contenuti dinamici o di linguaggi server side come PHP o ASP per interagire con data base.
Per questo motivo Shopping Carts, form, login page  e tutti i contenuti dinamici sono potenzialmente vulnerabili a questo tipo di attacco.

Alcuni studi, forse un po' allarmistici, dichiarano che il 75% delle frodi via web siano legate a questa problematica. Tuttavia se pensiamo che i potenziali bersagli sono ecommerce e data base di dati piu' o meno sensibili possiamo capire come mai  vi sia cosi tanta attenzione al problema.

Ad aggravare la situazione va sottolineato che la base su cui si fonda l'attacco e' un singolo errore umano del programmatore all'interno di un progetto di ampie dimensioni.
In una piattaforma web molto sviluppata la possibilità di trovare un punto in cui sfruttare tale vulnerabilità risulta molto alta.

L'sql injection ricorda molto il buffer Overflow ma applicato in un ambiente molto meno complesso.
Sfrutta un mancato controllo su un parametro web per iniettare codice SQL all'interno di un interrogazione.

Tipicamente una applicazione web acquisisce dai parametri dalle scelte dell'utente e compone una stringa SQL da inoltrare al database.
L'applicazione genera la domanda SQL ed il databese fornisce la risposta.
Lo sviluppatore prevede che l'utente inserisca  un  parametro consono al contesto dell'applicazione, al più formula dei casi d'errore  per fare fronte a scelte sbagliate.

Quello che normalmente non si aspetta è che l'utente di metta a pasticciare con l'aritmetica delle stringhe o che inserisca valori di 200 caratteri o una complessa serie di caratteri speciali al posto dei 5 previsti per il CAP o per l'indirizzo.

Questa tecnica ha lo scopo di valutare che tipo di controlli vengono effettuati su un campo per poi poter "forzare" la costruzione della stringa SQL.

Select * from PasswordTable where user=’mario’ and password=’mario1’

Che tradotto dal sql significa più o meno:

Rispondi “tutto bene” se nel registro delle password all’utente mario corrisponde la password mario1.

Se però nello spazio per inserire la password inseriamo qualcosa di anomalo come 123’ or ‘1’=’1 possiamo ottenere una reazione imprevista  (per lo sviluppatore...)

Select * from PasswordTable where user=’mario’ and password=’123’ or ‘1’=’1’

Senza nessun controllo la stringa appena inserita agisce in modo diretto nella creazione della stinga SQL ed ottiene qualcosa che risulta più o meno così:

Rispondi “tutto bene” se nel registro delle password all’utente mario corrisponde la password 123 Oppure rispondi “tutto bene” se 1 = 1 .

Che la password di mario non sia 123 poco importa, la seconda parte del controllo, da noi forzato, permette di ottenere il “tutto bene” che ci serve per autenticarsi come mario.

L’esempio è abbastanza banale ma senza la conoscenza base di questo problema e’ possibili incaparvi durante la realizzazione di una applicazione.

Ovviamente le tecniche di sicurezza sono progredite e parimenti anche le tecniche di hacking per sfruttare una vulnerabilità simile.
Individuato un singolo elemento non correttamente protetto all’interno di un applicazione web si può procedere seguendo due approcci:

• Il primo prevede uno studio dei messaggi d’errore per ricostruire lo schema sql del DB e continuare ad operare in ambiente SQL (difficilmente tracciabile)
• Il secondo prevede un attacco diretto al database server attraverso l’sql injection teso a prendere il controllo dell’apparato stesso. Molto piu’ “rumoroso” ma in grado di dare il controllo completo di un apparato al di la del controllo periferico del firewall.

Un analisi Ethical Hacking permette di individuare questi elementi critici prima che siano sfruttati. La strumentazione d’indagine e’ molto simile e sfrutta lo stesso codice automatico che un aggressore esterno userebbe per setacciare un applicazione web.

Va inoltre ribadito che coloro che esguono dei test di verifica dovrebbero essere diversi da coloro che hanno realizzato il prodotto, questo per godere di un diverso punto di vista ed di una apporccio piu' analitico.

Purtroppo risulta difficile per uno sviluppatore effettuare autonomamente test di  sicurezza sui propri applicativi.

Individuati i punti di pericolo sono nella maggior parte dei casi facilmente risolvibili.

Il suggerimento per ovviare hai pericoli dell’SQL injection sono quindi due:

• una maggior attenzione in fase di sviluppo al problema

• un analisi dettagliata dell’applicazione “a caldo” (Ethical Hacking)