Protection contre les injections SQL en ASP classique

Question

Quelle est la meilleure façon de se protéger contre l'injection sql pour une application asp classique ?

Pour info, je l'utilise avec une base de données Access. (Je n'ai pas écrit l'application)

Answer 1

Procédures stockées et/ou déclarations préparées :

http://stackoverflow.com/questions/1973/what-is-the-best-way-to-avoid-sql-injection-attacks

http://stackoverflow.com/questions/139199/can-i-protect-against-sql-injection-by-escaping-single-quote-and-surrounding-us

http://stackoverflow.com/questions/1284/catching-sql-injection-and-other-malicious-web-requests

Avec Access DB, vous pouvez toujours le faire, mais si vous êtes déjà préoccupé par l'injection SQL, je pense que vous devez abandonner Access de toute façon.

Voici un lien vers la technique en Access :

http://www.asp101.com/samples/storedqueries.asp

Notez que ce qui protège généralement de l'injection n'est pas la procédure stockée elle-même, mais le fait qu'elle soit paramétrée et non dynamique. Rappelez-vous que même les procédures stockées qui construisent du code dynamique peuvent être vulnérables à l'injection si elles utilisent des paramètres de certaines manières pour construire le code dynamique. Dans l'ensemble, je préfère les procédures stockées parce qu'elles forment une couche d'interface permettant aux applications d'accéder à la base de données, de sorte que les applications ne sont même pas autorisées à exécuter du code arbitraire en premier lieu.

En outre, le point d'exécution de la procédure stockée peut être vulnérable si vous n'utilisez pas de commande et de paramètres. Par exemple, il reste vulnérable car il est construit dynamiquement et peut être une cible d'injection :

Conn.Execute("EXEC usp_ImOnlySafeIfYouCallMeRight '" + param1 + "', '" + param2 + "'") ;

N'oubliez pas que votre base de données doit défendre son propre périmètre, et que si différents logins ont des droits sur les éléments suivants INSERT/UPDATE/DELETE dans les tables, tout code dans ces applications (ou dans des applications compromises) peut constituer un problème potentiel. Si les logins n'ont que des droits d'exécution de procédures stockées, cela forme un entonnoir à travers lequel vous pouvez beaucoup plus facilement garantir un comportement correct. (Similaire aux concepts OO où les objets sont responsables de leurs interfaces et n'exposent pas tous leurs fonctionnements internes).

Answer 2

Voici un couple de scripts sqlinject que j'ai fait il y a longtemps : une version simple et une version étendue :

function SQLInject(strWords) 
dim badChars, newChars, i
badChars = array("select", "drop", ";", "--", "insert", "delete", "xp_") 
newChars = strWords 
for i = 0 to uBound(badChars) 
newChars = replace(newChars, badChars(i), "") 
next 
newChars = newChars 
newChars= replace(newChars, "'", "''")
newChars= replace(newChars, " ", "")
newChars= replace(newChars, "'", "|")
newChars= replace(newChars, "|", "''")
newChars= replace(newChars, "\""", "|")
newChars= replace(newChars, "|", "''")
SQLInject=newChars
end function 

function SQLInject2(strWords)
dim badChars, newChars, tmpChars, regEx, i
badChars = array( _
"select(.*)(from|with|by){1}", "insert(.*)(into|values){1}", "update(.*)set", "delete(.*)(from|with){1}", _
"drop(.*)(from|aggre|role|assem|key|cert|cont|credential|data|endpoint|event|f ulltext|function|index|login|type|schema|procedure|que|remote|role|route|sign| stat|syno|table|trigger|user|view|xml){1}", _
"alter(.*)(application|assem|key|author|cert|credential|data|endpoint|fulltext |function|index|login|type|schema|procedure|que|remote|role|route|serv|table|u ser|view|xml){1}", _
"xp_", "sp_", "restore\s", "grant\s", "revoke\s", _
"dbcc", "dump", "use\s", "set\s", "truncate\s", "backup\s", _
"load\s", "save\s", "shutdown", "cast(.*)\(", "convert(.*)\(", "execute\s", _
"updatetext", "writetext", "reconfigure", _
"/\*", "\*/", ";", "\-\-", "\[", "\]", "char(.*)\(", "nchar(.*)\(") 
newChars = strWords
for i = 0 to uBound(badChars)
Set regEx = New RegExp
regEx.Pattern = badChars(i)
regEx.IgnoreCase = True
regEx.Global = True
newChars = regEx.Replace(newChars, "")
Set regEx = nothing
next
newChars = replace(newChars, "'", "''")
SqlInject2 = newChars
end function

Answer 3

"Une bonne façon de se protéger contre l'injection sql pour une application asp classique" est de valider impitoyablement toutes les entrées. Période.

Les procédures stockées seules et/ou un système de base de données différent ne sont pas nécessairement synonymes de bonne sécurité.

MS a récemment mis en place un outil d'inspection des injections SQL qui recherche les entrées non validées utilisées dans une requête. C'est ce que vous devez rechercher.

Voici le lien : L'outil Microsoft Source Code Analyzer for SQL Injection est disponible pour détecter les vulnérabilités d'injection SQL dans le code ASP.

Answer 4

En utilisant des requêtes paramétrées, vous devez créer un objet de commande, lui attribuer des paramètres avec un nom et une valeur, si vous faites cela vous n'aurez pas besoin de vous soucier de quoi que ce soit d'autre (se référant à l'injection sql bien sûr ;))

http://prepared-statement.blogspot.com/2006/02/asp-prepared-statements.html

Et ne faites pas confiance aux procédures stockées, elles peuvent aussi devenir un vecteur d'attaque si vous n'utilisez pas d'instructions préparées.

Answer 5

Si les procédures stockées ne sont pas une option - et même si elles le sont - valider de manière complète toutes les données d'entrée