Web 开发者安全清单

TODO/web-developer-security-checklist.md

@@ -5,96 +5,96 @@
 > * 校对者：
 
 
-# Web Developer Security Checklist #
+# Web 开发者安全清单
 
 ![](https://cdn-images-1.medium.com/max/800/1*UOl3ydmbG1ehgoSpBxdGFA.jpeg)
 
-Developing secure, robust web applications in the cloud is **hard, very hard**. If you think it is easy, you are either a higher form of life or you have a painful awakening ahead of you.
+开发安全、健壮的云端 web 应用程序是**非常困难**的事情。如果你认为这很容易，要么你过着更高级的生活，要么你还正走向痛苦觉醒的路上。
 
-If you have drunk the [MVP](https://en.wikipedia.org/wiki/Minimum_viable_product) cool-aid and believe that you can create a product in one month that is both valuable and secure — think twice before you launch your “proto-product”. After you review the checklist below, acknowledge that you are skipping many of these critical security issues. At the very minimum, be *honest* with your potential users and let them know that you don’t have a complete product yet and are offering a prototype without full security.
+倘若你已经接受 [MVP（最小化可行产品）](https://en.wikipedia.org/wiki/Minimum_viable_product) 的开发理念，并且相信能在一个月内创造既有价值又安全的产品 —— 在发布你的“原型产品”之前请再三考虑。在你检查下面列出的安全清单后，承认你在开发过程中忽视了很多极其重要的安全问题。至少要对你潜在的用户坦诚，让他们知道你并没有真正完成产品，而仅仅只是提供没有充分考虑安全问题的原型。
 
-This checklist is simple, and by no means complete. It is a list of some of the more important issues you should consider when creating a web application.
+这份安全清单很简单，绝非覆盖所有方面。它列出了在创建 web 应用时需要考虑的比较重要的安全问题。
 
-Please comment if you have an item I can add to the list.
+如果下面的清单遗漏了你认为很重要的问题，请发表评论。
 
-### **Database** ###
+### **数据库** ###
 
--  Use encryption for data identifying users and sensitive data like access tokens, email addresses or billing details.
--  If your database supports low cost encryption at rest (like [AWS Aurora](https://aws.amazon.com/about-aws/whats-new/2015/12/amazon-aurora-now-supports-encryption-at-rest/)), then enable that to secure data on disk. Make sure all backups are stored encrypted as well.
--  Use minimal privilege for the database access user account. Don’t use the database root account.
--  Store and distribute secrets using a key store designed for the purpose. Don’t hard code in your applications.
--  Fully prevent SQL injection by only using SQL prepared statements. For example: if using NPM, don’t use npm-mysql, use npm-mysql2 which supports prepared statements.
+-  对识别用户身份的数据和诸如访问令牌、电子邮箱地址或账单明细等敏感数据进行加密。
+-  如果数据库支持在休息状态进行低消耗的数据加密 (如 [AWS Aurora](https://aws.amazon.com/about-aws/whats-new/2015/12/amazon-aurora-now-supports-encryption-at-rest/))，那么请激活此功能以加强磁盘数据安全。确保所有的备份文件也都被加密存储。
+-  对访问数据库的用户帐号使用最小权限原则，禁止使用数据库 root 帐号。
+-  使用精心设计的密钥库存储和分发密钥，不要对应用中使用的密钥进行硬编码。
+-  仅使用 SQL 预备语句以彻底阻止 SQL 注入。例如，如果使用 NPM 开发应用，连接数据库时不使用 npm-mysql ，而是使用支持预备语句的 npm-mysql2 。
 
-### Development ###
+### **开发** ###
 
--  Ensure that all components of your software are scanned for vulnerabilities for every version pushed to production. This means O/S, libraries and packages. This should be automated into the CI-CD process.
--  Secure development systems with equal vigilance to what you use for production systems. Build the software from secured, isolated development systems.
+-  确保检查软件所有组件的每个投入生存环境使用的版本漏洞，包括操作系统、库和软件包。此操作应该以自动化的方式注入 CI/CD 过程。
+-  对开发环境系统的安全问题保持与生产环境同样的警惕，从安全、独立的开发环境系统构建软件。
 
-### Authentication ###
+### **认证** ###
 
--  Ensure all passwords are hashed using appropriate crypto such as bcrypt. Never write your own crypto and correctly initialize crypto with good random data.
--  Implement simple but adequate password rules that encourage users to have long, random passwords.
--  Use multi-factor authentication for your logins to all your service providers.
+-  确保所有密码都使用适当的加密算法（例如 bcrypt ）进行哈希。
+-  实现简单但充分的密码规则以激励用户使用长的随机密码。
+-  使用多因素身份验证方式实现对服务提供商的登录操作。
 
-### **Denial of Service Protection** ###
+### **拒绝服务防卫** ###
 
--  Make sure that DOS attacks on your APIs won’t cripple your site. At a minimum, have rate limiters on your slower API paths like login and token generation routines.
--  Enforce sanity limits on the size and structure of user submitted data and requests.
--  Use [Distributed Denial of Service](https://en.wikipedia.org/wiki/Denial-of-service_attack) (DDOS) mitigation via a global caching proxy service like [CloudFlare](https://www.cloudflare.com/). This can be turned on if you suffer a DDOS attack and otherwise function as your DNS lookup.
+-  确保对 API 进行 DOS 攻击不会让你的网站崩溃。至少在执行时间较长的 API 路径（例如登录、令牌生成等程序）使用速度限制器。
+-  对用户提交的数据和请求在大小和结构上增强完整性限制。
+-  通过类似 [CloudFlare](https://www.cloudflare.com/) 的全局缓存代理服务应用缓解 [Distributed Denial of Service](https://en.wikipedia.org/wiki/Denial-of-service_attack) (DDOS)对网站带来的影响。如果你遭受 DDOS 攻击，或者用于 DNS 查找，可以考虑开启此服务。？？？
 
-### **Web Traffic** ###
+### **网络交通** ###
 
--  Use TLS for the entire site, not just login forms and responses. Never use TLS for just the login form.
--  Cookies must be httpOnly and secure and be scoped by path and domain.
--  Use [CSP](https://en.wikipedia.org/wiki/Content_Security_Policy) without allowing unsafe-* backdoors. It is a pain to configure, but worthwhile.
--  Use X-Frame-Option, X-XSS-Protection headers in client responses
--  Use HSTS responses to force TLS only access. Redirect all HTTP request to HTTPS on the server as backup.
--  Use CSRF tokens in all forms and use the new [SameSite Cookie](https://scotthelme.co.uk/csrf-is-dead/) response header which fixes CSRF once and for all newer browsers.
+-  整个网站使用 TLS （安全传输层协议），不要仅对登录表单使用 TLS。
+-  Cookies 必须添加 httpOnly 和 secure 属性，且由属性 path 和 domain 限定作用范围。
+-  使用 [CSP（内容安全策略）](https://en.wikipedia.org/wiki/Content_Security_Policy) 以禁止不安全的后门操作。策略的配置很繁琐，但是值得。
+-  使用 X-Frame-Option 和 X-XSS-Protection 响应头。
+-  使用 HSTS(HTTP Strict Transport Security) 响应强迫客户端仅使用 TLS 访问服务器。将所有 HTTP 请求重定向到服务器上的 HTTPS 作为后备。？？？
+-  在所有表单中使用 CSRF 令牌，使用新响应头 [SameSite Cookie](https://scotthelme.co.uk/csrf-is-dead/) 一次性解决 CSRF 问题， SameSite Cookie 适用于所有新版本的浏览器。
 
 ### **APIs** ###
 
--  Ensure that no resources are enumerable in your public APIs.
--  Ensure that users are fully authenticated and authorized appropriately when using your APIs.
+-  确保公有 API 中没有可枚举的资源。
+-  确保每个访问 API 的用户都能被恰当地认证和授权。
 
-### **Validation** ###
+### **校验** ###
 
--  Do client-side input validation for quick user feedback, but never trust it.
--  Validate every last bit of user input using white lists on the server. Never directly inject user content into responses. Never use user input in SQL statements.
+-  执行客户端输入校验以快速获取用户的反馈，但是不能完全依赖校验。
+-  使用服务器的白名单校验用户输入。不要向响应直接注入用户信息，不要在 SQL 语句使用用户输入。
 
-### **Cloud Configuration** ###
+### **云端配置** ###
 
--  Ensure all services have minimum ports open. While security through obscurity is no protection, using non-standard ports will make it a little bit harder for attackers.
--  Host backend database and services on private VPCs that are not visible on any public network. Be very careful when configuring AWS security groups and peering VPCs which can inadvertently make services visible to the public.
--  Isolate logical services in separate VPCs and peer VPCs to provide inter-service communication.
--  Ensure all services only accept data from a minimal set of IP addresses.
--  Restrict outgoing IP and port traffic to minimize APTs and “botification”.
--  Always use AWS IAM roles and not root credentials.
--  Use minimal access privilege for all ops and developer staff
--  Regularly rotate passwords and access keys according to a schedule.
+-  确保所有服务开放最少的端口。尽管是通过模糊的安全性不受保护的，使用非标准端口将使得黑客的攻击更加困难。
+-  在对任何公有网络都不可见的私有 VPC 上部署后台数据库和服务。配置 AWS 安全组和对等 VPC 务必谨慎（可能无意间使服务对外部可见）。
+-  在独立的 VPC 和对等的 VPC 隔离逻辑服务，以提供内部服务交流。？？？
+-  确保所有服务仅接收来自最小的IP地址集合的数据。
+-  限制对外输出的 IP 和端口流量，以最小化 APT（高级持续性威胁） 和 “警告”。
+-  始终使用 AWS 的 IAM （身份与访问管理）角色，而不是使用 root 的认证信息。
+-  对所有操作和开发人员使用最小访问权限原则。
+-  按照预定计划定期轮换密码和访问密钥。
 
-### **Infrastructure** ###
+### **基础架构** ###
 
--  Ensure you can do upgrades without downtime. Ensure you can quickly update software in a fully automated manner.
--  Create all infrastructure using a tool such as Terraform, and not via the cloud console. Infrastructure should be defined as “code” and be able to be recreated at the push of a button. Have zero tolerance for any resource created in the cloud by hand — Terraform can then audit your configuration.
--  Use centralized logging for all services. You should never need SSH to access or retrieve logs.
--  Don’t SSH into services except for one-off diagnosis. Using SSH regularly, typically means you have not automated an important task.
--  Don’t keep port 22 open on any AWS service groups on a permanent basis.
--  Create [immutable hosts](http://chadfowler.com/2013/06/23/immutable-deployments.html) instead of long-lived servers that you patch and upgrade. (See [Immutable Infrastructure Can Be More Secure](https://simplesecurity.sensedeep.com/immutable-infrastructure-can-be-dramatically-more-secure-238f297eca49)).
--  Use an [Intrusion Detection System](https://en.wikipedia.org/wiki/Intrusion_detection_system) like [SenseDeep](https://www.sensedeep.com/) or service to minimize [APTs](https://en.wikipedia.org/wiki/Advanced_persistent_threat) .
+-  确保在不停机的情况下对基础架构进行升级，确保以全自动的方式快速更新软件。
+-  利用 Terraform 等工具创建所有的基础架构，而不是通过云端命令行窗口。基础架构应该定义为“代码”，仅需一个按钮的功夫即可重建。对云端任何亲手创建的资源零容忍 —— Terraform 能审查你的所有配置。？？？
+-  为所有服务使用集中化的日志记录，不该再利用 SSH 访问或检索日志。
+-  除了一次性诊断以外，不要使用 SSH 登录进服务。 经常使用 SSH ，意味着你还没有将执行重要任务的操作自动化。？？？
+-  不要长期开放任何AWS服务组的22号端口。
+-  创建 [immutable hosts（不可变主机）](http://chadfowler.com/2013/06/23/immutable-deployments.html) 而不是创建需要提交补丁和更新的服务器。（详情请看博客 [Immutable Infrastructure Can Be More Secure](https://simplesecurity.sensedeep.com/immutable-infrastructure-can-be-dramatically-more-secure-238f297eca49)）。
+-  使用如 [SenseDeep](https://www.sensedeep.com/) 的 [Intrusion Detection System（入侵检测系统）](https://en.wikipedia.org/wiki/Intrusion_detection_system) 或服务，以最小化 [APTs（高级持续性威胁）](https://en.wikipedia.org/wiki/Advanced_persistent_threat) 。
 
-### **Operation** ###
+### **操作** ###
 
--  Power off unused services and servers. The most secure server is one that is powered down.
+-  关闭未使用的服务和服务器，最安全的服务器是关机的。
 
-### Test ###
+### **测试** ###
 
--  Audit your design and implementation.
--  Do penetration testing — hack yourself, but also have someone other than you pen testing as well.
+-  审核你的设计与实现。
+-  进行渗透测试 — 攻击自己的应用，让其他人为你的应用编写测试代码。
 
-### **Finally, have a plan** ###
+### **最后，制定计划** ###
 
--  Have a threat model that describes what you are defending against. It should list and prioritize the possible threats and actors.
--  Have a practiced security incident plan. One day, you will need it.
+-  准备用于描述网络攻击防御的威胁模型，它应该列出并优先考虑可能的威胁和网络攻击参与者。
+-  制定经得起实践考验的安全事故计划，总有一天你会用到它。
 
 ---