Discussion :

[JeanYvette]

Bonjour tout le monde,

Désolé si le sujet a déjà été traité mais j'ai l'impression de pas trouver de réponses exact ou autre (je me sens nul ohlala je pleure)
Je vous présente le contexte, j'ai fait une bdd sous sql server et pour la tester je le fais en asp (site rapide, pas de design, juste du fonctionnel). Je ne fonctionne que par fonction table ou scalar, et par procédure stockée. J'appelle tout cela dans mes différentes pages asp, tout va bien dans le meilleur des mondes
Mais un jour j'ai eu une vision (bon ok jsuis juste allé sur le site de la CNIL) et là, horreur LES INJECTIONS SQL !!! *tremble*
Ma question est simple, est ce que ce système de procédure stockées ou function pour toutes opérations suffisent à palier aux injections sql ???

Je prie le grand Bouddha pour que oui mais bon, je suis pas trop sûr !

[JeanYvette]

Juste un petit up avant de me faire insulter

Dans les appels (string requete = "") j'ai fait en sorte que tout ce qui peut être APRES un ; soit supprimé

[SQLpro]

est ce que ce système de procédure stockées ou function pour toutes opérations suffisent à palier aux injections sql ???

Absolument pas !

Pour se protéger des injections de SQL (c'est plus facile si vous n'avez fait que du code côté serveur), il faut :
1) mettre en place la sécurité base sur des privilèges en rapport à des utilisateurs SQL / compte de connexion. Cela sera grandement facilité si vous avez découpé votre base en de multiples schémas SQL et je vous conseille de jouer sur les rôles
2) dans les routines (procédures et déclencheurs), qui propose du SQL dynamique (facilement identifiable par "EXEC (" ou sp_executesql) il faut vérifier vos variables et voir si elles ne contiennent pas du code maligne.... La plupart du temps c'est trivial, par une comparaisons aux méta données. Dans les autres cas, faire une fonction générique qui repère certains motifs, comme :
EXECUTE
EXEC
sp_executesql.
[
]
%
_
"
;
--
/*
*/
xp_
sp_

Vous pouvez même faire une table de tous ces motifs plutôt que de les mettre en dur.

Enfin, ne renvoyez aucune erreur en cas de détection d'une possible injection et tracez ce qui a été envoyé. Cela vous permettra de bloquer l'adresse IP de l'expéditeur.
Dans le même esprits, ne renvoyez jamais les erreurs telles qu'elle. Enregistrez les erreurs pour les analyser plus tard et renvoyez une erreur générique...

A +

[JeanYvette]

Pour les privilège c'est bon

Pour les variable je suis pas sur de bien comprendre, si je fais par exemple :

Code :

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

1
2
exec InsertionUsers @NomUtilisateur = '" + TextBoxNom.Text + "', @PrenomUtilisateur ='" + TextBoxPrenom.Text + "', @NumeroRueUtilisateur = " 
+ TextBoxNumRue.Text + ", @NomRueUtilisateur = '" + TextBoxNomRue.Text + " ' "

On peut mettre, si je comprends ce que vous dites, des requêtes dans les textbox.text qui seraient au final exécutés par le sgbd ??


Pour ce qui est du traçage j'ai une table qui historise les requêtes fait par les utilisateurs, la date, et l'ip de connection (pour pouvoir faire une rollback plus tard) est-ce une bonne méthode ?

[SQLpro]

Pour les privilège c'est bon

Pour les variable je suis pas sur de bien comprendre, si je fais par exemple :

exec InsertionUsers @NomUtilisateur = '" + TextBoxNom.Text + "', @PrenomUtilisateur ='" + TextBoxPrenom.Text + "', @NumeroRueUtilisateur = " + TextBoxNumRue.Text + ", @NomRueUtilisateur = '" + TextBoxNomRue.Text + " ' "

Ne sachant pas avec quel outil vous développez vos IHM, je suis en peine de vous aider. Le mieux serait que cet outil soit capable de faire des requêtes paramètrées.
De mon temps (mon dieu, j'ai l'air d'un vieux con !!!) on faisait :

Code :

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

1
2
3
4
5
6
theQuery.text := "exec InsertionUsers @NomUtilisateur = :param1 , @PrenomUtilisateur = :param2 , @NumeroRueUtilisateur = :param3 , @NomRueUtilisateur = :param4;";
theQuery.params[1] := TextBoxNom.Text;
theQuery.params[2] := TextBoxPrenom.Text;
theQuery.params[3] := TextBoxNumRue.Text;
theQuery.params[4] := TextBoxNomRue.Text;
theQuery.execute();

Ce qui permettait déjà de limiter la casse en ayant prévu des paramètres typés !

On peut mettre, si je comprends ce que vous dites, des requêtes dans les textbox.text qui seraient au final exécutés par le sgbd ??


Pour ce qui est du traçage j'ai une table qui historise les requêtes fait par les utilisateurs, la date, et l'ip de connection (pour pouvoir faire une rollback plus tard) est-ce une bonne méthode ?

Dans la procédure, pour chacun des paramètres passés, vérifier s'il ne contient pas des caractères ou motifs illicites...

Pour cela faite par exemple le module suivant :

Code :

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

1
2
3
4
5
6
7
8
USE MaBase
GO
 
CREATE SCHEMA S_SECURITY
CREATE TABLE T_EXCLUDE_INJECTION_PATTERN_EIP
(EIP_ID         SMALLINT IDENTITY PRIMARY KEY,
 EIP_PATTERN    VARCHAR(16) NOT NULL UNIQUE);
GO

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
INSERT INTO S_SECURITY.T_EXCLUDE_INJECTION_PATTERN_EIP VALUES
('EXECUTE'), 
('EXEC'), 
('sp_executesql'), 
('['), 
(']'), 
('%'), 
('_'), 
('"'), 
(''''), 
(';'), 
('--'), 
('/*'), 
('*/'), 
('xp_'), 
('sp_');
GO

Code :

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

1
2
3
4
5
6
7
8
9
10
CREATE FUNCTION S_SECURITY.IS_INJECTION_PATTERN (@WORD NVARCHAR(max))
RETURNS BIT
BEGIN
   IF EXISTS(SELECT *
                FROM   S_SECURITY.T_EXCLUDE_INJECTION_PATTERN_EIP 
		        WHERE  @WORD LIKE N'%' + EIP_PATTERN + '%')
      RETURN 1;
   RETURN 0;
END;
GO

Dans vos procédures, au tout début, juste après le SET NOCOUNT ON; ajoutez un test de vos variables :

Code :

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

1
2
3
4
5
IF S_SECURITY.IS_INJECTION_PATTERN(@NomUtilisateur) = 1
   RETURN;
IF S_SECURITY.IS_INJECTION_PATTERN(@PrenomUtilisateur) = 1
   RETURN;
...

ne testez que les variables littérales !

A +

[JeanYvette]

D'accord je viens de comprendre, un énorme merci à vous pour le coup
Je vais faire ce que vous avez dit de ce pas

ah mais oui du coup j'avais fait un appel de requête de ce style là :

Code :

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

1
2
 
 string requete = "exec InsertionPourPatient @NomUtilisateur = '" + TextBoxNom.Text + "', @PrenomUtilisateur ='" + TextBoxPrenom.Text + "', @NumeroRueUtilisateur = " + TextBoxNumRue.Text + ", @NomRueUtilisateur = '" + TextBoxNomRue.Text + "', @VilleUtilisateur = '" + TextBoxVille.Text + "', @Identifiant='" + TextBoxSecuSociale.Text + "', @Metier  = '" +TextBoxMetier.Text+ " ' "

Mais ca marche plus avec cette histoire de double quotes qui sont interdites via la table des caractères c'est ça ?

[SQLpro]

C'est plutôt que votre outil de développement doit proposer les bons objets....
Quel est cet outil ? .net ? java ? PHP ? ...

Et pour les tests, uniquement ceux qui font du SQL dynamique. Dans le cas d'une requête paramétrée, il n'y a aucun intérêt de faire des tests.

A +