Discussion :

[CLion]

Bonjour tout le monde.
avec asp.net et sqlserver je peux facilement enregistrer mes données dans une base de donnée, bizarrement, quand je mis dans une variable ' ou " un problème est envoyer et les données ne peuvent être enregistrer, voici un exemple:

avec ce genre de données j'ai aucun probleme:
1- sans erreur:
ceci est un vrai teste

2- avec erreur:
l'autre teste était un jolie teste

voilà, le mot: l'autre provoque un problème que dois-je faire ?

merci

[Immobilis]

Salut,

Est-ce que tu as un message d'erreur? Utilises-tu des procédures stockées?

A+

[Graffito]

Pour éviter ce type de problème, on utilise les requêtes paramétrées.
Voir : http://webman.developpez.com/article.../sqlparameter/

[rohstev]

Hello,

cela vient du fait que l'apostrophe de ton mot l'autre va faire office de délimiteur dans ta requête SQL et ta requête va être erronnée.

Pour contrer ce problème :
1. Utiliser des requêtes paramétrées --> meilleure solution
2. Ajouter la méthode Replace("'","''") à ton champ qui sera ensuite passé dans ta requête :
_monChampAvecApostrophe = txtBox.Text.Replace("'","''"). Le double apostrophe sera interprété correctement par le serveur SQL et lors du select, il n'apparaîtra pas à double.
Méthode plus rapide mais moins "pro".

Steve

[Bluedeep]

Méthode plus rapide mais moins "pro".

On ne voit pas bien en quoi c'est plus rapide et surtout c'est extrémement dégueulasse et illisible.

[frecil]

Bonjour tout le monde.
avec asp.net et sqlserver je peux facilement enregistrer mes données dans une base de donnée, bizarrement, quand je mis dans une variable ' ou " un problème est envoyer

merci

Attention si tu n'échappe pas correctement les caractères spéciaux, un hacker peut s'en servir pour attaquer la BD de ton site internet.

Cette attaque se nomme une Injection_SQL

[nid4mail]

et si tu écrivais l/'autre au lieu de l'autre ??

[StringBuilder]

Ca ne marcherait pas mieux, parceque SQL Server respecte la norme SQL, et la norme SQL, c'est pas la norme ANSI, donc pour échapper ', ce n'est pas \' mais ''.

En SQL, \' ça veut dire \ suivit d'un '.

Y'a pas à tortiller dans tous les sens, la seule solution portable, propre, performante, sécurisée et lisible, c'est l'utilisation de requête paramétrée.

[Immobilis]

Il y a aussi entity data model. Sinon, plus classique: les procédures stockées.

[nid4mail]

je suis finalement tombé sur le meme probleme que toi et voici comment je l'ai résolu :
Sans mon dossier App_Code, j'ai créé un fichier utils.cs qui contient le code suivant :

Code :

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

1
2
3
4
public static string NettoieString(string strValeur)
    {
        return strValeur.Replace("'", "''").ToUpper();
    }

Du coup quand j'ai besoin de passer en parametre un champs qui contient un apostrophe comme par exemple le nom de la commune et son code saisis par un humain, je fais :

Code :

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

Commune.AjouterCommune(Utils.NettoieString(tbCodeCommune.Text), Utils.NettoieString(tbCommune.Text))

et ma fonction recoit AjouterCommune(003,L''autre) et ca rentre dans la base de donnée "003 - L'Autre" et ca marche nickel...

(en esperant avoir pu t'aider ou d'autres qui auront un jour le meme probleme)

[StringBuilder]

C'est exactement ce qu'il ne fait pas faire.

Comme dit maintes fois précédemment, il faut passer par une requête paramétrée :

http://webman.developpez.com/article...ameter/csharp/

C'est pourtant pas compliqué à utiliser...

[StringBuilder]

Pour information, MySQL par exemple, supporte les séquences d'échappement ANSI en plus de celles prévues par SQL.

Ainsi :
Imaginons que l'utilisateur "toto" a pour mot de passe "O'Brian".

Sous SQL Server :

Code :

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

select * from matable where login = 'toto' and password = 'O\'Brian';

=> Plante
Mais pas sous MySQL par exemple.

Ainsi, en échappant les ' avec '', on va produire :

Code :

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

select * from matable where login = 'toto' and password = 'O\''Brian';

=> Sous SQL Server, ça va fonctionner parfaitement... (et accessoirement, ne rien retourner, ce qui est logique)

Mais sous MySQL, ça va planter.

Bref, c'est pas portable !

Et pire :

Imaginez que l'utilisateur saisi dans la case "mot de passe" :

Code :

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

\' or login = substr(\'administrateur\', 2, 14)

Avec SQL Server, en échappant le ' avec un '', pas de souci.

Demain, vous portez l'application sous MySQL... Et n'importe qui peut se connecter en mode administrateur sans avoir besoin de connaître le mot de passe.

En effet, la requête devient :

Code :

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

select * from matable where login = 'toto' and password = '\'' or login = substr(\''administrateur\'', 2, 14)';

Bref...

Requêtes paramétrées, point barre !

[nsanabi]

Requêtes paramétrées, point barre !

[nid4mail]

Faut etre moins betes que les utilisateurs et imposer des regles pour les mots de passes : Au moins 2 chiffres et entre 6 et 10 caracteres, caracteres speciaux (.,;:!/.? et autres @ interdits dans les mdp)

De plus dans mon appli on est en SSO (identification par LPAD(mm identifiants que windows et on est en intranet))

La technique que j'ai proposée marche sous Oracle pour contrer les saisies malheureuses de l'utilisateur(il y a d'autre fonction tel que la mise en majuscule automatique de tous les champs saisis aussi, la suppression des doubles espace etc...)

Bref, c'est une proposition... apres si tu as envie de voir tes requetes parametrees partout bin fait donc... tu peux meme en rever la nuit si tu veux... moi c'est juste une piste de reflexion que je propose!

[StringBuilder]

On ne parle pas ici de la sécurité des mots de passe.

Premièrement :

Code :

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

\' or login = substr(\'administrateur\', 2, 14)

C'est un mot de passe absolument valide sous Windows par exemple. Et au contraire, il est très content, car on mélanges lettres, chiffres et caractères étendus.

Deuxièmement :
Ici, la question n'est pas de savoir si le mot de passe est "toto", mais si l'utilisateur tente une injection lorsqu'il saisi son mot de passe, ou toute autre information, dans un formulaire.
Les méthodes que tu indique à propos des contrôles de mot de passe ne s'appliquent pas par exemple à une adresse postale ou un message sur un forum, dans lequel on doit pouvoir taper n'importe quel caractère.

Troisièmement :
La non-utilisation de requêtes paramétrées est la principale source de failles de sécurité dans les applications (web ou non d'ailleurs). Même pour la moindre requête, même si les données proviennent d'un fichier de paramètres, de la base de données elle-même ou autre, il faut systématiquement utiliser les requêtes paramétrées. C'est une habitude de développement qu'il faut prendre, pas un truc à dépoussiérer une fois de temps en temps quand on s'en sort pas avec une séquence d'échappement de caractères.

Quatrièmement, et dernièrement :
Que ce soit SQL Server, Oracle, MySQL ou n'importe quel SGBD, les requêtes paramétrées sont "infiniment" plus performances.
En effet, l'interprétation de la requête SQL, le calcul du plan d'exécution et le choix des index est, pour la plupart des requêtes, de loin ce qui prends le plus de temps.
Par conséquent, l'interprétation des requêtes est mise en cache, ainsi, que le plan d'exécution et les index.
Ce cache à pourtant une limite : lorsque deux requêtes strictement identiques sont reçues, alors il est utilisé. Mais si une seul caractère change, alors la requête doit être ré-interprétée depuis le début.
Ainsi :

Code :

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

select * from matable where login = '@login' and password = '@password'

=> Ne sera interprétée qu'une et une seule fois, quelles que soient les valeurs de @login et @password.
En revanche :

Code :

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

select * from matbale where login = 'toto' and password = 'titi';

et

Code :

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

select * from matbale where login = 'toto2' and password = 'titi2';

Sont deux requêtes parfaitement différentes, et nécessitent d'être interprétées toutes les deux. Ceci implique ensuite qu'elles sont chargées en cache... et par conséquent qu'elles viennent prendre la place d'autres requêtes éventuellement paramétrées, qui devront alors être ré-interprétées la fois suivante.

Ne pas utiliser les requêtes paramétrées, au niveaux performances, c'est donc parfaitement catastrophique, exactement comme sur le plan de la sécurité et de la lisibilité.

Maintenant, si tu préfères ne pas les utiliser, libre à toi. Mais ne viens pas chouiner un jour si tu as des problèmes avec ton employeur s'il se rend compte de la merde que tu fais.

[nid4mail]

Dans le doute j'en ai discuté avec mon "chef réseau" :

on ne risque rien en attaque externe en sql injection (on est tres bien protégé de ce coté là) et les champs sont plutot bien verrouillé. Reste l'hypothese que un type en interne s'amuse à faire ce genre de blague et il est aussitot detecte et une reponse est prevue.

Par contre si on veut anticiper la portabilité vers l'extérieur alors oui il faudrait passer en RP mais cela signifirait reprendre toutes nos applications maisons... donc on va faire remonter l'info et on disctuera avec les grands pontes et si besoin on fera intervenir une entreprises exterieure pour se coltiner les quelques 100 applis maison a refaire pour repasser en requetes parametrees. en attendant j'ai pris le lien pour mieux me renseigner et expliquer le pourquoi du comment au quidam quelconque...

[Nathanael Marchand]

Dans le doute j'en ai discuté avec mon "chef réseau" :

on ne risque rien en attaque externe en sql injection (on est tres bien protégé de ce coté là) et les champs sont plutot bien verrouillé. Reste l'hypothese que un type en interne s'amuse à faire ce genre de blague et il est aussitot detecte et une reponse est prevue.

Par contre si on veut anticiper la portabilité vers l'extérieur alors oui il faudrait passer en RP mais cela signifirait reprendre toutes nos applications maisons... donc on va faire remonter l'info et on disctuera avec les grands pontes et si besoin on fera intervenir une entreprises exterieure pour se coltiner les quelques 100 applis maison a refaire pour repasser en requetes parametrees. en attendant j'ai pris le lien pour mieux me renseigner et expliquer le pourquoi du comment au quidam quelconque...

Je vais être un peu incisif dans ma réponse mais le concept de requête parametrée est une notion de base. Lorsque je fais des entretiens d'embauche, c'est une des premières choses que je demande sur l'accès aux base de données. Si c'est un confirmé et qu'il ne connait pas, je ne le prend pas. Si c'est un débutant il passera obligatoirement par la case formation. On ne peut pas s'en passer et cela quelque soit la plateforme (.Net, Java, PHP, etc.)

[Jean-Michel Ormes]

Bonjour,

Il n'y à même pas à débattre sur le sujet. la réponse est : requête paramétrée.

[Immobilis]

on ne risque rien en attaque externe en sql injection

Chiche
Tu peux me passer l'url d'un de vos site publiques?

Sinon, chef réseau, il s'y connait en développement?

[nid4mail]

il n'y a pas de sites publics justement (c'est de l'intranet et les sites public et intranet ne sont pas sur les meme serveurs). Oui il s'y connait en dev... sinon ce serait grave