Le HTTPS est-il suffisant pour éviter les attaques de rejeu?

10

J'expose quelques méthodes REST sur un serveur pour une application mobile.

Je voudrais éviter que les utilisateurs puissent flairer la façon dont les méthodes HTTP sont construites (à partir de l'application mobile), puis les renvoyer au serveur. Exemple :

L'application mobile envoie une demande
L'utilisateur utilise un proxy et peut vérifier ce qui se passe sur le réseau
L'utilisateur voit et enregistre la demande que le mobile vient d'envoyer
=> Maintenant, je ne veux pas que l'utilisateur puisse envoyer manuellement cette demande

Est-ce suffisant pour sécuriser le serveur via HTTPS?

api https

— MartinMoizard
source

7

HTTPS peut être suffisant pour sécuriser le serveur contre les attaques de relecture (le même message étant envoyé deux fois) si le serveur est configuré pour autoriser uniquement le protocole TLS conformément à la section F.2 de rfc2246.

Les données sortantes sont protégées par un MAC avant transmission. Pour éviter les attaques de rejeu ou de modification de message, le MAC est calculé à partir du secret MAC, le numéro de séquence [...]

— Emirikol
source

1

Ce n'est plus le cas avec (draft) TLS 1.3 si les tickets 0-RTT sont activés. De plus, bien que n'étant pas strictement dans la portée de la question, une attaque de relecture peut toujours être montée même avec les versions TLS actuelles si vous utilisez un navigateur Web .

— Alex Shpilkin

9

HTTPS signifie simplement que les données transportées sont cryptées afin que seuls le client et le serveur puissent les décrypter (dans un monde idéal, sans parler des attaques MITM, etc.).

En tant que tel, rien dans le protocole n'empêchera les attaques de rejeu de se produire.

Vous devrez créer une sorte de mécanisme d'évitement d'attaque de relecture (quelque chose comme des jetons expirants ou des jetons qui invalident une fois le processus terminé) pour vous assurer que votre application n'est pas vulnérable aux attaques de relecture. Ce mécanisme peut être utilisé avec HTTP normal.

— Oded
source

8

Cette réponse semble suggérer le contraire: stackoverflow.com/questions/2769992/… Une idée pourquoi la différence?

— Brian Armstrong

1

@BrianArmstrong Je pense que le problème est que HTTPS a différentes implémentations comme mentionné par la réponse d'Emirikol. Certains protocoles empêchent les attaques par relecture, tandis que d'autres ne le font pas. (Cela se produit lors de l'échange de clés, l'échange de clés RSA empêche mais l'échange de clés anonyme ne le fait pas. Ref: tools.ietf.org/html/draft-ietf-tls-ssl-version3-00#appendix-F ) C'est pourquoi les jetons ( comme csrf) sont importants (le scénario de référence est ici: stackoverflow.com/a/2770135/4206925 )

— MewX