[译] Web 开发者安全清单

• 原文地址：Web Developer Security Checklist
• 原文做者：Michael O'Brien
• 译文出自：掘金翻译计划
• 译者： GangsterHyj
• 校对者： zaraguo, yzgyyang

Web 开发者安全清单

开发安全、健壮的云端 web 应用程序是很是困难的事情。若是你认为这很容易，要么你过着更高级的生活，要么你还正走向痛苦觉醒的路上。

假若你已经接受 MVP（最简可行产品） 的开发理念，而且相信能在一个月内创造既有价值又安全的产品 —— 在发布你的“原型产品”以前请再三考虑。在你检查下面列出的安全清单后，意识到你在开发过程当中忽视了不少极其重要的安全问题。至少要对你潜在的用户坦诚，让他们知道你并无真正完成产品，而仅仅只是提供没有充分考虑安全问题的原型。

这份安全清单很简单，绝非覆盖全部方面。它列出了在建立 web 应用时须要考虑的比较重要的安全问题。

若是下面的清单遗漏了你认为很重要的问题，请发表评论。

数据库

• 对识别用户身份的数据和诸如访问令牌、电子邮箱地址或帐单明细等敏感数据进行加密。
• 若是数据库支持在空闲状态进行低消耗的数据加密 (如 AWS Aurora)，那么请激活此功能以增强磁盘数据安全。确保全部的备份文件也都被加密存储。
• 对访问数据库的用户账号使用最小权限原则，禁止使用数据库 root 账号。
• 使用精心设计的密钥库存储和分发密钥，不要对应用中使用的密钥进行硬编码。
• 仅使用 SQL 预备语句以完全阻止 SQL 注入。例如，若是使用 NPM 开发应用，链接数据库时不使用 npm-mysql ，而是使用支持预备语句的 npm-mysql2 。

开发

• 确保已经检查过软件投入生存环境使用的每一个版本中全部组件的漏洞，包括操做系统、库和软件包。此操做应该以自动化的方式加入 CI/CD（持续集成/持续部署） 过程。
• 对开发环境系统的安全问题保持与生产环境一样的警戒，从安全、独立的开发环境系统构建软件。

认证

• 确保全部的密码都使用例如 bcrypt 之类的合适的加密算法进行哈希。绝对不要使用本身写的加密算法，并正确地使用随机数初始化加密算法。
• 使用简单但充分的密码规则以激励用户设置长的随机密码。
• 使用多因素身份验证方式实现对服务提供商的登陆操做。

拒绝服务防卫

• 确保对 API 进行 DOS 攻击不会让你的网站崩溃。至少增长速率限制到执行时间较长的 API 路径（例如登陆、令牌生成等程序）。
• 对用户提交的数据和请求在大小和结构上加强完整性限制。
• 使用相似 CloudFlare 的全局缓存代理服务应用以缓解 Distributed Denial of Service （DDOS，分布式拒绝服务攻击）对网站带来的影响。它会在你遭受 DDOS 攻击时被激活，而且还具备相似 DNS 查找等功能。

网络交通

• 整个网站使用 TLS （安全传输层协议），不要仅对登陆表单使用 TLS。
• Cookies 必须添加 httpOnly 和 secure 属性，且由属性 path 和 domain 限定做用范围。
• 使用 CSP（内容安全策略） 以禁止不安全的后门操做。策略的配置很繁琐，可是值得。
• 使用 X-Frame-Option 和 X-XSS-Protection 响应头。
• 使用 HSTS(HTTP Strict Transport Security) 响应强迫客户端仅使用 TLS 访问服务器，同时服务端须要将全部 HTTP 请求重定向为 HTTPS。
• 在全部表单中使用 CSRF 令牌，使用新响应头 SameSite Cookie 一次性解决 CSRF 问题， SameSite Cookie 适用于全部新版本的浏览器。

APIs

• 确保公有 API 中没有可枚举的资源。
• 确保每一个访问 API 的用户都能被恰当地认证和受权。

校验

• 使用客户端输入校验以及时给予用户反馈，可是不能彻底信任客户端校验结果。
• 使用服务器的白名单校验用户输入。不要直接向响应注入用户信息，切勿在 SQL 语句里使用用户输入。

云端配置

• 确保全部服务开放最少的端口。尽管经过隐藏信息来保障安全是不可靠的，使用非标准端口将使黑客的攻击操做更加困难。
• 在对任何公有网络都不可见的私有 VPC 上部署后台数据库和服务。在配置 AWS 安全组和对等互联多个 VPC 时务必谨慎（可能无心间使服务对外部可见）。
• 不一样逻辑的服务部署在不一样的 VPC 上，VPC 之间经过对等链接进行内部服务的访问。
• 让链接服务的 IP 地址个数尽量少。
• 限制对外输出的 IP 和端口流量，以最小化 APT（高级持续性威胁）和“警告”。
• 始终使用 AWS 的 IAM（身份与访问管理）角色，而不是使用 root 的认证信息。
• 对全部操做和开发人员使用最小访问权限原则。
• 按照预约计划按期轮换密码和访问密钥。

基础架构

• 确保在不停机的状况下对基础架构进行升级，确保以全自动的方式快速更新软件。
• 利用 Terraform 等工具建立全部的基础架构，而不是经过云端命令行窗口。基础架构应该代码化，仅需一个按钮的功夫便可重建。请不要手动在云端建立资源，由于使用 Terraform 就能够经过配置自动建立它们。
• 为全部服务使用集中化的日志记录，不应再利用 SSH 访问或检索日志。
• 除了一次性诊断服务故障之外，不要使用 SSH 登陆进服务。频繁使用 SSH ，意味着你还没将执行重要任务的操做自动化。
• 不要长期开听任何 AWS 服务组的22号端口。
• 建立 immutable hosts（不可变主机） 而不是使用一个通过你长期提交补丁和更新的服务器。。（详情请看博客 Immutable Infrastructure Can Be More Secure）。
• 使用如 SenseDeep 的 Intrusion Detection System（入侵检测系统） 或服务，以最小化 APTs（高级持续性威胁） 。

操做

• 关闭未使用的服务和服务器，关闭的服务器是最安全的。

测试

• 审核你的设计与实现。
• 进行渗透测试 — 攻击本身的应用，让其余人为你的应用编写测试代码。

最后，制定计划

• 准备用于描述网络攻击防护的威胁模型，列出可能的威胁和网络攻击参与者，并按优先级对其排序。
• 制定经得起实践考验的安全事故计划，总有一天你会用到它。

---

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、React、前端、后端、产品、设计 等领域，想要查看更多优质译文请持续关注 掘金翻译计划。