Et pourtant... Si tu savais le nombre de candidats en entretiens (même sans être junior) qui ne connaissent pas les requêtes parametrées... Sur ce forum aussi, 8fois sur 10 c'est une concaténationEnvoyé par nflowerpower
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Et pourtant... Si tu savais le nombre de candidats en entretiens (même sans être junior) qui ne connaissent pas les requêtes parametrées... Sur ce forum aussi, 8fois sur 10 c'est une concaténation
Retrouvez moi sur :
Mon Espace Developpez.com-------------------------------
Je trouve ton estimation plutôt optimisteSur ce forum aussi, 8fois sur 10 c'est une concaténation
Pas de questions techniques par MP ! Le forum est là pour ça...
Ya des choses qu'on peut pas faire avec une requête paramétrée.Et pourtant... Si tu savais le nombre de candidats en entretiens (même sans être junior) qui ne connaissent pas les requêtes parametrées... Sur ce forum aussi, 8fois sur 10 c'est une concaténation
Suffit que la concaténation soit bien faite
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
Exact, un "DecryptByPassphrase" par exemple passera.
Les protections par defauts bloquent les attaques XSS mais pas les injections sql.
Bonjour,
Un
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
Code : Sélectionner tout - Visualiser dans une fenêtre à part String.Format("SELECT * FROM Dogs1 WHERE Name LIKE {0}", nameFromQueryString)
Non, et encore moins que la première forme.
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).
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.
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Au contraire, la première forme est parfaitement sûre, alors que la 2e introduit un risque d'injection...
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.
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.
Le SQL c'est pas du code ?
Ca vient de sortir ?
Tu veux dire que ce n'est pas la tienne.Ce n'est pas sa spécialité.
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.On ne peut pas tout connaitre sur tout. Chacun son secteur.
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 .....).
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 ?
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.
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.
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.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).
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 .....).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
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.
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
Retrouvez moi sur :
Et si je te réponds que SYBASE n'accepte pas les paramètres sur des champs TEXT, tu me prends pas?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.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
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.
Un millon c tt
Répondre avec citation
Partager