Ⅰ 参数化查询为什么能够防止sql注入
因为参数化查询限制了条件的数据类型，可以有效的防止恶意的字符串拼接
Ⅱ 参数化查询为什么能够防止SQL注入
很多人都知道SQL注入，也知道SQL参数化查询可以防止SQL注入，可为什么能防止注入却并不是很多人都知道的。
本文主要讲述的是这个问题，也许你在部分文章中看到过这块内容，当然了看看也无妨。
首先：我们要了解SQL收到一个指令后所做的事情：
具体细节可以查看文章：Sql Server 编译、重编译与执行计划重用原理
在这里，我简单的表示为： 收到指令 -> 编译SQL生成执行计划 ->选择执行计划 ->执行执行计划。
http://www.cnblogs.com/LoveJenny/archive/2013/01/15/2860553.html
详细可以参考这个，有图解教程，希望可以帮到你
Ⅲ 为什么参数化查询可以防止SQL注入
首先：我们要了解SQL收到一个指令后所做的事情：
具体细节可以查看文章：Sql Server 编译、重编译与执行计划重用原理
在这里，我简单的表示为： 收到指令 -> 编译SQL生成执行计划 ->选择执行计划 ->执行执行计划。
具体可能有点不一样，但大致的步骤如上所示。
接着我们来分析为什么拼接SQL 字符串会导致SQL注入的风险呢？
首先创建一张表Users:
CREATE TABLE [dbo].[Users](
[Id] [uniqueidentifier] NOT NULL,
[UserId] [int] NOT NULL,
[UserName] [varchar](50) NULL,
[Password] [varchar](50) NOT NULL,
CONSTRAINT [PK_Users] PRIMARY KEY CLUSTERED
(
[Id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
插入一些数据：
INSERT INTO [Test].[dbo].[Users]([Id],[UserId],[UserName],[Password])VALUES (NEWID(),1,'name1','pwd1');
INSERT INTO [Test].[dbo].[Users]([Id],[UserId],[UserName],[Password])VALUES (NEWID(),2,'name2','pwd2');
INSERT INTO [Test].[dbo].[Users]([Id],[UserId],[UserName],[Password])VALUES (NEWID(),3,'name3','pwd3');
INSERT INTO [Test].[dbo].[Users]([Id],[UserId],[UserName],[Password])VALUES (NEWID(),4,'name4','pwd4');
INSERT INTO [Test].[dbo].[Users]([Id],[UserId],[UserName],[Password])VALUES (NEWID(),5,'name5','pwd5');
假设我们有个用户登录的页面，代码如下：
验证用户登录的sql 如下：
select COUNT(*) from Users where Password = 'a' and UserName = 'b'
这段代码返回Password 和UserName都匹配的用户数量，如果大于1的话，那么就代表用户存在。
本文不讨论SQL 中的密码策略，也不讨论代码规范，主要是讲为什么能够防止SQL注入，请一些同学不要纠结与某些代码，或者和SQL注入无关的主题。
可以看到执行结果：
这个是SQL profile 跟踪的SQL 语句。
注入的代码如下：
select COUNT(*) from Users where Password = 'a' and UserName = 'b' or 1=1—'
这里有人将UserName设置为了 “b' or 1=1 –”.
实际执行的SQL就变成了如下：
可以很明显的看到SQL注入成功了。
很多人都知道参数化查询可以避免上面出现的注入问题，比如下面的代码：
class Program
{
private static string connectionString = "Data Source=.;Initial Catalog=Test;Integrated Security=True";
static void Main(string[] args)
{
Login("b", "a");
Login("b' or 1=1--", "a");
}
private static void Login(string userName, string password)
{
using (SqlConnection conn = new SqlConnection(connectionString))
{
conn.Open();
SqlCommand comm = new SqlCommand();
comm.Connection = conn;
//为每一条数据添加一个参数
comm.CommandText = "select COUNT(*) from Users where Password = @Password and UserName = @UserName";
comm.Parameters.AddRange(
new SqlParameter[]{
new SqlParameter("@Password", SqlDbType.VarChar) { Value = password},
new SqlParameter("@UserName", SqlDbType.VarChar) { Value = userName},
});
comm.ExecuteNonQuery();
}
}
}
实际执行的SQL 如下所示：
exec sp_executesql N'select COUNT(*) from Users where Password = @Password and UserName = @UserName',N'@Password varchar(1),@UserName varchar(1)',@Password='a',@UserName='b'
exec sp_executesql N'select COUNT(*) from Users where Password = @Password and UserName = @UserName',N'@Password varchar(1),@UserName varchar(11)',@Password='a',@UserName='b'' or 1=1—'
可以看到参数化查询主要做了这些事情：
1：参数过滤，可以看到 @UserName='b'' or 1=1—'
2：执行计划重用
因为执行计划被重用，所以可以防止SQL注入。
首先分析SQL注入的本质，
用户写了一段SQL 用来表示查找密码是a的，用户名是b的所有用户的数量。
通过注入SQL，这段SQL现在表示的含义是查找(密码是a的，并且用户名是b的，) 或者1=1 的所有用户的数量。
可以看到SQL的语意发生了改变，为什么发生了改变呢？，因为没有重用以前的执行计划，因为对注入后的SQL语句重新进行了编译，因为重新执行了语法解析。所以要保证SQL语义不变，即我想要表达SQL就是我想表达的意思，不是别的注入后的意思，就应该重用执行计划。
如果不能够重用执行计划，那么就有SQL注入的风险，因为SQL的语意有可能会变化，所表达的查询就可能变化。
在SQL Server 中查询执行计划可以使用下面的脚本：
DBCC FreeProccache
select total_elapsed_time / execution_count 平均时间,total_logical_reads/execution_count 逻辑读,
usecounts 重用次数,SUBSTRING(d.text, (statement_start_offset/2) + 1,
((CASE statement_end_offset
WHEN -1 THEN DATALENGTH(text)
ELSE statement_end_offset END
- statement_start_offset)/2) + 1) 语句执行 from sys.dm_exec_cached_plans a
cross apply sys.dm_exec_query_plan(a.plan_handle) c
,sys.dm_exec_query_stats b
cross apply sys.dm_exec_sql_text(b.sql_handle) d
--where a.plan_handle=b.plan_handle and total_logical_reads/execution_count>4000
ORDER BY total_elapsed_time / execution_count DESC;
Ⅳ 参数化查询为什么能够防止sql注入
简单来说，参数里的内容都会被当作文本来处，而不是SQL语句中一部分。
Ⅳ mybatis 为什么可以防止sql注入
因为在mybatis中，”${xxx}”这样格式的参数会直接参与sql编译，从而不能避免注入攻击。但涉及到动态表名和列名时，只能使用“${xxx}”这样的参数格式，所以，这样的参数需要程序开发者在代码中手工进行处理来防止注入。
#xxx# 代表xxx是属性值,map里面的key或者是你的pojo对象里面的属性, ibatis会自动在它的外面加上引号,表现在sql语句是这样的 where xxx = 'xxx' ;
$xxx$ 则是把xxx作为字符串拼接到sql语句中, 比如 order by topicId , 语句这样写 ... order by #xxx# ibatis 就会翻译成order by 'topicId' （这样就会报错） 语句这样写 ... order by $xxx$ ibatis 就会翻译成 order by topicId
#将传入的数据都当成一个字符串，会对自动传入的数据加一个双引号。如：order by #user_id#，如果传入的值是111,那么解析成sql时的值为order by "111", 如果传入的值是id，则解析成的sql为order by "id".2. $将传入的数据直接显示生成在sql中。如：order by $user_id$，如果传入的值是111,那么解析成sql时的值为order by user_id, 如果传入的值是id，则解析成的sql为order by id
所以说#方式能够很大程度防止sql注入。
Ⅵ 参数化查询为什么能够防止SQL注入
如果使用.net，那就简单了，可以用ADO.NET的参数化查询。
例如:
SqlCommand cmd=new SqlCommand("SELECT * FROM test WHERE id=@id",conn);
cmd.Parameters.AddWithValue("@id",sid);
cmd.ExecuteNonQuery();
这个有很多种用法，详细的内容需要对离线数据库的概念进行理解
Ⅶ 参数化查询为什么能够防止SQL注入
比如一个请求带参数，我们不使用参数化查询，那么他在url后面接上 or 1=1那么所有的记录都会出现，这么数据库就不安全。
参数化查询可以防止这种注入，绑定sql语句的对应列的值，不会出现上面这种情况。
Ⅷ c# 传参的方式能完全防止sql注入吗
参数化sql语句完全能够防止sql注入，我说得是完全。不必再过滤什么了。
参数化sql是直接生成sql数据库查询底层的参数，而不是通过编译器和解释器根据sql语句自动分词，确定参数的值（这样容易被骗）。
比如：select 姓名 from 基本信息 where 学号='18'，客户构造sql语句：select 学号 from 基本信息 where 学号='' or '1'='1'，sql数据库系统编译解释为：
1.这是一条select语句；
2。操作的表为“基本信息”；
3。返回字段为“姓名”；
4。条件为学号='' or '1'='1'
5。学号的参数为''。
这样就被骗了。
而采用参数化方法，select 学号 from 基本信息 where 学号=@studentID，参数@studentID=' or '1'='
最后编译解释为select 学号 from 基本信息 where 学号="' or '1'='"
相当于在参数@studentID的值的外面加上了一个看不见的""，所以无论对方构造的如何巧妙，都无法注入。