È meglio valutare le richieste API basate su UserId o indirizzo IP per gli utenti autenticati?

0

Sto pensando di limitare la frequenza delle richieste anonime basate su IP, ma per gli utenti con un token di autenticazione valido, non riesco a decidere se è meglio registrare e valutare le richieste limite in base al loro UserId o indirizzo IP.

Opzione 1 : 15 richieste al minuto per UserId

Opzione 2 : 30 richieste al minuto per indirizzo IP

Opzione 3 : esegui entrambi

Se una persona / entità malevola decide di eseguire un attacco bot contro le API, l'opzione migliore sembra essere la limitazione della velocità in base all'indirizzo IP perché possono potenzialmente avere molti token pronti per gli utenti con diversi, per esempio, indirizzi email (supponendo che ogni utente si registri con un indirizzo email univoco).

Tuttavia, esiste anche la possibilità che un individuo sofisticato possa cambiare indirizzo IP durante l'attacco ma passare lo stesso token di autenticazione e abusare del sistema con lo stesso UserId.

La terza opzione sembra allettante, ma per me significa che ogni richiesta API deve essere scritta due volte nel database (i record sono partizionati orizzontalmente in base a UserId e c'è un altro schema di partizionamento basato sull'indirizzo IP. Sharding renderà più semplice per cercare e contare le richieste).

Esistono buone pratiche per quanto riguarda l'opzione (o qualcos'altro) da perseguire quando si limitano gli utenti autenticati? Mi piacerebbe avere un'idea generale di cosa fare prima di scrivere a fondo tutta la logica di validazione?

    
posta user246392 13.11.2018 - 19:29
fonte

3 risposte

1

Direi che dipende. In generale, il blocco IP è una buona pratica in quanto l'IP è l'unico identificatore esistente per gli utenti anonimi. Ma tieni presente che un utente può "cambiare" gli IP usando i servizi proxy online E d'altra parte che forse più utenti condividono un IP identico quando usano un server proxy (che spesso è il caso negli ambienti aziendali).

Se i tuoi utenti sono autenticati, dovresti bloccare l'ID utente quando l'utente sta facendo cose dannose.

Un altro aspetto: quanto è facile per un utente anonimo creare un nuovo account nella tua app? Quando è in grado di creare nuovi account senza problemi, il blocco di userIds è inutile, perché quando l'utente malintenzionato 1 è bloccato, può facilmente creare un nuovo utente.

Quindi dovresti fare affidamento su entrambi i techniqus e verificare quanto sia facile per un individuo creare nuovi account.

    
risposta data 13.11.2018 - 20:06
fonte
0

Aggiungerò l'uso di geoip, in alcuni casi è auspicabile che tu possa bloccare direttamente i paesi che non hanno nulla da appartenere al tuo servizio così come l'elenco bianco per i Paesi di cui hai più fiducia.

    
risposta data 13.11.2018 - 22:54
fonte
0

Entrambi. Proteggono da diversi stili di attacco.

Invece di dividere il database, puoi utilizzare Fail2Ban per il blocco IP e attaccare con l'applicazione / monitoraggio interno solo per il blocco degli utenti.

Se hai un log da qualche parte per le richieste, puoi concedere l'accesso in lettura a Fail2Ban per fare il suo lavoro senza nemmeno toccare il tuo database.

Se questa è la tua applicazione, puoi implementare un log minimalista solo per Fail2Ban. Se si tratta di un'applicazione commerciale, dovrai scoprire come e dove registrano le richieste in entrata.

    
risposta data 13.12.2018 - 23:23
fonte

Leggi altre domande sui tag