流式处理请求支持

Citrix Web App Firewall 现在使用请求端流式处理,这会显著提升性能。Web App Firewall 现在不会在处理整个请求之前缓冲整个请求,而是逐字段查看传入数据,以检查每个字段的输入是否有任何配置的安全检查冲突(SQL、XSS、字段一致性、字段格式等)。一旦字段的数据处理完成,它将转发到后端,同时继续对其余字段进行评估。这显著提高了处理时,特别是处理表单具有大量字段的大型帖子时的处理时间。

注意

Citrix Web App Firewall 支持最大 20 MB 的帖子大小,而无需流式处理。为了提高资源利用率,Citrix 建议您为大于 20 MB 的负载启用流式处理选项。此外,启用流式处理时,后端服务器必须接受分块请求。

虽然流式处理过程对用户是透明的,但由于以下更改,需要进行小的配置调整:

RegEx 模式匹配:RegEx 模式匹配现在限制为 4K,以便连续字符串匹配。

字段名称匹配:Web App Firewall 学习引擎只能区分学习名称的前 128 个字节。如果表单具有多个字段的名称具有相同字符串匹配的前 128 个字节,则学习引擎可能无法区分它们。同样,部署的放宽规则可能会无意中放宽所有这些字段。

在规范化过程中完成的删除空格、百分比解码、unicode 解码和字符集转换,在安全检查检查之前进行。128 字节限制适用于 UTF-8 字符格式的字段名称的规范化表示形式。ASCII 字符是 1 个字节,但某些国际语言中字符的 UTF-8 表示形式可能范围从 1-4 个字节。如果将名称中的每个字符转换为 UTF-8 格式时需要 4 个字节,则只有名称中的前 32 个字符可以通过这种语言的学习规则来区分。

字段一致性检查:启用字段一致性检查后,会话中的所有表单现在都会基于 Web App Firewall 插入的“as_fid”标签存储,而不考虑“action_url”。

  • 表单字段一致性的强制性表单标记:启用字段一致性检查时,也必须启用表单标记。如果表单标记已关闭,则字段一致性保护可能不起作用。
  • 无会话表单字段一致性:当启用无会话字段一致性参数时,Web App Firewall 不再执行表单的“GET”到“POST”转换。表单标记也是无会话字段一致性所必需的。
  • 篡改 as_fid:如果在篡改 as_fid 后提交表单,它现在触发字段一致性冲突,即使没有其他字段被篡改。在非流式处理请求中,允许这样做,因为可以使用存储在会话中的“action_url”来验证表单。

签名:签名现在具有以下规格:

  • 位置:现在强制要求必须为每个模式指定位置。规则中的所有模式都 必须 有一个<Location> 标签。

  • 快速匹配:所有签名规则必须具有快速匹配模式。如果没有快速匹配模式,将尝试在可能的情况下选择一个模式。快速匹配必须是文字字符串,但如果某些 PCRE 包含可用的文字字符串,则可以使用它们进行快速匹配。

  • 弃用位置:签名规则不再支持以下位置。

    • HTTP_ 任何
    • 甜点饼干
    • 标题
    • 重新编制的标题
    • 创建一套曲奇饼干

XSS/SQL 转换:原始数据用于转换,因为 SQL 特殊字符(单引号 (‘)、反斜杠 () 和分号 (;))和 XSS 标签 ((<) and (>)) 在所有语言中都是相同的,不需要数据的规范化。这些字符的所有表示形式(如 HTML 实体编码、百分比编码或 ASCII)都将被评估为转换操作。

Web App Firewall 不再检查 XSS 转换操作的属性名称和值。现在,只有 XSS 属性名称在流处理时才会被转换。

处理 XSS 标签: 作为 10.5.e 版本中流更改的一部分,跨站点脚本标签的 Web App Firewall 处理已更改。在早期版本中,打开括号 (<), or close bracket (>) 或打开和关闭括号 (<>) 的存在被标记为跨站点脚本冲突。该行为在 10.5.e 构建中发生了变化。仅存在开括号字符 (<) 或只存在近括号字符 (>) 不再被视为攻击。当一个打开括号字符 (<) is followed by a close bracket character (>) 时,跨站点脚本攻击被标记。这两个字符必须按正确的顺序 (< followed by >) 显示,才能触发跨站点脚本冲突。

注意

SQL 冲突日志中的更改消息:作为 10.5.e 版本中流更改的一部分,我们现在以块形式处理输入数据。RegEx 模式匹配现在限制为 4K 以进行连续字符串匹配。通过此更改,SQL 冲突日志消息可能包含与早期版本相比不同的信息。输入中的关键字和特殊字符可以用大量字节分隔。我们现在在处理数据时跟踪 SQL 关键字和特殊字符串,而不是缓冲整个输入值。除了字段名称之外,日志消息现在还包括 SQL 关键字或 SQL 特殊字符,或 SQL 关键字和 SQL 特殊字符,具体取决于配置的设置。输入的其余部分不再包含在日志消息中,如以下示例所示:

示例:

在 10.5 中,当 Web App Firewall 检测到 SQL 冲突时,整个输入字符串可能包含在日志消息中,如下所示:

SQL 关键字检查失败的字段 文本 = “从 testbed1 中选择一个名称;\(;\)”.*<blocked>

在 11.0 中,我们只记录日志消息中的字段名称、关键字和特殊字符(如果适用),如下所示:

字段text="select(;)" <blocked> 的 SQL 关键字检查失败 此更改适用于包含 应用程序/x-www 表单编码多部分/表单数据文本 /x-gwt-rpc内容类型的请求。处理 JSONXML 有效负载期间生成的日志消息不受此更改的影响。

RAW POST 主体:安全检查检查总是在 RAW POST 主体上完成。

表单 ID:Web App Firewall 插入了“as_fid”标签,这是表单的计算散列,对于用户会话来说将不再是唯一的。无论用户或会话如何,它现在对于特定表单具有相同的值。

字符集:如果请求没有字符集,则在处理请求时使用应用程序配置文件中指定的默认字符集。

计数器

添加前缀为“se_”和“appfwreq_”的计数器以分别跟踪流式处理引擎和 Web App Firewall 流式处理引擎请求计数器。

nsconsmg -d statswt0 -g se_err_

nsconsmg -d statswt0 -g se_tot_

nsconsmg -d statswt0 -g se_cur_

nsconsmg -d statswt0 -g appfwreq_err_

nsconsmg -d statswt0 -g appfwreq_tot_

nsconsmg -d statswt0 -g appfwreq_cur_

_err 计数器:指示应该成功但由于内存分配问题或其他资源紧缩而失败的罕见事件。

_tot 计数器:不断增加的计数器。

_cur 计数器:指示基于当前交易记录的使用情况不断更改的当前值的计数器。

提示

  • Web App Firewall 安全检查应与以前完全相同。
  • 安全检查的处理没有设置顺序。
  • 响应端处理不受影响,并保持不变。
  • 如果使用 CVPN,则不会进行流媒体播放。

重要

计算 Cookie 长度: 在 10.5.e 版本(在 59.13xx.e 版本之前的几个临时增强版本中)和 11.0 版本(在 65.x 之前的版本中)中,Web App Firewall 对 Cookie 头的处理发生了更改。在这些版本中,每个 cookie 都是单独评估的,如果 cookie 标头中接收到的任何一个 cookie 的长度超过配置的 BufferOverflowMaxCookieLength,则触发缓冲区溢出冲突。由于此更改,可能允许在 10.5 和更早版本版本中被阻止的请求,因为不计算整个 cookie 标头的长度来确定 cookie 长度。在某些情况下,转发到服务器的 Cookie 总大小可能大于接受的值,并且服务器可能会响应“400 错误请求”。

请注意,此更改已被恢复。10.5.e->59.13xx.e 和后续 10.5.e 增强版本以及 11.0 版本 65.x 和后续版本中的行为现在类似于版本 10.5 的非增强版本。现在在计算 Cookie 的长度时考虑整个原始 Cookie 标头。在确定 cookie 长度时,还包括周围空格和分号 (;) 字符分隔名称-值对。

流式处理请求支持