NET里面怎样防止SQL注入
发布网友
发布时间：2022-04-30 09:53
共3个回答
懂视网
时间：2022-04-30 14:15
1 DROP TABLE dbo.Person 2 CREATE TABLE Person(ID INT IDENTITY,NAME CHAR(5) DEFAULT ‘aaaaa‘) 3 INSERT INTO dbo.Person DEFAULT VALUES 4 go 1000 5 6 DBCC freeproccache 7 SELECT * FROM dbo.Person WHERE ID=100
<2> 数据已经查询出来了，下面我们看下dm_exec_sql_text中的sql会是怎样？
1 SELECT usecounts,objtype,cacheobjtype, plan_handle,query_plan,text FROM sys.dm_exec_cached_plans 2 CROSS APPLY sys.dm_exec_query_plan(plan_handle) 3 CROSS APPLY sys.dm_exec_sql_text(plan_handle) 4 WHERE text LIKE ‘%Person%‘
从上面的图中可以看到，当我select一下后，出现了两个sql text，第一个叫Adhoc（即时查询），一个叫Prepared（参数化），然后我点击第二个记录
的query_plan，会出现图形化的执行计划，如下图：
跟着好奇心，我继续点击第三个记录的query_plan会是怎样？？？
通过这两个sql text的执行计划，不知道你观察出来下面四点了没有：
（1） 我的sql是执行表扫描的，这个没有问题，问题在于我的两个sql text中，第一个plan居然没有完整的执行计划，而仅仅是一个图形化的select，
第二个参数化sql，它的plan是一个完整的执行计划。。。那这说明什么呢？？？既然Prepared是完整的执行计划，那干嘛还要把adhoc这个
sql缓存起来呢？？？其实这个我也不清楚。。。我猜测肯定是让引擎快速的找到prepared这个完整的执行计划吧。。。
（2） 就是想为什么sqltext要做参数化，仔细想想应该明白参数化的目的就是为了重用执行计划，因为这时候的xml已经生成好了，不然的话，你
每次执行的sql中只要参数不同都要生成一次query_plan的xml，是不是会拉查询速度的后腿呢？？？
(3) 你有没有关注到参数化的类型是tinyint，看到这个tinyint我马上就想破它了，我们知道tinyint就是byte类型，表示的范围也就到256...也许
引擎看我where 100才觉得我好欺负。。。那我现在想法就是where 500，看看会是什么效果？？？
1 SELECT * FROM dbo.Person WHERE ID=500 2 3 SELECT usecounts,objtype,cacheobjtype, plan_handle,query_plan,text FROM sys.dm_exec_cached_plans 4 CROSS APPLY sys.dm_exec_query_plan(plan_handle) 5 CROSS APPLY sys.dm_exec_sql_text(plan_handle) 6 WHERE text LIKE ‘%Person%‘
从图中可以看到，当我where 500的时候，引擎会再次生成一个prepared的sqltext，这样就有两个prepared了，那我在想，为什么不直接
给一个(@1 int)呢？？？像目前这样sql引擎的处理方式，会有几条prepared记录的xml和sqltext的，是不是有点浪费内存呢？
(4) 仔细想想你会知道，sql引擎还是挺色胆包天的，因为prepared的记录已生成，执行计划也就生成了。。。。那说明什么呢？？？说明这时候
的xml已经是死的了，也就说明执行计划也是定死的了，难道@1参数的不同不会导致执行计划有变更么？？？如果有变更难道还让我执行原来
这个表扫描执行计划么？？？有点奇葩，好了，我准备在下面仔细说说。
二：参数的变化对prepared的影响
如果你看过之前的博文，你应该明白有一个叫做书签查找的玩意。。。它的原理是在非聚集索引上通过B树查找，当查找到目标键的时候拿到这
个键的聚集索引key，然后通过key来取数据的记录，如果你的非聚集索引的键值的唯一性比较高，这时候sql引擎会走书签查找，但是如果你的键值
唯一性比较低或者在数据量比较小的情况，sql引擎就不会走书签查找，而转向聚集索引扫描。。。那这说明什么呢？说明执行计划在有些时候会跟
(@1 int)这个值有关系。。。那这样的话貌似就不能重用执行计划了，对吧。。。。为了验证sql引擎怎么处理的，我们来做一个测试。
1.先清空缓存，再在Name列上建索引，然后我们select下，如下图：
1 DBCC freeproccache 2 CREATE INDEX idx_Name ON dbo.Person(NAME) 3 SELECT * FROM dbo.Person WHERE NAME=‘aaaaa‘
2. 然后还是继续看看xml和sqltext
你有什么发现吗？在记录中并没有发现什么prepared记录，这说明什么。。。说明sqlserver很聪明，它知道Name可能会有 “表扫描”到
“书签扫描”的来回切换，为了验证问题，我继续向Person表插入1w条数据，然后再插入一个唯一性数据。如下图：
1 INSERT INTO dbo.Person DEFAULT VALUES 2 go 10000 3 INSERT INTO dbo.Person(NAME ) VALUES (‘ccccc‘)
确实，如我猜想的一样，sqlserver很聪明的。。。如果它觉得这个Name不靠谱的话，它是绝对不敢给这条sqltext生成prepared的。。。转过
头来再想想第一条为什么会有sqltext，那是因为a列不管取值多少，都改变不了走表扫描的现实，所以sql引擎才敢这么大胆。。。突然觉得人生
不就是这样嘛？？？？很多人都是不把稳的事情是绝对不敢做的。。。
sqltext的参数化处理
标签：
热心网友
时间：2022-04-30 11:23
⑴ 某个ASP.NET Web应用有一个登录页面，这个登录页面控制着用户是否有权访问应用，它要求用户输入一个名称和密码。
⑵ 登录页面中输入的内容将直接用来构造动态的SQL命令，或者直接用作存储过程的参数。下面是ASP.NET应用构造查询的一个例子：
System.Text.StringBuilder query = new System.Text.StringBuilder(
"SELECT * from Users WHERE login = '")
.Append(txtLogin.Text).Append("' AND password='")
. Append(txtPassword.Text).Append("'");
⑶ 攻击者在用户名字和密码输入框中输入"'或'1'='1"之类的内容。
⑷ 用户输入的内容提交给服务器之后，服务器运行上面的ASP.NET代码构造出查询用户的SQL命令，但由于攻击者输入的内容非常特殊，所以最后得到的SQL命令变成：SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'。
⑸ 服务器执行查询或存储过程，将用户输入的身份信息和服务器中保存的身份信息进行对比。
⑹ 由于SQL命令实际上已被注入式攻击修改，已经不能真正验证用户身份，所以系统会错误地授权给攻击者。
如果攻击者知道应用会将表单中输入的内容直接用于验证身份的查询，他就会尝试输入某些特殊的SQL字符串篡改查询改变其原来的功能，欺骗系统授予访问权限。
系统环境不同，攻击者可能造成的损害也不同，这主要由应用访问数据库的安全权限决定。如果用户的帐户具有管理员或其他比较高级的权限，攻击者就可能对数据库的表执行各种他想要做的操作，包括添加、删除或更新数据，甚至可能直接删除表。
⑴ 对于动态构造SQL查询的场合，可以使用下面的技术：
第一：替换单引号，即把所有单独出现的单引号改成两个单引号，防止攻击者修改SQL命令的含义。再来看前面的例子，“SELECT * from Users WHERE login = ''' or ''1''=''1' AND password = ''' or ''1''=''1'”显然会得到与“SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'”不同的结果。
第二：删除用户输入内容中的所有连字符，防止攻击者构造出类如“SELECT * from Users WHERE login = 'mas' -- AND password =''”之类的查询，因为这类查询的后半部分已经被注释掉，不再有效，攻击者只要知道一个合法的用户登录名称，根本不需要知道用户的密码就可以顺利获得访问权限。
第三：对于用来执行查询的数据库帐户，*其权限。用不同的用户帐户执行查询、插入、更新、删除操作。由于隔离了不同帐户可执行的操作，因而也就防止了原本用于执行SELECT命令的地方却被用于执行INSERT、UPDATE或DELETE命令。 ⑵ 用存储过程来执行所有的查询。SQL参数的传递方式将防止攻击者利用单引号和连字符实施攻击。此外，它还使得数据库权限可以*到只允许特定的存储过程执行，所有的用户输入必须遵从被调用的存储过程的安全上下文，这样就很难再发生注入式攻击了。
⑶ *表单或查询字符串输入的长度。如果用户的登录名字最多只有10个字符，那么不要认可表单中输入的10个以上的字符，这将大大增加攻击者在SQL命令中插入有害代码的难度。
⑷ 检查用户输入的合法性，确信输入的内容只包含合法的数据。数据检查应当在客户端和服务器端都执行——之所以要执行服务器端验证，是为了弥补客户端验证机制脆弱的安全性。在客户端，攻击者完全有可能获得网页的源代码，修改验证合法性的脚本（或者直接删除脚本），然后将非法内容通过修改后的表单提交给服务器。因此，要保证验证操作确实已经执行，唯一的办法就是在服务器端也执行验证。你可以使用许多内建的验证对象，例如RegularExpressionValidator，它们能够自动生成验证用的客户端脚本，当然你也可以插入服务器端的方法调用。如果找不到现成的验证对象，你可以通过CustomValidator自己创建一个。
⑸ 将用户登录名称、密码等数据加密保存。加密用户输入的数据，然后再将它与数据库中保存的数据比较，这相当于对用户输入的数据进行了“消毒”处理，用户输入的数据不再对数据库有任何特殊的意义，从而也就防止了攻击者注入SQL命令。System.Web.Security.FormsAuthentication类有一个HashPasswordForStoringInConfigFile，非常适合于对输入数据进行消毒处理。
⑹ 检查提取数据的查询所返回的记录数量。
热心网友
时间：2022-04-30 12:41
