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

本文探讨了SQL注入的原理,指出拼接SQL字符串导致的安全风险,并详细解释了参数化查询如何通过重用执行计划防止注入。通过实例展示了注入攻击过程,强调了参数化查询在保持SQL语义不变性上的关键作用,从而有效避免SQL注入。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

很多人都知道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]

3F3ECD42B7A24B139ECA0A7D584CA195

 

插入一些数据:

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
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值