Voici le premier épisode des 3 minutes du professeur Audenard : la "leçon" du jour porte sur les injections SQL.
Pour regarder cette vidéo, vous devez consentir aux Cookies de notre partenaire Youtube Ces cookies permettent de partager ou réagir directement sur les réseaux sociaux auxquels vous êtes connectés ou d'intégrer du contenu initialement posté sur ces réseaux sociaux. Ils permettent aussi aux réseaux sociaux d'utiliser vos visites sur nos sites et applications à des fins de personnalisation et de ciblage publicitaire.
regardez cette vidéo directement sur Youtube
Les injections SQL sont une catégorie de faille de sécurité que l'on retrouve dans un très grand nombre de sites web, que ceux-ci soient développés "sur mesure" ou qu'ils utilisent un système de type CMS (Joomla, ....).
si ça tape, ça peut faire très mal
Les failles injections SQL permettent à un attaquant d'accéder directement (ou quasiment) à la base de données localisée derrière un site web "dynamique".
Les conséquences d'une attaque réussie peuvent avoir pour conséquences un "pompage" de l'ensemble des données présentes dans la base de données, des modifications non-autorisées de ces dernières ou encore être utilisées pour infecter les machines des internautes se connectant au site web. Les injections SQL ne sont donc pas à prendre à la légère.
deux techniques de protection...
Le premier rempart de protection pour protéger son site contre des attaques en SQL s'appuie sur un principe simple. L'approche est de considérer que toutes données provenant de l'extérieur (c'est-à-dire le navigateur ou "poste client") comme étant potentiellement dangeureuses et donc qu'elles doivent être analysées et filtrées en amont. Seules les données considérées comme "saines" auront le droit de passer le premier rempart.
La seconde couche de sécurisation est située entre l'application web et le moteur de base de données. Elle arrive donc en renfort de la première. Il s'agit ici de "fixer dans le marbre" le comportement (ou la "logique") des requêtes SQL afin que leur principe de fonctionnement ne puisse pas être changé via des commandes ou "verbes" injectées.
... qui sont complémentaires et se renforcent
Ces deux techniques sont complémentaires et se renforcent mutuellement : en effet, si l'une d'entre-elles venait à être contournée (nouvelle technique d'attaque non prévue initialement, mise en oeuvre imparfaite) la seconde devrait permettre de stopper l'attaque. De façon assez classique, on retrouve ici le principe de "défense en profondeur".
Ces deux techniques nécessitent de modifier le code source de l'application : vos développeurs devront donc être impliqués. Les impliquer le plus tôt pour qu'ils intégrent ces mesures dès le début des développements.
deux techniques complémentaires...
Outre les deux techniques au niveau applicatif, il est possible d'intercaler des systèmes pour filtrer les données.
- Le premier type de système c'est le WAF (Web Application Firewall) qui va se positionner devant le serveur web afin d'analyser les requêtes et bloquer celles non conformes à ce qui est attendu. Un WAF peut être un équipement spécifique ou alors une fonction du serveur web comme mod_security sous Apache.
- Le second type de système se positionne entre le serveur web et la base de données. Il va surveiller les requêtes SQL et bloquer celles qui sont visiblement malicieuses. Pour plus d'infos, aller relire ce bulletin qui présentait GreenSQL, un firewall pour bases de données opensource.
... devant être maintenues et supervisées dans le temps
Tant le "Web Application Firewall" que le "database firewall" doivent être administrés de façon continue : actualisation de leur configuration sur les nouvelles techniques d'attaques, prise en compte de nouvelles fonctionnalités du site web ou de nouvelles requêtes SQL.
La complexité de ces systèmes réside notamment dans le fait qu'ils sont souvent gérés par des équipes différentes de celles en charge du développement ou de la maintenance du site web. Il y a donc un risque important que leur configuration soit en retard sur les dernières versions du site... et donc le protection sera eventuellement diminué pendant un certain temps.
pourquoi les 3 minutes ? c'est terminé les 5 minutes ?
Les 3 minutes du professeur Audenard doivent être vues comme un essai, une façon de capitaliser sur le succès des 5 mins. Comme vous avez pu le voir, la réalisation des 3 mins est beaucoup plus aboutie et le temps passé pour monter une telle "leçon" est clairement plus conséquent.
Dans l'approche, les deux séries devraient vivre en parallèle. Les 5 minutes vont clairement continuer alors que pour les 3 minutes ne continueront que si le rendez-vous est un succès : autrement dit, si les 3 minutes plaisent alors on fera sûrement d'autres épisodes ! Si c'est un bide, alors "exit les 3 minutes".
Nous sommes donc clairement dans le "try & buy" du coté blog sécurité. Qui ose dire que nous ne sommes pas pragmatiques chez Orange Business ? Allez-y, j'ai mon carnet, je note les noms. :-)
Jean François
Au sein de la direction sécurité du Groupe Orange, je suis en charge de la veille sécurité et de la sensibilisation à la sécurité. Franchise, optimisme et bonne-humeur sont mes moteurs quotidiens