Forum PHP 2019
[: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
Se prémunir contre l’imprévisible : une analyse des failles les plus courantes en PHPMê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 !