Se protéger contre le SQL injection

[ikaly29]

Bonjour,

Si en PHP j'arrive à sécuriser mes requetes SQL contre le SQL injection, en ASP 3 pouvez-vous me donner le moyen le plus efficace pour en faire de même ?

ça passe peut être par une fonction de nettoyage des variables dans ce cas avez-vous un regex à me conseiller ?

Merci à vous tous.

[Immobilis]

Salut,

Envoyé par ikaly29

ça passe peut être par une fonction de nettoyage des variables

Oui, tout à fait.

1. Verifier ce qui rentre (isnumeric(), isdate(), instr())
2. Vérifier la longueur des chaines. Inutile de laisser passer une chaine de caractères de 3km pour mettre à jour un champ qui en contient 10.
3. Utiliser des procédures stockées car les variables de la procédure sont typées.

C'est déjà pas mal.

La plupart des attaques consistent à remplacer une variable passée en paramètre par une chaine sql. Je ne crois pas qu'on puisse utiliser une expression regulière.

A+

[kaiser59]

Salut,

Le seul moyen d'y remédier est de simplement créer une fonction qui remplace tout les mots ou expressions à remplacer comme tu l'avais suggérer.

Attention, je ne sais pas si tu sais mais il faut aussi faire attention aux urls susceptible de pouvoir contenir de l'sql injection

[ikaly29]

Oui j'étais donc sur la bonne voie, j'ai crée un regex qui devrait résoudre ce problème :

Code :

1
2
3
4
5
6
 
dim regEx
Set regEx = New RegExp
regEx.IgnoreCase = True
regEx.Global = True
regEx.Pattern = "exec(\s+\(|\()|varchar|delete|update|drop|\s+or\s+|\s+and\s+|insert|union\s+|union("

qu'en pensez vous ?

[ludo13]

Salut,

En plus de ce qui a été déjà dit, tu peux essayer d'interdire les caractére : <, >, =, ;
puis AND, OR

Je pense que tu peux utiliser les expression régulière, voir tutorial suivant.
http://jacques-guizol.developpez.com...Exp/RegExp.php
http://prevot.developpez.com/outils/regex/
Je pense qu'il doit avoir unr fonction asp ou vbscript pour tester les expression regulieres.
A+

[GoN49]

Bonjour ,

Et je rajouterais en priorité dans mes filtres CAST puis DECLARE.
CAST te permet de passé des donné en hexa alors attention.
Je rajouterais aussi sp_exec

Voili voilou

[Immobilis]

J'oubliais aussi,

• utiliser un identifiant de connection à la base qui possède le minimum de privilèges (netement pas le droit de lister les tables system).
• Pourquoi pas avoir deux bases de données différentes, une client et une pour l'administration (backoffice).

A+

[TekP@f]

Salut,

Sauf que des injections peuvent être codées en hexa ce qui démonte toute ta mécanique de détection.
Suis les conseils d'immobilis le sage

[Immobilis]

Envoyé par TekP@f

Suis les conseils d'immobilis le sage

Ouh là faut faire attention tout de même.

Envoyé par TekP@f

Sauf que des injections peuvent être codées en hexa

Oui

Envoyé par TekP@f

ce qui démonte toute ta mécanique de détection.

Peut-être pas car pour avoir vu les effets de nihaorr1 , il faut tout de même faire un CAST de la chaine haxedecimale. Donc il reste du code malveillant sous forme literale (cf image jointe).

C'est le genre de truc qui marche quand on ne verifie pas bien les données qui rentre. On constate que l'instruction ne marcherai pas dans les champs texte dont la taille est correctement dimenssionnée.

Je crois tout de même que le premier truc à faire est d'utiliser un identifiant de connection à la base avec un minimum de privilèges (SELECT, UPDATE/INSERT sur certaines tables et pas DELETE, ...).

Envoyé par ikaly29

Si en PHP j'arrive à sécuriser mes requetes SQL contre le SQL injection

Comment fais-tu en PHP?

A+

[copin]

Salut salut,

Je crois tout de même que le premier truc à faire est d'utiliser un identifiant de connection à la base avec un minimum de privilèges (SELECT, UPDATE/INSERT sur certaines tables et pas DELETE, ...).

Solution la plus efficace je confirme j'ai testé sans mettre en place de script

il faut tout de même faire un CAST de la chaine haxedecimale. Donc il reste du code malveillant sous forme literale (cf image jointe).

Donc en théorie, si on fait une recherche du mot "CAST" (ou d'équivalent) grâce à un script je dois pouvoir bloquer un certains nombres d'attaque même minime? Non?

A plouch

[Immobilis]

Donc en théorie, si on fait une recherche du mot "CAST" (ou d'équivalent) grâce à un script je dois pouvoir bloquer un certains nombres d'attaque même minime

En théorie oui, mais il y a pas mal de mots qui commencent par CAST. Peut-être "CAST(".

A lire: http://fr.wikipedia.org/wiki/Injection_SQL

A+

[Laurent Jordi]

Salut,

J'ai aussi été attaqué, on m'a injecté plein de lien vers un script alacon qui doit sans doute installer une sorte de virus ou au moins un malware.

Parade (Je ne vois pas quoi faire d'autre en attendant que ma version ASP.net 3.5 soit prête)

• transfert de la base SQL Serveur 2000 vers 2005 Express (comme ca au passage je me met au carré pour ma licence de dev expirée)
• création d'un nouveau Schéma Site
• création d'un nouvel utilisateur dont le compte d'accès est le même que celui qui utilise le site concerné (défini dans la sécurité du répertoire, normalement IUSR_...)
• Création d'un rôle Site n'ayant que les droits d'exécution sur les objets du schéma pas de droit de select ou autre action directe
• pensez quand même a donner les droits à votre compte sur le schema dbo pour que vous puissiez trankil déboguer vos procs dans visual studio
• Suppression de toutes les requêtes en texte dans les pages (il en restait) et transformation de ces dernières en Proc appartenant au Schéma Site.
• Transfert de toutes les procédures stockées, vues et fonctions du schema dbo vers le schéma site
• ET BIEN SUR Nettoyage de la base (j'ai fait un petit prog C# pour ça) j'essayerais de le publier dès que j'aurais sorti la tête de l'eau.

Après, lorsqu'on travaille sur un CMS avec un répertoire d'Upload SURTOUT ne pas oublier de retirer les droits d'exécution du répertoire d'upload.

Bon, ben bon Week end, si j'arrive a finir tout ça en 2 jours je me raze la tête...

++

Laurent

[Immobilis]

• transfert de la base SQL Serveur 2000 vers 2005 Express (comme ca au passage je me met au carré pour ma licence de dev expirée). Pas de rapport
• création d'un nouveau Schéma Site. C'est quoi?
• création d'un nouvel utilisateur dont le compte d'accès est le même que celui qui utilise le site concerné (défini dans la sécurité du répertoire, normalement IUSR_...). Il faut séparer le compte d'accès du site web de celui de la base de données. Créer un compte de base de donnée ayant peu de droits. L'injection dont tu as été victime utilise un compte avec les privilèges suffisant pour lister les tables system qui conserve le schema de ta base
• Création d'un rôle Site n'ayant que les droits d'exécution sur les objets du schéma pas de droit de select ou autre action directe. Je ne sais pas trop là. Faudrait voir du côté du forum SGBD
• pensez quand même a donner les droits à votre compte sur le schema dbo pour que vous puissiez trankil déboguer vos procs dans visual studio. Non, il faut utiliser un compte différent. Un compte pour le site utilisé par les internaute, un autre pour le developpeur qui débogue
• Suppression de toutes les requêtes en texte dans les pages (il en restait) et transformation de ces dernières en Proc appartenant au Schéma Site. Oui, bonne idée. Il faut cependant vérifier les données qui rentre
• Transfert de toutes les procédures stockées, vues et fonctions du schema dbo vers le schéma site. C'est quoi le schéma site?
• ET BIEN SUR Nettoyage de la base (j'ai fait un petit prog C# pour ça) j'essayerais de le publier dès que j'aurais sorti la tête de l'eau. Ey faire des sauvegardes fréquentes. Nous avons pu réagir très vite grace à des sauvegardes toutes les 15mn.

A+

[Laurent Jordi]

Salut,

Un schéma est un groupe d'objets. Ça permet, très simplement de regrouper toutes les procédures stockées pour que seul un rôle puisse les exécuter. L'intérêt du schéma combiné au rôles est d'éviter justement que l'utilisateur site puisse avoir accès à la liste des tables ou plus.

Donc le rôle permet de regrouper des utilisateurs et de leur affecter des droits sur les schémas qui regroupent des objets.

Si tu ne donnes que les droits d'exécution uniquement sur tes procédures de ton schéma (et donc pas dbo qui donne accès à certaines proc système), normalement tu es protégé.

Concernant le l'utilisateur séparé du compte du site, selon moi c'est une erreur car ça oblige (EN ASP 3) a stocker quelque part le mot de passe et c'est dangereux. Il vaut mieux utiliser la sécurité de sql serveur combinée à celle de Windows.

J'ajoute que si j'en juge les endroits ou on m'a injecté des cochonneries, je crois que c'est la partie ASP.net 1.1 qui a été violée et non la partie ASP 3.0 toutefois je peux me tromper et il est possible que les deux soient en cause.

@+

Laurent

[Immobilis]

Envoyé par Laurent Jordi

Concernant le l'utilisateur séparé du compte du site, selon moi c'est une erreur car ça oblige (EN ASP 3) a stocker quelque part le mot de passe et c'est dangereux. Il vaut mieux utiliser la sécurité de sql serveur combinée à celle de Windows.

C'est aussi ce qui est conseillé par MS. Toutefois, dans le fond cela ne change rien si d'une façon et l'autre les utilisateurs on des privilèges trop élevés par rapport à leur prérogatives.

Pour ce qui est de la sécurité du mot de passe. Bah, le code vbscript serveur n'est pas visible et les fichiers ne sont pas téléchargeables. Alors...

Ta base de données et ton site ne sont pas sur le même serveur j'imagine. Peux-tu expliquer comment tu gères les identifiants sur les deux domaines constitués par les deux machines?

A+

[Laurent Jordi]

Re

Je suis un tout petit éditeur indépendant... Je n'ai pas 36 machine mais une seule... C'est même pas une bête c'est juste un P4 à 2Ghtz avec 1Go de ram.

Pour répondre à ta question, le mieux est d'utiliser un Web Service WS*
Deuxième option c'est de faire une relation d'approbation de domaines.

Dans mon cas, mon serveur de prod est une machine stand alone bien protégée par un Firewall. En 5 ans, je n'ai eu qu'une seule attaque réussie.

D'après ce que j'ai lu, c'est presque un bug laissé intentionnellement par MS. Sans doute pour pousser les gens à renouveler leur parc.

La future version de mon application sera quasi inviolable. Elle est en préprod pour le moment. Elle pourra fonctionner sur une machine, deux ou sur un réseau plus complexe doté d'une batterie de serveurs frontaux stateless.

L'un des mécanismes de protection sera un interpréteur de contenu fonctionnant en temps réel à la sauvegarde et à la restitution de chaque contenu. J'ai aussi imaginé une solution pour garantir une parfaite sécurité pour les upload.

Etant tout seul je suis obligé de conserver ma solution actuelle en prod pour les quelques clients de test que j'ai.

C'est lorsqu'on est confronté à ces problèmes que l'on constate que créer et faire évoluer un CMS c'est pas juste mettre en oeuvre un éditeur WYSIWYG open source pour sauvegarder deux pages web...

++

Laurent

[Laurent Jordi]

Salut,

Je sais qu'il y a au moins 10 bonnes raison de ne pas poster ça ici mais c'est dans le prolongement de ce qui précède.

Je m'apperçois que j'ai bien IUSR... qui utilise ma base de données pour les pages ASP 3 par contre pour les pages asp.net 1.1 issues de la même racine web, j'ai l'impression qu'ASPNET a les droits dbo (ce qui m'ennuie).

C'est bien ASPNET qui nollicite la base de données lorsque les pages ASP.net s'exécutent ?

D'avance merci pour votre aide car la j'ai un gros doute...

++

Laurent

[Immobilis]

Envoyé par Laurent Jordi

C'est bien ASPNET qui nollicite la base de données lorsque les pages ASP.net s'exécutent ?

Ben normalement, non, sauf peut-être quand on utilise un compte Windows pour le faire. Le compte ASPNet est à l'aspx ce que IUSR est à l'ASP3. Donc...

A+

[Laurent Jordi]

Re,

Merci. C'est bien ce qui me semblait. Ce qui m'étonne c'est que des scripts SQL écrits en chaines de caractères à partir d'asp.net passent alors qu'ASPNET n'a pas les droits en SELECT UPDATE ET DELETE. Il doit y avoir des droits par défauts...

C'est assez gênant dans mon cas..

Je verrais ça demain matin, là j'overdose un peu

++

Laurent

[Laurent Jordi]

Salut,

Je viens de relire le thread qui m'a fait un peu peur au niveau de la chaine codée en hexa.

Je pense être concerné puisque je manipule mainenant des variables nvarchar(max).

Si le site n'a plus que des procédures stockées, vous pensez qu'il est encore vulnérable au SQL Injection ?

D'avance merci,

Laurent