Citrix Web Application Firewall 简介
Citrix Web App Firewall 可防止安全漏洞、数据丢失以及可能对访问敏感业务或客户信息的网站进行未经授权的修改。它通过过滤请求和响应、检查它们是否存在恶意活动的证据以及阻止显示此类活动的请求来实现这一目标。您的站点不仅受到常见类型的攻击的保护，而且还受到尚未知的新攻击的保护。除了保护 Web 服务器和网站免遭未经授权的访问之外，Web App Firewall 还可防止传统 CGI 代码或脚本、Web 框架、Web 服务器软件和其他底层操作系统中的漏洞。
Citrix Web App Firewall 可作为独立设备或 Citrix ADC 虚拟设备 (VPX) 上的功能使用。在 Web App Firewall 文档中，术语 Citrix ADC 是指运行 Web App Firewall 的平台，无论该平台是专用防火墙设备、也配置了其他功能的 Citrix ADC，还是 Citrix ADC VPX。
要使用 Web App Firewall，您必须至少创建一个安全配置，以阻止违反为受保护网站设置的规则的连接。您可能想要创建的安全配置的数量取决于网站的复杂性。有时，单个配置就足够了。在其他情况下，特别是那些包括交互式网站、访问数据库服务器的网站、带购物车的在线商店的情况下，您可能需要几种不同的配置来最好地保护敏感数据，而不会浪费大量精力处理不易受某些类型影响的内容攻击。您通常可以将影响所有安全配置的全局设置的默认设置保持不变。但是，如果全局设置与配置的其他部分冲突，或者您希望对其进行自定义，则可以更改全局设置。
Web 应用程序安全性
Web 应用程序安全性是通过使用 HTTP 和 HTTPS 协议进行通信的计算机和程序的网络安全性。这是一个安全缺陷和弱点比比皆是广泛的领域。服务器和客户端上的操作系统都存在安全问题，容易受到攻击。Web 服务器软件和支持网站的技术，例如 CGI、Java、JavaScript、PERL 和 PHP 都存在潜在的漏洞。与启用 Web 的应用程序通信的浏览器和其他客户端应用程序也存在漏洞。使用除最简单的 HTML 以外的任何技术的网站（包括允许与访问者互动的任何网站）的网站往往存在自己的漏洞。
过去，破坏安全通常只是一种烦恼，但今天的情况很少发生。例如，黑客获得 Web 服务器访问权限并对网站进行未经授权的修改（破坏）的攻击过去是常见的。它们通常是由黑客发起的，他们除了向黑客同胞展示自己的技能或使目标人员或公司尴尬之外，没有动机。然而，大多数目前的安全冲突行为都是出于对金钱的渴望。大多数人都试图实现以下一个或两个目标：获取敏感且可能有价值的私人信息，或者获得对网站或 Web 服务器的未经授权的访问和控制。
某些形式的 Web 攻击侧重于获取个人信息。即使是针对足够安全以阻止攻击者完全控制的网站，这些攻击通常也可能发生。攻击者可以从网站获取的信息包括客户姓名、地址、电话号码、社会保险号码、信用卡号码、医疗记录和其他私人信息。攻击者可以使用这些信息或将其出售给他人。通过这种攻击获得的大部分信息受到法律保护，所有这些信息都受到习俗和期望的保护。这种类型的违规行为可能会对私人信息遭到泄露的客户造成严重后果。充其量，这些客户必须保持警惕，以防止他人滥用信用卡、以自己的名义开设未经授权的信用账户或直接侵占其身份（身份盗用）。在最坏的情况下，客户可能面临被毁的信用评级，甚至被指责为他们没有参与的犯罪活动。
其他网络攻击的目的是获得对网站或服务器的控制权（或 损害）其运行的服务器，或两者兼而有。获得对网站或服务器的控制权的黑客可以使用该网站或服务器托管未经授权的内容、充当托管在另一个 Web 服务器上的内容的代理、提供 SMTP 服务以发送未经请求的批量电子邮件，或者提供 DNS 服务以支持其他受感染的 Web 服务器上的此类活动。托管在受损的 Web 服务器上的大多数网站都会促进可疑或彻底的欺诈性业务。例如，大多数网络钓鱼网站和儿童剥削网站都托管在受到攻击的 Web 服务器上。
保护您的网站和 Web 服务免受这些攻击需要多层防御，既能阻止具有可识别特征的已知攻击，又能防止未知攻击，因为这些攻击通常会被检测到，因为它们看起来不同于网站和 Web 的正常流量服务。
已知的网络攻击
您的网站的第一道防线是防范已知存在的大量攻击，网络安全专家已经观察和分析了这些攻击。针对基于 HTML 的网站的常见攻击类型包括：
- 缓冲区溢出攻击。向 Web 服务器发送长 URL、长 cookie 或长信息会导致系统挂起、崩溃或提供对底层操作系统的未经授权的访问。缓冲区溢出攻击可用于访问未经授权的信息、破坏 Web 服务器或两者。
- Cookie 安全攻击。将修改后的 cookie 发送到 Web 服务器，通常希望通过使用伪造的凭据获取对未经授权的内容的访问权限。
- 强制浏览。直接访问网站上的 URL，而无需导航到主页上带有超链接的 URL 或网站上其他常见的起始 URL。强制浏览的个别实例可能表示用户在您的网站上添加了书签，但反复尝试访问不存在的内容或用户绝不能直接访问的内容，通常表示对网站安全性的攻击。强制浏览通常用于访问未经授权的信息，但也可以与缓冲区溢出攻击结合使用，以试图危害您的服务器。
- Web 表单安全攻击。以 Web 表单向您的网站发送不适当的内容。不当内容可能包括修改后的隐藏字段、HTML 或代码，仅用于字母数字数据的字段中的代码，只接受短字符串的字段中的过长字符串，只接受整数的字段中的字母数字字符串，以及网站不接受的各种其他数据预计将以该网络形式收到。Web 表单安全攻击可用于从您的网站获取未经授权的信息，也可以直接破坏网站，通常与缓冲区溢出攻击结合使用时。
对 Web 表单安全性的两种专门攻击类型值得特别提及：
- SQL 注入攻击。以 Web 表单或作为 URL 的一部分发送一个或多个活动的 SQL 命令，目的是使 SQL 数据库运行一个或多个命令。SQL 注入攻击通常用于获取未经授权的信息。
- 跨站点脚本攻击。使用网页上的 URL 或脚本违反同源策略，该策略禁止任何脚本从其他网站获取属性或修改任何内容。由于脚本可以获取信息和修改网站上的文件，因此允许脚本访问其他网站上的内容可以为攻击者提供获取未经授权的信息、破坏 Web 服务器或两者兼而有的手段。
针对基于 XML 的 Web 服务的攻击通常至少分为以下两类：试图向 Web 服务发送不适当的内容，或试图破坏 Web 服务的安全性。针对基于 XML 的 Web 服务的常见攻击类型包括：
- 恶意代码或对象。包含代码或对象的 XML 请求，这些代码或对象可以直接获取敏感信息，或者可以让攻击者控制 Web 服务或底层服务器。
- 格式不良的 XML 请求。不符合 W3C XML 规范的 XML 请求，因此可能会在不安全的 Web 服务上冲突安全性
- 拒绝服务 (DoS) 攻击。重复发送大量 XML 请求，其目的是压倒目标 Web 服务并拒绝合法用户访问 Web 服务。
除了基于 XML 的标准攻击外，XML Web 服务和 Web 2.0 站点还易受 SQL 注入和跨站点脚本攻击的攻击，如下所述：
- SQL 注入攻击。在基于 XML 的请求中发送一个或多个活动的 SQL 命令，目的是使 SQL 数据库运行该命令。与 HTML SQL 注入攻击一样，XML SQL 注入攻击通常用于获取未经授权的信息。
- 跨站点脚本攻击。使用基于 XML 的应用程序中包含的脚本冲突同源策略，该策略不允许任何脚本从其他应用程序获取属性或修改任何内容。由于脚本可以使用 XML 应用程序获取信息和修改文件，因此允许脚本访问属于不同应用程序的内容，攻击者可以获取未经授权的信息、破坏应用程序或两者兼有
通常可以通过筛选网站流量来阻止已知的 Web 攻击，这些特征（签名）的特定特征（签名）始终出现在特定攻击中，绝不能出现在合法流量这种做法的优点是，需要的资源相对较少，造成误报风险相对较小。因此，它是抵御对网站和 Web 服务的攻击以及配置基本签名保护的重要工具。
未知的网络攻击
对网站和应用程序的最大威胁不是来自已知的攻击，而是来自未知的攻击。大多数未知攻击分为两类：安全公司尚未制定有效防御的新攻击（零日攻击），以及对特定网站或 Web 服务而不是许多网站或 Web 服务进行精心定位的攻击（矛攻击）。这些攻击与已知的攻击一样，旨在获取敏感的私人信息、破坏网站或 Web 服务并允许它们用于进一步的攻击，或者这两个目标。
零日攻击是对所有用户的主要威胁。这些攻击通常与已知攻击类型相同；零日攻击通常涉及注入的 SQL、跨站点脚本、跨站点请求伪造或类似已知攻击的其他类型的攻击。通常，它们针对目标软件、网站或 Web 服务的开发人员不知道或已经了解的漏洞。因此，安全公司尚未开发防御这些攻击的防御措施，即使它们已经开发出防御措施，用户也没有获得和安装补丁程序，也没有执行防御这些攻击所需的解决方法。从发现零日攻击到可用防御（漏洞窗口）之间的时间正在缩短，但是犯罪者仍然可以指望许多网站和 Web 服务在几小时甚至几天内缺乏任何针对攻击的具体保护。
矛攻击是一个主要威胁，但对于更多选择的用户群体来说。一种常见的矛攻击，即长矛过程，是针对特定银行或金融机构的客户，或（不常见的）针对特定公司或组织的员工。与其他网络钓鱼不同，它们通常是粗鲁的伪造，熟悉该银行或金融机构的实际通信的用户都能识别出来，矛 Phies 是完美而有说服力的。它们可以包含特定于个人的信息，首先没有任何陌生人必须知道或能够获得这些信息。因此，长矛网络钓鱼者能够说服目标提供所要求的信息，然后网络钓鱼者可以利用这些信息掠夺账户，处理从其他来源非法获得的资金，或获取其他更敏感的信息。
这两种类型的攻击都具有通常可以检测到的特性，尽管不像标准签名那样使用查找特定特性的静态模式。检测这些类型的攻击需要更复杂和资源密集型的方法，例如启发式筛选和积极的安全模型系统。启发式筛选外观，不是针对特定模式，而是针对行为模式。正面安全模型系统模拟它们所保护的网站或 Web 服务的正常行为，然后阻止不适合正常使用模式的连接。基于 URL 的安全检查和基于 Web 表单的安全检查分析您网站的正常使用情况，然后使用启发式和积极安全性来阻止异常或意外流量，控制用户与您的网站进行交互的方式。正确设计和部署的启发式安全性和正面安全性都可以捕获特征码缺少的大多数攻击。但是，它们需要的资源比签名要多得多，您必须花费一些时间正确配置它们以避免误报。因此，它们不被用作主要防线，而是用作签名的备份或其他资源密集程度较低的方法。
除了特征码之外，通过配置这些高级保护功能，您可以创建混合安全模型，使 Web App Firewall 能够针对已知和未知攻击提供全面保护。
Citrix Web Application Firewall 的工作原理
安装 Web App Firewall 时，您将创建初始安全配置，其中包括策略、配置文件和签名对象。策略是一个规则，用于标识要筛选的流量，配置文件标识了筛选流量时允许或阻止的模式和行为类型。最简单的模式（称为签名）不在配置文件中指定，而是在与配置文件关联的签名对象中指定。
签名是与已知攻击类型相匹配的字符串或模式。Web App Firewall 包含七个类别的超过一千个签名，每个签名都针对特定类型的 Web 服务器和 Web 内容的攻击。在发现新威胁时，Citrix 会使用新签名更新列表。在配置过程中，您可以指定适用于需要保护的 Web 服务器和内容的签名类别。签名提供良好的基本保护，处理开销较低。如果您的应用程序有特殊漏洞，或者您检测到没有签名的针对这些漏洞的攻击，您可以添加自己的签名。
更高级的保护称为安全检查。安全检查是对特定模式或行为类型的请求进行更严格的算法检查，这些行为可能表明受到攻击或对受保护的网站和 Web 服务构成威胁。例如，它可以识别尝试执行可能会冲突安全性的特定类型操作的请求，或者识别包含敏感私人信息（如社会安全号或信用卡号）的响应。在配置过程中，您可以指定适用于需要保护的 Web 服务器和内容的安全检查。安全检查是限制性的。如果您在配置合法请求和响应时未添加适当的异常（放宽），其中许多可能会阻止它们。如果您使用自适应学习功能，可以观察网站的正常使用情况并创建建议的例外情况，确定所需的例外情况并不困难。
Web App Firewall 可以作为第 3 层网络设备或第 2 层网络桥接安装在您的服务器和用户之间，通常是在您公司的路由器或防火墙后面。它必须安装在一个位置，以便它能够拦截要保护的 Web 服务器与用户访问这些 Web 服务器的中心或交换机之间的流量。然后，您将网络配置为将请求发送到 Web App Firewall（而不是直接发送到 Web 服务器），并将响应 Web App Firewall（而不是直接发送给您的用户）。Web App Firewall 会在将流量转发到最终目标之前对流量进行筛选，同时使用其内部规则集以及您的添加和修改。它会阻止或使其检测到有害的任何活动变得无害，然后将剩余的流量转发到 Web 服务器。下图概述了筛选过程。
注意 ： 该图省略了策略对传入流量的应用。它说明了策略处理所有请求的安全配置。此外，在此配置中，已配置一个签名对象并与配置文件关联，并在配置文件中配置了安全检查。
图 1. Web App Firewall 过滤流程图
如图所示，当用户请求受保护网站上的 URL 时，Web App Firewall 首先检查请求以确保其与签名不匹配。如果请求与签名匹配，Citrix Web Application Firewall 会显示错误对象（位于 Web App Firewall 设备上的网页，您可以使用导入功能进行配置），或者将请求转发到指定的错误 URL（错误页面）。签名不需要安全检查那么多的资源，因此在运行任何安全检查之前检测和停止签名检测到的攻击可以减少服务器上的负载。
如果请求通过签名检查，Web App Firewall 将应用已启用的请求安全检查。请求安全检查会验证请求是否适用于您的网站或 Web 服务，并且不包含可能构成威胁的材料。例如，安全检查检查请求是否有迹象，指示请求可能是意外类型、请求意外内容或包含意外且可能是恶意的 Web 表单数据、SQL 命令或脚本。如果请求未通过安全检查，Web App Firewall 会对请求进行清理，然后将其发送回 Citrix ADC 设备（或 Citrix ADC 虚拟设备），或显示错误对象。如果请求通过了安全检查，则会将其发送回 Citrix ADC 设备，该设备完成任何其他处理并将请求转发到受保护的 Web 服务器。
当网站或 Web 服务向用户发送响应时，Web App Firewall 会应用已启用的响应安全检查。响应安全检查将检查敏感私人信息泄露、网站破损迹象或其他不得存在的内容的响应。如果响应未通过安全检查，Web App Firewall 会删除必须不存在的内容或阻止响应。如果响应通过安全检查，则会将响应发回 Citrix ADC 设备，由该设备将响应转发给用户。
Citrix Web Application Firewall 功能
基本的 Web App Firewall 功能是策略、配置文件和签名，它们提供混合安全模型， 如 [已知 Web 攻击](/zh-cn/citrix-adc/13/application-firewall/introduction/web-application-security.html)、 [未知 Web 攻击](/zh-cn/citrix-adc/13/application-firewall/introduction/web-application-security.html)和 Web App Firewall 的工作原理中所述。特别值得注意的是学习功能，它可以观察到受保护应用程序的流量，并为某些安全检查建议适当的配置设置。
导入功能管理您上载到 Web App Firewall 的文件。然后，Web App Firewall 将在各种安全检查中使用这些文件，或者在响应与安全检查匹配的连接时使用这些文件。
您可以使用日志、统计信息和报告功能评估 Web App Firewall 的性能，并确定可能需要更多保护。
Citrix Web Application Firewall 如何修改应用程序流量
Citrix Web Application Firewall 通过修改以下内容影响其保护的 Web 应用程序的行为：
- cookie
- HTTP 标头
- 表单/数据
Citrix Web Application Firewall 会话 Cookie
为了保持会话状态，Citrix ADC Web App Firewall 会生成自己的会话 cookie。此 Cookie 仅在 Web 浏览器和 Citrix ADC Web 应用程序防火墙之间传递，而不是传递到 Web 服务器。如果任何黑客试图修改会话 cookie，应用程序防火墙会在将请求转发到服务器之前删除 Cookie，并将请求视为新的用户会话。只要网络浏览器打开，会话 cookie 就会存在。当 Web 浏览器关闭时，应用程序防火墙会话 cookie 将变得更加有效。会话状态维护客户端访问的 URL 和表单的信息。
可配置的 Web App Firewall 会话 cookie 为citrix_ns_id。
从 Citrix ADC 版本 12.1 54 和 13.0 开始，Cookie 一致性是无会话的，它不强制设备 citrix_ns_id 生成的添加会话 Cookie。
Citrix Web App Firewall Cookie
许多 Web 应用程序会生成 Cookie 来跟踪用户或会话特定信息。此信息可以是用户首选项或购物车商品。Web 应用程序 cookie 可以是以下两种类型之一：
- 持久性 Cookie -这些 Cookie 存储在本地计算机上，并在您下次访问网站时再次使用。这种类型的 cookie 通常包含有关用户的信息，例如登录、密码或首选项。
- 会话或临时 Cookie -这些 Cookie 仅在会话期间使用，并在会话终止后销毁。此类 Cookie 包含应用程序状态信息，例如购物车项目或会话凭据。
黑客可能会尝试修改或窃取应用程序 Cookie，以劫持用户会话或伪装为用户。应用程序防火墙通过哈希应用程序 Cookie，然后添加更多带有数字签名的 cookie 来防止此类尝试。通过跟踪 Cookie，应用程序防火墙可确保客户端浏览器和应用程序防火墙之间的 Cookie 不会被修改或破坏。应用程序防火墙不会修改应用程序 cookie。
Citrix Web Application Firewall 将生成以下默认 Cookie 以跟踪应用程序 Cookie：
-
持久性 Cookie：
citrix_ns_id_wlf。注意：wlf 代表将永远活着。 -
会话或暂时 Cookie：
citrix_ns_id_wat。注意：佛塔代表将采取暂时操作。 为了跟踪应用程序 cookie，应用程序防火墙将持久性或会话应用程序 cookie 分组在一起，然后将所有 cookie 散列并签名在一起。因此，应用程序防火墙生成一个wlfcookie 来跟踪所有持久性应用程序 Cookie，另一个watcookie 来跟踪所有应用程序会话 Cookie。
下表显示了应用程序防火墙根据 Web 应用程序生成的 Cookie 生成的 Cookie 的数量和类型：
| Citrix ADC Web App Firewall 之前 | 更改为 |
|---|---|
| 一个永久性 cookie | 持久 cookie： citix_ns_id_wlf
|
| 一个暂时的饼干 | 暂时饼干： citix_ns_id_wat
|
| 多个持久性 cookie，多个瞬态 cookie | 一个持久饼干： citrix_ns_id_wlf，一个暂时性饼干： citix_ns_id_wat
|
Citrix Web App Firewall 允许对应用程序 cookie 进行加密。应用程序防火墙还提供了一个选项来代理应用程序发送的会话 cookie，方法是将其与应用程序防火墙会话数据一起存储，而不是将其发送到客户端。当客户端向包含应用程序防火墙会话 cookie 的应用程序发送请求时，应用程序防火墙会话 cookie 的应用程序会将发送的 cookie 重新插入到请求中，然后再将请求发送到源应用程序。应用程序防火墙还允许将 HTTPOLly 和/或安全标志添加到 cookie。
应用程序防火墙如何影响 HTTP 标头
HTTPS 请求和 HTTPS 响应都使用标题发送有关一条或多条 HTTPS 消息的信息。标题是一系列行，每行都包含一个名称，后跟冒号和一个空格以及一个值。例如，主机标头具有以下格式：
Host: www.citrix.com
某些标头字段同时用于请求和响应标头，而其他标头字段仅适用于请求或响应。应用程序防火墙可能会在一个或多个 HTTPS 请求或响应中添加、修改或删除某些标头，以维护应用程序的安全性。
Citrix Web Application Firewall 删除的请求标头
许多与缓存相关的请求标头都会被删除，以查看会话上下文中的每个请求。同样，如果请求包含允许 Web 服务器发送压缩响应的编码标头，应用程序防火墙将删除此标头，因此 Web App Firewall 会检查未压缩服务器响应中的内容，以防止任何敏感数据泄露到客户端。
应用程序防火墙会删除以下请求标头：
- 范围 — 用于从失败或部分文件传输中恢复。
- If Range — 允许客户端在其缓存中包含该对象的一部分时检索部分对象（条件 GET）。
- IF 修改自 — 如果在此字段中指定的时间后未修改请求的对象，则不会从服务器返回实体。你得到一个 HTTP 304 未修改的错误。
- If-None-Match — 允许以最小的开销高效更新缓存的信息。
- 接受编码 — 特定对象（如 gzip）允许使用哪些编码方法。
Citrix Web Application Firewall 修改的请求标头
如果 Web 浏览器使用 HTTP/1.0 或更早的协议，则浏览器在收到每个响应后不断打开和关闭 TCP 套接字连接。这会增加 Web 服务器的开销，并防止维护会话状态。HTTP/1.1 协议允许连接在会话期间保持打开状态。应用程序防火墙修改以下请求标头，以便在应用程序防火墙和 Web 服务器之间使用 HTTP/1.1，而不考虑 Web 浏览器使用的协议： 连接：保持活动状态
Citrix Web Application Firewall 添加的请求标头
应用程序防火墙充当反向代理，并将会话的原始源 IP 地址替换为应用程序防火墙的 IP 地址。因此，Web 服务器日志中记录的所有请求都表示请求是从应用程序防火墙发送的。
Citrix Web Application Firewall 删除的响应标头
应用程序防火墙可能会阻止或修改内容，例如删除信用卡号或剥离注释，这可能会导致大小不匹配。为了防止出现这种情况，应用程序防火墙会删除以下标头：
内容长度 — 表示发送给收件人的邮件大小。 应用程序防火墙修改的响应标头
应用程序防火墙修改的许多响应标头都与缓存有关。必须修改 HTTP (S) 响应中的缓存头，以强制 Web 浏览器始终向 Web 服务器发送最新数据的请求，而不是使用本地缓存。但是，某些 ASP 应用程序使用单独的插件来显示动态内容，并且可能需要在浏览器中临时缓存数据的能力。若要在启用 FFC、URL 关闭或 CSRF 检查等高级安全保护时允许临时缓存数据，应用程序防火墙使用以下逻辑在服务器响应中添加或修改缓存控制标头：
- 如果服务器发送 Pragma: no-cache，则应用程序防火墙不会进行任何修改。
- 如果客户端请求是 HTTP 1.0，则应用程序防火墙会插入 Pragma：无缓存。
- 如果客户端请求是 HTTP 1.1 并且具有缓存控制：无存储区，则应用程序防火墙不会进行任何修改。
-
如果客户端请求是 HTTP 1.1，并且服务器响应具有没有存储或没有缓存指令的缓存控制标头，则应用程序防火墙不会进行任何修改。
- 如果客户端请求是 HTTP 1.1，并且服务器响应具有无缓存控制标头或缓存控制标头没有存储或无缓存指令，则应用程序防火墙将完成以下任务：
- 插入缓存控制：最大年龄 = 3，必须重新验证，私有。
- 插入 X 缓存控件 Orig = 缓存控件头的原始值。
- 删除上次修改的标题。
- 替换 Etag。
- 插入 X-过期-原始= 服务器发送的过期标头的原始值。
- 修改 Expres 标题并将网页的过期日期设置为过去，因此始终会再次获取该页面。
- 修改接受范围并将其设置为无。
要在应用程序防火墙更改响应时替换客户端浏览器中的临时缓存数据，例如，对于 StripComments、XOUT /删除safeObject、xout 或删除信用卡或 URL 转换，应用程序防火墙将采取以下操作：
- 在转发到客户端之前，从服务器删除上次修改的内容。
- 将 Etag 替换为应用程序防火墙确定的值。
Citrix Web App Firewall 添加的响应标头
-
Transfer-Encoding：分块。此标头将信息流回客户端，而无需在发送响应之前知道响应的总长度。此标题是必需的，因为内容长度标题已被删除。 -
Set-Cookie：应用程序防火墙添加的 Cookie。 -
Xet-Cookie：如果会话有效且响应未在缓存中过期，则您可以从缓存中提供服务，而不必发送新的 cookie，因为会话仍然有效。在这种情况下，设置 Cookie 被更改为 Xet Cookie。对于网络浏览器。
如何影响表单数据
应用程序防火墙可防止试图修改服务器发送的原始表单内容的攻击。它还可以防止跨站点请求伪造攻击。应用程序防火墙通过在页面中插入隐藏的表单标记 as_fid 来完成。
示例：<input type="hidden" name="as_fid" value="VRgWq0I196Jmg/+LOY7C" />
隐藏字段作为 _fid 用于实现字段一致性。应用程序防火墙使用此字段跟踪表单的所有字段，包括隐藏的字段名称/值对，并确保服务器发送的表单的任何字段都不会在客户端更改。CSRF 检查还使用此唯一的表单标记 as_fid 来确保用户提交的表单在此会话中提供给用户，并且没有黑客试图劫持用户会话。
无会话表单检查
应用程序防火墙还提供了使用无会话字段一致性保护表单数据的选项。这对于表单可能具有大量动态隐藏字段的应用程序非常有用，这些字段会导致应用程序防火墙每个会话分配较高的内存。无会话字段一致性检查是通过插入另一个隐藏字段作为 _ffc_field 来完成的，只针对 POST 请求或基于配置的设置为 GET 和 POST 请求。应用程序防火墙将方法 GET 更改为 POST 时，它将表单转发到客户端。然后，设备在将方法提交回服务器时将其还原为 GET。as_ffc_field 值可以很大，因为它包含所提供的表单的加密摘要。以下是无会话窗体检查的示例：
<input type="hidden" name="as_ffc_field" value="CwAAAAVIGLD/luRRi1Wu1rbYrFYargEDcO5xVAxsEnMP1megXuQfiDTGbwk0fpgndMHqfMbzfAFdjwR+TOm1oT
+u+Svo9+NuloPhtnbkxGtNe7gB/o8GlxEcK9ZkIIVv3oIL/nIPSRWJljgpWgafzVx7wtugNwnn8/GdnhneLCJTaYU7ScnC6LexJDLisI1xsEeONWt8Zm
+vJTa3mTebDY6LVyhDpDQfBgI1XLgfLTexAUzSNWHYyloqPruGYfnRPw+DIGf6gGwn1BYLEsRHKNbjJBrKpOJo9JzhEqdtZ1g3bMzEF9PocPvM1Hpvi5T6VB
/YFunUFM4f+bD7EAVcugdhovzb71CsSQX5+qcC1B8WjQ==" />
<!--NeedCopy-->
HTML 注释剥离
应用程序防火墙还提供了一个选项，用于在将响应中的所有 HTML 注释发送到客户端之前去除它们。这不仅影响表单，而且影响所有响应页面。应用程序防火墙定位并删除嵌入在“<!-”与“->”注释标记之间的任何文本。标记仍然是为了表示 HTML 源代码的该位置存在注释。嵌入在任何其他 HTML 或 JavaScript 标签中的任何文本都将被忽略。 某些应用程序可能无法正常工作，如果它们在注释标签中嵌入了 JavaScript。对应用程序防火墙剥离注释之前和之后的页源代码进行比较，有助于确定任何被剥离的注释是否嵌入了所需的 JavaScript。
信用卡保护
应用程序防火墙提供了一个选项，可以检查响应的标题和正文，并在将响应转发给客户端之前删除或取出信用卡号码。目前应用防火墙为以下主要信用卡提供保护：American Express、Diners Club、Discover、JCB、MasterCard 和 Visa。X-out 操作独立于“阻止”操作。
安全对象保护
与信用卡号类似，通过使用应用程序防火墙安全对象安全检查来删除或 X-out 响应中的敏感内容，也可以防止泄露其他敏感数据。
跨站脚本转变了行动
为跨站点脚本启用转换后，Web App Firewall 会在请求 "<" into "%26lt;" and ">" into "%26gt;" 中发生变化。如果启用了 Web App Firewall 中的 CheckRequeAaders 设置，则 Web App Firewall 将检查请求标头并在标题和 Cookie 中转换这些字符。转换操作不会阻止或转换最初由服务器发送的值。Web App Firewall 允许有一组用于跨站点脚本的默认属性和标签。此外，还提供了被拒绝的跨站点脚本模式的默认列表。可以通过选择签名对象并单击 GUI 中的 “ 管理 SQL/ 跨站点脚本模式” 对话 框来自定义这些内容。
转换 SQL 特殊字符
应用程序防火墙具有以下 SQL 特殊字符的默认转换规则：
| 原术语 | 更改为 | 转型 |
|---|---|---|
| ‘（单引号，即 %27） | ” | 另一个单引号 |
| \（反斜杠为 %5C） | |添加了另一个反斜杠 | |
| ; (分号为 %3B) | 丢弃 |
当启用特殊字符的转换并且 CheckRequeAaders 设置为开时，特殊字符的转换也会在标题和 Cookie 中进行。 注意：某些请求标头（如用户代理、接受编码）通常包含分号，可能会受到 SQL 转换的影响。
Citrix Web 应用程序防火墙行为，其中它会损坏 HEEE 标头
- 每当 NetScaler 收到包含 HEIGHE 标头的 HTTP 请求时，NetScaler 会代表后端服务器向客户端发送 “期望：100-继续” 响应。
- 此行为是因为在将请求转发到服务器之前必须对整个请求运行应用程序防火墙保护，NetScaler 必须从客户端获取整个请求。
- 在收到
100 continue响应时，客户端将发送完成请求的剩余请求部分。 - NetScaler 然后运行所有保护，然后将请求转发到服务器。
- 现在，随着 NetScaler 正在转发完整请求，初始请求中的 HEWE 标头将过时，结果 NetScaler 会损坏此标头并将其发送到服务器。
- 接收请求时的服务器忽略任何已损坏的标头。