AFUP AFUP Day 2020 Baromètre Planète PHP

La parole est aux speakers : Paul Molin

Jusqu’au Forum PHP 2019, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !

La conférence

Se prémunir contre l’imprévisible : une analyse des failles les plus courantes en PHP

Même avec des frameworks robustes et éprouvés, il est encore possible d’introduire des vulnérabilités dans les applications PHP.En prenant l’exemple de Symfony, et en se basant sur des cas concrets et inspirés d’histoires vraies, nous verrons qu’il est facile y compris pour des développeurs chevronnés de faire des petites erreurs aux conséquences potentiellement désastreuses.

À la tête d’une équipe chargée d’aider nos 80+ développeurs à construire des applications sans failles, j’ai pu répertorier les meilleures (et les pires) pratiques pour faire du code sécurisé.

Des contrôles d’accès bancals aux Cross Site Scripting involontaires, en passant par les injections DQL, nous verrons les principales vulnérabilités des applications Web peuvent s’introduire subrepticement dans une application PHP et, surtout, comment s’en prémunir.

À la fin de ce talk, vous aurez les idées claires sur la surface d’attaque de votre code applicatif, et sur les manières les plus simples de se protéger efficacement contre les vulnérabilités les plus courantes. Vous aurez toutes les clefs en main pour apporter une réelle culture de sécurité aux développeurs de votre équipe.

Grace Hopper
24/10/2019
15:15-15:55

Quels sont tes premiers réflexes pour sécuriser une application PHP ?

Les premiers gestes ont lieu avant même de commencer à coder. Quand les devs conçoivent l’application, ils peuvent déjà se poser des questions comme : Quels problèmes peuvent survenir avec cette fonctionnalité ? Quel est le pire qui puisse arriver pour le métier ? Quelles données sont confidentielles ? Si j’étais un attaquant, qu’est-ce que j’aimerais réussir à faire ? En se posant ces questions, on met déjà le doigt sur des failles potentielles.

L’avantage de ces questions, c’est qu’elles ne sont pas techniques. C’est donc possible (et même essentiel) d’impliquer le métier dès le début sur ces problématiques. Cela permet d’aligner toute l’équipe sur les risques pour le produit. Et, mieux encore, l’idée que c’est important commence à germer dans l’esprit des responsables métiers, qui auront moins tendance à déprioriser des fonctionnalités liées à la sécurité ou des corrections de failles.

Il faut ensuite se fixer, en équipe, des standards de qualité, afin que tout le monde soit aligné. Comment gérer le contrôle d’accès ? Quelles restrictions s’imposer sur la construction de requêtes SQL sur mesure ? Comment gérer les erreurs ?

Pour ne rien oublier, l’équipe technique doit collaborer avec l’équipe sécurité. Mais cela ne doit pas empêcher les développeurs de faire de la veille et de chercher à savoir quelles failles ils peuvent introduire alors même qu’ils sont en train de taper sur leur clavier. C’est leur responsabilité en tant que professionnel·le·s !

Quelles sont les bonnes pratiques pour collaborer entre développeur·euses et ops afin d’assurer la sécurité de ses applications ?

La première étape est de faire en sorte que les devs et les ops se sentent dans la même équipe : avoir un objectif en commun et créer de la confiance dès le début. Par exemple, les devs doivent impliquer les ops lors de la conception de fonctionnalités critiques. Côté ops, il faut aider les devs à trouver des solutions plutôt que de se contenter de bloquer des mises en production en cas de problème.

À Theodo, nous avons développé une offre d’audit de sécurité au sein de laquelle un expert travaille en peer programming avec un développeur. Ce dernier bénéficie des compétences de l’expert tout en lui partageant sa connaissance de la base de code. C’est la meilleure manière de collaborer efficacement !

Ensuite, il y a un véritable effort à fournir de la part des experts sécurité pour se rapprocher des devs. Par exemple, en expliquant pourquoi faire spécialement attention en ajoutant un éditeur de texte riche ou bien quels sont les risques associés à utiliser des wildcards pour les CORS. Ça aura plus de portée qu’une simple checklist. Je trouve beaucoup plus convaincant de raconter comment les données de plus de 145 millions de personnes ont pu être récupérées en modifiant la valeur d’un header HTTP que d’imposer la validation des entrées utilisateur sans expliquer le risque encouru. L’équipe sécurité de Theodo envoie d’ailleurs une Newsletter bimensuelle qui reprend ces idées et qui fonctionne très bien ! Et nous avons même commencé à écrire un livre sur le sujet.

C’est l’une des raisons pour lesquelles j’ai envie de parler au Forum PHP 2019, et de parler de sécurité à d’autres développeurs. Vous allez voir que ce sujet est passionnant, et souvent franchement grisant !

Tu es membre de l’OWASP, un organisme qui fait un gros travail sur les bonnes pratiques, cependant cela peine à être connu, quel est ton point de vue ?

L’OWASP fournit en effet beaucoup de ressources à destination des développeurs et des responsables de la sécurité d’applications Web. Des bonnes pratiques, mais également des applications volontairement vulnérables (afin de s’entraîner à hacker soi-même), ou encore des outils tels que l’excellent ZAP, un proxy pour aider les pentesters à auditer une application Web. Je recommande par exemple le guide ASVS (Application Security Verification Standard), très détaillé, ou encore Juice Shop, une application pleine de failles à exploiter.

Bien que l’OWASP soit très connu dans la communauté des experts sécurité, il y a encore du travail à faire pour se rapprocher des devs. Cela dit, la prise de conscience de la nécessité de rapprocher développeurs et experts sécurité est récente. L’OWASP doit encore améliorer ses ressources et les rendre utilisables plus facilement par les développeurs. Nous devons être encore plus “développeur-centriques”

L’autre difficulté, c’est qu’on travaille avec des risques qui peuvent très bien ne jamais se réaliser. Contrairement à des bugs, les failles ne seront pas constatées par la plupart des utilisateurs (avant la brèche). Aussi a-t-on tendance à minimiser l’importance du sujet. C’est pour cette raison qu’il est essentiel de communiquer sur les brèches et attaques ayant déjà eu lieu. Il faut raconter des histoires, pour partager les apprentissages avec les développeurs, et que ceux-ci n’oublient pas le risque qu’ils font courir aux utilisateurs. Peut-être un prochain projet pour l’OWASP !

Le speaker

Paul MOLIN
Paul MOLIN
Paul est architecte développeur, membre de l'OWASP et évangéliste sécurité à Theodo. Après avoir suivi une formation en sécurité des systèmes d'information à Télécom ParisTech, il rejoint Theodo en 2013 et se passionne pour le développement Web. Très vite, il se spécialise sur les problématiques de sécurité en aidant les équipes de Theodo à réussir leurs audits post-mise en production. Il est conférencier au Web2Day en 2017, et explique aux développeurs pourquoi ils doivent et comment ils peuvent devenir des hackers. Convaincu que ce sont les développeurs qui parviendront à changer le monde de la sécurité, il anime des formations et développe des outils pour les aider à coder sans faille du premier coup.

Autres interviews

En poursuivant votre navigation sur ce site, vous acceptez l’utilisation des cookies pour améliorer votre navigation. plus d'infos

1. Qu’est-ce qu’un cookie?

Un Cookie est un petit fichier texte enregistré sur votre terminal (ordinateur, tablette, smartphone, etc.), à l’occasion de la consultation d’un service en ligne grâce à votre logiciel de navigation. Il permet à son émetteur d’identifier le terminal dans lequel il est enregistré, pendant la durée de validité ou d’enregistrement du Cookie. Lors de la consultation de notre site Internet, des informations relatives à la navigation de votre terminal sont susceptibles d'être enregistrées dans ces fichiers dits "Cookies". Ces derniers sont installés sur votre terminal, sous réserve des choix que vous auriez exprimés concernant les Cookies et que vous pouvez modifier à tout moment.

2. A quoi servent les cookies émis sur notre site ?

Seul l’émetteur d’un cookie est susceptible de lire ou de modifier les informations qui y sont contenues.
Les cookies utilisés sur notre site permettent :

3. Vos choix concernant les cookies

Vous disposez de différents moyens pour gérer les cookies. Tout paramétrage que vous pouvez entreprendre sera susceptible de modifier votre navigation sur notre site et sur Internet en général et vos conditions d'accès à certains services de notre site nécessitant l'utilisation de cookies. Vous pouvez à tout moment exprimer et modifier vos souhaits en matière de cookies, par les moyens décrits ci-dessous. L'accord sur les cookies L'enregistrement d'un cookie dans un terminal est essentiellement subordonné à la volonté de l'utilisateur du terminal, que celui-ci peut exprimer et modifier à tout moment et gratuitement à travers les choix qui lui sont offerts par son logiciel de navigation. Si vous avez accepté dans votre logiciel de navigation l'enregistrement de cookies dans votre terminal, les cookies intégrés dans les pages et contenus que vous avez consultés pourront être stockés temporairement dans un espace dédié de votre terminal. Ils y seront lisibles uniquement par leur émetteur.

Le refus des cookies Si vous refusez l'enregistrement de cookies dans votre terminal, ou si vous supprimez ceux qui y sont enregistrés, vous ne pourrez plus bénéficier d'un certain nombre de fonctionnalités qui sont néanmoins nécessaires pour naviguer dans certains espaces de notre site. Tel serait le cas si vous tentiez d'accéder à votre compte ou à votre abonnement qui nécessite de vous identifier. Tel serait également le cas lorsque nous, ou nos prestataires, ne pourrions pas reconnaître, à des fins de compatibilité technique, le type de navigateur utilisé par votre terminal, ses paramètres de langue et d'affichage ou le pays depuis lequel votre terminal semble connecté à Internet. Le cas échéant, nous déclinons toute responsabilité pour les conséquences liées au fonctionnement dégradé de nos services résultant de l'impossibilité pour nous d'enregistrer ou de consulter les cookies nécessaires à leur fonctionnement et que vous auriez refusés ou supprimés. Les choix offerts par votre logiciel de navigation Vous pouvez configurer votre logiciel de navigation de manière à ce que des cookies soient enregistrés dans votre terminal ou, au contraire, qu'ils soient rejetés, soit systématiquement, soit selon leur émetteur. Vous pouvez également configurer votre logiciel de navigation de manière à ce que l'acceptation ou le refus des cookies vous soient proposés ponctuellement, avant qu'un cookie soit susceptible d'être enregistré dans votre terminal. Pour la gestion des cookies et de vos choix, la configuration de chaque navigateur est différente. Elle est décrite dans le menu d'aide de votre navigateur, qui vous permettra de savoir de quelle manière modifier vos souhaits en matière de cookies. Selon votre navigateur, consultez le lien ci-dessous pour configurer votre navigateur et refuser les cookies :