Récemment, on m’a parlé d’une technique qui visait à exploiter les failles de sécurité des applis mobiles. Mais avant de voir jusqu’où on peut aller, installons les éléments de bases:
Un ordi avec Burp Proxy (il vous faut débloquer le port 8080 dans votre firewall)
Une tablette ou un téléphone (iOS/ Android)
Sur Android, il vous faut l’application ProxyDroid et lui configurer le proxy. Petit tuto pour les Noob android.
Sur iOS, il suffit de cliquer sur le i ou la flèche bleu de votre réseau wifi et lui configurer le proxy. Petit tuto pour les Noob iOS.
Le proxy étant l’ip de votre réseau local de votre ordinateur et le port étant 8080.
Maintenant, sur BURP, dans l’onglet Proxy, cliquez pour avoir « Intercept is off », et dans les options ajouter votre IP locale en plus de 127.0.0.1 et écoutez le port 8080.
Ouvrez l’onglet History puis naviguez sur le web avec votre mobile, vous devriez voir les requêtes transitées.
Passons aux choses sérieuses
Les applications mobiles « pro » sont construites comme ceci:
L’appli va envoyer des données au serveur web (à une api), et celle-ci va lui restituer les données.
C’est ensuite l’application mobile qui va les structurer graphiquement selon la taille du device.
Bien souvent, ce n’est pas la même personne qui s’occupe du dév web, et de l’appli mobile.
Donc lorsque l’appli mobile accède à un article, par défaut, le dév web lui renverra tous les champs associés à cet article dans un format json, xml… et ca sera l’appli mobile qui se chargera de les afficher.
Vous commencez à comprendre où je veux en venir ?
Si tous les champs sont accessibles et bien structurés, alors on peut mettre à la casse nos scrapeurs, et récupérer des bases complètes d’informations. Parfois il y a même des données qui ne devraient pas être accessibles (masqués par l’appli mobile, mais affichés dans le flux).
Les problèmes que ca posent:
Imaginons un badboy. En quelques lignes de code, il peut copier le contenu de votre base, monter un site mirroir du votre, et vous pourrir la vie sur Google (duplicate content).
On peut imaginer également qu’ils revendent ces informations (surtout si ces données devraient rester secrètes. ex : la sexualité des personnes dans leur profil privé).
Comment se protéger de ça:
Aujourd’hui, en étudiant les requêtes qui transitent un bon pirate ne se génera pas pour se faire passer pour une application mobile. Vous pouvez seulement le ralentir, et lui pourrir un peu la vie. Voyons comment faire:
– Utiliser un user-agent dédié.
– Faire de l’analyse comportementale (si une personne attaque 10 articles en 2 secondes, c’est louche surtout si il s’agit d’une suite numérique 1,2,3,4,5,6…)
– Et surtout faire du bannissement d’ip en cas de détection d’erreur. Si vous détectez une erreur qui ne devraient pas se produire (l’id visé n’existe pas par exemple), c ‘est qu’il s’agit probablement d’un pirate; alors autant le ralentir un peu et lui griller son proxy.
Ok, il peut toujours utiliser le réseau GSM (et vous ne pouvez pas bannier les ips de Bouygues, SFR…)
Mais en détectant le fingerprint du navigateur ou autre, il y a quand même moyen de le ralentir pas mal.
La note de fin:
Dites vous qu’aujourd’hui, les développeurs commencent tout juste à découvrir les failles que les API peuvent révéler. Pour le moment, sachez qu’il y a encore vraiment de quoi s’amuser 🙂
