Un nuovo livello di sicurezza grazie ad una corretta gestione dell’API
Leggi l’articolo di approfondimento di Gianantonio Dehò – Practice Manager Innovation Software Lab, Bizmatica.
Da Wikipedia: “In un programma informatico, con Application Programming Interface (API), in italiano “interfaccia di programmazione di una applicazione”, si indica un insieme di procedure (in genere raggruppate per strumenti specifici) atte a risolvere uno specifico problema di comunicazione tra diversi computer o tra diversi software o tra diversi componenti di software; spesso tale termine designa le librerie software di un linguaggio di programmazione, sebbene più propriamente le API sono il metodo con cui le librerie vengono usate per sopperire ad uno specifico problema di scambio di informazioni.”
Nell’era dell’esplosione digitale, le API sono decisamente il metodo preferito per progettare e realizzare applicazioni moderne, specialmente per le architetture a microservizi, il mondo Mobile e per i dispositivi IoT.
Sebbene il concetto di alimentare un’applicazione con informazioni provenienti da fonti esterne non sia nuovo, la forte spinta verso l’innovazione ed il conseguente evolversi delle app mette in evidenza che alcune organizzazioni potrebbero non aver ancora compreso i potenziali rischi connessi alla messa a disposizione del pubblico delle loro API.
La maggior parte delle organizzazioni dispone già di misure per combattere attacchi noti come cross-site scripting, injection, denial-of-service distribuito e altri che possono minare la sicurezza delle API, ma non sempre la protezione “dall’esterno” è efficace.
Il concetto di “security by design” è sicuramente una delle best practices da adottare in questo campo, e il team di onStage segue e implementa costantemente le linee guida di OWASP in materia di sicurezza.
Modalità comuni di Attacco alle API
- Injection;
- Distributed Denial off Service (DDos);
- Man in the Middle:(MitM);
- Cross Site Scripting (XSS);
- Credential Guessing;
- Gestione impropria degli Endpoint;
- Monitoring insufficiente;
Modalità comuni di Attacco alle API
Injection
- Una categoria molto ampia di vettori di attacco, che include alcuni dei più gravi rischi per la sicurezza delle applicazioni. Il denominatore comune di quasi tutti gli attacchi injection è che gli aggressori sono in grado di inserire input utente non convalidati direttamente nel codice dell’applicazione eseguita.
Distributed Denial of Service (DDoSs)
- Un attacco DDoS è un tentativo di interrompere il normale traffico di un server, un servizio o una rete sovraccaricando l’obiettivo o l’infrastruttura circostante con un enorme flusso di traffico dati attraverso Internet.
Man in the Middle (MitM)
- Un attacco MitM è un tipo di attacco informatico in cui l’attaccante intercetta e controlla la comunicazione tra due parti che credono di comunicare direttamente tra loro.
Cross Site Scripting (XSS)
- Gli attacchi XSS sono un tipo di injection, in cui gli script dannosi vengono iniettati in siti web altrimenti benigni e affidabili. Gli attacchi XSS si verificano quando un utente malintenzionato utilizza un’applicazione Web per inviare un codice dannoso, generalmente sotto forma di script lato browser, a un utente finale diverso.
Credential Guessing
- Il riempimento delle credenziali è un metodo di attacco informatico in cui gli aggressori utilizzano elenchi di credenzali utente compromesse per violare un sistema. L’attacco utilizza i bot per l’automazione e la scalabilità e si basa sul presupposto che molti utenti riutilizzano nomi utente e password su più servizi.
Gestione impropria degli Endpoint
- Nelle applicazioni che stanno lungo tempo in produzione è frequente che rimangano raggiungibili endpoints non più usati, non aggiornati o addirittura obsoleti. La presenza di questi endpoint “abbandonati” può essere utilizzata come vettore d’attacco.
Monitoring insufficiente
- Se l’infrastruttura di logging e monitoraggio non è sufficiente possono verificarsi situazioni in cui non sia possibile accorgersi che vi è un attacco in corso, rendendo la capacità di reazione molto bassa. Il logging ben strutturato consente anche di effettuare analisi a posteriori, per saper attuare adeguate misure correttive dopo l’attacco.
Contromisure
| Tipo di attacco | onStage | Altri sistemi |
|---|---|---|
| Injection | Serializzazione e deserializzazione dei dati in ingresso e in uscita verso Entities di business note. Validazione e sanitizzazione dei dati in input. | Validazione e “sanitizzazione” di tutti i dati in ingresso; limitazione dei dati nella response per evitare la fuoriuscita di dati non necessari. |
| DDoS | Configurazione del throttling per singolo endpoint, anti-hammering progressivo (automatico), meccanismo di alerting sui comportamenti sospetti del chiamante. | Utilizzo di strumenti per limitare le chiamate (throttling) e per limitare le dimensioni dei dati per ogni request/response (payload). |
| MitM | HTTPS only, encryption del payload. | Cifratura del traffico in entrata ed in uscita. |
| XSS | Validazione dei dati in ingresso. | Validazione dei dati in ingresso. |
| Crediental Guessing | Monitoring degli endpoint attraverso la onStage web console, connesione dei client attraverso attraverso una API Key ed un Client ID. | Controllo degli attacchi bruteforce, detection e segregazione del chiamante. |
| Gestione Impropria degli Endpoint | Gestione granulare degli endpoint attraverso la onStage web console. | Manutenzione periodica e disabilitazione degli endpoint obsoleti. |
| Monitoring insufficiente | Dashboard per il monitoring dei log, e delle statistiche di chiamata degli endpoint. | Analisi statistica delle performance e analisi periodica dei log. |
Le best practices di onStage
Le best practice adottate da OnStage per la sicurezza delle API seguono le linee guida di OWASP e sono le seguenti:
Prioritizzazione della sicurezza
Nello sviluppo di onStage la sicurezza è vista come il primo obiettivo.
API first
onStage implementa il principio fornendo tool per semplificare il disegno delle API, la generazione di codice per guidare l’implementazione, la documentazione e la realizzazione automatica degli script di mock.
TLS, Sempre!
onStage obbliga gli utilizzatori ad avere l’HTTPS come unica opzione disponibile.
Strong Authentication and Authorization
Il client che si connette ad onStage è autenticato attraverso una API Key ed un Client ID, ed è autorizzato in maniera univoca. L’accesso ad ogni endpoint è granulare e configurabile, il protocollo di comunicazione è sicuro e cifrato. onStage si integra con i provider SAML, OpenID, OAuth2, JWT.
Principio del “minimo privilegio” (Zero trust philosophy)
L’accesso delle API non è mai abilitato per default. È necessario configurare onStage e dare esplicitamente l’accesso agli endpoint agli utenti.
Solo informazioni necessarie.
La definizione delle interfacce e dei datamodels in input e in output, obbliga il sistema a gestire solo le informazioni strettamente necessarie, filtrando i dati alla fonte. Il dato in ingresso viene processato dal frontend-layer, tipizzato, deserializzato in un’entity di business, validato e se classificato come conforme, inviato al business process layer.
Throttling/Rate limiting.
In onStage è possibile configurare il numero di chiamate al secondo che può ricevere ogni endpoint. Le chiamate vengono accodate nell’ordine di arrivo e poi “scodate” con il rispetto dei limiti configurati.
Consulenza
Assistiamo i nostri clienti che utilizzano onStage durante tutte le fasi dell’implementazione.
Biografia Gianantonio Dehò – Practice Manager Innovation Software Lab
Dopo aver conseguito le specializzazioni in Oracle, Gianantonio Dehò lavora da oltre 20 anni nell’industria del Software Developing diventando poi Practice Manager – Software Innovation Lab di Bizmatica Econocom, sviluppando applicativi interni ed esterni, volti a supportare le continue innovazioni digitali e ottimizzazione dei processi, supportando anche le attività dei clienti osservando le best practices da adottare.