IIS服务器请求过滤规则防SQL注入

IIS服务器自带的“请求过滤”功能，是防御SQL注入攻击最直接、成本最低的手段之一。很多人习惯在应用层做复杂的WAF规则，却忽略了Web服务器本身就能拦截掉大量恶意请求。直接在IIS层面配置过滤规则，能让恶意请求在到达应用程序之前就被拒绝，这比事后修补漏洞要有效得多。

要写好过滤规则，必须先搞清楚SQL注入攻击在HTTP请求中长什么样。攻击者通常会在URL参数、表单提交或Cookie中插入SQL关键字和特殊字符。常见的特征包括：单引号用于闭合字符串、分号用于结束语句、两个减号用于注释后续代码，还有UNION、SELECT、DROP、EXEC等危险关键字。这些内容出现在查询字符串里，往往不是正常业务所需要的。比如一个正常的搜索框，用户输入“手机”是合理的，但输入“手机' OR 1=1--”就明显异常。IIS请求过滤可以针对这些特征设置拒绝规则，从源头切断攻击链条。

打开IIS管理器，在网站或服务器级别找到“请求筛选”图标。如果你的服务器没有显示这个图标，说明没有安装该角色服务，需要到服务器管理器的“Web服务器(IIS)”角色下，添加“安全性”中的“请求筛选”功能。进入请求筛选界面后，你会看到几个选项卡：文件扩展名、规则、隐藏段、HTTP头、查询字符串等。SQL注入防护主要用到“规则”、“查询字符串”和“HTTP头”这三个选项卡。规则可以针对URL路径、查询字符串或请求体中的特定字符串进行拦截。

在“请求筛选”界面切换到“规则”选项卡，点击右侧“添加筛选规则”。这里可以设置对特定字符串的拒绝。名称可以自定义，比如“SQL注入关键字拦截”。在“筛选依据”中选择“字符串”，在“字符串”框中填入要拦截的关键字，在“应用对象”中勾选“查询字符串”和“请求体”。建议分批次添加以下关键字：单引号、分号、两个减号、井号、百分号等特殊字符，以及UNION、SELECT、DROP、DELETE、INSERT、UPDATE、EXEC、EXECUTE、DECLARE、CAST、CONVERT等SQL关键字。每个关键字单独建立一条规则，这样便于后期排查误拦截情况。注意大小写问题，IIS的请求筛选默认是不区分大小写的，所以写“select”就能同时拦截“SELECT”和“Select”。

SQL注入攻击往往携带很长的恶意载荷，正常业务请求的查询字符串通常不会太长。在“查询字符串”选项卡中，可以设置“最大查询字符串长度(字节)”。一般建议设置为2048字节，如果业务不需要这么长，可以进一步缩小到1024甚至512字节。同时勾选“拒绝包含非ASCII字符的查询字符串”可以拦截一些编码绕过攻击，但要注意如果你的网站有中文参数，就不能勾选此项，否则正常的中文请求也会被拦截。这个需要根据实际业务情况灵活调整。

攻击者有时会把注入载荷藏在HTTP头字段里，比如User-Agent、Referer、Cookie等。在“HTTP头”选项卡中，可以限制特定头字段的长度，或者直接添加头字段的黑名单。对于Cookie，建议设置最大长度限制，一般2048字节足够。对于User-Agent和Referer，可以添加筛选规则，拦截包含SQL关键字的请求。配置方式与查询字符串规则类似，只是在“应用对象”中选择对应的HTTP头字段即可。

某些SQL注入攻击会直接在URL路径中插入恶意代码，比如针对RESTful风格的API。在“规则”选项卡中添加规则时，“应用对象”选择“URL”，可以拦截URL路径中包含危险字符的请求。常见的拦截对象包括单引号、分号、括号等。另外在“文件扩展名”选项卡中，可以拒绝一些不常用的扩展名，比如.bak、.sql、.mdb、.ldb等，防止攻击者通过URL直接访问数据库备份文件。

IIS请求筛选支持正则表达式规则，这比简单的字符串匹配要强大得多。在添加筛选规则时，“筛选依据”选择“正则表达式”。以下是一些实用的正则表达式规则示例：

检测SQL注释符号：(\-\-|#|\/\*)
检测UNION查询：\bunion\b.*\bselect\b
检测系统存储过程：\bexec\s*\(|\bexecute\s*\(|\bsp_executesql\b
检测危险函数调用：\b(cast|convert|char|declare)\s*\(
检测数字型注入：\b\d+\s*=\s*\d+\b.*\b(and|or)\b

使用正则表达式时要注意性能影响，过于复杂的正则可能会导致请求处理变慢。建议先用简单字符串规则拦截大部分攻击，再用少量精准的正则规则补充。每条正则规则都要经过充分测试，确保不会误伤正常请求。

在“HTTP谓词”选项卡中，可以限制允许的HTTP方法。如果你的网站只需要GET和POST，就把PUT、DELETE、OPTIONS、TRACE、HEAD等全部拒绝。TRACE方法尤其危险，可能被用于跨站追踪攻击。OPTIONS方法会暴露服务器支持的HTTP方法列表，关闭它可以减少信息泄露。这个配置虽然不直接防SQL注入，但能缩小攻击面，让攻击者更难探测你的服务器环境。

在“规则”选项卡的右侧，有一个“编辑功能设置”链接。点进去可以设置“最大允许内容长度(字节)”，也就是请求体的最大大小。默认值约30MB，对于大多数Web应用来说太大了。根据业务实际需要，建议设置为2MB到10MB之间。过大的请求体不仅可能携带注入载荷，还可能被用于拒绝服务攻击。同时可以设置“最大URL长度”和“最大查询字符串长度”，这两个值默认是4096和2048字节，根据实际情况可以进一步收紧。

单纯的黑名单总有被绕过的可能，更安全的做法是结合白名单策略。在“规则”选项卡中添加规则时，将“筛选行为”设置为“允许”，就可以创建白名单。比如你的某个API确实需要接收包含“select”关键词的请求，可以为这个特定URL路径创建允许规则。IIS的请求筛选规则是按照添加顺序执行的，一旦某条规则匹配成功就停止后续匹配。因此白名单规则要放在黑名单规则之前。具体操作是：先添加针对特定路径的允许规则，再添加全局的拒绝规则。这样当请求匹配到白名单路径时，就不会被后续的黑名单拦截。

规则的执行顺序直接决定了过滤效果。建议按照以下顺序组织规则：第一步，放置所有白名单允许规则，针对已知安全的URL路径或参数。第二步，放置针对特殊字符的拒绝规则，如单引号、分号、注释符等，这些字符在正常业务参数中极少出现。第三步，放置SQL关键字拒绝规则，如SELECT、UNION、DROP等。第四步，放置正则表达式规则，用于捕获组合型攻击模式。最后一步，放置全局的长度限制和字符集限制。这样的分层防御体系，既能保证正常业务不受影响，又能最大化拦截恶意请求。

配置好过滤规则后，一定要开启IIS的日志记录功能，并配置记录被拒绝的请求。在“请求筛选”界面点击“编辑功能设置”，将“拒绝操作类型”设置为“AbortRequest”或“Unauthorized”，同时确保IIS日志中记录了这些拒绝事件。通过分析被拦截的请求日志，可以发现是否有正常请求被误拦，也可以了解攻击者正在尝试什么手法。定期审查这些日志，对规则进行优化调整。建议将IIS日志接入集中式日志分析平台，设置告警规则，当拦截量突然激增时及时通知安全团队。

如果你更习惯用配置文件管理，可以直接在Web.config中编写请求过滤规则。以下是一个完整的配置示例：

<configuration>
  <system.webServer>
    <security>
      <requestFiltering>
        <requestLimits maxQueryString="2048" maxUrl="4096" maxAllowedContentLength="10485760" />
        <denyQueryStringSequences>
          <add sequence="'" />
          <add sequence="--" />
          <add sequence=";" />
          <add sequence="/*" />
          <add sequence="*/" />
        </denyQueryStringSequences>
        <filteringRules>
          <filteringRule name="SQLKeywords" scanQueryString="true" scanUrl="true">
            <denyStrings>
              <add string="union" />
              <add string="select" />
              <add string="drop" />
              <add string="delete" />
              <add string="insert" />
              <add string="update" />
              <add string="exec" />
              <add string="execute" />
              <add string="declare" />
              <add string="cast" />
              <add string="convert" />
              <add string="information_schema" />
              <add string="xp_cmdshell" />
            </denyStrings>
          </filteringRule>
        </filteringRules>
      </requestFiltering>
    </security>
  </system.webServer>
</configuration>

使用Web.config部署的好处是可以纳入版本控制，方便在多台服务器间同步配置。修改Web.config后IIS会自动检测并重新加载配置，不需要重启服务。但要注意，如果Web.config中的配置与IIS管理器中的配置冲突，以Web.config为准。建议统一使用Web.config管理请求过滤规则，避免两处配置不一致导致的问题。

任何过滤规则都可能误伤正常业务。当用户反馈某个功能无法使用时，首先要检查IIS请求筛选日志，确认是否被规则拦截。如果确认是误拦，有两种处理方式：一是修改规则使其更精准，比如把简单的关键字匹配改为带边界的正则表达式；二是为这个特定URL添加白名单允许规则。建议优先选择第一种方式，因为白名单开多了会削弱整体防护效果。对于确实需要包含SQL关键字的正常请求，比如论坛搜索功能中包含“select”关键词的帖子标题，可以考虑对参数值进行URL编码，因为IIS请求筛选检查的是原始请求字符串，编码后的内容不会被关键字规则匹配到。

IIS请求过滤是纵深防御体系中的一环，不能替代应用层的输入验证和参数化查询。正确的做法是：数据库访问层强制使用参数化查询或ORM框架，从根源上杜绝SQL注入；应用层对所有用户输入进行类型检查和格式验证；IIS请求过滤作为前置防线，拦截明显的恶意请求；最后在网络边界部署专业的WAF产品，应对更复杂的攻击手法。多层防护互相配合，即使某一层被绕过，还有其他层兜底。IIS请求过滤的优势在于零额外成本、极低延迟、不依赖第三方产品，是性价比最高的防护手段之一。

攻击手法在不断演进，过滤规则也需要定期更新。建议每季度审查一次规则列表，根据最新的攻击趋势添加新的拦截关键字。同时检查日志中被拦截但实际为正常业务的请求，及时调整规则避免影响用户体验。如果服务器上运行着多个网站，要注意规则的一致性管理，可以在服务器级别设置全局规则，再针对个别网站的特殊需求在站点级别进行覆盖。使用IIS的共享配置功能，可以将一套经过验证的请求过滤配置快速应用到服务器集群中的所有节点。