Les applications Web des petites et des grandes organisations peuvent être la cible des malfaiteurs. Deux spécialistes discutent de cette problématique que l’on prévient par la sensibilisation et la proactivité.
Les applications Web jouissent d’une grande popularité. Bon nombre d’organisations y ont déjà recours pour informatiser un processus existant ou pour offrir une application nouveau genre, accessible universellement par le biais d’Internet, à leurs clients, leurs fournisseurs ou leurs employés. Or, comme bien des composantes du domaine des TIC, la sécurité de ces applications Web constitue un enjeu préoccupant.
Depuis longtemps, on tente de berner des internautes par courriel afin de les inciter à fournir des données personnelles par l’entremise d’applications Web frauduleuses qui simulent les sites de confiance qu’ils utilisent. Or, d’autres pratiques malveillantes visent directement les applications Web pour en soutirer des informations, en altérer les contenus dynamiques ou s’en servir pour attaquer d’autres cibles sur la Toile.
Michel Cusin est officier de sécurité au groupe Grandes entreprises chez Bell Canada à Québec. Il fait état de l’avènement, avec le Web 2.0, de technologies qui sont réunies dans un procédé nommé AJAX (Asynchronous JavaScript and XML) dont la composante de script JavaScript récupère dynamiquement des contenus sur Internet à partir de plusieurs sources. Or, ce type de script, utilisé à de mauvaises fins, peut servir au vol d’information ou à la redirection de l’internaute d’un site de confiance infecté vers un site frauduleux.
« Même si le site est sécurisé par le protocole HTTPS et chiffré par le protocole SSL, la plupart des gens n’en sont pas conscients et vont sur un site connu sans se soucier qu’ils pourraient être éventuellement piratés et se faire injecter du code malicieux », constate M. Cusin.
Le spécialiste de la sécurité décrit d’autres types de menaces réelles. À la tentative d’hameçonnage bien connue, s’ajoute depuis peu la production de faux courriels, rédigés à l’aide d’informations sur les intérêts personnels d’un internaute à partir d’un réseau social comme Facebook, en reprenant même ses fautes d’orthographe, afin d’inciter ses amis à ouvrir en toute confiance un fichier infecté.
Pour une base de données accessible par l’entremise d’une interface Web, l’injection d’un code malicieux dans les champs d’un formulaire qui n’est pas systématiquement vérifié peut résulter en l’extraction des d’informations supposément protégées. « Si l’application ou la base de données ne filtre pas et ne valide pas ce qui est entré dans ces champs, il est possible que la commande se rende directement à la base de données pour obtenir une liste de clients ou de numéros de carte de crédit. »
Enfin, une autre problématique émane des protocoles Web, comme PHP et JavaScript, qui sont non malicieux en apparence, mais qui sont encodés de façon à transformer le fureteur installé sur un ordinateur en un « balayeur » pour sonder une application Web et en acheminer les vulnérabilités aux fraudeurs. Puisque le code réside dans la mémoire vive d’un ordinateur, les preuves s’effacent une fois que le fureteur est éteint. Or, M. Cusin souligne que ce procotole n’est pas bloqué ni en entrée, ni en sortie par les organisations, sinon une page Web sur deux ne s’afficherait pas ou serait inutilisable.
« On peut avoir un poste de travail avec un antivirus à jour et actif, un serveur mandataire, de la détection d’intrusion et des coupe-feux, mais la commande de balayage d’un site passera à travers tous les mécanismes parce que ce n’est pas un virus, un ver, un code malicieux ou une attaque. Avec le Web 2.0, on est capable d’utiliser les protocoles eux-mêmes de façon détournée pour faire les attaques… La menace devient un monde parallèle. », constate M. Cusin.
Prudence et proactivité
Pour contrer les menaces impliquant des applications Web, M. Cusin estime que la prévention nécessite une approche multicouche.
La bonne vieille approche de la sensibilisation et de la formation incitera les utilisateurs à ne pas fournir n’importe quelle information sur n’importe quel site. « Il faut éduquer les usagers à être suspicieux, remarque M. Cusin. Si on va sur Hacker.com, il est possible qu’on reçoive du code non voulu. Si on va sur le site d’une compagnie sérieuse qui prend la sécurité au sérieux, il y a moins de chances d’avoir un problème… Mais le risque n’est pas à zéro. »
M. Cusin estime que l’accès à une application Web destinée à l’utilisation interne d’une organisation peut être restreint par le recours à un réseau privé virtuel, sans être visible sur Internet. À propos du fureteur, il suggère de recourir à un module enfichable qui bloque les scripts par défaut et demande la permission d’exécuter un script ou qui mise sur des listes blanches (scripts permis) et noires (scripts bloqués). Au niveau du périmètre informatique, le filtrage des adresses URL bloquera l’accès à des adresses problématiques, alors que des passerelles XML et des coupe-feu en feront autant pour des contenus malicieux par l’examen des protocoles utilisés.
En matière de développement, M. Cusin met en garde contre la récupération sur Internet et l’insertion aux applications de codes disponibles sur Internet, puisqu’ils peuvent se comporter de façon sournoise et causer une brèche. « On crée une faille et on a déjà une porte dérobée dans notre application dès le premier jour. Il faut faire attention à la construction de l’application », recommande-t-il.
D’autre part, il recommande de réaliser des audits à l’interne et à l’externe, à l’aide de logiciels et de services de fournisseurs, pour s’assurer que l’application Web réponde aux attentes en matière de sécurité. La validation des champs d’un formulaire permet de déceler un problème rapidement et de le colmater avant qu’on tente d’exploiter une vulnérabilité.
« Un audit peut être fait un jour sans problème, mais la situation peut changer le lendemain en raison d’une mise à jour, de la modification du site ou de la connexion d’une base de données. Au fur et à mesure que l’on ajoute des fonctions ou des capacités, il faut s’assurer que ça cadre bien avec ce qui est en place, sinon on peut induire une faille tout en ayant un faux sentiment de sécurité », estime l’expert.
« Idéalement, il faudrait balayer l’interface Web de façon quotidienne, par exemple la nuit. Si un nouveau code s’est installé la veille et que l’on voit la nuit que l’application est sujette à de l’injection [de base de données] SQL ou à du cross-site scripting (faille XSS en français), un rapport le mentionne le lendemain et on peut corriger le problème. Il faut être proactif », ajoute-t-il.
Envisager les opportunités
La productrice Web Anick Tardif est propriétaire de L3interactive, une firme de développement Web de Québec. Depuis 2005, l’entreprise produit des systèmes de gestion des contenus et des systèmes de gestion d’envoi d’invitations personnalisées pour le compte de petites entreprises.
La firme incite ses clients à utiliser des applications en ligne pour l’élaboration et la réalisation du projet, comme la suite de bureautique Google Documents. Elle met également à leur disposition des outils de gestion des envois de bulletins électroniques et de l’hébergement Web, pour réaliser certaines tâches de façon autonome. La petite équipe de développement de la firme utilise des applications Web aux fins du travail.
« C’est moins coûteux d’avoir une application Web que d’avoir des licences sur chacun des postes. Ce sont des solutions très évoluées qui coûtent moins cher pour le rendement qu’elles procurent », estime la productrice.
La sécurité est également considérée comme un enjeu d’importance. Mme Tardif fait état de discussion en ce sens avec des clients, où il est autant question du recours aux certificats de sécurité pour les interfaces impliquant l’inscription de données personnelles, de l’adaptation de politiques de confidentialité et des risques de la conservation des données d’authentification aux applications Web sur les postes de travail.
« Si les solutions envisagées sont hébergées à l’interne, on souligne la réalisation de sauvegardes et de la mise à jour constante de la sécurité. S’il s’agit d’applications hébergées par des tiers, gratuites ou payantes, nous vérifions [le niveau de] confort du client quant aux probabilités d’une perte de données ou d’un problème de sécurité », indique-t-elle.
Mme Tardif souligne que la recommandation aux clients de recourir aux applications Web de grands fournisseurs a trait à leur meilleure capacité d’assurer la sécurité des applications et de leurs contenus.
« Notre objectif est toujours de trouver des solutions accessibles, car notre clientèle est composée de petites entreprises qui ont peu de moyens, mais qui veulent en faire autant que les grandes entreprises. Nous pouvons faire une solution à l’interne, où il y aura plus de sécurité, ou bien mettre des vidéos sur sur un compte payant de YouTube, ce qui coûte moins cher que de développer [une solution maison]. On y pensera à deux fois avant d’aller avec un petit joueur. »
Cela dit, Mme Tardif croit qu’une organisation doit définir quels types de contenu seront hébergés dans des applications de tiers et ce qui faudra faire en cas de perte partielle ou totale. Elle privilégie les solutions redondantes, comme le transfert d’une copie des courriels sur un serveur interne en complémentarité à la conservation des messages dans un compte en ligne.
« On peut commencer à utiliser une application Web avec des comptes gratuits, mais une entreprise doit opter pour un compte corporatif qui garantit des sauvegardes. Plus cela évolue, plus on exige de la sécurité et de la confiance à l’aide de preuves de sécurité », estime-t-elle.
Jean-François Ferland est journaliste au magazine Direction informatique.
À lire aussi cette semaine: Conjoncture économique favorable pour le logiciel-service Perspectives : les applications Web Repères : les applications Web
