Docsity
Docsity

Prepara i tuoi esami
Prepara i tuoi esami

Studia grazie alle numerose risorse presenti su Docsity


Ottieni i punti per scaricare
Ottieni i punti per scaricare

Guadagna punti aiutando altri studenti oppure acquistali con un piano Premium


Guide e consigli
Guide e consigli


Analisi della Sicurezza Web: Protocolli, Vulnerabilità e Contromisure - Prof. Armando, Appunti di Sicurezza Dei Sistemi Informativi

Un'analisi dettagliata della sicurezza web, esaminando i protocolli http, le vulnerabilità comuni come sql injection e cross-site scripting (xss), e le contromisure per proteggere le applicazioni web. Vengono discussi concetti chiave come la same origin policy, l'autenticazione http e la gestione delle sessioni, offrendo una panoramica completa delle sfide e delle soluzioni nel campo della sicurezza web. Il documento evidenzia l'importanza della validazione degli input, della sanificazione degli output e dell'adozione di pratiche di sviluppo sicure per prevenire attacchi e proteggere i dati degli utenti. Inoltre, vengono presentate le architetture a tre livelli delle applicazioni web moderne e le implicazioni di sicurezza dei metodi get e post.

Tipologia: Appunti

2025/2026

In vendita dal 23/10/2025

tezcat96
tezcat96 🇮🇹

9 documenti

1 / 5

Toggle sidebar

Questa pagina non è visibile nell’anteprima

Non perderti parti importanti!

bg1
Analisi della Sicurezza Web
La Web Security non è un campo definito in modo rigoroso come la ricurezza
crittografica. La sua natura è quella di “bersaglio mobile”, poiché non esiste una
soluzione definitiva e permanente. La sicurezza pratica delle applicazioni web dipende
da una complessa interazione di fattori, tra cui:
Dettagli standard di rete;
Specifiche di implementazione;
Versioni concrete di browser e server.
Fondamenti del protocollo http
L’Hyper Text Protocol (http) è il protocollo a livello applicativo che gestisce il
trasferimento di richieste ed informazioni ipertestuali tra client (il browser) ed il server.
Architettura Client-Server: Il client (utente) avvia sempre la comunicazione,
navigando tramite URL e inviando richieste. Il server risponde consegnando i
dati richiesti;
Protocollo stateless: http è intirinsecamente “stateless”, ovvero non
mantiene memoria delle sessioni o delle richieste precedenti;
Metodi HTTP: I metodi principali per le richieste sono GET (richieste di una
pagina) e POST (invio di dati con un “playload”, o corpo della richiesta);
Contenuto statico vs contenuto dinamico: Il server può fornire dati statici
(pagine HTML, immagini) oppure dinamici, ovvero calcolati su richiesta da
un’applicazione web. Questo calcolo può avvenire:
oServer-Side: Tramite script come Perl, ASP, JSP,
oClient-Side: Tramite script eseguiti nel browser, come JavaScript, Flash o
Applet.
Architettura a tre livelli (three-tier): Le applicazioni web moderne seguono
spesso un’architettura a tre livelli: Presentation (1st tier) (il client/browser),
Business Logic (2nd tier) (il web server/application server) e Backend (3rd
tier) (tipicamente i database).
GET vs POST
Sebbene entrambi i metodi inviino dati, la loro gestione ha implicazioni di sicurezza
critiche:
GET: i dati vengono accodati all’URL (es. ...?name=blah&type=1). Questo
espone informazioni sensibili:
oNei log del web server e dei proxy;
oNell’header HTTP Referer (quando si clicca un link verso un altro sito);
oNei segnalibri (bookmarks) e nella cronologia, che possono essere
facilmente condivisi.
POST: I dati vengono inseriti nel corpo della richiesta HTTP, non nell’URL.
Per il trasporto di dati sensibili, è imperativo utilizzare HTTPS (http su SSL/TLS) e il
metodo POST.
pf3
pf4
pf5

Anteprima parziale del testo

Scarica Analisi della Sicurezza Web: Protocolli, Vulnerabilità e Contromisure - Prof. Armando e più Appunti in PDF di Sicurezza Dei Sistemi Informativi solo su Docsity!

Analisi della Sicurezza Web

La Web Security non è un campo definito in modo rigoroso come la ricurezza crittografica. La sua natura è quella di “bersaglio mobile”, poiché non esiste una soluzione definitiva e permanente. La sicurezza pratica delle applicazioni web dipende da una complessa interazione di fattori, tra cui:  Dettagli standard di rete;  Specifiche di implementazione;  Versioni concrete di browser e server.

Fondamenti del protocollo http

L’ Hyper Text Protocol (http) è il protocollo a livello applicativo che gestisce il trasferimento di richieste ed informazioni ipertestuali tra client (il browser) ed il server.  Architettura Client-Server: Il client (utente) avvia sempre la comunicazione, navigando tramite URL e inviando richieste. Il server risponde consegnando i dati richiesti;  Protocollo stateless: http è intirinsecamente “stateless”, ovvero non mantiene memoria delle sessioni o delle richieste precedenti;  Metodi HTTP: I metodi principali per le richieste sono GET (richieste di una pagina) e POST (invio di dati con un “playload”, o corpo della richiesta);  Contenuto statico vs contenuto dinamico: Il server può fornire dati statici (pagine HTML, immagini) oppure dinamici, ovvero calcolati su richiesta da un’applicazione web. Questo calcolo può avvenire: o Server-Side: Tramite script come Perl, ASP, JSP, o Client-Side: Tramite script eseguiti nel browser, come JavaScript, Flash o Applet.  Architettura a tre livelli (three-tier): Le applicazioni web moderne seguono spesso un’architettura a tre livelli: Presentation (1st tier) (il client/browser), Business Logic (2nd tier) (il web server/application server) e Backend (3rd tier) (tipicamente i database). GET vs POST Sebbene entrambi i metodi inviino dati, la loro gestione ha implicazioni di sicurezza critiche:  GET: i dati vengono accodati all’URL (es. ...?name=blah&type=1). Questo espone informazioni sensibili: o Nei log del web server e dei proxy; o Nell’header HTTP Referer (quando si clicca un link verso un altro sito); o Nei segnalibri (bookmarks) e nella cronologia, che possono essere facilmente condivisi.  POST: I dati vengono inseriti nel corpo della richiesta HTTP, non nell’URL. Per il trasporto di dati sensibili, è imperativo utilizzare HTTPS (http su SSL/TLS) e il metodo POST.

Sicurezza lato client

Ad ogni richiesta il client invia degli header HTTP. Se si usa HTTP, questi header sono trasmessi in chiaro con HTTPS invece sono cifrati. Essi contengono informazioni come il tipo di browser, la lingua e i cookie. Alcuni header possono contenere informazioni private che minacciano la privacy:  FROM: L’indirizzo e-mail dell’utente;  AUTHORIZATION: Contiene le credenziali di autenticazione.  COOKIE: Dati inviati dal server per la gestione della sessione;  REFERER: La pagina di provenienza, che può includere termini di ricerca sensibili. Cookies I cookie sono stati introdotti per permettere la gestione delle sessioni (session management) su un protocollo stateless come HTTP. Il server invia un cookie nella sua risposta; il client lo memorizza e lo invia automaticamente nelle richieste successive verso lo stesso server. Sebbene utili, i cookie sono la principale fonte di preoccupazione per la privacy, poiché possono essere usati per tracciare il comportamento degli utenti online. Per questo motivo, i cookie devono essere considerati informazioni confidenziali. Autenticazione http HTTP supporta due modalità di autenticazione:

  1. Basic Authentication: Un semplice schema basato su login e password. È ampiamente supportato ma estremamente insicuro: le credenziali sono inviate in chiaro (spesso codificate in Base64, ma non cifrate) ad ogni singola richiesta.
  2. Digest Authentication: Un meccanismo di challenge-response. Il server invia un “nonce” (valore casuale) e il client risponde con un hash crittografico basato su password e nonce. È raramente utilizzato. JavaScript e Same Origin Policy JavaScript è il linguaggio di scripting più popolare, progettato per aggiungere interattività alle pagine HTML. Viene eseguito in una sandbox (un ambiente controllato) all’interno del browser, che (in teoria) gli impedisce di accedere al file system locale o alla memoria di altri programmi. La politica di sicurezza fondamentale per JavaScript è la Same Origin Policy (SOP).Principio: Uno script può accedere ai documenti (DOM) scaricati dalla stessa “origine” da cui proviene lo script stesso;  Definizione di Origine: Un’origine è definita dalla tripla (scheme, host, port), ovvero protocollo (es. http), nome host (es. www.unige.it) e porta (es. 80).  Scopo: La SOP impedisce a uno script ostile (es. www.attacker.com) di leggere dati sensibili (es. password) o di manipolare pagine aperte in altre finestre provenienti da un sito legittimo (es. www.mybank.com).
  1. L’attaccante crea un link malevolo che inietta codice JavaScript nel parametro: .../welcome.php?name=
  2. L’attaccante inganna una vittima (tramite email, phishing) affinche faccia clic su quel link.
  3. Il browser della vittima invia la richiesta al sito vulnerabile;
  4. Il sito vulnerabile risponde con una pagina HTML che contiene lo script dell’attaccante: ...Hi ...
  5. Il browser della vittima esegue lo script perché proviene da un’origine fidata (www.vulnerable.site), rispettando la Same Origin Policy.  Impatto: Invece di un semplice alert, uno script malevolo può rubare il cookie di sessione della vittima (document.cookie) e inviarlo al server dell’attaccante, permettendo il furto completo della sessione.

Cross-Site Request Forgery (CSRF)

Un attacco CSRF si verifica quando un sito web malevolo induce il browser di un utente a eseguire un’azione indesiderata su un sito fidato per il quale l’utente attualmente autenticato. (Es. l’utente è loggato sulla sua banca e visita un sito malevolo che, a sua insaputa, invia una richiesta di bonifico alla banca)  Prevenzione (Synchronizer Token Pattern): è la difesa più comune.

  1. Per ogni sessione utente, l’applicazione genera un token (un valore casuale e segreto);
  2. Questo token viene inserito in tutti i form e i link che eseguono operazioni sensibili;
  3. Quando l’utente invia il frm, il server deve verificare che il token inviato corrisponda a quello memorizzato per la sessione;
  4. L’attaccante può conoscere questo token. Quindi qualsiasi richiesta forgiata ne sarà priva e verrà rigettata.

Clickjacking (UI Redressing)

Una tecnica malevola che inganna un utente facendogli cliccare su qualcosa di diverso da ciò che crede di cliccare. Comunemente, questo avviene caricando il sito bersaglio (es. la pagina “elimina account”) all’interno di un trasparente, posizionato sopra un’interfaccia apparentemente innocua (es. un pulsante “vinci un premio”)  Prevenzione: Utilizzare l’header http X-Frame-Options per comunicare al browser se la pagina può essere inserita in un frame o meno (es. DENY per impedirlo totalmente, SAMEORIGIN per permetterlo solo dallo stesso sito).

Broken Authentication and Session Management

Poiché HTTP è stateless, le applicazioni web devono gestire le sessioni manualmente. Questo avviene memorizzando i dati della sessione sul server e associandoli a un Session ID univoco, che viene inviato al client (tramite cookie, URL o campi nascosti) e restituiti ad ogni richiesta. I cookie sono il metodo preferibile.  Attacchi alla Sessione: Mirano a rubare il Session ID tramite:

  1. Intercettazione: Sniffing della rete;
  2. Predizione/Brute Force: Indovinare l’ID se non è sufficientemente casuale.  Prevenzione:
  1. Contro l’intercettazione: Usare SSL/HTTPS per tutte le richieste che trasportano il Session ID, non solo per il login. L’header Strict-Transport- Security può essere usato per imporre questa politica al browser.
  2. Contro la predizione: Generare Session ID utilizzando numeri casuali crittograficamente sicuri. Conclusioni La maggior parte degli attacchi riusciti oggi non sfrutta debolezze crittografiche, ma piuttosto errori di programmazione e configurazione. La sicurezza di un sistema è determinato dal suo anello più debole.  Progettazione (Design): o Mantenere il design semplice; o Non fare affidamento sulla “security by obscurity”; o Applicare il principio del minimo privilegio.  Implementazione: o Validare tutti gli input e output; o Non fidarsi MAI della validazione lato client. o Testare il sistema, anche utilizzando strumenti di attacco.  Gestione: o Utilizzare firewall a livello applicativo; o Implementare sistemi di intrusion detection; o Mantenere i sistemi costantemente aggiornati.