如何修复服务器状态代码：SQL Inject Me Firefox Addon 发现的 302

Posted 2023-02-24

【中文标题】如何修复服务器状态代码：SQL Inject Me Firefox Addon 发现的 302

【英文标题】：How to fix Server Status Code: 302 Found by SQL Inject Me Firefox Addon

【发布时间】：2010-11-19 23:42:15

【问题描述】：

我使用 SQL Inject Me Firefox 插件扫描了我的登录脚本

根据测试结果，我的脚本易受 SQL 注入攻击。示例结果

Results:
Server Status Code: 302 Found
Tested value: &#49&#39&#32&#79&#82&#32&#39&#49&#39&#61&#39&#49
Server Status Code: 302 Found
Tested value: 1' OR '1'='1
Server Status Code: 302 Found
Tested value: 1 UNI/**/ON SELECT ALL FROM WHERE
Server Status Code: 302 Found
Tested value: %31%27%20%4F%52%20%27%31%27%3D%27%31

我的脚本

login.php - 登录表单

check-login.php - 检查登录细节，这里是代码。

$email = clean($_POST['username']); $pass = clean($_POST['password']); $user = "select * from tbl_admin where admin='$email' and pass='$pass'";

// 一些代码

$_SESSION['login_mes'] = "您已成功登录！"; header("位置：admin.php"); 退出（）；

否则

$_SESSION['login_mes'] = "电子邮件地址或密码无效，请重试。"; header("位置：login.php"); 出口（）;

登录失败时出现问题。如果我删除

 else 

$_SESSION['login_mes'] = "Invalid email address or password, please try again.";
header("Location:login.php");
exit();

SQL Inject Me 没有检测到故障以及如何修复这部分？

【问题讨论】：

clean 函数有什么作用？

一个附带问题 - PHP 中有参数化查询的概念吗？这可能值得研究。

【参考方案1】：

302 是服务器表示“我希望你去[其他地方]”的方式（在本例中为 login.php）。 这不是错误，而是完全正常的反应。特别是在您的情况下，在 SQL 注入尝试后将用户发送到登录页面比让他进入更有意义（如果您问我）。

【参考方案2】：

"// some code" 没有多大帮助，但问题可能出在这个clean() 上。请改用mysql_real_escape_string()。

编辑：如上所述，302 代码表示“您正在被转发”。这并不意味着 SQL 注入是成功的，因为这并不意味着它也不是。在这种情况下，您只会知道，如果您可以确定此 302 将您转发到“admin.php”还是“login.php”。

【讨论】：

清洁功能工作正常。问题出现在 else

之后

我们也知道它不成功并且重定向到 login.php （因为当他删除该特定标头（“Location:...”）时，不再检测到 302 . 将 302 作为 SQL 注入成功的标志是一个相当愚蠢的想法，恕我直言，我想知道他们在想什么。

【参考方案3】：

一些渗透测试工具更喜欢服务器不返回错误消息或至少返回非常通用的消息。例如，在 SQL Inject Me 页面上它说

该工具通过表单发送数据库转义字符串来工作 字段。然后它查找输出到的数据库错误消息 页面呈现的 html。

因此，当它看到 302 响应代码时，可能会认为您的应用返回的信息过多。您可以通过为您的响应设置不同的状态代码并查看 SQL Inject Me 是否仍然给出错误来测试这个理论，如下所示：

header('HTTP/1.1 404 Not Found');

当然，向他们发送 404 不会帮助您的用户返回登录页面，因此您可能需要尝试其他 3XX 消息，可能是 303 或 307。

【参考方案4】：

四年后，但我只是在研究这个问题，并认为我会为下一个人分享。

经过一些分析，我们得出的结论是 302 本身不是问题。问题是 302 之前的哪个页面可能已发送但在显示之前被 302 扫走。如果浏览器收到的前一页（可能由 Fiddler 记录）包含数据库错误（或黑客可能认为有用的其他信息），那就不好了。如果 302 是初始响应并且它有一个空的正文，只是一个标题，那么我认为你没问题。

您必须显示错误页面（302 的目的），所以我看不出这怎么会被认为是“信息过多”。

【讨论】：

是的。在我的站点中，302 重定向到显示错误消息的错误页面。从 tsql 语句被泄露的意义上说，它是在泄漏信息，但似乎没有将我的网站暴露给注入。