Citrix ADC

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 服务。

已知的网络攻击

您的网站的第一道防线是防御已知存在的大量攻击,并由 Web 安全专家观察和分析。针对基于 HTML 的网站的常见攻击类型包括:

  • 缓冲区溢出攻击。向 Web 服务器发送极长的 URL、极长的 cookie 或其他极长的信息,希望使其或底层的操作系统挂起、崩溃或使攻击者能够访问底层操作系统。缓冲区溢出攻击可用于访问未经授权的信息、破坏 Web 服务器或两者。
  • Cookie 安全攻击。将修改后的 cookie 发送到 Web 服务器,通常希望通过使用伪造的凭据获取对未经授权的内容的访问权限。
  • 强制浏览。直接访问网站上的 URL,而无需通过主页上的超链接或网站上的其他常见起始 URL 导航到 URL。强制浏览的单个实例可能只是表示用户在您的网站上添加了书签,但反复尝试访问不存在的内容或用户永远不应直接访问的内容,往往是对网站安全的攻击。强制浏览通常用于访问未经授权的信息,但也可以与缓冲区溢出攻击结合使用,以试图危害您的服务器。
  • Web 表单安全攻击。以 Web 表单向您的网站发送不适当的内容。不适当的内容可能包括修改后的隐藏字段、HTML 或仅用于字母数字数据的字段中的代码、仅接受短字符串的字段中的过长字符串、仅接受整数的字母数字字符串以及网站不接受的各种其他数据期望以该 Web 表单接收。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 服务,并允许它们用于进一步的攻击,或者这两个目标。

零日攻击是对所有用户的主要威胁。这些攻击通常与已知攻击类型相同;零日攻击通常涉及注入的 SQL、跨站点脚本、跨站点请求伪造或类似已知攻击的其他类型的攻击。在大多数情况下,它们针对目标软件、网站或 Web 服务的开发人员不知道或刚刚了解到的漏洞。因此,安全公司通常没有针对这些攻击开发防御措施,即使他们有,用户通常也没有获取和安装补丁程序或执行防御这些攻击所需的解决方法。从发现零日攻击到防御可用性(漏洞窗口)之间的时间正在缩短,但是肇事者仍然可以依靠数小时甚至数天,许多网站和 Web 服务缺乏针对攻击的任何特定保护。

矛攻击是一个主要威胁,但对于更多选择的用户群体来说。常见类型的矛攻击,即矛钓鱼,通常针对特定银行或金融机构的客户,或(较少)针对特定公司或组织的员工。与其他网络钓鱼(这些网络钓鱼通常是粗俗的伪造,熟悉该银行或金融机构的实际通信的用户可以识别出来的)不同,矛网络钓鱼是完美的字母,非常有说服力。它们可以包含特定于个人的信息,首先看来,没有陌生人应该知道或能够获得这些信息。因此,钓鱼者能够说服他或她的目标提供所要求的信息,网络钓鱼者随后可以用这些信息来抢劫账户,处理从其他来源非法获得的资金,或者获取其他甚至更敏感的信息。

这两种类型的攻击都具有通常可以检测到的特性,尽管不像标准签名那样使用查找特定特性的静态模式。检测这些类型的攻击需要更复杂和资源密集型的方法,例如启发式筛选和积极的安全模型系统。启发式筛选外观,不是针对特定模式,而是针对行为模式。积极安全模型系统对其所保护的网站或 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 过滤流程图

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 的基本功能是策略、配置文件和签名,它们提供混合安全模型已知网络攻击/zh-cn/citrix-adc/13/application-firewall/introduction/web-application-security.html[()],未知网络攻击[]如/zh-cn/citrix-adc/13/application-firewall/introduction/web-application-security.html(),和Web App Firewall 的工作原理/zh-cn/citrix-adc/13/application-firewall/introduction/how-application-firewall-works.html[()]。特别值得注意的是学习功能,它可以观察到受保护应用程序的流量,并为某些安全检查建议适当的配置设置。

导入功能管理您上载到 Web App Firewall 的文件。然后,Web App Firewall 将在各种安全检查中使用这些文件,或者在响应与安全检查匹配的连接时使用这些文件。

您可以使用日志、统计信息和报表功能来评估 Web App Firewall 的性能,并确定对其他保护的可能需求。

Citrix Web Application Firewall 如何修改应用程序流量

Citrix Web Application Firewall 通过修改以下内容影响其保护的 Web 应用程序的行为:

  • cookie
  • HTTP 标头
  • 表单/数据

为了保持会话状态,Citrix ADC Web App Firewall 会生成自己的会话 cookie。此 Cookie 仅在 Web 浏览器和 Citrix ADC Web 应用程序防火墙之间传递,而不是传递到 Web 服务器。如果任何黑客试图修改会话 cookie,应用程序防火墙会在将请求转发到服务器之前删除 Cookie,并将请求视为新的用户会话。只要网络浏览器打开,会话 cookie 就会存在。当 Web 浏览器关闭时,应用程序防火墙会话 cookie 将变得更加有效。

可配置的 Web App Firewall 会话 cookie 为citrix_ns_id

许多 Web 应用程序会生成 Cookie 来跟踪用户或会话特定信息。此信息可以是用户首选项或购物车项目。Web 应用程序 cookie 可以是以下两种类型之一:

  • 持久性 Cookie -这些 Cookie 存储在本地计算机上,并在您下次访问网站时再次使用。这种类型的 cookie 通常包含有关用户的信息,例如登录、密码或首选项。
  • 会话或暂时 Cookie -这些 Cookie 仅在会话期间使用,并在会话终止后销毁。此类 Cookie 包含应用程序状态信息,例如购物车项目或会话凭据。

黑客可能会尝试修改或窃取应用程序 Cookie,以劫持用户会话或伪装为用户。应用程序防火墙通过对应用程序 cookie 进行哈希处理,然后使用数字签名添加其他 Cookie 来防止此类尝试。通过跟踪 Cookie,应用程序防火墙可确保客户端浏览器和应用程序防火墙之间的 Cookie 不会被修改或破坏。应用程序防火墙不会修改应用程序 cookie。

Citrix Web Application Firewall 将生成以下默认 Cookie 以跟踪应用程序 Cookie:

  • 持久性 Cookiecitrix_ns_id_wlf。注意:wlf 代表将永远活着。
  • 会话或暂时 Cookiecitrix_ns_id_wat。注意:佛塔代表将采取暂时操作。 为了跟踪应用程序 cookie,应用程序防火墙将持久性或会话应用程序 cookie 分组在一起,然后将所有 cookie 散列并签名在一起。因此,应用程序防火墙生成一个wlf cookie 来跟踪所有持久性应用程序 Cookie,另一个wat cookie 来跟踪所有应用程序会话 Cookie。

无论 Web 应用程序是否生成任何 Cookie,Web App Firewall 始终生成应用程序防火墙会话 cookie。

下表显示了应用程序防火墙根据 Web 应用程序生成的 Cookie 生成的 Cookie 的数量和类型:

Citrix ADC Web App Firewall 之前 更改为
没有 cookie 会话 cookie:citrix_ns_id
一个永久性 cookie 会话 cookie:citrix_ns_id
两个永久性 cookie 来自应用程序的两个原始的持久性 Cookie。会话 Cookie:正确的,持久性的 cookie:正确的存在
一个永久性 cookie,一个瞬时 cookie 来自应用程序的一个原始持久 Cookie。来自应用程序的一个原始会话 cookie。会话 Cookie:正常使用,持久性 Cookie:citrix_ns_id_wlf,暂时性 Cookie:citix_ns_id_wat

Citrix Web App Firewall 允许对应用程序 cookie 进行加密。应用程序防火墙还提供了一个选项来代理应用程序发送的会话 cookie,方法是将其与应用程序防火墙会话数据一起存储,而不是将其发送到客户端。当客户端向包含应用程序防火墙会话 cookie 的应用程序发送请求时,应用程序防火墙会话 cookie 的应用程序会将发送的 cookie 重新插入到请求中,然后再将请求发送到源应用程序。应用程序防火墙还允许将 HTTPOLly 和/或安全标志添加到 cookie。

应用程序防火墙如何影响 HTTP 标头

HTTP 请求和 HTTP 响应都使用标头来发送有关 HTTP 消息的信息。标题是一系列行,每行都包含一个名称,后跟冒号和一个空格以及一个值。例如,主机标头具有以下格式:

Host: www.citrix.com

某些标头字段同时用于请求和响应标头,而其他标头字段仅适用于请求或响应。应用程序防火墙可能会在 HTTP 请求或响应中添加、修改或删除某些标头,以维护应用程序的安全性。

Citrix Web Application Firewall 删除的请求标头

许多与缓存相关的请求标头可能会被应用程序防火墙删除,以便查看会话上下文中的每个请求。同样,如果请求包含允许 Web 服务器发送压缩响应的编码标头,应用程序防火墙将删除此标头,以便应用程序防火墙可以检查未压缩服务器响应中的内容,以防止敏感数据泄漏到客户端。

应用程序防火墙会删除以下请求标头:

  • 范围 — 用于从失败或部分文件传输中恢复。
  • 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 检查等高级安全保护时允许临时缓存数据,应用程序防火墙使用以下逻辑在服务器响应中添加或修改缓存控制标头:

  • 如果服务器发送编译:无缓存,则应用程序防火墙不会进行任何修改。
  • 如果客户端请求是 HTTP 1.0,则应用程序防火墙插入指示:无缓存。
  • 如果客户端请求是 HTTP 1.1 并且具有缓存控制:无存储区,则应用程序防火墙不会进行任何修改。
  • 如果客户端请求是 HTTP 1.1,并且服务器响应具有没有存储或没有缓存指令的缓存控制标头,则应用程序防火墙不会进行任何修改。

  • 如果客户端请求是 HTTP 1.1,并且服务器响应具有无缓存控制标头或缓存控制标头没有存储或无缓存指令,则应用程序防火墙将完成以下任务:
  1. 插入缓存控制:最大年龄 = 3,必须重新验证,私有。
  2. 插入 X 缓存控件 Orig = 缓存控件头的原始值。
  3. 删除上次修改的标题。
  4. 替换 Etag。
  5. 插入 X-过期-原始= 服务器发送的过期标头的原始值。
  6. 修改过期标题并将网页的过期日期设置为过去,因此它始终被重新拾取。
  7. 修改接受范围并将其设置为无。

要在应用程序防火墙更改响应时替换客户端浏览器中的临时缓存数据,例如,对于剥离注释、X-out /删除 SafeObject、xout 或删除信用卡或 URL 转换,应用程序防火墙将执行以下操作:

  1. 在转发到客户端之前,从服务器删除上次修改的内容。
  2. 将 Etag 替换为应用程序防火墙确定的值。

Citrix Web App Firewall 添加的响应标头

  • Transfer-Encoding:分块。此标头将信息流回客户端,而无需在发送响应之前知道响应的总长度。此标题是必需的,因为内容长度标题已被删除。
  • Set-Cookie:应用程序防火墙添加的 Cookie。
  • Xet-Cookie:如果会话有效,并且响应未在缓存中过期,则您可以从缓存中提供服务,并且不必发送新的 cookie,因为会话仍然有效。在这种情况下,设置 Cookie 被更改为 Xet Cookie。对于 Web 浏览器,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==" />

HTML 注释剥离

应用程序防火墙还提供了一个选项,用于在将响应中的所有 HTML 注释发送到客户端之前去除它们。这不仅影响表单,而且影响所有响应页面。应用程序防火墙定位并删除嵌入在“<!-”与“->”注释标记之间的任何文本。标记仍然是为了表示 HTML 源代码的该位置存在注释。嵌入在任何其他 HTML 或 JavaScript 标签中的任何文本都将被忽略。 某些应用程序可能无法正常工作,如果它们在注释标签中嵌入了 JavaScript。对应用程序防火墙剥离注释之前和之后的页源代码进行比较,有助于确定任何被剥离的注释是否嵌入了所需的 JavaScript。

信用卡保护

应用程序防火墙提供了一个选项,用于检查标头和响应正文,并在将响应转发给客户端之前删除或切换信用卡号。目前应用防火墙为以下主要信用卡提供保护:American Express、Diners Club、Discover、JCB、MasterCard 和 Visa。X-out 操作独立于“阻止”操作。

安全对象保护

与信用卡号类似,通过使用应用程序防火墙安全对象安全检查来删除或 X-out 响应中的敏感内容,也可以防止泄露其他敏感数据。

XSS 转换操作

为 XSS 启用转换后,应用程序防火墙将在请求"<" into "%26lt;" and ">" into "%26gt;" 中发生变化。如果启用了应用程序防火墙中的检查重复程序设置,则应用程序防火墙将检查请求标头并转换标头和 Cookie 中的这些字符。转换操作不会阻止或转换最初由服务器发送的值。应用程序防火墙允许的 XSS 默认属性和标签集。此外,还提供了拒绝 XSS 模式的默认列表。可以通过选择签名对象并单击图形用户界面中的“管理 SQL/XSS 模式”对话框来自定义这些选项。

转换 SQL 特殊字符

应用程序防火墙具有以下 SQL 特殊字符的默认转换规则:

原术语 更改为 转型
‘(单引号,即 %27) 另一个单引号
\(反斜杠为 %5C) |添加了另一个反斜杠  
; (分号为 %3B)   丢弃

当启用特殊字符的转换并且检查重新调整器设置为开时,特殊字符的转换也会在标题和 cookie 中发生。 注意:某些请求标头(如用户代理、接受编码)通常包含分号,可能会受到 SQL 转换的影响。

Cirix Web 应用程序防火墙行为,其中损坏 WHEURE 标头

  1. 每当 NetScaler 收到带有预期标头的 HTTP 请求时,NetScaler 代表后端服务器向客户端发送期望:100-继续响应。
  2. 此行为是因为应用程序防火墙保护需要在将请求转发到服务器之前对整个请求运行,NetScaler 需要从客户端获取整个请求。
  3. 在收到 100-继续响应时,客户端将发送完成请求的请求的剩余部分。
  4. NetScaler 然后运行所有保护,然后将请求转发到服务器。
  5. 现在,随着 NetScaler 正在转发初始请求中出现的完整请求 WHERT 标头变得过时,NetScaler 会损坏此标头并将其发送到服务器。
  6. 接收请求时的服务器忽略任何已损坏的标头。

Citrix Web Application Firewall 简介