1. 为什么不用字符串拼接可以防止sql注入
sql
=
"select
*
from"
&
mc
'怎么拼对吗？
这个是正确的。
set
rs
=
conn.execute("select
*
from
&
mc")
‘怎么拼接对吗？
这个是不对的。这个里面的sql语句建议赋值给一个变量，然后直接调用变量，当然也可以这么写，不过要注意格式：set
rs
=
conn.execute("select
*
from
"&
mc)应该是这个样子的，不知道有没有记错，你试试看。
2. 关于搜索框sql注入的问题，限制搜索框中只能输入数字是不是能防止sql注入
这是一种前端js校验的安全机制，在某种程度上是可以防止SQL注入的攻击。正所谓一切的输入都是罪恶的源泉，所以从输入源头尽量去规避一些风险是必要的。
但是在后端的程序中，也尽量使用成熟的框架，按照标准的开发规则去写代码，比如：不要使用${userName}这样的方式变量出现在访问数据库的SQL语句中。
3. 在SQL数据库中对插入的数据加入约束能防止SQL注入吗
SQL注入
的存在形式比较多,一般是从语句的语法格式上作文章.
数据约束可能能防止部分SQL注入,但不可能防止所有SQL注入.
4. 为什么参数化SQL查询可以防止SQL注入
参数化查询主要做了这些事情：
1：参数过滤
2：执行计划重用
因为参数化查询可以重用执行计划，并且如果重用执行计划的话，SQL所要表达的语义就不会变化，所以就可以防止SQL注入,如果不能重用执行计划，就有可能出现SQL注入，存储过程也是一样的道理，因为可以重用执行计划。
5. 通过加密解密数据可以防止sql注入吗
不是这样的吧，能够被sql注入是因为程序员编写代码的问题，未作相关的约束等造成的，通过加密解密数据只能是在传输的过程中防止信息的泄露、篡改等问题。
6. 如何能防止sql注入
如何能防止sql注入
普通用户与系统管理员用户的权限要有严格的区分。
如果一个普通用户在使用查询语句中嵌入另一个Drop Table语句，那么是否允许执行呢?由于Drop语句关系到数据库的基本对象，故要操作这个语句用户必须有相关的权限。在权限设计中，对于终端用户，即应用软件的使用者，没有必要给他们数据库对象的建立、删除等权限。那么即使在他们使用SQL语句中带有嵌入式的恶意代码，由于其用户权限的限制，这些代码也将无法被执行。故应用程序在设计的时候，
强迫使用参数化语句。
如果在编写SQL语句的时候，用户输入的变量不是直接嵌入到SQL语句。而是通过参数来传递这个变量的话，那么就可以有效的防治SQL注入式攻击。也就是说，用户的输入绝对不能够直接被嵌入到SQL语句中。与此相反，用户的输入的内容必须进行过滤，或者使用参数化的语句来传递用户输入的变量。参数化的语句使用参数而不是将用户输入变量嵌入到SQL语句中。采用这种措施，可以杜绝大部分的SQL注入式攻击。不过可惜的是，现在支持参数化语句的数据库引擎并不多。不过数据库工程师在开发产品的时候要尽量采用参数化语句。
多多使用SQL Server数据库自带的安全参数。
为了减少注入式攻击对于SQL Server数据库的不良影响，在SQLServer数据库专门设计了相对安全的SQL参数。在数据库设计过程中，工程师要尽量采用这些参数来杜绝恶意的SQL注入式攻击。
如在SQL Server数据库中提供了Parameters集合。这个集合提供了类型检查和长度验证的功能。如果管理员采用了Parameters这个集合的话，则用户输入的内容将被视为字符值而不是可执行代码。即使用户输入的内容中含有可执行代码，则数据库也会过滤掉。因为此时数据库只把它当作普通的字符来处理。使用Parameters集合的另外一个优点是可以强制执行类型和长度检查，范围以外的值将触发异常。如果用户输入的值不符合指定的类型与长度约束，就会发生异常，并报告给管理员。如上面这个案例中，如果员工编号定义的数据类型为字符串型，长度为10个字符。而用户输入的内容虽然也是字符类型的数据，但是其长度达到了20个字符。则此时就会引发异常，因为用户输入的内容长度超过了数据库字段长度的限制。
加强对用户输入的验证。
总体来说，防治SQL注入式攻击可以采用两种方法，一是加强对用户输入内容的检查与验证;二是强迫使用参数化语句来传递用户输入的内容。在SQLServer数据库中，有比较多的用户输入内容验证工具，可以帮助管理员来对付SQL注入式攻击。测试字符串变量的内容，只接受所需的值。拒绝包含二进制数据、转义序列和注释字符的输入内容。这有助于防止脚本注入，防止某些缓冲区溢出攻击。测试用户输入内容的大小和数据类型，强制执行适当的限制与转换。这即有助于防止有意造成的缓冲区溢出，对于防治注入式攻击有比较明显的效果。
如可以使用存储过程来验证用户的输入。利用存储过程可以实现对用户输入变量的过滤，如拒绝一些特殊的符号。如以上那个恶意代码中，只要存储过程把那个分号过滤掉，那么这个恶意代码也就没有用武之地了。在执行SQL语句之前，可以通过数据库的存储过程，来拒绝接纳一些特殊的符号。在不影响数据库应用的前提下，应该让数据库拒绝包含以下字符的输入。如分号分隔符，它是SQL注入式攻击的主要帮凶。如注释分隔符。注释只有在数据设计的时候用的到。一般用户的查询语句中没有必要注释的内容，故可以直接把他拒绝掉，通常情况下这么做不会发生意外损失。把以上这些特殊符号拒绝掉，那么即使在SQL语句中嵌入了恶意代码，他们也将毫无作为。
故始终通过测试类型、长度、格式和范围来验证用户输入，过滤用户输入的内容。这是防止SQL注入式攻击的常见并且行之有效的措施。
多层环境如何防治SQL注入式攻击?
在多层应用环境中，用户输入的所有数据都应该在验证之后才能被允许进入到可信区域。未通过验证过程的数据应被数据库拒绝，并向上一层返回一个错误信息。实现多层验证。对无目的的恶意用户采取的预防措施，对坚定的攻击者可能无效。更好的做法是在用户界面和所有跨信任边界的后续点上验证输入。如在客户端应用程序中验证数据可以防止简单的脚本注入。但是，如果下一层认为其输入已通过验证，则任何可以绕过客户端的恶意用户就可以不受限制地访问系统。故对于多层应用环境，在防止注入式攻击的时候，需要各层一起努力，在客户端与数据库端都要采用相应的措施来防治SQL语句的注入式攻击。
7. 如何彻底防止SQL注入
1、对，限制用户输入肯定有效
2、应该也可以做到，但正则不是一种高效的方法，用HtmlEncode的方法可以有效防止空格等被DBMS解释，但注意别把编码、解码搞反了；存储过程是DBMS执行的一段程序，把数据操纵交给存储过程执行，而不是提交SQL语句，可以有效防止SQL注入。
3、地址栏的Sql攻击，下面我引用了一段资料解释，他关于机制说的较清楚，关于解决，只是从客户端考虑的，实际上用存储过程等都可以防范。
资料：
首先，入侵者会对一个网站确定可不可以进行注入，假设一篇文章的地址为：http://www.naohou.cn/show.asp?id=325一般会以提交两个地址来测试，如：
http://www.naohou.cn/show.asp?id=325 and 1=1
http://www.naohou.cn/show.asp?id=325 and 1=2
第一个地址后面加了 and 1=1，构成的SQL语句也就变为了：Select * from 表单名 where id=1 and 1=1这句话要成立就必须and前后语句都成立。那么前面的文章地址是可以访问的，后面的1=1也是客观成立的，那么第一个地址就可以正常显示；相反1=2是显然不成立的，关键就看这步了，如果提交and 1=2页面还是正常显示说明他并没有将and 1=2写入SQL语句，此站也就不存在注入漏洞；但如果提交and 1=2之后返回了错误页面则说明此站点将后面的语句带入了SQL语句并执行了，也就说明他可以进行SQL注入。（注：如果地址后面跟的是news.asp?id='1'就得变为news.asp?id=1' and '1'='1来补全引号了）
那么，知道可以注入后入侵者可以做什么呢？
这里就简单的说一下，比如提交这样的地址：
http://www.naohou.cn/show.asp?id=325 and exists (select * from 表名 where 列名=数据)
根据返回的正确或错误页面来判断猜的表名和列名是否正确，具体实现时是先猜表名再猜列名。当猜出表名和列名之后还可以用ASC和MID函数来猜出各列的数据。MID函数的格式为：mid(变量名,第几个字符开始读取,读取几个字符)，比如：mid(pwd,1,2)就可以从变量pwd中的第一位开始读取两位的字符。ASC函数的格式为：ASC（"字符串"），如：asc("a")就可以读出字母a的ASCII码了。那么实际应用的时候就可以写为：asc(mid(pwd,1,1))这样读取的就是pwd列的第一个字符的ASCII码，提交： asc(mid(pwd,1,1))>97以返回的页面是否为正确页面来判断pwd列的第一个字符的ASCII码是否大于97（a的ASCII码），如果正确就再试是否小于122（z的ASCII码）……这样慢慢缩小字符的ASCII码的范围，猜到真实的ASCII码也只是时间的问题。一位一位的猜就可以得到数据库中的用户名和密码了。还有一种ASP验证缺陷——就是用户名和密码都输'or '1'='1，构造SQL语句Select * form 表单名 where username='' or '1'='1' and pwd='' or '1'='1'就可以达到绕过密码验证的目的。
说了那么多，其实防范的方法很简单，我们把特殊字符（如and、or、'、"）都禁止提交就可以防止注入了。ASP传输数据分为get和post两种， get是通过将数据添加到URL后提交的方式，post则是利用邮寄信息数据字段将数据传送到服务器。
8. 将参数中的空格全部替换掉，可以防止sql注入吗
果所有关键字都过滤，确实可以。既然没有关键字，那么传入的参数只是个字符串，没有其他的效果了。
但是，这是不可能的，有些时候你不得不用到一些关键字，比如密码[这里面肯定会含有特殊字符的]
建议：采用参数化的赋值方式
我们实际做的是尽可能避免参数注入
9. 如何防止sql注入
JAVA中采用预编译语句，C#用特殊字符过滤或者存储过程传入参数，主要目的是防止SQL拼接
10. 用PreparedStatement是否就可以防止SQL注入了
是的，注入漏洞是由于在参数值改变了sql的执行逻辑，例如
//username正常情况下应该是一个用户名只包含数字或者英文字母，
//但是当用户填写的是下面的串的时候，注入漏洞就发生了
String username=" a' or 1=1 ";
String pssword="xxx";
String sql="select * from users where password='"+password+"' and user_name = ' "+username;
此时不管密码的什么都能查询到数据。相当于绕过验证了。
PreparedStatement的参数注入功能会把参数里的特殊字符进入转义，单引号这样的是会被转义的，所以sql的逻辑不会因为参数值发生改变，注入漏洞就不可能发生了