Êtes-vous sûr que l'injection SQL est morte ?

Pendant longtemps, j'ai pensé que le problème le plus probable dans le développement back-end en termes de sécurité était l'injection SQL. Grâce à la méthode d'écriture SQL magique de where 1=1, vous pouvez facilement attaquer un système problématique et éventuellement évoluer vers l'existence d'artefacts comme sqlmap.

Ce dernier fastjson a rafraîchi ma compréhension. Ce cadre peut également être considéré comme une promotion du concept de sécurité Internet. Même les patrons qui ne comprennent pas la technologie connaissent fastjson快的要命, et en tant que programmeur, leur concept de sécurité a été amélioré.

Recommandé (gratuit) : sql

Pourquoi avez-vous un faible pour l'injection SQL ? Parce qu'il y a trop d'endroits où les développeurs s'occupent de SQL. Certains étudiants spécialisés dans le développement de rapports écrivent même plus de lignes de SQL que de lignes de code !

Le problème est que. Il y a bien longtemps, il y a déjà 10 ans, certains criaient que l'injection SQL était morte, mais à ce jour, il existe encore un grand nombre de tutoriels d'injection SQL et de cas d'injection SQL.

L'injection SQL est la reine des vulnérabilités, ce n'est pas une vantardise.

Bien sûr, à cet égard, PHP a apporté la plus grande contribution, Java étant à la traîne.

La raison pour laquelle l'injection SQL est populaire est que les développeurs ont trop confiance en eux-mêmes ou que les outils qu'ils utilisent sont trop primitifs et n'ont pas été filtrés par la couche framework. Si vous utilisez MyBatis ou JPA dans le monde Java, la possibilité d'injection SQL devient très faible. Désormais, PHP dispose également d'un framework similaire à thinkphp, ce qui signifie qu'il y a de moins en moins de vulnérabilités d'injection SQL.

Mais cela ne veut pas dire qu’il n’y en a pas, cela signifie simplement que le seuil a été relevé. Prenons MyBatis comme exemple pour voir si l'injection SQL peut toujours se produire.

L'injection SQL existe toujours dans MyBatis

Les étudiants qui utilisent Mybatis, le premier concept avec lequel ils entrent en contact est la différence entre # et $. Ces deux symboles sont très similaires aux symboles magiques de Shell, mais heureusement il n'y a que deux situations.

• # représente l'utilisation de la méthode de pré-compilation SQL, qui est sûre et fiable.

• $ représente la méthode d'épissage. , qui correspond aux risques de l'injection SQL

Par exemple, la configuration XML suivante est un moyen absolument sûr de l'écrire. Parce que l'intégralité du #{id} sera remplacé par ?.

<select id="queryAll"  resultMap="resultMap">
  SELECT * FROM order WHERE id = #{id}
</select>

Mais malheureusement, dans certains scénarios, la précompilation ne peut pas être utilisée (ou vous ne le savez tout simplement pas ou êtes paresseux). Par exemple, dans certaines refactorisations de code, lorsque des champs tels que le nom de la table/le nom de la colonne/le tri sont transmis dynamiquement, l'épissage SQL est inévitablement requis et l'injection SQL se produit toujours.

Mais des phrases similaires telles que LIKE et IN sont plus susceptibles de causer des problèmes.

Voici comment écrire une requête floue Like en deux phrases. Lors des tests réels, il s'avérera que l'utilisation de # n'est pas facile à utiliser et une erreur sera signalée. épissage $. C'est là que le problème se pose.

SELECT * FROM order WHERE name like '%#{name}%'  //会报语法错
SELECT * FROM order WHERE name like '%${name}%'  //可以运行

La bonne façon de l'écrire est d'utiliser l'épissage de fonctions. Mais le délai de construction est écrasant, et sans même s’en rendre compte, la plupart des gens choisissent la manière simple d’écrire. Après tout, la fonction passe avant tout, et c’est aussi le moyen le plus important de refléter la charge de travail.

SELECT * FROM order WHERE  name like concat(‘%’,#{name}, ‘%’) //正确的写法

Le même problème existe dans la déclaration IN.

in (#{tag}) //报错
in (${tag}) //可以运行

Comme il peut être exécuté avec seulement quelques caractères, bien sûr, personne ne choisit la méthode d'écriture compliquée ci-dessous.

tag in
<foreach collection="tag" item="item" open="("separatosr="," close=")">
#{tag} 
</foreach>

Commandez également, ne le prenez pas à la légère, sinon vous serez condamné.

SELECT * FROM order order by createDate #{sortType} //报错
SELECT * FROM order order by createDate ${sortType} //正常

Dans ce cas, vous devez ajouter sortType à la liste blanche. Il n'y a pas que ASC et DESC. Vous m'avez envoyé une longue chaîne, que se passe-t-il ?

Résumé

L'injection SQL existe toujours en 2021, mais le seuil a été relevé. . La diminution de l'injection SQL est désormais entièrement due au framework et n'a rien à voir avec le niveau des programmeurs. La situation de l’épissage SQL ne disparaîtra jamais car c’est le moyen le plus rapide et le plus simple et cela rendra les gens dépendants. Il existe d’innombrables projets d’externalisation, et de nombreux systèmes sont restés inactifs depuis plus de dix ans. Espérer que l’injection SQL sera éliminée au niveau du framework.

Parce que son adversaire est la paresse humaine. Personne ne peut le vaincre.

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!