UTF-8和mb_check_encoding

Question

我有一个问题。我刚刚从iso-8859-1切换到utf-8，在我的SQL数据库和我的所有PHP文件中。我所有的PHP脚本都是GET放在表单（X）中的任何内容，并在SQL数据库中搜索它，并显示数据，同时还显示消息“X返回Y结果。”

现在我有一个问题要问mb_check_encoding的用法。我在this主题中阅读了以下内容：

  

不幸的是，在尝试存储或在任何地方使用它之前，您应该将每个收到的字符串验证为有效的UTF-8。 PHP的mb_check_encoding（）可以解决这个问题，但你必须虔诚地使用它。由于恶意客户端可以以他们想要的任何编码方式提交数据，因此真的无法解决此问题，而且我还没有找到让PHP可靠地为您执行此操作的技巧。

你可以说，我很担心。我做了以下事情：

• 将我的SQL数据库切换到utf8mb4。
• 使用$mysqli->set_charset('utf8mb4');进行数据库与PHP文件之间的连接。
• 通过<meta http-equiv="content-type" content="text/html; charset=utf-8" />在我的HTML / PHP文件中设置我的字符集。
• 以UTF-8保存我的所有文件（无BOM）。
• 使用htmlspecialchars($_GET['name'], ENT_COMPAT | ENT_HTML401, 'UTF-8')作为“X返回Y结果。” - 消息。

我的问题是：即使我已经完成了以上所有操作，我还应该使用mb_check_encoding吗？我如何检查我是否容易受到这种“恶意”攻击？

Answer 1

“攻击”这个词听起来令人震惊，但实际上我们正在谈论“给那些期待Y并等待看到会发生什么的人”。实际上发生了一些不好的事情远非一个给定的。

在这种情况下，MySql与您一样担心：如果客户端发送的输入不符合约定的编码，该怎么办？ MySql不是老室友的周末项目，显然必须加强并以理智的方式处理问题。确实如此：当你输入这种输入时，它会发出错误代码1366“不正确的字符串值”。

总之：只要您遵循既定的最佳实践（带参数的预处理语句）来防止SQL注入攻击，这里可能没有真正的攻击向量。可能发生的最糟糕的事情是攻击者会导致您的一个SQL查询失败;在合理的情况下，由于错误的默认值和零错误处理，这种失败不会导致一连串的悲剧，这意味着他们只会获得一个错误信息。当然MySql对此“免疫”并不意味着你的应用程序作为一个整体也会免疫，但它确实意味着你不必担心数据库组件。