Que faire si l'attaquant décide de falsifier le "from: id" afin qu'il puisse envoyer des messages arbitraires à n'importe qui de n'importe quel utilisateur?

Créez une session et utilisez le identifiant de session comme identifiant, pas directement l'ID utilisateur. Par exemple. laissez l'utilisateur envoyer les informations d'identification, et après validation réussie, renvoyez un descripteur de session (de courte durée), qui peut être utilisé dans les messages futurs.

Validez que la session existe et est active, et mappez-la au serveur utilisateur -side.

Que se passe-t-il si l'attaquant crée un script qui spams des millions de messages en tirant parti du champ "to: id"?

Limite de débit côté serveur des utilisateurs. Par exemple, interdisez l'envoi de messages à plus de dix utilisateurs différents par minute. Cela ne dérangera probablement pas les utilisateurs légitimes, mais entravera les efforts des spammeurs. Le réglage de la limite peut évidemment être nécessaire - et il peut être judicieux de l'augmenter pour les utilisateurs de confiance, en fonction du comportement, et de l'abaisser lors de la réception de rapports sur le spam des utilisateurs.

En gros, vous devez traiter chaque entrée de l'utilisateur comme potentiellement malveillante.

Vidarlo a déjà mentionné deux problèmes de sécurité et comment ils peuvent être évités dans sa réponse.

J'ajouterais également que le contenu lui-même ("text:") pourrait contenir du code malveillant (par exemple, des extraits de code javascript). Assurez-vous que ce code n'est pas exécuté à la réception.

Et je vérifierais également si l'heure semble correcte. Selon votre application, la vérification des horodatages peut être utile, voire nécessaire.

Que faire si l'attaquant décide de falsifier le "from: id" afin qu'il puisse envoyer des messages arbitraires à n'importe qui de n'importe quel utilisateur?

Ne pas utiliser from: id dans votre API. Vous le connaissez déjà à partir d'une session authentifiée par l'utilisateur et vous n'avez aucune raison pour que l'utilisateur vous le transmette en premier lieu. Et s'il n'y a rien à transmettre, il n'y a rien à falsifier.

Sur cette note, jetez aussi la date et l'heure. Vous savez déjà quand vous avez reçu un message et vous n'avez pas besoin que l'utilisateur vous le dise. Vous n'en aurez besoin que si votre application et votre API ont un concept de messages hors ligne / programmés / en attente.

Et si l'attaquant construisait un script qui spammait des millions de messages en tirant parti du " to: id "field?

C'est un problème assez ancien, même classique, qui a des solutions différentes, tout comme les anciennes. L'un des plus simples est d'introduire un timeout: le backend se souvient quand l'utilisation a envoyé un message et il ne peut rien envoyer avant qu'un certain délai ne soit écoulé. Une solution plus complexe se résume toujours à limiter l'utilisateur à un certain nombre de messages par période de temps, mais utilise des délais de plus en plus importants qui diminuent avec le temps à mesure que davantage de messages sont envoyés. Recherchez «limitation» ou «limite de débit» pour certains exemples et idées.

Voici une vision légèrement différente de la manière dont ces problèmes pourraient être résolus. Je suppose que l'authentification et la gestion de session sont correctement implémentées.

Que faire si l'attaquant décide de falsifier le "from: id" de sorte qu'il puisse envoyer des messages arbitraires à n'importe qui de n'importe quel utilisateur?

Si vous générez un identifiant unique (long, aléatoire, très difficile à deviner, comme un identifiant de session) pour chaque "salle de chat" au moment de la création et assurez-vous que toutes les parties sont heureuses de rejoindre cette salle de discussion, vous pouvez l'utiliser à la place des identifiants d'utilisateur et contrôler les salles de discussion auxquelles chaque utilisateur peut envoyer un message, pour vous assurer que d'autres ne peuvent pas envoyer de contenu aux discussions privées de quelqu'un d'autre; Ainsi, vos messages des utilisateurs X et Y seraient envoyés à la salle de discussion A et l'application les enverrait. L'utilisateur Z n'a pas été autorisé à entrer, l'application refuse donc de transmettre le message.

Que se passe-t-il si l'attaquant crée un script qui spams des millions de messages en profitant du champ "to: id"?

Assurez-vous que les messages ne peuvent pas être adressé aux identifiants d'utilisateurs et s'efforcer de rendre les identifiants d'utilisateurs difficiles à deviner.

Que faire si l'attaquant décide de falsifier le "from: id" afin qu'il puisse envoyer des messages arbitraires à n'importe qui de n'importe quel utilisateur?

Une autre option est de donner à chaque utilisateur un ensemble de clés publiques et privées. Ceux-ci peuvent être utilisés pour générer une signature pour chaque message qui vérifie que le contenu n'a pas été falsifié et provient de l'utilisateur spécifié.

Disons que l'utilisateur 1 veut envoyer un message à l'utilisateur 2, une simplification processus serait:

• l'utilisateur 1 reçoit une paire de clés publique / privée. Ils (ou le serveur) exposent leur clé publique à d'autres utilisateurs.
• l'utilisateur 1 crée le contenu du message, puis génère une signature pour celui-ci en utilisant sa propre privée key (ils gardent ce secret)
• l'utilisateur 1 envoie le message dans un paquet qui ressemble à quelque chose comme

  {"Signature": "kA7dagf4. .. ", Contenu: {date: '2020-05-31', heure: '14: 28: 05 ', texte:" Hey! "...  

• l'utilisateur 2 reçoit le message, puis utilise la clé publique de l'utilisateur 1 pour vérifier que le contenu du message correspond à la signature

L'essentiel est que la clé publique ne peut être utilisée pour vérifier la signature - il n'est pas possible de créer une signature sans la clé privée.

Tout acteur malveillant qui souhaite se faire passer pour l'utilisateur 1 et envoyer un message à l'utilisateur 2 ne le pourra pas, car il ne le fera pas être capable de créer une signature qui est vérifiée par la clé publique de l'utilisateur 1. Ainsi, l'utilisateur 2 verrait que la signature n'est pas valide et pourrait rejeter le message lorsqu'il le reçoit.

C'est à peu près ainsi que fonctionnent les jetons Web JSON - je suggère de lire cela pour plus d'informations - https://jwt.io/introduction/

Et si l'attaquant construisait un script qui spammait des millions de messages en profitant du champ "to: id"?

Comme mentionné dans les réponses précédentes, une combinaison de limitation de débit et de rendre les champs to: id et from: id difficiles à deviner.

Il est évident que les données ne sont pas chiffrées. Vous avez déjà mentionné la falsification et souvent le cryptage et l'intégrité sont traités en même temps car le cryptage sans intégrité vous laisse toujours ouvert aux attaques

Ajoutez un MAC (code d'authentification de message) pour les données. Certains modes de cryptage comme GCM (Galois / Counter Mode) en incluent un, d'autres sont séparés, vous pouvez donc utiliser HMAC avec autre chose. Tuez 2 oiseaux avec une pierre pour ainsi dire, ou utilisez simplement 2 pierres. Cela protégera-t-il l'utilisateur contre une attaque de votre côté de l'API? Vous devez également réfléchir à ce qui se passe si vous êtes compromis.

Vous pouvez regarder d'autres types d'API et voir comment ils ont atténué les types d'attaques. Par exemple, OAuth 2 utilise un paramètre d'état et un nonce, pour des raisons différentes. Comme pour la réponse de @ vidarlo, vous pouvez utiliser un nonce en combinaison avec l'ID de session.

Il y a de nombreux problèmes de sécurité dans votre approche, la plupart déjà signalés dans d'autres réponses.

Je veux répondre avec des principes généraux qui vous aideront à trouver ces problèmes par vous-même.

traiter chaque donnée fournie par l'utilisateur comme malveillante

tout ce qui vient d'un client n'est pas fiable. Il a besoin de validation d'entrée, de rognage, d'échappatoire, les neuf mètres entiers. Dans votre cas, votre application envoie probablement le JSON approprié, mais que se passe-t-il dans votre API si quelqu'un fabrique à la main un JSON et vous donne un JSON invalide, ne termine pas la chaîne ou mélange l'injection SQL?

ne saisissez jamais les données que vous avez déjà

comme indiqué dans d'autres réponses, vous connaissez déjà la date / l'heure et l'identifiant "de", alors ne les acceptez pas comme contribution. En général, n'acceptez jamais de commentaires sur quelque chose que vous pouvez obtenir d'une source plus fiable.

L'approche SWIFT

examinez chaque élément et demandez-vous "qu'est-ce qui pourrait mal tourner?". SWIFT ( ici ou plusieurs autres sources) est une manière structurée de le faire. Essentiellement, une fois que vous avez réduit votre saisie au texte et à l'ID, pensez à la manière dont quelqu'un pourrait en abuser. Pourrait-il envoyer de mauvaises données, trop peu de données, trop de données? Cette approche devrait vous conduire aux menaces décrites dans d'autres réponses, telles que l'énumération, l'inondation / le spam, etc.

considérez votre système backend

enfin, connaissez les faiblesses de votre système backend . Si vous avez une base de données SQL derrière, réfléchissez aux possibilités d'injection SQL. Pensez également aux performances et aux limites du système - un utilisateur peut-il potentiellement envoyer tellement de données qu'elles submergent vos E / S, votre traitement ou votre capacité de stockage? Peut-il bloquer l'API pour d'autres utilisateurs (quelles sont vos limites de traitement parallèle? Combien de connexions pouvez-vous gérer, etc.)

Bien que ce ne soit pas une approche complète de modélisation des menaces, je trouve qu'elle sert 90% aussi bien avec un peu d'effort complet.

Règle 0: ne faites jamais confiance au client. Validez toutes les entrées du côté client en toutes circonstances.

Dans ce cas, cela signifie vérifier que l'utilisateur expéditeur est (a) authentifié en tant que qui il prétend envoyer le message, et (b) est autorisé pour envoyer un message donné, en fonction de vos critères. Cela signifie également que le champ «texte» doit être nettoyé avant d'être stocké ou affiché à quiconque, et que l'horodatage de l'heure d'envoi doit être défini par le serveur - en ce qui concerne votre système, un message n'était «envoyé» que lorsque le système l'a reçu de l'expéditeur.

Après avoir coupé les parties du modèle que le serveur peut (et devrait) remplir pour l'utilisateur, ce que vous avez vraiment n'est que l'identifiant du destinataire et le message

En ce qui concerne l'énumération de la liste d'utilisateurs à l'aide d'identifiants séquentiels et / ou de spam, il existe plusieurs moyens de gérer cela, comme une "demande d'ami" (par e-mail, téléphone, nom d'utilisateur, etc) qui limite les utilisateurs à ne pouvoir envoyer des messages qu'à des destinataires préautorisés et ne donne aucune indication sur le fait que la cible d'une demande d'ami est un utilisateur réel du système. De plus, vous pouvez faire une limitation de débit traditionnelle avec quelque chose comme un seau qui fuit, ou même créer un système de surveillance qui marque / interdit les utilisateurs qui présentent des comportements d'inondation / spam.