考虑要点：检测跨站点脚本(半机翻有删增)

Web应用程序（WA）扩展其用途以提供越来越多的服务，它已成为服务提供商和用户之间最重要的通信渠道之一。为了增强用户体验，许多Web应用程序正在使用客户端脚本语言（如JavaScript），但这种JavaScript的增长也增加了Web应用程序中的严重安全漏洞，例如跨站点脚本（XSS）。在本文中，我 调查了用于检测XSS的所有技术， 并安排了大量分析来评估这些方法的性能。本文指出了检测XSS的主要困难。我没有实现此漏洞问题的任何解决方案，因为我的重点是审查这个问题。但是，我相信这个评估将合作进一步研究这个问题，因为这篇论文弄清了这个超越性安全问题的一切。

介绍

一类脚本代码被注入动态生成的可信站点页面，用于将敏感数据传输到任何第三方（即攻击者的服务器）并避免同源策略或cookie保护机制，以允许攻击者访问机密数据。

XSS通常影响客户端受害者的Web浏览器，而 SQL 注入则涉及与服务器端相关的Web漏洞。因此，对于Web应用程序的操作员来说，追踪XSS漏洞是棘手的。此外，任何攻击者都不需要特定的应用知识或诀窍来揭示漏洞。

此外，Wassermann和Su的论文中提到的几个因素导致了XSS漏洞的普遍存在。首先，XSS的系统要求很低。其次，大多数Web应用程序编程语言为将不受信任的输入传递给客户端提供了不安全的默认设置。最后，对不可信输入的正确验证很难正确，主要是因为调用JavaScript解释器的许多（通常是浏览特定的）方式。

因此，我们可以说，对用户输入的验证不充分是跨站点脚本（XSS）和有效输入验证方法可用于检测WA中XSS漏洞的关键原因。但并非总是如此。我在调查期间发现了一些情况， 只有输入验证不能令人满意地阻止XSS 。已经开发了几种技术来检测这种注射问题。其中一些是动态的，其中一些是静态处理的。每个研究人员都试图提供比以前的工作更有能力和有效的方法。但在我看来，每种方法都有利有弊。

XSS 攻击类型

有三种不同类型的XSS攻击：非持久性，持久性和基于DOM的。

非持久性跨站点脚本漏洞是最常见的类型。攻击代码不是持久存储的，而是立即回显给用户。例如，考虑一个搜索表单，其中包含搜索查询到页面中的结果，但不过滤查询脚本代码。例如，可以通过向受害者发送包含指向搜索表单并包含恶意JavaScript代码的特制链接的电子邮件来利用此漏洞。通过欺骗受害者点击此链接，搜索表单将以JavaScript代码作为查询字符串提交，攻击脚本会立即发送回受害者，作为带有结果的网页的一部分。作为另一示例，考虑访问流行的trusted.com网站以执行敏感操作的用户的情况（例如，在线银行）。

trusted.com上的基于Web的应用程序使用cookie在用户的浏览器中存储敏感的会话信息。请注意，由于源策略相同，因此只能从trusted.com Web服务器下载的JavaScript代码访问此cookie。但是，用户可能还在浏览恶意网站，例如www.evil.com，可能会被欺骗点击以下链接：

当用户点击链接时，用户的浏览器会将HTTP请求发送到www.trusted.com Web服务器，请求页面：

trusted.com Web服务器接收请求并检查它是否具有正在请求的资源。当trusted.com主机找不到所请求的页面时，它将返回错误页面消息。 Web服务器还可以决定包括所请求的文件名（实际上是脚本）将从trusted.com Web服务器发送到用户的浏览器，并且将在trusted.com源的上下文中执行。执行脚本时，trusted.com设置的cookie将作为参数调用steal-cookie.php服务器端脚本发送到恶意网站。该cookie将被保存，并且evel.com网站的所有者可以使用该模拟来冒充与trusted.com相关的毫无戒心的用户。

持久类型将恶意代码持久存储在由服务器管理的资源（在数据库，文件系统或其他位置）中，稍后显示给用户而不使用HTML实体进行编码。例如，考虑一个在线留言板，用户可以在其中发布消息，其他人可以在以后访问消息。让我们进一步假设应用程序不会从发布的消息中删除脚本内容。在这种情况下，攻击者可以制作类似于下一个示例的消息。

此消息包含联机消息板在其数据库中存储的恶意JavaScript代码。读取消息的访问用户将脚本代码作为消息的一部分进行检索。用户的浏览器然后执行脚本，该脚本又将用户的敏感信息从他的站点发送到攻击者的站点。

基于DOM的跨站点脚本攻击是通过修改客户端的DOM“环境”而不是向服务器发送任何恶意代码来执行的。因此服务器没有任何范围来验证有效负载。以下示例显示符号（＃）表示其后面的所有内容都是片段，即不是查询的一部分。

浏览器不会将片段发送到服务器，因此服务器只能看到 http://www.evil.com/Home.html的等效内容，而不是有效负载的受感染部分。因此，我们看到这种逃避技术导致主要浏览器不将恶意负载发送到服务器。因此，即使是精心策划的XSS过滤器也无法抵御此类攻击。

正如格罗斯曼，RSNAKE，PDP，Rager和Fogie所指出的，跨站脚本是一个多变的问题，不容易在短期内解决。与其他安全相关的问题一样，大多数人都无法接受快速修复。

他们发现问题是双重的。首先，浏览器在设计上并不安全。简单地创建它们以产生关于请求的输出。任何浏览器的主要职责都不是确定该条代码是否在做恶意的事情。其次，由于缺乏编程技巧或时间限制，Web应用程序开发人员无法创建安全站点。因此，攻击者有机会利用应用程序的漏洞。因此，现在，用户被困在两个不可能的状态之间。

现有方法

动态方法

1）基于漏洞分析的方法：

a）基于解释器的方法：

Pietraszek和Berghe使用仪器解释器的方法来跟踪字符级别的不可信数据，他们在每个敏感的接收器上使用上下文敏感的字符串评估识别漏洞。这种方法很健全，可以检测漏洞， 因为它们通过修改解释器来增加安全保障 。但是修改解释器的方法并不容易适用于某些其他Web编程语言，例如Java（即JSP和servlet）

b）句法结构分析：

成功的注入攻击改变了被利用实体的句法结构，Su和Wassermann说过，他们提出了一种检查输出字符串的句法结构以检测恶意有效载荷的方法。 使用元数据扩充用户输入以从源数据到接收器跟踪此子字符串 。此元数据通过指示用户给定数据的结束和开始位置，帮助修改的解析器检查动态生成的字符串的语法结构。如果有任何异常，则阻止进一步的过程。这些过程非常成功，同时它可以检测除XSS之外的任何注入漏洞。仅检查语法结构不足以防止由多个模块的交互引起的这种工作流漏洞。

2）攻击预防方法：

a）基于代理的解决方案：

Noxes，一种Web代理， 可防止敏感信息从受害者站点传输到第三方站点 。这是一个用于阻止和检测恶意软件的应用程序级防火墙。用户可以对从本地机器进出的每个连接进行精细控制。如果任何连接与防火墙规则不匹配，则防火墙会提示用户决定是否需要阻止或允许连接。将链接列入黑名单并不足以防止跨站点脚本攻击，例如那些不违反同源策略的技术，就像Samy蠕虫的情况一样。基于代理的解决方案不提供任何识别错误的过程，它需要注意配置。这些类型的系统保护不可预测的链路而不检查可能增加误报的故障。

b）浏览器强制嵌入式策略：

Web应用程序向浏览器提供所有良性脚本的白名单，以防止恶意代码。 这个聪明的想法只允许运行列出的脚本 。不同浏览器的解析机制之间没有相似之处，因此，一个浏览器的成功过滤系统可能对另一个浏览器不成功。因此，本文的方法在这种情况下非常成功，但是对浏览器实施策略需要对其进行修改。因此，从Web应用程序的角度来看，它存在可伸缩性问题。每个客户端都需要具有此修改版本的浏览器。

静态方法：

1）污点传播分析：

许多静态和动态方法使用污点传播分析，使用数据流分析来跟踪从源到汇的信息流。这种技术的基本假设如下 ：如果在从源到接收器的所有路径上完成清理操作，那么应用程序是安全的

保持对用户过滤器的信任并且根本不检查过滤功能根本不是一个好主意，因为一些XSS向量可以轻松绕过许多强过滤器。因此它没有提供强有力的安全机制

2）字符串分析：

字符串分析的研究源于文本处理程序的研究。XDuce是一种为XML转换而设计的语言，它使用形式语言（例如，常规语言）。 Christensen，Mǿller和Schwartzbach通过展示字符串分析在分析 Java 程序中的反射代码和检查动态生成的SQL查询中的错误中的有用性，介绍了对命令式（和现实世界）语言的静态字符串分析的研究。他们 使用有限状态自动机（FSA）作为目标语言表示来设计Java分析 。他们还应用计算语言学技术来生成CFG的良好FSA近似。然而，他们的分析并不跟踪数据来源，并且因为它必须确定每个操作之间的FSA，所以其他字符串分析的效率较低，而且对于发现XSS漏洞并不实际。

Minamide遵循相同的技术设计 PHP 的字符串分析，不接近FSA的CFG。他提出的技术检查整个文档是否存在 <script> 标记。由于Web应用程序通常包含自己的脚本，并且由于存在许多其他调用JavaScript解释器的方法，因此该方法对于查找XSS漏洞并不实用。

3）脚本黑名单防止XSS：

使用不受信任的脚本列表来检测来自用户给定数据的有害脚本是众所周知的技术。Wassermann和Su最近的工作是这个过程的缩影。 他们构建策略并生成不可信标记的正则表达式 ，以检查它是否在生成的正则表达式和CFG之间具有非空交集，从String污染静态分析生成，如果是，则采取进一步操作。我们认为使用任何不受信任的脚本列表都是容易和不好的想法。 OWASP的文件中也有相同的意见。在文档中，提到了“不要使用”黑名单“验证来检测输入中的XSS或编码输出。搜索和替换只有几个字符（“<”“>”和其他类似字符或短语，如“script”）我们很弱，并且已成功攻击。 XSS拥有数量惊人的变种，可以轻松绕过黑名单验证。“

4）软件测试技术：

Y.Huang，S.Huang，Lin和Tsai使用多种软件测试技术， 如黑盒测试，故障注入和对Web应用程序的行为监控 ，以推断出漏洞的存在。它将用户行为模拟与用户体验建模结合为黑盒测试。类似的方法被用于几个商业项目，如APPScan ，WebInspect 和ScanDo由于这些方法用于识别开发周期中的错误，因此这些方法可能无法提供即时Web应用程序保护，并且它们也无法保证检测到所有缺陷。

5）有界模型检验：

Huang等使用反例跟踪来减少插入的清理例程的数量，并确定导致错误报告和代码检测精度错误的原因。为了验证Web应用程序中的合法信息流， 它们分配表示变量当前信任级别的状态。然后，使用有界模型检验技术来验证所有该计划的摘要解释可能的安全状态 。在他们的方法中，他们省略了别名分析或包括文件解析问题，这些是当前大多数系统中的一些主要问题。

静态和动态分析组合

1）基于格的分析：

WebSSARI是一种工具，结合了静态和运行时功能，应用静态污点传播分析来发现安全漏洞。在格模型和类型状态的基础上，该 工具 使用流敏感，程序内分析来检测漏洞。该工具在确定受污染的数据到达敏感函数时自动插入运行时防护，即清理程序。该方法的主要问题在于，由于其基于过程内类型的分析，它提供了大量的假阳性和阴性。此外，该方法考虑用户设计的过滤器的结果是安全的。因此，它可能会错过真正的漏洞。因为，指定的过滤功能可能无法检测恶意有效载荷。

检测XSS的考虑要点

不安全的 JS 测试

岳等人通过检查安全漏洞的严重性和性质来描述不同网站上JavaScript包含和动态生成的不安全工程实践。这两种不安全的做法是将恶意代码注入网站并创建XSS向量的主要原因。根据他们的调查结果，66.4％的测量网站使用脚本标记的src属性进行JavaScript包含的不安全做法，以将来自外部域的JavaScript文件包含到网页的顶级域文档中。顶级文档是从Web浏览器地址栏中显示的URL加载的文档。

只有在丢弃其顶级域名（例如.com）和主要名称“www”（如果存在）之后，两个域名才被视为不同;他们没有任何共同的子域名。例如，只有当两个集合{d1sub2.d1sub1}和{d2sub3.d2sub2.d2sub1}的交集为空时，才会认为两个域名不同。

1. www.d1sub2.d1sub1.d1tld
2. d2sub3.d2sub2.d2sub1.d2tld

79.9％的测量网站使用一种或多种类型的JavaScript动态生成技术。在动态生成技术的情况下，document.write()，innerHTML，eval()函数比其他一些安全方法更受欢迎。

他们的结果显示，94.9％的被测网站在其网页中注册了各种事件处理程序。动态生成的脚本（DJS）实例以不同的方式用于不同的生成技术。对于eval()函数，整个评估的字符串内容被视为DJS实例。

在document.write（）方法的书面内容和innerHTML属性的值内，可以通过三个源来识别DJS实例。