Sicurezza nei Web Service

Meccanismi di autenticazione

Oggigiorno i web service sono utilizzati sia per fornire l’accesso a risorse pubbliche, sia per l’accesso a risorse private. Nel secondo caso, il meccanismo di autenticazione deve garantire un adeguato livello si sicurezza.

Utente e password

Quando un client richiede l’accesso a un web service protetto da autenticazione, il server risponde con una challenge, ovvero una stringa casuale. Il client deve quindi calcolare l’hash della password concatenata alla challenge utilizzando un algoritmo di hashing, ad esempio MD5 o SHA-1. L’hash calcolato viene inviato insieme all’username nel campo Authorization della richiesta HTTP, utilizzando lo schema Basic Authentication. Il server verifica l’username e l’hash, e se corretti permette l’accesso alle risorse protette.

Token di accesso

L’autenticazione mediante token o API key prevede che il client invii una stringa chiamata token per poter accedere ai servizi. Normalmente, il token viene generato dal server previa l’autenticazione con altri meccanismi quali, ad esempio, utente e password. Il token inviato al client, verrà usato ad ogni successiva richiesta verso server.

Il token può essere creato utilizzando diversi algoritmi di crittografia e spesso ha una scadenza. In caso di scadenza, l’utente dovrà ottenere un nuovo token per accedere nuovamente ai servizi del web service.

Facendo riferimento alla figura a fianco, vediamo i passi che coinvolgono una sessione protetta mediante token.

  1. Inizialmente il client spedisce al server le proprie credenziali (username e password).
  2. Il server verifica, consultando un database, che le credenziali siano valide e genera il token.
  3. Il token generato viene anche associato all’utenza appena autenticata inserendolo nel database (questa servirà per le prossime richieste).
  4. Il server risponde al cliente inviando il token.

Successivamente (parte bassa della figura) la comunicazione tra cliente e server avviene servendosi del token.

  1. Il client manda, con ogni richiesta, il token che ha precedentemente ottenuto dal server.
  2. Il server verifica la validità del token (questo può richiedere un accesso al database).
  3. In caso di token valido, il server risponde al cliente fornendo la risorsa richiesta.

OAuth 2.0

L’autenticazione tramite OAuth 2.0 è un meccanismo di autorizzazione delegata. In pratica, l’utente concede l’autorizzazione ad un’applicazione di terze parti per accedere alle proprie risorse, senza dover condividere le credenziali di accesso.

Bisogna fare attenzione al fatto che in questo caso il web service è l’applicazione di terze parti che richiede risorse ad un server di autorizzazione (ad esempio Google o Facebook). L’utente deve, quindi, autenticarsi preso tale server (ad esempio Google), il quale fornirà al web service un token che indica:

  1. che l’utente è autenticato presso il server di autorizzazione (es. Google)
  2. la app terza (il web server) può accedere alle risorse (a ad un parte di esse) presente nel server di autorizzazione.

Le risorse che vengono richieste dal server di autorizzazione possono essere diverse, tipicamente queste comprendono: email, nome e cognome. Nel caso di servizi come Google, mediante OAuth 2.0 si può ottenere l’accesso alle cartelle di Google Drive, nel caso di Facebook, si può ottenere l’accesso ai contatti, …

Riferendoci alla figura a fianco, vediamo in dettaglio i passaggi coinvolti in un’autenticazione mediante OAuth.

  1. Il client del web service richiede un token di accesso all’OAuth Server,
  2. L’utente viene autenticato e…
  3. …decide le risorse che saranno accessibile da chi possiede il token.
  4. Il server OAuth genera un token che restituisce al client.
  5. Il client ora richiede l’accesso alla risorsa sul web service utilizzando il token appena ottenuto.
  6. Il web service verifica la validità del token…
  7. …che deve essere confermata dall’OAuth server.
  8. Infine, in caso di token validato, il web server restituisce la risorsa richiesta.
Importante

È importante notare come le credenziali di accesso al server OAuth sono spedite e gestite esclusivamente dall’OAuth server stesse. In altre parole, quando utilizzano Login con Google, le nostre credenziali vengono solo gestite da Google e non dal servizio terzo a cui vogliamo accedere. Questo potrà utilizzare unicamente il token di accesso fornito da Google.

Sicurezza per i Web Service

Oltre all’autenticazione, che permette un accesso selettivo alle risorse del web service, è necessario prevedere meccanismi di sicurezza che rendano sicuro l’accesso. Questi sono, tipicamente, i meccanismi utilizzati per rendere sicure connessioni di altri tipi. I principali metodi sono elencati di seguito.

  • Crittografia La crittografia permette di proteggere i dati scambiati tra il client e il server utilizzando algoritmi crittografici per oscurare le informazioni sensibili prima di trasmetterle. Le tecniche crittografiche sono alla base dei metodi di protezione HTTPS e dei certificati SSL/TLS.
  • HTTPS L’utilizzo del protocollo HTTPS prevede una connessione cifrata tra client e server. Ciò garantisce l’integrità dei dati scambiati, evitando che la comunicazione essere intercettate da “attori” non autorizzate.
  • Certificati SSL/TLS L’utilizzo di certificati SSL/TLS consiste nell’implementazione di un protocollo crittografico che garantisce l’integrità, la riservatezza e l’autenticità dei dati scambiati tra client e server. In particolare, i certificati SSL/TLS permettono di autenticare il server, proteggere la comunicazione mediante cifratura dei dati e garantire l’affidabilità della connessione.

Protezione da attacchi comuni

Infine va tenuta in considerazione la possibilità (ad oggi si doverebbe dire la certezza) che il sistema possa essere bersaglio di attacchi informatici. Gli attacchi possono essere di vario tipo e con scopi diversi, alcuni si limitano a rendere il servizio indisponibile (attacchi Denial of Service, DoS), altri mirano ad ottenere informazioni riservati (ad esempio password o risorse private). Di seguito presentiamo un elenco non esaustivo dei principali attacchi.

  • SQL Injection: un attaccante cerca di inserire del codice SQL dannoso in un’applicazione web, al fine di manipolare la sua logica e accedere o modificare dati presenti nel database. Questo può avvenire quando un’applicazione web non gestisce correttamente l’input dell’utente, consentendo agli attaccanti di inserire codice malevolo tramite campi di input come moduli web o parametri URL.
  • Cross-Site Scripting (XSS) sfrutta la vulnerabilità di un’applicazione web consentendo ad un attaccante di inserire script malevoli all’interno di pagine visualizzate da altri utenti. L’attacco avviene generalmente attraverso l’inserimento di codice JavaScript in input che verrà eseguito dal browser degli utenti.
  • Cross-Site Request Forgery (CSRF): un attaccante convince l’utente ad eseguire un’azione su un sito web deciso dall’attaccante, per fare questo utilizza la sessione autenticata dell’utente, ad esempio usando un link malevolo. Questa tecnica permette all’attaccante di eseguire operazioni non autorizzate a nome dell’utente, ad esempio effettuare un trasferimento di denaro o modificare le credenziali di accesso dell’account. Per prevenire questi attacchi, è necessario utilizzare token di sicurezza e verificare sempre l’origine delle richieste.

Cross Origin Resource Sharing (CORS)

Un modo per evitare alcuni degli attacchi e degli utilizzi malevoli dei web service prevede l’utilizzo del meccanismo di Cross Origin Resource Sharing (CORS).

CORS è un meccanismo di sicurezza implementato nei browser che permette ad un server di consentire l’accesso alle risorse in risposta alle richieste provenienti da un’origine specifica. In pratica, CORS impedisce a un’applicazione web di accedere alle risorse di un’origine diversa senza autorizzazione esplicita.

Nell’esempio a fianco, un’applicazione web che esegue JavaScript nel browser di un utente fa una richiesta HTTP a un server che ha abilitato CORS. Il browser esegue una pre-richiesta (preflight) OPTIONS per verificare se possiede l’autorizzazione sul server. In caso affermativo, il browser esegue la “vera” richiesta a cui il server risponderà “positivamente”. Al contrario, se dalla pre-richiesta viene negata l’autorizzazione, il browser non procede con la vera e propria richiesta.

References

  • Michele Schimd © 2024
  • Ultimo aggiornamento: 17/02/2024
  • Materiale di studio e di esercizio per gli alunni dello Zuccante.

Creative Commons License