我没有清理来自 url 等的用户输入和数据我所做的是我将数据库中的每一件事都编码为 base64 甚至表主键的 id.. 是否足以对抗漏洞？
问问题
117 次
2 回答
4
不，这不对。
您将设法做的所有事情（除了浪费的 CPU 和数据库中的空间）就是存储不安全的数据。如果操作正确，您就可以保护自己免受 SQL 注入。但仅此而已。一旦您解码数据，您就会遇到未清理数据的所有问题。
因此，除非您打算永远不对您存储的内容做任何事情，否则您是不安全的。
于 2013-08-04T06:09:00.710 回答
2
您要防范的漏洞是什么？正如 Mat 所说，您将不会受到 SQL 注入的影响，但仅此而已。
另外，值得注意的是base_64编码除了去除SQL注入之外没有任何安全价值，而且任何查看者都清楚你的数据是base_64编码的，所以很容易被破解。
我可以建议您在继续之前阅读OWASP的工作。其中一些有点枯燥，但大多数对于任何 Web 开发人员来说都是有价值的预读。如果你只是确保你被他们的前 10 名覆盖，那将是一个开始。
提供一些阅读建议：
请考虑您的数据。任何敏感的东西都应该受到保护。真正偏执的人可能会考虑 AES 加密，但坦率地说，除非您存储健康、财务或军事数据，否则这可能是矫枉过正。保密您的密钥 - 任何可以下载您的数据库的人都可以下载您的密钥。有一些方法可以防止这种情况发生，但你的问题表明你还没有达到那个水平。在可能的情况下，不要加密密钥，因为它会阻止索引，并且不加密琐碎的数据。但请确保未加密的数据不能用于得出有关加密数据的重要结论。
务必将密码存储为加盐哈希。至少如果您的数据库被入侵，黑客将无法攻击您用户的其他帐户（他们将使用相同的密码......）
不要使用电子邮件地址作为用户名和密码重置。要么/要么
不要自己动手做安全解决方案。毕竟，AES 对于任何没有 CIA 的东西来说已经足够好了。
一定要在 HTML 中混淆你的密钥——网上有很多简单的混淆器。
请检查访问您的数据库特别是 AJAX 脚本的每个页面的经过身份验证的会话。
不要依赖客户端身份验证——这只会阻止愚蠢。恶意的人可以很容易地绕过它。
最后-
务必对所有用户输入使用准备好的语句。
抱歉继续说下去，但这些问题每天都在这个论坛上以一种或另一种形式出现，值得重复一下。
一旦你做了/不做上面列表中的所有事情，你将不会受到最严重的问题的影响，尽管仍然远非安全。我故意没有完全解释任何方法，因为您将通过谷歌搜索并阅读一下来了解大量有关应用程序安全性的知识。
玩得开心...
编辑回答下面的评论。
使用 base_64 编码作为一种击败 SQL 注入的手段，本质上并没有错。它是完全可靠的，因为 base_64 编码不包含任何可能扰乱 sql 的字符。
有几个理由不这样做：
- 这是非常数据密集型的，需要更多的空间来存储您的数据。- 它使搜索您的数据非常低效。- 它让你很难读取你的数据，但对攻击者来说并不难。- 它没有提供有效的密码保护（请使用加盐哈希）。
echo base64_encode("Abcde")."<BR>".base64_encode("cd");
有效地演示了搜索和大小问题——如果没有额外的指令，你不能有效地使用 LIKE 或通配符——如果你有 mysql 5.6.1 或更高版本，WHERE from_base64(field) LIKE '%cd%' 将起作用。
如果它适合您的特殊需要，那么这样做很好，但我告诉您，您没有学会正确地做到这一点。如果您改用预准备语句，您可以高效、可索引、可扩展、可搜索、安全、可读且易于调试地存储数据。
您正在做的事情对于一个非常小的站点来说足够好，但对于更大的站点就不行了。
于 2013-08-04T06:39:43.650 回答