API esposte: le porte nascoste del tuo sito web

Il tuo sito web ha una porta d'ingresso che i visitatori vedono: le pagine, i moduli, la navigazione. Ma dietro quella porta d'ingresso ci sono decine di altre porte che la maggior parte delle persone non nota mai. Sono le tue API, Application Programming Interface, e sono il modo in cui i componenti del tuo sito comunicano tra loro e con servizi esterni.

Il problema e che molte di queste porte sono aperte. Alcune sono spalancate. E gli attaccanti sanno esattamente come trovarle.

Questo articolo spiega cosa sono le API nel contesto di un sito aziendale, perche sono un problema di sicurezza, come gli attaccanti le scoprono e le sfruttano, e cosa puoi fare per proteggerti.

Cosa sono le API e perche ogni sito moderno ne ha

Un'API e un modo per far comunicare i componenti software tra loro. Quando compili un modulo di contatto su un sito web, i dati vengono inviati a un endpoint API sul server. Quando una pagina carica elenchi di prodotti, potrebbe recuperare quei dati da un'API. Quando il tuo sito si integra con un processore di pagamenti, un servizio email o un CRM, quelle integrazioni avvengono tramite API.

Anche un semplice sito aziendale ha tipicamente API per:

• Invio modulo di contatto - dati inviati dal browser al server.
• Funzionalita di ricerca - query inviate a un endpoint di ricerca che restituisce risultati.
• Autenticazione utente - login, logout, endpoint di reset password.
• Gestione contenuti - il CMS usa API per creare, leggere, aggiornare e cancellare contenuti.
• Integrazioni con terze parti - analytics, processori di pagamento, email marketing, widget chat.
• Caricamento dinamico di contenuti - scroll infinito, filtraggio, ordinamento, paginazione.

Se il tuo sito funziona con WordPress, Drupal o qualsiasi CMS moderno, ha una REST API completa esposta per impostazione predefinita. Se usa un framework JavaScript come React o Vue, quasi certamente comunica con API backend. Anche un sito "semplice" con un modulo di contatto ha almeno un endpoint API.

WordPress REST API: esposizione dati utente per impostazione predefinita

WordPress viene distribuito con una REST API completa attiva per impostazione predefinita dalla versione 4.7 (rilasciata nel 2016). Questa API e stata progettata per rendere WordPress una piattaforma migliore per costruire applicazioni, ma espone anche dati di cui la maggior parte dei proprietari di siti non si rende conto siano pubblici.

Cosa espone la WordPress REST API

Prova questo su qualsiasi sito WordPress: naviga su /wp-json/wp/v2/users. Su molti siti, vedrai una risposta JSON che elenca tutti gli account utente, inclusi nomi utente, nomi visualizzati, ID utente e URL dei profili. Queste informazioni sono disponibili a chiunque senza autenticazione.

Altri endpoint comunemente esposti:

• /wp-json/wp/v2/posts - tutti i post pubblicati con metadati.
• /wp-json/wp/v2/pages - tutte le pagine pubblicate.
• /wp-json/wp/v2/comments - commenti con informazioni sull'autore.
• /wp-json/wp/v2/media - file caricati con URL completi e metadati.
• /wp-json/ - l'endpoint di discovery dell'API che elenca tutte le rotte disponibili.

Perche questo e importante

L'enumerazione degli username e il punto di partenza per gli attacchi brute force. Se un attaccante conosce i nomi utente del tuo sito WordPress (e la REST API glieli ha appena forniti), puo iniziare a tentare di indovinare le password. Combinato con l'endpoint /wp-login.php e nessun rate limiting o blocco account, questo e un percorso di attacco diretto.

L'endpoint media puo rivelare file che sono stati caricati ma non collegati pubblicamente, inclusi documenti interni, immagini in bozza o file sensibili che qualcuno ha caricato tramite la libreria media di WordPress pensando fossero privati.

Abbiamo discusso rischi correlati nel nostro articolo sulle pagine admin esposte.

Come limitare la WordPress REST API

Hai diverse opzioni, a seconda di come il tuo sito usa l'API:

1. Disabilitarla completamente se il tuo sito non ne ha bisogno (la maggior parte dei siti vetrina non ne ha bisogno).
2. Limitare endpoint specifici. Blocca l'endpoint /users lasciando gli altri accessibili se necessari al tuo tema o plugin.
3. Richiedere autenticazione per tutte le richieste API. Questo e l'approccio piu sicuro ma potrebbe interrompere funzionalita che dipendono dall'accesso API pubblico.

GraphQL introspection lasciata attiva

GraphQL e un'alternativa alle REST API che sta diventando sempre piu comune. Permette ai client di richiedere esattamente i dati di cui hanno bisogno in una singola query. Molti siti web e applicazioni moderni usano GraphQL per il loro livello dati.

Il problema dell'introspection

GraphQL ha una funzionalita integrata chiamata introspection che permette a chiunque di interrogare lo schema completo dell'API. Questo significa che un attaccante puo scoprire ogni tipo, ogni campo, ogni relazione e ogni mutation (operazione di scrittura) disponibile nella tua API, semplicemente inviando una singola query:

{ __schema { types { name fields { name type { name } } } } }

E come consegnare a un attaccante un progetto completo della struttura del tuo database e di ogni operazione supportata dalla tua API. Con queste informazioni, puo creare query mirate per estrarre dati, trovare campi sensibili e scoprire mutation che potrebbero permettergli di modificare i dati.

La soluzione

Disabilita l'introspection in produzione. Ogni libreria GraphQL principale fornisce un'opzione di configurazione per questo. In Apollo Server: introspection: false. Questo dovrebbe essere parte della tua checklist di deployment.

Endpoint API senza autenticazione

Oltre a WordPress e GraphQL, molti siti web e applicazioni personalizzati hanno endpoint API privi di autenticazione adeguata. Questo succede per diverse ragioni comuni:

• Scorciatoie di sviluppo: L'autenticazione "doveva essere aggiunta dopo" e non e mai stata aggiunta.
• Oscurita presunta: Lo sviluppatore ha assunto che nessuno avrebbe trovato l'endpoint perche non e collegato da nessuna pagina. Questa e sicurezza per oscurita, e non funziona.
• Middleware mal configurato: Il middleware di autenticazione e stato applicato alla maggior parte delle rotte ma ne ha mancate alcune.
• Endpoint legacy: Vecchi endpoint API da una versione precedente dell'applicazione mai correttamente dismessi.

Vulnerabilita IDOR: quando l'autenticazione non basta

IDOR sta per Insecure Direct Object Reference. Si verifica quando un'API usa un identificatore prevedibile (come un numero sequenziale) per riferirsi a oggetti, e non verifica che l'utente richiedente abbia il permesso di accedere a quello specifico oggetto.

Come funziona IDOR

Immagina un endpoint API come /api/fatture/1234 che restituisce i dettagli di una fattura. Sei connesso e stai richiedendo la tua fattura. Ora cambia il numero in 1235. Se l'API restituisce la fattura di qualcun altro, quella e una vulnerabilita IDOR.

L'API ha verificato che sei autenticato (sei connesso), ma non ha verificato l'autorizzazione (se hai il permesso di accedere alla fattura 1235). Questo e uno dei tipi di vulnerabilita piu comuni nelle applicazioni web e compare costantemente nella OWASP Top 10.

Impatto reale

Le vulnerabilita IDOR hanno causato grandi violazioni di dati:

• Un attaccante enumera i record dei clienti incrementando il parametro ID, scaricando l'intero database clienti un record alla volta.
• Un utente modifica l'ID utente in una richiesta API e ottiene accesso alle impostazioni dell'account di un altro utente, permettendogli di cambiare l'indirizzo email e prendere il controllo dell'account.
• Un'API per il download di documenti usa ID documenti sequenziali, permettendo a chiunque di scaricare ogni documento nel sistema.

Prevenzione

Ogni endpoint API che accede a dati specifici dell'utente deve verificare che l'utente richiedente abbia il permesso di accedere a quella specifica risorsa. Usa UUID invece di interi sequenziali per gli identificatori degli oggetti per rendere l'enumerazione piu difficile (ma implementa comunque controlli di autorizzazione adeguati).

Rate limiting: la protezione mancante

Il rate limiting limita quante richieste un client puo fare a un'API in un dato periodo di tempo. Senza di esso, gli attaccanti possono:

• Attacchi brute force sugli endpoint di login: Provare migliaia di combinazioni di password al minuto.
• Enumerare dati: Scaricare l'intero database facendo migliaia di richieste API sequenziali.
• Denial of service: Sovraccaricare il server con richieste, rendendolo non disponibile per gli utenti legittimi.
• Abusare di operazioni costose: Attivare ripetutamente chiamate API ad alto consumo di risorse per esaurire le risorse del server.

Come appare un rate limiting adeguato

Tipo di endpoint	Limite suggerito	Motivazione
Login / Autenticazione	5-10 tentativi per minuto per IP	Previene attacchi brute force
Reset password	3 richieste all'ora per email	Previene email bombing
Modulo di contatto	5 invii all'ora per IP	Previene spam
Ricerca	30 richieste al minuto per IP	Previene data scraping
API generale	100 richieste al minuto per utente	Previene abusi permettendo l'uso normale

Chiavi API nel JavaScript frontend

Questo e uno degli errori piu comuni che troviamo durante gli audit dei siti web. Gli sviluppatori incorporano chiavi API, token segreti e credenziali direttamente nel codice JavaScript lato client. Poiche tutto il JavaScript servito al browser e visibile a chiunque apra gli strumenti per sviluppatori, questi segreti sono effettivamente pubblici.

Cosa troviamo nel codice sorgente JavaScript

• Chiavi API di Google Maps (spesso con fatturazione abilitata e nessuna restrizione).
• Configurazione Firebase inclusi URL del database e chiavi API.
• Chiavi API dei processori di pagamento (a volte incluse le chiavi segrete, non solo quelle pubbliche).
• Token API del CMS con permessi di scrittura.
• Chiavi API di servizi email (SendGrid, Mailgun, ecc.).

Come risolvere

1. Non mettere mai chiavi segrete nel codice frontend. Solo le chiavi pubbliche/pubblicabili dovrebbero essere nel JavaScript lato client.
2. Usa variabili d'ambiente sul server. Mantieni i segreti nelle variabili d'ambiente lato server, mai nel codice che viene inviato al browser.
3. Limita le chiavi API per dominio. Google Cloud, AWS e la maggior parte dei servizi permettono di limitare le chiavi API a domini o indirizzi IP specifici. Usa queste restrizioni.
4. Fai passare le chiamate API sensibili attraverso il tuo backend. Invece di chiamare un'API di terze parti direttamente dal browser, instrada la richiesta attraverso il tuo server dove la chiave segreta e memorizzata in sicurezza.
5. Ruota le chiavi esposte immediatamente. Se scopri che una chiave e stata esposta, genera una nuova chiave e revoca quella vecchia.

Come gli attaccanti enumerano e sfruttano le API

Capire come gli attaccanti trovano e testano le API ti aiuta a capire cosa deve essere protetto. Questo non e teorico; sono tecniche usate quotidianamente contro siti reali.

Fase di scoperta

Gli attaccanti usano piu metodi per scoprire gli endpoint API:

• Strumenti per sviluppatori del browser: Apri la scheda Network e naviga il sito. Ogni chiamata API e visibile, incluso l'URL completo, gli header, il corpo della richiesta e la risposta.
• Analisi del codice sorgente JavaScript: Leggi i file JavaScript del sito. Endpoint API, chiavi e a volte token di autenticazione sono incorporati nel codice.
• Scansione di percorsi comuni: Strumenti come DirBuster, ffuf o script personalizzati testano percorsi API comuni: /api/, /v1/, /graphql, /wp-json/.
• Source map JavaScript: Se le source map sono distribuite in produzione (un errore comune), rivelano la struttura del codice sorgente originale, incluse tutte le definizioni degli endpoint API.

Strumenti che gli attaccanti usano

• Postman: Originariamente uno strumento legittimo di sviluppo API, comunemente usato per creare e riprodurre richieste API con parametri modificati.
• Burp Suite: Uno strumento professionale di test di sicurezza web. La funzione proxy intercetta e modifica ogni richiesta tra il browser e il server.
• cURL: Il client HTTP da riga di comando. Semplice, potente e disponibile su ogni sistema.
• OWASP ZAP: Un'alternativa open-source a Burp Suite con capacita simili.

Come proteggere le tue API

La sicurezza delle API non e un'azione singola; e un insieme di pratiche che devono essere applicate coerentemente su tutti i tuoi endpoint.

Autenticazione

Ogni endpoint API che non e esplicitamente pubblico dovrebbe richiedere autenticazione. Usa meccanismi standard: JWT, OAuth 2.0, chiavi API per comunicazione tra servizi, cookie di sessione per applicazioni browser.

Autorizzazione

L'autenticazione conferma l'identita. L'autorizzazione conferma il permesso. Entrambi sono necessari. Implementa il controllo degli accessi basato sui ruoli o sugli attributi. Verifica l'autorizzazione a ogni richiesta, per ogni risorsa.

Validazione degli input

Valida ogni input lato server. Non fidarti mai dei dati provenienti dal client. Controlla: tipi di dati, limiti di lunghezza, validazione del formato, valori ammessi, encoding.

Gestione degli errori

Le risposte di errore delle API dovrebbero essere abbastanza informative per gli utenti legittimi ma non dovrebbero rivelare dettagli interni agli attaccanti. Usa messaggi di errore generici per i fallimenti di autenticazione. Non includere stack trace, percorsi di file o query SQL nelle risposte di errore.

Checklist pratica di audit

Se vuoi valutare la sicurezza delle tue API, inizia con questa checklist:

1. Apri il tuo sito in un browser con gli strumenti per sviluppatori aperti. Vai alla scheda Network. Naviga ogni pagina e clicca ogni pulsante. Quante chiamate API vedi?
2. Per ogni endpoint, prova ad accedervi senza autenticazione. Che dati restituisce?
3. Controlla la WordPress REST API: visita /wp-json/wp/v2/users. Puoi vedere i nomi utente?
4. Controlla GraphQL: prova /graphql con una query di introspection. Risponde?
5. Guarda i file sorgente JavaScript. Ci sono chiavi API, token o credenziali incorporate?
6. Prova a modificare gli ID numerici nelle richieste API. Puoi accedere a dati di altri utenti?
7. Invia 100 richieste a un endpoint sensibile in rapida successione. Vieni limitato?

Prossimi passi

La sicurezza delle API e un'area specializzata che richiede sia conoscenze tecniche sia una comprensione della tua specifica applicazione. In Envestis eseguiamo valutazioni approfondite della sicurezza delle API per le aziende a Lugano e in tutta la Svizzera, identificando endpoint esposti, testando i controlli di autorizzazione e fornendo raccomandazioni specifiche per la correzione.

Se non sei sicuro della sicurezza delle API del tuo sito, contattaci per una valutazione di sicurezza. Mapperemo la superficie delle tue API, testeremo le vulnerabilita descritte in questo articolo e ti daremo un report chiaro di cosa deve essere corretto e come.