2025年渗透测试面试题总结-2025年HW(护网面试) 03（题目+回答）
安全领域各种资源，学习文档，以及工具分享、前沿信息分享、POC、EXP分享。不定期分享各种好玩的项目及好用的工具，欢迎关注。
目录
2025年HW(护网面试) 03
1. 同源策略（Same-Origin Policy）
2. XSS攻击用途
3. XSS类型与防御
4. 存储型XSS原理
5. XSS攻击本质
6. 快速定位XSS漏洞点
7. DOM型XSS原理/防御
8. DOM型 vs 反射型XSS
9. 前端Referer置空方法
10. Cookie关键参数
11. 未定位XSS的应急响应
12. XSS、CSRF、CRLF对比
13. CSRF不带Referer访问
14. CSRF防御方案
15. XSS蠕虫原理
16. Cookie的P3P性质
17. CSRF危害
2025年HW(护网面试) 03
1、什么是同源策略 2、XSS 能用来做什么 3、XSS的三种类型，防御方法 4、存储型xss原理 5、你怎么理解xss攻击 6、如何快速发现xss位置 7、Dom xss 原理/防范 8、DOM型XSS与反射型XSS区别 9、如何使得前端 referer 为空 10、cookie参数，security干什么的 11、如果 SRC 上报了一个 XSS 漏洞，payload 已经写入页面，但未给出具体位置，如何快速介入 12、XSS， CSRF， CRLF比较容易弄混，说说三者的原理，防御方法 13、csrf 如何不带referer访问 14、CSRF 成因及防御措施；如果不用 token 如何做防御 15、Xss worm原理 16、Cookie的P3P性质 17、CSRF有何危害1. 同源策略（Same-Origin Policy）
浏览器核心安全机制，限制不同源（协议+域名+端口）的脚本交互。例如：
- ✅ 允许
https://a.com访问同源资源- ❌ 禁止
https://b.com通过脚本读取a.com的Cookie或DOM
2. XSS攻击用途
- 窃取用户Cookie、会话Token
- 钓鱼攻击（伪造登录框）
- 网页篡改（如植入恶意广告）
- 传播XSS蠕虫（如新浪微博蠕虫事件）
- 键盘记录、内网探测
3. XSS类型与防御
类型 原理 防御措施 反射型XSS 恶意脚本通过URL参数注入，服务端返回含攻击代码的页面 输入过滤 + 输出编码 + CSP 存储型XSS 攻击脚本存储到数据库（如评论区），所有访问者触发 同反射型 + 富文本白名单（如DOMPurify） DOM型XSS 前端JS动态操作DOM时执行恶意代码（不经过服务端） 避免 innerHTML，用textContent；对location.hash等做校验通用防御：
- 设置Cookie为
HttpOnly（防JS读取）- 启用CSP（Content Security Policy）限制脚本来源
- 框架自动编码（如React的JSX、Vue的
{{ }}）
4. 存储型XSS原理
攻击流程：
mermaidgraph LR A[攻击者提交恶意脚本] --> B[脚本存入数据库] B --> C[用户访问含恶意内容的页面] C --> D[浏览器执行脚本→数据泄露]案例：用户评论中插入
<script>stealCookie()</script>，所有查看评论者受害。
5. XSS攻击本质
利用Web应用对用户输入的信任，将恶意脚本注入合法页面，绕过同源策略执行未授权操作。
6. 快速定位XSS漏洞点
- 输入点扫描：表单、URL参数、Cookie、Headers
- 输出点检测：
- 使用
alert(1)、<img src=x onerror=alert(1)>等Payload测试- 观察是否弹窗或HTML解析异常
- 工具辅助：
- 浏览器插件（如XSS Hunter、Retire.js ）
- DAST工具（如OWASP ZAP、Burp Suite自动扫描）
7. DOM型XSS原理/防御
原理：
javascript// 漏洞代码 document.getElementById('output').innerHTML = location.hash.slice(1); // 攻击：http://site.com#<script>alert(1)</script>防御：
- 避免直接操作
innerHTML/outerHTML- 使用
encodeURIComponent()处理动态内容- 对
location/document.referrer等来源做校验
8. DOM型 vs 反射型XSS
特征 DOM型 反射型 执行位置 纯前端，不经过服务端 服务端返回恶意脚本 可见性 URL中#后的内容不发送到服务端 完整URL参数发送到服务端 检测方式 需前端代码审计 可通过流量监控发现
9. 前端Referer置空方法
- HTML标签：
html<meta name="referrer" content="no-referrer">- JS跳转：
javascriptwindow.location.replace('https://target.com'); // 部分浏览器生效- Fetch API：
javascriptfetch(url, { referrerPolicy: "no-referrer" });
10. Cookie关键参数
Secure：仅通过HTTPS传输HttpOnly：禁止JS访问（防XSS窃取）SameSite：
Strict：完全禁止跨站携带Lax：允许GET导航跳转携带（默认）None：允许跨站携带（需配合Secure）
11. 未定位XSS的应急响应
- 隔离攻击入口：
- 禁用用户内容发布功能
- 回滚至未污染的数据版本
- 追踪Payload：
- 数据库搜索关键词（如
<script>、javascript:）- 审查所有用户输入渲染点（评论/私信/文件名等）
- 前端监控：
- 部署DOM断点调试可疑输出点
- 启用CSP报告机制收集触发点
12. XSS、CSRF、CRLF对比
类型 原理 防御措施 XSS 注入恶意脚本执行 输入过滤+输出编码+CSP+HttpOnly CSRF 诱骗用户发起非意愿请求（如转账） Anti-CSRF Token+SameSite Cookie CRLF 注入回车换行符篡改HTTP头/响应体 过滤 \r\n+ 编码HTTP头字段
13. CSRF不带Referer访问
- HTML页面：
html<iframe src="https://attacker.com" referrerpolicy="no-referrer"></iframe>- JS发起请求：
javascriptfetch('http://vuln.com/transfer', { method: 'POST', referrerPolicy: 'no-referrer' });注意：部分浏览器仍会发送
Origin头，需配合其他绕过手段。
14. CSRF防御方案
成因：浏览器自动携带Cookie发起请求，用户身份被冒用。
防御：
- 主流方案：Anti-CSRF Token（服务端生成并校验）
- 无Token方案：
- SameSite Cookie：设为
Strict或Lax- 验证Origin/Referer头：
pythonif request.headers.get('Origin') not in ALLOWED_ORIGINS: abort(403)- 二次验证：敏感操作需密码/短信确认
15. XSS蠕虫原理
传播流程：
mermaidgraph TB A[用户A访问含蠕虫页面] --> B[脚本自动发布含恶意代码的新内容] B --> C[用户B看到A的内容被感染] C --> D[用户B成为新传播节点]案例：Samy蠕虫（MySpace，2005）通过AJAX自动添加好友并传播。
16. Cookie的P3P性质
作用：允许跨域iframe读写Cookie（已废弃）
风险：html<!-- 攻击者页面 --> <iframe src="https://bank.com"></iframe> <script> // 若bank.com 设置P3P头，攻击者可读写其Cookie </script>现代浏览器已禁用P3P，替代方案为
SameSite和 CORS。
17. CSRF危害
- 资金损失：伪造转账、购物请求
- 数据泄露：诱导修改邮箱/密码窃取账户
- 系统破坏：删除数据、篡改配置（如路由器DNS设置）
- 自动化攻击：利用用户权限发起批量操作