[RUBY] Vulnérabilités et contre-mesures dans le traitement important (traitement des achats) (CSRF)

supposition
Programmation débutant(2~Trois mois)C'est ce que j'ai appris.
Il peut contenir des éléments qui ne fonctionnent pas dans le domaine réel ou qui sont faux.
Nous vous serions reconnaissants si vous pouviez signaler ou ajouter des parties qui sont incorrectes ou que vous ne comprenez pas.

Nous avons résumé l'une des attaques contre un traitement important, CSRF (Cross-Site Request Forgery). Qu'est-ce qu'un traitement important, par exemple? Il s'agit d'un processus qui ne doit pas être exécuté de l'extérieur, comme l'affichage sur un babillard électronique, l'envoi d'un e-mail ou l'achat d'un produit sur un site EC. Dans CSRF, ce processus important est utilisé par un attaquant pour se faire passer pour un utilisateur légitime (envoyer une requête).

Mécanisme et contre-mesures du CSRF

** Que fera exactement le CSRF? ** Les processus importants suivants existent dans l'application Web. ・ Paiement par carte de crédit · Envoyer un mail ·changer le mot de passe Un attaquant peut utiliser ces processus importants en se faisant passer pour un utilisateur légitime.

CSRF (falsification de requête intersite)

Une attaque dans laquelle un attaquant vole les informations de connexion d'un utilisateur (piratage de session) et envoie une requête à une application Web vulnérable en usurpant l'identité d'un utilisateur légitime. Une demande d'usurpation d'identité est une demande malveillante, et une application Web qui ne peut pas déterminer cette demande malveillante est vulnérable à CSRF.

Dommages pouvant survenir en cas de vulnérabilité CSRF

Les vulnérabilités CSRF peuvent provoquer les dommages suivants: ・ Le compte utilisateur est mal utilisé ・ Le mot de passe et l'adresse e-mail de l'utilisateur seront modifiés ・ L'argent dont dispose l'utilisateur est utilisé

Comment fonctionne CSRF

Procédure pour CSRF ① Préparez un site Web où un attaquant vole des informations utilisateur Un attaquant crée un site Web à l'avance pour voler des informations (pour le détournement de session). (2) L'utilisateur se connecte à l'application Web vulnérable et obtient l'ID de session. Connectez-vous à une application Web vulnérable pour utiliser le site Web comme d'habitude. ③ Accéder à un site malveillant en étant connecté à l'application Web En accédant à un site Web malveillant à partir d'un site Web vulnérable, un piratage de session est établi et les informations de connexion sont volées par un attaquant. (4) Faites une demande non autorisée à une application Web vulnérable en fonction des informations de connexion extraites par l'attaquant. Un attaquant utilise les informations de connexion volées par le détournement de session pour usurper l'identité d'un utilisateur légitime et faire des demandes frauduleuses (comme l'achat de biens ou l'envoi d'argent).

Une application Web vulnérable ne peut pas déterminer si cette requête malveillante est malveillante ou non. De cette manière, le CSRF est établi. À propos, XSS est une vulnérabilité côté client et CSRF est une vulnérabilité côté serveur.

Mesures CSRF

Identifier les éléments à prendre contre le CSRF

Tout d'abord, il est important de connaître la demande qui nécessite de prendre des mesures CSRF. CSRF ne doit pas être fait pour chaque demande. Les demandes qui nécessitent des contre-mesures sont des demandes qui ne doivent pas être exécutées par d'autres utilisateurs. Par exemple, des demandes telles que le traitement des achats sur le site EC et le traitement des changements de mot de passe.

Contre-mesures spécifiques

Il existe deux méthodes efficaces pour déterminer si la demande provient d'un utilisateur légitime. ・ Entrez le mot de passe avant la confirmation ・ Incorporation de jetons dans les demandes

Contre-mesure ① Entrez à nouveau le mot de passe

Demandez-leur de saisir à nouveau leur mot de passe avant que le processus important ne soit confirmé. Il est possible de prévenir les attaques CSRF en saisissant le mot de passe actuel pour les demandes liées aux changements de mot de passe qui sont la cible d'attaques CSRF. C'est une méthode qui peut être utilisée car l'attaquant est connecté par détournement de session, mais le mot de passe lui-même n'est pas connu.

Contre-mesure (2) Incorporation de jetons (informations confidentielles) dans les demandes

Si l'attaquant demande un jeton que l'attaquant ne connaît pas sur les pages qui nécessitent des contre-mesures CSRF, telles que l'écran d'enregistrement et l'écran de confirmation de commande, les traitements importants dus à des demandes frauduleuses ne seront pas exécutés.

jeton Un jeton est un mot de passe qui ne peut être utilisé qu'une seule fois et qui n'est stocké que sur le navigateur de l'utilisateur. Il est souvent utilisé pour l'authentification des utilisateurs. Lorsque vous effectuez un traitement tel que la connexion, un jeton unique est enregistré dans le navigateur de l'expéditeur. Lorsque je fais une demande similaire d'un autre utilisateur, le jeton est différent ou n'existe pas. De cette manière, vous pouvez déterminer si la demande est invalide. À propos, la méthode d'assistance, qui est une forme de Ruby on Rails, prend cette mesure.

finalement

point important Comme certains d'entre vous l'ont peut-être remarqué, la présence de vulnérabilités XSS et de piratage de session pourrait même extraire ce jeton. En conséquence, les mesures CSRF perdent leur sens. En d'autres termes ** Les mesures de sécurité doivent être complètes dans tous les aspects ** à propos de ça. Même si vous renforcez un endroit, il est possible qu'un autre endroit faible vous donne un indice pour percer un endroit renforcé.

Recommended Posts

Vulnérabilités et contre-mesures dans le traitement important (traitement des achats) (CSRF)
Traitement parallèle et parallèle dans divers langages (édition Java)
[Android / Java] Transition d'écran et traitement de retour par fragments
Traitement asynchrone et intégration d'API Web dans Android Studio