Cet article fait référence à la revue de littérature du mémoire de Michel KPAOSSOU réalisé durant son Master II Génie électrique option réseaux informatiques et télécommunications (2018/2019)
Titre du mémoire : Attaque et Défense pour la Sécurisation des Applications Web et Mobile : Cas du système de traduction « FFtranslator »
Sommaire
La sécurité informatique
La sécurité d’une entité (politique, juridique, économique, physique, humaine, informatique…) rassemble l’ensemble des activités et des moyens qui concourent à prévenir et à opposer des parades offensives et défensives, actives et passives à des menaces de toute nature, potentielles, déclarées ou avérées à l’égard de cette entité.
Généralités sur la sécurité informatique
La sécurité informatique est l’ensemble des moyens (techniques, organisationnels, humains, . . .) mis en œuvre pour réduire la vulnérabilité d’un système contre les menaces accidentelles ou intentionnelles. En d’autres mots, c’est l’ensemble des techniques qui assurent que les ressources du système d’information (matérielles ou logicielles) d’une organisation sont utilisées uniquement dans le cadre où il est prévu qu’elles le soient. Les exigences fondamentales de la sécurité informatique se résument à assurer :
- la disponibilité. L’information sur le système doit être toujours disponible aux personnes autorisées ;
- la confidentialité. L’information sur le système ne doit être diffusée qu’aux personnes autorisées ;
- l’intégrité. L’information sur le système ne doit pouvoir être modifiée que par les personnes autorisées ;
- la traçabilité de l’information traitée. Il s’agit de journaliser et de suivre les actions et traitements de données afin de pouvoir détecter et, dans la mesure du possible, prévenir que la confidentialité, l’intégrité ou la disponibilité soient compromises.
Les differents types de sécurité informatique
La sécurité peut être implémentée à plusieurs niveaux mais les 3 niveaux les plus connus sont :
- la sécurité réseau;
- la sécurité système;
- la sécurité applicative.
La sécurité réseau
La sécurité d’un réseau est un niveau de garantie que l’ensemble des machines du réseau fonctionnent de façon optimale et que les utilisateurs des dites machines possèdent uniquement les droits qui leur ont été octroyés.
Il peut s’agir :
- d’empêcher des personnes non autorisées d’agir sur le système de façon malveillante ;
- d’empêcher les utilisateurs d’effectuer des opérations involontaires capables de nuire au système ;
- de sécuriser les données en prévoyant les pannes ;
- de garantir la non interruption d’un service.
Le but ici est d’instaurer la sécurité au niveau d’un réseau entier (ou sous réseau) de telle sorte à empêcher toute atteinte à n’importe quel élément faisant partie de ce réseau-là. Les firewalls et les NIPS sont des solutions souvent envisagées dans cette situation
La sécurité système
Dans ce cas de figure, le système et les services tournés sur un ordinateur (serveur, station de travail, terminal…) sont ciblés par la sécurité. Les antivirus constituent une solution très populaire, mais aussi les HIPS ou HIDS.
La sécurité applicative
La sécurité applicative ne concerne ni le réseau, ni le système entier d’un ordinateur. Ce niveau d’implémentation concerne un logiciel ou une application en particulier (site, application web…). Dans ce cas de figure on peut utiliser :
- des correctifs ;
- des filtres ;
- des IPS applicatifs ;
- des WAF (Web Application Firewall)…
La Sécurité applicative
Généralités sur la sécurité applicative
La norme ISO 27034 définit la sécurité des applications comme : un processus effectué pour appliquer des contrôles et des mesures aux applications d’une organisation afin de gérer le risque de leur utilisation.
Les contrôles et les mesures peuvent être appliquées à l’application elle-même (ses processus, les composants, les logiciels et résultats), à ses données (données de configuration, les données de l’utilisateur, les données de l’organisation), et à toutes les technologies, les processus et acteurs impliqués dans le cycle de vie de l’application.
C’est cette sécurité qui fera l’objet de notre attention tout au long de ce document. Par ailleurs, notons que la sécurisation d’une application ou d’un système s’attache à 6 aspects primordiaux que sont : l’authentification, le contrôle d’accès, l’intégrité des données, la confidentialité des données, la non-répudiation, la protection contre l’analyse du trafic.
L’authentification
L’authentification consiste à savoir lier, grâce à une caractéristique discriminante (un mot de passe par exemple) une identité à une entité donnée d’un système (la partie administration d’un site, un processus en particulier ou 1 ordinateur par exemple). Elle s’applique à l’utilisateur, à l’émetteur d’un message ou à l’auteur d’un document.
Le contrôle d’accès
Une fois authentifié, l’utilisateur souhaite accéder à des fonctionnalités offertes par l’application. Au préalable, il faut contrôler s’il a le droit d’y accéder. Assurer cette fonction c’est avoir la capacité de lier une ressource (une base de données par exemple) avec des droits d’accès à cette ressource et une entité.
L’intégrité des données
Il s’agit ici de prévenir l’altération volontaire ou accidentelle d’une donnée ou des services d’un système. Elle s’applique à la phase de communication entre composants, au flux, au stockage des données (altérations de contenu) et au système (détection d’intrusion).
La confidentialité des données
La confidentialité des données doit être assurée lors d’échange de données sensibles (mot de passe, données bancaires ou médicales.) Il s’agit de garantir que des données acquises illégalement soient inutilisables.
La non-répudiation
Cette fonction consiste à s’assurer que l’envoi et la réception d’un message sont incontestables. En d’autres termes, l’émetteur ou le récepteur d’une donnée ne doit pas être en mesure de nier son implication en cas de litige. Le moyen technologique repose sur les certificats. C’est une mesure qui est particulièrement complexe à mettre en œuvre, car il est difficile de remettre en cause la bonne foi d’une personne prétextant qu’elle s’est fait dérober son identité.
La protection contre l’analyse du trafic
La sécurité des communications repose sur des mécanismes comme l’authentification, le chiffrement et le hachage.
o Le chiffrement
Le chiffrement est la conversion des données d’un format lisible à un format codé qui peut uniquement être lu ou traité après déchiffrement. Il est le bloc de construction de base de la sécurité des données et le moyen le plus simple et le plus important pour s’assurer que les informations du système informatique ne puissent pas être volées et lues par quelqu’un qui souhaite les utiliser à d’autres fins.
o Le hachage
Le hachage est une fonction qui, à partir d’une donnée fournie en entrée, calcule une empreinte servant à identifier rapidement la donnée initiale. Cette empreinte est de taille fixe et est différente selon la fonction utilisée et la donnée d’entrée. Ainsi différentes données donneront toutes des empreintes différentes. Une empreinte ne contient pas assez d’informations pour permettre la restitution du message originale, c’est pour cela que l’on parle de fonction à sens unique.
Pour résumer, une fonction de hachage permet de convertir un objet de taille arbitraire (texte, fichier, vidéo, . . .) en une chaîne de taille fixe. Généralement cette taille s’étend sur 128, 160, 256 ou 512 bits. L’exemple le plus emblématique de la protection contre l’analyse du trafic est l’utilisation des protocoles SSL(Secure Socket Layer) ou TLS(Transport Layer Security) dans les échanges sur le Web grâce au protocole HTTP.414.
Top dix OWASP des failles de sécurité
L’OWASP est un organisme à but non lucratif mondial qui milite pour l’amélioration de la sécurité des applications web. Son objectif est d’informer les individus ainsi que les entreprises sur les risques liés à la sécurité des systèmes d’information. L’organisation fonctionne comme une communauté de professionnels qui partagent la même vision des choses et propose un guide de développement pour les applications web dans lequel se trouve les bonnes pratiques à adopter lors de la phase de développement d’un projet web.
Des méthodes et outils de référence permettant de contrôler le niveau de sécurisation de ses applications Web sont aussi publiés par l’organisme. On retrouve ainsi le Top 10 OWASP des failles de sécurité les plus importantes que l’organisme publie de façon périodique. La dernière publication date de 2017.
Injection
Elle correspond au risque d’injection de commande (Système, SQL, Shellcode, …). La plus célèbre reste l’injection SQL. Comme son nom l’indique, l’injection SQL (ou SQLi) est une méthode d’exploitation de faille de sécurité d’une application possédant des interactions avec une base de données.
Le principe est d’injecter, dans une requête, du code SQL malveillant qui viendra modifier l’effet escompté et ainsi compromettre l’intégrité des données présentes dans la base. Cette technique est très souvent utilisée pour contourner les mécanismes d’authentification et d’autorisation d’une application web.
Une faille SQLi peut avoir de lourdes conséquences car un hackeur peut avoir un accès non autorisé aux données sensibles. Il sera en mesure de lire la base de données, y enregistrer de nouvelles données ou exécuter du code malveillant. Réussir une attaque du genre peut avoir des conséquences désastreuses pour la cible comme par exemple.
L’attaquant peut alors :
- accéder à un espace non autorisé via une fausse authentification ;
- supprimer des données d’une manière frauduleuse ;
- voler de données confidentielles enregistrées dans la base de données ;
- détruire ou porter atteinte à l’intégrité de la base de données.
Quand on connaît la valeur et l’importance des données il serait dommageable pour un site de subir une telle cyberattaque.
Broken Authentification and Session Management
Cette faille correspond au risque de casser ou de contourner la gestion de l’authentification et de la session. Elle comprend notamment le vol de session ou la récupération de mots de passe. La gestion des authentifications et des sessions inclut tous les aspects de la gestion de l’authentification des utilisateurs et des sessions actives.
L’authentification est un aspect essentiel de ce processus, mais même des mécanismes d’authentification solides peuvent être compromis par des fonctions de gestion des informations d’identité défectueuses, telles que la modification du mot de passe, l’oubli de mon mot de passe, la mémorisation de mon mot de passe, la mise à jour du compte et d’autres fonctions connexes. Comme de nombreuses applications Web sont susceptibles de provoquer des attaques indirectes, toutes les fonctions de gestion des comptes doivent nécessiter une nouvelle authentification, même si l’utilisateur dispose d’un identifiant de session valide.
L’authentification d’utilisateur sur le Web implique généralement l’utilisation d’un ID utilisateur et d’un mot de passe. Des méthodes d’authentification plus robustes sont disponibles dans le commerce, telles que des jetons cryptographiques basés sur du matériel et des logiciels ou la biométrie, mais de tels mécanismes sont d’un coût prohibitif pour la plupart des applications Web.
Un large éventail de failles dans la gestion des comptes et des sessions peut compromettre les comptes utilisateur ou d’administration système. Les équipes de développement sous estiment souvent la complexité de la conception d’un schéma de gestion des sessions et de l’authentification qui protège correctement les informations d’identification dans tous les aspects du site. Les applications Web doivent établir des sessions pour suivre le flux de demandes de chaque utilisateur. HTTP ne fournit pas cette fonctionnalité, les applications Web doivent donc la créer elles-mêmes.
Fréquemment, l’environnement d’application Web fournit une capacité de session, mais de nombreux développeurs préfèrent créer leurs propres jetons de session. Dans les deux cas, si les jetons de session ne sont pas correctement protégés, un attaquant peut pirater une session active et assumer l’identité d’un utilisateur. Créer un schéma pour créer des jetons de session forts et les protéger tout au long de leur cycle de vie s’est révélé insaisissable pour de nombreux développeurs.
À moins que toutes les informations d’authentification et tous les identifiants de session ne soient protégés à tout moment avec SSL et protégés contre la divulgation d’autres vulnérabilités, telles que les scripts inter-sites, un attaquant peut pirater la session d’un utilisateur et en prendre l’identité.
Sensitive Data Exposure (exposition de données sensibles)
L’exposition de données sensibles se produit lorsqu’une application ne protège pas correctement les informations sensibles. Les données peuvent varier et tout peut être exposé : mots de passe, jetons de session, données de carte de crédit, données de santé privées, etc… Au cours des dernières années, cette attaque a été la plus répandue. La faille la plus commune est simplement de ne pas chiffrer les données sensibles.
Lorsque la cryptographie est utilisée, la génération et la gestion de clés faibles, ainsi que l’utilisation d’algorithmes, de protocoles et de chiffrements faibles, sont courantes, en particulier pour les techniques de stockage avec hachage de mots de passe faibles. Pour les données en transit, les faiblesses côté serveur sont principalement faciles à détecter, mais difficiles pour les données au repos.
En effet, lors de la création d’une application, beaucoup d’entre les développeurs hiérarchisent par ordre de priorité la protection des données sensibles. Même s’ils sont conscients du fait qu’ils doivent, par exemple, hacher les mots de passe, il est courant de prévoir de le faire plus tard. Une application viable est la priorité absolue et une fois que l’application fonctionne, la protection planifiée est oubliée ou simplement ignorée.
Faire face à la cryptographie est aussi l’une des choses les plus difficiles à faire. Il est donc courant de commettre des erreurs lors de la mise en œuvre d’une solution auto-construite, ce qui entraînera une protection insuffisante des données. Sensitive Data Exposure est donc une vulnérabilité typique des petits acteurs, tels que les projets de loisir et les petites entreprises mais elle peut toutefois affecter également de grandes structures : une situation qui n’arrive quand même pas très souvent vu que la plupart des vulnérabilités liées à la cryptographie sont considérées comme difficiles à exploiter, en particulier à plus grande échelle.
XML External Entities – XXE (Entités Externes XML)
XML, ou Extensible Markup Language, est un outil flexible pour la transmission, le stockage et la modification de données. Les logiciels XML et les applications Web permettent d’accéder aux fichiers XML. C’est donc un outil efficace pour permettre à différentes entreprises ou applications d’accéder à des données communes.
Il n’est plus à démontrer que toute situation dans laquelle des attaquants peuvent introduire leur propre code dans un système est mauvaise, mais la flexibilité de XML pour l’intégration à d’autres applications ne fait qu’aggraver les choses. En effet, selon le glossaire informatique de Gartner, « il est devenu la norme en matière de transactions interentreprises, d’échanges de données électroniques et de services Web. »
Une partie de ce qui rend XML si flexible réside dans la possibilité de définir ses propres blocs de construction ou « entités », ainsi que de définir ce qui constitue une syntaxe valide. Ces définitions sont créées en ligne ou dans un fichier séparé avec des définitions de type de document, ou DTD. Si plusieurs organisations s’accordent sur une DTD standard, cela permet à leurs applications de visualiser et d’interpréter des données que le XML de base ne pourrait pas analyser.
Le plus gros risque avec XXE est la grande variété de façons dont il peut être exploité. Qu’il soit simple ou complexe, si un élément de code externe peut se retrouver dans un document XML, le système a été compromis. L’omniprésence de XML signifie que les applications utilisant XML risquent de rencontrer beaucoup de données sensibles. La forme la plus connue d’attaque XXE est connue sous le nom d’attaque « Billion Laughs », ou « bombe XML».
Il s’agit d’une attaque par déni de service simple mais efficace, utilisée pour surcharger et arrêter un serveur cible. En définissant une entité – généralement quelque chose de petit et absurde, comme « lol » ou « haha » – comme une chaîne imbriquée d’autres entités, un attaquant peut rapidement saturer les ressources d’un système.
Broken Access Control (Violation de Contrôle d’Accès)
Celle-ci correspond aux failles de sécurité sur les droits des utilisateurs authentifiés. Les attaquants peuvent exploiter ces défauts pour accéder à d’autres utilisateurs. Le contrôle d’accès, parfois appelé autorisation, est la façon dont une application Web accorde l’accès au contenu et aux fonctions à certains utilisateurs et non à d’autres.
Ces vérifications sont effectuées après l’authentification et régissent ce que les utilisateurs « authentifiés » sont autorisés à faire. Le contrôle d’accès semble être un problème simple, mais il est insidieusement difficile à mettre en œuvre correctement. Le modèle de contrôle d’accès d’une application Web est étroitement lié au contenu et aux fonctions fournis par le site. En outre, les utilisateurs peuvent appartenir à un certain nombre de groupes ou de rôles dotés de capacités ou de privilèges différents.
Les développeurs sous-estiment souvent la difficulté de mettre en œuvre un mécanisme de contrôle d’accès fiable. Bon nombre de ces projets n’ont pas été conçus délibérément, mais ont simplement évolué avec le site Web. Dans ces cas, les règles de contrôle d’accès sont insérées à divers endroits dans le code. À mesure que le site approche de son déploiement, la collection de règles ad hoc devient si difficile à comprendre qu’elle est presque impossible à comprendre.
Bon nombre de ces systèmes de contrôle d’accès imparfaits ne sont pas difficiles à découvrir et à exploiter. Fréquemment, il suffit de créer une demande pour des fonctions ou du contenu qui ne devraient pas être accordés. Une fois qu’une faille est découverte, les conséquences d’un système de contrôle d’accès imparfait peuvent être dévastatrices. Outre la visualisation de contenu non autorisé, un attaquant peut également être en mesure de modifier ou de supprimer du contenu, d’exécuter des fonctions non autorisées ou même de prendre en charge l’administration du site.
Un type spécifique de problème de contrôle d’accès concerne les interfaces administratives permettant aux administrateurs de site de gérer un site sur Internet. Ces fonctionnalités sont fréquemment utilisées pour permettre aux administrateurs de site de gérer efficacement les utilisateurs, les données et le contenu sur leur site. Dans de nombreux cas, les sites prennent en charge une variété de rôles administratifs afin de permettre une administration plus fine des sites. En raison de leur puissance, ces interfaces sont souvent des cibles de choix pour les attaques des étrangers et des initiés.
Security Misconfiguration
La mauvaise configuration de la sécurité correspond aux failles liées à une mauvaise configuration des serveurs Web, applications, base de données ou Framework. Elle est parmi les dix risques les plus critiques actuels liés à la sécurité des applications Web selon OWASP. Une mauvaise configuration peut inclure à la fois des erreurs lors de l’installation de la sécurité et l’échec complet de l’installation des contrôles de sécurité disponibles.
Il s’agit d’un problème répandu qui peut se produire à n’importe quel niveau de la pile d’applications. Certaines des erreurs de configuration les plus courantes dans les centres de données traditionnels incluent des configurations par défaut qui n’ont jamais été modifiées et restent non sécurisées, des configurations incomplètes destinées à être temporaires et des hypothèses erronées sur le comportement réseau attendu de l’application et les exigences de connectivité.
Cross-Site Scripting
Il n’existe pas de classification standardisée des failles de Cross-Site Scripting, mais l’on peut facilement distinguer deux types principaux de XSS: les Reflected XSS(ou non persistantes) et les Stored XSS(ou persistantes). Une faille XSS permettrait à un individu de :
- faire des redirections dans le but de faire du phishing,
- voler des informations (Cookies, sessions, . . .) ;
- faire des actions sur le site vulnérable et à l’insu de la victime.
Reflected XSS (Non persistante)
Ce type de faille de sécurité, qui peut être qualifié de « non permanent », est de loin le plus commun. Elle est dite non-persistant car il n’est pas stocké dans un fichier ou dans une base de données. Ce type de faille XSS ne stocke pas le contenu malicieux sur le serveur web. Il apparaît lorsque des données fournies par un client web sont utilisées telles quelles par les scripts du serveur pour produire une page de résultats.
Si les données non vérifiées sont incluses dans la page de résultat sans encodage des entités HTML, elles pourront être utilisées pour injecter du code dans la page dynamique reçue par le navigateur client. Le contenu est par exemple livré à la victime via une URL qui le contient (envoyée par email ou par un autre moyen). La plupart des navigateurs web ont intégré dans leurs dernières versions un filtre anti-XSS (Chrome, IE, Safari, Opera, Edge). Il analyse le rendu d’une page envoyée par le serveur et supprime toute occurrence de javascript qui serait également présente dans la requête du client. Cela protège les utilisateurs d’une Reflected XSS mais pas d’une Persistent XSS.
Reflected XSS (Persistante)
Ce type de vulnérabilité, aussi appelé faille permanente ou du second ordre permet des attaques puissantes. La faille XSS persistante est la plus dangereuse car elle sera exécutée à chaque chargement du site. En effet, cette dernière est stockée soit dans un fichier ou dans une base de données. Autrement dit, ce type d’attaque se produit quand les données fournies par un utilisateur sont stockées sur un serveur (dans une base de données, des fichiers, ou autre), et ensuite réaffichées sans que les caractères spéciaux HTML aient été encodés.
Par exemple sur un forum de discussions quelconque, l’attaquant va poster un message ou un commentaire contenant le contenu malicieux. Lorsque les autres utilisateurs vont se rendre sur la page contenant le message ou le commentaire frauduleux, ce dernier sera exécuté.
Insecure deserialization (Désérialisation non sécurisée)
La sérialisation et la désérialisation sont des concepts importants dans les Framework de programmation orientés objet, tels que Java et .Net; et sont par conséquent communs à de nombreuses applications Web. La sérialisation fait référence à la modification d’un objet dans un format pouvant être transmis ou conservé sur le disque. La désérialisation est le processus inverse ; c’est à dire reconvertir les données sérialisées en un objet utilisable par l’application Web.
Contrôler le flux sérialisé peut permettre à un attaquant d’exploiter le processus de désérialisation de ce flux et ainsi compromettre l’application Web. Une vulnérabilité de désérialisation non sécurisée existe lorsqu’une application ne sécurise pas correctement ce processus. Si une implémentation de désérialisation est laissée à ses paramètres par défaut, une application peut avoir peu ou pas de contrôle sur les données désérialisées.
Dans les cas les plus extrêmes, cela peut inclure toutes les données sérialisées entrantes provenant de n’importe quelle source, sans vérification ni précaution. Sur le plan conceptuel, cela ressemble beaucoup au risque XML Entités externes (XXE) d’autant plus que XML est un format utilisé pour la sérialisation. Nous avons déjà examiné les vulnérabilités de XML spécifiquement, mais la désérialisation non sécurisée s’applique à un plus grand nombre de formats de données.
Les formats de sérialisation les plus courants incluent JSON, XML, BSON et YAML. Différentes API et infrastructures ont différents processus de sérialisation et de désérialisation. Bien que le risque s’applique à toute instance de désérialisation, il doit être géré de manière spécifique à l’application. Une attaque de désérialisation réussie, telle que XXE ou XSS, permet d’introduire du code non autorisé dans une application.
Si le code d’un attaquant peut être désérialisé de manière non sécurisée, presque toute intention malveillante est possible. L’exposition des données, le contrôle d’accès compromis et l’exécution de code à distance sont toutes les conséquences possibles d’une désérialisation non sécurisée.
Using Components with Known Vulnerabilities (Utilisation decomposants à vulnérabilités connues)
Ces failles correspondent aux failles liées à l’utilisation de composants tiers vulnérables. En effet, de plus en plus d’applications utilisent des composants préexistants au lieu d’être entièrement codées à partir de zéro. Les applications Web nécessitent souvent des délais d’exécution rapides et, compte tenu du nombre de composants open source disponibles, il n’y a aucune raison de ne pas les utiliser.
L’analyse indique qu’une bonne partie (près de 96 %) des applications utilise au moins une partie des composants open source. En moyenne, plus de la moitié du code d’une application est constituée de code open source plutôt que de code propriétaire. Le problème est exacerbé par la tendance des développeurs de logiciels à utiliser des composants open source souvent développés par des programmeurs de pays en développement.
Sous pression pour livrer rapidement, ces composants ne sont pas suffisamment contrôlés avant utilisation. Le résultat peut être de nouveaux sites Web et applications avec des vulnérabilités profondément intégrées inconnues de l’opérateur d’application. Mais une fois que cette vulnérabilité est découverte par les cybercriminels, les applications utilisant le composant vulnérable peuvent être trouvées et exploitées.
Cela pourrait être une simple faille dans un petit composant, mais qui rend finalement le système entier piratable. C’est un problème sérieux pour les petites entreprises (et parfois pas si petites) ou les particuliers qui utilisent les bibliothèques JavaScript, PHP ou Python pour obtenir des routines pré-écrites gratuites utilisées pour rendre leurs sites Web plus attrayants et / ou interactifs. Étant donné que les bibliothèques existent, les scripts sont souvent utilisés sans être vérifiés, ou ne sont pas conscients du fait qu’ils peuvent introduire une vulnérabilité dans l’application.
Bien entendu, rien ne garantit qu’un composant d’une application – open source, propriétaire ou sous licence – sera entièrement sécurisé. Les développeurs et / ou les chercheurs en sécurité découvrent souvent de nouvelles vulnérabilités après la publication et publient des correctifs de sécurité pour les corriger. Tous les composants ne recevront pas les correctifs nécessaires, mais même s’ils le font, si l’utilisateur ne les applique pas, la vulnérabilité demeure.
Les vulnérabilités connues non corrigées représentent un risque sérieux. Dès qu’une vulnérabilité est corrigée par le développeur, son existence devient une connaissance publique. Les pirates se précipitent pour développer et utiliser des exploits avant que les utilisateurs n’aient le temps de corriger les applications. C’est un problème croissant : Gartner a prédit que d’ici 2020, 99 % failles de sécurité exploitées seront connues depuis au moins un an.
Insufficient Logging and Monitoring (Enregistrement et surveillance insuffisants)
Une journalisation et une surveillance insuffisantes diffèrent quelque peu des 9 risques précédents. Bien que cela ne puisse conduire à une intrusion directe, le risque est que l’intrusion ne soit pas détectée en temps voulu, or une défaillance pouvant coûter des millions de dollars.
L’enregistrement et la surveillance vont de pair. Il est peu utile de disposer de journaux adéquats s’ils ne font pas l’objet d’une surveillance adéquate. Le problème de la journalisation et de la surveillance insuffisante concerne l’ensemble de l’infrastructure informatique et pas seulement l’application Web avec accès à Internet, comme le fait la solution.
Pour cette raison, nous ne limiterons pas cette discussion à la journalisation et à la surveillance des applications Web. L’un des principaux problèmes est qu’il y a tellement de journaux (presque tous les systèmes modernes génèrent leurs propres journaux). La gestion des journaux devient alors un problème majeur. Au moment où tous les différents journaux sont rassemblés et de préférence assemblés, la taille même de l’ensemble de données devient trop volumineuse pour permettre une surveillance manuelle efficace.
La solution réside dans une automatisation accrue du processus. Par exemple, certains systèmes de contrôle d’accès peuvent avoir leurs propres règles de surveillance. Les règles de connexion peuvent être définies pour autoriser un nombre prédéfini de tentatives de connexion par session. Le système enregistre les tentatives, puis bloque les accès à partir de cette adresse IP, pour une période prédéfinie ou indéfiniment.
De tels systèmes alerteront probablement aussi l’équipe de sécurité que quelque chose ne va pas.
Importance et enjeux de la sécurité des applications Web et mobiles
Importance de la sécurité des applications Web et mobiles
Pour faire face aux risques sans cesse grandissant de cyberattaques, les responsables de la sécurité des systèmes d’information (RSSI) investissent donc dans des pare-feux, et des systèmes d’authentification Web, de détection d’intrusion et de gestion des identités. Cependant, ces solutions ne sécurisent que le périmètre du SI en gérant le trafic vers les applications.Aucune d’entre elles ne protège les applications de l’intérieur vers l’extérieur en en renforçant le code ou en en gérant les failles.
Assurer la sécurité des applications malgré une stratégie axée sur l’intégration de composants tiers nécessite la mise en place de processus, ainsi que de l’entraînement et des outils adéquats. Il faut également établir un réel partenariat entre les équipes dédiées et de conception autour de deux éléments clés : la création par les développeurs d’un inventaire précis des composants open source et propriétaires utilisés ; et un système permettant de faire le lien entre les projets en cours et les vulnérabilités connues et divulguées, géré par l’équipe de sécurité.
Enjeux de la sécurité des applications Web et mobiles
L’activité des entreprises et des administrations repose de plus en plus sur les technologies et applications Web. Les vulnérabilités de ces applications Web sont désormais le vecteur le plus important des attaques dirigées contre la sécurité des entreprises. Selon Gartner, près de 96% de ces attaques viseraient les applications Web.
Une attaque peut avoir un effet catastrophique sur l’image d’une les entreprises et administrations victimes de cette situation. Cette dernière peut voir son image dégradée ou voir fuir ses clients : ce qui peut engendrer de lourdes pertes financières. La sécurité des applications Web est donc devenue un enjeu stratégique aussi important que les fonctionnalités ou l’ergonomie. D’ailleurs les utilisateurs y attachent de plus en plus d’importance.
La peur de se faire voler des données sensibles (numéro de Carte Bancaire, documents, . . .) est bien plus présente dans les esprits qu’il y a encore quelques années. Ceci est sans nul doute dû au fait que les attaques se multiplient et que plus personne n’est épargné. Notons aussi que même les plus petites structures et plus petits sites sont aussi des cibles potentielles.
Elles ne sont pas visées par les pirates pour en tirer un profit direct mais plutôt pour servir de passerelle et de couverture pour des attaques de plus grandes envergures. Les obligations légales face à ces problèmes de sécurité sont de plus en plus drastiques et faire office de passerelle peut maintenant représenter un risque pénal.
Il est donc primordial de nos jours de développer les applications Web dans une logique de sécurité, dès le départ et tout au long du processus. Aucune sécurité n’est inviolable, cela permettrait déjà de considérablement compliquer la tâche des pirates. De plus, réaliser des audits réguliers de nos applications servirait fortement à réduire le champ d’attaque
Présentation du système d’étude : FFtranslator
Architecture du système
L’architecture définit la structure des éléments constitutifs du système, du point de vue matériel et logiciel. Elle définit la façon dont ces différents éléments sont assemblés et fonctionnent. Dans notre cas ici, le système nous offre une architecture client-serveur de type 2 tiers. Une telle architecture favorise une centralisation des données sur un seul serveur, physique ou virtuel, ce qui simplifie les contrôles de sécurité, l’administration et la mise à jour des données. Comme le montre la 1.1 cidessous, les applications Web et mobile représentent les clients et dialoguent avec le serveur Web.
La plateforme Web permettra un accès au système de traduction depuis n’importe quel terminal Web. Elle enverra des requêtes au serveur Web et recevra un résultat en fonction de la ressource indexée. L’application mobile quant à elle reste un moyen plus simple pour les utilisateurs sur smartphone Android d’accéder au système sans passer par un terminal Web. Elle enverra également des requêtes au serveur Web via l’API qui a été mise en place.
Le présent système reste accessible à deux acteurs.
- L’utilisateur simple, c’est-à-dire toute personne qui, au travers de son smartphone Android ou d’un terminal Web désire bénéficier des services du système.
- Puis les développeurs qui désirent intégrer certains services du système dans leurs applications respectives par le biais d’une API mise à leur disposition. Il s’agit notamment de la traduction de texte et de la synthèse vocale
Fonctionnement du système
Que l’on s’y connecte en tant que simple utilisateur ou en tant que développeur, le système offre une gamme d’opération variée. L’utilisateur peut par exemple :
- traduire du texte du Français vers le Fongbé ou vice-versa ;
- faire une synthèse vocale de phrase écrite en Français ;
- faire une reconnaissance de parole. (Uniquement disponible pour le Français et sur l’application mobile) ;
- gérer l’historique des traductions. (Uniquement disponible sur l’application mobile);
- faire une reconnaissance de parole. (Uniquement disponible pour le Français et sur l’application mobile) ;
- gérer certains paramètres de l’application. (Uniquement disponible sur l’application mobile).
Le développeur peut entre autres intégrer le module de traduction de texte à des programmes par le biais d’une API mise à sa disposition.
Pour faire par exemple une traduction de texte du Français vers le Fongbé ou vice versa après avoir entré le texte et cliqué sur le bouton de traduction, une requête POST asynchrone est envoyée au serveur à partir de l’application Web ou mobile.
Le corps de la requête est au format JSON et contient les informations nécessaires pour la traduction telles que la langue source, la langue de destination et le corps du message. Le serveur fait appel au module de traduction de texte et formate le résultat de ce dernier en JSON avant d’envoyer une réponse au client.
Pour plus d’informations sur ce mémoire, n’hésitez pas à vous adresser directement à l’auteur ci-dessous.
Michel KPAOSSOU
Livres pour approfondir
