我最近了解到 overlong encodings cause a security risk 在未正确验证时。从前面提到的帖子中的答案：
例如字符
还有：
如果您接受此输入并以基于 Unicode 忽略字节的方式处理它 工具，那么在该工具中使用的任何字符处理步骤都可以 被避开。
意思是如果我在使用超长编码的字符串上使用htmlspecialchars，那么输出仍然可能包含标签。我还假设您可以发布类似的字符（如" 或;），这些字符也可用于 SQL 注入。
也许是我，但我相信这是一个相对较少人考虑甚至知道的安全风险。我已经编码多年，现在才发现这一点。
无论如何，我的问题是：我可以使用哪些工具来发送编码过长的数据？ 熟悉此风险的人：您如何在网站上执行测试？我想在我的网站上发布一堆过长的字符，但我不知道该怎么做。
在我的情况下，我主要使用 PHP 和 MySQL，但我真正想知道的是测试工具，所以我想后端情况并不重要。
【问题讨论】：
我想在我的网站上发布一堆过长的字符，但我不知道该怎么做。
除了使用 curl 等手动请求工具对其进行测试外，浏览器内测试的一个简单解决方法是覆盖表单提交的编码。使用例如 Firebug/Chrome 调试器，更改您正在测试的表单以添加属性：
accept-charset="iso-8859-1"
您现在可以键入在编码为 Windows 代码页 1252(*) 时成为所需的 UTF-8 超长字节序列的字符。
例如，在表单中输入café，您将获得字节序列c a f 0xC3 0xA9，因此应用程序会认为您输入了café。输入À¼foo，将提交序列0xC0 0xBC f o o，可以解释为<foo。请注意，您不会在任何输出页面源中看到 <foo，因为现代浏览器不会解析网页中过长的 UTF-8 序列，但您可能会收到 �foo 或其他指示有问题。
如需更深入地访问网络应用的输入和检查输出，请参阅 Burp 等专用 sec 工具。
【讨论】：
iso-8859-1，但由于繁琐的历史原因，Web 浏览器将此编码视为真正含义 windows-1252。它们是令人困惑的相似编码，但并不相同。
要测试您的网站是否易受攻击，请使用 curl 使用 post 和编码为 utf8 long 并发布 utf8 long 编码信息来获取您的页面（您可以通过将文本编辑器编码设置为 utf8 long 来使用您的文本编辑器，这样您使用 curl 发布的文本和 php 文件很长）
【讨论】：