当前位置:首页 » 编程语言 » sql参数化插入不怕转移吗
扩展阅读
webinf下怎么引入js 2023-08-31 21:54:13
堡垒机怎么打开web 2023-08-31 21:54:11

sql参数化插入不怕转移吗

发布时间: 2022-11-02 10:28:05

Ⅰ 参数化查询为什么能够防止sql注入

参数化查询可以重用执行计划,并且如果重用执行计划的话,SQL所要表达的语义就不会变化,所以就可以防止SQL注入,如果不能重用执行计划,就有可能出现SQL注入,存储过程也是一样的道理,因为可以重用执行计划。参考文档:http://www.cnblogs.com/LoveJenny/archive/2013/01/15/2860553.html

Ⅱ 为什么参数化查询sql能够防止sql注入

因为sql语句在后端早就生成了,需要哪几个参数值都是预设好的,前端只能传入符合条件的参数;如果请求的参数不合法,程序不会执行。

Ⅲ ado.net使用参数化的sql语句为什么可以防止sql注入攻击

参数化数据库操作就是可以防止sql注入的,它将所有传递过来的参数仅作为参数使用,若参数中含有关键字也不会被执行

Ⅳ 参数化查询为什么能够防止SQL注入

比如一个请求带参数,我们不使用参数化查询,那么他在url后面接上 or 1=1那么所有的记录都会出现,这么数据库就不安全。

参数化查询可以防止这种注入,绑定sql语句的对应列的值,不会出现上面这种情况。

Ⅳ sql为什么要参数化,怎么参数化

一、最主要是: 数据库 机制问题,参数化 可以加快 执行效率,数据库有个缓存区,可以缓存 非参数部分的语句(或者说 下次执行不用数据库再次 解析语句),而不用参数,每次数据库 都需要解析 语句
二、次要是:防止,sql语句特殊字,注入:减少,字符转义等
三、清晰 便于理解

Ⅵ 为什么参数化查询可以防止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语句时参数化,有什么好处

防注入。
比如你登录的语句写成:
string sql="select uid from login where uid='"+uid+"' and pwd='"+pwd+"'";
那只需要把密码写成'or'0'='0就可以登录了

Ⅷ 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的值的外面加上了一个看不见的"",所以无论对方构造的如何巧妙,都无法注入。

Ⅸ 参数化查询为什么可以避免sql注入

因为参数化查询时,参数与SQL语句是分开提供的,攻击者构造的参数不会被拼接入SQL字符串,也就无法实现SQL注入攻击了