Web 开发人员安全检查表 V2

在云端开发安全、健壮的 Web 应用程序非常困难。如果你觉得很容易，那么你要么是更高级的生命形式，要么就是即将经历痛苦的​​觉醒。

如果您已经喝了MVP酷爱饮料并相信您可以在一个月内创造出既有价值又安全的产品——那么在推出“原型产品”之前请三思。

查看以下清单后，请确认您忽略了许多关键的安全问题。至少，请诚实地告知您的潜在用户，您尚未提供完整的产品，并且提供的原型产品并未提供全面的安全保障。

这份清单很简单，但绝不完整。我从事安全 Web 应用程序开发已有 14 年多，这份清单包含了我在此期间痛苦地总结出的一些更重要的问题。希望您在创建 Web 应用程序时能够认真考虑这些问题。

这是清单的第二版。它在第一版的基础上进行了重新组织，并根据公众需求新增了一些项目（谢谢）。我会尽力保持清单的简洁性和重点，但如果您认为我应该添加任何项目，请留言。

凭证和机密

• [ ] 使用专门设计的密钥库来存储和分发密钥。请勿将密钥硬编码到应用程序中，也绝对不要存储在 GitHub 中！对于 CMS 用户，请勿将您的凭据存储在文档目录中的文件中。

• [ ] 使用团队密码管理器（例如1Password）来管理所有服务密码和凭证。切勿通过电子邮件将密码或凭证发送给团队成员。

• [ ] 对所有服务提供商的登录使用多因素身份验证。

验证

• [ ] 确保所有密码都使用合适的加密算法（例如bcrypt ）进行哈希处理。切勿自行编写加密算法，并使用良好的随机数据正确初始化加密算法。建议使用Auth0或AWS Cognito等身份验证服务。

• [ ] 使用最佳实践和经过验证的组件来处理登录、忘记密码和其他密码重置问题。不要自行设计——在所有情况下都正确无误非常困难。

• [ ] 实施简单但足够的密码规则，鼓励用户使用长而随机的密码。

• [ ] 永远不要使用任何未记录或未公开的手段访问设备，包括后门账户（如“现场服务”）。

• [ ] 以最小权限运行应用程序和容器，并且永远不要以 root 身份运行（注意：Docker 默认以 root 身份运行应用程序）。

数据库

• [ ] 除非真正需要，否则请勿存储敏感数据。这通常指电子邮件地址、个人身份信息以及其他个人信息。应将敏感数据视为放射性废物——也就是说，保护敏感数据需要付出实际、巨大且持续的成本，而总有一天，这些数据可能会对您造成伤害。

• [ ] 保留所有存储敏感信息位置的完整列表：数据库、文件系统、Dropbox、GitHub、Vault、Office 文档，甚至纸质文件夹。这不仅有助于管理，也是 GDPR 的要求，如果遭到黑客攻击，更是至关重要。您需要能够找到所有敏感信息。

• [ ] 如果受 GDPR 约束，请确保您真正理解相关要求，并从一开始就将其纳入设计中。对于某些企业而言，这将意味着设计和思维上的重大转变。参见以及GDPR 简介。

• [ ] 如果可能，对识别用户的数据和敏感数据（如访问令牌、电子邮件地址或账单详细信息）使用加密（这会将查询限制为完全匹配查找）。

• [ ] 如果您的数据库支持低成本静态加密（例如AWS Aurora），请启用该功能以保护磁盘上的数据。确保所有备份也都加密存储。

• [ ] 对数据库访问用户帐户使用最低权限。不要使用数据库 root 帐户，并检查是否存在未使用的帐户和密码错误的帐户。

• [ ] 仅使用 SQL 预处理语句即可完全防止 SQL 注入。例如：如果使用 NPM，请勿使用 npm-mysql，而应使用支持预处理语句的 npm-mysql2。

应用程序

• [ ] 确保开发系统的安全，并使其与生产系统保持同等的警惕性。在安全、隔离的开发系统中构建软件。

• [ ] 确保在每次发布到生产环境的版本中，对软件的所有组件进行漏洞扫描。这包括操作系统、库和软件包。这应该自动纳入CI/CD流程。

• [ ] 进行客户端输入验证，以便快速获得用户反馈，但切勿轻信。务必在显示之前验证并编码用户输入。

• [ ] 使用服务器上的白名单验证所有用户输入。考虑使用Swagger之类的工具根据 API 规范生成验证代码，这比手动生成的代码更可靠。

• [ ] 切勿将用户内容直接注入响应中。切勿在 SQL 语句或其他服务器端逻辑中使用不受信任的用户输入。

• [ ] 对所有应用、服务器和服务使用集中式日志记录。您无需通过 SSH 即可访问或检索日志。

• [ ] 日志应包含足够的详细信息，以便诊断所有操作和安全问题，切勿记录敏感信息或个人信息。建议使用 JSON 格式创建日志，并使用高基数字段，而不是纯文本行。

• [ ] 不要向用户泄露错误详情或堆栈跟踪，也不要将启用 DEBUG 的应用程序部署到生产环境中。

蜜蜂

• [ ] 确保用户在使用您的 API 时经过完全身份验证并获得适当的授权。

• [ ] 确保公共 API 中不存在可枚举的资源。对于 ID，请考虑使用符合 RFC 4122 标准的 UUID，而不是整数。有关节点，请参阅NPM uuid。

• [ ] 在 API 中使用金丝雀检查来检测表明存在攻击的非法或异常请求。

网络流量

• [ ] 对您的网络进行分段并保护敏感服务。使用防火墙、虚拟专用网络 (VPN) 和云安全组来限制和控制往返于适当目的地的入站和出站流量。AWS和CloudFlare都提供了出色的产品。

• [ ] 对整个网站使用 TLS，而不仅仅是登录表单和响应。切勿仅对登录表单使用 TLS。过渡期，请使用 strict-transport-security 标头强制所有请求使用 HTTPS。

• [ ] Cookies 必须是 httpOnly 且安全的，并且受路径和域的限制。

• [ ] 使用CSP，但不要允许 unsafe-* 后门。配置起来很麻烦，但值得。对 CDN 内容使用 CSP子资源完整性保护。

• [ ] 在客户端响应中使用 X-Frame-Option 和 X-XSS-Protection 标头。使用https://observatory.mozilla.org为您的网站评分。

• [ ] 使用 HSTS 响应强制仅使用 TLS 访问。将所有 HTTP 请求重定向到服务器上的 HTTPS 作为备份。

• [ ] 在所有表单中使用 CSRF 令牌，并使用新的SameSite Cookie响应标头，它可以一劳永逸地修复所有较新的浏览器的 CSRF。

• [ ] 删除其他识别标头，这些标头可能会让黑客更容易识别您的堆栈和软件版本。

• [ ] 不要在 URL 中使用包含敏感数据或令牌的 GET 请求，因为这些数据或令牌将被记录在服务器和代理上。

云配置

• [ ] 确保所有服务都开放了最少数量的端口。虽然通过隐藏端口实现的安全性并不能完全杜绝安全隐患，但使用非标准端口会让攻击者的攻击难度有所增加。

• [ ] 将后端数据库和服务托管在任何公共网络上不可见的私有 VPC 上。配置 AWS 安全组和对等 VPC 时务必小心，因为这可能会无意中将服务暴露给公众。

• [ ] 在与生产资源不同的 AWS 账户中创建测试和暂存资源。

• [ ] 将逻辑服务隔离在单独的 VPC 和对等 VPC 中，以提供服务间通信。

• [ ] 确保所有服务只接受来自最少 IP 地址集的数据。

• [ ] 限制传出 IP 和端口流量，以最大限度地减少 APT 和“机器人化”。

• [ ] 始终使用 AWS IAM 角色而不是根凭证。

• [ ] 对所有操作和开发人员使用最小访问权限。

• [ ] 根据计划定期轮换密码和访问密钥。

基础设施

• [ ] 确保无需停机即可升级。确保能够以全自动方式快速更新软件。

• [ ] 使用Terraform等工具创建所有基础设施，而不是通过云控制台。基础设施应该定义为“代码”，并且能够一键重建。对任何在云中手动创建的资源零容忍——Terraform 可以审计你的配置。

• [ ] 除非是一次性诊断，否则不要通过 SSH 连接服务。经常使用 SSH 通常意味着你没有自动执行一项重要的任务。

• [ ] 请勿在任何 AWS 服务组上永久开放 22 端口。如果必须使用 SSH，请仅使用公钥身份验证，而不要使用密码。

• [ ] 创建不可变主机，而不是需要修补和升级的长期服务器。（请参阅不可变基础设施可以更安全）。

• [ ] 如果不使用不可变基础设施（不好），请确保您有一个自动化系统来修补和更新所有服务器，并定期更新您的 AMI 并轮换您的服务器以防止长期 APT。

• [ ] 关闭未使用的服务和服务器。最安全的服务器是处于关闭状态的服务器。请安排在下班后不需要时关闭开发服务器。

• [ ] 使用入侵检测系统来最大限度地减少APT。

拒绝服务保护

• [ ] 确保针对 API 的 DOS 攻击不会瘫痪您的网站。至少，在较慢的 API 路径和与身份验证相关的 API（例如登录和令牌生成例程）上设置速率限制器。考虑在前端 API 上使用验证码 (CAPTCHA)，以保护后端服务免受 DOS 攻击。

• [ ] 对用户提交的数据和请求的大小和结构实施合理限制。

• [ ] 执行混沌测试来确定您的服务在压力下的表现。

• [ ] 考虑通过CloudFlare等全局缓存代理服务来缓解分布式拒绝服务(DDOS) 攻击。如果您遭受 DDOS 攻击，可以启用此功能，否则它将作为您的 DNS 查找功能。

黑客自己

• [ ] 审核您的设计和实施。

• [ ] 进行渗透测试——自己进行渗透测试，但也请其他人也进行渗透测试。

• [ ] 主动测试您的应用，使其超出常规使用范围。请参考OWASP 测试清单来指导您的测试工作。

事件响应

• [ ] 对员工（尤其是高级员工）进行有关安全社会工程的危险和技术的培训。

• [ ] 建立一个威胁模型，描述你所防御的威胁。该模型应该列出所有可能的威胁和行为者，并按优先级排序。

• [ ] 设置一个标准的电子邮件帐户和网页，专门供用户报告安全问题（security@example.com和 /security）。

• [ ] 制定一个成熟的安全事故预案。总有一天你会用到它。

安全是一段旅程

最重要的是，请记住，安全性是一个过程，不可能在产品交付前就“嵌入”到产品中。我希望这份清单能够在整个开发生命周期中指导您提升服务的安全性。

我们在EmbedThis Ioto IoT 中间件中使用了这些技术。