IIS请求内容筛选是否在筛选之前加载完整的请求

Question

我正在按内容长度查看IIS Request filtering。我已经设置了允许的最大内容长度：

appcmd set config /section:requestfiltering /requestlimits.maxallowedcontentlength:30000000

我的问题是何时进行过滤。

IIS将首先将所有请求读入内存，然后引发错误，还是在达到阈值后立即引发问题？

Answer 1

IIS请求筛选模块在请求管道中很早就得到了处理。不需要的请求会被快速丢弃，然后再继续执行速度较慢且攻击面更大的应用程序代码。因此，有些人报告说在实施请求过滤设置后性能会提高。

限制

请求过滤限制包括以下内容：

• 无状态-请求过滤不了解应用程序或会话状态。不管是否建立会话，都会单独处理每个请求。
• 仅请求标头-请求过滤只能检查请求标头。它无法查看请求正文或响应的任何部分。
• 基本逻辑-正则表达式和通配符匹配不可用。大多数设置包括建立大小限制，而其他设置则执行简单的字符串匹配。

maxAllowedContentLength

请求过滤检查Content-Length请求标头的值。如果该值超过为maxAllowedContentLength设置的值，则客户端将收到HTTP 404.13。

IIS 8.5 STIG的建议值是30000000或更少。

IISRFBaseline

以上信息基于我的PowerShell模块IISRFBaseline。通过利用Microsoft Logparser扫描网站的内容目录和IIS日志，它可以帮助建立IIS请求筛选基准。

许多设置都有专用的markdown文件，提供有关该设置的更多信息。可以在以下位置找到maxAllowedContentLength的一个：

https://github.com/phbits/IISRFBaseline/blob/master/IISRFBaseline-maxAllowedContentLength.md

更新-@ johnny-5评论

过滤会立即进行，这很有意义，因为“请求过滤”仅对请求标头具有可见性。通过以下方法确认了这一点：

• 失败的请求跟踪-请求过滤模块使用HTTP 413请求实体太大来响应请求。
• http.sys event tracing-接受请求并将其移交给IIS网站。此后不久，就有一个条目显示HTTP 413响应。间隔时间还不够长，无法完成上传。
• 数据包捕获-使用Microsoft网络监视器，HTTP对话显示IIS立即用HTTP 413请求实体进行了响应。

您应该正确考虑的部分是，无论文件大小如何，IIS仍会接受上载。我发现限制因素为connectionTimeout，其默认设置为120秒。如果在超时之前文件已“完成”，则会显示HTTP 413错误消息。发生超时时，浏览器将显示连接重置，因为在发送TCP ACK / RST之后IIS破坏了TCP连接。

要进一步测试，请增加超时并将其设置为connectionTimeout=6000。然后提交大量上载，并且一次停止了以下IIS组件。每次停止后，通过网络监视器检查上载并确认其仍在运行。

1. Website
2. 应用程序池（Stop-WebAppPool -Name AppPoolName）
3. 万维网发布服务（Stop-Service -Name W3SVC）

三个都停止了，我确认没有IIS进程仍在运行，但是字节仍在上载。这使我得出结论，该连接由http.sys维护。 connectionTimeout与http.sys紧密相连的事实似乎支持了这一点。我不知道上传的字节是进入缓冲区还是被丢弃。 event tracing messages在这种情况下没有提供任何帮助。

省略Content-Length请求标头将导致400生成RFC协议错误（即HTTP http.sys错误请求），因为未声明HTTP有效负载的大小