理解动态的SQL

　　当一个程序在运行的时候将SQL 字符串也执行的话，它被称为动态SQL 。

　　检查应用程序的代码没有提供明确的标志来区别哪些SQL 可以被实际执

　　行，它只提供了一个标志这些语句可以被执行，只有SQL 事件探测器能找到那

　　些实际执行的sql.。审查下列应用程序代码构建SQL 字符串的测试应用程序：

　　.CommandText = “select EmployeeID from Employees where FirstName = ‘” + _

　　FirstName.Text + “‘ and LastName = ‘” + LastName.Text +”‘”

　　上面的例子看起来SQL 的描述很符合逻辑，如果分别输入Andrew 和Fuller

　　作为第一个名字和最后名字，然后SQL 事件探查表明，实际的SQL 执行的是：

　　select EmployeeID from Employees

　　where FirstName = ‘Andrew’ and LastName = ‘Fuller’

　　这是完全符合预定设计中的应用。无效的输入被发现，用户是无法获得权限。

　　改变的逻辑威胁

　　通过简单的文本框测试应用系统可以接受到输入的第一个名字和最后一个

　　名字，用户可以自由地输入文字以外的其他名字或姓氏。黑客可以使用基本的

　　SQL 知识就可以不通过猜测一个有效的名字和姓氏直接获得权限。

　　用户输入下面的字符串，然后获得权限

　　’ or 1=1—

　　通过在第一名字文本框输入SQL 片段语句，一个黑客“注入”的SQL 片段，

　　从而改变了SQL 语句的执行。注入的SQL 片段实际上由三个不同的片段，每一

　　个不同的目的：

　　1、在单引号关闭了First Name = ‘片段的模板查询。这样做是为了保持修改

　　查询的语法的正确性。

　　2、这个or 1=1 每次都会返回一个值，假设这个表不空。

　　3、因为1=1 是永远返回一个true 的值，于是这个输入导致整个剩余的动态

　　建立SQL 语句被忽视。任何投入的姓文本将被忽略。

　　SQL 事件探查显示实际执行：

　　select EmployeeID from Employees

　　where FirstName = ” or 1=1–‘ and LastName = ”

　　应用程序设计初衷是将名字与姓氏作为输入条件，但SQL 注入改变了SQL

　　逻辑，使它们是多余的。

　　多个声明的威胁

　　未经授权的访问的权限的不同级别的严重程度取决于应用程序的目的。有时

　　人们不认为这是潜在危害的安全威胁。

　　例如，如果一个Web 应用程序提供收费进入公共平台系统，未经授权的访

　　问导致收入的损失远远超过了加强安全功能的费用，毕竟，有很大一种可能，如

　　果一个人进入了一个收费的公共服务系统，而要进一步进入这个网站存在失败的

　　风险他就不会轻易尝试。然而，这样的推理是幼稚和致命的缺陷-如果在SQL 娴

　　熟的黑客决定将注入新的SQL 语句呢?

　　参考下面的SQL 代码：

　　www.51testing.com

　　《51 测试天地》第十四期15

　　’ or 1=1;update Products set UnitPrice = 0—

　　再次，在SQL 事件探查器显示实际执行的-其实，两个单独的SQL 语句：

　　select EmployeeID from Employees

　　where FirstName = ” or 1=1;

　　update Products set UnitPrice = 0–‘ and LastName = ”

　　分号是一个有效的SQL 字符用来联合多个SQL 语句。而在SQL 分析器里

　　这个SQL 语句通过分号被逐个分开执行。

　　黑客不仅限于增删改的操作(插入，更新，删除)删除一个表怎么样?假设

　　具有删除这个应用系统表的权限，黑客可以使用删除这个表的语法来从数据库删

　　除这个表，参考下面的输入：

　　’ or 1=1;update prices set cost = 0;drop table audit_trail;shutdown–

　　不仅仅是这个日志表被删除，就连数据库也会被立刻关闭。

本文地址：http://www.jwzzsw.com/archives/712.html