Comprendre la sécurité web - C. Villeneuve

Titre : Comprendre la sécurité web
Intervenant : Christophe Villeneuve alias hellosct1
Lieu : Ubuntu Party - Paris
Date : Novembre 2016
Durée : 42 min 59
Visualiser la conférence webm
Licence de la transcription : Verbatim

Transcription

Bonjour à tous et bonjour à toutes. Là il y avait une petite image, elle sera mise dans les slides ; je n’ai pas compris pourquoi elle a disparu, mais bon, il y avait un petit bouclier avec un petit chevalier qui était en train d’essayer de pénétrer et de transpercer le bouclier. Donc je trouvais ça rigolo. Mais vous la verrez après.

Tout d’abord qui je suis ? Je m'appelle Christophe Villeuneuve. Je suis consultant pour l’entreprise AUSY. On est ISO, je ne sais plus le numéro, mais c’est autour de la sécurité donc on est impliqués. Je suis aussi impliqué dans tout ce qui est autour de PHP, MariaDB. Je suis aussi représentant Mozilla et puis aussi Drupal. Et puis, bien entendu, j’ai amené deux compagnons, on va dire, deux éléphants qui sont là, qui sont toujours très friands de trouver des familles d’adoption et ils sont toujours là aussi pour ramener des bonnes connaissances et des bonnes nouvelles auprès de leurs familles et de tout le monde.

Je suis aussi auteur du livre Drupal avancé, donc autour du CMS [content management system, NdT]. Et les problématiques de sécurité de sites web, j’ai un certain vécu et tout ce dont on va parler aujourd’hui, il y a certains des cas que j’ai eu la joie et la tristesse aussi de bénéficier, c’est-à-dire me faire pirater. Oui, avant que je me mette vraiment dans la sécurité, parce que c’est toujours très gênant, pour vous je ne sais pas, mais pour l’avenir, lorsqu’on se fait pirater un site internet, c’est toujours désastreux. Pas au niveau utilisation, mais au niveau conséquences. Et là, les conséquences c’est important, donc on va essayer d’anticiper ces conséquences et surtout éviter l’inévitable c’est-à-dire : « Mince, j’ai un joli site, mais il s’est fait hacker. »

Bien entendu quelques petits événements de cette année que j’ai pu organiser.

Quand on parle de sécurité, souvent, quand on était jeunes, enfin quand moi j’étais jeune, pour vous je pense que peut-être vous avez déjà eu peur, mais souvent c'est « moi je n’ai pas peur, je ne crains pas la sécurité, c’est pour les autres. Ça ne sert à rien, ce n’est pas le but. Ce n’est pas pour nous, c’est pour les autres. Donc moi je suis tranquille, je ne fais que des choses propres. » Souvent c’est ça que mes collègues ou d’autres personnes, quand je discute, me disent : « Non, non, moi ça va très bien. Les attaques, ah, ah, je rigole, je n’en bénéficie pas. » Manque de pot, à l’heure d’aujourd’hui, il y a 10 ans on disait la même chose et aujourd’hui on le dit encore, toujours, que les attaques ça touche tout le monde. Quelle que soit la méthode, quelle que soit la technique, et même à votre insu vous pouvez vous faire attaquer, sans vous en rendre compte.

Donc toutes ces notions, cette approche, vous allez avoir peur. Alors ne soyez pas tristes, parce qu’à la fin de la session il y a quand même des solutions, mais souvent, quand j’aborde cette thématique autour des sites web, eh bien, souvent après j’ai des questions me disant : « C’est vrai tout ça ? » Donc oui, il y a des choses qui sont vraies, il y a des choses que je ne vais pas pouvoir vous dire ici, que je pourrai vous dire sur le stand de Mozilla, tout à l’heure, si vous venez me voir, mais il y a des choses qui peuvent faire très peur. Mais on n’est pas là pour prévoir le pire, on est là pour éviter le pire.

Quand on parle, souvent, de sécurité, eh bien on a ces petites notions de : « Ça ne sert à rien. C’est pour les autres. La sécurité je ne m’en occupe pas. Je n’ai pas besoin d’antivirus, je suis protégé. » Mais manque de pot, même si vous ramenez une clef USB, même si vous allez sur Internet, eh bien déjà l’Internet, c’est déjà une faille de sécurité. Oui ! Déjà juste en allumant votre ordinateur c’est aussi une faille de sécurité parce qu’il n’y a énormément de choses dont vous n’avez pas le contrôle et qui dit ne pas avoir le contrôle dit envoyer les informations avec lesquelles quelqu’un peut faire, à l’insu de votre plein gré, des opérations que vous ne souhaitez pas.

Pourquoi parle-t-on de sécurité ? Parce qu’il y a toujours des menaces. On les entend à la radio, on les entend au journal de 20 heures, mais nous, la sécurité numérique, il faut penser que depuis toujours eh bien les hackers, les pirates, toutes ces personnes qui ont des plus ou moins bonnes ou mauvaises intentions vont essayer de trouver quelque chose, comme la petite souris, le moyen de récupérer – là ici c’est le morceau de gruyère, même s’il y a le piège – eh bien le hacker, c’est ça. Il va essayer de trouver, par n’importe quelle manière, de pouvoir pénétrer dans votre site internet. Les risques, eh bien c’est de se faire hacker, c’est-à-dire une jolie page noire, où il y a marqué hacké. C’est toujours dommageable, surtout quand c’est quelqu’un de votre famille qui vous appelle en disant : « Eh ! Ton site on ne peut plus consulter l’information ! »

Les conséquences, quand on se fait pirater, c’est que si votre site est fixe, c’est-à-dire des pages qui ne bougent pas, il n’y a pas de base de données, ce n’est que du contenu, ce n’est pas très gênant. Et encore, on peut se servir de cet espace comme de zone de stockage, c’est-à-dire que votre site ne sera plus du tout accessible. Par contre, s’il possède une base de données, vous allez être confronté à un carnet d’adresses. Donc le carnet d’adresses va être aspiré vers l’extérieur, sans que vous ne vous en rendiez compte. Vous allez perdre des données. Vous allez me dire : « Bon, ce n’est pas grave, j’ai juste quelques données, quelques contenus, je peux les retaper ». Oui, quand c’est un site personnel, quand c’est un blog, quand c’est un site vitrine. Mais lorsqu’on parle de vitrine, c’est aussi un risque. Parce que la vitrine, c’est la vitrine, l’image que vous faites pour vous, pour la compagnie, pour la société où vous bossez. Et si vous faites quelque chose et que la compagnie, d’un seul coup, voit que son site se fait pirater, ce n’est pas bon du tout pour son image, pour continuer sa survie dans les mois et les années après.

Pour cela, il existe énormément de pistes pour savoir si les outils, ce que vous avez l’habitude d’utiliser, peuvent être à jour. C’est-à-dire, je ne sais pas si vous faites des sites internet, on va dire que oui, vous faites des sites avec un WordPress, un Dotclear, avec un CMS, un Framework, des langages plus compliqués, eh bien tous ceux-ci ont une vie. C’est-à-dire que, régulièrement, il y a des mises à jour comme un logiciel bureautique que vous utilisez tous les jours, un logiciel Windows, Linux, un LibreOffice, eh bien régulièrement vous voyez des mises à jour. Il faut les mettre en place, il faut les appliquer. Le site internet c’est la même chose, parce qu’il y a des choses que référencent. C'est une bibliothèque de failles qui s’appelle CVE security1 où comme là, là je l’ai téléchargée il y a quelques heures, c’est-à-dire qu’il y a quand même en failles très critiques, 11 929 sites outils qui sont identifiés, comme quoi on peut pirater. On ne va pas entrer dans les détails, mais ça va impacter tout.

Moi ce que j’ai fait, je m’en excuse auprès d’Ubuntu puisqu’ils m’ont accordé de venir ici, j’ai regardé Ubuntu. Ubuntu que vous avez pu utiliser ou télécharger ou installer, puisqu’on est dans une Ubuntu Party, et donc j’ai regardé. Et je vois qu’en 2016, eh bien il y a quand même encore pas mal de failles de sécurité qui ont été identifiées. C’est-à-dire que le système d’exploitation, aussi, bénéficie de risques de failles, de prises de contrôle, différentes attaques de piraterie. Lorsqu’on clique sur une, là c’était une faille XSS, heureusement on a l’information comme quoi la faille a été détectée telle date et là vous voyez, une semaine après, elle a été corrigée. Donc si vous mettez à jour, comme ici Ubuntu, eh bien vous êtes sauvé parce que les mises à jour sont faites. Le seul risque c’est que vous avez 7 jours avec des failles et des susceptibilités de vous faire pirater.

Cependant les vulnérabilités sont souvent connues. Lorsqu’on fait un site internet, eh bien souvent on oublie de tester la sécurité. Vous faites votre site internet, vous faites votre habillage, vous faites votre contenu, tout est beau, et vous le mettez en production. Le seul problème c’est que le CMS que vous avez utilisé, vous n’avez pas ajouté les modules de sécurité, c’est-à-dire que dans les préférences où ce sont des extensions supplémentaires, il faut les activer. Lorsque vous activez ces extensions, eh bien vous allez avoir une sécurité supplémentaire fournie par le CMS, le Framework, l’outil que vous utilisez. Si vous n’activez pas ces cases-là, vous allez être confronté à un risque de faille de sécurité.

Il y a aussi beaucoup aussi d’évolutions, c’est-à-dire qu’il y a la partie core, la partie basique que vous utilisez, mais les extensions, les add-ons, les évolutions, c’est-à-dire que un Dotclear, un CMS, un Framework, vous rajoutez toujours des modules extérieurs. Ces modules, il faut penser à les maintenir, parce que eux aussi, sont des failles de sécurité, des risques de failles.

Les différents types qui peuvent être confrontés lorsqu’on est sur le Net et lorsqu’on fait des sites web, c’est touchant le matériel. Quelqu’un qui vient vers vous et qui utilise votre ordinateur : vous n’avez pas fermé votre session et donc il peut faire des choses à votre insu.

Des clefs USB. Les clefs USB sont tellement puissantes et avec un système de cache qu’on met la clef USB, on peut récupérer directement vos identifiants, même si la clef USB a dit qu’elle est vierge.

Les smartphones, les mobiles, tous vos téléphones, ce que vous avez dans vos poches, eh bien c’est aussi des failles de sécurité, parce que vous allez aller sur Internet, vous allez pouvoir consulter des informations. Donc tout ceci, si votre site internet ne respecte pas les normes, ne respecte pas les normes de sécurité et les protections, vous allez être confronté à tout ceci.

Bien entendu lorsqu’on parlait de logiciel, eh bien le logiciel est aussi, si vous ne le maintenez pas à jour, vous dites : « C’est bon, j’ai ma licence », mais la licence est expirée depuis deux ans ! Eh bien non, manque de pot, votre logiciel que vous allez utiliser, eh bien pendant deux ans, vous risquez de bénéficier de ces failles qui ont été décelées et trouvées.

Le Web : le navigateur. Là aussi. J’ai mis quelques navigateurs, les principaux. Le navigateur est aussi une faille de sécurité, parce que le navigateur qui n’est pas mis à jour, qui n’est pas maintenu, eh bien lorsque vous allez naviguer sur un site internet, avec des comportements malicieux, vous allez pouvoir vous faire pirater.

Et pour finir – mais ce n’est pas fini la conférence – il y a l’Internet des objets : tout ce qui est aujourd’hui et surtout ce qui va sortir demain, tout ce qui est connecté, qu’on voit dans tous les magazines eh bien là-aussi, là on a beaucoup de choses dont parler.

Les points faibles, c’est surtout les bases applicatives. Donc on va voir quelques petits points, d’abord les fonctionnalités de base, la balise qui pose problème et puis, ensuite, on va aller rentrer plus dans le détail.

La principale vulnérabilité c’est ce symbole [est affiché le symbole « < », NdT]. Lorsqu’on fait des sites internet, on déclare une balise, HTML, on déclare des fonctionnalités un table, un div, etc. On commence toujours par cette balise, cet inférieur. Eh bien cet inférieur-là a énormément de possibilités. Vous allez me dire : « C’est juste un caractère ! » Eh bien oui, mais c’est plus qu’un caractère, parce que ce caractère, lorsqu’on le convertit en décimal, on obtient celle valeur-là, [est affiché « < », NdT]. Cette valeur-là peut être interprétée par d’autres logiciels plus ou moins malicieux, plus ou moins compréhensibles. Mais si on manipule des caractères spéciaux, ou normaux, eh bien on peut aussi manipuler des double quote, des simple quote, l’amperstand, inférieur, supérieur. C’est-à-dire que chaque caractère, il existe des fonctionnalités quel que soit le langage que vous utilisez – aussi bien du Python, du C, du Pearl, du PHP, du Ruby ou d’autres – eh bien vous pouvez, à partir de ces fonctionnalités, si vous n’en prenez pas soin, eh bien bénéficier d’une attaque de base. Cette attaque de base, lorsqu’on veut faire une injection, on va utiliser supérieur inférieur en lui disant script quelque chose et il va exécuter du code. Et là on voit le caractère en clair, mais pensez que, comme tout à l’heure ma petite souris elle est malicieuse pour attraper le morceau de gruyère. Eh bien on peut directement convertir ce caractère en Unicode et si vous n’avez pas géré correctement ce caractère-là, avec le principe de l’Unicode, eh bien vous avez un risque. C’est pour ça que dans vos langages il existe des fonctionnalités qui permettent de neutraliser, de couper toutes ces barrières de supérieur et inférieur.

Bien entendu, la fonctionnalité est vraiment pure et dure, mais il n’y a pas que ça, parce que vous savez que l’Internet, le Web c’est tellement un grand univers et dans ce grand univers il y a des trojans, il y a des injections, il y a tout plein d’attaques et différentes méthodes de possibilités de pouvoir pénétrer.

On va parler d’un trompe-l’œil que j’aime bien qui s’appelle le sténographe, c’est-à-dire qu’on va cacher quelque chose et vous allez essayer de trouver la réponse. C’est-à-dire que je vais vous montrer une photo et vous allez me dire quelle est la courbe la plus longue dans l’image. Il y en a qui ont peut-être trouvé, d’autres qui n’ont pas trouvé : la courbe la plus longue c’est celle-là ; ce n’est pas celle peut-être que vous pensiez, parce que là ici, elle était au fond, mais je l’avais cachée par une autre image, à votre insu. Ce type d’effet, de représentation, eh bien c’est ce que votre site internet peut faire, c’est-à-dire que votre site il est bien, mais manque de pot, derrière vous vous êtes fait pirater et donc il y a d’autres fonctionnalités, sans que vous en ayez eu le contrôle, parce qu’un pirate a fait quelque chose de malin.

Au niveau code comment ça va se comporter ? J’ai pris un petit exemple, un château. Un château fort, à l’époque du Moyen Âge, ils se mettaient toujours en haut des collines avec une seule route d’accès pour forcer ceux qui vont attaquer, les assaillants, de pouvoir passer obligatoirement par cette route pour arriver au château, ce qui permettait d’être vu. Un site internet c’est pareil ; il faut penser la même chose. Lorsque vous faites votre site internet, il faut penser comment naviguer, comment accéder aux contenus. Est-ce qu’il faudra des identifiants – un login, un mot de passe ? Est-ce que vous aurez besoin d’accéder différemment par une seule porte d’entrée ou plusieurs. Donc tout ceci ce sont des choses de base. C’est-à-dire qu’il faut forcer l’utilisateur à aller prendre la route. Si vous lui permettez d’aller prendre le petit chemin à côté, il y aura toujours quelqu’un qui va le trouver, le petit chemin à côté, pour contourner la protection et c’est là que ce n’est pas bon. Donc il faut penser comme au Moyen Âge, à l’époque des châteaux. Vous êtes votre site internet en haut de la colline, avec un seul chemin d’accès.

Mais sinon, lorsqu’on a des anomalies, quelles qu’elles soient, et surtout pour ne pas donner des pistes supplémentaires auprès des internautes qui vont venir consulter votre site internet, il faut penser que s’ils font n’importe quoi en tapant dans l’URL, eh bien ils peuvent avoir ce genre d’informations : une erreur 404, une erreur 500. C’est-à-dire, ce sont des informations supplémentaires qui sont dévoilées et c’est toujours dommageable, parce que lorsqu’on a ce type d’informations, ça veut dire que, à partir de là, on connaît que c’est un serveur Apache, on peut après remonter l’information comme quel est le langage que vous avez utilisé, les versions, et si votre version n’est pas à jour, eh bien avec le CVE au début, on a l’ensemble des informations pour pouvoir récupérer votre contenu de site internet, juste parce qu’il y avait une page 404 ou une page 500 qui était affichée.

Et là c’est véridique, on peut le faire facilement en cinq/dix minutes et sûrement nettement moins pour quelqu’un de professionnel. Et il faut penser que ces personnes qui ont ces mauvaises intentions, eh bien elles ont ces habitudes et ont ces techniques pour pouvoir le faire.

Bien entendu, pour contrer tout ceci, il faut bloquer ces quatre pages, ces informations eh puis envoyer vos données dans des logs, dans des fichiers qui vous permettront d’être consultés et d’être analysés pour après.

Il y a des minimums de sécurité, quand même à respecter, lorsqu'on fait son site web, c’est surtout au niveau authentification. C’est une des premières étapes. La première étape c’est de ne rien stocker en clair. Il faut penser à crypter, surtout les données sensibles, les verrouiller, les protéger.

Il faut identifier les sessions. Il faut respecter les normes et les protocoles qui sont utilisés. Il existe une doc française qui est traduite, MDN2, fournie par Mozilla et cette doc explique l’ensemble de fonctionnalités que vous pouvez lister, française, et sans besoin de chercher comment on l’utilise.

Contrôler les accès, les droits. Tout ceci c’est important. Il faut penser à ne pas faire un open bar, que toutes les portes soient ouvertes, et les fenêtres, lorsqu’on veut accéder à une page supplémentaire. C’est-à-dire, lorsque vous tapez votre contenu, vous voulez remplir un nouvel article : lorsque vous saisissez votre nouvel article, vous allez vous identifier pour pouvoir accéder à une autre interface, pour pouvoir taper votre article et après l’enregistrer et ce sera affiché. Eh bien ces accès-là, il faut penser que ça soit un minimum d’accès, pour éviter que n’importe qui, monsieur Tout-le-monde puisse accéder à ces pages.

Et bien sûr, lorsqu’on fait des mises à jour des évolutions, il existe des fonctionnalités qui permettent de pouvoir neutraliser l’ensemble de ces points de sécurité.

Les autres solutions. Là ça va être des solutions externes, parce qu’on a vu les techniques, on a vu différentes choses, ces fonctionnalités sont vraiment celles de base mais vraiment les premières et si on ne les fait pas déjà tout le reste, après, c’est porte ouverte.

Donc les autres solutions c’est OWASP. OWASP3 c’est un organisme, c’est une fondation qui est là, qui fournit énormément de documentation et d’outils pour pouvoir aider les utilisateurs à réaliser un site propre, un site correct, bien sûr tout en respectant les normes et les protocoles.

On va essayer d’en voir quelques-uns mais plus en top 10, parce que, régulièrement, tous les deux/trois ans, ils publient un top 10, c’est-à-dire le hit-parade des failles de sécurité identifiées. Et souvent, la première qui ressort régulièrement, c’est l’injection. Là c’est aussi la première faille de sécurité importante de l’outil.

Je vous ai mis les deux dernières années, les deux derniers numéros, c’est-à-dire 2010/2013. La première version est sortie en 2003, c’est-à-dire que depuis, il y en a régulièrement.

Lorsqu’on regarde ces analyses, 2013, on reste toujours sur l’ensemble des failles de sécurité, l’injection, on va voir un petit plus dans le détail, juste après, ce que c’est de l’injection. On peut voir aussi qu’il y a une petite perte au niveau XSS [cross-site scripting, NdT]. On peut voir que les mauvaises configurations commencent à être prises en compte, c’est-à-dire qu’il y a certaines failles qui commencent à diminuer. Certains types et certaines méthodes d’attaque de piraterie diminuent, changent. Mais, par contre, on laisse des mauvaises configurations de sécurité, comme aujourd’hui, eh bien les balises de base que je vous ai montrées, pour lesquelles les gens font : « Ah, c’est bon, j’ai confiance en mon outil ! » Manque de pot, ce n’est pas vrai puisque cette faille était ici, donc en huitième position, elle est quand même montée en cinquième, et là, en 2016, ce qui est en train d’être rédigé, eh bien elle doit être en troisième position. Donc elle monte en force parce que les fonctionnalités de base, la sécurité, les fonctionnalités de base de HTML, lorsqu’on fait un site internet, eh bien on ne s’en occupe plus. On pense que l’outil qu’on va utiliser fait le nécessaire, en vérité non ! Il faut penser que l’outil ne fait pas le nécessaire, il faut penser à les mettre en place.

En top 10, pour 2016, donc c’est une documentation qui est en cours de développement, vous avez la chance de l’avoir, j’ai pu l’obtenir cette nuit, donc ce sont les orientations de ce qui nous attend dans le prochain rapport, qui devrait être publié et disponible correctement l’année prochaine, en 2017. C’est-à-dire que la vérification de tout ce qui est sécurité, quel que soit le niveau de votre connaissance, de votre développement, votre navigation, sera toujours l’un des premiers critères et une des premières failles de sécurité.

Tout ce qui est communication avec les requêtes, quelles qu’elles soient, les requêtes vers la base de données, eh bien là aussi, ça sera une énorme faille de sécurité qui restera toujours d’actualité. Quand on parle de requêtes, c’est là où on stocke vos identifiants, votre nom, votre adresse, votre code postal, votre ville, date de naissance, etc., donc toutes ces informations personnelles, et ce n’est pas bon du tout. Tout ce qui est aussi les champs d’entrée, les inputs, l’encodage. Donc comme vous pouvez voir il y a énormément de choix et de possibilités qui sont encore d’actualité alors qu’en réalité, on est quand même en 2016, la fondation existe depuis 2001. Ça veut dire que ça fait quinze ans que ça existe et que c’est toujours présent.

Au niveau sécurité pour vous, concrètement, eh bien, même si la petite souris a réussi à obtenir gain de cause, il y a toujours le prédateur, le chat qui est toujours aussi malicieux pour réussir à contrer ou à accéder à sa proie. En comparaison avec les langages du Web, comme vous pouvez le voir, eh bien il y a différentes méthodes et quel que soit le niveau, quelle que soit la position, on va prendre un petit exemple : l’injection.

L’injection, j’en ai parlé à plusieurs reprises, c’est la première position qui se trouve en haut de tous les hit parades. L’injection va se traduire d’abord du côté serveur, donc pas trop pour nous pour le site web. Là, ça sera beaucoup plus du côté architecture, c’est-à-dire du côté où l’emplacement de votre site web sera stocké.

Souvent les failles de sécurité proviennent de la configuration pas à jour, le système d’exploitation, l’OS. Les conséquences, c’est que vous allez transformer votre site web en une machine zombie, c’est-à-dire que c’est quelque chose qui va exécuter une fonctionnalité, pirater quelque chose, récupérer des informations ailleurs. Donc, ce n’est pas bon du tout lorsqu’on administre un site internet, surtout si on n’a pas désactivé les fonctionnalités de base, comme là ici dans php.ini, donc là c’est pour PHP, mais dans Python, dans les autres langages, Ruby, Pearl, etc., il y a aussi l’équivalence, donc à vous de rechercher l’équivalence.

Comment ça se présente ? Eh bien si je fais un « echo exec » ou « whoami », eh bien il va me sortir des informations. Je ne l’ai pas mis parce que ça va me sortir mes informations personnelles, donc je ne voulais pas vous les transmettre. Mais si vous voulez le faire chez vous dès demain ou tout à l’heure, exécuter cette fonction, l’éditer sur votre ordinateur, faites-le et vous verrez exactement ce que vous pouvez obtenir.

Au niveau SQL [Structured Query Language, NdT], donc c’est vers la base de données. La base de données c’est lorsqu’on remplit un formulaire et qu’on va envoyer à la base de données les informations. Vous remplissez vos coordonnées et quand vous appuyez sur le bouton « confirmer », eh bien ça va envoyer directement à la base de données le nom, l’adresse, votre code postal, la ville, surtout si vous avez fait un site marchand ou autre chose, eh bien ça va envoyer les informations que vous pouvez, après, retrouver sur votre facture, que vous retrouvez sur le bon de livraison, etc.

Les conséquences. Eh bien cette communication entre la page internet et la base de données, il y a un tunnel. Ce tunnel, s’il n’est pas sécurisé, il y a un risque d’injection. Votre formulaire n’est pas sécurisé, il ne respecte pas les normes, les protocoles, il va y avoir aussi le même problème, son contenu risque d’être volé. Et du côté de la base de données aussi, la même chose. Donc à chaque étape vous avez un risque potentiel de perte de contenu.

Par exemple, une petite requête. Là je veux connaître les informations sur mon utilisateur qui a un nom et un mot de passe. Donc là, en s’appuyant sur ce principe-là, donc j’envoie un login, un mot de passe, la base de données me répond : « Merci, voilà les informations. »

Maintenant je n’ai pas le login, je n’ai pas le mot de passe, mais je n‘ai pas sécurisé ma base de données, ma connexion. Eh bien je lui dis : « OR 1= 1 ou passe » et il me répond « merci ». C’est-à-dire que là il va me retourner l’ensemble du contenu de la base de données. Ça marche, je vous l’assure, j’ai déjà fait. Pour sécuriser tout ceci, il y a même cette fonctionnalité, là, c’est-à-dire que je lui demande d’effacer le contenu de tous mes contacts, juste à partir de cette fonctionnalité : c’est-à-dire qu’à votre insu, vous allez perdre tous vos abonnés. Bien sûr, au préalable, la personne malveillante aura récupéré le contenu avant, elle aura fait un backup pour elle.

Au niveau protection, il faut penser à mettre des antislashs. Vous savez, tout à l’heure, les quote et double quote que je vous ai montrés, les fonctionnalités la faille la première, eh bien là il y a un intérêt. Donc si vous les neutralisez par l’antislash, eh bien c’est important. Ou utiliser, donc là c’est en PHP, utiliser les fonctionnalités prévues par le langage. Et qui dit fonctionnalités fournies par le langage, eh bien c’est lui qui fait le travail. Donc c’est quand même important d’utiliser et de lire la documentation du livre ou du langage.

Côté front, l’injection se traduit de la manière suivante : c’est-à-dire que ce sont les champs qui vont permettre d’accéder à du contenu. Par exemple, quand vous allez sur votre banque pour consulter vos comptes, eh bien vous avez toujours un login, un mot de passe, et puis de plus en plus, même maintenant quasiment partout, des clics par la souris pour pouvoir accéder ou déverrouiller un code supplémentaire qui peut être soit votre identifiant, soit sur votre mot de passe pour accéder à vos comptes. Tout ceci, ce sont des informations qui sont importantes et des méthodes qui permettent de sécuriser les données de la banque. Tout cela c’est utile. Si vous ne faites pas ces protections-là, n’importe qui pourra obtenir les informations de vos codes bancaires. Principalement, c’est lié au mot de passe, les Cartes bleues. Les Cartes bleues, c’est-à-dire que si vous avez obtenu d’un seul coup, vous regardez votre compte et que vous voyez des relevés de Carte bleue et que vous n’avez pas fait de règlement, eh bien ça vient parce que le site n’est pas sécurisé, entre autres. Il n’y a pas que ça, il y a d’autres choses, mais ça c’est une des méthodes.

Au niveau métier, vous pouvez aussi connecter avec d’autres services, des web services, des services LDAP [Lightweight Directory Access Protocol, NdT], eh bien là aussi, la même chose : si on ne respecte pas les normes, les langages, les protocoles, vous avez des risques potentiels. En gros partout, quel que soit votre site web, vous avez des failles à tous les niveaux.

Cependant, votre site web, il est aussi consulté sur tablette, sur mobile. Et si votre application ou votre projet vous lui dites : « Ah, je vais le faire sur mobile », pourquoi pas ! Mais là aussi, on va se retrouver avec un top 10, fourni par OWASP.

Donc le premier c’était en 2012, 2014 et 2016. 2016, ils sont en version RC, donc en release candidate,c’est-à-dire qu’il est bientôt sur le point de sortir. Ça n’a quasiment pas bougé entre les deux, entre ces dernières versions.

On parle de cela parce que l’application mobile, c’est, on va dire, la tendance, depuis quelques années sur « on va faire une application mobile parce que c’est fun, c’est super, on peut y accéder ». Manque de pot, souvent l’application mobile, on se retrouve vingt ans avant, oh oui, vingt ans ! C’est-à-dire qu’on ne s’occupait pas de la sécurité, on faisait confiance au matériel ; on pensait que l’authentification sécurisée n’était pas utile ; lorsqu’on communiquait avec une application qui était dans le bac, c’est-à-dire un gros site internet, eh bien ce n’était pas utile de crypter, de protéger, de chiffrer. Tout ceci, comme vous pouvez le voir, la liste est quand même assez longue, il y a quand même dix points, les dix failles les plus reconnues et chacune d’elles est un risque. C’est-à-dire que là vos téléphones sont allumés, vous avez aussi un risque, entre temps vous avez pu consulter le programme ou la session qui va se dérouler derrière. Un code malicieux sur le site d’Ubuntu aurait pu récupérer le contenu de vos téléphones, même si vous avez vos téléphones en mode vibreur, et c’est vrai. Je vous rassure, je ne vais pas le faire, mais on peut le faire. Tout ceci pour vous montrer, parce que l’application n’a pas respecté les normes et les sécurités.

On ne va pas s’attarder dessus, vous pourrez lire à tête reposée, c’est tout petit, je suis désolé parce que j’avais beaucoup de choses. Les failles, souvent, sont liées lorsqu’on fait un site, une application mobile sur les problèmes de sécurité, de cryptage, le niveau n’est pas assez élevé. On peut même attaquer directement, mais ça on n’y peut pas grand-chose en tant que développeur de site web, c’est qu’on peut directement attaquer le noyau, c’est-à-dire l’OS. Vous avez des Androids, vous avez des iPhones, vous avez d’autres systèmes, il est possible d’attaquer jusqu’à ce niveau-là. Pour l’instant, ça reste encore très marginal, mais ce sont des failles qui vont être de plus en plus connues et identifiées, parce que le système d’exploitation de vos téléphones, au bout de quelques années ou quelques mois, vous allez avoir des messages comme quoi il faut faire une mise à jour et si vous ne la faite pas, eh bien là aussi vous avez des risques potentiels, pour votre application et pour l’utilisateur.

L’autre point qui est en train d’arriver et qui a déjà commencé. Pour l’instant on fait de la bidouille, c’est rigolo, ce sont les objets connectés. Arduino, Raspberry Pi, voiture connectée, tout ça c’est tout nouveau. Manque de pot, le nouveau qu’on voit aujourd’hui, ça existe depuis cinq/six ans, même beaucoup plus. Ces objets connectés, que vous pouvez connecter et embarquer de l’Internet et votre site internet pourquoi pas, parce que c’est toujours bien d’avoir, par exemple ici pour permettre à vos enfants si la voiture est connectée, vous avez Internet donc ils peuvent jouer directement à leurs jeux favoris en ligne. Donc, qui dit communication, dit qu’il y a un minimum de travail à faire pour vous, parce que c’est votre site web qui est en jeu.

Le premier rapport date de 2014 et donc, là aussi, on se retrouve sur les mêmes principes : les problèmes de sécurité, les problèmes de communication, l’authentification, les problèmes de droit, la configuration. Tout ceci, même si j’en parle depuis le début, eh bien les objets connectés aussi sont impactés par ces approches-là, même si ça reste encore pas grand public, mais il faut penser que tout cela ce sont les failles qui vont arriver demain.

Et quand on parle d’avenir proche, eh bien, les tendances de tout ce qui est les objets connectés, l’Internet des objets, puisque de plus en plus on nous propose des solutions connectées. Tout récemment, et ce n’est pas encore sorti dans le commerce, mais il existe une poêle connectée, je ne dirai pas le nom du fabriquant, mais cette poêle connectée, vous la mettez sur votre gazinière, vous sortez un steak haché ou une autre viande de votre congélateur, vous la mettez dans la poêle, vous programmez en lui disant : « Je veux que ça soit à point, saignant » ; quelques minutes après vous allez entendre un bip, ça veut dire que la viande il faut la retourner, un deuxième bip trois/quatre minutes après, et votre viande est prête et vous n’avez plus qu’à la manger. Et elle est bonne, je vous rassure ! Et pourtant, il y a 10 minutes, elle était encore dans le congel !

Lorsqu’on parle d’objets connectés, on ne peut pas se connecter en mettant un mot de passe dans une poêle, non, pas pour l’instant.

Il y a aussi tout ce qui est communication vers le cloud, le big data, toutes ces nouvelles tendances.

Il y a aussi tout ce qui est la communication avec les utilisateurs, la sécurité liée avec la vie privée, et pourquoi pas mettre de la biométrie, par exemple avec votre doigt. Mais ça pose d’autres problèmes, parce que lorsque vous mettez votre doigt qui sert de verrou pour débloquer quelque chose, ça va toucher votre vie privée, parce qu’il n’y aura plus que vous qui pourrez débloquer le système. Donc on se retrouve avec beaucoup de problématiques, beaucoup de choses, mais ça c’est pour l’avenir. L’avenir, c’est-à-dire que c’est maintenant !

Au niveau outils, donc ça ce n’est pas de moi, mais c’est de OWASP, donc OWASP, dont vous aurez l’URL tout à l’heure, propose énormément de solutions. Des solutions qu’il faut, bien sûr, prendre avec attention, ne pas faire n’importe quoi, parce que ce sont des outils qui vont être là pour vous aider dans une tâche bien précise. L’ensemble de ces outils, il faut faire attention de ne pas faire n’importe quoi. Il existe aussi bien Framework que des outils qui vous permettent d’analyser les failles. Des documentations de ce que je vous ai montré succinctement, les top 10, donc chaque point et détaillé et illustré, c’est-à-dire qu’ils vous expliquent comment un pirate peut faire, comment il faut sécuriser. Et si vous lisez bien la documentation, vous avez la solution pour être sécurisé, pour une page précise, ça ne va pas sécuriser les autres points dont a pu parler, les autres tendances.

En résumé, ce à quoi il faut penser, c’est que le droit des données est important parce que c’est là, la survie de votre client, c’est la survie de votre notoriété et si vous ne mettez pas la sécurité dès le début ou que vous ne sensibilisez vos collaborateurs ou même vous-même en disant : « Avant d’attaquer mon site web comment je vais faire pour sécuriser, comment je vais protéger, sécuriser, garantir auprès de mon client ou de l’internaute un service correct », eh bien il faut mettre tout ceci en place. Bien entendu, avoir une politique de sécurité importante.

Concernant les rapports, eh bien je vous ai mis directement les liens que vous pourrez télécharger ou accéder à travers votre navigateur. Le site référence sur lequel je me suis appuyé c’était OWASP. Et je vous remercie pour cette écoute et je suis disponible à vos questions.

Public : Bonjour. Est-ce que vous pourriez éventuellement me répondre sur les fonctionnalités, celles qu’on doit désactiver en priorité ?

Christophe Villeneuve: Tout à l’heure, j’ai montré une liste de fonctionnalités qui sont listées dans php.ini. L’ensemble de ces fonctionnalités sont toutes à désactiver, mais la majorité, en prenant les dernières versions PHP 5, 6, PHP 7, elles sont déjà désactivées, la plupart nativement, donc c’est plus une vérification. Par exemple vous utilisez une version beaucoup plus antérieure, un PHP 4, PHP 5, parce que ça existe encore, eh bien désactiver cette liste est nécessaire. Donc l’ensemble des points qui ont été listés doivent être désactivés, là il n’y a pas photo, mais certaines sont déjà désactivées par défaut suivant la version de PHP que vous utilisez. Donc il faut regarder votre version de PHP et vous pourrez comparer par rapport à ce que j’ai déjà listé.

Public : Par rapport aux erreurs 404 et 500, on peut modifier quand on met en place du code HTML ou PHP ou est-ce que c’est certain qu'on va avoir accès ?

Christophe Villeneuve: Concernant les deux écrans, l’erreur 400, l’erreur 500, pour ne pas laisser visible auprès de l’internaute, il y a deux méthodes : soit vous utilisez un CMS et le CMS propose déjà la fonctionnalité en disant : « S’il y a une erreur 404 ou une 500, affiche telle page », par exemple la page index du site internet. Si le CMS ne le propose pas, vous pouvez le modifier ou ajouter une règle de gestion dans le fichier htaccess, c’est-à-dire du côté de votre environnement ou du côté de votre serveur, en lui disant : « S’il y a une page 404 ou 500, renvoyer automatiquement la personne vers une autre page ». Comme ceci la personne malveillante ne verra pas ces messages d’erreur.

Public : Inaudible.

Christophe Villeneuve: htaccess, .htaccess, c’est un fichier de base lorsqu’on fait de la sécurité et de la redirection d’URL donc, c’est fourni oui, ça existe depuis que l’Internet existe. Eh bien merci pour cette écoute.

Applaudissements

• 1. CVE security
• 2. MDN - Mozilla Developer Network
• 3. OWASP - Open Web Application Security Project