如何安全处理用户输入的request text？

Question

如何防止用户输入的 request text 导致跨站脚本攻击（XSS）？在 Web 应用中，用户提交的文本若未经充分过滤或转义，可能嵌入恶意脚本，在浏览器中执行，窃取会话信息或劫持用户操作。常见场景包括评论、表单输入和 URL 参数。应采取哪些安全措施，如输入验证、输出编码、使用内容安全策略（CSP），以及在服务端与前端如何协同防御？

Answer 1

1. XSS 攻击的基本原理与常见类型

跨站脚本攻击（Cross-Site Scripting, XSS）是一种常见的 Web 安全漏洞，攻击者通过在网页中注入恶意脚本，当其他用户浏览该页面时，脚本在用户浏览器中执行，从而窃取 Cookie、会话令牌或重定向至钓鱼页面。

• 反射型 XSS：恶意脚本作为请求参数传入，服务器未过滤直接返回响应，脚本在页面中执行。
• 存储型 XSS：用户输入被持久化存储（如数据库），后续访问者加载页面时自动执行。
• DOM 型 XSS：不经过后端，仅通过前端 JavaScript 操作 DOM 引发的脚本执行。

例如，用户在评论框输入：<script>alert('XSS')</script>，若未处理，该脚本将在所有查看评论的用户浏览器中运行。

2. 输入验证：第一道防线

输入验证是防御 XSS 的基础策略，应在服务端对所有用户提交的数据进行严格校验。

1. 使用白名单机制限制允许的字符集，如仅允许字母、数字和特定符号。
2. 对字段长度、格式（如邮箱、URL）进行正则校验。
3. 拒绝包含 HTML 标签或 JavaScript 协议（javascript:）的输入。

输入类型	推荐验证方式	示例
用户名	^[a-zA-Z0-9_]{3,20}$	john_doe
评论内容	过滤 script、iframe、onerror 等标签	支持 HTML 子集（如 <b>, <i>）
URL 参数	URL 编码 + 协议白名单	仅允许 http://, https://

3. 输出编码：关键的安全实践

即使输入合法，输出到不同上下文（HTML、JavaScript、CSS、URL）时仍需针对性编码。

// Java 示例：使用 OWASP Java Encoder
String safeOutput = Encode.forHtml(userInput);
String safeScript = Encode.forJavaScript(userInput);
String safeUrl = Encode.forUri(userInput);

在前端，避免使用 innerHTML，改用 textContent 或现代框架（React、Vue）的自动转义机制。

graph TD A[用户输入] --> B{服务端接收} B --> C[输入验证] C --> D[存储/处理] D --> E[输出编码] E --> F[浏览器渲染] F --> G[安全展示]

4. 内容安全策略（CSP）：纵深防御

CSP 是一种 HTTP 响应头机制，用于限制页面可加载的资源来源，有效缓解 XSS 影响。

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; object-src 'none'; frame-ancestors 'none';

• script-src 'self'：仅允许同源脚本执行。
• object-src 'none'：禁止插件（如 Flash）加载。
• frame-ancestors 'none'：防止点击劫持。

配合 nonce 或 hash 策略，可允许内联脚本安全执行：

<script nonce="2726c7f26c">...</script>

5. 服务端与前端的协同防御机制

单一层面防护不足，需构建多层协同体系。

层级	措施	技术实现
服务端	输入过滤 + 输出编码	使用 HtmlSanitizer 库净化富文本
前端	避免 innerHTML，使用 DOMPurify	DOMPurify.sanitize(dirty)
传输层	设置 CSP 和 X-XSS-Protection	HTTP 头强化
运行时	启用沙箱 iframe	隔离不可信内容

1. 服务端接收 request text 后立即验证并清理。
2. 存储前进行 HTML 净化（如使用 Jsoup 或 sanitize-html）。
3. 响应输出时根据上下文进行编码。
4. 前端渲染动态内容时二次校验。
5. 结合自动化扫描工具（如 ZAP、Burp Suite）定期检测。