1 / 31

Gruppo ISP1

Gruppo ISP1. Commessa tuttipunti.org. Sommario. Descrizione commessa Organizzazione del lavoro Lavoro svolto Problematiche di sicurezza Impostazioni di sicurezza del web server Conclusioni. Descrizione commessa.

barny
Download Presentation

Gruppo ISP1

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Gruppo ISP1 Commessa tuttipunti.org

  2. Sommario • Descrizione commessa • Organizzazione del lavoro • Lavoro svolto • Problematiche di sicurezza • Impostazioni di sicurezza del web server • Conclusioni

  3. Descrizione commessa • Realizzazione del sito "www.tuttipunti.org" che implementi uno sportello per lo scambio di punti premio di un insieme di prodotti. • Il sito in accordo ad una breve descrizione dei requisiti formulata dall’utente permette l’accesso agli stessi a due diverse sezioni:portafoglio e scambia

  4. Descrizione commessa • Nella sezione portafoglio è possibile inserire le proprie disponibilità unitamente alle proprie richieste di punti. • Nella sezione scambia è visualizzabile l’elenco delle disponibilità inserite dagli utenti nel sito.

  5. Organizzazione del lavoro • Sono stati individuati quattro task fondamentali e sono state associate le risorse ad ogni task. • Si è cercato di ottimizzare la suddivisione dei task per rispondere in maniera più efficiente alle possibili problematiche di sicurezza riscontrabili nella gestione di siti web

  6. Organizzazione del lavoro

  7. Organizzazione del lavoro • In input alla prima fase arriva la richiesta del cliente, output di questa fase è una descrizione informale dei requisiti dell’applicazione • In seguito sono partite in parallelo le fasi di sviluppo e di analisi delle problematiche di sicurezza. • Lo sviluppo prevede la codifica dell’applicazione web

  8. Organizzazione del lavoro • L’analisi delle problematiche di sicurezza è partita dall’analisi dell’ applicazione commissionata fino ad arrivare allo studio delle principali metodologie di attacco e i relativi approcci di difesa. Sarà redatto un breve documento contenente frammenti di codice per contrastare le tipologie di attacco individuate. • Eseguendo in parallelo le attività di sviluppo e analisi problematiche di sicurezza, si è cercato di ottimizzare i tempi. Bisogna considerare infatti che le nozioni relative allo sviluppo web erano gia acquisite, mente un approccio organizzato alla sicurezza non era mai stato considerato in passato

  9. Organizzazione del lavoro • Ultima attività prima del rilascio è quella del testing. Inizialmente gli sviluppatori hanno concentrato la loro attenzione sul testing funzionale dell’applicazione. • Fatto questo si è passato ad una fase di testing sulle caratteristiche di sicurezza.

  10. Organizzazione del lavoro • Realizzato il documento relativo alle problematiche di sicurezza, i responsabili di tale attività hanno verificato le risposte agli attacchi più comuni. • Ad ogni mancanza rilevata è conseguita una modifica al codice dell’applicazione. In tal modo si è cercato di rendere l’applicazione più sicura.

  11. Lavoro svolto • Di seguito saranno presentati gli screen shot principali relativi all’applicazione realizzata.

  12. Lavoro svolto

  13. Lavoro svolto

  14. Lavoro svolto

  15. Lavoro svolto

  16. Lavoro svolto

  17. Lavoro svolto

  18. Lavoro svolto

  19. Lavoro svolto

  20. Problematiche di sicurezza • Attacchi DOS un attacco DoS ha essenzialmente l’obiettivo di mettere fuori uso o negare un servizio agli utenti legittimi. • Sql Injection Questa tecnica prevede lo sfruttamento, attraverso stringhe ad-hoc inviate ad un web server,delle vulnerabilità specifiche dei database basati su sql

  21. Problematiche di sicurezza:DOS • Gli attacchi di tipo DOS possono essere evitati o quanto meno ridotti mantenendo aggiornato il sistema e adottando un opportuno firewall. Il sistema win 2003 è stato costantemente aggiornato. Diverso è il problema relativo all’utilizzo di un firewall.

  22. Problematiche di sicurezza:DOS • Firewall di tipo commerciale risultavano adatti a contrastare gli attacchi DOS ma non è stato possibile utilizzarli nella simulazione come da accordo. • Quindi con un semplice script è possibile produrre un tale tipo di attacco. :ciao start ping –l Datasize 192.168.0.3 goto ciao

  23. Problematiche di sicurezza:SQL Injection • Questo tipo di attacco può essere contrastato unicamente ponendo attenzione al codice degli script che accede al database. • Un tale tipo di attacco viene eseguito inserendo una stringa opportuna in input ad un campo di un form. Presentiamo in seguito un attacco ti questo tipo e le contromisure adottate

  24. Problematiche di sicurezza:SQL Injection • Supponiamo di riempire un campo di un form che esegue una ricerca. Inseriamo nel campo • ‘ or ‘1=1 • Il primo apice ha l’effetto di chiudere l’apice presente nel codice dello script. Il secondo rappresenta l’apice iniziale cui corrisponde l’apice finale presente nel codice della query sql.

  25. Problematiche di sicurezza:SQL Injection • Per evitare l’utilizzo di apici nel campi dei form, tali campi sono stai controllati in questo modo. • if(ctype_alnum($_POST[“campo1]) and ctype_alnum($_POST['campo'])){ • La funzione ctype_alnum permette di verificare se la stringa passata come parametro è composta solo da caratteri alfabetici o numeri. Nel caso in cui la stringa passata risulta essere del tipo descritto la funzione ritorna true, altrimenti restituisce false.

  26. Impostazioni di sicurezza del web server • Si è cercato di proteggere l’accesso ai file sensibili in due modi. Abbiamo utilizzato alcune direttive di Apache ed inoltre è stato utilizzato un file htaccess.

  27. Impostazioni di sicurezza del web server • Per prima cosa abbiamo modificato il file http.config di Apache inserendo direttive simili alla seguente • <Files ~ "^\nomefile.inc"> • Order allow,deny • Deny from all • Satisfy All • </Files>

  28. Impostazioni di sicurezza del web server • Altra modalità di protezione dei file in una directory del server è quella inerente l’utilizzo di file di tipo htaccess. • <IfModule mod_ssl.c> RewriteEngine On RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} • </IfModule> • <IfModule !mod_ssl.c> order allow,deny • </IfModule>

  29. Conclusioni • Non sono stati rilevati particolari problemi nello sviluppo del codice. • Per quanto riguarda gli attacchi DOS non sono stati sufficientemente testati i firewall open source disponibili, il sistema è quindi vulnerabile a questo tipo di attacchi. • Sono stati riscontrati problemi con http 1.0 con la diretiva virtualhost di Apache

  30. Conclusioni • Openssl req -new -out server.csr -keyout server.pem -config tuttipunti-ssl.cnf • Common Name nome DNS completo del virtual host • Attivare per il virtual host il motore SSL:<VirtualHost 192.168.0.3:443>SSLEngine OnSSLCertificateKeyFile /etc/apache/keys/server.keySSLCertificateFile /etc/apache/server.crt... altre direttive ... • Setting di alcuni parametri per PHP

  31. FINE

More Related