Cette série d’articles aborde les points les plus importants de la sécurité des applications mobiles, quelque soit la plateforme (iOS, Android ou autre).
L’objectif est de démystifier les différents aspects de la sécurité mobile, avec des mots très simples.
Sujet numéro 1 cette semaine : Les contrôles côté serveur
Oui, côté serveur. Le premier des risques ne se situe pas forcément sur l’appareil mobile lui-même, mais sur les serveurs. Voyons pourquoi.
Une application mobile fonctionne assez rarement seule, et communique avec un serveur qui lui fournit des données :
- Données d’authentification (pour authentifier les utilisateurs)
- Données métier (pour que l’application sache quelles données afficher à l’utilisateur)
- Données financières, s’il y a des transactions
- Données transactionnelles (ventes, RH…)
- Données de reporting
- Données personnelles
La partie du serveur qui communique avec l’appareil mobile est appelée l’API, ou le webservice.
Le serveur étant un élément central et global, il y a de fortes chances pour qu’il soit attaqué.
Les possibilités d’attaque sur un serveur sont énormes. L’OWASP édite le top 10 de ces attaques, que nous avons détaillées au cours d’une précédente série d’articles (Comprendre les vulnérabilités web en 5 min – episode #1 : Injections!).
Parmi ces attaques, les plus connues et dangereuses sont notamment :
- Les attaques par injection (où un attaquant peut directement avoir accès aux données)
- Les attaques sur la gestion de l’authentification et des sessions (où un attaquant outrepasse les contrôles)
Exemple d’attaque
Prenons le cas d’une application mobile permettant à ses utilisateurs de commander des produits et de consulter leurs factures.
Pour afficher et télécharger une facture, l’application mobile va envoyer une requête vers le webservice :
Cette requête peut être envoyée d’une manière très simple, via un navigateur web ou via tout autre outil utilisé par un hacker.
Le webservice peut manquer de protection dans sa manière d’identifier l’émetteur des requêtes et de vérifier ses permissions. Dans ce cas, des requêtes similaires peuvent être effectuées pour obtenir n’importe quelle (toutes) facture, même si elle n’appartient pas à l’émetteur des requêtes :
https://api.example.com/client/invoice_download?id_invoice=3676&view=pdf
https://api.example.com/client/invoice_download?id_invoice=26736&view=pdf
https://api.example.com/client/invoice_download?id_invoice=18376&view=pdf
Toutes les informations de facturations de tous les consommateurs (et potentiellement leurs données personnelles) sont alors accessibles en ligne, à la portée de tous.
Sécuriser le serveur
Même si au final l’interface utilisateur sera l’application mobile, les attaquants vont à coup sûr essayer d’attaquer le serveur et son API.
Cela signifie que des efforts doivent être faits pour sécuriser le serveur et l’API afin d’implémenter des contrôles et empêcher les attaques. Se reposer uniquement sur la sécurité de l’application mobile installée sur les téléphones et les tablettes serait donc une erreur.
Quelques solutions concrètes de sécurisation :
- Revues de code (avec plusieurs développeurs)
- Audit de sécurité (pentest), pour détecter les vulnérabilités et obtenir des solutions techniques
- Web Application Firewall, pour ajouter une couche supplémentaire de protection
Bien entendu, de nombreux efforts de sécurité sont aussi à effectuer sur l’application mobile elle-même : nous les détaillerons un à un dans de prochains articles.
Ne vous précipitez pas lorsque votre application est développée, et protégez-là avant de la diffuser sur les stores !