Protezione pulita ed economica per le richieste HTTP di registrazione degli utenti?

Question

Protezione pulita ed economica per le richieste HTTP di registrazione degli utenti?

#1 da (0 voti)

0

Sto sviluppando un sito Web che ha la registrazione dell'utente. Ho già sviluppato alcune tecniche di protezione del limite di velocità usando nginx e un livello inferiore usando iptables, ma sono preoccupato per attacchi reali come l'ip-spoofing o DDoS.

L'unica soluzione che conosco è il CAPTCHA di Google, che viene utilizzato anche da grandi aziende come Reddit e Gitlab. Il problema è che non è amichevole sui dispositivi mobili e tablet, e inoltre mette i visitatori fuori.

Esistono metodi puliti ed economici per le alluvioni di richieste HTTP POST? Ho pensato di aggiungere un token casuale temporaneo ai parametri POST che è memorizzato anche sul mio server per uno o due secondi usando Redis per verificare se la richiesta è automatizzata (cioè veloce) o da un umano (lento). Non voglio convincermi che questa è una soluzione affidabile poiché non sono un esperto di sicurezza.

http captcha ddos

posta Ejonas GGgg 16.01.2017 - 13:02

fonte

1 risposta

Leggi altre domande sui tag http captcha ddos

Come connettersi ad AP quando l'attaccante sta abbellendo il mio dispositivo? Script NMAP NSE 'http-verb-tamper' non funziona come previsto

score 0 · Accepted Answer

Sto facendo fatica ad immaginare come questo possa fornire una protezione contro lo spoofing. Indipendentemente dal fatto che l'IP-spoofing su una connessione TCP sia difficile da ottenere, ti consiglio di ignorarlo per ora.

In termini di protezione DOS, vorrei raccomandare cautela. Quanto più sofisticate sono le tue misure di protezione, tanto più diventano un collo di bottiglia e quindi sfruttabili da DOS.

I thought to add a temporary random token to POST parameters that is stored also on my server for one or two seconds

Suona piuttosto costoso per me. Vuoi davvero ridurre al minimo la quantità di informazioni che stai catturando / tentando di memorizzare su potenziali richieste DOS.

Una soluzione è riporre il costo di archiviazione sul client: creare un cookie sul browser in una pagina precedente contenente valori crittografati su server che indicano alcuni attributi sul client (come l'indirizzo IP o ASN, browser ...) e un timestamp di livello millisecondo usando javascript e convalidarlo nella richiesta POST.

Nota che devi pensare a come convalidare un indirizzo IP che può estendersi su più di una sessione.

L'eliminazione del cookie e l'uso di javascript convalidano che il client è un browser (o un facsimile abbastanza sofisticato) che ha visitato altre pagine del tuo sito. Un breve intervallo tra la generazione del timestamp e il cookie presentato indica un attacco con script.

rate-limit protection techniques using nginx and at a lower level using iptables

Presumo che tu abbia assicurato che questi non hanno un impatto sulla capacità e hai ridimensionato la tua tabella conntrack.