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

核心提示： 如果你得到一个数据库服务器返回的某些错误信息，那么SQL注射显然是存在的.然而，SQL概述及在网络安全中的应用（上）(3)，数据库错误信息不一定总是明显的(有时候编写程序的人可能做一些奇怪的事情),所以，你应该顺便看看每个可能的地方来确认注射是否成功，或礼貌的让用户把他们的请求email给

如果你得到一个数据库服务器返回的某些错误信息，那么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来利用这些站点，这将在后面讨论。