DOC - Sicurezza su reti 2

COMMESSA – G2ISP
TITOLO
Informatica Granata
DESCRIZIONE SINTETICA
Realizzazione del sito di e-commerce Informatica-granata.com per la vendita on-line di PC ed
hardware convenzionato con "UfficialePagatore"
GRUPPI
2 e 3 (entrambe ISP)
DESCRIZIONE
Il sito comprende alcune pagine esplicative, un catalogo navigabile e, per gli utenti registrati, il
listino prezzi, il carrello per la spesa e la possibilita' di acquisto on-line, tramite il sistema
implementato da "UfficialePagatore.com".
Per gli utenti che hanno effettuato almeno 10 acquisti e' previsto uno sconto del 20% sul prezzo di
listino.
SPECIFICHE
Si richiede l'implementazione del sito Informatica Granata e più precisamente:
1. Gestione anagrafica clienti
2. Gestione catalogo e listino (con apposito pannello amministratori)
3. Gestione utenti amministratori
4. Carrello della spesa
5. Interfaccia col sistema di pagamento U.P.
6. Si richiede la registrazione di almeno 30 utenti ed un catalogo di almeno 20 prodotti di
diversa prezzatura
SOLUZIONE PROPOSTA
La soluzione proposta segue lo schema previsto dal protocollo definito nello specifico documento;
il sito web di Informatica Granata utilizza il web server Apache ed il DBMS MySQL, mentre dal
punto di vista della sicurezza si ci è affidati ad OpenSSL.
Inizialmente la soluzione proposta prevedeva una suddivisione dei vari livelli dell’applicazione tra i
server dei gruppi 2 e 3; secondo tale decisione i livelli di presentazione e di logica dell’applicazione
avrebbero risieduto sulla macchina del gruppo 3 mentre il database sarebbe stato creato e mantenuto
sul nostro server, il server del gruppo 2.
Nella sezione Difficoltà Incontrate verranno presentati anche i motivi che hanno condotto alla
revisione delle scelte iniziali; nonostante i cambiamenti effettuati le scelte fondamentali e gli
approcci per la realizzazione dell’applicazione sono rimasti immutati.
In generale si è scelto di creare un sito web dinamico mediante PHP al fine di consentire
l’interazione con gli utenti/clienti del negozio e con l’applicazione preposta al pagamento degli
ordini eseguiti in maniera sicura.
L’interazione con l’utente avviene mediante form da compilare con l’indicazione di dati ed input
specifici per la richiesta di servizi; la soluzione proposta viene descritta in dettaglio nella
documentazione relativa e rispecchia ciò che è stato definito nel protocollo.
Presentiamo ora nel dettaglio il lavoro compiuto dal nostro gruppo.
LAVORO COMPIUTO
Il nostro gruppo si è occupato della creazione e della gestione del database “SHOP” fondamentale
per l’attività del sito Informatica Granata; ciò vuol dire che oltre alla definizione delle associazioni
e delle tabelle è stata fornita una serie di funzioni che i programmatori dell’applicazione hanno
utilizzato per implementare le funzionalità del Sistema.
Gli strumenti utilizzati per lo svolgimento del proprio incarico sono stati MYSQL e PHP.
Mysql 5.0.37 è il Database Management System installato in fase di setup della simulazione sulla
nostra macchina e scelto per i motivi indicati nel documento di riepilogo di tale fase.
Lo stesso vale per PHP, linguaggio di script server-side, scelto in quanto installato in fase di setup
ed utilizzato dal Gruppo 3 per l’implementazione delle funzionalità del sito Informatica Granata.
L’attività si è concretizzata nella creazione del succitato database e di un oggetto PHP,
MyDBManager caratterizzato da tutti i metodi necessari ai programmatori del Gruppo 3 per il loro
lavoro; in tal modo il nostro compito è stato quello di creare la struttura necessaria alla
memorizzazione dei dati e di fornire funzioni predefinite d’accesso a questi.
La scelta della creazione di quest’interfaccia è servita a separare in maniera molto netta la logica di
applicazione da quella di memorizzazione dei dati.
All’interno del gruppo, o meglio della coppia, l’organizzazione del lavoro è stata alquanto
orizzontale con una sommaria suddivisione dello stesso come segue:
 Creazione Database I. Barone
 Interazione Database D. Laurino
Come già detto, la separazione dei compiti è sommaria e non netta in quanto i due tipi di attività
hanno richiesto una costante interazione, una volta determinato in coppia il modello ER da
utilizzare.
L’interazione non ha banalmente interessato solo i componenti del gruppo ma ha coinvolto anche,
ed in maniera molto forte, i membri del Gruppo 3 A. Bruno, F. Di Perna e F. Granato.
La definizione del modello ER è derivata dal processo di raccolta dei requisiti; tale raccolta si è
basata sulla descrizione della commessa e soprattutto sulle richieste ed esigenze del gruppo
collaboratore.
Allo stesso modo le funzioni da fornire al Gruppo 3 sono state realizzate, e modificate in corso
d’opera, sulla base di quanto lo stesso gruppo ha ritenuto necessario al fine della realizzazione delle
funzionalità.
Il Database SHOP si compone di 5 tabelle:
1. Customers
2. Orders
: utilizzata per memorizzare le informazioni relative ai clienti di Informatica
Granata come Codice Fiscale, Nominativo, Indirizzo, Uname, Password e
l’indicazione dei privilegi di Amministratore
: contiene i dati caratteristici di ogni ordine effettuato, quali Codice, Cliente
3. Products
4. Prod_Ord
5. Tokens
che effettua l’ordine, il Totale, la Data in cui esso è stato effettuato e se esso
è stato confermato o è ancora sospeso
: sono presenti tutte le informazioni relative ai prodotti del negozio, il Codice,
il Nome, la Descrizione, il Prezzo, la Quantità presente in magazzino ed il
path del file che contiene la foto dell’oggetto
: è la tabella che nasce dall’associazione esistente tra il prodotto ordinato e
l’ordine in cui lo è stato; vengono indicati il Codice del Prodotto e
dell’Ordine e la quantità ordinata
: questa è la struttura che memorizza i token utilizzati dall’applicazione
Informatica Granata, con il riferimento al Codice ed al Contenuto
Vengono presentate di seguito le istruzioni SQL che hanno permesso la creazione del database
DROP TABLE IF EXISTS 'Customers';
CREATE TABLE 'Customers' (
'CF' varchar(16) NOT NULL,
'NAME' varchar(50) default NULL,
'ADDRESS' varchar(100) default NULL,
'UNAME' varchar(20) default NULL,
'PASSWORD' varchar(8000) default NULL,
'ADMINISTRATOR' enum('True','False') default 'False',
PRIMARY KEY ('CF')
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
DROP TABLE IF EXISTS 'Orders';
CREATE TABLE 'Orders' (
'COD_ORDER' int(11) NOT NULL auto_increment,
'CUSTOMER' varchar(16) default NULL,
'TOT_ORDER' double(12,2) default NULL,
'STATUS' enum('Suspended','Closed') default 'Suspended',
'DATE' datetime default NULL,
PRIMARY KEY ('COD_ORDER'),
KEY 'CUSTOMER' ('CUSTOMER')
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
DROP TABLE IF EXISTS 'Prod_Ord';
CREATE TABLE 'Prod_Ord' (
'PRODUCT' int(11) NOT NULL,
'COD_ORDER' int(11) NOT NULL,
'QTY' int(11) default NULL,
PRIMARY KEY ('PRODUCT','COD_ORDER'),
KEY 'COD_ORDER' ('COD_ORDER')
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
DROP TABLE IF EXISTS 'Products';
CREATE TABLE 'Products' (
'COD_PROD' int(11) NOT NULL auto_increment,
'NAME' varchar(50) default NULL,
'DESCRIPTION' varchar(8000) default NULL,
'PRICE' double(9,2) default NULL,
'QTY' int(11) default NULL,
'PHOTO' varchar(256) default NULL,
PRIMARY KEY ('COD_PROD')
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
DROP TABLE IF EXISTS 'Tokens';
CREATE TABLE 'Tokens' (
'ID' int(11) NOT NULL,
'TOKEN' text,
PRIMARY KEY ('ID')
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
Una volta concretizzata la definizione del modello ER si può passare alla descrizione
dell’interfaccia creata.
Si è scelto di realizzare un oggetto PHP, denominato MyDBManager, molto simile ad un classico
oggetto Java.
All’interno del costruttore viene gestita la connessione al database in modo che essa sia unica ed
utilizzabile per tutte le operazioni consentite; nell’applicazione, per poter accedere alle funzionalità
da noi fornite, i programmatori hanno dovuto istanziare un oggetto di tipo MyDBManager e poi
utilizzarlo invocandone i metodi.
L’oggetto in esame contiene funzionalità per:







Login di Utenti ed Amministratori
Gestione Utenti con modifiche dati
Elenco Utenti e Dati Utente Specifico
Gestione Prodotti con modifiche dati
Catalogo Prodotti e Dati Prodotto Specifico
Gestione ed Elenco Ordini e Prodotti Ordinati
Gestione di Timeout e Conferma Ordini
Dal punto di vista della sicurezza ci sono tre aspetti fondamentali che sono stati trattati.
Innanzitutto è stata valutata le possibilità di collocazione del database all’interno del Sistema; la
scelta era tra il server del nostro gruppo oppure quello del Gruppo 3.
E’ stata scelta la prima opzione; questo ha comportato una misura di sicurezza da noi considerata
necessaria, ovvero la connessione sicura al db utilizzando il parametro che consente di sfruttare
SSL. Questa accortezza serve per evitare che le query eseguite sul database viaggino in chiaro sulla
rete dal momento che i metodi vengono invocati sul server del Gruppo 3 ma i dati sono sulla nostra
macchina.
Il secondo aspetto riguarda l’implementazione dell’oggetto MyDBManager al fine di evitare che
l’applicazione risulti vulnerabile ad attacchi di SQL Injection. Come è possibile notare nel codice
sorgente, per ogni metodo dell’oggetto, sono state utilizzate le due funzioni predefinite PHP
addslashes e stripslashes con le quali aggiungere e rimuovere alle/dalle stringhe da gestire tutti gli
slash necessari per l’inserimento ed il reperimento nel/dal database dei caratteri speciali.
PHP fornisce tali metodi al fine di consentire agli sviluppatori la difesa delle proprie applicazioni
dall’injection senza implementare funzioni proprie che potrebbero contenere errori o non
considerare ogni caso possibile.
Il terzo aspetto ed ultimo aspetto riguarda la gestione e considerazione delle operazioni sul database
quali transazioni ovvero unità atomiche di elaborazione; si presuppone che tutte le operazioni che
costituiscono una transazione vengano eseguite in isolamento da altre transazioni.
Anche se a prima vista tale approccio sembra non riguardare la sicurezza dell’applicazione, invece
esso si rivela importante in quanto contribuisce all’efficienza del Sistema e permette di limitare o
evitare addirittura possibili danni dovuti ad attacchi DoS, Denial of Service.
Le modifiche di eventuali query sul database vengono memorizzate e diventano effettive solo
quando viene eseguito il “commit” della transazione, ovvero quando questa viene confermata in
quanto correttamente terminata; in caso di abort nessun dato viene modificato nel database.
Per indicare inizio e fine di una transazione, l’oggetto PHP utilizza due metodi privati che vengono
invocati dalle funzionalità che modificano il database; ognuna delle caratteristiche dell’oggetto
creato per fornire i servizi richiesti può essere reperita nel codice sorgente allegato alla
documentazione del lavoro del gruppo e dell’intera commessa.
La gestione degli aspetti di sicurezza succitati riguarda unicamente il lavoro del nostro gruppo e
quindi non sono esclusi interventi ed ulteriori politiche di sicurezza da parte degli altri gruppi che
lavorano al progetto e che verranno eventualmente descritti nella documentazione finale della
commessa o dell’intera simulazione del singolo gruppo.
DIFFICOLTA’ INCONTRATE
Nell’ambito dello sviluppo dell’applicazione e nelle fasi di creazione del database e dell’interfaccia
per accedervi sono state diverse le difficoltà incontrate.
La più importante ha riguardato l’utilizzo del Secure Socket Layer (SSL) nella comunicazione tra il
server dove risiedeva il sito web (gruppo 3) ed il nostro host sul quale avevamo creato il database
SHOP; avendo optato per la separazione dei livelli del Sistema è stato definito prioritario avere una
comunicazione sicura tra i nodi dello stesso.
L’esecuzione di ogni query sul DB avviene a cavallo della rete e quindi si è scelto di non far
viaggiare in chiaro i dati relativi a tali operazioni. Per fare ciò, inizialmente la connessione al
database veniva effettuata con il parametro MYSQL_SSL_CLIENT sfruttando la funzione PHP
mysql_connect.
Tale funzione viene tuttora invocata un’unica volta nel costruttore dell’oggetto MyDBManager, al
fine di averne l’esecuzione all’atto dell’istanziazione dello stesso e di poterla utilizzare per ogni
richiesta dell’applicazione.
L’indicazione del parametro per l’utilizzo di SSL permette la connessione sicura al DB e la cifratura
di ogni query eseguita sullo stesso. Purtroppo quello che era stato ipotizzato non si è verificato e
non si è riusciti in alcun modo, nonostante ripetuti ed estenuanti tentativi, a far interagire i due nodi
in maniera sicura nonostante si utilizzassero certificati validi.
La soluzione è stata quella di spostare il database sul server del gruppo 2 rinunciando all’utilizzo
della connessione sicura mediante il parametro sopra citato e velocizzando anche i tempi di risposta
per i servizi dal momento che le query vengono eseguite in locale.
Le altre difficoltà sono state di minore importanza ed hanno riguardato la definizione dello schema
relazionale da adottare in termini di consistenza, efficienza e di quelle che erano le richieste dei
componenti del gruppo 2.
L’ultima difficoltà è stata quella relativa alla gestione delle transazioni SQL, con il reperimento online delle operazioni necessarie per la loro implementazione; la soluzione stata trovata grazie
all’analisi di alcuni esempi presenti in rete e che prevedevano l’esecuzione di particolari query sul
database come LOCK TABLE … WRITE, START TRANSACTION e COMMIT con le quali
bloccare in scrittura le tabelle, cominciare una transazione ed indicare la riuscita esecuzione della
stessa. L’utilizzo di tali query è stato racchiuso in due metodi privati con lo scopo di fare tutto il
necessario per dare inizio e terminare una transazione.