Navigation

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

  1. #21
    Membre confirmé Avatar de Grabeuh
    Homme Profil pro
    Développeur Web
    Inscrit en
    février 2009
    Messages
    114
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2009
    Messages : 114
    Points : 639
    Points
    639
    Par défaut
    Citation Envoyé par ixpe Voir le message
    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.

  2. #22
    Expert confirmé
    Avatar de Lyche
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    janvier 2007
    Messages
    2 523
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : janvier 2007
    Messages : 2 523
    Points : 5 785
    Points
    5 785
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par Grabeuh Voir le message
    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é.
    Rejoignez la communauté du chat et partagez vos connaissances ou vos questions avec nous

    Mon Tutoriel pour apprendre les Agregations
    Consultez mon Blog SQL destiné aux débutants

    Pensez à FAQ SQL Server Ainsi qu'aux Cours et Tuto SQL Server

  3. #23
    Nouveau membre du Club
    Profil pro
    Inscrit en
    octobre 2011
    Messages
    71
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : octobre 2011
    Messages : 71
    Points : 39
    Points
    39
    Par défaut
    Citation Envoyé par Idelways Voir le message
    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 ?

  4. #24
    Membre actif
    Profil pro
    azeazeae
    Inscrit en
    septembre 2002
    Messages
    114
    Détails du profil
    Informations personnelles :
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : azeazeae

    Informations forums :
    Inscription : septembre 2002
    Messages : 114
    Points : 287
    Points
    287
    Par défaut
    Citation Envoyé par matios Voir le message
    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


    Citation Envoyé par Grabeuh Voir le message
    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.

  5. #25
    Membre régulier
    Profil pro
    Inscrit en
    septembre 2008
    Messages
    65
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2008
    Messages : 65
    Points : 97
    Points
    97
    Par défaut
    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 ?

  6. #26
    Inactif  
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    janvier 2007
    Messages
    6 604
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France

    Informations professionnelles :
    Activité : Chef de projet NTIC

    Informations forums :
    Inscription : janvier 2007
    Messages : 6 604
    Points : 13 210
    Points
    13 210
    Par défaut
    Citation Envoyé par Marauder Voir le message
    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.

    Je ne réponds pas aux questions techniques par MP ! Le forum est là pour ça...


    Une réponse vous a aidé ? utiliser le bouton

    "L’ennui dans ce monde, c’est que les idiots sont sûrs d’eux et les gens sensés pleins de doutes". B. Russel

  7. #27
    Membre actif
    Profil pro
    azeazeae
    Inscrit en
    septembre 2002
    Messages
    114
    Détails du profil
    Informations personnelles :
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : azeazeae

    Informations forums :
    Inscription : septembre 2002
    Messages : 114
    Points : 287
    Points
    287
    Par défaut
    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).

  8. #28
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2005
    Messages
    27 051
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2005
    Messages : 27 051
    Points : 40 213
    Points
    40 213
    Par défaut
    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.

  9. #29
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 872
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2004
    Messages : 19 872
    Points : 39 718
    Points
    39 718
    Par défaut
    Citation Envoyé par Marauder Voir le message
    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...

    Citation Envoyé par Médinoc Voir le message
    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.

  10. #30
    Membre régulier
    Inscrit en
    avril 2004
    Messages
    213
    Détails du profil
    Informations forums :
    Inscription : avril 2004
    Messages : 213
    Points : 111
    Points
    111
    Par défaut
    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 .

  11. #31
    Inactif  
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    janvier 2007
    Messages
    6 604
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France

    Informations professionnelles :
    Activité : Chef de projet NTIC

    Informations forums :
    Inscription : janvier 2007
    Messages : 6 604
    Points : 13 210
    Points
    13 210
    Par défaut
    Citation Envoyé par antrax2013 Voir le message
    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 .....).

    Je ne réponds pas aux questions techniques par MP ! Le forum est là pour ça...


    Une réponse vous a aidé ? utiliser le bouton

    "L’ennui dans ce monde, c’est que les idiots sont sûrs d’eux et les gens sensés pleins de doutes". B. Russel

  12. #32
    Membre régulier
    Inscrit en
    avril 2004
    Messages
    213
    Détails du profil
    Informations forums :
    Inscription : avril 2004
    Messages : 213
    Points : 111
    Points
    111
    Par défaut
    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 ?

  13. #33
    Membre éprouvé Avatar de Charvalos
    Homme Profil pro
    Développeur Web
    Inscrit en
    juin 2010
    Messages
    344
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : juin 2010
    Messages : 344
    Points : 1 201
    Points
    1 201
    Par défaut
    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.
    "Non, je ne dois rien à personne
    Et je ne méprise personne".


    Je ne réponds pas aux message techniques par MP !

  14. #34
    Inactif  
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    janvier 2007
    Messages
    6 604
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France

    Informations professionnelles :
    Activité : Chef de projet NTIC

    Informations forums :
    Inscription : janvier 2007
    Messages : 6 604
    Points : 13 210
    Points
    13 210
    Par défaut
    Citation Envoyé par antrax2013 Voir le message
    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 .....).

    Je ne réponds pas aux questions techniques par MP ! Le forum est là pour ça...


    Une réponse vous a aidé ? utiliser le bouton

    "L’ennui dans ce monde, c’est que les idiots sont sûrs d’eux et les gens sensés pleins de doutes". B. Russel

  15. #35
    Nouveau Candidat au Club
    Homme Profil pro
    Inscrit en
    octobre 2011
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : octobre 2011
    Messages : 1
    Points : 1
    Points
    1
    Par défaut
    Citation Envoyé par Bluedeep Voir le message
    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.

  16. #36
    Rédacteur
    Avatar de Nathanael Marchand
    Homme Profil pro
    Expert .Net So@t
    Inscrit en
    octobre 2008
    Messages
    3 615
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert .Net So@t
    Secteur : Conseil

    Informations forums :
    Inscription : octobre 2008
    Messages : 3 615
    Points : 8 080
    Points
    8 080
    Par défaut
    Citation Envoyé par antrax2013 Voir le message
    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

  17. #37
    Rédacteur
    Avatar de lutecefalco
    Profil pro
    zadzdzddzdzd
    Inscrit en
    juillet 2005
    Messages
    5 052
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : zadzdzddzdzd

    Informations forums :
    Inscription : juillet 2005
    Messages : 5 052
    Points : 8 731
    Points
    8 731
    Par défaut
    Citation Envoyé par Nathanael Marchand Voir le message
    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?

  18. #38
    Inactif  
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    janvier 2007
    Messages
    6 604
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France

    Informations professionnelles :
    Activité : Chef de projet NTIC

    Informations forums :
    Inscription : janvier 2007
    Messages : 6 604
    Points : 13 210
    Points
    13 210
    Par défaut
    Citation Envoyé par bahbou Voir le message
    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).

    Je ne réponds pas aux questions techniques par MP ! Le forum est là pour ça...


    Une réponse vous a aidé ? utiliser le bouton

    "L’ennui dans ce monde, c’est que les idiots sont sûrs d’eux et les gens sensés pleins de doutes". B. Russel

  19. #39
    Membre régulier
    Inscrit en
    avril 2004
    Messages
    213
    Détails du profil
    Informations forums :
    Inscription : avril 2004
    Messages : 213
    Points : 111
    Points
    111
    Par défaut
    Citation Envoyé par Nathanael Marchand Voir le message
    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.

  20. #40
    Rédacteur
    Avatar de lutecefalco
    Profil pro
    zadzdzddzdzd
    Inscrit en
    juillet 2005
    Messages
    5 052
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : zadzdzddzdzd

    Informations forums :
    Inscription : juillet 2005
    Messages : 5 052
    Points : 8 731
    Points
    8 731
    Par défaut
    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

Discussions similaires

  1. Réponses: 33
    Dernier message: 27/10/2011, 17h03
  2. Réponses: 16
    Dernier message: 31/03/2011, 14h36
  3. Réponses: 3
    Dernier message: 11/11/2009, 17h25
  4. injection SQL avec magic_quotes_gpc sur on
    Par elcoyotos dans le forum Langage
    Réponses: 2
    Dernier message: 12/09/2009, 19h33
  5. remplir une Bdd sql serveur a travers un formulaire Asp.net
    Par mead_Developper dans le forum ASP.NET
    Réponses: 9
    Dernier message: 28/05/2009, 12h36

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo