Imerio Moretti ‐Matr. 738932Relatore: Prof. Paolo CeravoloCorrelatore: Prof. Stelvio CimatoCorso di laurea in Sicurezza Sistemi e Reti Informatiche – corso onlineA.A. 2010 – 2011

PROPOSTA #1 - WEB APPLICATION SERVER SIDE

1. Il “motore” dell’applicativo è tutto su server;2. i client vi accedono tramite browser  e connessione internet. 

PROPOSTA #2 - WEB APPLICATION CLIENT/SERVER SIDE

1. Il “motore” dell’applicativo si trova su client e su server ;2. ogni client è dotato di un proprio applicativo autonomo “motore client”. Può 

salvare su una base dati esterna i propri dati “motore server”.

ARCHITETTURE

PROPOSTE

PROPOSTA #3 – MEDIAZIONE TRA LE DUE PRECEDENTI ARCHITETTURE

1. Della prima architettura si tiene la portabilità di un applicazione Web gestibile inambito server da qualsiasi host in grado di connettersi ad Internet ;

2. per venire incontro alla seconda architettura si decide di dare la possibilità discaricare in locale, in formato XML, i propri dati criptati salvati su server e tramitesemplici pagine HTML coadiuvate da funzioni JavaScript dar la possibilitàall'utente di avere sempre con sé in locale il suo archivio di password consultabileindipendentemente dalla connettività Internet.

ARCHITETTURE

PROPOSTE

VANTAGGI1. si ha un'applicazione indipendente dall’host. Basta un client dotato di browser e 

connessione internet;2. i dati si trovano sul server quindi indipendentemente dall’host che potrebbe 

rompersi, perdersi, essere rubato rimarrebbero sempre a nostra disposizione con un host sostitutivo anche se improvvisato;

3. una volta scaricati i dati in locale nessun client è costretto ad avere una connessione Internet per accedere ai propri dati.

SVANTAGGI1. i dati potrebbero trovarsi unicamente su server. In tal caso se non avessimo a 

disposizione un accesso a internet, saremmo impossibilitati ad accedere ai nostri dati;

2. i nostri dati sensibili verrebbero archiviati su di un sistema indipendente dal nostro controllo. È necessario un rapporto di fiducia nei confronti dei gestori del servizio;

3. la sicurezza dei nostri dati dipende dalle vulnerabilità del server che li ospita .

ARCHITETTURE

PROPOSTE

XHTML CSS XML JAVASCRIPT DOM AJAX PHP WAMP

FUNZIONAMENTO

DEL

PROGRAMMA

FUNZIONAMENTO

DEL

PROGRAMMA

FUNZIONAMENTO

DEL

PROGRAMMA

FUNZIONAMENTO

DEL

PROGRAMMA

FUNZIONAMENTO

DEL

PROGRAMMA

FUNZIONAMENTO

DEL

PROGRAMMA

FUNZIONAMENTO

DEL

PROGRAMMA

FUNZIONAMENTO

DEL

PROGRAMMA

FUNZIONAMENTO

DEL

PROGRAMMA

FUNZIONAMENTO

DEL

PROGRAMMA

L'utente a questo punto dovrà solamente cliccare sul file “cliccare_qui.html” in modo da permettere al proprio dispositivo di aprire una finestra del browser che richiede la password di decrittatura

Una volta inserita la corretta password di decrittatura e cliccato su “decritta pw”, l'utente  dopo un messaggio  di elaborazione in corso…

… potrà vedere su schermo la relativa decrittatura dei dati presenti nell’XML crittografato.

Verranno implementate ulteriori gradi di sicurezza per 

esempio in fase di  registrazione sarà 

previsto un controllo a livello di immagini  

CAPTCHA  (Completely

Automated Public Turing test to tellComputers and HumansApart ).

Verrà previsto un servizio e‐mail che 

permetterà all’utente di: 1) confermare la propria volontà di 

registrarsi al servizio 2) modificare e gestire le proprie credenziali di login 3) rimanere 

aggiornato tramite una reportistica di log sulle 

modifiche/accessi effettuati con la sua credenziale alla base 

dati.

Verrà previsto un sistema di 

generazione di log atto a registrare i tentativi di login andati a buon fine 

e non riusciti.

Migliorie a livello di interazione con 

l’utente: 1) migliorie grafiche dell’applicativo 2) migliorie logiche  (per esempio 

evitando di salvare l’md5 nella base 

dati).

Migliorie sull’aspetto della portabilità lato 

client.