跳到主要内容

6. 安全考虑

6. 安全考虑 (Security Considerations)​

使用 HTTP 的 application 需要仔细考虑安全性. 本节强调若干关键 security consideration; 另见 [HTTP] Section 17.

application SHOULD 对所有通信使用 TLS [RFC8446]. 特别是, application 在传输 authentication credential 或 personal data 等 sensitive information 时 MUST 使用 TLS. 关于 ubiquitous encryption 必要性的更多信息见 [RFC7258].

application SHOULD 使用 "https" URI scheme 而不是 "http", 以确保使用 TLS. 使用 TLS 时, application SHOULD 遵循当前 best practice, 包括:

  • 使用 TLS 1.3 [RFC8446] 或更高版本.

  • 验证 server certificate.

  • 使用适当的 cipher suite.

  • 考虑使用 HTTP Strict Transport Security (HSTS) [RFC6797], 以确保 browser 总是使用 HTTPS.

application 需要意识到各种 Web-based attack 以及如何缓解它们:

  • Cross-Site Scripting (XSS): 如果 application 返回可由 browser 解释为 HTML 或 JavaScript 的 content, 它需要正确 escape 或 sanitize 该 content, 以防止 XSS attack. 适当使用 Content-Type 并设置 Content-Security-Policy [CSP] header 会有所帮助.

  • Cross-Site Request Forgery (CSRF): 维护 state 的 application (例如使用 cookie) 需要防护 CSRF attack. 在此类攻击中, malicious site 会诱使 user 的 browser 向 application 发出 request. 常见缓解措施包括使用 CSRF token, 并检查 Origin 或 Referer header field.

  • Injection attacks: 将 user input 纳入 query, command 或其他 structured data 的 application, 需要正确 validate 和 sanitize 该 input, 以防止 injection attack (例如 SQL injection).

  • Information disclosure: application 需要谨慎处理 error message, header field 和其他 response 中包含的信息. 详细 error message 可能帮助 attacker 理解 application 内部结构.

application SHOULD 考虑 caching 的 security implication. 特别是:

  • Sensitive information SHOULD NOT 被缓存, 或者如果必须缓存, 则只应私下缓存 (使用 Cache-Control: private).

  • Authentication credential SHOULD NOT 包含在 URL 中, 因为它们可能被记录或缓存.

使用 authentication 的 application 需要考虑:

  • authentication credential 如何传输 (它们应由 TLS 保护).

  • authentication session 持续多久, 以及如何 revoked.

  • 如何防护针对 authentication 的 brute-force attack.

  • multi-factor authentication 是否合适.

application SHOULD 意识到 client 和 server 可能不受 application 设计者控制. 特别是:

  • intermediary (proxy, CDN 等) 可能缓存, 记录或修改 request 和 response.

  • client 可能是 malicious 的或已被 compromised.

  • server 可能已被 compromised.

因此, application SHOULD:

  • 在适当时使用 end-to-end encryption 和 authentication.

  • 不要仅依赖 transport-layer security 保护 sensitive operation.

  • 验证来自 client 的所有 input.

  • 意识到 least privilege principle, 避免赋予 client 或 server 超出必要范围的 access.

允许 user upload content 或 execute code 的 application, 需要格外注意 sandboxing 和 isolation. 即便看似无害的 feature 也可能被滥用:

  • file upload 可能包含 malicious content, 可利用 parser 或 viewer 中的 vulnerability.

  • user-controlled URL 可能被用于 Server-Side Request Forgery (SSRF) attack.

  • 执行 user-provided code 的 feature (例如 browser context 中的 JavaScript) 需要强 isolation.

可从 Web browser 访问的 application 需要特别谨慎, 因为 browser 具有复杂 security model, 且存在许多潜在陷阱. application SHOULD:

  • 使用适当的 Content-Security-Policy header [CSP], 限制 browser 可执行的操作.

  • 使用适当的 CORS policy [FETCH], 控制 cross-origin access.

  • 使用适当 flag (Secure, HttpOnly, SameSite) 设置 cookie.

  • 考虑使用 X-Frame-Options 或 CSP 的 frame-ancestors directive 防止 clickjacking.

  • 意识到 browser-specific behavior, 例如 prefetching, DNS prefetching 和 preconnecting.

  • 考虑使用 Subresource Integrity (SRI), 确保 externally-hosted resource 未被篡改.

application SHOULD 意识到 HTTP feature 有时可能被滥用:

  • redirect 可用于 phishing 或绕过 security control.

  • 大 request 或 response 可用于 denial-of-service attack.

  • 对 header field 或 content 的复杂解析可能导致 vulnerability.

最后, application SHOULD 具有清楚的 security policy, 并且从一开始就应以安全为设计考量. security 不应是事后补救.

最后于 更新