HTTPS è abbastanza per evitare attacchi di replay?

10

Sto esponendo alcuni metodi REST su un server per un'app mobile.

Vorrei evitare che gli utenti possano annusare la modalità di creazione dei metodi HTTP (dall'app mobile) e inviarli di nuovo al server. Esempio :

L'app mobile invia una richiesta
L'utente utilizza un proxy e può verificare cosa sta succedendo sulla rete
L'utente vede e salva la richiesta che il cellulare ha appena inviato
=> Ora non voglio che l'utente sia in grado di inviare manualmente tale richiesta

È sufficiente proteggere il server su HTTPS?

api https

— MartinMoizard
fonte

7

HTTPS può essere sufficiente per proteggere il server dagli attacchi di riproduzione (lo stesso messaggio viene inviato due volte) se il server è configurato per consentire solo il protocollo TLS secondo la sezione F.2 di rfc2246.

I dati in uscita sono protetti con un MAC prima della trasmissione. Per impedire la riproduzione di messaggi o attacchi di modifica, il MAC viene calcolato dal segreto MAC, il numero di sequenza [...]

— Emirikol
fonte

1

Questo non è più vero con (bozza) TLS 1.3 se i ticket 0-RTT sono abilitati. Inoltre, anche se non strettamente nell'ambito della domanda, un attacco di riproduzione può ancora essere montato anche con le attuali versioni TLS se si utilizza un browser Web .

— Alex Shpilkin,

9

HTTPS significa semplicemente che i dati trasportati sono crittografati in modo che solo il client e il server possano decrittografarli (in un mondo ideale, senza parlare di attacchi MITM ecc.).

Pertanto, nulla nel protocollo impedirà che si verifichino attacchi replay.

Dovrai creare una sorta di meccanismo di prevenzione degli attacchi di replay (qualcosa come i token in scadenza o i token che si invalidano al termine del processo) per garantire che l'applicazione non sia vulnerabile agli attacchi di replay. Questo meccanismo può essere utilizzato con HTTP normale.

— Oded
fonte

8

Questa risposta sembra suggerire il contrario: stackoverflow.com/questions/2769992/… Qualche idea sul perché la differenza?

— Brian Armstrong,

1

@BrianArmstrong Penso che il problema sia che HTTPS ha implementazioni diverse, come indicato dalla risposta di Emirikol. Alcuni protocolli prevengono gli attacchi di riproduzione, mentre altri no. (Succede quando si fa lo scambio di chiavi, lo scambio di chiavi RSA impedisce ma lo scambio di chiavi anonime no. Ref: tools.ietf.org/html/draft-ietf-tls-ssl-version3-00#appendix-F ) Ecco perché token ( come CSRF) sono importanti (scenario di riferimento è qui: stackoverflow.com/a/2770135/4206925 )

— MewX