CA Technologies: la Security Web API si progetta, non si improvvisa

Fino a non molto tempo fa, costruire un’applicazione distribuita significava implementare un servizio Web utilizzando un protocollo SOAP per lo scambio di messaggi tra componenti software.
Le interfacce Web-based si basavano su standard piuttosto pesanti che formavano uno stack noto come “WS-*” dal quale negli ultimi anni si sono ampiamente prese le distanze.

Gli sviluppatori hanno, infatti, scelto di abbracciare un sistema di design organico, più flessibile e meno prescrittivo che, com’è ormai noto, ha dato il via alle Web API e, con loro, all’adesione esclusiva al protocollo HTTP e alle specifiche URI (Uniform Resource Identifier ) che identificano univocamente una risorsa generica, sia essa un indirizzo Web, un documento, un’immagine, un file, un servizio, un indirizzo di posta elettronica.

L’autore di questo articolo, Francesco Tragni, è Senior Solution Strategist in CA Technologies

API più semplici ma meno sicure?

Questa libertà ha permesso di creare API semplici da utilizzare, in quanto adottano convenzioni comunemente accettate.
Tuttavia, la mancanza di procedure univoche per risolvere uniformemente problemi specifici ha finito per scoprire il fianco rispetto ai vecchi stack “WS-*” che, al contrario, hanno sempre fornito specifiche molto chiare per risolvere requisiti di sicurezza comuni.
Questa debolezza appare in tutta la sua evidenza quando si tratta di sicurezza, aspetto non negoziabile quando si  tratta di gestire dati privati, garantendone l’accesso ai soli utenti abilitati.È facile comprendere dunque da dove nasca il crescente  consenso da parte dell’attuale generazione di sviluppatori API rispetto all’importanza di riferirsi a specifiche concordate e condivise,  dalle quali è emersa una nuova serie di standard.

Strumenti sicuri per chi progetta Web API

Da più parti definito come misura minima per la sicurezza su Internet, il protocollo per la comunicazione sicura sul Web, HTTPS, anche noto come HTTP over TLS, risulta particolarmente utile quando si tratta di far transitare sulla rete dati riservati.
Ma non lasciatevi ingannare. Come dimostra la molteplicità degli attacchi registrati negli ultimi cinque anni, configurare un server all’interno di una connessione criptata rappresenta una vera e propria sfida.
Il che non significa che chi intende sviluppare una API non possa guardare con fiducia al protocollo HTTPS. Il suggerimento, però, è di farlo prestando attenzione a come viene configurata e implementata l’infrastruttura TLS, possibilmente seguendo le direttive dell’OWASP, ossia dell’Open Web Application Security Project.

Pro e contro del protocollo HTTP

Per certi versi, il bello di utilizzare la specifica HTTP come base per progettare API consiste nella ricchezza delle funzionalità disponibili, particolarmente utile per affrontare sfide di progettazione comuni, come l’accesso protetto a una API per il quale l’HyperText Transfer Protocol fornisce un framework di autenticazione.
L’autenticazione di base, realizzata attraverso nome utente e password su HTTP, è particolarmente familiare per chi progetta Web API ma uno dei suoi limiti è l’invio in chiaro delle password a ogni richiesta, che renderebbe più facile a un malintenzionato intercettarle e farle proprie.
Viceversa, le API che utilizzano TLS sono meno esposte a rischi, dal momento che i dati sono cifrati.
Inoltre, nonostante l’autenticazione di base sia chiamata a supportare un client e un server, molte API sono presenti in ambienti di interazione più complessi, dove l’ostacolo maggiore è rappresentato dai vari gradi di “trust” tra le parti coinvolte in un’applicazione distribuita aperta.
Prendiamo ad esempio una interfaccia di programmazione delle applicazioni per un sistema di archiviazione file: molto probabilmente,  gli utenti vorranno poter gestire i propri file in modi e su piattaforme differenti richiedendo l’esposizione della API a terzi, creando nuove interfacce utente per il sistema.
Senza dubbio, quest’opzione rappresenta un vantaggio ma anche una netta esposizione a rischi potenziali, visto che richiede agli utenti di affidarsi ad applicazioni di terze parti per gestire le proprie risorse di file.
Chi assicura, in questo caso, che le credenziali dell’utente saranno gestite correttamente? E chi decide chi può accedere alle risorse o chi non viene autorizzato ad accedere ad un’applicazione client?
Ecco che, allora, a farsi largo sono nuove opzioni per garantire accesso alle odierne API basate sul Web.

Un aiuto concreto dai protocolli “open”

Per fornire una soluzione uniforme, una decina di anni fa, alcuni cloud service provider hanno messo a punto lo standard OAuth, Open Authorization, ovvero un protocollo aperto che permette alle applicazioni di chiamare in modo sicuro e autorizzato le API messe a disposizione da un servizio Web e di accedere alle risorse protette di un utente senza che quest’ultimo sia costretto a condividere le proprie credenziali.
Niente più deleghe uniche a ogni piè sospinto per gli sviluppatori di applicazioni di fronte a una nuova API, né impegnative implementazioni crittografiche per i clienti e curve di apprendimento più difficili per gli sviluppatori derivanti dalla prima versione di OAuth.
Sostituendo le firme crittografiche con token, la più recente versione 2.0 di OAuth, consente, infatti, di ottenere l’accesso a una risorsa protetta. Così facendo, per gli sviluppatori di applicazioni client viene meno la necessità di implementare la crittografia e si abbattono i costi per accedere alle API.
Peccato, però, che il meno popolare OAuth 2.0 non sia compatibile con la versione precedente dello standard e che il suo stesso uso, come è accaduto negli ultimi due anni, abbia imposto una scelta a chiunque dovesse decidere quale tipologia di controllo degli accessi implementare per la propria interfaccia.

Verso uno standard de facto per l’accesso alle API

Fortunatamente, la diatriba si è conclusa e OAuth 2.0 è diventato lo standard de facto per il controllo degli accessi alle nuove Web API, con tool di supporto e librerie in costante miglioramento per offrire, lato client, agli sviluppatori ancor più familiarità nel loro uso.
Per contro, con quattro diverse modalità di funzionamento supportate e numerosi dettagli demandati a chi la implementa, la specifica OAuth 2.0 risulta estremamente complessa lato server.
Oltre che frustrante da applicare nella pratica, OAuth 2.0 lascia, poi, spazio a errori di implementazione che possono provocare gravi vulnerabilità, tanto che sempre più fornitori di API hanno preso a utilizzare componenti gateway per rafforzare lo standard in uso.
Non a caso uno dei vantaggi intrinseci derivanti dalla mancanza di prescrizione nella specifica di OAuth 2.0 consiste nel suo essere diventato un framework piuttosto che una soluzione stand-alone. Il che permette a nuovi standard di risolvere problemi più specifici sfruttando i vantaggi del protocollo stesso.

Cresce il valore dei sotto-protocolli

Ne è un valido esempio Open ID Connect, un protocollo standard-based utilizzato per realizzare un’autenticazione federata degli utenti sul Web, che garantisce una protezione molto più potente e prescrittiva rispetto a OAuth 2.0.
Appare evidente che  in futuro sarà possibile veder proliferare ulteriori sotto-protocolli OAuth 2.0 in grado di risolvere specifici problemi di dominio e con costi inferiori di implementazione, grazie alla crescente popolarità di questo standard.

Da “WS-*” a “JW-*”, con l’aggiunta di firma e crittografia

Open ID Connect si basa, inoltre, su JSON Web Token, o JWT, uno standard di sicurezza che sta guadagnando una posizione di rilievo nelle soluzioni enterprise candidandosi a diventare una componente fondamentale nella sicurezza delle API.
Parte di una serie di standard crittografici IETF, JWT include, infatti, sia la firma sia la crittografia la cui standardizzazione ben si adatta alle moderne interazioni Web API.
Del tutto simili nello spirito al precedente stack “WS-*”, l’insieme di norme “JW-*” si differenziano da quest’ultimo perché progettate per il Web e più semplici da utilizzare nel mondo XML.
Il resto lo ha fatto la popolarità di OAuth 2.0, che ha reso l’uso dei token una feature assodata per chi vuole implementare API sicure.

Progettare API: una continua sfida alla sicurezza

Anche se è impossibile prevedere quel che accadrà nei prossimi anni, si può di certo presumere che le sfide alla sicurezza per chi progetta API non si esauriscono qui.
Il suggerimento, allora, è tenere d’occhio due tecnologie attualmente in fase di affermazione sul mercato.
La prima si chiama Oz ed è il nuovo sistema delle deleghe messo a punto da Eran Hammer, già nel gruppo di lavoro che ha portato alla creazione della prima versione di OAuth. Fuoriuscito nel 2012 dal team, Hammer ha dato vita a Oz le cui basi, Iron e Hawk, si candidano a diventare una legittima alternativa a OAuth 2.0.
La seconda tecnologia si chiama Macaroons e rappresenta un nuovo tipo di token in grado di memorizzare in maniera embedded le regole di accesso per dar vita a un unico pacchetto di sicurezza comprensivo di accesso granulare e politiche di convalida, così da automatizzare nel token stesso i numerosi passaggi di validazione, necessari a mantenere al sicuro le implementazioni OAuth.
Diversamente dagli standard XACML e SAML, sviluppati per rispondere a problematiche simili, i Macaroons sono specificamente disegnati per il Web e, cosa più importante, hanno il benestare di Google. Il che lascia prevedere un rapido diffondersi del loro utilizzo nella comunità del Web.

Protezione delle Web API: non importa il mezzo ma il fine

 Considerato lo scenario fin qui descritto, oggi, gli strumenti a disposizione dei responsabili della sicurezza delle Web API non mancano: si parte con l’uso di TLS per la sicurezza punto a punto del canale, per poi delegare a OAuth 2.0 il controllo accessi mentre Open ID Connect si occupa della parte di autenticazione lasciando allo standard JWT quella dei token.
Attenzione, però: strumenti e specifiche da soli non bastano. A prescindere dagli standard di sicurezza utilizzati, è l’effettiva attuazione degli stessi che determina i singoli livelli di rischio nella creazione della propria API.

Ulteriori approfondimenti su questo tema sono consultabili a questo indirizzo

Sullo stesso tema potrebbero interessarti anche:
Appunti di Api Economy – Hai successo nell’Api economy? Misuralo!
Quattro mosse per avere successo nell’App Economy