Come impedire agli autori di attacchi di duplicare gli invii?

3

Voglio creare un sito web di sondaggi. Un client richiede di rispondere al sondaggio usando POST e il server risponde con i candidati. Il client invia quindi un POST con le informazioni del candidato e il vincitore al server, che quindi memorizza le informazioni. Voglio impedire a un cliente di manipolare i risultati inviando ripetutamente il proprio voto al server. Un modo in cui pensavo fosse:

  1. Il client richiede di votare nel sondaggio.
  2. Server invia una lista di candidati, data / ora e un hash salato creati utilizzando i candidati e il timestamp. Il server quindi memorizza l'hash.
  3. Il cliente sceglie un candidato e rimanda il vincitore con la lista dei candidati, il timestamp e l'hash salato.
  4. Il server calcola l'hash con lo stesso sale e controlla se l'hash è un hash valido come memorizzato nel database. Se l'hash è valido, onora il voto. In caso contrario, silenziosamente non riesce a evitare di avvisare l'utente malintenzionato o risponde con un errore.

Voglio trovare un modo più elegante per farlo anche se. Innanzitutto, ho problemi a pensare a un sale che non è statico. Non voglio che l'utente sia limitato dall'indirizzo IP, quindi non può essere incluso nel sale. Dopo non riesco a pensare a un buon modo di salare il mio hash.

In secondo luogo, voglio trovare un modo per non dover memorizzare le informazioni sul server. Se potessi creare un metodo di validazione che possa essere calcolato rapidamente anziché memorizzato, sarebbe meglio (a meno che l'archiviazione non sia definitivamente migliore del computing perché potrebbe essere più veloce?).

In terzo luogo, dovrei fallire silenziosamente o informare esplicitamente il cliente di un errore?

    
posta umop aplsdn 05.09.2015 - 01:06
fonte

2 risposte

3

Sembra che tu abbia davvero due problemi qui:

  • Prevenzione degli attacchi di riproduzione.

  • Impedire allo stesso cliente di votare due volte.

Questi sono sottilmente diversi. Un attacco di replay sta semplicemente inviando una richiesta più volte, forse con leggere variazioni, ed eventualmente da una terza parte. Votare più volte è proprio questo: votare legittimamente più di una volta.

Il problema principale qui è non sai chi sono i client . Cosa succede se un client sposta le posizioni (IP o subnet)? È un nuovo cliente? Anche se pensi di sapere chi sono, a livello astratto, non lo fai.

Questo non è un nuovo problema. In generale, la maggior parte di Internet risolve questo problema richiedendo che i clienti creino account. L'autenticazione avviene su TLS, assicurando che un client sia quello che dicono di essere. Fatto ciò, il client può inviare il proprio voto sulla connessione TLS dove il server lo memorizza nel database. Un ID cliente (ad es. Indirizzo email o nome account), un voto.

Questo impedisce attacchi di riproduzione: TLS è già temprato contro questi attacchi di progettazione. Ciò impedisce anche il voto più volte: i voti sono collegati all'ID account nel database, rendendo banalmente facile vedere se un determinato cliente ha già votato. Basta avere una chiave primaria multiparte composta da ID sondaggio e ID account. Un altro campo memorizza il voto. Puoi aggiungere metadati opzionali come l'indirizzo IP e la data / ora del voto.

Non c'è alcun motivo per reinventare la ruota qui: TLS e alcuni progetti di base del database possono facilmente risolvere il tuo problema e molto meglio di qualsiasi soluzione sviluppata in loco.

    
risposta data 09.09.2015 - 03:27
fonte
0
  1. È possibile utilizzare il numero di riga della tabella in cui il record viene archiviato come sale? (o una funzione di questo numero univoco).
  2. Vorrei memorizzare le informazioni sul server, solo perché in linea di principio non mi fiderei mai del client in Internetland. Se vuoi davvero memorizzare le informazioni sul client, lo firmi digitalmente o lo crittografa utilizzando la tua chiave privata e verificandolo o decrittandolo al momento del voto. Se questo è accettabile dipende dalla natura del sondaggio: per l'elezione a un ufficio pubblico, sceglierei il server, dove andare a pranzo in gruppo, sceglierei il server anche per quello.
  3. Dai un feedback (e registralo), altrimenti corri il rischio che nessuno sappia nemmeno se i voti legittimi vengono pizzicati e utilizzati prima che il vero elettore abbia il tempo di votare.
risposta data 09.09.2015 - 02:20
fonte

Leggi altre domande sui tag