# # #
#

Mythes et réalités

Mythe N°1 « Sans demande particulière, le développeur me fournira une solution sécurisée »

La sécurité d’une application web n’est pas innée. Au contraire, si des précautions particulières ne sont pas prises, il est fort probable que des vulnérabilités existent dans la solution mise en place et qu’elles puissent impacter la confidentialité, l’intégrité ou la disponibilité de l’application et des données traitées. Ce qui est vrai pour tout type d’application l’est encore plus pour une technologie à l’origine conçue pour permettre un accès totalement libre aux informations, et donc où les mécanismes d’authentification, de gestion de session et de contrôle d’accès ne sont pas natifs. Le donneur d’ordre doit donc faire en sorte que les bonnes pratiques de sécurité soient comprises et appliquées par le maître d’œuvre, puis se doter des moyens de contrôler le niveau de sécurité de l’application (voir ci-après le chapitre sur la vérification de la sécurité).

Mythe N°2 « Seuls des génies de l’informatique savent exploiter les failles des applications Web »

Au contraire, les failles de sécurité au sein des applications Web sont le plus souvent faciles à exploiter. Un attaquant n’a souvent besoin que d’un simple navigateur Web pour identifier et exploiter des failles de sécurité. Des outils complémentaires, comme des logiciels de proxy locaux, capables d’intercepter les requêtes entre le navigateur et le serveur Web sont disponibles gratuitement sur Internet. Les technologies Web reposent en outre sur un ensemble de protocoles, langages, et architectures ouverts, dont les spécifications sont librement accessibles. N’importe qui peut donc étudier ces référentiels et les flux échangés entre l’application Web et le client, pour identifier des failles d’implémentation ou de conception.

Mythe N°3 « Mon site Web est sécurisé puisqu’il est protégé par SSL »

La technologie SSL a été conçue pour éviter que des données sensibles, comme des données de paiement, soient transmises « en clair » sur Internet, et les sites commerciaux arborent aujourd’hui tous un logo « site sécurisé par un certificat SSL ». Lors de l’explosion du e- commerce, les medias ont expliqué qu’un internaute ne devait se considérer sur un site de confiance que si le fameux cadenas s’affichait dans la barre d’état du navigateur Web. La dérive vers le mythe du « Mon site est sécurisé puisque il est protégé par SSL » s’explique donc facilement. Or, si SSL est un mécanisme de sécurité nécessaire pour protéger la confidentialité et l’intégrité des données échangées entre le client et le serveur, il n’est pas suffisant pour protéger totalement l’application Web, notamment des attaques contenues dans le flux Web envoyé par le client au serveur, qui passent donc dans le tuyau « SSL ».

Mythe N°4 : « Je suis protégé contre les attaques, j’ai un firewall »

Historiquement, les entreprises ont commencé à se connecter à Internet, en mettant en place des composants de sécurité opérant au niveau du réseau, tels que des pare-feu réseau (firewall). S’ils sont bien configurés, ces mécanismes sont et restent efficaces dans la plupart des cas pour empêcher des accès non autorisés à l’infrastructure hébergeant les applications Web, comme les services réseau des systèmes d’exploitation ou des bases de données, et sont donc nécessaires. Malheureusement, ils sont insuffisants pour assurer la sécurité d’une application web, car les failles applicatives sont exploitées via des canaux de communication normaux et nécessaires au bon fonctionnement de l’application, et donc autorisés par le pare- feu.

Mythe N°5 : « Une faille sur une application interne n’est pas importante »

Une application interne, non publiée sur Internet, est certes moins exposée qu’un site Internet, accessible 24h sur 24 à des centaines de millions d’internautes. Toutefois, si elle contient des failles, elle est vulnérable aux attaques menées par n’importe quelle personne, ayant accès au réseau interne, et disposant d’un simple navigateur Web. En outre, l’utilisation de la technologie web pour les applications internes a fait du navigateur Web un outil unique utilisé à la fois pour accéder à des ressources Web externes et internes à l’entreprise. Il peut donc exister des situations où un utilisateur interne accède en même temps et à partir du même navigateur Web, à une application Web interne sensible et à un site Web externe, potentiellement sous le contrôle d’un attaquant. Or les technologies Web peuvent permettre à un site Web « malveillant » de faire réaliser par le navigateur d’un utilisateur qui accède à ce site des requêtes sur un autre site, même interne, et ce à l’insu de l’utilisateur. C’est donc un moyen potentiel pour un attaquant externe d’exploiter des failles sur une application Web intranet, depuis Internet, même si un pare-feu est en place, en utilisant le navigateur Web comme un pivot de rebond.

Source : Clusif