Java Mybatis empêche l'analyse par injection SQL-javaDidacticiel-php.cn

Java Mybatis empêche l'analyse par injection SQL

巴扎黑

Libérer： 2017-08-09 17:56:25

original

1581 Les gens l'ont consulté

Cet article présente les informations pertinentes de Mybatis pour empêcher l'injection SQL à travers des exemples. Il est très bon et a une valeur de référence. Les amis dans le besoin peuvent s'y référer

L'injection SQL est familière à tout le monde et est courante. La méthode d'attaque consiste à ce que l'attaquant saisisse des fragments SQL étranges dans les informations de formulaire ou l'URL de l'interface, tels que des instructions telles que "or '1'='1'", qui peuvent envahir les applications avec une vérification insuffisante des paramètres. Par conséquent, nous devons travailler sur nos applications pour empêcher de telles attaques. Dans certaines applications hautement sécurisées, telles que les logiciels bancaires, la méthode consistant à remplacer toutes les instructions SQL par des procédures stockées est souvent utilisée pour empêcher l'injection SQL. Il s'agit bien sûr d'une méthode très sûre, mais dans notre développement quotidien, elle peut ne pas être nécessaire. pour une approche aussi rigide.

En tant que framework de couche de persistance semi-automatique, le framework mybatis nous oblige à écrire manuellement ses instructions SQL nous-mêmes. Bien sûr, nous devons empêcher l'injection SQL pour le moment. En fait, le sql de Mybatis est une structure avec fonction "entrée + sortie", similaire à une fonction, comme suit :

<select id="getBlogById" resultType="Blog" parameterType=”int”>
  select id,title,author,content
  from blog where id=#{id}
 </select>

Copier après la connexion

Ici, paramètreType indique le type du paramètre d'entrée , resultType indique le type de paramètre de sortie. En réponse à ce qui précède, si l’on veut éviter l’injection SQL, il est naturel de travailler sur les paramètres d’entrée. La partie en surbrillance dans le code ci-dessus est la partie où les paramètres d'entrée sont épissés dans SQL. Après avoir transmis les paramètres, imprimez l'instruction SQL exécutée et vous verrez que le SQL ressemble à ceci :

<🎜. >

select id,title,author,content from blog where id = ?

Copier après la connexion

Peu importe les paramètres saisis, le SQL imprimé sera comme ceci. En effet, mybatis a activé la fonction de pré-compilation. Avant l'exécution du SQL, le SQL ci-dessus sera envoyé à la base de données pour compilation. Lors de l'exécution, le SQL compilé sera utilisé directement et l'espace réservé "?" Étant donné que l'injection SQL ne peut fonctionner que sur le processus de compilation, cette méthode peut bien éviter le problème de l'injection SQL.

Comment mybatis réalise-t-il la pré-compilation SQL ? En fait, au bas du framework, la classe PreparedStatement dans jdbc est à l'œuvre. PreparedStatement est une sous-classe de Statement que nous connaissons très bien, et son objet contient des instructions SQL compilées. Cette approche « prête » améliore non seulement la sécurité, mais améliore également l'efficacité lors de l'exécution répétée d'un SQL. La raison en est que le SQL a été compilé et n'a pas besoin d'être compilé à nouveau lors de sa nouvelle exécution.

Cela dit, pouvons-nous définitivement empêcher l'injection SQL en utilisant mybatis ? Bien sûr que non, veuillez regarder le code suivant :

<select id="orderBlog" resultType="Blog" parameterType=”map”>
  select id,title,author,content
  from blog order by ${orderParam}
 </select>

Copier après la connexion

Regardez attentivement, le format du paramètre en ligne est passé de "#{xxx}" à ${ xxx}. Si nous attribuons la valeur de "id" au paramètre "orderParam" et imprimons le SQL, cela ressemblera à ceci :

sélectionnez l'identifiant, le titre, l'auteur, le contenu du blog, commandez par identifiant

Évidemment, c'est le cas. Il n'y a aucun moyen d'empêcher l'injection SQL. Dans mybatis, les paramètres au format "${xxx}" participeront directement à la compilation SQL, les attaques par injection ne pourront donc pas être évitées. Mais lorsqu'il s'agit de noms de tables et de colonnes dynamiques, seuls les formats de paramètres tels que "${xxx}" peuvent être utilisés. Par conséquent, ces paramètres doivent être traités manuellement dans le code pour empêcher l'injection.

Conclusion : lors de la rédaction de l'instruction de mappage de mybatis, essayez d'utiliser le format "#{xxx}". Si vous devez utiliser des paramètres tels que "${xxx}", vous devez les filtrer manuellement pour empêcher les attaques par injection SQL.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!