创业碎碎念之安全
道理千万条，完全第一条，行车不规范，亲人两行泪。 来自于「流浪地球」中的一句台词，在电影中反复出现。
对于创业者来说，安全也是非常重要的。 服务不安全，老板两行泪。创业几年以来，亲历过大大小小的安全问题还不少。 现在还记得在乌云网站上有很多白帽子的给我们提了一些安全漏洞（乌云这个网站已经不可访问），有一个白帽子朋友当时差点来入职公司。
简单回顾下之前碰到的一些问题，并给出一些建议。
sql 注入问题
sql 注入问题是在创业初期经常碰到的问题。之前都是在大公司工作，没有涉及从 0 到 1 的整个技术架构过程，所以对安全方面的设计重视度不够。更多的是考虑是并发性，可扩展性等等。
sql 注入主要是 string 类型的字段内容没有进行编码，直接传入 sql 语句中，sql 语句可以直接对数据库进行操作。 數據庫被拖庫很多时候就是因为 sql 注入导致。
建议方案： sql 语句都使用参数化查询（推荐）或对参数进行 escape（不推荐）。 如果因为历史原因使用拼接的 sql, 对 string 类型的内容进行一次 escape 处理。不要相信用户输入的内容。 可以使用 sqlmap 扫一下接口；
xss 攻击
xss 是指恶意攻击者往 Web 页面里插入恶意脚本代码，而程序对于用户输入内容未过滤，当用户浏览该页之时，嵌入其中 Web 里面的脚本代码会被执行，从而达到恶意攻击用户的特殊目的。
创业初期，也出现过好几次 xss 攻击。比如跳转到黄色网站...... 用户在 app 上发帖，然后分享到微信的朋友圈或者群里。 用户在微信中访问的时候，先是访问公司的域名，然后跳转到第三方网站，展现恶意的内容。 因为这个漏洞，我们的域名被微信封过好几回......
建议方案：不要轻易详细用户输入的内容，用户提供的内容都要进行一次编码。
上传漏洞
之前还碰到另外一种攻击，不是篡改 web 页面内容，而是直接篡改页面中的文件内容，app 客户端上可以发帖上传图片，但客户端和服务器都没有限制只能上传图片，有些用户上传了 js 文件，当户访问的时候，直接执行 js 文件中的内容，跳转到第三方网站。
建议方案：不要相信客户端的验证逻辑，服务器端验证上传文件的类型；
密码太简单
记得 2015 年的时候，有人在 wooyun 上提交了一个漏洞，是我们的内部系统有漏洞，别人可以直接登录看到公司的核心数据。
因为刚开始的时候用户的不是很多，对方很快找到我们内部员工的 id，然后用一些很简单的密码暴力尝试，就试出来密码是 123456.
建议方案：核心系统的密码一定强制复杂。必须包含同时包含数字，大小写字母且 6 位以上。
劫持
记得 2015，2016 年的时候很疯狂，经常看到 web 页面被篡改，页面上出现一个小圆球，或者出现 banner，非常影响到用户体验。最近几年域名劫持的情况有很大的改善。
比较系统的解决方案是 http 转成 https, 页面被篡改的难度大幅度提升。目前我们的 web 页面基本上改造为 https.
从 http 迁移到 https，整个过程没有想像中的困难。对用户体验并没有损失，对服务器的资源占用也没有太大的变化。 这几年 https 也已经成为了标配。
建议方案：使用 https, 有条件的话，使用 httpdns. dns 都可能劫持。
接口防刷问题
最近几天就出现接口被刷的问题，之前没有做一套系统性的防刷方案，近期会完善架构。
主要的表征是短时间内，有限的 ip 非常频繁的枚举暴力请求。 近期就出现一例，黑客拿着上亿个手机号通过接口来查询手机号是否注册？ 如果查到有注册，用已注册的手机号和一套简单的密码本枚举暴力请求，破解用户的手机号。由于问题发现的比较及时，被暴力破解的用户数很少。
建议方案：接口防刷，主要是 ip+ 频率的方式来打击。 https 请求中 ip 地址很难篡改， 伪造成本高。
服务器密码管理问题
创业初期，只有几台服务器的时候，不存在管理的问题。大家想要访问服务器，都是把密码复制粘贴的方式发给同事。后面觉得麻烦，没法备案，每次想要访问某台机器，改成需要邮件申请密码。创业初期，人员比较少。人多的时候，不可避免就有人员流动的时候，这种做法就非常麻烦。 需要把所有的机器改一遍密码，然后一遍遍通知到在职的同事。非常低效且不安全。
后续就使用开源的代码搭部署一台跳板机器，跳板机服务有比较完善的管理功能，不需要提供所有服务器的密码，在跳板机器上创建一个帐号和密码，并分配给新同事，离职之后把帐号回收就可以。
有了跳板机器之后，所有的机器一定必须从跳板机器登录。每一台机器的 ssh 登录只认准固定的几个内网 ip 地址。其他 ip 地址的 ssh 登录全部被拒绝。
我们采用的跳板机器开源项目，还有个问题，跳板机器本身成为单点，一旦跳板机器被攻破，所有的机器都面临危险。所以，跳板机器的安全级别就需要非常高，我们直接在开源项目上做了一些二次开发，加入二重验证。每次登录跳板机器，还需要输入一个验证码，验证码通过手机号 / 工作邮箱发送。
建议方案：引入多重验证的跳板机机制。
%% ### 签名泄漏问题
%%
%% 一旦签名被泄漏，非常被动。尤其是客户端已经发出去。不像服务器，一次更新，可以很快全量更新。
%%
%% 建议方案：签名动态配置；不能完全依赖签名，每个用户要有独立的密钥； 请求 https 加密，无法抓包；
服务器防火墙
不应该暴露的端口尽量不要去暴露。
之前出现过 mongdb 的漏洞，导致 mongdb 中的数据被控制，需要付费才能拿回来。幸好当时我们 mongdb 中的数据都是一些不重要的服务配置信息，通过重装解决问题。
建议方案：防火墙打开。只暴露该暴露的端口；
服务器木马植入
前一段时间， 我们有台机器经常出现 cpu 高的告警，登录之后发现有个 watchbog 程序在运行（网上搜索，很多中标，应该是挖矿的程序）。这个非法程序是通过什么途径部署在服务器，一直没有查到。我们把相关的文件清理之后，恢复正常，过了一段时间又复发。
针对这种情况，建议不要去定位问题。 直接把服务器退掉，新买一台机器，或者重装系统。已经脏了的系统，你不知道黑客预埋多少文件在服务器中。最快最彻底的解决方案就是重装系统。
建议方案：「脏」系统，重装。不要尝试修复， 根据墨菲定律，一旦出现问题，后续还是可能继续出问题。
如果我重新创业
如果我重新创业，在安全这一块，应该会考虑更周全。
- https 是标配；
- 不要自己部署机房，直接使用云服务器，云服务器有非常完善的安全服务；
- 架构设计一定要优先考虑安全相关；尤其涉及到 app 相关客户端，出问题非常被动；
- 跳板机器尽早使用起来；
- 密码要复杂，要定期更换；
- 核心系统的密码必须是复杂的；（涉及公司的核心数据）
- 边际成本几乎为 0，暴力破解是个非常低成本的攻击手段；要有一套完善的异常监控系统；
- 涉及到用户核心数据，不要明文存储，比如密码，手机号等等；
- 客户端不可信，客户端不可信，客户端不可信；
- 只暴露该暴露的端口， 比如数据库只有内网才能访问；
- 涉及到写数据库相关操作的接口，一定要检验身份，是否本人？是否有权限？写脏数据是无法回滚；
- 核心数据，比如支付等，一定要有备份；
- 文件名称最好不要用自增长的数字，而是类似于 32 位的随机字符串；规则太简单，很容易一个 for 循环就把所有资源爬取走；
以上提到的几点，是作为创业团队的同事在平时工作中可以多加关注的点。涉及到 ddos, 渗透，入侵，等各种更高阶的安全相关的攻击，建议还是付费接入专业的服务和专业的团队。
没有绝对的安全，道高一尺魔高一丈，任何的安全策略都是为了增加攻击者的成本，在安全这条路上，需要持续的投入，持续的关注。对于一个创业公司来说，在安全方面的投入都会有限，比如我们团队一直都没有专职的运维人员，一直是开发同事在兼着。创业最大的特点是资源受限。资源受限，但不能忽视安全。
安全是典型的木桶定律，其他方面做得再好，安全存在很大的隐患，直接导致前功尽弃。
