Affidabilità del trasferimento dati via API: come garantirla?

Il nostro lavoro ci ha portato molte volte a dover progettare e implementare trasferimenti di dati via API per applicazioni che dovevano garantire un alto livello di robustezza e di sicurezza, e il nostro team si è spesso confrontato sulle scelte tecnologiche da prendere per garantire questa sicurezza.

Come spesso accade però, le soluzioni più sicure non sono quelle più complesse, ma quelle più semplici.

Facciamo quindi un passo indietro e partiamo dal problema di fondo, ovvero:

Come facciamo a fidarci dei dati che ci arrivano attraverso un canale di comunicazione non sicuro?

Problema: trasferire dati via API

Immaginiamo che Alice voglia dichiarare il suo amore a Bob, per fare ciò decide di inviare un messaggio a Bob per posta.

Fin qui tutto bene, ma James, l’ex-fidanzato di Alice, non è contento della cosa e decide di giocare un brutto scherzo alla sua vecchia fiamma.

James si finge Bob ingannando il postino, intercetta il messaggio di Alice, lo cambia e lo inoltra quindi al povero Bob.

Bob non ha modo di accorgersi della truffa perché non ha nessun mezzo per determinare se il messaggio ricevuto proveniva davvero da Alice.

La soluzione?

Se invece Alice avesse “firmato” il suo messaggio, in quello scritto da James la firma sarebbe mancata e ora Bob non avrebbe il cuore spezzato.

Ma il nostro James è un provetto grafologo ed è in grado di imitare alla perfezione la firma di Alice, rendendo di nuovo Bob incapace di capire se la firma è davvero quella di Alice o se è invece un’imitazione.

Può quindi Alice fare in modo tale che la sua firma non venga copiata o contraffatta?

La risposta è : no.

Nel medioevo avevano (quasi) risolto sigillando la missiva con la ceralacca, se qualcuno avesse tentato di alterare la lettera avrebbe dovuto rompere il sigillo e il destinatario se ne sarebbe sicuramente accorto, ma nel mondo digitale possiamo replicare qualsiasi cosa in modo perfetto, è come se noi potessimo copiare carta, colla, inchiostro e pure la ceralacca.

E quindi?

Alice non potrà mai fare un qualcosa che non possa venire copiato o contraffatto, ma può affrontare il problema da un altro punto di vista e anziché tentare invano di impedire la manomissione, può far capire a Bob che il messaggio che ha ricevuto è stato alterato.

La vera soluzione

Come? L’aiuto decisivo ci arriva da una particolare tipologia di algoritmi:
le funzioni crittografiche di hash.

In sostanza, queste funzioni sono in grado di restituirci una “firma” di un particolare contenuto, la peculiarità che ci interessa è quella che se il contenuto cambia di anche solo un singolo carattere la firma restituita è differente. Non è possibile dalla firma risalire al contenuto, ma abbiamo la sicurezza che due contenuti con la stessa firma sono sicuramente uguali.

Alcuni famosi algoritmi di hash sono : MD5, SHA-1

Torniamo a Bob ed Alice.
C’è una cosa che solo loro due conoscono: il nome della canzone che suonava al party in cui si sono visti per la prima volta, “Purple Rain”.

Alice quindi prende il suo messaggio, ci aggiunge il nome della canzone (il “segreto”) e passa il tutto attraverso un algoritmo di hash, generando una “firma”.

Prende quindi il messaggio originale, gli allega la firma ottenuta e la invia a Bob.

Bob, una volta ottenuto il messaggio, recupera il contenuto e mette temporaneamente da parte la firma ricevuta.
Dopodichè esegue la stessa procedura di firma eseguita da Alice, usando il loro segreto condiviso “Purple Rain” e verifica se la firma da lui ottenuta coincide con quella ricevuta.

Le firme coincidono e Bob è sicuro che il messaggio ricevuto sia stato davvero scritto da Alice.

Ma siamo davvero sicuri questa volta? E se James provasse a cambiare di nuovo il messaggio?
Questa volta, anche se James conosce a perfezione la procedura di firma concordata tra Alice e Bob, non conosce il loro segreto, e dato che questo non viene inviato per posta (il famoso canale non sicuro) non ha modo di ottenerlo.

In pratica, James potrebbe provare a cambiare il testo senza cambiare la firma, ma la funzione di hash si accorgerebbe della variazione e genererebbe una firma differente.

Bob avrebbe quindi un messaggio con una firma diversa da quella verificata da lui e saprebbe immediatamente che il messaggio non è “genuino”.

Conclusioni

Abbiamo un po’ scherzato ed è giunta l’ora di lasciare i nostri Bob, Alice e James.

Il concetto chiave è capire che nella progettazione di servizi Web dobbiamo sempre ricordarci che Server e Client sono entità disaccoppiate, e i dati che si scambiano attraversano un canale che è insicuro per definizione, rendendo di fatto insicuri anch’essi. È quindi necessario verificare sempre la natura e la genuinità delle richieste che ci arrivano da entrambi i soggetti.

Originally published at https://caffeina.com/blog/affidabilita-del-trasferimento-dati-via-api-come-la-garantiamo.