Sorry, you need to enable JavaScript to visit this website.

Image CAPTCHA
Saisir les caractères affichés dans l'image.

Les 3 minutes du professeur Audenard - épisode 1 : les injections SQL

Les 3 minutes du professeur Audenard - épisode 1 : les injections SQL
2012-06-062013-06-03sériesfr
Voici le premier épisode des 3 minutes du professeur Audenard : la "leçon" du jour porte sur les injections SQL. 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...
Publié le 6 Juin 2012 par Jean-François Audenard dans séries
les 3 minutes du professeur Audenard - épisode 1 : les injections SQL

Voici le premier épisode des 3 minutes du professeur Audenard : la "leçon" du jour porte sur les injections SQL.

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 Services ? Allez-y, j'ai mon carnet, je note les noms. :-)

Jean François

4 Commentaires

  • 25 Août 2015
    2015-08-25
    par
    ScrittE
    Vraiment? la dynamique et les sgbd sql seraient apparus avec le web2.0?? Qu'a t-on fait avant 2003 et Facebook?? Apparement personne ne s'en rappelle... bravo Marc tu te sauras finalement tout approprié. Heureusement toutefois qu'il ne s'agit pas là d'un cours d'histoire.
  • 11 Juin 2012
    2015-08-25
    par
    Pour ceux d'entre-vous se posant la question "à quoi sert un blog comme celui-ci ?", je vous invite à lire cet article de Yann Gourvennec : les blogs constituent-ils (toujours) une opportunité en B2B ?
  • 11 Juin 2012
    2015-08-25
    par
    Christophe
    C'est efficace.
  • 6 Juin 2012
    2015-08-25
    par
    Topdam
    Très bon montage, sympa, continuer !!!

Ajouter un commentaire

comments

  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Tags HTML autorisés : <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <br>

Plain text

  • Aucune balise HTML autorisée.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.

Email HTML

  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
Image CAPTCHA
Saisir les caractères affichés dans l'image.
Changer d'affichage