Protection D'Injection classique ASP SQL
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 un accès DB. (Je n'ai pas écrit l'application)
8 réponses
procédures stockées et / ou déclarations préparées:
https://stackoverflow.com/questions/1973/what-is-the-best-way-to-avoid-sql-injection-attacks
Capture d'Injection SQL et autres menaces Web Demandes
avec Access DB, vous pouvez toujours le faire, mais si vous êtes déjà inquiet à propos de L'Injection SQL, je pense que vous avez besoin de quitter L'accès de toute façon.
voici un lien vers la technique D'accès:
http://www.asp101.com/samples/storedqueries.asp
noter que ce qui protège typiquement de l'injection n'est pas la procédure stockée elle-même, mais le fait qu'elle est paramétrée et non dynamique. Rappelez-vous que même les SPs qui construisent du code dynamique peuvent être vulnérables à l'injection s'ils utilisent des paramètres d'une certaine manière pour construire le code dynamique. Dans l'ensemble, je préfère SPs parce qu'ils forment une couche d'interface que les applications reçoivent à la base de données, de sorte que les applications ne sont même pas autorisés à 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 la commande et les paramètres, par exemple, il est encore vulnérable parce qu'il est dynamiquement construit et peut être une cible d'injection:
Conn.Execute("EXEC usp_ImOnlySafeIfYouCallMeRight '" + param1 + "', '" + param2 + "'") ;
rappelez-vous que votre base de données doit défendre son propre périmètre, et si divers logins ont des droits de INSERT/UPDATE/DELETE dans les tables, n'importe quel code dans ces applications (ou applications compromises) peut être un problème potentiel. Si les logins ont seulement le droit d'exécuter des procédures stockées, cela forme un entonnoir à travers lequel vous pouvez beaucoup plus facilement assurer un comportement correct. (Semblable aux concepts OO où les objets sont responsables de leurs interfaces et n'exposent pas tous leurs travaux intérieurs.)
voici quelques 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
"une façon forte de 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 D'Injection SQL qui recherche les entrées non validées qui sont utilisées dans une requête. QU'est ce que vous devriez être à la recherche pour.
en utilisant des querys paramétrés, vous devez créer un objet de commande, lui assigner des paramètres avec un nom et une valeur, si vous le faites, vous n'auriez 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 se fient pas aux procédures stockées, ils peuvent devenir un vecteur d'attaque aussi si vous n'utilisez pas des déclarations préparées.
si les procédures stockées ne sont pas une option - et même si elles le sont - valider toutes les entrées complètement
le Microsoft Source Code Analyzer for SQL Injection tool est disponible pour trouver des vulnérabilités D'injection SQL dans le code ASP
Hey, n'importe quelle base de données aussi bonne que le développeur qui l'utilise.
Rien de plus mais rien de moins.
si vous êtes un bon développeur, vous pouvez créer un site de commerce électronique en utilisant des fichiers texte comme base de données. Oui, il ne sera pas aussi bon que le site web dirigé par Oracle, mais il fera très bien pour les petites entreprises comme la maison basée, fabrication de bijoux sur mesure.
et si vous êtes un bon développeur, vous n'utiliserez pas de déclarations SQL inline sur votre ASP page. Même dans Access vous avez la possibilité de construire et d'utiliser des requêtes..
stocke procs avec vérification des données, avec encodage html -- est le meilleur moyen de prévenir toute attaque par Injection SQL.
passer à SQL Express est une excellente option. Cela rendra les choses beaucoup plus sûres. Même si l'utilisation des paramètres et des procédures stockées peut aider grandement. Je vous recommande également de valider les entrées avec soin pour être sûr qu'elles correspondent à ce que vous attendez.
pour des valeurs comme les nombres il est assez facile d'extraire le nombre pour vérifier qu'il est en effet juste un nombre. Escape tous les caractères spéciaux pour SQL. Ce faisant, on empêchera la tentative attaque de travail.