我在 WP.org v4.7.2 上安装了 NinjaFirewall 插件。它把我锁在我的网站之外。
他们向我的托管公司的 cPanel 索要日志，我得到了这些日志，他们报告说：
您有一个包含 NULL 字节字符 (0x00) 的 cookie。这是非常奇怪和不寻常的。
您可以使用其他浏览器登录 WordPress（或先删除您的 cookie），然后转到“NinjaFirewall > 防火墙策略 > 各种 > 阻止 ASCII 字符 0x00（NULL 字节）”并选择“否”。然后，向下滚动到页面底部并单击“保存防火墙策略”。
这对我来说是全新的领域。有谁知道我是否应该注意任何问题？
有谁知道我是否应该注意任何问题？
主要问题是解析 cookie 的脚本语言（例如 PHP）可能以将 NULL 字节字符（0x00）视为特殊控制字符的语言（例如 C）实现。
例如，在 C 语言中，长度为 N 的“字符串”被实现为 N+1 个字符的数组，其中数组末尾的第 (N+1) 个字符是 0x00，用于表示结束的字符串。
这里违反的一般安全原则是指令（类似指令的控制字符 0x00）与数据的意外混合。Cookie 通常被认为是数据字符串，但由于空字节在 C 中具有特殊的控制属性（它指示字符串的结尾并可能导致字符串解析例程返回），因此它的功能更像是一条指令而不是数据。
下面是一个空字节如何导致问题的具体示例： 可以上传一个名为“backdoor.php\x00.png”的文件，其中包含 PHP 后门代码。即使php文件被列入黑名单，由于扩展名为“.png”，该文件仍有可能被上传。如果 PHP 文件名解析（在 C 中实现）不正确地返回空字节字符，则文件可能会以名称“backdoor.php”保存，然后可以通过访问上传文件夹中的文件来执行。这种类型的漏洞被称为“空字节注入”。
我不知道基于 cookie 中的空字符的特定漏洞，但这个想法与上面类似，并且会在解析 cookie 的代码的实现语言中利用空字节的特殊属性。