㈠ SQL注入预编译是绝对安全的么
没错，存储过程的确能有效解决SQL注入式攻击！
理由：因为通常的数据库访问方法，都是把访问数据表的权利赋给程序，注入式攻击者通过你的程序漏洞判断和获得更多的信息，并利用你赋给程序的访问和操作权，轻者破坏本表数据，重者毁坏整个数据库！
使用存储过程则完全不同，程序中不必再有SQL语句，因此程序不必拥有访问和操作数据表的权限，只把运行存储过程的权限交给程序。程序只是把参数和存储过程名告诉数据库，然后等待结果就行了，注入式攻击者要想运行存储过程，就必需猜对存储过程名，并且还要猜对参数个数、参数名和参数的顺序，同时满足这些条件太难了，即便所以条件都满足，那么攻击者也只是往数据表里存了一组合法数据而已，不会导致其它破坏。
因此，通过存储过程能从根本上解决注入式攻击。
需要注意的是，使用存储过程后，应把原来交给程序的操作数据表的权限收回，否则就象为了防小偷锁了前门，却开着后门一样。
㈡ SQL注入的防范 使用预编译语句
预编译语句PreparedStatement是 java.sql中的一个接口，继承自Statement 接口。通过Statement对象执行SQL语句时，需要将SQL语句发送给DBMS，由 DBMS先进行编译后再执行。而预编译语句和Statement不同，在创建PreparedStatement对象时就指定了SQL语句，该语句立即发送给DBMS进行编译，当该编译语句需要被执行时，DBMS直接运行编译后的SQL语句，而不需要像其他SQL语句那样先将其编译。引发SQL注入的根本原因是恶意用户将SQL指令伪装成参数传递到后端数据库执行。作为一种更为安全的动态字符串的构建方法，预编译语句使用参数占位符来替代需要动态传入的参数，这样攻击者无法改变SQL语句的结构，SQL语句的语义不会发生改变，即便用户传入类似于前面' or '1'='1这样的字符串，数据库也会将其作为普通的字符串来处理。
㈢ spring mvc sql注入 问题
这样太容易出现注入问题了，一些关键属性不能进行拼接的，使用SQL预编译的的形式吧，也就是使用？（问号）传进去
㈣ java里面的prepareStatement中的“预编译”的概念的理解
开始执行的时候放入内存··
还有一个好处就是 防止sql注入··
预编译的sql语句比普通的sql语句要安全很多··
㈤ 在java中如何实现预编译
/*
* ProCompile.java *预处理要编译的文件，删除多余的空白，注释，换行，回车等
* Created on 2007年9月18日, 下午8:58 */ package javacompile; import java.io.*;
import java.util.regex.*;
import javax.swing.JOptionPane; /** * @com.junjian.sun public class PerCompile { File f = null;
String fileString = null;
Pattern p = null;
Matcher m = null;
String regex; //正则表达式 //初始化p
public PerCompile() {
regex ="(//.+)" + //(//.+) 对应单行注释
//"|(/\\*(.+\\n)+\\*/)"+ // 想对应多行注释... "|(\\r\\n)" + "|(\\n)"+//(\\r\\n)|(\\n)对应换行
"|(\\B\\s+)" ; // 空白符
String ss;
f = new File(new JOptionPane()
.showInputDialog("请输入文件所在路径~"));
try {
BufferedReader bf = new BufferedReader(new FileReader(f));
ss = bf.readLine()+"\n";
fileString = ss; //如果没有这两句，ss的开头会有“null”
while((ss = bf.readLine())!= null){
fileString += ss+"\n"; bf.close();
} catch (IOException ex) {
ex.printStackTrace(); p = Pattern.compile(regex);
m = p.matcher(fileString); //执行替换所有多余空行，空白符，注释
void Dels(){
System.out.println("before: "+fileString);
if(m.find()) System.out.println("find!!");
System.out.println(m.replaceAll("")); } }
-
㈥ 什么是sql注入如何防止sql注入
SQL注入是一种非常常见的数据库攻击手段，同时也是网络世界中最普遍的漏洞之一，简单理解就是恶意用户通过在表单中填写包含SQL关键字的数据来使数据库执行非常规代码的过程。
问题来源是，SQL数据库的操作是通过SQL语句来执行的，而无论是执行代码还是数据项都必须写在SQL语句中，也就导致如果我们在数据项中加入了某些SQL语句关键字，比如SELECT、DROP等，这些关键字就很有可能在数据库写入或读取数据时得到执行。
解决方案
方案一：
采用预编译技术
使用预编译的SQL语句，SQL语句的语义不会是不会发生改变的。预编译语句在创建的时候就已经将指定的SQL语句发送给了DBMS，完成了解析，检查，编译等工作，所以攻击者无法改变SQL语句的结构，只是把值赋给?，然后将?这个变量传给SQL语句。当然还有一些通过预编译绕过某些安全防护的操作，大家感兴趣可以去搜索一下。
方案二：
严格控制数据类型
在java、c等强类型语言中一般是不存在数字型注入的，因为在接受到用户输入id时，代码一般会做一个int id 的数据类型转换，假如我们输入的是字符串的话，那么这种情况下，程序就会报错。但是在php、ASP这些没有强调处理数据类型的语言，一般我们看到的接收id的代码都是如下等代码。
方案三：
对特殊的字符进行转义
数字型注入可以通过检查数据类型防止，但是字符型不可以，那么怎么办呢，最好的办法就是对特殊的字符进行转义了。比如在MySQL中我们可以对" '
"进行转义，这样就防止了一些恶意攻击者来闭合语句。当然我们也可以通过一些安全函数来转义特殊字符。如addslashes()等，但是这些函数并非一劳永逸，攻击者还可以通过一些特殊的方式绕过。
㈦ 用预编译的方式查询是不是能够杜绝SQL注入
是的，预编译有个类是PreparedStatement.
这个类的对象是通过参数？来传值的
例：
String sql = "select * from table where id = ?";
Connection con = .....///这里得到是数据库的连接
PreparedStatement ps = con.prepareStatement(sql);
ps.setInt(1,id);//这里的数据库语句所用到的参数要被设置的，如果你传入了错的值，或不同类型的值，它在插入到数据库语句中会编译不通过，这也就防止了SQL注入。
㈧ mybatis中的$的sql注入该怎么解决
#{ } 解析为一个 JDBC 预编译语句（prepared statement）的参数标记符。
例如，sqlMap 中如下的 sql 语句
select * from user where name = #{name};
解析为：
select * from user where name = ?;
一个 #{ } 被解析为一个参数占位符 ? 。
${ } 仅仅为一个纯碎的 string 替换，在动态 SQL 解析阶段将会进行变量替换
例如，sqlMap 中如下的 sql
select * from user where name = '${name}';
当我们传递的参数为 "ruhua" 时，上述 sql 的解析为：
select * from user where name = "ruhua";
预编译之前的 SQL 语句已经不包含变量 name 了。
综上所得， ${ } 的变量的替换阶段是在动态 SQL 解析阶段，而 #{ }的变量的替换是在 DBMS 中。
注意：${ } 在预编译之前已经被变量替换了，这会存在 sql 注入问题。
㈨ 有人遇到过项目中已经使用了hibernate,可是测试的时候依然会被sql注入,请问是怎么回事呢
需要提供具体调用的代码，否则无法判断。
再强大的框架，也不能完全杜绝漏洞，因为框架既要考虑安全性，也要考虑灵活性，数据库的封闭框架，如果严格按照既有的方法生成查询或写入语句，一般是不会有注入漏洞的。但个别地方可能需要灵活拼装查询或更新语句，传入了自拼装的代码，就很可能导致漏洞产生
㈩ php 使用mysql 的prepare预编译,下面这段代码有防sql注入的功能么请高手赐教
sql注入怎么回事:说白了就是在一个单引号上做文章,你把单引号转义就没啥问题了,预编译就是把这些字符转义后插入,其中包括单引号。
这段可以防止.