实用性 WEB 开发人员安全须知

目标读者

安全问题主要由以下两类原因导致：

1. 那些刚入门的无法区分 MD5 和 bcrypt 作用的开发者
2. 那些知道这件事但忘记/忽略了的开发者

我们的详细说明应该可以帮到第 1 类开发者，而我们希望我们的 checklist 可以帮到第 2 类的开发者构建更多的安全系统。这并不是一个综合性的全面指南，只是覆盖了大多数我们在过去发现的常见问题。

目录

1. 安全Checklist
2. 什么东西会出问题?
3. 安全地传输数据: HTTPS 详解
4. 权限验证: 我是谁？

4.1 基于表单的权限验证 4.2 基础鉴权 4.3 一次是不够的、二次、三次（验证）.... 4.4 为什么使用不安全的文本消息? HOTP & TOTP 介绍 4.5 处理密码重置

1. 权限验证: 我能做什么？

5.1 基于 Token 的权限验证 5.2 OAuth 和 OAuth2 5.3 JWT（JSON Web Token）

1. 数据校验和过滤: 绝不信任用户输入

6.1 校验和过滤用户输入 6.2 过滤输出 6.3 跨站脚本攻击（XSS） 6.4 注入攻击 6.5 用户上传 6.6 用户篡改输入

1. 纯文本 != 编码 != 加密 != 哈希

7.1 通用编码模式 7.2 加密 7.3 哈希和单向函数（功能） 7.4 哈希速度对照表

1. 密码: dadada、123456、cute@123

8.1 密码策略 8.2 密码存储 8.3 没有密码的生活

1. 公钥加密
2. 会话: 请记住我

10.1 哪里存储状态？ 10.2 使会话失效 10.3 Cookie 怪物和你

1. 加固安全, 一次只有一个头信息

11.1 安全的 web header 11.2 第三方代码的数据集成检测 11.3 证书绑定

1. 配置错误

12.1 云上准备: 端口、Shodan、AWS 12.2 亲，你开了 debug 模式 12.3 日志（或者没有日志） 12.4 监控 12.5 最低优先级原理 12.6 （请求）频率限制 和 Captchas 12.7 把项目的密钥和密码保存在文件上 12.8 DNS: 关于子域名和被遗忘的宠物计划 12.9 打补丁和更新

1. 攻击: 当坏人来临

13.1 点击劫持 13.2 跨站请求伪造 13.3 拒绝服务 13.4 服务端请求伪造

1. 互联网公司漏洞统计
2. 重造轮子，但做出来是方的

15.1 Python 的安全库和包 15.2 NodeJS 的安全库和包 15.3 学习资料

1. 掌握良好的安全习惯
2. 安全性 vs 可用性
3. 回到第 1 条: 安全 Checklist 解释

我们是谁?

我们是全栈开发工程师，讨厌看到那些所谓为了做某件事情而 hack，但写了一堆不安全代码的开发者。在过去六个月，我们保护了超过 1500w 信用卡信息不被泄露，超过 4500w 的用户个人信息不被盗取，潜在的拯救了大量公司的倒闭。最近，我们发现的一个安全问题，可以导致一家比特币交易公司因数据泄露而倒闭。我们帮助了若干创业公司让他们的系统更安全，大多数都是免费的，有时候甚至连『谢谢』都没收到 :)

如果你不同意我们的观点或者找到 bug，请开启一个 issue 或者提交一个 PR 给我们。另外，你也可以通过 hello@fallible.co 与我们交流。

security checklist zh

返回目录

安全checklist

权限系统 (注册/注册/二次验证/密码重置)

• ☐ 任何地方都使用 HTTPS.
• ☐ 使用 Bcrypt 存储密码哈希 (没有使用盐的必要 - Bcrypt 干的就是这个事).
• ☐ 登出之后销毁会话 ID .
• ☐ 密码重置后销毁所有活跃的会话.
• ☐ OAuth2 验证必须包含 state 参数.
• ☐ 登陆成功之后不能直接重定向到开放的路径（需要校验，否则容易存在钓鱼攻击）.
• ☐ 当解析用户注册/登陆的输入时，过滤 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 失效.

用户数据和权限校验

• ☐ 诸如我的购物车、我的浏览历史之类的资源访问，必须检查当前登录的用户是否有这些资源的访问权限.
• ☐ 避免资源 ID 被连续遍历访问，使用 /me/orders 代替 /user/37153/orders 以防你忘了检查权限，导致数据泄露。
• ☐ 修改邮箱/手机号码功能必须首先确认用户已经验证过邮箱/手机是他自己的。
• ☐ 任何上传功能应该过滤用户上传的文件名，另外，为了普适性的原因（而不是安全问题），上传的东西应该存放到例如 S3 之类的云存储上面(用 lambda 处理)，而不是存储在自己的服务器，防止代码执行。
• ☐ 个人头像上传 功能应该过滤所有的 EXIF 标签，即便没有这个需求.
• ☐ 用户 ID 或者其他的 ID，应该使用 RFC compliant 的 UUID 而不是整数. 你可以从 github 找到你所用的语言的实现.
• ☐ JWT（JSON Web Token）很棒.当你需要构建一个 单页应用/API 时使用.

安卓和 iOS APP

• ☐ 支付网关的 盐（salt） 不应该被硬编码
• ☐ 来自第三方的 secret 和 auth token 不应该被硬编码
• ☐ 在服务器之间调用的 API 不应该在 app 里面调用
• ☐ 在安卓系统下，要小心评估所有申请的 权限
• ☐ 在 iOS 系统下，使用系统的钥匙串来存储敏感信息（权限 token、api key、 等等） __不要__ 把这类信息存储在用户配置里面
• ☐ 强烈推荐证书绑定（Certificate pinning）

安全头信息和配置

• ☐ 添加 CSP 头信息，减缓 XSS 和数据注入攻击. 这很重要.
• ☐ 添加 CSRF 头信息防止跨站请求伪造（CSRF）攻击.同时添加 SameSite 属性到 cookie 里面.
• ☐ 添加 HSTS 头信息防止 SSL stripping 攻击.
• ☐ 添加 你的域名到 HSTS 预加载列表
• ☐ 添加 X-Frame-Options 防止点击劫持.
• ☐ 添加 X-XSS-Protection 缓解 XSS 攻击.
• ☐ 更新 DNS 记录，增加 SPF 记录防止垃圾邮件和钓鱼攻击.
• ☐ 如果你的 Javascript 托管在第三方的 CDN 上面，需要添加 内部资源集成检查 。为了更加安全，添加require-sri-for CSP-directive 就不会加载到没有 SRI 的资源
• ☐ 使用随机的 CSRF token，业务逻辑 API 可以暴露为 POST 请求。不要把 CSRF token 通过 http 接口暴露出来，比如第一次请求更新的时候
• ☐ 在 get 请求参数里面，不要使用临界数据和 token。 暴露服务器日志的同时也会暴露用户数据

过滤输入

• ☐ 所有暴露给用户的参数输入都应该 过滤 防止 XSS 攻击.
• ☐ 使用参数化的查询防止 SQL 注入.
• ☐ 过滤所有具有功能性的用户输入，比如 CSV导入
• ☐ 过滤一些特殊的用户输入，例如将 robots.txt 作为用户名，而你刚好提供了 coolcorp.io/username 之类的 url 来提供用户信息访问页面。（此时变成 coolcorp.io/robots.txt，可能无法正常工作）
• ☐ 不要自己手动拼装 JSON 字符串，不管这个对象有多么小。请使用你所用的语言相应的库或者框架来编写
• ☐ 过滤 那些有点像 URL 的输入，防止 SSRF 攻击
• ☐ 在输出显示给用户之前，过滤输出信息

操作

• ☐ 如果你的业务很小或者你缺乏经验，可以评估一下使用 AWS 或者一个 PaaS 平台来运行代码
• ☐ 在云上使用正规的脚本创建虚拟机
• ☐ 检查所有机器没有必要开放的端口
• ☐ 检查数据库是否没有设置密码或者使用默认密码，特别是 MongoDB 和 Redis
• ☐ 使用 SSH 登录你的机器，不要使用密码，而是通过 SSH key 验证来登录
• ☐ 及时更新系统，防止出现 0day 漏洞，比如 Heartbleed、Shellshock 等
• ☐ 修改服务器配置，HTTPS 使用 TLS1.2，禁用其他的模式。(值得这么做)
• ☐ 不要在线上开启 DEBUG 模式，有些框架，DEBUG 模式会开启很多权限以及后门，或者是暴露一些敏感数据到错误栈信息里面
• ☐ 对坏人和 DDOS 攻击要有所准备，使用那些提供 DDOS 清洗的主机服务
• ☐ 监控你的系统，同时记录到日志里面 (例如使用 New Relic 或者其他 ).
• ☐ 如果是 2B 的业务，坚持顺从需求。如果使用 AWS S3,可以考虑使用 数据加密 功能. 如果使用 AWS EC2，考虑使用磁盘加密功能（现在系统启动盘也能加密了）

关于人

• ☐ 开一个邮件组（例如：security@coolcorp.io）和搜集页面，方便安全研究人员提交漏洞
• ☐ 取决于你的业务，限制用户数据库的访问
• ☐ 对报告 bug、漏洞的人有礼貌
• ☐ 把你的代码给那些有安全编码观念的同伴进行 review (More eyes)
• ☐ 被黑或者数据泄露时，检查数据访问前的日志，通知用户更改密码。你可能需要外部的机构来帮助审计
• ☐ 使用 Netflix Scumblr 及时了解你的组织（公司）在社交网络或者搜索引擎上的一些讨论信息，比如黑客攻击、漏洞等等

vulnerabilities stats zh

返回目录

Hackerone 公开漏洞统计

目前为止，Hackerone 平台已经发现 1731 个公开的漏洞，主要来自 Twitter、Uber、Dropbox、Github 等公司。其中 8 个已经删除，9 个来自互联网或者特定的语言，剩下的 1714 个中，有 1359 个我们可以通过代码或者人工的方式进行分类。

按照错误的类型划分

按照发生的频率排序

其中 1/3 的问题与 XSS、不安全的数据引用 (数据泄露) 或者忘记设置 CSRF token 有关，这个 页面 列举的这些问题非常有趣，值得一读.

类型|数量|占比 | --- | --- | --- | XSS|375|21.87 非安全引用 + 数据泄露|104|6.06 CSRF Token|99|5.77 开放重定向|59|3.44 信息/源代码泄露|57|3.32 DNS 配置错误 + Apache/Nginx + 子域名接管 + Open AWS_S3|44|2.56 不正确的 session 管理/固定|39|2.27 TLS/SSL/POODLE/Heartbleed|39|2.27 HTML/JS/XXE/内容注入|37|2.15 HTTP 头信息问题|34|1.98 空指针 + 段错误 + 在 free() 之后使用内存|33|1.92 DMARC/DKIM/邮件 SPF 设置|31|1.8 SQL 注入|28|1.63 点击劫持|27|1.57 不正确的 cookie 使用 (secure/httpOnly/暴露)|25|1.45 路径暴露|25|1.45 开放权限|24|1.4 暴力破解|24|1.4 内容欺诈|20|1.16 缓冲区溢出|20|1.16 拒绝服务|19|1.1 服务端请求伪造|18|1.05 Adobe Flash 漏洞|18|1.05 用户/信息 枚举|17|0.99 远程代码执行|15|0.87 密码重置 token 过期/尝试/其他|13|0.75 整型溢出|11|0.64 版本泄露|11|0.64 CSV 注入|10|0.58 权限放大|9|0.52 OAuth 状态/泄露和其他问题|9|0.52 密码策略|7|0.4 CRLF|7|0.4 python 语言|6|0.35 单向攻击|6|0.35 文件上传类型/大小/存储位置 过滤|6|0.35 Captcha|5|0.29 远程/本地 文件包含|4|0.23 目录列表|4|0.23 路径遍历|4|0.23 远程文件上传|4|0.23 （WEB表单）开启自动填充|4|0.23 通过引用泄露|3|0.17 Pixel Flood Attack|3|0.17 输入控制字符|2|0.11

一些特殊的漏洞类型

1. 竞态条件漏洞
2. Pixel Flood Attack
3. IDN Homograph Attack
4. 输入控制字符后输入一些有趣的东西