Migliori pratiche per la limitazione della velocità

Le sezioni seguenti trattano le configurazioni tipiche di limitazione della velocità per i casi d'uso più comuni. È possibile combinare le regole di esempio fornite e adattarle al proprio scenario.

I principali casi d'uso della limitazione della velocità sono i seguenti:

  • Applicare un controllo granulare dell'accesso alle risorse, che include il controllo dell'accesso basato su criteri quali user agent, indirizzo IP, referrer, host, paese e regione del mondo.
  • Protezione contro gli attacchi di credential stuffing e account takeover.
  • Limitare il numero di operazioni eseguite dai singoli clienti. Include la prevenzione dello scraping da parte dei bot, l'accesso a dati sensibili, la creazione in massa di nuovi account e l'acquisto programmatico nelle piattaforme di e-commerce.
  • Proteggi le API REST dall'esaurimento delle risorse (attacchi DDoS mirati) e le risorse dall'abuso in generale.
  • Proteggi GraphQL le API prevenendo il sovraccarico del server e limitando il numero di operazioni.

Applicazione di un controllo granulare degli accessi

È possibile utilizzare la limitazione della velocità per controllare il modo in cui gli utenti e le applicazioni accedono alle risorse. La limitazione della velocità aiuta a proteggere la tua applicazione da abusi, limitando il traffico in base ad attributi quali user agent, indirizzo IP, referrer o host.

Ciascuno dei seguenti esempi illustra come configurare una regola di limitazione della velocità per uno specifico scenario di controllo degli accessi.

Limitazione delle richieste da parte dell'agente utente

È possibile limitare il numero di richieste consentite per uno specifico user agent. Il seguente esempio di regola consente agli utenti delle app mobili di effettuare fino a 100 richieste ogni 10 minuti. È anche possibile creare una regola separata che limiti la velocità per i browser desktop.

Esempio: limitare le richieste in base all'agente utente
Impostazione Valore
Criteri di corrispondenza User Agent uguale a MobileApp
Espressione http.user_agent eq "MobileApp"
Caratteristiche di conteggio IP
Frequenza (richieste/periodo) 100 richieste / 10 minuti
Azione Sfida Gestita

Consentire indirizzi IP o ASN specifici

Controlla l'accesso includendo o escludendo determinati indirizzi IP o numeri di sistema autonomo (ASN) da una regola di limitazione della velocità.

Il seguente esempio di regola di limitazione della velocità consente fino a 10 richieste al minuto dallo stesso indirizzo IP e di effettuare una GET richiesta al /status percorso, a condizione che l'indirizzo IP non sia incluso nell'elenco IP denominato partner_ips.

Esempio: consentire IP o ASN specifici
Impostazione Valore
Criteri di corrispondenza Il percorso URI è uguale a /status e il metodo di richiesta è uguale a GET e l'indirizzo IP di origine non è presente nell'elenco partner_ips
Espressione http.request.uri.path eq "/status" and http.request.method eq "GET" and not ip.src in $partner_ips
Caratteristiche di conteggio IP
Frequenza (richieste/periodo) 10 richieste / 1 minuto
Azione Sfida Gestita

Limitazione delle richieste in base al referrer

È possibile limitare le richieste provenienti da pagine di provenienza, come annunci pubblicitari di terze parti o siti web esterni. Questo caso d'uso contribuisce a ridurre il rischio di attacchi indiretti di tipo denial-of-service ( DDoS ) e aiuta a gestire le quote di richiesta.

Esempio: limitare le richieste in base al referrer
Impostazione Valore
Criteri di corrispondenza Il percorso URI è uguale a /status e il metodo di richiesta è uguale a GET
Espressione http.request.uri.path eq "/status" and http.request.method eq "GET"
Caratteristiche di conteggio Intestazione (Referrer). Il nome HTTP dell'intestazione utilizza un errore ortografico di referrer.
Frequenza (richieste/periodo) 100 richieste / 10 minuti
Azione Blocca

Questa regola di esempio richiede la limitazione avanzata della velocità.

Protezione contro il credential stuffing

È possibile utilizzare la limitazione della frequenza per proteggere gli endpoint di accesso dagli attacchi di "credential stuffing". Il credential stuffing si verifica quando gli aggressori utilizzano script automatizzati per provare diverse combinazioni di nome utente e password su un modulo di accesso. La limitazione della frequenza contribuisce a mitigare questi attacchi limitando i tentativi ripetuti di accesso non riusciti dallo stesso indirizzo IP.

Gli esempi seguenti mostrano tre regole di limitazione della velocità che aumentano le restrizioni e le sanzioni in base al numero di tentativi di accesso non riusciti.

Regola 1: Soglia di protezione iniziale

La regola 1 consente fino a quattro tentativi di accesso non riusciti al minuto. Quando il limite viene superato, il sistema attiva una sfida gestita. Questa configurazione aiuta gli utenti legittimi a recuperare da errori di accesso occasionali, scoraggiando al contempo i bot automatizzati.

Configurazione della regola 1
Impostazione Valore
Criteri di corrispondenza Il nome host è uguale a example.com e il percorso URI è uguale a /login e il metodo di richiesta è uguale a POST
Espressione http.host eq "example.com" and http.request.uri.path eq "/login" and http.request.method eq "POST"
Caratteristiche di conteggio IP
Aumenta il contatore quando Il percorso URI è uguale a /login e il metodo è uguale a POST e il codice di risposta è compreso tra (401, 403)
Espressione di conteggio http.request.uri.path eq "/login" and http.request.method eq "POST" and http.response.code in {401 403}
Frequenza (richieste/periodo) 4 richieste / 1 minuto
Azione Sfida Gestita

Regola 2: Soglia di protezione intermedia

Se gli utenti legittimi superano la sfida quando raggiungono il limite di velocità della regola 1, la regola 2 applica una protezione aggiuntiva per i clienti che continuano a effettuare tentativi di accesso non riusciti. Consente fino a 10 tentativi falliti in 10 minuti prima di attivare un'altra sfida gestita.

Configurazione della regola 2
Impostazione Valore
Criteri di corrispondenza Il nome host è uguale a example.com e il percorso URI è uguale a /login e il metodo di richiesta è uguale a POST
Espressione http.host eq "example.com" and http.request.uri.path eq "/login" and http.request.method eq "POST"
Caratteristiche di conteggio IP
Aumenta il contatore quando Il percorso URI è uguale a /login e il metodo di richiesta è uguale a POST e il codice di stato della risposta è compreso tra (401, 403)
Espressione di conteggio http.request.uri.path eq "/login" and http.request.method eq "POST" and http.response.code in {401 403}
Frequenza (richieste/periodo) 10 richieste / 10 minuti
Azione Sfida Gestita

Regola 3: Soglia di protezione rigorosa

La regola 3 applica una sanzione più severa ai clienti che superano la soglia della regola 2, bloccando un indirizzo IP per un giorno dopo 20 tentativi di accesso non riusciti nell'arco di un'ora. Questa regola fornisce una difesa definitiva contro i tentativi di attacco persistenti.

Configurazione della regola 3
Impostazione Valore
Criteri di corrispondenza Host uguale a example.com
Espressione http.host eq "example.com"
Caratteristiche di conteggio IP
Aumenta il contatore quando Il percorso URI è uguale a /login e il metodo di richiesta è uguale a POST e il codice di stato della risposta è compreso tra (401, 403)
Espressione di conteggio http.request.uri.path eq "/login" and http.request.method eq "POST" and http.response.code in {401 403}
Frequenza (richieste/periodo) 20 richieste / 1 ora
Azione Blocco per 1 giorno

Tutte queste regole di esempio richiedono un piano Business o superiore.

Queste tre regole hanno un'espressione di conteggio separata dall'espressione della regola (nota anche come espressione di mitigazione). Quando si configura un'espressione di conteggio separata, i criteri di corrispondenza vengono utilizzati quando viene attivata un'azione. Nell'espressione di conteggio è possibile includere condizioni basate sul codice di stato della HTTP risposta e sulle HTTP intestazioni della risposta per integrare la limitazione della velocità con la logica del backend.

È anche possibile decidere di avere due espressioni diverse: un'espressione di conteggio e un'espressione di regola/mitigazione, per definire:

  1. Le richieste utilizzate per calcolare il tasso.
  2. Le richieste effettivamente soddisfatte.

Ad esempio, l'esempio della regola 3 calcola la frequenza considerando POST le richieste che /login hanno restituito un codice di 401 stato 403HTTP o. Tuttavia, quando il limite di velocità viene superato, CIS blocca tutte le richieste example.com all'host generate dallo stesso IP.

Limitare il numero di operazioni

È possibile utilizzare la limitazione della frequenza per controllare il numero di operazioni eseguite da un client in un determinato periodo di tempo. Le regole configurate dipendono dal comportamento dell'applicazione e dal profilo di rischio.

Gli esempi seguenti mostrano come impedire lo scraping dei contenuti e le attività automatizzate che possono sovraccaricare il sistema o utilizzare in modo improprio i dati. Esempi includono la limitazione delle richieste tramite stringa di query, parametri del corpo JSON o caratteristiche dei bot.

Prevenzione dello scraping dei contenuti tramite stringa di query

In questo esempio, i clienti eseguono operazioni (come la ricerca dei prezzi o l'aggiunta di articoli al carrello) su un sito web di e-commerce tramite parametri della stringa di query. Ad esempio, una richiesta tipica inviata da un client potrebbe essere simile alla seguente:

GET https://store.com/merchant?action=lookup_price&product_id=215
Cookie: session_id=12345

Il tuo team di sicurezza potrebbe prendere in considerazione l'idea di impostare un limite al numero di volte in cui un cliente può cercare i prezzi, al fine di impedire ai bot (che potrebbero aver eluso CIS il Bot Management) di estrarre l'intero catalogo del negozio.

Configurazione della regola 1
Impostazione Valore
Criteri di corrispondenza Il percorso URI è uguale a /merchant e la stringa di query URI contiene action=lookup_price
Espressione http.request.uri.path eq "/merchant" and http.request.uri.query contains "action=lookup_price"
Caratteristiche di conteggio IP
Frequenza (richieste/periodo) 10 richieste / 2 minuti
Azione Sfida Gestita
Configurazione della regola 2
Impostazione Valore
Criteri di corrispondenza Il percorso URI è uguale a /merchant e la stringa di query URI contiene action=lookup_price
Espressione http.request.uri.path eq "/merchant" and http.request.uri.query contains "action=lookup_price"
Caratteristiche di conteggio IP
Frequenza (richieste/periodo) 20 richieste / 5 minuti
Azione Blocca

Queste due regole di limitazione della frequenza corrispondono alle richieste che eseguono un'azione selezionata (in questo esempio, la ricerca del prezzo) e utilizzano IP come caratteristica di conteggio. Analogamente all'esempio /login, le due regole aiutano a ridurre i falsi positivi in caso di visitatori persistenti (ma legittimi).

È possibile limitare la ricerca di un elemento specifico product_id utilizzando un parametro stringa di query. Aggiungendo un parametro di query come caratteristica di conteggio, il tasso viene calcolato su tutte le richieste, indipendentemente dal client.

L'esempio seguente limita il numero di ricerche per ciascuna product_id a 50 richieste in 10 secondi.

Limite della regola tramite stringa di query
Impostazione Valore
Criteri di corrispondenza Percorso URI uguale a /merchant
Espressione http.request.uri.path eq "/merchant"
Caratteristiche di conteggio Interrogazione (product_id)
Frequenza (richieste/periodo) 20 richieste / 10 secondi
Azione Blocca

Questa regola di esempio richiede la limitazione avanzata della velocità.

È possibile seguire lo stesso modello di regole di limitazione della velocità per proteggere le applicazioni che gestiscono prenotazioni e riservazioni.

Prevenzione dello scraping dei contenuti tramite l'uso del corpo della richiesta

Consideriamo un'applicazione che gestisce l'operazione e i relativi parametri tramite il corpo della richiesta in formato JSON. Ad esempio, lookup_price l'operazione potrebbe essere simile alla seguente:

POST https://api.store.com/merchant
Cookie: session_id=12345
Body:
{
  "action": "lookup_price",
  "product_id": 215
}

In questo scenario, è possibile creare la seguente regola per limitare il numero di azioni delle singole sessioni:

Regola: limitare le azioni di ricerca per sessione
Impostazione Valore
Criteri di corrispondenza Il percorso URI è uguale a /merchant e la stringa JSON è action uguale a lookup_price
Espressione http.request.uri.path eq "/merchant" and lookup_json_string(http.request.body.raw, "action") eq "lookup_price"
Caratteristiche di conteggio Cookie (session_id)
Frequenza (richieste/periodo) 10 richieste / 2 minuti
Azione Sfida Gestita

Questa regola di esempio richiede la limitazione avanzata della velocità e l'ispezione del payload.

È inoltre possibile limitare il numero di ricerche di ciascuno, product_id indipendentemente dal client che effettua le richieste, implementando una regola come la seguente:

Regola: limitare le richieste di ricerca per ID prodotto
Impostazione Valore
Criteri di corrispondenza Il percorso URI è uguale a /merchant e il campo JSON è action uguale a lookup_price
Espressione http.request.uri.path eq "/merchant" and lookup_json_string(http.request.body.raw, "action") eq "lookup_price"
Caratteristiche di conteggio Campo JSON (product_id)
Frequenza (richieste/periodo) 50 richieste / 10 secondi
Azione Blocca

Questa regola di esempio richiede la limitazione avanzata della velocità e l'ispezione del payload.

Se il corpo della richiesta non è in formato JSON, è possibile utilizzare il http.request.body.raw campo e le espressioni regolari (insieme all'operatore matches) per ottenere lo stesso risultato.

Limitazione delle richieste provenienti dai bot

È possibile utilizzare la limitazione della velocità per controllare il traffico automatizzato proveniente dai bot. Un approccio comune consiste nel monitorare le richieste che restituiscono un numero elevato di codici di stato 403 della risposta 404 o, che spesso indicano un'attività di scraping automatizzata.

In questa situazione, è possibile configurare una regola simile alla seguente:

Regola: limitare le richieste in base ai codici di stato della risposta
Impostazione Valore
Criteri di corrispondenza Il nome host è uguale a example.com
Espressione http.host eq "example.com"
Caratteristiche di conteggio IP
Aumenta il contatore quando Il codice di stato della risposta è (401, 403)
Espressione di conteggio http.response.code in {401 403}
Frequenza (richieste/periodo) 5 richieste / 3 minuti
Azione Sfida Gestita

Questa regola di esempio richiede un piano Business o superiore.

Per controllare la frequenza delle azioni eseguite da fonti automatizzate, prendi in considerazione l'utilizzo di regole di limitazione della frequenza insieme alla gestione dei bot. Con Bot Management, è possibile utilizzare il punteggio bot come parte dei criteri di corrispondenza per applicare la regola solo al traffico automatizzato o probabilmente automatizzato. Ad esempio, è possibile utilizzare un punteggio massimo (o soglia) di 30 per il traffico probabilmente automatizzato e 10 per il traffico automatizzato.

È possibile migliorare la protezione combinando la limitazione della velocità con la gestione dei bot. Con Bot Management, è possibile utilizzare il punteggio bot come parte dei criteri di corrispondenza per applicare la regola solo al traffico automatizzato o probabilmente automatizzato.

Ad esempio:

  • Un punteggio bot inferiore a 30 indica probabilmente traffico automatizzato.
  • Un punteggio bot inferiore a 10 rappresenta traffico automatizzato confermato.

Limitazione delle richieste per sessione

Se la tua applicazione utilizza cookie di sessione, utilizza il cookie come caratteristica di conteggio. Questo metodo raggruppa le richieste provenienti da diversi indirizzi IP all'interno della stessa sessione, utile per rilevare attacchi bot distribuiti.

Regola 1

Limita la richiesta per i bot con punteggio inferiore a 30
Impostazione Valore
Criteri di corrispondenza Punteggio bot inferiore a 30 e stringa di query URI contiene action=delete
Espressione cis.bot_management.score lt 30 and http.request.uri.query contains "action=delete"
Caratteristiche di conteggio Cookie (session_id)
Frequenza (richieste/periodo) 10 richieste / 1 minuto
Azione Sfida Gestita

Rule 2

Limita la richiesta per i bot con punteggio inferiore a 10
Impostazione Valore
Criteri di corrispondenza Punteggio bot inferiore a 10 e stringa di query URI contenente action=delete
Espressione cis.bot_management.score lt 10 and http.request.uri.query contains "action=delete"
Caratteristiche di conteggio Cookie (session_id)
Frequenza (richieste/periodo) 20 richieste / 5 minuti
Azione Blocca

Queste regole di esempio richiedono la limitazione avanzata della velocità e la gestione dei bot.

Utilizzo JA3 delle impronte digitali

Se l'applicazione non utilizza un cookie di sessione, è possibile utilizzare JA3 le impronte digitali per identificare i singoli clienti. Un 'impronta JA3 digitale è un identificatore univoco, disponibile per i clienti con Bot Management, che consente CIS di identificare le richieste provenienti dallo stesso client. Tutti i clienti hanno un'impronta digitale associata, indipendentemente dal fatto che siano automatizzati o meno.

Limita la richiesta utilizzando JA3 Fingerprint
Impostazione Valore
Criteri di corrispondenza Percorso URI uguale a /merchant e punteggio bot inferiore a 10
Espressione http.request.uri.path eq "/merchant" and cf.bot_management.score lt 10
Caratteristiche di conteggio JA3 Impronta digitale
Frequenza (richieste/periodo) 10 richieste / 1 minuto
Azione Sfida Gestita

Questa regola di esempio richiede la limitazione avanzata della velocità e la gestione dei bot.

Protezione delle API REST

Le API REST possono creare un carico elevato sui sistemi backend perché le richieste API spesso richiedono un'elaborazione intensiva o ricerche di dati di grandi dimensioni. L'accesso incontrollato alle API può causare un calo delle prestazioni o addirittura tempi di inattività. Utilizza la limitazione avanzata della velocità per prevenire abusi, mitigare attacchi volumetrici e proteggere le risorse critiche.

Protezione delle risorse

Anche GET le richieste possono sovraccaricare l'applicazione o consumare larghezza di banda quando vengono utilizzate per il download di dati di grandi dimensioni, come file o immagini.

Ad esempio, considera il seguente endpoint:

GET https://api.store.com/files/<FILE_ID>
Header: x-api-key=9375

Per prevenire abusi consentendo al contempo download legittimi, è possibile definire una regola che limiti le richieste di file senza scrivere regole separate per ciascun file.

Regola — Limita il download dei file in base al percorso
Impostazione Valore
Criteri di corrispondenza Il nome host è uguale a api.example.com e il metodo di richiesta è uguale a GET
Espressione http.host eq "api.example.com" and http.request.method eq "GET"
Caratteristiche di conteggio Percorso
Frequenza (richieste/periodo) Come suggerito da API Discovery o valutato analizzando il traffico passato.
Azione Blocca

Questa regola di esempio richiede la limitazione avanzata della velocità.

Questa regola limita i download a 10 richieste ogni 10 minuti per ogni file con estensione https://api.store.com/files/*. Utilizzando Path come caratteristica di conteggio, è possibile evitare di creare nuove regole per ogni nuovo <FILE_ID>. La tariffa è calcolata per file, indipendentemente dall'IP del cliente o dall'ID della sessione.

È possibile rafforzare ulteriormente la protezione combinando Path con un identificatore client come x-api-key o IP. Questo approccio consente di limitare il numero di download che un determinato cliente può effettuare per un dato file.

Regola — Limita i download dei file in base al percorso e all'intestazione
Impostazione Valore
Criteri di corrispondenza Il nome host è uguale a api.store.com e il metodo di richiesta è uguale a GET
Espressione http.host eq "api.example.com" and http.request.method eq "GET"
Caratteristiche di conteggio Percorso e intestazione (x-api-key)
Frequenza (richieste/periodo) Come suggerito da API Discovery o valutato analizzando il traffico passato.
Azione Blocca

Questa regola di esempio richiede la limitazione avanzata della velocità.

Protezione GraphQL delle API

Prevenire il sovraccarico del server per GraphQL le API può essere diverso dal prevenire il sovraccarico per le API RESTful. Una delle maggiori sfide poste dalle applicazioni basate su GraphQL è che un unico percorso gestisce tutte le query al server e ogni richiesta è solitamente un'operazione POST. Ciò impedisce la creazione di limiti di velocità diversi per API diverse in base al HTTP metodo e al percorso URI.

Tuttavia, invece di utilizzare il metodo e il percorso come un'API RESTful, lo scopo della richiesta è solitamente incorporato nel corpo, che contiene informazioni sui dati che il client desidera recuperare o modificare (secondo GraphQL's la terminologia relativa alla modifica dei dati lato server), insieme a eventuali dati aggiuntivi necessari per eseguire l'azione.

Per evitare il sovraccarico del server, prendere in considerazione i seguenti approcci:

  • Limita il numero di volte in cui un determinato utente può richiamare lo stesso nome GraphQL operazione.
  • Limitare la complessità totale delle query che un determinato utente può richiedere.
  • Limitare la complessità delle query delle singole richieste.

Gli esempi seguenti si basano su un'applicazione che accetta recensioni di film.

POST https://moviereviews.example.com/graphql
Cookie: session_id=12345
Body:
{
  "data": {
    "createReview": {
      "stars": 5,
      "commentary": "This is a great movie!"
    }
  }
}

Limitare il numero di operazioni

Per limitare la frequenza delle azioni, crea la seguente regola:

Limitare il numero di operazioni
Impostazione Valore
Criteri di corrispondenza Il percorso URI è uguale a /graphql e il corpo contiene createReview
Espressione http.request.uri.path eq "/graphql" and http.request.body.raw contains "createReview"
Caratteristiche di conteggio Cookie (session_id)
Frequenza (richieste/periodo) 5 richieste / 1 ora
Azione Blocca

Questa regola di esempio richiede la limitazione avanzata della velocità e l'ispezione del payload.

Limitare la complessità totale delle query

La complessità della gestione di una GraphQL richiesta può variare in modo significativo. Poiché l'API utilizza un unico endpoint, può essere difficile determinare la complessità di ciascuna richiesta prima che venga elaborata.

Per evitare l'esaurimento delle risorse sul server di origine, limitare la complessità totale delle richieste per cliente nel tempo, piuttosto che limitare il numero di richieste. CIS La limitazione della velocità consente di creare regole che monitorano la complessità nel tempo e bloccano le richieste che superano un budget di complessità definito.

Questo metodo richiede che il server di origine assegni un punteggio di complessità a ciascuna richiesta e includa tale punteggio nell'intestazione HTTP della risposta. Il meccanismo di limitazione della velocità utilizza quindi le informazioni sul punteggio per aggiornare il budget di complessità per quel cliente specifico.

L'esempio seguente definisce un budget di complessità totale di 1.000 all'ora:

Limitare la complessità totale delle query
Impostazione Valore
Criteri di corrispondenza Il percorso URI contiene /graphql
Espressione http.request.uri.path eq "/graphql"
Caratteristiche di conteggio Cookie (session_id)
Punteggio per periodo 1.000
Punto 1 ora
Nome dell'intestazione della risposta score
Azione Blocca

Questa regola di esempio richiede la limitazione avanzata della velocità e l'ispezione del payload.

Quando il server di origine elabora una richiesta, aggiunge scoreHTTP un'intestazione alla risposta con un valore che indica la quantità di lavoro che l'origine ha svolto per gestirla. Ad esempio, 100. Nell'ora successiva, lo stesso cliente può effettuare richieste fino a un budget aggiuntivo di 900. Non appena questo budget viene superato, le richieste successive vengono bloccate fino alla scadenza del timeout.

Limitare la complessità di ogni singola query

I clienti API Shield possono utilizzare la GraphQL protezione dalle query dannose per proteggere le loro GraphQL API. Questa funzione esegue la scansione del GraphQL traffico in entrata alla ricerca di query che potrebbero sovraccaricare il server di origine e causare una condizione di denial-of-service.

È possibile creare regole per limitare la profondità e la dimensione delle query in GraphQL entrata. Queste regole aiutano a bloccare le query sospette o eccessivamente complesse prima che influiscano sulle prestazioni.