本地搭建XSS 漏洞接收平台实践分享

免责声明

本文仅限于学习讨论与技术知识的分享,不得违反当地国家的法律法规。对于传播、利用文章中提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责,本文作者不为此承担任何责任,一旦造成后果请自行承担!

前言

XSS Platform 平台主要是用作验证跨站脚本攻击。该平台可以部署在本地或服务器环境中。我们可以使用 XSS Platfrom 平台搭建、学习或验证各种类型的 XSS 漏洞。

项目地址:https://github.com/NepoloHebo/XSS-Platform

运行环境

phpStudy

本文笔者是在windows10上,安装小皮面板phpStudy8.1作为运行环境。

小皮面板官网:小皮面板-好用、安全、稳定的Linux服务器面板!

下载、安装即可。

frp配置

准备一个可以使用的域名和frp做内网穿透,关于frp的使用,本文不赘述。

笔者使用本次测试的域名为s*1.com,将7550端口(端口自定义)映射出来。

XSS Platform 平台搭建和使用

平台搭建

运行小皮面板,启动mysql数据库和Apache服务。

创建网站:xssplatform,填写相关信息。

配置伪静态规则

伪静态配置内容在项目目录的安装说明.txt中

将下载好的 xss platform 项目源代码解压放到网站目录xssplatform中。

http://s*1.com:7550/

填写数据库信息

导入成功

打开首页

功能介绍

登录成功之后会自动跳转到首页,如下图所示

在首页中可以看到有一个默认项目,点击default后可以看到受害者列表,不过刚刚安装肯定是还没有数据的,如下图所示

在图中右上方有一个查看代码的链接,点击进去便可以查看XSS Platform预备好的攻击代码,如下图所示

攻击测试实践

本文以ctfhub.com技能树 XSS反射型题为例。

配置xss.js

攻击测试

根据提示,把XSS平台给出的代码复制到第一个输入框中进行注入

提交后,在第二个框中访问第一个框注入XSS脚本后的网址

提交后,在XSS平台查看注入结果,即可得到flag

### 解决方案 跨站点脚本攻击(XSS)可能导致平台无法正常接收 Cookie 的原因通常涉及浏览器的安全策略以及目标网站的配置。以下是可能的原因分析及解决方案: #### 原因一:HttpOnly 和 Secure 属性设置不当 如果目标网站设置了 `HttpOnly` 或者 `Secure` 属性,那么这些 Cookies 将不会被 JavaScript 访问或者通过非 HTTPS 连接发送。 - 如果 `_geckoboard_session` 被标记为 `HttpOnly`,JavaScript 代码将无法读取该 Cookie[^1]。 - 如果 `_geckoboard_session` 被标记为 `Secure`,而 XSS 平台尝试通过 HTTP 请求获取它,则请求会失败。 **解决方法**: 确保 XSS 攻击载荷运行在一个支持 HTTPS 的环境中,并验证目标网站是否允许通过 JavaScript 获取特定的 Cookies。 --- #### 原因二:SameSite 属性的影响 现代浏览器引入了 `SameSite` 属性来增强安全性,默认情况下可能会阻止第三方上下文中发送 Cookies。 - 如果目标网站设置了 `SameSite=Strict` 或 `SameSite=Lax`,Cookies 可能不会随跨域请求一起发送。 **解决方法**: 确认目标网站的 Cookie 设置是否有 `SameSite=None` 配置。如果没有,可以通过调整 XSS 攻击向量的方式绕过此限制,例如利用 POST 表单提交而非 AJAX 请求。 --- #### 原因三:CORS 策略限制 跨源资源共享 (CORS) 策略也可能影响 Cookie 的传递行为。即使存在有效的 XSS 漏洞,某些 CORS 头部(如 `Access-Control-Allow-Credentials`)未正确配置时,Cookie 不会被附加到请求中。 **解决方法**: 测试目标网站是否存在宽松的 CORS 配置,例如允许任意来源访问资源并附带认证信息。如果可以控制请求头,尝试手动添加必要的字段以触发 Cookie 发送。 ```javascript fetch('https://target-site.com/api', { method: 'POST', credentials: 'include' // Ensure cookies are sent along with the request. }); ``` --- #### 原因四:URL 参数污染防御机制 部分应用会对 URL 中的关键参数实施额外保护措施,防止恶意修改或注入非法数据。例如,在引用[2]中的链接形式可能存在类似的防护逻辑。 - 若检测到异常活动(比如伪造 token),服务器端可能会拒绝处理请求或清除敏感信息[^2]。 **应对策略**: 仔细研究目标系统的输入校验规则,构建更加隐蔽且符合预期格式的有效负载。 --- ### 总结 综合以上几点可以看出,成功提取和利用受感染页面上的 Cookies 往往取决于多种因素共同作用的结果。除了技术层面的操作外,还需要考虑实际环境下的各种约束条件。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

林鸿风采

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值