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