有趣的文章（CVE-2011-4885，适合那些喜欢参考的人），感谢您的提醒 - 我会阅读这篇文章，但有几点已经很突出。

• 只是为了澄清-问题出在逻辑层内-而不是网络服务器本身。
• 您是否可以使用 ini_set 的问题取决于已升级的底层 PHP 引擎 - 当您已经争辩说这对于许多托管服务提供商而言不太可能发生时。OTOH 任何升级 PHP 的托管服务提供商都可能会部署相关的 ini 更改或提供这样做的机制。
• 虽然大多数托管公司会积极避免对其用户进行重大升级，但他们应该将供应商补丁部署到现有部署中——而且这个补丁已经被向后移植到 5.3 和 5.2 的所有生产版本，我相信 Redhat 现在已经发布了补丁当前的 RHEL
• 在 PHP 中至少有 4 个不同的地方可以更改 ini 设置 - 在 php.ini 文件中、在 webserver 配置中（当 PHP 作为模块实现时）、在 .htaccess 文件中（如果是模块）和 PHP 代码中本身 - 但并非所有设置都可以在所有地方更改 - 到目前为止，新的配置变量在手册中没有说明可以更改的位置。
• 为了利用此漏洞，有必要在请求中发送大量变量 - Apache（可能还有大多数其他网络服务器）允许对请求、请求正文和 POST 数据的总大小进行一些控制 - 也可以执行在 httpd 配置和使用 .htaccess 的特定目录树中有效和有选择地使用这些配置选项可用于减轻任何潜在的攻击 - 记住任何需要支持（例如）文件上传。
• 基于此漏洞的 DOS 本质实际上与 Apache 上的范围请求问题 (CVE-2011-3192) 非常相似 - 尽管是一个严重的漏洞，但我没有看到太多证据表明该缺陷被广泛利用.

我知道如果有人攻击服务器整个站点将会关闭，但是通过设置 max_input_vars 至少如果有人攻击我的站点我的站点将是安全的

我不明白 - 基于此漏洞的攻击当然不会导致数据/代码（AFAICS）的泄漏或修改。

我知道如果有人攻击服务器，整个站点都会关闭，但是通过设置 max_input_vars，如果有人攻击我的站点，至少我的站点是安全的。这个对吗？

我认为除非 max_input_vars 低于默认值（1000），否则它仍然可能发生在多个请求中，您非常希望将其设置为您的软件使用的最大 vars 数，但是找出来是多么痛苦（或者如果您有动态字段，则不可能）。

IMO：对癌症的创可贴，他们需要将哈希算法更改为随机的。