Web 开发人员安全检查表 V1

此清单已在Web 开发人员清单 V2中更新。

最初发布于：https://www.sensedeep.com/blog/posts/stories/web-developer-security-checklist.html

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

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

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

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

如果您有我可以添加到列表中的项目，请发表评论。

数据库

[ ] 对识别用户的数据和敏感数据（如访问令牌、电子邮件地址或账单详细信息）使用加密。

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

[ ] 对数据库访问用户帐户使用最小权限。不要使用数据库 root 帐户。

[ ] 使用专门设计的密钥存储系统（例如Vault或AWS Secret Manager ）来存储和分发机密信息。请勿在应用程序中对机密信息进行硬编码，也切勿将机密信息签入 GitHub。

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

发展

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

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

验证

[ ] 确保所有密码都使用合适的加密算法（例如bcrypt ）进行哈希处理。切勿自行编写加密算法，并使用良好的随机数据正确初始化加密算法。

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

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

拒绝服务保护

[ ] 确保针对 API 的 DOS 攻击不会瘫痪您的网站。至少，在较慢的 API 路径（例如登录和令牌生成例程）上设置速率限制器。

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

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

网络流量

[ ] 对整个网站使用 TLS，而不仅仅是登录表单和响应。切勿仅在登录表单上使用 TLS。

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

[ ] 使用CSP，但不允许 unsafe-* 后门。配置起来比较麻烦，但值得。

[ ] 在客户端响应中使用 X-Frame-Option、X-XSS-Protection 标头

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

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

蜜蜂

[ ] 确保您的公共 API 中没有任何资源是可枚举的。

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

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

验证

[ ] 进行客户端输入验证以便快速获得用户反馈，但永远不要相信它。

[ ] 使用服务器上的白名单验证用户输入的每一位信息。切勿将用户内容直接注入响应中。切勿在 SQL 语句中使用用户输入。

云配置

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

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

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

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

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

[ ] 始终使用 AWS IAM 用户和角色，而非根凭证。投入精力学习如何有效使用 IAM。

[ ] 对所有运维和开发人员使用最低访问权限。赋予 IAM 用户和角色完成任务所需的最低权限。

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

基础设施

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

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

[ ] 所有服务均采用集中式日志记录。您无需通过 SSH 即可访问或检索日志。

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

[ ] 不要在任何 AWS 服务组上永久保持端口 22 开放。

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

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

手术

[ ] 关闭未使用的服务和服务器。最安全的服务器是处于关闭状态的服务器。

测试

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

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

最后，制定计划

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

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

安全是一段旅程

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

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