在线服务中的漏洞, 如跨站、CSRF(跨站点请求伪造)、或者信息泄露，都是 微软安全响应中心 (MSRC) 重点关注的区域。最近几年以来，微软已经开发了很多能够缓解特定Web漏洞的工具（例如 UrlScan）。为了在这方面提供帮助，我们参与了一项将常用的开放源模块 ModSecurity 引入 IIS 平台的社区工作。在昨天的拉斯维加斯黑帽子 (Black Hat) 大会上，我们已经宣布 RC 版上市，并预计稳定版本也会很快上市。

安装

尽管已完全公布 ModSecurity的 IIS 组件的源代码并且已公开描述了生成过程（参见 SourceForge 存储库中的 mod_security/iis/winbuild/howto.txt），但我们仍强烈建议不要出于非研究或非开发目而自行生成该模块。

可从 ModSecurity 项目的 SourceForge 文件存储库获取 ModSecurity for IIS 7 和更高版本的标准 MSI 安装程序，将来会有指定的维护人员为它更新该模块的最新修补程序和次要版本。

配置

IIS 安装程序不会干扰当前运行的 Web 应用程序。这意味着必须在安装过程后执行应用程序池重新启动或回收，以便将新模块加载到应用程序池进程中。对于
RC 版的模块，也强烈建议在每次更改 ModSecurity 配置文件后执行重新启动/回收步骤：

将该模块成功加载到应用程序池进程中后，应用程序事件日志中将会记录一系列信息事件：

运行阶段生成的运行时消息和通知（均来自用户定义的规则和系统特定事件或错误）将会发送到相同的应用程序事件日志存储库。

若要将 ModSecurity 配置文件应用于 Web 应用程序或路径，用户必须使用 IIS 配置方案扩展，如下所示：

<?xml version="1.0" encoding="UTF-8"?>

<configuration>

    <system.webServer>       

<ModSecurity enabled="true" configFile="c:\inetpub\wwwroot\test.conf" />

    </system.webServer>

</configuration>

c:\inetpub\wwwroot\test.conf 配置文件是一个常规 ModSecurity 配置，其中包含 Apache Web 服务器上使用的相同指令。

保护示例

ModSecurity 最常见的应用是称为“虚拟修补”的保护层（参见“资源”部分 [5]）。以最近的两个漏洞为例，我们将要演示如何可以在包含与 ModSecurity 一起运行的 IIS 服务器的环境中指定此层。

CVE-2011-3414

2011 年 12 月，我们解决了 ASP.NET 中的一个漏洞，该漏洞允许攻击者在大多数 ASP.NET Web 应用程序上生成过大的处理器负载。哈希冲突问题要求攻击者向服务器发送较大的（通常为 1MB 或 4MB）POST 请求，并且其中包含数以万计的带有专门生成的名称的参数。至少有四种方式可以缓解这种类型的攻击： 

• 限制请求正文大小。

• 限制参数的数量。

• 识别重复的负载。

• ​对照 PoC 数据检查参数名称。

检查是否存在重复的负载的方法是最高明的，可使用以下规则链在 ModSecurity 中实现该方法： 

SecRule &ARGS "@ge 1000" "chain,id:1234,phase:2,t:none,deny,msg:'Possible Hash DoS Attack Identified.',tag:'https://blogs.technet.com/b/srd/archive/2011/12/27/more‑information‑about‑the‑december‑2011‑asp‑net‑vulnerability.aspx?Redirected=true'"

  SecRule REQUEST_BODY "^\w*?=(.*?)&\w*?=(.*?)&\w*?=(.*?)&\w*?=(.*?)&"
"chain,capture"

    SecRule TX:1 "@streq %{tx.2}" "chain,setvar:tx.hash_dos_match=+1"

    SecRule
TX:2 "@streq %{tx.3}"
"chain,setvar:tx.hash_dos_match=+1"

    SecRule
TX:3 "@streq %{tx.4}"
"chain,setvar:tx.hash_dos_match=+1"

      SecRule TX:HASH_DOS_MATCH "@eq
3"

在将此规则加载到 IIS 服务器配置中之后，如果在受保护路径上受到了攻击，则 Windows 应用程序事件日志将记录来自 ModSecurity 的“访问被拒绝”消息：

同时，攻击者将会看到 HTTP 响应 403，并且攻击在到达 ASP.NET 漏洞组件之前会停下来。

CVE-2012-1859

2012 年 7 月，Microsoft 修补了 Microsoft SharePoint 2010 中的反射跨站点脚本漏洞的经典案例。对于利用漏洞的攻击，只需欺骗用户点击恶意 URL 就够了，如下所示：

https://sharepoint/_layouts/scriptresx.ashx?culture=en‑us&name=SP.JSGrid.Res&rev=laygpE0lqaosnkB4iqx6mA%3D%3D&sections=All<script>alert(‘Hacked!!!’)</script>z

攻击者注入的脚本通过受到攻击的 SharePoint 服务器，可获得对受害者可用的整个数据集的访问权限。

阻止此攻击的一个可能方法是白名单方法：

让带有只包含有效字符的 sections 参数的 URL 通过，而阻止所有其他 URL。

下面是一个为字母数字字符执行此方法的 ModSecurity 规则：

SecRule REQUEST_FILENAME
"@contains /_layouts/scriptresx.ashx" "chain,phase:1,block,msg:'SharePoint
Sections Param Violation - Illegal Chars"

  SecRule
ARGS:sections "!@rx ^\w+$"

在对应的 SharePoint URL 中发现任何无效字符（表示可能的攻击尝试）时，通过 ModSecurity 配置文件包含到 SharePoint web.config 文件中的规则将生成以下事件：

反馈

我们鼓励您下载并试用此工具。如果您有任何关于您对此工具的体验的反馈，可以通过 switech@microsoft.com 联系我们。

致谢

以下人员参与了 ModSecurity 的多平台工作：

•  Microsoft – ModSecurity Port for IIS
  •       Greg Wroblewski – 高级安全开发人员
  •       Suha Can – 安全研究人员 / 开发人员
•  Trustwave - ModSecurity
  •       Ziv Mador – 安全研究总监
  •       Ryan Barnett – 安全研究人员主管
  •       Breno Pinto – ModSecurity 研究人员和开发人员
•  Open 社区  - Nginx 的安全端口
  •       Alan Silva  - Locaweb 的软件工程师

我们衷心地感谢：微软的 IIS 团队的成员 Wade Hilmo 和 Nazim Lala 为解决众多技术问题提供的支持和帮助。

资源

[1]    ModSecurity 主页：https://www.modsecurity.org/

[2]    ModSecurity 的OWASP 核心规则集：https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project

[3]    https://blog.modsecurity.org/files/enough_with_default_allow_r1_draft.pdf

[4]    https://www.modsecurity.org/documentation/Securing_Web_Services_with_ModSecurity_2.0.pdf

[5]    https://www.blackhat.com/presentations/bh-dc-09/Barnett/BlackHat-DC-09-Barnett-WAF-Patching-Challenge-Whitepaper.pdf

-      Greg Wroblewski，Microsoft 安全工程中心

-      Ryan Barnett, Trustwave

阅读原文：https://learn.microsoft.com/en-us/archive/blogs/twcchina/iis-modsecurity