Cet article présente principalement l'évitement de l'injection SQL. L'éditeur pense que c'est plutôt bien. Maintenant, je le partage avec vous et le donne comme référence. Suivons l'éditeur et jetons un coup d'œil.
1. Il doit y avoir une distinction stricte entre les autorisations des utilisateurs ordinaires et des utilisateurs administrateurs système.
Si un utilisateur ordinaire intègre une autre instruction Drop Table dans une instruction de requête, son exécution est-elle autorisée puisque l'instruction Drop est liée aux objets de base de la base de données, l'utilisateur doit-il le faire ? faire fonctionner cette instruction Doit disposer des autorisations appropriées. Dans la conception des autorisations, pour les utilisateurs finaux, c'est-à-dire les utilisateurs de logiciels d'application, il n'est pas nécessaire de leur accorder des autorisations pour créer et supprimer des objets de base de données. Ainsi, même si du code malveillant est intégré dans les instructions SQL qu’ils utilisent, ces codes ne seront pas exécutés en raison de restrictions sur leurs autorisations utilisateur. Par conséquent, lors de la conception d’une application, il est préférable de distinguer les utilisateurs administrateurs système des utilisateurs ordinaires. Cela peut minimiser les dommages causés par les attaques par injection dans la base de données.
2. Forcer l'utilisation d'instructions paramétrées.
Si les variables saisies par l'utilisateur ne sont pas directement intégrées dans l'instruction SQL lors de l'écriture de l'instruction SQL. Si vous transmettez cette variable via des paramètres, vous pouvez empêcher efficacement les attaques par injection SQL. En d’autres termes, les entrées utilisateur ne doivent pas être directement intégrées dans les instructions SQL. En revanche, les entrées utilisateur doivent être filtrées ou des instructions paramétrées doivent être utilisées pour transmettre les variables d'entrée utilisateur. Les instructions paramétrées utilisent des paramètres au lieu d'incorporer des variables d'entrée utilisateur dans l'instruction SQL. Grâce à cette mesure, la plupart des attaques par injection SQL peuvent être éliminées. Malheureusement, peu de moteurs de bases de données prennent en charge les instructions paramétrées. Cependant, les ingénieurs de bases de données doivent essayer d'utiliser des instructions paramétrées lors du développement de produits.
3. Renforcer la vérification des entrées des utilisateurs.
En général, deux méthodes peuvent être utilisées pour empêcher les attaques par injection SQL. L'une consiste à renforcer l'inspection et la vérification du contenu saisi par l'utilisateur. L'autre consiste à forcer l'utilisation d'instructions paramétrées. transmettre le contenu saisi par l'utilisateur. Dans la base de données SQLServer, il existe de nombreux outils de vérification du contenu des entrées utilisateur qui peuvent aider les administrateurs à gérer les attaques par injection SQL. Testez le contenu d'une variable chaîne et acceptez uniquement la valeur requise. Rejetez les entrées contenant des données binaires, des séquences d'échappement et des caractères de commentaire. Cela permet d'empêcher l'injection de scripts et empêche certaines attaques par débordement de tampon. Testez les entrées utilisateur pour la taille et le type de données, en appliquant les limites et les conversions appropriées. Cela permet d’éviter les débordements intentionnels de tampon et a un effet significatif sur la prévention des attaques par injection.
4. Utilisez les paramètres de sécurité fournis avec la base de données SQL Server.
Afin de réduire les effets néfastes des attaques par injection sur la base de données SQL Server, des paramètres SQL relativement sûrs sont spécialement conçus dans la base de données SQL Server. Au cours du processus de conception de la base de données, les ingénieurs doivent essayer d'utiliser ces paramètres pour empêcher les attaques malveillantes par injection SQL.
5. Comment prévenir les attaques par injection SQL dans les environnements multi-niveaux
Dans les environnements d'applications multi-niveaux, toutes les données saisies par les utilisateurs doivent être vérifiées ? après vérification Ce n'est qu'alors qu'ils pourront être autorisés à entrer dans la zone de confiance. Les données qui échouent au processus de validation doivent être rejetées par la base de données et un message d'erreur renvoyé au niveau suivant. Implémentez une vérification multicouche. Les précautions prises contre les utilisateurs malveillants inutiles peuvent ne pas être efficaces contre des attaquants déterminés. Une meilleure approche consiste à valider les entrées au niveau de l'interface utilisateur et à tous les points ultérieurs au-delà des limites de confiance. Par exemple, la validation des données dans l'application client peut empêcher une simple injection de script. Cependant, si la couche suivante pense que son entrée a été validée, tout utilisateur malveillant pouvant contourner le client peut avoir un accès illimité au système. Par conséquent, pour les environnements d'applications multicouches, lors de la prévention des attaques par injection, toutes les couches doivent fonctionner ensemble et des mesures correspondantes doivent être prises du côté client et de la base de données pour empêcher les attaques par injection d'instructions SQL.
6. Si nécessaire, utilisez des outils professionnels d'analyse des vulnérabilités pour trouver d'éventuels points d'attaque.
L'utilisation d'outils professionnels d'analyse des vulnérabilités peut aider les administrateurs à trouver les points possibles d'attaques par injection SQL. Cependant, les outils d’analyse des vulnérabilités ne peuvent découvrir que les points d’attaque et ne peuvent pas se défendre activement contre les attaques par injection SQL. Bien entendu, cet outil est souvent utilisé par les attaquants. Par exemple, les attaquants peuvent utiliser cet outil pour rechercher automatiquement des cibles d'attaque et mener des attaques. Pour cette raison, si nécessaire, les entreprises devraient investir dans des outils professionnels d’analyse des vulnérabilités. Un scanner de vulnérabilités complet est différent d'un scanner de réseau dans la mesure où il recherche spécifiquement les vulnérabilités d'injection SQL dans la base de données. Les derniers scanners de vulnérabilités recherchent les dernières vulnérabilités découvertes. Par conséquent, des outils professionnels peuvent aider les administrateurs à découvrir les vulnérabilités par injection SQL et rappeler aux administrateurs de prendre des mesures actives pour empêcher les attaques par injection SQL. Si l'administrateur de la base de données découvre les vulnérabilités d'injection SQL que l'attaquant peut trouver et prend des mesures actives pour bloquer les vulnérabilités, l'attaquant n'aura aucun moyen de démarrer.
上面主要是介绍了在web应用程序中对sql注入的大体解决思路,下面我们就根据java web应用程序的特征来具体说明一下如何解决在java web应用程序中的sql注入问题。
1.采用预编译语句集,它内置了处理SQL注入的能力,只要使用它的setXXX方法传值即可。
使用好处:
(1).代码的可读性和可维护性.
(2).PreparedStatement尽最大可能提高性能.
(3).最重要的一点是极大地提高了安全性.
String sql= "select * from users where username=? and password=?; PreparedStatement preState = conn.prepareStatement(sql); preState.setString(1, userName); preState.setString(2, password); ResultSet rs = preState.executeQuery();
原理:sql注入只对sql语句的准备(编译)过程有破坏作用,而PreparedStatement已经准备好了,执行阶段只是把输入串作为数据处理,而不再对sql语句进行解析,准备,因此也就避免了sql注入问题.
2.使用正则表达式过滤传入的参数
正则表达式:
private String CHECKSQL = “^(.+)\\sand\\s(.+)|(.+)\\sor(.+)\\s$”;
判断是否匹配:
Pattern.matches(CHECKSQL,targerStr);
下面是具体的正则表达式:
检测SQL meta-characters的正则表达式 :/(\%27)|(\')|(\-\-)|(\%23)|(#)/ix
修正检测SQL meta-characters的正则表达式 :/((\%3D)|(=))[^\n]*((\%27)|(\')|(\-\-)|(\%3B)|(:))/i
典型的SQL 注入攻击的正则表达式 :/\w*((\%27)|(\'))((\%6F)|o|(\%4F))((\%72)|r|(\%52))/ix
检测SQL注入,UNION查询关键字的正则表达式 :/((\%27)|(\'))union/ix(\%27)|(\')
检测MS SQL Server SQL注入攻击的正则表达式:/exec(\s|\+)+(s|x)p\w+/ix
等等…..
其实可以简单的使用replace方法也可以实现上诉功能:
public static String TransactSQLInjection(String str) { return str.replaceAll(".*([';]+|(--)+).*", " "); }
3.字符串过滤
比较通用的一个方法:(||之间的参数可以根据自己程序的需要添加)
public static boolean sql_inj(String str) { String inj_str = "'|and|exec|insert|select|delete|update| count|*|%|chr|mid|master|truncate|char|declare|;|or|-|+|,"; String inj_stra[] = split(inj_str,"|"); for (int i=0 ; i < inj_stralength ; i++ ) { if (str.indexOf(inj_stra[i])>=0) { return true; } } return false; }
4.jsp中调用该函数检查是否包函非法字符
防止SQL从URL注入:
sql_inj.java代码:
package sql_inj; import java.net.*; import java.io.*; import java.sql.*; import java.text.*; import java.lang.String; public class sql_inj{ public static boolean sql_inj(String str) { String inj_str = "'|and|exec|insert|select|delete|update| count|*|%|chr|mid|master|truncate|char|declare|;|or|-|+|,"; //这里的东西还可以自己添加 String[] inj_stra=inj_strsplit("\\|"); for (int i=0 ; i < inj_stra.length ; i++ ) { if (str.indexOf(inj_stra[i])>=0) { return true; } } return false; } }
5.JSP页面添加客户端判断代码:
使用JavaScript在客户端进行不安全字符屏蔽
功能介绍:检查是否含有”‘”,”\\”,”/”
参数说明:要检查的字符串
返回值:0:是1:不是
函数名是
function check(a) { return 1; fibdn = new Array (”‘” ,”\\”,”/”); i=fibdn.length; j=a.length; for (ii=0; ii<i; ii++) { for (jj=0; jj<j; jj++) { temp1=a.charAt(jj); temp2=fibdn[ii]; if (tem'; p1==temp2) { return 0; } } } return 1; }
关于安全性,本文可总结出一下几点:
1.要对用户输入的内容保持警惕。
2.只在客户端进行输入验证等于没有验证。
3.永远不要把服务器错误信息暴露给用户。
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!