SQL Injection. Indice. Introduzione. Informazioni sugli autori. Capire il problema. Metodologie di testing. I problemi piu` diffusi

Transcript

1 SQL Injection Indice Introduzione Informazioni sugli autori Capire il problema Metodologie di testing I problemi piu` diffusi Accessi non desiderati Visualizzare dati non accessibili Analisi delle query tramite l'introduzione di errori Advanced SELECT Injection INSERT Injection STORED PROCEDURES Injection Le feature e i problemi dei DBMS piu` diffusi Scrivere codice sicuro Configurare Linux Configurare Windows 2000 o XP Professional Esempi di codice vulnerabile PHP e PostgreSQL PHP e MySQL ASP e MDB

2 Introduzione L'evoluzione delle esigenze del pubblico internauta ha comportato l'introduzione di tecnologie dinamiche (creazione di contenuti "on demand") nei piu` disparati servizi offerti dal web. Sono sempre piu` numerosi i server, anche gratuiti, che offrono la possibilita` di elaborare script per la creazione di contenuti web e sempre piu` utenti stanno convertendo i propri siti statici in vere e proprie applicazioni residenti sul web. Tali applicazioni utilizzano, nella maggioranza dei casi, dati provenienti dall'utente ed introducono quindi la possibilita` di modifica arbitraria delle variabili utilizzate dallo script, rendendo cosi` possibile l'insorgere di vulnerabilita` sfruttabili da remoto. In questo paper analizzeremo una fra le piu` diffuse vulnerabilita` delle applicazioni web-related: la vulnerabilita` da SQL Injection. Informazioni sugli autori Eduard <Master^Shadow> Roccatello studia Ingegneria Informatica presso l'universita` di Padova. Si occupa di programmazione e di amministrazione di rete con un occhio di riguardo alle problematiche di sicurezza su sistemi unixlike. Aspinall studente in Informatica e Amministratore di Sistema, si interessa di sviluppo e sicurezza in ambiente UNIX. Sono entrambi membri di S.P.I.N.E. Group ( Capire il problema La maggior parte delle applicazioni web vengono realizzate interfacciando l'applicazione stessa ad un server DBMS ed interagiscono con tali server tramite l'utilizzo del linguaggio standard SQL. SQL Injection e` una tecnica di exploiting delle web application che utilizzano dati provenienti dai client nelle query, senza controllare la presenza di caratteri potenzialmente pericolosi. Contrariamente a quello che si puo` pensare, questo tipo di vulnerabilita` e` molto diffusa e tale diffusione e` spesso dovuta alla mancanza di professionalita` di molti programmatori, spesso improvvisati, e alla mancanza di solide basi di programmazione sicura. Metodologie di testing Controllare le applicazioni per trovare eventuali vulnerabilita`

3 dovute all'sql Injection potrebbe essere molto complesso ma ci sono casi dove la ricerca di script potenzialmente vulnerabili e` molto semplice. Se, ad esempio, l'aggiunta di un apice in un form ritorna una pagina bianca o piena di errori riportati dal server DBMS siamo gia` ad un buon punto di partenza per quanto comporta la ricerca delle vulnerabilita`. Un buon programmatore dovrebbe controllare l'input di ogni variabile e non pensare che l'utente, utilizzatore della web application, formatti correttamente le variabili. Ogni possibile campo dovrebbe essere testato per tutte le vulnerabilita` che potrebbero coinvolgerlo, in modo da evitare ripercussioni in tutto lo script, spesso legato ad altri. Un buon metodo di controllo delle applicazioni web potrebbe essere quello di inserire in ogni campo una comando tipico di SQL preceduto da un apice, cercando cosi` eventuali problemi sulle singole variabili. Dopo aver provato i campi uno alla volta potrebbe essere utile riempire il form con dati formalmente corretti e ripetere la procedura "apice+comando" per ogni campo, mantenendo formalmente corretti gli altri campi. Ipotizziamo di passare ad uno script questi parametri formalmente corretti: script.php?nome=mario&cognome=rossi& =mariorossi@provider.ext Lo script funziona alla perfezione. Proviamo ora a modificare la stringa con un apice nel parametro "nome": script.php?nome='mario&cognome=rossi& =mariorossi@provider.ext Ipotizzando che lo script sia vulnerabile, siamo andati a modificare i parametri inviati al server DBMS dalla query, modificandone strutturalmente la sintassi (ricordo che l'apice (') e` un operatore SQL). Cosa potrebbe accadere utilizzando una stringa di parametri come quella proposta dall'esempio? I risultati potrebbero essere molteplici: dalla semplice pagina bianca ai piu` disparati errori provenienti dal server DBMS. Potrebbe riportare l'errore che gli altri paramentri non sono stati inseriti o addirittura mostrare dati che non dovrebbero essere visualizzati con quella query. Dopo aver trovato una possibile vulnerabilita` da SQL Injection, la parte piu` importante e` l'interpretazione degli errori. Se l'errore viene generato del server DBMS siamo sicuramente davanti ad una vulnerabilita` ad SQL Injection ma gli errori spesso sono tutt'altro che ovvi. Controlliamo sempre gli errori che si riferiscono ad ODBC, alla sintassi, al server SQL. Bisogna inoltre prestare attenzione alle piu` minimali modifiche della pagina, segno di SQL Injection Exploiting, poiche` molti programmatori possono nascondere le informazioni mettendo, ad

4 esempio, eventuali errori negli header del documento HTML e non mostrandone traccia nel body, la parte visualizzata dal browser. Non bisogna fermarsi all'analisi della singola pagina colpita da SQL Injection ma e` buona abitudine seguire i link presenti nella pagina, alla ricerca di eventuali ripercussioni sull'intera applicazione ed e` importante seguire anche eventuali redirect verso una pagina di errore predefinita, spesso preceduta da una schermata di errore propria del database. I problemi piu` diffusi Passiamo ora all'analisi dei piu` diffusi problemi di sicurezza dovuti alla vulnerabilita` da SQL Injection. Accessi non desiderati L'autenticazione delle web application e` spesso delegata ad uno script di login che ha il compito di processare la coppia login/password proveniente dal client e di confrontarla con le coppie presenti nel database. In caso di corrispondenza lo script settera` gli appositi flag per consentire il nostro accesso o, nel caso opposto, ci vietera` l'accesso. Consideriamo il seguente codice PHP: $user = $_GET['nome']; $passwd = $_GET['password']; $query = mysql_query( SELECT * FROM utenti WHERE user='$user' AND password='$passwd' ); if (mysql_num_rows($query) == 0) { $logged = 0; } else { $logged = 1; } Questo breve script prende i dati dalla querystring e li mette nella query senza controllare la presenza di eventuali caratteri pericolosi. Ipotizziamo di modificare entrambi gli argomenti passati allo script in "' OR ''='" e di far processare la pagina al server. La parte condizionale della query passata al server DBMS (in questo caso MySQL) diventa:... WHERE user='' OR ''='' AND passwd='' OR ''='' Come potrete ben capire entrambe queste condizioni sono sempre verificate e mysql_num_rows() restituira` un valore sicuramente diverso da zero (se la tabella contiene dati) consentendo cose` il login a qualsiasi persona a conoscenza di questo problema.

5 Visualizzare dati non accessibili Il mancato parsing dei parametri per caratteri maligni ha introdotto la possibilita` di editare, a piacimento dell'attaccante, la query verso il database. Abbiamo appena visto che e` possibile entrare con il massimo dei privilegi in un'applicazione web ma potremmo decidere di accedere a dati non direttamente accessibili dall'applicazione stessa. Lo standard SQL permette la creazione di SELECT multiple tramite il comando UNION e tale fatto puo` essere sfruttato per gli scopi dell'attaccante. Prendiamo in esame la seguente query: SELECT nome FROM users WHERE paese='$var' La variabile $var dovrebbe contenere il paese di provenienza degli utenti, dei quali stiamo cercando il nome ma, su di essa, non viene fatto nessun controllo ed e` quindi possibile scrivere codice SQL direttamente nella variabile. Nel nostro caso $var conterra` ' UNION ALL SELECT nome, passwd FROM users ''=' Vediamo il contenuto della query una volta settata $var: SELECT nome FROM users WHERE paese='' UNION ALL SELECT nome, passwd FROM users WHERE ''='' Evidentemente la prima SELECT non restituira` nessun record (supponendo che nessun utente ha il campo paese vuoto) mentre la seconda SELECT e` incondizionata e restituira` tutte le coppie nome/password. Il problema e` quello della visualizzazione dei dati: i dati ora sono stati estratti dal database ma l'applicazione considera solo il campo "nome" e non "password". Fortunatamente (!) il linguaggio SQL permette l'aliasing dei campi tramite il comando AS che puo` essere sfruttato per fare l'output dei dati non visualizzabili ordinariamente. Analisi delle query tramite l'introduzione di errori Molti server web restituiscono parte delle query in caso di errore. Normalmente questa funzionalita` e` utile, anzi direi necessaria, durante il debugging delle applicazioni web ma puo` essere usata impropriamente per analizzare le query e quindi carpire informazioni sulla realizzazione di una web application vulnerabile da SQL Injection. E' sempre utile testare un'applicazione inserendo volutamente errori di sintassi nei campi che interagiscono con l'utente, magari utilizzando costrutti SQL incompleti come "valore'", "'",

6 "'valore", "' OR '", ";" e "0,1,2". Advanced SELECT Injection Non sempre le web application elaborano query semplici e lineari. Capita a volte che siano presenti istruzioni racchiuse da parentesi, selezione sulla base di wildcards e campi non direttamente modificabili. Iniettare codice sintatticamente corretto e funzionante all'interno di queste tipologie di query potrebbe richiedere l'utilizzo di piccoli accorgimenti, a volte non immediati. SELECT nome FROM utenti WHERE (paese='campovariabile') Estrapolare dati da una query di questo tipo non puo` essere fatto con il metodo visto nelle pagine precedenti poiche` ci verrebbero segnalati diversi errori di sintassi. Occorre quindi modificare la query utilizzando un campo di questo genere ') UNION ALL SELECT campo FROM altratabella WHERE (''=' che, sostituita nella precedente, soddisfa perfettamente la sintassi SQL: SELECT nome FROM utenti WHERE (paese='') UNION ALL SELECT campo FROM altratabella WHERE (''='') Il trucco sta semplicemente nel completare parentesi e apici con piccoli trucchi in modo da far risultare la sintassi corretta e impostare correttamente le variabili booleane di confronto. Altra sintassi che potrebbe creare problemi e` quella dovuta al costrutto di confronto LIKE. SELECT nome FROM utenti WHERE nome LIKE '%campovariabile%' I simboli di percentuale funzionano nelle query SQL come wildcards e un eventuale completamento %% ritornerebbe tutti i record e quindi non sarebbe applicabile il costrutto UNION. Bisogna quindi pensare di inserire una stringa che non risulti in nessuno dei record, come potrebbe essere ad esempio "!?!". Un campo tipico per iniettare codice in questa query potrebbe essere il seguente:!?!%' UNION ALL SELECT campo FROM tab WHERE campo LIKE '% Sostituendo la query SQL diventa: SELECT nome FROM utenti WHERE nome LIKE '%!?!%' UNION ALL SELECT campo FROM altratabella WHERE campo LIKE '%%'

7 INSERT Injection Finora abbiamo considerato SQL Injection un problema legato al costrutto SELECT ma possiamo tranquillamente dire che questa vulnerabilita` si puo` estendere a qualsiasi query contentente input dell'utente non appositamente controllato. Un altro costrutto potenzialmente vulnerabile e` INSERT, necessario per l'inserimento di nuovi record all'interno di una tabella. Controllare la vulnerabilita` di una query di inserimento comporta le stesse tecniche viste per la query di selezione ma la forzatura di queste query potrebbe segnalarci all'amministratore dell'applicazione in quanto verrebbero riportate nei record parti di sintassi SQL. Iniettare codice nella query INSERT consente all'utente smaliziato di prelevare dati da un database e utilizzarli per la propria registrazione. Ad esempio e` possibile registrarsi al posto di un altro utente senza aver nessun dato su di lui. L'unico trucco necessario per assicurarsi dell'effettiva estrazione dei dati e` quella di visualizzarli (ad esempio tramite il pannello di controllo). Per portare a termine questo tipo di exploit il server DBMS deve supportare le SUBSELECT (ad esempio MySQL non supporta questa feature) e si devono conoscere i nomi di campi e tabella, ricavabili con un po' di reverse engineering. Ipotizziamo di avere la seguente query di inserimento: INSERT INTO tab (nome, cognome) VALUES ('campo1', 'campo2') Se al posto di campo1 inseriamo e al posto di campo2 inseriamo ' + SELECT nome FROM tab LIMIT 1 + ' ' + SELECT cognome FROM tab LIMIT 1 + ' otteniamo una perfetta replica di un record esistente all'interno del database poiche` la query in questione diventa: INSERT INTO tab (nome, cognome) VALUES ('' + SELECT nome FROM tab LIMIT 1 + '', '' + SELECT cognome FROM tab LIMIT 1 + '') Per cambiare l'utente da selezionare basta scorrere i record con l'offset offerto dall'istruzione LIMIT o, eventualmente, usare la sintassi NOT IN () per ciclare i record. STORED PROCEDURES Injection Exploitare le stored procedures e` generalmente molto piu`

8 semplice che agire sul costrutto SELECT. Le stored procedures sono parti di codice SQL richiamabili nei costrutti SQL tramite l'utilizzo di EXEC e sono praticamente degli script batch, atti ad effettuare operazioni direttamente all'interno del server DBMS. Hanno la particolarita` di essere abbastanza veloci e sono molto utilizzate per le operazioni transizionali. Non tutti i server DBMS permettono l'esecuzione delle stored procedures e, per richiamare l'esecuzione delle stesse, e` necessario che lo stesso server permetta l'utilizzo di statement multipli (istruzioni SQL distinte separate da un punto e virgola). Diversi server DBMS hanno comunque queste feature e possiedono, inoltre, diverse Stored Procedures predefinite, molte delle quali possono compiere operazioni molto interessanti per un attaccante. Esaminiamo la vulnerabilita` piu` evidente nel server DBMS di MicroSoft, MS SQL Server. Tale server attiva di default innumerevoli stored procedures, fra le quali troviamo xp_cmdshell ovvero un frontend per l'interprete dei comandi dei sistemi basati su kernel NT. Il server in questione supporta statement multipli e basta quindi una qualsiasi vulnerabilita` da SQL Injection per accedere al sistema con i permessi del server SQL. Consideriamo la seguente query: SELECT * FROM tab WHERE nome='campovariabile' Terminando il primo costrutto con un nome arbitrario ed applicando la sintassi di EXEC sulla procedura xp_cmdshell otteniamo la sequente query: SELECT * FROM tab WHERE nome='ed'; EXEC master.dbo.xp_cmdshell 'cmd.exe comando' Al posto di "comando" possiamo immettere qualsiasi stringa di comando interpretabile dalla shell dei sistemi NT ovvero il sistema e` in balia dei nostri comandi. Ovviamente il sistema server SQL di Microsoft non e` l'unico ad offrire stored procedures predefinite ma e` stato preso in considerazione per la gravita` della situazione che combinata con errori di programmazione web permette l'accesso a persone non desiderate. E' quindi bene disabilitare, o rimuovere, le stored procedures non necessarie al corretto funzionamento del server e assicurarsi che i permessi sulle parti vitali del sistema siano piu` restrittivi possibile. Le feature e i problemi dei DBMS piu` diffusi MySQL Supporta 'INTO OUTFILE' Supporta 'UNION' (dalla versione 4.x)

9 Spesso gira come "root" Molti moduli e librerie non supportano statement multipli Oracle Supporta le SubSelect Supporta 'UNION' Supporta le stored procedures Non supporta statement multipli Molte stored procedures preimpostate, alcune delle quali pericolose DB2 Supporta le SubSelect Supporta 'UNION' Supporta le stored procedures Non supporta statement multipli Postgres Supporta 'COPY' se fatto girare come superutente Supporta le SubSelect Supporta 'UNION' Supporta le stored procedures Supporta gli statement multipli MS SQL Server Supporta le SubSelect Supporta 'UNION' Supporta le stored procedures Supporta gli statement multipli Molte store procedures preimpostate sono pericolose Scrivere codice sicuro Ogni web application che si rispetti deve seguire piccole norme di programmazione per elevare la sicurezza al massimo possibile. Se l'applicazione riceve input dall'utente questo deve essere processato appropriatamente in modo da escludere eventuali caratteri maligni, che potrebbero interferire con le query previste dai programmatori. E' quindi necessario lasciar passare solo i caratteri necessari e filtrare tutti gli indesiderati tramite l'utilizzo di parser appositi (magari una regular expression ben congengnata). Ad esempio per lasciar passare solo i caratteri alfabetici la regexp seguente e` l'ideale: s/[^a-za-z]//g mentre per far passare i soli numeri si puo` applicare: s/[^0-9]//g Lasciare solo i caratteri alfanumerici e` quasi sempre un'ottima soluzione al nostro problema ma puo` capitare di aver bisogno di altri tipi di caratteri. In questo caso e` bene sostituire ai caratteri la loro codifica nello standard UniCode o nello standard

10 HTML. Ovviamente e` sempre bene utilizzare il minimo numero possibile di caratteri non alfanumerici per evitare potenziali problemi di iniezione. Altra feature interessante per aumentare la sicurezza delle web application potrebbe essere l'individuazione di tentativi di iniezione del codice prima del passaggio a stored procedures e a query. All'interno delle stored procedures e` bene non creare le query dinamicamente ma cercare di mantenere fisso piu` codice possibile. Realizzare una procedura di questo tipo richiede la creazione di una procedura contentente la sola query statica ed il semplice passaggio delle variabili come parametri. Ad esempio: CREATE PROC nvarchar(255) AS SELECT nome, cognome, indirizzo, telefono FROM utenti WHERE nick RETURN La configurazione del server deve essere piu` restrittiva possibile e deve evitare la possibilita` di accedere liberamente a parti del sistema non normalmente disponibili. Disabilitare le stored procedure non necessarie agli utenti potrebbe essere la soluzione ai nostri problemi ma un'attenta policy di permessi potrebbe evitare la mutilazione eccessiva del server DBMS. Configurare Linux MySQL La versione scaricata è la seguente : mysql tar.gz Una volta scompattato diamo i seguenti comandi : #./configure --prefix=/usr # make # make install Lanciamo lo script mysql_install_db per generare i database iniziali e ora lanciamo il demone mysqld con il comando # mysql.server start Ricordatevi di settare i permessi, # chown -R root /usr/local/mysql non entriamo troppo nel dettaglio,se dovestre riscontrare dei problemi vi consigliamo di leggervi la documentazione ufficiale.

11 Una volta lasciato il demone in ascolto, possiamo settare la password per l'utente root di mysql: # mysqladmin -u root -p password Per testare il tutto connettiamoci al nostro database appena installato root@aspinazzo:/# mysql -u root -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 10 to server version: log Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> E` raccomandato connettersi al database non da root, quindi aggiungete un nuovo utente al database server. Consultate per scegliere i dovuti privilegi Apache Ora scarichiamo i sorgenti di apache e diamo i seguenti comandi : #./configure --prefix=/usr --sysconfdir=/etc/apache \ --enable-mods-shared=all --with-ssl --with-perl # make # make install root@aspinazzo:/# httpd -version Server version: Apache/ Server built: Aug :08:05 PHP Procuriamoci la versione e scompattiamola. Compiliamo ed installiamo con la seguente procedura: #./configure --prefix=/usr --with-apxs2 \ --enable-cli --with-config-file-path=/etc/apache/php.ini \ --enable-magic-quotes --with-openssl --with-zlib \ --enable-bcmath --with-bz2 --enable-calendar --with-jpeg \ --with-tiff --enable-exif --enable-ftp --with-gd --with-gmp \ --with-gettext --with-mysql --with-mysql-sock=/var/.../mysql.sock \ --with-ncurses --enable-shmop --enable-sockets --enable-sysvmsg \ --enable-sysvsem --enable--sysvshm --enable-zend-multibyte --withpear \ --enable-trans-sid # make # make install

12 Aggiungiamo le seguenti stringhe in httpd.conf LoadModule php4_module modules/libphp4.so AddType application/x-httpd-php.php.php3 AddType application/x-httpd-php-source.phps Dovremmo aver finito, ora riavviamo apache : # apachectl restart Creiamo un database e proviamo l'interazione tra php e mysql. # mysqladmin -u root create testdb -p (testdb è il db che useremo per per eseguire i test) Editiamo una pagina di test per provare il tutto: // test.php <? # Apertura connessione verso mysql $tmp_socket=mysql_connect("localhost", "user", "prova") or die("impossibile connettere a mysql: ".mysql_error()); echo '> Apertura del database effettuata.<br>'; # Seleziono il database di test mysql_selectdb("testdb"); echo '> Database \'testdb\' selezionato.<br>'; # Creo un record nella mia tabella di test $sql = "INSERT INTO testtb(testfield) VALUES('test')"; $result = mysql_query($sql); if (!$result) { die('impossibile aggiungere record alla tabella<br>'); } else { echo '> Record inserito con successo.<br>'; } # Recupero il record appena inserito $sql = "SELECT idkey, testfield FROM testtb"; $result = mysql_query($sql); if (!$result) { die('impossibile leggere record dalla tabella<br>'); } else { $record = mysql_fetch_array($result); echo '> Il valore contenuto nella tabella per il record con idkey '.$record['idkey'].' e` <'.$record['testfield'].

13 '><br>'; } # Elimino il record creato e chiudo la connessione a mysql $sql = "DELETE FROM testtb"; $result = mysql_query($sql); if (!$result) { die('impossibile cancellare record dalla tabella<br>'); } else { echo '> Record cancellato con successo.<br>'; } mysql_close($tmp_socket); echo '> Connessione con il database chiusa.<br>';?> // EOF Eseguiamo la pagina per verificare il corretto funzionamento: #lynx /test.php > Apertura del database effettuata. > Database 'testdb' selezionato. > Record inserito con successo. > Il valore contenuto nella tabella per il record con idkey 15 e` <test> > Record cancellato con successo. > Connessione con il database chiusa. Apache, MySQL e PHP sono correttamente installati e possiamo passare all'installazione di PostgreSQL. PostgreSQL PostgreSQL e` un RDBMS e fornisce il maggior supporto agli standard ANSI SQL per quanto riguarda il software opensource ma e` leggermente piu` difficile da gestire di MySQL. Ci sono essenzialmente due modi per installare PostgreSQL: utilizzare i binari o compilare il sorgente. Entrambi le soluzioni possono essere trovate su o nel sito della propria distribuzione Linux. Installare i binari e` molto semplice e puo` essere fatto con i tools della propria distribuzione. In questo articolo parleremo della compilazione dei sorgenti di PostgreSQL. Il primo passo da effettuare e` quello di creare un utente per il database, che noi chiameremo postgres, al quale assegneremo il gruppo postgres e la home directory /usr/local/pgsql. L'installazione di PostgreSQL e` stata effettuata su una macchina

14 Linux Slackware. Copiamo il tarball dei sorgenti postgresql tar.gz in /tmp e scompattiamolo con il comando tar: tar xzvf postgresql tar.gz Abbiamo ottenuto una nuova cartella contenente i sorgenti di PostgreSQL. Spostiamoci all'interno della cartella con: cd postgresql-7.3.4/src e cominciamo a configurare il Makefile per il nostro sistema:./configure Continuiamo la compilazione con: make Se tutto va per il meglio l'ultima riga restituita dal sistema dovrebbe essere All of PostgreSQL is successfully made. Ready to install. Prima di procedere all'installazione cambiamo il nostro utente nel nostro utente postgres con su postgres e diamo il via all'installazione make install Se ci dovessero essere problemi effettuando l'installazione dall'utente postgres, e` necessario provare utilizzando il superuser root e poi cambiare il possessore dei file con il comando chown in questo modo: cd /usr/local chown -R postgres.postgres pgsql Abbiamo bisogno di informare il sistema che le librerie di pgsql sono installate. Aggiorniamo il file /etc/ld.so.conf aggiungendo la riga /usr/local/pgsql/lib e lanciando il comando /sbin/ldconfig Abbiamo quasi terminato. Dobbiamo impostare il database iniziale di PostgreSQL. Come utente postgres lanciamo il comando: /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data Facciamo partire postgres utilizzando il seguente script: su -c '/usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data >> /usr/local/pgsql/logs/server.log 2>&1' postgres & Abbiamo appena terminato l'installazione di PostgreSQL, non ci resta che configurare i file di configurazione che troverete nella directory /usr/local/pgsql/data/. Apriamo il file postgresql.conf con un editor di testo e settiamo la seguente opzione a true: tcpip_socket = true

15

16 Configurare Windows 2000 o XP Professional Come tutti gli applicativi sotto Microsoft Windows l'installazione del server web richiede poco tempo e pochi click. Si rivela quindi alla portata di tutti. La prima cosa da fare e` l'apertura del Pannello di Controllo e la selezione dell'icona Installazione Applicazioni. Una volta aperta la finestra di dialogo dobbiamo selezionare Aggiungi componenti di Windows ed aggiungere Internet Information Services (IIS) come da figura: Vi verra` richiesto il cd di installazione e terminata la procedura il software sara` installato sul vostro disco fisso. Procediamo ad una piccola configurazione tornando nel Pannello di Controllo, aprendo Strumenti di Amministrazione e cliccando su Internet Information Services. Apparira` la finestra in figura:

17 Apriamo il menu della figura cliccando con il tasto destro su Sito Web Predefinito e selezioniamo Proprieta` dal menu a scomparsa: apparira` la seguente finestra di dialogo. Configuriamo la home directory impostando il Percorso Locale attualmente impostato su c:\inetpub\wwwroot

18 Esempi di codice vulnerabile PHP e PostgreSQL Per i nostri test avremo bisogno di un database dove inserire le nostre tabelle. Per fare cio` logghiamoci nel sistema come utente postgres: su postgres e utilizziamo il comando: createdb nomedatabase Per le nostre prove chiamaremo il database testdb Se non l'abbiamo gia` fatto e` bene crearsi un utente per lavorare al database senza loggarsi come postgres. Io ho utilizzato il mio stesso nomeutente in modo da non usare flag durante la connessione al database da console. Il comando da utilizzare e`: createuser nomeutente Ora abbiamo accesso al server DBMS. Entriamo con le credenziali dell'utente appena creato e interfacciamoci al database test digitando il comando: psql testdb Abbiamo appena cominciato una sessione di comunicazione con il database test contenuto nel server PostgreSQL. Il nostro nuovo utente puo` tranquillamente entrare da locale ma non puo` entrare da una connessione esterna. Abbiamo quindi la necessita` di modificare il file di configurazione pg_hba.conf situato nella directory 'data' di pgsql. Io ho inserito le seguenti righe di configurazione che vanno bene per un server locale monoutente ma certo non per un server remoto. local all all password utenti host all all password utenti host all all password utenti Queste regole impostano Postgres in modo da richiede una password per l'accesso e, dopo tale autentificazione, il DBMS non ci dara` limitazioni se non quelle impostate al momento della creazione dell'utente. La dicitura password utenti dice a postgres di richiedere una password, imagazzinata in un file chiamato 'utenti' nella directory 'data' della home del server. Tale file ha la seguente struttura: nomeutente:passwordinchiaro Le password sono in chiaro quindi solo postgres deve poterci accedere.

19 Durante le nostre prove avremo bisogno essenziamente di due tabelle, create ad hoc per focalizzare l'attenzione sulla problematica, e alcuni dati fittizi. Creiamo la prima tabella nominativi tramite console: CREATE TABLE nominativi (nome VARCHAR(30), cognome VARCHAR(50)); ed inseriamo i seguenti dati: INSERT INTO nominativi (nome, cognome) VALUES ('mario', 'bianchi'); INSERT INTO nominativi (nome, cognome) VALUES ('giacomo', 'rossi'); INSERT INTO nominativi (nome, cognome) VALUES ('beppe', 'verdi'); INSERT INTO nominativi (nome, cognome) VALUES ('maria', 'bianchi'); Creiamo una seconda tabella lavoro : CREATE TABLE lavoro (ruolo VARCHAR(30), specializzazione VARCHAR(50)); ed inseriamo i dati: INSERT INTO lavoro (ruolo, specializzazione) VALUES ('ingegnere', 'supervisione'); INSERT INTO lavoro (ruolo, specializzazione) VALUES ('informatico', 'programmatore'); INSERT INTO lavoro (ruolo, specializzazione) VALUES ('manager', 'organizzazione'); INSERT INTO lavoro (ruolo, specializzazione) VALUES ('perito', 'tecnico'); Ora siamo pronti a lavorare lato scripting per mostrare la pericolosita` delle SQL Injection. Prepariamo due pagine: index.html e sql.php index.html contiene il seguente codice html: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN " <html> <head> <title>sql Injection</title> <meta http-equiv="content-type" content="text/html; charset=utf- 8"> </head> <body> <form action="sql.php" method="post"> <input type="text" name="query"><input type="submit"> </form>

20 </body> </html> sql.php contiene il seguente codice php: <? $conn = pg_connect('dbname=testdb user=utente password=password'); $text = ''; if (get_magic_quotes_gpc() == 1) { // GPC attivate $text = stripslashes($_post['query']); } else { $text = $_POST['query']; } $query = pg_query($conn, 'SELECT * FROM nominativi WHERE nome=\''.$text.'\''); while ($row = pg_fetch_array($query)) { print $row['nome'].' '.$row['cognome']."<br>\n"; } pg_free_result($query); pg_close($conn);?> Il codice php e` stato strutturato il modo tale da funzionare su qualsiasi tipo di php, con e senza magic quotes. Se noi apriamo con un browser index.html ed inseriamo uno dei nomi che abbiamo precedentemente inserito (ad esempio 'mario') otteniamo la voce contenente il suo nome e il suo cognome come ci aspettiamo ma proviamo ad inserire un apice ('): Warning: pg_query() query failed: ERROR: parser: unterminated quoted string at or near "'''" at character 37 in / home/apache/www/sql/sql.php on line 12 Warning: pg_fetch_array(): supplied argument is not a valid PostgreSQL result resource in /home/apache/www/sql/sql.php on line 13 Warning: pg_free_result(): supplied argument is not a valid PostgreSQL result resource in /home/apache/www/sql/sql.php on line 16 Come era nostra intenzione mostrare, il codice e` vulnerabile. Questa enorme falla permette l'esecuzione di query arbitrarie al nostro database e a tutti i database ai quali abbiamo accesso. Abbiamo volutamente inserito due tabelle nel database per fare le prove con lo statement UNION. La sintassi UNION ci permette di unire piu` query SELECT in una e in questo caso puo` essere utilizzata per visualizzare dati ai quali non avremmo accesso. Il nostro scopo e` quello di evitare la visualizzazione dei dati