Sto creando un'API REST e intendo utilizzare la limitazione della velocità (utilizzando l'algoritmo del bucket leaky) come metodo per proteggersi dalla scansione e dall'enumerazione. L'API verrà utilizzata da un'app mobile / tablet (installata su molti dispositivi) e da client server-server (alcuni interni, alcuni esterni).
Consentendo agli utenti di installare l'app sui propri telefoni (rendendo i dati esposti dalla conoscenza pubblica dell'API) mentre si limitano ancora la scansione e l'enumerazione da parte dei tecnici inversi ho elaborato questa strategia:
- Al primo avvio, l'app genera un ID casuale abbastanza grande da essere considerato univoco
- Quando si richiede un token per l'accesso all'API, l'app si autentica con quell'ID.
- Qualsiasi richiesta di token per lo stesso ID applicazione riceve risposta con lo stesso token (purché non sia scaduto)
- Qualsiasi richiesta di token per lo stesso indirizzo IP riceve lo stesso token (purché non sia scaduto), ignorando completamente l'ID dell'app.
Questa politica non si applica ai client server-to-server poiché questi dovranno impostare un contratto con la mia azienda per poter utilizzare l'API.
Ora, per valutare la limitazione:
È preferibile una di queste strategie? Se: quali sono i pro e i contro?
- assicura che nessuna entità che consuma entri in possesso di più di un token valido alla volta (sostanzialmente uguale a quello delle APP). Aggancia il secchio che perde ai token.
- concedere tanti token a un'entità che richiede. Condividi il bucket che perde tra tutti i token concessi a un'entità.
Inoltre: se l'opzione 1 è preferibile: come deve essere applicata la politica 1-token-per-entity?
- Concedi nuovi token solo dopo che quelli precedenti sono scaduti. Fornisci un'interfaccia che consenta alle entità di revocare / invalidare il loro token corrente.
- Quando viene richiesto un nuovo token, revoca tutti i token precedenti.
Sono particolarmente preoccupato per le condizioni di gara tra
- istanze multiple del server dello stesso appaltatore (quindi tutte soggette allo stesso limite di velocità)
- più installazioni di app in esecuzione che condividono un indirizzo IP (WiFi pubblico, più utenti che condividono una connessione Internet, ...)