Come proteggere un utente OpenID dagli abusi?

Question

Sto considerando OpenID come metodo di accesso per la mia applicazione PHP, ma c'è una cosa che mi impedisce di continuare: come posso proteggere un consumatore OpenID dagli abusi?

An example of abusing OpenID by using a consumer as proxy

di abuso comprende inondando altri server con le richieste, usando la mia applicazione come un proxy, il superamento di un download di grandi dimensioni come URL o inutilmente rallentare il server facendo un sacco di richieste.

Immagino che dovrei implementare il limite di velocità per fare richieste, ma come dovrei farlo? I possibili attaccanti potrebbero usare altri proxy o TOR per bypassare i controlli IP. Limitare i fornitori consentiti sarebbe contrario ai principi di OpenID giusto?

Non mi aspetto che i miei utenti siano malvagi, ma mi piacerebbe sapere quali elementi devo tenere in considerazione prima di aggiungere un altro possibile vettore di attacco.

Se è importante, sto per utilizzare lightopenid come back-end per l'applicazione PHP.

Answer 1

È necessario separare gli attacchi in due pool. 1) Attacchi contro il tuo sito e 2) Attacchi contro qualcun altro che ti utilizza come proxy. Nessuno di questi problemi è nuovo o unico per OpenID. Ad esempio, i classici moduli di posta elettronica "tell a friend" potrebbero essere automatizzati per inviare spam e-mail dall'indirizzo IP e dall'e-mail della parte proxy, proteggendo la parte spam dalle conseguenze e fornendo loro un IP (potenziale) pulito/e-mail che non è già contrassegnato dalla protezione antispam. Questo è stato principalmente affrontato con il "CAPTCHA" per impedire l'uso automatizzato del modulo.

Per gli attacchi contro il tuo sito, tutto questo è stato coperto innumerevoli volte prima. Prova qui: protect your self against DOS attacks

Per gli attacchi contro il sito di qualcun altro, molti degli stessi principi si applicano come menzionato in quell'altra domanda. Richieste di autenticazione di Throttle, rifiuto di richieste irragionevoli o malformate, verifica che l'intestazione Content-Length sia effettivamente presente sul retro dei POST e, naturalmente, puoi sempre aggiungere il classico "CAPTCHA" per prevenire attacchi automatici che utilizzano il tuo consumer OpenID.

Contrariamente ad altri suggerimenti qui, non potrei limitare basato sul TLD OpenID, ma piuttosto l'indirizzo IP della parte richiedente. Sì, le persone possono noleggiare IP proxy, ma non è possibile limitare il regime basato sul TLD, poiché la base utente per ciascun provider OpenID varierà ampiamente.È inoltre possibile acquistare un database di IP proxy conosciuti da un'azienda come MaxMind. Se l'utente proviene da un IP proxy, aumentare l'aggressività della limitazione.

Answer 2

Rallenta le richieste in proporzione al numero di volte in cui è stato richiesto un determinato dominio.

Per esempio, supponiamo che qualcuno cerca di utilizzare di DOS server example.com richiedendo molti URL come http://example.com/foo, http://example.com/bar, http://example.com/foobar120382. Considerare tutte queste richieste come richieste per example.com ed eseguire la prima richiesta senza alcun ritardo. Ritardare 2 secondi prima di effettuare la richiesta successiva, ritardare 4 secondi prima di effettuare la terza richiesta, ritardare 8 secondi prima di effettuare la quarta richiesta, 16 prima della quinta e così via.

Tali piccoli ritardi sono praticamente inosservati dagli utenti umani, ma ridurranno notevolmente la capacità del server di agire come proxy di DOS. Basti pensare che la dodicesima richiesta verrà bloccata per più di un'ora (se si usano le potenze di due).

Ovviamente si dovrebbe anche creare una sorta di lista bianca o grigia per i comuni provider OpenID di grandi dimensioni come Google o myOpenID. È probabile che questi domini vengano richiesti molto spesso.

Answer 3

Farei qualcosa di più semplice. Limita gli endpoint OpenID a un insieme limitato di trusted: Google, wordpress, myopenid, yahoo. Probabilmente coprirà la maggior parte degli utenti e non consentirà ai bot di generare traffico verso siti casuali.