- 正确答案：XSS（Cross-Site Scripting，跨站脚本攻击）是一种常见的Web安全漏洞，攻击者通过在目标网站的页面中注入恶意脚本（通常是JavaScript），当其他用户浏览该页面时，恶意脚本在用户浏览器中执行，从而窃取Cookie、会话令牌、重定向用户、篡改页面内容或发起进一步的钓鱼攻击。XSS分为三类：反射型（Reflected）、存储型（Stored）和基于DOM的（DOM-based）。 - 解答思路：首先明确XSS的本质是“未对用户输入做安全处理，导致浏览器错误地将不可信数据解析为可执行脚本”。预防的核心逻辑是：**永远不信任任何用户输入，对所有动态输出到HTML/JS/CSS上下文的数据进行上下文敏感的转义或过滤**。需结合输入校验、输出编码、内容安全策略（CSP）等多层防御机制，而非依赖单一手段。 - 深度知识讲解： 1. **底层执行原理**：浏览器渲染HTML时，会按HTML解析规则（HTML5规范）识别标签、属性、事件处理器（如 onclick、onload）、script标签、style标签中的JS表达式（如 javascript:伪协议）、以及DOM API（如 innerHTML、document.write）等执行点。XSS生效的关键在于：攻击者控制的数据被插入到这些“执行上下文”中，且未被正确转义。例如： - `

Hello,

` → 若 $user_input = `

`，则生成 `

Hello,

`，onerror触发。 - `document.innerHTML = user_input` → 若 user_input = ``，则直接执行。这说明XSS不是服务器端代码执行漏洞，而是客户端渲染阶段的语义混淆问题。 2. **三类XSS的差异与利用链**： - 反射型：恶意payload经URL参数传入，服务端未经处理直接拼入响应HTML返回（如搜索结果页）。利用门槛低，但需诱使用户点击恶意链接。 - 存储型：payload被持久化存入数据库（如评论、用户名、bio字段），所有访问该页面的用户自动触发。危害最大，属于“一次注入，全网传播”。 - DOM型：服务端响应本身无恶意脚本，但前端JS代码（如 location.hash、location.search）动态读取并写入DOM（如 innerHTML += hash），造成客户端污染。不经过服务端，传统WAF难拦截，需前端代码审计。 3. **核心防御机制详解**： a) **输出编码（Context-Aware Encoding）——最根本措施**：根据数据插入的HTML上下文，使用对应编码规则： - HTML主体上下文（如 `

HERE

`）→ HTML实体编码：`<` → `<`，`>` → `>`，`&` → `&`，`"` → `"`，`'` → `'` - HTML属性上下文（如 ``）→ 若属性值用双引号包裹，需编码双引号；若用单引号，则编码单引号；还需编码`&`和`<`（防属性截断+标签注入） - JavaScript上下文（如 `` 或 `onclick="alert('HERE')"`）→ 必须使用JS字符串转义：`'` → `\'`，`"` → `\"`，`\` → `\\`，控制字符（如 `\u0000`）需过滤或编码；更安全做法是JSON.stringify()后放入script标签（注意结尾``需处理） - URL上下文（如 ``）→ 使用 encodeURIComponent() 编码（但注意：仅适用于URL路径/查询参数部分；若插入到href=javascript:xxx中，则必须禁止javascript:协议）关键原则：**没有“通用编码”，只有“上下文特定编码”**。使用成熟库（如OWASP Java Encoder、DOMPurify、React的jsx自动转义）而非手写正则替换。 b) **输入验证（Input Validation）——辅助手段，非替代方案**：白名单校验：如邮箱字段只允许 `[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}`；数字字段强制 parseInt() + 范围检查。但切忌仅依赖黑名单（如过滤`` 和 `onclick=` 失效 - 禁止eval类函数（`unsafe-eval` 不启用）→ 阻断 `eval()`, `setTimeout(string)`, `new Function()` - 限制脚本来源白名单，阻止加载外部恶意JS 注意：CSP无法防御DOM型XSS中纯前端触发的 `innerHTML += user_input`，但能阻止其加载远程payload；需配合report-uri/report-to收集违规日志用于溯源。 d) **HttpOnly Cookie + Secure Flag**：设置 `Set-Cookie: sessionid=abc; HttpOnly; Secure; SameSite=Lax`，使JavaScript无法读取session cookie（`document.cookie` 不可见），大幅降低会话劫持风险。但注意：HttpOnly不防CSRF，也不防键盘记录等其他攻击。 e) **现代框架的默认防护**： React/Vue/Angular默认对插值表达式（如 `{{ user.name }}`）做HTML转义；但显式使用 `dangerouslySetInnerHTML`（React）或 `v-html`（Vue）时，开发者需自行保证数据安全。这说明框架只是工具，安全责任仍在开发者。 - 代码示例（Node.js + Express 安全输出实践）： ``` // ❌ 危险：直接拼接 res.send(`

Welcome, ${req.query.name}

`); // ✅ 安全：使用上下文编码库（如 'xss-filters' 或原生encoder） const escapeHtml = require('escape-html'); // 简单HTML实体编码 res.send(`

Welcome, ${escapeHtml(req.query.name)}

`); // ✅ 更健壮：使用模板引擎的自动转义（如 EJS 默认<%= %>即转义，<%- %>为非转义） // views/welcome.ejs: //

Welcome, <%= name %>

// ✅ 前端JS中安全插入（避免 innerHTML） const container = document.getElementById('user'); container.textContent = userInput; // 自动转义，仅文本 // 若必须插入HTML（如富文本），使用DOMPurify净化 import DOMPurify from 'dompurify'; const clean = DOMPurify.sanitize(untrustedHtml, { ALLOWED_TAGS: ['b', 'i', 'em', 'strong'], ALLOWED_ATTR: ['class'] }); container.innerHTML = clean; ``` - 扩展知识： - XSS与CSRF的区别：XSS是“盗用用户身份执行任意JS”，CSRF是“诱导用户在已认证状态下发起非预期请求”，二者常组合利用（XSS获取token后发CSRF）。 - XSS Worm：如2005年Samy蠕虫（MySpace），利用存储型XSS自动添加好友并传播自身，体现XSS的横向扩散能力。 - 浏览器新特性缓解：Trusted Types API（Chrome 83+）强制要求赋值给innerHTML等sink的数据必须是TrustedHTML类型，从API层面阻断DOM型XSS；需配合CSP `require-trusted-types-for 'script'`。 - 自动化检测：Burp Suite Scanner、ZAP、以及AST静态扫描（如ESLint插件 no-dangerous-innerhtml）可辅助发现漏洞，但无法替代人工上下文分析。

腾讯 一面 ima

全站热榜

创作者周榜

腾讯一面 ima