SQL概述及在网络安全中的应用（上）

CompanyName='

可能只会给你一个错误告诉你需要指定一个ContactName值。

这行:

ContactName=BadContactName&CompanyName='

可能返回同样的页面，因为请求根本没有指定ContactName。或者，它可能返回你站点默认的主页。或者，可能它找不到指定的ContactName，或者web程序认为没有必要看CompanyName，所以它甚至根本不把这个参数值认为是一个SQL声明，或者，它可能给你一些完全不同的东西,所以，当检测SQL注射的时候，记得总是用完整的参数行，并且除了你正在检测的那个参数外，还要给其它所有的参数一个合法的值。

2.3分析结果

假如你得到一个数据库服务器返回的某些错误信息，那么SQL注射显然是存在的.然而，数据库错误信息不一定总是明显的(有时候编写程序的人可能做一些希奇的事情),所以，你应该顺便看看每个可能的地方来确认注射是否成功，首先你应该从返回的页面上的所有资源中找寻像"ODBC", "SQL Server", "Syntax"等的短语，更多的信息可能含在HTTP的头部,隐藏的输入...。我曾见过某些存储系统上的网络请求返回的错误信息中，在HTTP回复的body中完全没有任何信息，但在头部中却有数据库错误信息。为了调试和QA的目的，很多网络请求都内嵌了这种特征，然而到最后发表前却忘了把它们去处掉或使之无效。

你不只要注重即时返回的页面，同样链接页面也要看，在最近的一次pen－test中，我看到一个网络请求被SQL注射攻击后，返回了一个类错误信息页面，点击错误旁边的停止标志图片，链接到了另外一个满是SQL服务器错误信息的页面。

另一个应该密切注重的是302页面重定向，在你有机会注重到它之前,你可能就无奈的离开了一个含有数据库错误信息的页面.

请注重即使你真的得到了一个ODBC错误信息回复，SQL注射仍有可能成功，很多时候（Lots of the time）你得到一个properly formatted, seemingly类错误消息页面，告诉你"an internal server error" 或者 "problem processing your request."

有些网络请求被设计成一旦出现任何的错误，客户都返回到站点的主页面。假如你得到一个500错误页面，很有可能注射就出现了，很多站点都有一个默认的500服务器内部错误页面来说明服务器正在维护中，或礼貌的让用户把他们的请求email给站点的维护人员。这就有可能用procedure techniques来利用这些站点，这将在后面讨论。

3.1绕过验证

最简单的SQL注射技术是绕过基于表单的登陆.让我们假设某个网络请求的代码如下:

　　SQLQuery = "SELECT Username 

FROM Users WHERE Username = '" & strUsername & "' 

AND Password = '" & strPassword & "'" 

　　strAuthCheck = GetQueryResult(SQLQuery) 

　　If strAuthCheck = "" Then 

　　boolAuthenticated = False 

　　Else 

boolAuthenticated = True 

End If

当一个用户提交了一个用户名和密码后，查询（query）将搜索Users表单来看是否其中有一行中所包含的用户名和密码与用户提供的相同，假如找到了那么一行，则用户名被储存到变量strAuthCheck中，同时说明该用户应该被鉴定，假如没有找到那么一行，则strAuthCheck变量保持为空，同时该用户不被鉴定。
共4页: 上一页 [1] 2 [3] [4] 下一页

评论加载中…