A cura di Lori MacVitte, F5 Distinguished Engineer
Quiz time: quale di questi endpoint appartiene a un’API e quale a un’applicazione?
https://www.example.com/product o https://www.example.com/product?
Se siete indecisi e non riuscite a rispondere, va bene così. È proprio questo il punto: gli endpoint delle app e delle API sono praticamente identici. Questo perché in termini tecnici, se sono RESTful (e la maggior parte lo sono) vengono richiamati allo stesso modo, tramite HTTPS e di solito con un metodo GET. Ciò che spesso è diverso è il carico utile inviato con la richiesta. Per le API questo contiene tipicamente alcuni dati in formato JSON o XML, mentre le richieste delle applicazioni web possono contenere, beh, nulla.
Tuttavia, uno dei risultati principali del rapporto annuale State of Application Strategy che come F5 realizziamo indica che le organizzazioni trattano le API in modo diverso dalle applicazioni quando si tratta di sicurezza. Lo deduciamo dal fatto che il 41% delle organizzazioni possiede un numero di API pari o superiore a quello delle applicazioni, ma attribuisce un valore minore agli stessi servizi di sicurezza che le proteggono.
Ci si potrebbe chiedere come mai le organizzazioni si ritrovino con più API che applicazioni. Mentre le API utilizzate per la comunicazione interna da servizio a servizio (come i microservizi) sono certamente strettamente accoppiate al servizio che supportano, questo non è necessariamente vero quando le API sono utilizzate per presentare interfacce esterne.
Da dove vengono le API?
Considerate che, in una nostra ricerca del 2021, il 61% degli intervistati ha dichiarato che stava “aggiungendo un livello di API per consentire interfacce utente moderne” come metodo di modernizzazione. Nel 2022, la percentuale era del 45%. Ciò significa che le API che abilitano le moderne interfacce utente non sono necessariamente collegate direttamente alle applicazioni. Potrebbero essere façade che facilitano le interfacce utente e le applicazioni moderne, come le applicazioni mobili e i servizi digitali, oppure potrebbero essere façade progettate per consentire le comunicazioni con i partner e la supply chain. Questi casi d’uso sono supportati dai gateway API e dal routing di livello 7 nei load balancer, che spesso forniscono un certo livello di capacità di trasformazione che consente loro di tradurre dall’endpoint dell’API all’endpoint dell’applicazione, consentendo così una API façade come quelle che fanno apparire i vecchi edifici del West americano molto più imponenti di quanto non siano.
Naturalmente, un buon numero di API è costituito da entities rivolte al pubblico collegate alle applicazioni e accessibili tramite il Web (in genere HTTPS).
Indipendentemente dal modo in cui sono arrivate, le API public-facing sono soggette a molti degli stessi attacchi delle applicazioni. Ciò è particolarmente vero quando sono coinvolti i bot, poiché le API con una buona documentazione rendono più facile per gli aggressori eseguire attacchi su scala.
Ad esempio, poco più del 13% delle transazioni protette da F5 Distributed Cloud Bot Defense nel 2023 sono state automatizzate. Vale a dire, è stato utilizzato uno script o un software invece di un essere umano che utilizza un browser web o un’applicazione mobile. Queste transazioni avvengono sia tramite API che tramite mobile app. Una certa percentuale di queste transazioni automatizzate erano sicuramente “bad bots” a cui la presenza del nostro servizio di sicurezza ha impedito di fare qualsiasi attività malevola stessero cercando di fare. (Potete approfondire cosa stavano cercando di fare in questo rapporto degli F5 Labs).
Pertanto, quando abbiamo esaminato la percezione della gestione dei bot da parte degli intervistati in base al numero di API da loro stessi dichiarato, siamo rimasti un po’ scioccati nello scoprire che la gestione dei bot è piuttosto bassa nella scala di importanza.
Mentre l’importanza attribuita ai gateway API sembra essere adeguata al numero di API gestite, lo stesso non vale per la gestione dei bot. Anzi, è completamente il contrario! Al crescere del numero di API, l’importanza della gestione dei bot sembra diminuire rapidamente.
È possibile che la maggior parte di queste API sia interna. Si tratta cioè di API est-ovest tra microservizi che non sono esposte ad attori esterni che potrebbero essere bot cattivi con intenti malevoli.
Ma potrebbe anche essere così. Visto il numero di articoli che ho letto nell’ultimo anno su aggressori che ottengono l’accesso tramite API, immagino che ce ne siano molti di più esterni di quanto pensiamo.
È quindi giunto il momento di ricordare alla gente che, se da un lato esistono numerosi bot fastidiosi, come grinch bots, sneaker bots e così via, che interrompono le attività commerciali per impossessarsi di merci molto richieste, dall’altro esiste anche un numero significativo di bot il cui unico scopo è individuare le vulnerabilità e attaccarle. Sia nelle API che nelle applicazioni.
Pertanto, sarebbe una buona idea per le organizzazioni impiegare una gamma completa di opzioni di sicurezza per proteggere le loro API e, in ultima analisi, il loro business. La gestione dei bot è certamente una di queste opzioni di sicurezza e dovrebbe essere considerata una componente critica di qualsiasi strategia di sicurezza.
In fin dei conti, ai bot non importa se l’endpoint appartiene a un’app o a un’API. Li attaccheranno entrambi.
Ciò significa che le aziende devono proteggere sia le app che le API, rilevando i bot e impedendo loro di fare qualsiasi cosa cattiva stiano cercando di fare.
