Merge branch 'master' of github.com:FallibleInc/security-guide-for-de…

…velopers

README-zh.md

@@ -1,13 +1,13 @@
-# 实用性WEB开发人员安全须知  
+# 实用性 WEB 开发人员安全须知  
 
 ### 目标读者  
 
 安全问题主要由以下两类原因导致：   
 
-1. 那些刚入门的无法区分MD5和bcrypt作用的开发者  
+1. 那些刚入门的无法区分 MD5 和 bcrypt 作用的开发者  
 2. 那些知道这件事但忘记/忽略了的开发者  
 
-我们的详细说明应该可以帮到第1类开发者，而我们希望的我们的checklist可以帮到第2类的开发者构建更多安全的系统。这绝不是一个综合性的指南，仅仅是覆盖了大多数我们过去发现的比较常见的问题。  
+我们的详细说明应该可以帮到第 1 类开发者，而我们希望我们的 checklist 可以帮到第 2 类的开发者构建更多的安全系统。这并不是一个综合性的全面指南，只是覆盖了大多数我们在过去发现的常见问题。  
 
 
 
@@ -23,7 +23,7 @@
 4.4 为什么使用不安全的文本消息? HOTP & TOTP 介绍   
 4.5 处理密码重置  
 5. 权限验证: 我能做什么？  
-5.1 基于Token的权限验证    
+5.1 基于 Token 的权限验证    
 5.2 OAuth 和 OAuth2  
 5.3 JWT（JSON Web Token）  
 6. 数据校验和过滤: 绝不信任用户输入  
@@ -42,18 +42,18 @@
 8.1 密码策略  
 8.2 密码存储  
 8.3 没有密码的生活  
-9. 公钥加密 
+9. 公钥加密
 10. 会话: 请记住我   
 10.1 哪里存储状态？   
 10.2 使会话失效    
-10.3 Cookie怪物和你  
+10.3 Cookie 怪物和你  
 11. 加固安全, 一次只有一个头信息    
-11.1 安全的web header    
+11.1 安全的 web header    
 11.2 第三方代码的数据集成检测    
 11.3 证书绑定  
 12. 配置错误      
 12.1 云上准备: 端口、Shodan、AWS  
-12.2 亲，你开了debug模式    
+12.2 亲，你开了 debug 模式    
 12.3 日志（或者没有日志）  
 12.4 监控  
 12.5 最低优先级原理    
@@ -68,18 +68,18 @@
 13.4 服务端请求伪造  
 14. [互联网公司漏洞统计](vulnerabilities-stats-zh.md)   
 15. 重造轮子，但做出来是方的    
-15.1 Python的安全库和包    
-15.2 NodeJS的安全库和包  
+15.1 Python 的安全库和包    
+15.2 NodeJS 的安全库和包  
 15.3 学习资料  
 16. 掌握良好的安全习惯  
-17. 安全性  vs 可用性  
-18. 回到第1条: 安全Checklist解释  
+17. 安全性 vs 可用性  
+18. 回到第 1 条: 安全 Checklist 解释  
 
 
 
 
 ### 我们是谁?
 
-我们是全栈开发工程师，讨厌看到那些所谓为了做某件事情而hack，但写了一堆不安全的代码的开发者。在过去六个月，我们保护了超过1500w信用卡信息以及超过4500w用户的个人信息以及被盗，以及防止了大量的公司倒闭。最近，我们发现一个安全问题就能使一家比特币交易公司数据泄露从而倒闭。我们以及帮助了若干创业公司让他们的系统更安全，大多数是免费的，有时候甚至连『谢谢』都没收到：）
+我们是全栈开发工程师，讨厌看到那些所谓为了做某件事情而 hack，但写了一堆不安全代码的开发者。在过去六个月，我们保护了超过 1500w 信用卡信息不被泄露，超过 4500w 的用户个人信息不被盗取，潜在的拯救了大量公司的倒闭。最近，我们发现的一个安全问题，可以导致一家比特币交易公司因数据泄露而倒闭。我们帮助了若干创业公司让他们的系统更安全，大多数都是免费的，有时候甚至连『谢谢』都没收到 :)
 
-*如果你不同意我们的观点或者找到bug，请开启一个issue或者提交一个PR给我们。另外，你也可以通过 hello@fallible.co 与我们交流。*
+*如果你不同意我们的观点或者找到 bug，请开启一个 issue 或者提交一个 PR 给我们。另外，你也可以通过 hello@fallible.co 与我们交流。*

README.md

@@ -1,4 +1,4 @@
-# A practical security guide for web developers
+# A practical security guide for web developers (Work in progress)
 
 ### The intended audience
 
@@ -13,7 +13,7 @@ Our detailed explanations should help the first type while we hope our checklist
 ### Contents
 
 1. [The Security Checklist](security-checklist.md)
-2. What can go wrong?
+2. [What can go wrong?](what-can-go-wrong.md)    
 3. Securely transporting stuff: HTTPS explained
 4. Authentication: I am who I say I am  
 4.1 Form based authentication  

security-checklist-zh.md

@@ -3,80 +3,80 @@
 
 ### 安全checklist   
 
-##### 权限系统 (注册/注册/二次验证/密码重置) 
-- [ ] 任何地方都使用HTTPS.
-- [ ] 使用`Bcrypt`存储密码哈希 (没有使用盐的必要 - `Bcrypt` 干的就是加密这个事情).
-- [ ] `登出`之后销毁会话ID .  
+##### 权限系统 (注册/注册/二次验证/密码重置)
+- [ ] 任何地方都使用 HTTPS.
+- [ ] 使用 `Bcrypt` 存储密码哈希 (没有使用盐的必要 - `Bcrypt` 干的就是这个事).
+- [ ] `登出`之后销毁会话 ID .  
 - [ ] 密码重置后销毁所有活跃的会话.  
 - [ ] OAuth2 验证必须包含 `state` 参数.
 - [ ] 登陆成功之后不能直接重定向到开放的路径（需要校验，否则容易存在钓鱼攻击）.
-- [ ] 当解析用户注册/登陆的输入时，过滤 javascript://、 data:// 以及其他 CRLF 字符. 
+- [ ] 当解析用户注册/登陆的输入时，过滤 javascript://、 data:// 以及其他 CRLF 字符.
 - [ ] 使用 secure/httpOnly cookies.
-- [ ] 移动端使用`OTP`验证时，当调用`generate OTP` 或者 `Resend OTP` API时不能吧OTP（One Time Password）直接返回。（一般是通过发送手机验证短信，邮箱随机code等方式，而不是直接response）  
-- [ ] 限制单个用户`Login`、`Verify OTP`、 `Resend OTP`、`generate OTP`等API的调用次数，使用Captcha等手段防止暴力破解.  
-- [ ] 检查邮件或短信里的重置密码的token，确保随机性（无法猜测）  
-- [ ] 给重置密码的token设置过期时间.
-- [ ] 重置密码成功后，将重置使用的token失效.
+- [ ] 移动端使用 `OTP` 验证时，当调用 `generate OTP` 或者 `Resend OTP` API 时不能把 OTP（One Time Password） 直接返回。（一般是通过发送手机验证短信，邮箱随机 code 等方式，而不是直接 response）  
+- [ ] 限制单个用户 `Login`、`Verify OTP`、 `Resend OTP`、`generate OTP` 等 API 的调用次数，使用 Captcha 等手段防止暴力破解.  
+- [ ] 检查邮件或短信里的重置密码的 token，确保随机性（无法猜测）  
+- [ ] 给重置密码的 token 设置过期时间.
+- [ ] 重置密码成功后，将重置使用的 token 失效.
 
 
 ##### 用户数据和权限校验  
-- [ ] 诸如`我的购物车`、`我的浏览历史`之类的资源访问，必须检查当前登录的用户是否有这些资源的访问权限。  
-- [ ] 避免资源ID被连续遍历访问，使用`/me/orders` 代替 `/user/37153/orders` 以防你忘了检查权限，导致数据泄露。   
+- [ ] 诸如`我的购物车`、`我的浏览历史`之类的资源访问，必须检查当前登录的用户是否有这些资源的访问权限.
+- [ ] 避免资源 ID 被连续遍历访问，使用 `/me/orders` 代替 `/user/37153/orders` 以防你忘了检查权限，导致数据泄露。   
 - [ ] `修改邮箱/手机号码`功能必须首先确认用户已经验证过邮箱/手机是他自己的。  
-- [ ] 任何上传功能应该过滤用户上传的文件名，另外，为了普适性的原因（而不是安全问题），上传的东西应该存放到例如S3之类的云存储上面，而不是存储在这几的服务器，防止代码执行。  
+- [ ] 任何上传功能应该过滤用户上传的文件名，另外，为了普适性的原因（而不是安全问题），上传的东西应该存放到例如 S3 之类的云存储上面(用 lambda 处理)，而不是存储在自己的服务器，防止代码执行。  
 - [ ] `个人头像上传` 功能应该过滤所有的 `EXIF` 标签，即便没有这个需求.  
-- [ ] 用户ID或者其他的ID，应该使用 [RFC compliant ](http://www.ietf.org/rfc/rfc4122.txt) 的`UUID` 而不是整数. 你可以从github找到你所用的语言的实现.  
-- [ ] [JWT（JSON Web Token）](https://jwt.io/)很棒.当你需要做一个单页应用/API的使用使用.  
+- [ ] 用户 ID 或者其他的 ID，应该使用 [RFC compliant ](http://www.ietf.org/rfc/rfc4122.txt) 的 `UUID` 而不是整数. 你可以从 github 找到你所用的语言的实现.  
+- [ ] [JWT（JSON Web Token）](https://jwt.io/)很棒.当你需要构建一个 单页应用/API 时使用.  
 
 
-##### 安卓和iOS APP
-- [ ] 支付网关的 `盐（salt）` 不应该硬编码  
-- [ ] 来自第三方的 `secret` 和 `auth token` 不应该硬编码  
-- [ ] 在服务器之间调用的API不应该在app里面调用  
+##### 安卓和 iOS APP
+- [ ] 支付网关的 `盐（salt）` 不应该被硬编码  
+- [ ] 来自第三方的 `secret` 和 `auth token` 不应该被硬编码  
+- [ ] 在服务器之间调用的 API 不应该在 app 里面调用  
 - [ ] 在安卓系统下，要小心评估所有申请的 [权限](https://developer.android.com/guide/topics/security/permissions.html)   
-- [ ] 在iOS系统下，使用系统的钥匙串来存储敏感信息（权限token，api key等等）。 __不要__ 把这类信息存储在用户配置里面  
+- [ ] 在 iOS 系统下，使用系统的钥匙串来存储敏感信息（权限 token、api key、 等等） __不要__ 把这类信息存储在用户配置里面  
 - [ ] 强烈推荐[证书绑定（Certificate pinning）](https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning)   
 
 
 ##### 安全头信息和配置  
 - [ ] `添加` [CSP](https://en.wikipedia.org/wiki/Content_Security_Policy) 头信息，减缓 XSS 和数据注入攻击. 这很重要.  
-- [ ] `添加` [CSRF](https://en.wikipedia.org/wiki/Cross-site_request_forgery) 头信息防止跨站请求调用（CSRF）攻击.同时`添加` [SameSite](https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00) 属性到cookie里面.  
-- [ ] `添加` [HSTS](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security) 头信息防止SSL stripping攻击.
+- [ ] `添加` [CSRF](https://en.wikipedia.org/wiki/Cross-site_request_forgery) 头信息防止跨站请求伪造（CSRF）攻击.同时`添加` [SameSite](https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00) 属性到 cookie 里面.  
+- [ ] `添加` [HSTS](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security) 头信息防止 SSL stripping 攻击.
 - [ ] `添加` 你的域名到 [HSTS 预加载列表](https://hstspreload.appspot.com/)
 - [ ] `添加` [X-Frame-Options](https://en.wikipedia.org/wiki/Clickjacking#X-Frame-Options) 防止点击劫持.  
-- [ ] `添加` [X-XSS-Protection](https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#X-XSS-Protection) 缓解XSS攻击.  
-- [ ] `更新`DNS记录，增加 [SPF](https://en.wikipedia.org/wiki/Sender_Policy_Framework) 记录防止垃圾邮件和钓鱼攻击.  
-- [ ] 如果你的Javascript 库存放在第三方的CDN上面，需要`添加` [内部资源集成检查](https://en.wikipedia.org/wiki/Subresource_Integrity) 。为了更加安全，添加[require-sri-for](https://w3c.github.io/webappsec-subresource-integrity/#parse-require-sri-for) CSP-directive 就不会加载到没有SRI的资源。  
-- [ ] 使用随机的CSRF token，业务逻辑API可以暴露为POST请求。不要把CSRF token通过http接口暴露出来比如第一次请求更新的时候。  
-- [ ] 在get请求参数里面，不要使用临界数据和token。 暴露服务器日志的同时也会暴露用户数据。
-  
-  
+- [ ] `添加` [X-XSS-Protection](https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#X-XSS-Protection) 缓解 XSS 攻击.  
+- [ ] `更新` DNS 记录，增加 [SPF](https://en.wikipedia.org/wiki/Sender_Policy_Framework) 记录防止垃圾邮件和钓鱼攻击.  
+- [ ] 如果你的 Javascript 托管在第三方的 CDN 上面，需要`添加` [内部资源集成检查](https://en.wikipedia.org/wiki/Subresource_Integrity) 。为了更加安全，添加[require-sri-for](https://w3c.github.io/webappsec-subresource-integrity/#parse-require-sri-for) CSP-directive 就不会加载到没有 SRI 的资源  
+- [ ] 使用随机的 CSRF token，业务逻辑 API 可以暴露为 POST 请求。不要把 CSRF token 通过 http 接口暴露出来，比如第一次请求更新的时候  
+- [ ] 在 get 请求参数里面，不要使用临界数据和 token。 暴露服务器日志的同时也会暴露用户数据
+
+
 ##### 过滤输入  
 - [ ] 所有暴露给用户的参数输入都应该 `过滤` 防止 [XSS](https://en.wikipedia.org/wiki/Cross-site_scripting) 攻击.
 - [ ] 使用参数化的查询防止 [SQL 注入](https://en.wikipedia.org/wiki/SQL_injection).  
-- [ ] 过滤所有具有功能性的用户输入，比如`CSV导入`    
-- [ ] `过滤`一些特殊的用户输入，例如将robots.txt作为用户名，而你刚好提供了 coolcorp.io/username 之类的url来提供用户信息访问页面。（此时变成 coolcorp.io/robots.txt，可能无法正常工作）  
-- [ ] 不要自己手动拼装JSON字符串，不管这个字符串有多么小。请使用你所用的语言相应的库或者框架来编写。  
-- [ ] `过滤` 那些有点像URL的输入，防止 [SSRF](https://docs.google.com/document/d/1v1TkWZtrhzRLy0bYXBcdLUedXGb9njTNIJXa3u9akHM/edit#heading=h.t4tsk5ixehdd) 攻击  
-- [ ] 输出显示给用户之前需要`过滤`，防止XSS攻击.
+- [ ] 过滤所有具有功能性的用户输入，比如 `CSV导入`    
+- [ ] `过滤`一些特殊的用户输入，例如将 robots.txt 作为用户名，而你刚好提供了 coolcorp.io/username 之类的 url 来提供用户信息访问页面。（此时变成 coolcorp.io/robots.txt，可能无法正常工作）  
+- [ ] 不要自己手动拼装 JSON 字符串，不管这个对象有多么小。请使用你所用的语言相应的库或者框架来编写
+- [ ] `过滤` 那些有点像 URL 的输入，防止 [SSRF](https://docs.google.com/document/d/1v1TkWZtrhzRLy0bYXBcdLUedXGb9njTNIJXa3u9akHM/edit#heading=h.t4tsk5ixehdd) 攻击  
+- [ ] 在输出显示给用户之前，`过滤`输出信息
 
 ##### 操作  
-- [ ] 如果你的业务很小或者你缺乏经验，可以评估一下使用AWS或者一个PaaS平台来运行你的代码  
-- [ ] 在云上使用正规的脚本创建虚拟结  
+- [ ] 如果你的业务很小或者你缺乏经验，可以评估一下使用 AWS 或者一个 PaaS 平台来运行代码  
+- [ ] 在云上使用正规的脚本创建虚拟机  
 - [ ] 检查所有机器没有必要开放的`端口`  
-- [ ] 检查数据库是否没有密码或者使用默认密码，特别是MongoDB和Redis  
-- [ ] 使用SSH登录你的机器，不要使用密码，而是使用 SSH key 验证来登录  
-- [ ] 及时更新系统，防止出现0day漏洞，比如Heartbleed、Shellshock等  
-- [ ] 修改服务器配置，HTTPS使用TLS1.2，禁用其他的模式。(值得这么做)
-- [ ] 不要在线上开启DEBUG模式，有些框架，DEBUG模式会开启很多权限或者后门，或者暴露一些敏感数据到错误栈信息里面  
-- [ ] 对坏人和DDOS攻击要有所准备，选择那些提供DDOS清洗的主机服务  
-- [ ] 监控你的系统，同时写到日志里面 (例如使用 [New Relic](https://newrelic.com/) ).
-- [ ] 如果是2B的业务，坚持顺从需求。如果使用AWS S3,可以考虑使用 [数据加密](http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html) 功能. 如果使用AWS EC2，考虑使用磁盘加密功能（现在系统启动盘也能加密了）  
+- [ ] 检查数据库是否没有设置密码或者使用默认密码，特别是 MongoDB 和 Redis  
+- [ ] 使用 SSH 登录你的机器，不要使用密码，而是通过 SSH key 验证来登录  
+- [ ] 及时更新系统，防止出现 0day 漏洞，比如 Heartbleed、Shellshock 等  
+- [ ] 修改服务器配置，HTTPS 使用 TLS1.2，禁用其他的模式。(值得这么做)
+- [ ] 不要在线上开启 DEBUG 模式，有些框架，DEBUG 模式会开启很多权限以及后门，或者是暴露一些敏感数据到错误栈信息里面  
+- [ ] 对坏人和 DDOS 攻击要有所准备，使用那些提供 DDOS 清洗的主机服务  
+- [ ] 监控你的系统，同时记录到日志里面 (例如使用 [New Relic](https://newrelic.com/) 或者其他 ).
+- [ ] 如果是 2B 的业务，坚持顺从需求。如果使用 AWS S3,可以考虑使用 [数据加密](http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html) 功能. 如果使用 AWS EC2，考虑使用磁盘加密功能（现在系统启动盘也能加密了）  
 
 ##### 关于人  
-- [ ] 开一个邮件组和搜集页面，方便安全研究人员提交漏洞  
-- [ ] 信任你所创造的东西，限制用户数据库的访问  
-- [ ] 对报告bug、漏洞的人有礼貌
-- [ ] 将你的代码给那些有安全编码观念的同伴review (More eyes)
-- [ ] 出现被黑或者数据泄露是，检查数据访问前的日志，让相关的人改密码。你可能需要外部的机构来帮助审计  
-- [ ] 使用 [Netflix Scumblr](https://github.com/Netflix/Scumblr) 及时了解你的组织（公司）在社交网络或者搜索引擎上的一些讨论信息，比如黑客攻击、漏洞等等。    
+- [ ] 开一个邮件组（例如：security@coolcorp.io）和搜集页面，方便安全研究人员提交漏洞  
+- [ ] 取决于你的业务，限制用户数据库的访问  
+- [ ] 对报告 bug、漏洞的人有礼貌
+- [ ] 把你的代码给那些有安全编码观念的同伴进行 review (More eyes)
+- [ ] 被黑或者数据泄露时，检查数据访问前的日志，通知用户更改密码。你可能需要外部的机构来帮助审计  
+- [ ] 使用 [Netflix Scumblr](https://github.com/Netflix/Scumblr) 及时了解你的组织（公司）在社交网络或者搜索引擎上的一些讨论信息，比如黑客攻击、漏洞等等