考虑要点：检测跨站点脚本(半机翻有删增)
摘要
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实例。
- 在一对
<SCRIPT>和</ SCRIPT>标记之间 - 在指定为HTML属性值的事件处理程序中，例如onclick或onmouseover;
- 在使用特殊javascript：协议说明符的URL中。
我手动调查了超过100个独立网站的主页（阅读源文件）进行小规模测量。我的测量结果几乎反映了他们的结果
为了消除这种风险，开发人员必须避免使用JavaScript的不安全做法，例如他们需要使用内部JavaScript文件来避免外部JavaScript包含，eval()函数需要用其他一些安全函数替换。
静态脚本之间的恶意代码
在检测XSS时，任何现有脚本代码之间的用户输入是至关重要的问题。很难从现有系统中找到能够恰当地解决这一难题的任何方法。任何网页中都有两种类型的脚本代码。其中一些是静态的，其中一些是动态的（在运行时组成）。让我们以一个例子开始讨论这个问题。
在上面的示例中，同时启动脚本的开始和结束标记都是静态的，并且用户输入夹在它们之间，使脚本代码可执行。但问题是在这种情况下任何成功的注入都可能产生XSS向量。现有系统的所有强大过滤器都试图从用户输入中查找恶意代码。静态代码中的这种情况可能有助于攻击者绕过任何检测过滤器。例如，Samy MySpace Wormin引入了过滤器（innerHTML）通过JavaScript代码禁止的关键字，导致输出作为客户端（eval（’inner’+’HTML’））。另一方面，我们无法在过滤时消除任何静态脚本代码，因为它们是合法的，并且在这些合法代码之间可能存在安全的用户输入。因此很难分离和过滤构建这种构造的输入而不理解它们使用的语法上下文
因此，在过滤时，语法的含义是一个至关重要的问题。
特定于浏览器的问题
浏览器特性的多样性是检测漏洞时的主要问题之一。不同的浏览器以不同方式分析网页。其中一些遵循W3C的规则，其中一些是自己的。因此，这种多面的浏览器使许多过滤器变弱。此外，浏览器无法区分具有恶意输入的精制脚本和良性脚本。他们随时准备执行导致XSS攻击的所有脚本。例如，某些浏览器接受“JavaScript”中的换行符或空格，JavaScript的一部分：URL，有些则不接受。
这将导致某些浏览器的脚本执行。Vector依赖于Firefox HTML解析器的“ad-hoc（quirk）”行为，例如，只有Firefox执行
让我们看看另一个案例
上面的函数preg_replace查找关闭脚本标记。某些浏览器不允许任何脚本代码而没有任何关闭脚本标记。但对所有浏览器来说并非如此。大多数浏览器接受脚本代码而不关闭标记并自动插入缺少的标记(浏览器的容错性)。浏览器的这种慷慨程度可以帮助任何攻击者轻松插入恶意代码。
因此，对恶意有效负载的正确验证很难正确。在开发用于检测不受信任的用户输入的任何工具时，不同浏览器的解析机制的性质必须是至关重要的。一些现有系统试图克服这个问题，但我认为这些并不适合所有浏览器。
基于 DOM 的问题
大多数现有系统的关键问题之一是它们无法检测基于DOM的XSS。因此，仅识别存储和反映的XSS不足以阻止所有XSS域，并且根据Amit Klein的文章，DOMbased是Web世界即将出现的注入问题之一，因为如今，与其他类型的XSS问题相关的大多数问题正在出现在主要网站上清理。
所以，坏人会尝试第三种类型的XSS漏洞。我们已经知道，基于DOM的XSS向量不需要出现在服务器上，服务器也不容易识别。
因此，攻击者可以通过此类XSS漏洞获得额外优势。基于DOM的XSS由Amit Klein在他的文章中介绍，这种类型的XSS可以隐藏在JavaScript代码中，许多强大的Web应用程序防火墙无法过滤这些恶意代码。
在可扩展标记语言（XML）世界中，主要有两种类型的解析器，DOM和SAX。基于DOM的解析器将整个文档作为对象结构加载，该对象结构包含方法和变量，可以轻松地在文档中移动并动态修改节点，值和属性。浏览器使用DOM。加载页面时，浏览器会将生成的页面解析为对象结构。
getElementByTagName是一个标准DOM函数，用于根据标记名称定位XML / HTML节点。
让我们开始用Amit Klein的例子深入讨论这个话题。比如说，http：//www.vulnerable.site/welcome.html的内容如下：
如果我们分析示例的代码，我们将看到开发人员忘记清理“name”get参数的值，该参数随后在检索后立即写入文档中。此HTML页面的结果将是http://vulnerable.site/welcome.html?name=Joe（如果用户输入为“Joe”）。但是，如果用户输入是任何会导致XSS情况的脚本代码。例如。;
许多人可能不同意这种说法，并且可能会争辩说，恶意代码仍在发送到服务器，并且可以在服务器中使用任何过滤器来识别它。我们来看看前一个例子的更新版本。
在文件名用作片段启动器之后立即签名（＃），除此之外的任何内容都不是查询的一部分。大多数众所周知的浏览器都不会将片段发送到服务器。
因此，代码的实际恶意部分不会出现在服务器上，因此，服务器会看到相当于http://www.vulnerable.site/welcome.html。基于DOM的XSS的更多场景在Amit Klein的文章中。他建议最大限度地减少代码中不安全的JavaScript实践可能会降低基于DOM的XSS的可能性。 Web开发人员在依赖本地变量进行数据和控制时必须非常小心，并且应该关注使用用户输入修改DOM的场景。
自动化测试在识别和验证基于DOM的XSS方面的成功非常有限，因为它通常通过发送特定的有效负载来识别XSS并尝试在服务器响应中观察它。如果我们排除（＃）符号的想法但在下面的设计案例中可能不起作用，这对于图9可能正常工作：
因此，自动化测试不会检测可能对基于DOM的XSS敏感的区域，除非测试工具可以执行客户端代码的附加分析
因此，应该进行手动测试，并且可以通过检查代码中可能对攻击者有用的参数区域来完成。此类区域的示例包括将代码动态写入页面的位置以及修改DOM的其他位置或甚至直接执行脚本的位置。
多模块问题的问题
服务器页面的漏洞是Web应用程序漏洞的必要条件，但它不是必要条件（不理解）。这意味着保护任何单个页面免受恶意代码的侵害，从不保证整个Web应用程序的保护。服务器页面可以将用户数据发送到其他页面或任何其他持久数据存储而不是客户端浏览器。在这些情况下，XSS可能通过另一个页面发生。大多数现有系统不提供任何程序来处理这种困难。在多模块场景中，可以使用一些会话变量将数据从一个模块传递到另一个模块，并将这些会话变量状态存储在cookie中。让我们看看下面的例子。
在图13中，我们可以看到用户输入存储在会话变量中，之后它被存储到$name变量中。在图14中，该会话变量通过不同的页面回显。因此，$name变量的任何过滤过程都不会影响会话变量。在这种情况下，任何恶意代码都可以使用会话变量创建XSS向量，并可以绕过任何过滤进程。
在阅读了一个开源Web应用程序LogiCampus Educational Platform的源代码文件后，我找到了几个漏洞。表II中给出了不同种类漏洞的数量。为了找到基于DOM的XSS漏洞，需要查看用于在客户端网页上编写的DOM修改代码或代码。
跟踪任何动态使用用户定义数据的模式，例如任何事件处理程序或内联脚本代码，以分析静态脚本代码问题。多模块问题主要由会话变量引起。因此，我使用会话变量跟踪数据流，并且此应用程序使用了几个会话变量，但在向客户端站点显示任何用户定义数据之前，此应用程序使用过滤功能。因此，这些会话变量都不会为此应用程序创建任何多模块问题。
结论
这是我对大多数著名的注入问题，跨站脚本的分析报告。我没有实现或运行任何工具来进行实验。我使用他们的算法和程序来理解它们是如何工作的，并总结了它们的成功和局限性。我没有发现任何100％完美的方法。即使我没有提供任何可以检测XSS的工具。
我为未来的运动保留了这项任务。
Web应用程序执行许多关键任务并处理敏感信息。在我们的日常生活中，我们通过这种媒体传递了许多机密数据。所以这个平台必须安全稳定。如今，针对这些注入问题和XSS面临安全问题的Web应用程序就是其中之一。
研究人员正在努力使我们的Web应用程序平台更可靠。该调查报告将帮助他们进一步研究这一问题。我相信本报告提供了用于检测XSS的所有方法的摘要，以及它们的局限性和成功性
个人总结
这篇文章主要讲解了当前检测 XSS 漏洞的主要技术：主要分为静态方法和动态方法，还有动静结合
动态方法分为：
(1)基于漏洞分析的方法：1.改造接收器识别危险字符 2.分析句法结构
(2)攻击预防方法：1.代理策略 2.浏览器策略
静态方法分为：
(1)污点传播分析：从源到接收器的全部路径进行过滤
(2)字符串分析：有限状态自动机进行分析
(3)脚本黑名单防止XSS：设置标签黑名单
(4)软件测试技术：黑盒测试
(4)有界模型检验：对变量的威胁级别进行打分，最后算整个的均分和阙值比较
还讲到了 XSS 检测可能会遇到的一些问题
(1)不安全的 JS 使用方式，如使用危险函数配合用户输入等
(2)浏览器实现方式的多样性
(3)dom xss 难以检测的问题