Le code d'erreur signalé est-il considéré comme une injection SQL?

L'injection SQL qui exécute réellement une commande SQL est une chose. Mais injecter des données qui n'exécutent pas réellement une requête nuisible, mais qui pourrait vous dire quelque chose de précieux sur la base de données, est-ce considéré comme une injection SQL? Ou est-ce juste utilisé pour construire une injection SQL valide?Le code d'erreur signalé est-il considéré comme une injection SQL?

Un exemple pourrait être

set rs = conn.execute("select headline from pressReleases 
where categoryID = " & cdbl(request("id")))

L'adoption de cette chaîne qui ne pouvait être transformé en une valeur numérique causerait

Microsoft VBScript runtime error '800a000d' 
Type mismatch: 'cdbl'

qui vous dira que la colonne en question accepte uniquement les données numériques et est donc probablement de type entier ou similaire.

Il me semble trouver cela dans beaucoup de pages traitant de l'injection SQL, mais je n'ai pas vraiment de réponse si cela est considéré comme une injection SQL. La raison de ma question est que j'ai un outil d'analyse qui signale une vulnérabilité d'injection SQL et signale une erreur d'exécution de VBScript '800a000d' comme raison de la découverte.

Source

2010-06-09 inquam

Tout simplement parce que vous ne savez pas nécessairement comment construire un vecteur d'attaque malveillant, cela ne veut pas dire que personne d'autre ne le fait. Utilisez les paramètres liés dans votre SQL pour éliminer toute possibilité d'injection. – Cheekysoft

Il s'agit clairement d'une vulnérabilité d'injection SQL et elle doit être corrigée.

Il y a quelques raisons à cela dans votre scénario:

trouver des informations accessoires tels que vous décrivez peut être utile à un attaquant, si elles ont particulary d'autres vecteurs d'attaque.
Un attaquant trouvant cette vulnérabilité serait encouragé à aller en chercher d'autres. Sloppy ici peut signifier bâclé ailleurs.
En sécurité, il est important de ne pas être trop intelligent. Votre attaquant peut en savoir beaucoup plus, ou quelque chose de plus, que vous. Donc, ce qui peut vous sembler une vulnérabilité contenue peut être une porte ouverte à quelqu'un d'autre.

Alors oui, votre outil fait ce qu'il faut.

Source

2010-06-09 11:44:33

Compte rendu d'une telle constatation, je peux comprendre, car il divulgue des informations qui, le plus probablement, ne devraient pas être divulgués. Mais cela remplit-il encore les critères d'une attaque "injection" SQL? Quelle est la définition officielle qui rendrait cette injection SQL? C'est ce que j'essaie de trouver;) – inquam

L'injection SQL est en effet définie comme une action où l'utilisateur exécute des commandes sql en utilisant des entrées spécialement formatées. Avec votre SQL, il n'est probablement pas possible de faire une injection à cause du cdbl(). Mais comme l'a déclaré Phil Wallach, il est possible que l'utilisateur puisse le faire de temps à autre, ce que nous ne connaissons pas - c'est donc un endroit où l'injection sql pourrait se produire. Ainsi, ce n'est pas une "injection sql" mais une "vulnérabilité d'injection sql". (Imaginez que vous supprimiez parfois le cdbl - l'injection est immédiatement rendue possible.) –

Je ne suis pas un gourou de la sécurité, donc je ne peux pas donner une définition. Je crois juste qu'il est préférable d'éviter toutes les vulnérabilités possibles, même si elles ne sont pas explicitement dangereuses. –

Je dirais oui! Vous injectez une chaîne SQL et obtenez des informations que vous n'êtes pas censé obtenir. Je pense que c'est déjà "nocif".

Source

2010-06-09 11:40:34

Le code d'erreur signalé est-il considéré comme une injection SQL?

Répondre

Questions connexes