Il existe aujourd'hui de nombreuses applications mobiles avec prise en charge des passerelles de paiement. Cependant, contrairement aux navigateurs de bureau, ces applications mobiles ne nous montrent pas de "barre d'adresse" par laquelle nous pouvons identifier une connexion HTTPS. Comment puis-je m'assurer que j'effectue un paiement sur une application mobile avec une connexion HTTPS?
Comme le dit @StefHeylen, vous ne pouvez généralement pas. Et comme le dit @ d1str0, Burp est un moyen de voir si le trafic est crypté, si vous pouvez proxyer l'application via.
C'est en fait pire que cela - les applications mobiles ne font pas toujours qu'une seule connexion à un serveur. Il n'est pas rare qu'ils utilisent HTTP pour certaines parties et HTTPS pour d'autres. Ils peuvent également effectuer d'autres astuces que les navigateurs normaux ne touchent généralement pas. Par exemple, ils peuvent certifier le code PIN et refuser de s'exécuter s'ils ne peuvent pas établir une connexion sécurisée avec un serveur spécifique.
Par conséquent, il est parfaitement possible d'avoir des applications mobiles qui refusent de s'exécuter lorsqu'elles sont mandatées (car elles se connectent à un serveur HTTPS spécifique avec un certificat spécifique, ce qui signifie que Burp échoue), mais qui envoient ensuite des données de paiement par des moyens non cryptés à un autre serveur. La seule façon d'observer cela consiste à inspecter les paquets à l'aide de quelque chose comme Wireshark - vous verrez un tas de données chiffrées, puis des données non chiffrées (souvent JSON ou XML) envoyées à un autre serveur.
Il est également possible que les données de paiement soient envoyées correctement, puis pour les scripts tiers pour la surveillance des statistiques (voir dans quelle mesure les utilisateurs parcourent les formulaires dans l'application, par exemple) pour envoyer les mêmes détails sur des canaux non cryptés parce que le développeur de l'application n'a pas exclu champs de paiement.
L'ensemble du système d'application mobile est un gâchis - je seconderais les conseils de Stef pour éviter de faire des paiements à l'aide d'applications si possible. Si vous ne pouvez pas, envisagez d'utiliser une carte spécifique pour ces paiements, que vous surveillez régulièrement pour les transactions inhabituelles.
Malheureusement, à moins de renifler et d'inspecter votre propre trafic, vous ne pouvez pas ... Mon conseil est de ne pas utiliser de navigateurs intégrés qui n'indiquent pas le protocole utilisé pour gérer les informations sensibles
L'utilisation d'un outil proxy comme BurpSuite vous permettra de tester si cette application spécifique autorise ou non les mauvaises connexions HTTPS.
Dans iOS 9, HTTPS dans les applications est activé pour tout appel réseau. Vous pouvez le contourner temporairement, mais il ne sera bientôt plus que HTTPS pour tous les appels réseau.
À partir d'iOS 9.0 et OS X v10.11, une nouvelle fonctionnalité de sécurité appelée App Transport Security (ATS) est disponible pour les applications et est activée par défaut. Il améliore la confidentialité et l'intégrité des données des connexions entre une application et les services Web en appliquant des exigences de sécurité supplémentaires pour les demandes de mise en réseau HTTP. Plus précisément, avec ATS activé, les connexions HTTP doivent utiliser HTTPS (RFC 2818). Les tentatives de connexion à l'aide d'un protocole HTTP non sécurisé échouent. De plus, les demandes HTTPS doivent utiliser les meilleures pratiques pour des communications sécurisées.