笔者前日无聊，看到公司附近某个服务行业机构的网站，asp语言，搭建于iis服务器中。一开始笔者并没有留意到这网站有sql注入漏洞，随手在某个news.asp?id=52的url上输入了一个单引号，随后服务器报500错误，并给出了出错的sql信息（汗，服务器相关的出错信息一定不要泄漏出来，不过貌似我以前做的站好像也没注意异常的问题），该页面获取id参数的时候应该有强制int，所以在当前页面构造了几次请求都没有发现注入点，笔者不服气的犟驴劲顿时出来了。
苦寻无果，笔者注册了该网站的会员，并登陆之，看有没有新的注入口。笔者登陆之后抓包发现cookie中明文存放了会员信息，如会员登录名，于是笔者改了一下该cookie，也是简单加了个单引号，结果。。。服务器也500了，并且给出了出错的信息。但这次的出错信息有所不同，出错信息里显示程序里直接使用了cookie，没有做任何过滤，就像
select * from xxx where username=’$_Cookie['username']‘
这样。。。然后，注入点出现了。
于是笔者给网站管理员发了封邮件，告知网站会员系统有sql注入漏洞，希望网站在服务功能正式上线之前把它修复。
笔者下班之后，好奇害死猫，继续看怎么破之。
（1）笔者先猜他的后台管理系统登陆地址为 www.xxx.com/admin，果不其然，猜对了。
（2）笔者再猜他的管理员登陆表叫admin，注入了sql ‘exists(select * from admin)’,结果页面200，也猜对了。
（3）笔者猜他的管理员表admin里应该有一个字段名username,一个字段名password，结果一直500，没猜对
（4）于是笔者去看了下登录页面的html源码，希望从里面发现线索。笔者第一步看的是登陆表单，发现登陆表单名为admin，登陆密码表单名为UserPassword，于是笔者根据前面页面的报错信息猜测这个程序猿有把参数名和数据库设计映射一致的习惯，于是再猜测admin表里有个字段是admin，有个字段名是UserPassword…果然，笔者注入了sql ‘(select top 1 [admin] from admin)>0′,也成功了，相应的UserPassword也存在。。。额，这。。。
（5）笔者开始猜后台登陆用户名和密码的长度，继续注入了 sql ‘(select top 1 len(admin) from admin)=N’，使N一直递增，发现其网站第一个登陆用户名长度为5，密码长度为16.
（6）拿到了字段名，长度，接下来，笔者猜测这两者应该是字母，数字组合。笔者依次注入 sql ‘(select top 1 asc(mid(admin,N,1)))=M’，对于用户名N->[1,5],M->[0,128],密码N->[1,16],M->[0,128]，依次拿出了用户名和密码每一位的ascii码。。。结果发现用户名是 admin，密码是加密的16位字符串
（7）笔者猜测这是md5加密的密码，于是笔者找了个网站反向解密了这个字符串，得到xxxxxxxxxx
（8）笔者跑到网站登陆页面www.xxxx.com/admin，输入破解的用户名和密码，结果。。。登陆进去了他们的后台！！！
走完这几步，已经基本完成了入侵的过程了，不过笔者没有打算再深入下去，直接关机睡觉了。
写这篇文章不是为了教大家如何去入侵一个网站，而是，通过入侵的思路，来总结一下网站系统安全建设中常见的坑，在工作中可以适当去避免。
（1）异常信息，要记得try catch，然后对外屏蔽
（2）表单之类的信息，不要跟数据库字段有强关联，最好能做一个映射
（3）不要相信来自客户端的任何输入，包括表单、url参数、cookie，需要用到时，一定要进行安全过滤
（4）如果要用cookie，不要在重要路径依赖cookie，实在没办法，请加密你的cookie
（5）如果网站有后台，不要轻易暴露入口，不要用常用的名入口命名，不要在表单里暴露太多信息
（6）即使是非系统级别的错误提示，也不要给用户太详细的信息。
（7）如果有密码，可以在加密串中加入其他信息，对反向解密加干扰～
那要如何防注入呢
一，利用asp防注入
在 Asp 中彻底封死注入的方法：
1、数字型：
| 代码如下 | 复制代码 |
|
Dim Tmp Tmp = Request("test") IF Len(Tmp) > 9 then Response.Write "fuck you!" Response.End ElseIF IsNumber(Tmp) = False Then Response.Write "fuck you!" Response.End ElseIF Instr(Tmp, "+") > 0 Then Response.Write "fuck you!" Response.End ElseIF Instr(Tmp, "-") > 0 Then Response.Write "fuck you!" Response.End ElseIF Instr(Tmp, ".") > 0 Then Response.Write "fuck you!" Response.End Else Response.Write "ok!" End IF |
|
2、字符型：
| 代码如下 | 复制代码 |
|
Dim Tmp, I Tmp = Request("test") Tmp = Replace(Tmp, "'", "'") Tmp = Replace(Tmp, """", """") Tmp = Replace(Tmp, chr(10), "") Tmp = Replace(Tmp, chr(13), "") Response.Write "ok!" |
|
一，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) private static void Login(string userName, string password) 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 逻辑读,
|
|
这里作者有一句话：”不过这种写法和直接拼SQL执行没啥实质性的区别”
任何拼接SQL的方式都有SQL注入的风险，所以如果没有实质性的区别的话，那么使用exec 动态执行SQL是不能防止SQL注入的。
比如下面的代码：
| 代码如下 | 复制代码 |
|
private static void TestMethod() { using (SqlConnection conn = new SqlConnection(connectionString)) { conn.Open(); SqlCommand comm = new SqlCommand(); comm.Connection = conn; //使用exec动态执行SQL //实际执行的查询计划为(@UserID varchar(max))select * from Users(nolock) where UserID in (1,2,3,4) //不是预期的(@UserID varchar(max))exec('select * from Users(nolock) where UserID in ('+@UserID+')') comm.CommandText = "exec('select * from Users(nolock) where UserID in ('+@UserID+')')"; comm.Parameters.Add(new SqlParameter("@UserID", SqlDbType.VarChar, -1) { Value = "1,2,3,4" }); //comm.Parameters.Add(new SqlParameter("@UserID", SqlDbType.VarChar, -1) { Value = "1,2,3,4); delete from Users;--" }); comm.ExecuteNonQuery(); } } |
|
执行的SQL 如下：
| 代码如下 | 复制代码 |
|
exec sp_executesql N'exec(''select * from Users(nolock) where UserID in (''+@UserID+'')'')',N'@UserID varchar(max) ',@UserID='1,2,3,4' 可以看到SQL语句并没有参数化查询。 如果你将UserID设置为”1,2,3,4); delete from Users;—- ”,那么执行的SQL就是下面这样：exec sp_executesql N'exec(''select * from Users(nolock) where UserID in (''+@UserID+'')'')',N'@UserID varchar(max) ',@UserID='1,2,3,4); delete from Users;--' |
|
不要以为加了个@UserID 就代表能够防止SQL注入，实际执行的SQL 如下：
任何动态的执行SQL 都有注入的风险，因为动态意味着不重用执行计划，而如果不重用执行计划的话，那么就基本上无法保证你写的SQL所表示的意思就是你要表达的意思。 这就好像小时候的填空题，查找密码是(____) 并且用户名是(____)的用户。不管你填的是什么值，我所表达的就是这个意思。 最后再总结一句：因为参数化查询可以重用执行计划，并且如果重用执行计划的话，SQL所要表达的语义就不会变化，所以就可以防止SQL注入,如果不能重用执行计划，就有可能出现SQL注入，存储过程也是一样的道理，因为可以重用执行计划。