[:fr]La parole est aux speakers : Paul Molin[:]

[:fr]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

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 !

Une conférence présentée par

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

• [:fr]La parole est aux speakers : Romain Monceau[:]
• [:fr]La parole est aux speakers : Kévin Dunglas[:]
• [:fr]La parole est aux speakers : Nicolas Grekas[:]
• [:fr]La parole est aux speakers : Marie-Cécile Godwin et Thomas di Luccio[:]
• [:fr]La parole est aux speakers : Matthieu Napoli[:]
• [:fr]La parole est aux speakers : Olivier Allain[:]
• [:fr]La parole est aux speakers : Benoit Viguier[:]
• [:fr]La parole est aux speakers : François Zaninotto[:]
• [:fr]La parole est aux speakers : Benoit Jacquemont[:]
• [:fr]La parole est aux speakers : Damien Seguy[:]
• [:fr]La parole est aux speakers : Pascal Martin[:]
• [:fr]La parole est aux speakers : Nuno Maduro[:]
• [:fr]La parole est aux speakers : Roland Lehoucq[:]
• [:fr]La parole est aux speakers : Grégoire Pineau[:]
• [:fr]La parole est aux speakers : Adrien Lucas[:]
• [:fr]La parole est aux speakers : Nicolas De Boose[:]
• [:fr]La parole est aux speakers : Paula Čučuk[:]
• [:fr]La parole est aux speakers : Mickaël Andrieu [:]
• [:fr]La parole est aux speakers : Sylvain Combraque[:]
• [:fr]La parole est aux speakers : Valentine Boineau[:]
• [:fr]La parole est aux speakers : Alex Rock[:]
• [:fr]La parole est aux speakers : Julien Pauli[:]
• [:fr]La parole est aux speakers : Cindy Liwenge[:]
• [:fr]La parole est aux speakers : Frédéric Bouchery[:]