security-best-practices

安全最佳实践

概述

此技能介绍如何识别当前上下文所用的语言和框架，然后从此技能的 references 目录中加载有关这些语言和框架安全最佳实践的信息。

如果有相关信息，可以用来编写默认安全的代码，也可以主动检测现有代码中的重大问题；或者在用户提出要求时，提供漏洞报告并建议修复方案。

工作流

此技能的初始步骤是识别你需要使用的、或已存在于当前项目范围内的所有语言和所有框架。重点关注核心框架。通常需要同时识别前端和后端的语言与框架。

然后检查此技能的 references 目录，查看是否有适用于这些语言和框架的文档。文件名格式为 <language>-<framework>-<stack>-security.md。还应检查是否存在 <language>-general-<stack>-security.md，这类文档与所用框架无关。

如果要处理的 Web 应用同时包含前端和后端，请务必检查前端和后端的参考文档！

如果你被要求构建一个同时包含前端和后端的 Web 应用，但未指定前端框架，也请查看 javascript-general-web-frontend-security.md。了解如何保护前端和后端都很重要。

如果此技能的 references 目录中没有相关信息，请结合你对该语言、框架及其广为人知的安全最佳实践的了解进行判断。如果不确定，可以尝试在线搜索安全最佳实践文档。

之后，可以按以下几种方式开展工作。

1. 主要模式是从现在起运用这些信息编写默认安全的代码。这适用于启动新项目或编写新代码。

2. 次要模式是在项目中工作并为用户编写代码时，主动检测漏洞。可以指出关键或非常重要的漏洞，或严重违反安全指导的问题，并告知用户。此主动模式应侧重影响最大的漏洞和安全默认设置。

3. 用户可以要求提供安全报告或提升代码库的安全性。在这种情况下，应生成一份完整报告，说明项目未遵循安全最佳实践指导的所有方面。报告应按优先级排序，并清楚标明严重程度和紧急程度。然后提出开始着手修复这些问题。请参阅下文的 #fixes。

工作流决策树

• 如果语言或框架不明确，请检查代码仓库以确定它们，并列出依据。
• 如果 references/ 中有适用的指导，只加载相关文件并遵循其中的说明。
• 如果没有适用的指导，请考虑你是否了解所选语言和框架的广为人知的安全最佳实践；但如果用户要求生成报告，应告知用户目前没有具体指导（仍可生成报告，或检测确定无疑的关键漏洞）。

覆盖

虽然这些参考资料包含了适用于各种语言和框架的安全最佳实践，但客户有时可能需要绕过或覆盖这些实践。请留意项目文档和提示词文件中的具体规则和说明，它们可能要求你覆盖某些最佳实践。覆盖某项最佳实践时，你可以告知用户，但不要与用户争执。如果出于项目特定原因需要绕过／忽略某项安全最佳实践，你也可以建议在项目中添加相关文档，说明为何没有遵循该最佳实践，并确保今后继续遵循这一绕过做法。

报告格式

生成报告时，应将报告写入 Markdown 文件 security_best_practices_report.md；如果用户指定了其他位置，则写入该位置。你可以询问用户希望将报告写在哪里。

报告开头应有简短的执行摘要。

报告应根据漏洞严重程度划分为多个清晰的部分。报告应重点关注影响最大的关键发现。所有发现都应标注数字 ID，以便于引用。

对于严重发现，应包含一句影响说明。

报告写好后，也应直接向用户报告，但可以简洁一些。你可以主动提出，如果用户需要，可以进一步解释任何发现或安全最佳实践指导背后的原因。

重要：在报告中引用代码时，务必查找并注明所引用代码的行号。

写好报告文件后，向用户总结发现。

还要告知用户最终报告的保存位置。

修复

如果你生成了报告，应让用户阅读报告，并询问是否开始进行修复。

如果你被动发现了严重问题，应通知用户并询问是否希望你修复该问题。

进行修复时，每次只处理一个发现。添加简洁明确的注释，说明新代码遵循了特定安全最佳实践，并简要说明不这样做可能带来的危险。

始终考虑你计划进行的更改是否会影响用户代码的功能，以及是否可能导致项目回归。务必考虑不安全代码可能因其他原因而被依赖（这也是不安全代码长期存在的原因之一）。避免破坏用户的项目，否则他们可能不愿意再应用安全修复。与其匆忙敷衍地修改，不如结合项目其他部分，审慎充分地制定修复方案。

始终遵循用户配置的常规更改或提交流程。如果进行 Git 提交，应使用清晰的提交消息，说明此次更改旨在遵循安全最佳实践。尽量避免在一次提交中混入多个无关发现。

始终遵循用户配置的常规测试流程（如有），以确认更改不会引入回归。考虑更改可能带来的二阶影响；如有，应在操作前告知用户。

通用安全建议

以下是适用于几乎所有语言或框架的若干安全编码建议。

避免为资源的公开 ID 使用递增编号

为资源分配的 ID 如果将暴露在互联网上，应避免使用较小的自动递增编号。应改用较长的随机 UUID4 或随机十六进制字符串。这样可以防止用户了解资源数量，并猜测资源 ID。

关于 TLS 的说明

虽然 TLS 对生产部署很重要，但大多数开发工作会在禁用 TLS 的情况下进行，或者由范围外的 TLS 代理提供 TLS。因此，务必谨慎，不要将缺少 TLS 报告为安全问题。另外，使用“安全” Cookie 时也务必谨慎。只有在应用实际通过 TLS 提供服务时，才应设置此类 Cookie。如果在非 TLS 应用中设置（例如部署用于本地开发或测试时），应用将无法正常运行。你可以提供环境变量或其他标志来控制是否设置安全属性，以便在 TLS 生产部署前保持关闭。此外，避免建议使用 HSTS。若不了解其长期影响，使用 HSTS 会很危险（可能导致重大服务中断和用户无法访问），而且通常不建议在 codex 审查的项目范围内使用。