在Web应用中，XSS（跨站脚本）漏洞是如何产生的？请结合360浏览器的XSS过滤机制，说明如何检测和防御此类漏洞。

1) 【一句话结论】
XSS漏洞源于Web应用对用户输入未做有效验证/转义，导致恶意脚本注入页面并执行；360通过输入过滤、输出过滤、内容安全策略（CSP）等机制检测防御，需结合输入处理与输出渲染环节防护。

2) 【原理/概念讲解】
老师口吻：先解释“跨站脚本攻击（XSS）”的本质——用户输入被当作代码执行。比如，当你在搜索框输入<script>alert('XSS')</script>，若应用未对输入做“清洗”（转义或过滤），直接将其输出到页面，其他用户访问时该脚本就会在他们的浏览器中执行。类比：把用户输入当成“食材”，应用直接“生吃”（未处理），导致“中毒”（脚本执行）。

3) 【对比与适用场景】
不同类型XSS的对比要点：
| 类型 | 定义 | 特性 | 检测/防御重点 |
| 反射型 | 用户输入被直接返回到响应中（临时性） | 无持久化，触发时需用户主动访问 | 输入过滤、输出转义 |
| 存储型 | 输入存储到数据库等持久化存储（如用户名、评论） | 持久化，多次触发 | 数据库输入过滤、存储后输出转义 |
| DOM型 | 脚本执行依赖DOM结构（如客户端脚本操作DOM） | 依赖客户端代码，与服务器响应无关 | 客户端代码审计、CSP |

4) 【示例】
反射型XSS示例：

• 场景：Web应用提供搜索功能，URL参数search=...。
• 用户输入：<script>alert('Hello')</script>
• 应用行为：未转义直接拼接至HTML输出（如"<h1>搜索结果：${userInput}</h1>"）。
• 结果：其他用户访问/search?search=<script>alert(1)</script>时，脚本执行。

5) 【面试口播版答案】
“XSS漏洞的核心是用户输入被当作代码执行。比如，当你在搜索框输入恶意脚本，应用没转义直接输出到页面，别人访问时脚本就执行了。360的XSS过滤机制主要分三块：输入过滤（检查用户输入是否有危险字符，如<script>、on事件）、输出过滤（对输出到页面的内容转义，比如<转<）、内容安全策略（CSP，通过script-src等指令限制脚本来源）。检测的话，用工具扫描输入点（比如找没有过滤的表单字段）；防御就是严格验证输入、转义输出、用CSP限制脚本执行。这样就能有效防XSS。”

6) 【追问清单】

• 问：360浏览器的XSS过滤机制具体怎么实现？比如输入过滤的规则？
  回答要点：输入过滤通过正则或白名单检查危险字符（如<script>、on事件），拦截危险输入；输出过滤对输出内容进行HTML转义。
• 问：如何区分反射型XSS和DOM型XSS？检测时有什么不同？
  回答要点：反射型依赖服务器响应，DOM型依赖客户端DOM操作。检测时，反射型看输入是否在响应中，DOM型看客户端脚本是否操作DOM。
• 问：CSP在防御XSS中的作用？有没有局限性？
  回答要点：CSP通过script-src等指令限制脚本来源，防止执行非授权脚本。局限性是只能限制加载，不能完全阻止执行，需配合其他措施。

7) 【常见坑/雷区】

• 坑1：混淆不同类型XSS，只说反射型，忽略DOM型。
• 雷区：说360的过滤机制是唯一防御方法，忽略其他技术（如输入验证、输出转义）。
• 坑2：忽略输入验证的位置，比如只说输出过滤，没提输入过滤的重要性。
• 雷区：说CSP能完全防御XSS，其实不能，只能限制。
• 坑3：示例不典型，比如用存储型但没说明持久化，导致理解偏差。