Discussion :

[Grabeuh]

Par contre cela n empeche pas l'injection SQL : un
INSERT INTO USERS (username) VALUES ('blabla') peut passer
par contre un INSERT INTO USERS (username) VALUES ('<script> ne passera pas...

Les SGBD peuvent convertir une suite de caractères en hexadecimal en texte au moment de l'insertion grace à certaines fonctions embarquées. Je pense que ce type d'astuces doit passer à l'aise à travers la protection des formulaires.

C'est probablement parce que les développeurs pensent être protégés grâce à ce mécanisme automatique qu'ils ne se méfient pas forcément d'autres menaces, comme c'était le cas avec les magic quotes en PHP.

[Lyche]

Les SGBD peuvent convertir une suite de caractères en hexadecimal en texte au moment de l'insertion grace à certaines fonctions embarquées. Je pense que ce type d'astuces doit passer à l'aise à travers la protection des formulaires.

C'est probablement parce que les développeurs pensent être protégés grâce à ce mécanisme automatique qu'ils ne se méfient pas forcément d'autres menaces, comme c'était le cas avec les magic quotes en PHP.

Les procédures stockées ont été mises en places en partie pour éviter les injections SQL. De nos jours en BDD et même en dev il y a suffisament de moyens pour limiter ce genre de problèmes.. Si il y en a, c'est au dev qu'il faut s'en prendre de ne pas avoir respecter les règles de sécurité minimales. En revanche, pour des pages ASP.. c'est quand même assez vieux pour manquer de protocoles de sécurité.

[matios]

Une situation compliquée par le fait que seulement 6 Antivirus sur 43 sont en mesure de détecter la faille à l'heure de l'écriture de ces lignes.

Quels sont les six antivirus qui sont en mesure de détecter cette faille ?

[ixpe]

Quels sont les six antivirus qui sont en mesure de détecter cette faille ?

AntiVir 7.11.15.240 2011.10.12 TR/Dropper.Gen
ByteHero 1.0.0.1 2011.09.23 Trojan.Malware.Obscu.Gen.002
Fortinet 4.3.370.0 2011.10.12 W32/Binder.RZ!tr
Jiangmin 13.0.900 2011.10.12 Backdoor/Proxyier.a
McAfee 5.400.0.1158 2011.10.12 Suspect-BA!D8F9360A6B87
McAfee-GW-Edition 2010.1D 2011.10.12 Heuristic.LooksLike.Win32.Suspicious.J

Les SGBD peuvent convertir une suite de caractères en hexadecimal en texte au moment de l'insertion grace à certaines fonctions embarquées. Je pense que ce type d'astuces doit passer à l'aise à travers la protection des formulaires.

Exact, un "DecryptByPassphrase" par exemple passera.
Les protections par defauts bloquent les attaques XSS mais pas les injections sql.

[Marauder]

Bonjour,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SqlCommand command = new SqlCommand("SELECT * FROM Dogs1 WHERE Name LIKE @Name", connection)
 command.Parameters.Add(new SqlParameter("Name", nameFromQueryString)

Un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

String.Format("SELECT * FROM Dogs1 WHERE Name LIKE {0}", nameFromQueryString)

peut il suffir à se prémunir de ces attaques ?

[Bluedeep]

Un String.Format("SELECT * FROM Dogs1 WHERE Name LIKE {0}", nameFromQueryString) peut il suffir à se prémunir de ces attaques ?

Non, et encore moins que la première forme.

[ixpe]

L'utilisation de procedures stockées me parait le plus sécurisant.
C'est moins souple évidemment, c'est du boulot en plus, il faut faire quelques pirouettes de temps en temps mais je pense que coté securité (injection sql) on ne se pose plus trop de question.

De plus on peut gérer finement les droits sur les proc stock (qui execute quoi).

[Médinoc]

Le problème majeur pour les injections SQL, c'est que certains systèmes ne proposent pas de fonction SQLEscape. Notamment SQL server.

D'accord, les paramètres, c'est mieux, mais ce n'est pas une raison pour ne pas proposer la fonction. De plus, les paramètres ne servent à rien quand il est question de générer un script sous forme de fichier texte.

[tomlev]

Bonjour,

SqlCommand command = new SqlCommand("SELECT * FROM Dogs1 WHERE Name LIKE @Name", connection)
command.Parameters.Add(new SqlParameter("Name", nameFromQueryString)

Un String.Format("SELECT * FROM Dogs1 WHERE Name LIKE {0}", nameFromQueryString) peut il suffir à se prémunir de ces attaques ?

Au contraire, la première forme est parfaitement sûre, alors que la 2e introduit un risque d'injection...

Le problème majeur pour les injections SQL, c'est que certains systèmes ne proposent pas de fonction SQLEscape. Notamment SQL server.

D'accord, les paramètres, c'est mieux, mais ce n'est pas une raison pour ne pas proposer la fonction. De plus, les paramètres ne servent à rien quand il est question de générer un script sous forme de fichier texte.

Bah le problème avec une fonction du genre SQLEscape, c'est qu'il y a toujours un risque de mal l'utiliser... c'est comme avec les magic quotes de PHP, ça introduit souvent des bugs bizarre parce que ça a été utilisé de travers.

Les requêtes paramétrées sont un peu plus longues à écrire, mais c'est pas non plus le bout du monde, et ça protège totalement contre l'injection SQL.

[antrax2013]

Je ne suis pas d'accord avec Lyche. Le développeur doit respecter un minimum de normes au niveau de son codage. C'est un fait.

Mais le rôle des admins BD est de fournir des préconisations et aux responsables des développeurs de leurs faire appliquer. Le tout devant être pris en compte au niveau des charges de travail.

Le développeur, son métier c'est d'écrire du code pas du SQL. Ce n'est pas sa spécialité. On ne peut pas tout connaitre sur tout. Chacun son secteur.

Maintenant il est très facile et pratique de rejeter la faute sur le dernier maillon de la chaine.

Pour moi c'est une défaillance collectives.

Il ne faut pas non plus oublier que dans certaines des entreprises le développeur est aussi le responsable BD et le chef de projet. Il n'y a pas de miracle.

Si on se rapproche du secteur du bâtiment, on ne demande pas au maçon de poser les tuiles sur le toit .

[Bluedeep]

Le développeur, son métier c'est d'écrire du code pas du SQL.

Le SQL c'est pas du code ?
Ca vient de sortir ?

Ce n'est pas sa spécialité.

Tu veux dire que ce n'est pas la tienne.

On ne peut pas tout connaitre sur tout. Chacun son secteur.

Euh oui ... mais si je peux comprendre qu'un développeur ne connaisse ni le HTML ni les CSS, je ne prendrais en revanche jamais un gars qui ne connait pas le SQL.

Blague à part, écrire le code SQL d'une application nécessite de connaitre parfairtement l'aspect "métier" de celle ci; donc on ne peut pas imaginer une fraction de seconde comment le DBA, dont ce n'est pas le métier (je ne parle pas de coder en SQL, le DBA sait faire, mais de connaitre le métier de l'application) puisse s'occuper de cette tâche.

Ou alors tu considère la base de données comme rien d'autre qu'une sorte de "super ISAM" juste destinée à servir des données à la demande...... (et c'est, hélas, plus fréquent qu'on ne le pense .....).

[antrax2013]

Je comprends ce que tu dis, Bluedeep, et l'entend bien. Là où pour toi qu'un développeur "n'y connaissent rien" en CSS ou HTML c'est pas grave. Je te réponds que de mon point de vue c'est la même chose pour le SQL.

Faire des CSS et du HTML "efficasse", respectant les normes et compatible avec tout les navigateurs, c'est une affaire de "spécialistes". La base de données aussi. Après tout le monde peut en faire mais faut pas se plaindre de ce genre de mésaventure (injection SQL).

Aujourd’hui on demande beaucoup trop au développeur.
Si on prend le cas d'un projet web, on lui demande :
- d'écrire dans un langage par exemple PHP les règles métiers
- de faire des requettes SQL pour obtenir, stoker, modifier... ces données
- de faire du HTML et des CSS pour faire de belle interfaces
- de faire du javascript pour avoir du dynamisme

Et après on se plaint qu'il ne soit pas bon partout.

Pour moi le parallèle au développement c'est le BTP. Si tu fais construire une maison tu ne demanderas pas au peintre de te poser ton chauffage ni de te mettre tes tuiles sur ton toit. Alors pourquoi le fait-on avec le développeur ?

[Charvalos]

Dans un sens, t'as pas tort.

N'empêche, je me vois mal faire un site web avec PHP et demander à un, comme tu dit, "spécialiste" de base de données de me faire de simple requêtes SQL pour vérifier que la personne est bien inscrite ou encore pour ajouter quelque chose.

Surtout que maintenant, avec PDO, t'as même plus besoin de casser la tête pour savoir comment sécuriser tes requêtes SQL. Un simple prepare() suffit.

[Bluedeep]

Faire des CSS et du HTML "efficasse", respectant les normes et compatible avec tout les navigateurs, c'est une affaire de "spécialistes".

Oui, mais je voulais dire qu'un travail approximatif de ce coté là ne sapera pas les fondements du projet; cela peut être réglé a posteriori.(au prix d'une augmentation de la charge, il est vrai).

Il n'en va pas du tout de même d'un "baclage" ou niveau du modèle de données ou des règles en bases.

C'est de ce point de vue que j'ai infiniment moins de tolérance à une méconnaissance des mécaniques "cosmétiques" qu'à une méconnaissance de ce qui fait la base de 99% des projets IT : tout ce qui touche à la manipulation des données.

La base de données aussi. Après tout le monde peut en faire mais faut pas se plaindre de ce genre de mésaventure (injection SQL).

Pour moi la protection contre l'injection SQL se fait plutôt au niveau de la couche d'accès aux données, voire au dessus, mais certainement pas dans la base. D'autant que la DAL n'a pas à "taper" dans les tables en direct : en ne tapant que sur les PS et les Views, la sensibilité à l'injection SQL devient quand même des plus réduites.

Si on prend le cas d'un projet web, on lui demande :
- d'écrire dans un langage par exemple PHP les règles métiers
- de faire des requettes SQL pour obtenir, stoker, modifier... ces données

Là je ne suis pas d'accord : Une bonne partie des règles métiers se code au niveau de la base. Une base, comme je le disais dans mon poste supra, c'est pas un "super ISAM". (et, encore une fois, on la voit trop souvent utilisée ainsi, sans même parler des process DB <-> DB qui transitent par le serveur applicatif .....).

[bahbou]

Blague à part, écrire le code SQL d'une application nécessite de connaitre parfairtement l'aspect "métier" de celle ci; donc on ne peut pas imaginer une fraction de seconde comment le DBA, dont ce n'est pas le métier (je ne parle pas de coder en SQL, le DBA sait faire, mais de connaitre le métier de l'application) puisse s'occuper de cette tâche.

Je ne suis pas trop d'accord avec toi. Bien sur que les dba doivent connaître les techniques pour éviter les injections de code via les base de données, même si coder n'est pas leur métier. (Personnellement quasiment tous les DBA que j'ai rencontré étaient issus du monde du dev donc de ce coté pas de pb)

Au de la de ça je rejoint Antrax pour dire que pour moi la sécurité d'une application est l'affaire de tous:

• le chef de projet doit bien insister dessus, le prévoir dans ses phases de test et le vérifier
• le développeur doit coder en prenant cette problématique en compte, et évidemment tester.
• le dba doit communiquer et insister dessus, voir proposer des moyens de prévention s'il voit que le programmeur ne maîtrise pas bien le sujet.

[Nathanael Marchand]

Faire des CSS et du HTML "efficasse", respectant les normes et compatible avec tout les navigateurs, c'est une affaire de "spécialistes". La base de données aussi. Après tout le monde peut en faire mais faut pas se plaindre de ce genre de mésaventure (injection SQL).

Un développeur qui, en entretien, n'utilise pas les requêtes parametrées et me fait une concaténation, a moins qu'il soit vraiment une bête ailleurs, pour moi c'est non. Même si c'est un junior: c'est la base

[lutecefalco]

Un développeur qui, en entretien, n'utilise pas les requêtes parametrées et me fait une concaténation, a moins qu'il soit vraiment une bête ailleurs, pour moi c'est non. Même si c'est un junior: c'est la base

Et si je te réponds que SYBASE n'accepte pas les paramètres sur des champs TEXT, tu me prends pas?

[Bluedeep]

Je ne suis pas trop d'accord avec toi. Bien sur que les dba doivent connaître les techniques pour éviter les injections de code via les base de données, même si coder n'est pas leur métier. (Personnellement quasiment tous les DBA que j'ai rencontré étaient issus du monde du dev donc de ce coté pas de pb)

Je ne vois pas en quoi tu n'es pas d'accord avec moi, car ce que tu réponds (avec lequel je suis d'accord, d'ailleurs) ne contredit en aucune manière ce que j'ai écrit.

Ou alors, je me suis mal exprimé.

Je reprends donc : ce n'est pas le boulot du DBA de connaître le métier, c'est à dire la finance, la comptabilité, la chimie, les statistiques, l'imagerie médicale, etc ... enfin le domaine où ton application intervient quel qu'il soit.; donc ton DBA ne peut pas coder ta partie DB à ta place car il ne sait pas ce qu'il faut coder (même si il sait coder, et, en SQL, il sait obligatoirement .. sinon c'est pas un DBA, mais un bricoleur ).


Visiblement tu as mal interprété le sens du mot "métier" : je ne parlais pas du "métier de développeur" mais du "metier" de l'application en genèse. (au sens MOA si tu préféres).

[antrax2013]

Un développeur qui, en entretien, n'utilise pas les requêtes parametrées et me fait une concaténation, a moins qu'il soit vraiment une bête ailleurs, pour moi c'est non. Même si c'est un junior: c'est la base

Bien que je sois d'accord, partiellement, avec toi. On voit bien que c'est loin d'être le cas.

Pour éviter le problème il faut y être sensibilisé et être dans une "structure" qui s'en préoccupe.

Et quelque part ça tu ne peux pas l’exiger d'un candidat junior. De plus tu ne peux te battre seul.

En plus à mon sens ça ne doit pas être rédhibitoire à l'embauche d'une personne. Les bonnes pratiques ça acquièrent bien souvent au contact des plus chevronnés ou en subissant les effets d'une mauvaise pratique. C'est aussi le rôle de l'entreprise de "former".

Après si tu es expert c'est autre chose. Mais bon on dérive du sujet.

[lutecefalco]

Le A, c'est Adminstrator non?
Donc le rôle du DBA, c'est la maintenance, les back up, être capable d'expliquer le crash d'une DB etc

Pour moi, il est évident que c'est le rôle du développeur de gérer les injections SQL, de placer les index au bon endroit, de savoir lire un query process plan etc