🤔极狐 GitLab 的 Securtiy Code Reviewer 是如何工作的？
近日，在极狐 TechTalk 直播上，极狐 (GitLab) 资深后端工程师曹宝栋 联合他的工作教训答复了这个问题，并通过极狐 GitLab 历史上的一些 Bug 和破绽修复教训，诠释了 Security Code Review 的作用和意义。
以下内容整顿自本次分享，你也能够👉点击这里观看视频回放。enjoy～
大家好！首先分享一下我在极狐 GitLab 的一些工作成绩数据：
- 在极狐 GitLab repo 下，奉献 MR 90+ 个；
- 参加 Code Review MR 200 + 个。
下图展现的是极狐 GitLab 成立至今，为 GitLab Inc. 所奉献的 MR 的数量：极狐 GitLab 团队所奉献的 MR 数量目前居寰球第二，仅次于 GitLab Inc. 团队；其中我集体奉献数量是 72 个，波及 5 个不同 repo，外围 repo 是 GitLab。
明天分享的内容也是从这些理论开发工作登程，向大家介绍作为极狐 GitLab 的 Securtiy Code Reviewer，我是如何工作的，并联合极狐 GitLab 历史上的一些 Bug 和破绽修复，来看一下 Securtiy Code Review 关注重点是哪些。
为什么要做 Security Code Review？
毋庸置疑，平安是很重要的话题，与研发相干的任何一个环节都有可能裸露平安危险。产品性能越丰盛，绝对应的平安危险面越大。
并且，随着越来越多的企业和团队都采纳麻利研发格调，习惯小步快跑，可能一天就公布好几次，每次迭代所对应的更新，都有可能引入 Bug 或者安全漏洞。
因而 Securtiy Code Review 的重要性显而易见。极狐 GitLab 作为一体化平安 DevOps 平台，将「平安」提到了高优先级，帮忙用户平安、高效地交付软件。从极狐 GitLab 的性能矩阵上也能够看进去，「平安」这一栏占据着十分重要的地位。
然而平安这个话题切实是太大了，明天咱们先偏重分享 如何在开发过程中，进步安全意识，尽量减少开发性能所裸露的安全隐患。
在极狐 GitLab 工作流中，提交的每个 MR 都须要通过 Code Review，进行代码格调或性能实现方面的评审。
当一个 Code Reviewer 提交了 Approve 之后：
1. 机器人会揭示 Security Code Reviewer 进行平安审查；
2. Security Code Reviewer 平安审查通过之后，才会交给 Maintainer 进行 Merge 评审；
3. Maintainer 实现最初的 Merge 评审，才进行合并。
也就是说一个 MR 通过至多三道评审才会合并，确保了代码品质与代码平安。
上面咱们通过一些实例回顾，看一下从这些安全事故身上，咱们能总结出什么经验教训。
实例一：明码泄露
说到研发安全事故，不得不提明码泄露，数据库数据被泄露曾经是十分重大的事变了，如果数据库中存储的用户明文明码被泄露，可能导致用户在其余平台上的账号也遭受危险，会给企业和用户造成很大的挫伤和损失。
这里有一个背景，即便产品平台有明码复杂度的门槛，但还是有很多用户习惯应用简略的、容易被猜到的明码组合，甚至在不同的平台上应用雷同的明码。
作为开发者，咱们很难扭转这样的事实，咱们能做的是最大水平升高一旦产生数据泄露所导致的损失。
首先，咱们来看看，验证明码的原理。
用户登录零碎时，其实开发者不须要晓得用户设置的原始明码的明文是什么，只须要晓得在登录过程中，输出的明码与设置的明码是否统一。很天然的，咱们就想到了应用 摘要算法，摘要算法特点是不可逆的，即只能从数据计算到摘要，不能从摘要反推回数据自身。
用户输出明码后，把明码摘要哈希值存到数据库，下次认证时，应用雷同的算法再算一次，比拟两次哈希值是否统一，就能判断输出的明码是否正确了。
最常见的比方 MD5 这样的算法，对于雷同的字符串它总是能失去雷同的摘要值，它的长处是很稳固，性能很好，算得很快。但对于存储明码这样的具体场景来说，反而成了一个致命毛病，因为黑客能够用很小的老本，提前准备好字符串到摘要的映射。
除了 MD5，理论生产中还可能会用到其余算法，黑客须要先探测一下零碎应用的是哪一种算法。罕用的其实也不过几种，做一下取样就能够轻易探测出所应用的算法，或者说曾经能读到代码源码了，那么黑客就能够间接去代码里查看所应用的算法。下一步黑客就能够依据曾经晓得的算法，筹备相应的明文到哈希值的映射关系，这也就是咱们俗称的彩虹表。
为了应答事后筹备好的彩虹表，咱们须要给明码做一些解决，比方在用户输出的明码的根底上做一些拼接，再去做摘要算法，这也就是「明码加盐」，加盐的值个别是硬编码或者保留在环境变量里，如果这个值也被泄露了，黑客也很容易依据盐的值从新再生成一份彩虹表。
于是，咱们就想是不是应该给每一个用户调配不一样的盐值，这样就会大大提高黑客的破解老本，因为他须要给每个用户都从新生成一份新的彩虹表，这是十分消耗工夫和存储空间的。
前文说到了 MD5，或者相似的摘要算法都有很高的效率，这是一个算法自身的长处，然而咱们并不心愿黑客在破解的过程中也算这么快，如果能进步每次计算的计算成本，那么就会让黑客破解的总成本变得十分大。
综合以上所述，Bcrypt 就是一个十分适合的算法。
它由这 4 个局部形成：
1. 算法，它有很多备选的算法能够选，对于每一个明码来说，有可能算法取样都是不一样的，黑客进行破解的时候，要对每一个明码进行算法探测；
2. 计算成本，如图中“12”这个值对应的是计算成本，值越大，对于单个哈希计算的老本也就越大；
3. 盐，每个用户的盐都是不一样的；
4. 所对应的哈希值。
对于 Security Code Reviewer 来说，肯定要做好算法抉择，以及登录或者注册逻辑上的把关。除此之外，还须要一系列辅助性能的配合，比方：
1. 两步验证；
2. reCAPTCHA；
3. 对用户或 IP 的频率限度，包含如果发现账号在新的 IP 尝试登录，也会收回邮件告警等。
这些性能在极狐 GitLab 都是反对的。
上图是一个黑客发的帖，号称要卖一个 billion 的数据，据说这个数据的起源是因为一位程序员在某平台上分享了本人的一个代码片段，这个代码片段蕴含了连贯数据库所应用的 token，因而造成泄露。具体导致泄露的根本原因已无从考据，然而这个行为自身的确是十分危险的，而且的确有很多案例是因为 token 提交到了 Git 仓库中进而造成了微小的损失。
因而，Code Review 时须要特地留神这样的问题，但其实这是一个十分好辨认的景象，而且 极狐 GitLab 反对对 Git 仓库进行扫描，一旦发现有泄露的危险，就会给出提醒，下图就是具体例子：提醒到在 yml 中，Elasticsearch 的 URL 可能会暴露出危险。
这样的提醒对咱们来说十分具备警示作用。如果咱们能明确晓得它不具备平安危险，能够在这个页面中把它勾销，那么下一次就不会再次报警。
这背地的实现原理是通过 Gitleaks 这样的工具进行 SAST 扫描，扫描 Git 仓库里有平安危险的局部，比方 Passwords、API keys、或者 Tokens 等。它的应用办法非常简单：在极狐 GitLab CI 的 yml 外面，include 该模板，后续的流水线就能够主动应用这个性能。
实例二：SQL Injection
SQL 注入是 Reviewer 要特地关注的点，也是非常容易产生危险的点。
上图是一个简略例子，比方 ID 是 10，如果咱们去查问 ID 为 10 的 user，并且是本人手写的查问条件，会失去这样的 SQL，并失去相应的用户，这是现实状况。
然而如果咱们真的这样写查问的话，黑客就很容易把 ID 局部进行扩大，而后提前敞开判断，这样就会造成 SQL 注入问题。原本只想查一个用户，然而通过这样的组装，能够查出一系列的用户，更可怕的是在测验权限的中央，如果黑客这样毁坏了，就能够绕过你的权限判断，这是十分危险的。
上图中，比拟危险的写法是在 where 外面，本人拼 condition 条件，或者间接应用 execute 办法执行裸 SQL 查问，或者 find_by_sql 这样的裸查问都十分危险。
正确的做法是尽量应用 Prepared SQL Statement，并且在简单数据的时候进行数据校验。
当然，极狐 GitLab 也是有相应的工具反对—— SAST 工具，会报出相应的危险正告，比方下图，对于非凡的场景来说，的确须要手写一些 SQL 拼进去，组装成一个非凡的查问条件。这样尽管会被报警进去，但如果你能明确晓得它是平安的，能够手动把它解决掉。
对于 SAST 剖析工具，极狐 GitLab 有一系列反对，并且还在一直增加中，根本反对支流语言和框架。
实例三：CRLF Injection
还是以 Ruby 代码为例，如果咱们的 Message 是一个字符串，咱们想把这个字符串打印一下，如下图，它是一个失常的 Warning 输入，看起来如同没什么问题。
如果黑客想把报警信息覆盖掉，并且输入一个 Success 信息，他能够像上面这样本人手动拼接一个换行符进去，那么在 log 中就会多一行 Success 信息，这对个别 log 来说可能没什么太大影响，然而对于须要对账的零碎来说，就有可能导致对账出问题。
上面咱们来看一个更危险的 CRLF 注入。这是一段 HTTP 协定。重点看一下空行，它分隔了 Header 和 Content，这里大家能够联合后面的例子，猜一下，黑客有什么方法来篡改？
是的，黑客能够借助 cookie 字段，提前让 Header 局部完结，再本人伪造一些新的 body 内容。
解决这个问题的方法其实很简略，如上图标绿地位，只须要把非凡状况解决一下就好了，极狐 GitLab 须要做的就是降级到 PUMA 新版本。
实例四：上传文件带来的平安问题
下图是一个简化的极狐 GitLab 架构图。从下往上顺次是：
- 底层：存储，包含数据库，Redis；
- 中间层：从左到右是 Sidekiq，它是一个解决异步工作的工具；两头 PUMA 是 Web Server；左边 Gitaly 是由 Golang 编写的解决 Git 申请的中间件；
- 下层：GitLab Pages，是一项独立服务用来解决解决 Pages 页面服务的；GitLab Workhorse 是破绽的关键点，它是一个反向代理，或者说智能代理，它所做的事件就是进行分流，把大型申请比方文件解决、Git 申请等本人来解决，把动静申请交给 Rails 来解决，也就是中间层中的 PUMA 来解决。
那么，如果上传大文件会对极狐 GitLab Workhorse 造成什么影响？
在 GitLab 的某一个老版本中会呈现这样的景象：如果上传一个特地大的单个文件，它会让 Workhorse 的内存爆掉，导致整个 Workhorse 节点无奈工作，这样，用户的所有 HTTP 申请都会被回绝拜访，造成整个节点不可用。
解决办法也是非常简单，就是辨认出这样的异样文件，而后疏忽它，并且给用户相应提醒，如下图，从 CVE 的形容中，咱们能够看到更多的细节，感兴趣的同学也能够点击👉查看链接详情。
实例五：Workhorse RCE 破绽
另外一个与 workhorse 相干的问题，是一个 RCE 问题，全称是近程代码执行 (Remote Code Execution)。
这个问题十分有意思，首先先介绍一下背景，有一个工具 ExifTool，它是开源的，用来解决多媒体文件的 meta 信息，它反对的文件十分多，包含支流的图片、视频、音频，PDF 等。其中还有一种比拟少见的文件格式叫 DjVu，这是用来做简单文本排版的一种文件格式。
下面左侧是一个 DjVu 的 meta 信息，右侧是黑客构建进去的一种非凡的 DjVu 的 meta 信息。即便你不晓得他到底是怎么解析 meta 信息的，看起来也十分危险，如同是能执行起来，实际上的确是这样。
在上传图片时，Workhouse 会把所有图片都先做一次平安过滤，如果文件的 tag 不在白名单里，它就会把 tag 给移除掉，这个过程是通过 ExifTool 工具实现。
在 ExifTool 处理过程中，会疏忽掉文件自身 .jpg/.png 这样的后缀 ，因为这个值用户能够随便批改，所以 ExifTool 不看这个， 它是通过文件自身的实在内容去辨认文件类型，从而再进行下一步解决。
在这个过程中，ExifTool 会把所有反对的文件格式全都做一次辨认，包含上文介绍的 DjVu 格局。如果黑客结构出这样有问题的格局，能够达到一个十分危险的目标，就是把他所想要执行的命令埋在一个文件里，让这个文件去到 Server 机器上创立出一个文件，再执行起来。
上图展现的是 ExifTool 这个工具如何批改 Bug。
极狐 GitLab 做法是在解决有问题的格局之前，先做一次文件格式的查看，如果查看出有危险，就把它过滤掉。更多的细节咱们能够👉通过这个链接去查看。
实例六：XSS 破绽
XSS 破绽是一种更宽泛的破绽。下图展现的是通过对 Milestone title 非凡构建，构建进去保留之后，如果新的用户也过去查看页面，就会产生 XSS 攻打。
具体的攻打细节，能够在相应的 文档 和 Issue 里看到残缺复现。
针对 XSS 攻打，这可能是最常见的攻击方式，所以也是须要 Security Code Reviewer 重点关注。每个框架的应答形式可能有所区别，但思路是统一的：过滤有危险的组合。
还有一种状况是服务器端的申请伪造，咱们能够通过下图这个例子来看，图例右边是内网，左边是公网。
假如咱们在内网中有多种不同的服务，个别会假如内网的服务之间互相申请都是比拟平安的，如果用户拜访的申请就是结构一个假的内网的申请的话，这样的爱护机制很容易被骗过，让一台 Web Server 作为跳板来拜访 Admin 的一些申请，这样就会造成相应的权限治理破绽。
这也就是为什么极狐 GitLab 默认的配置下是不容许拜访 Localhost 的，可能大家也会在配置中遇到这样的状况，这是一种保护措施。
须要留神的就是在构建 HTTP 申请的时候，也是应用极狐 GitLab 曾经录制好的类库，GitLab::HTTP 或者 Gitlab::UrlBlocker，这外面包装了很多很多现成的办法能够方便使用。
总结
Security Code Reviewer 须要常常模仿黑客攻击，想一下黑客罕用的攻打伎俩是什么？咱们是不是曾经思考到了这些支流的形式？
总的来说，就是 不要把代码和数据混在一起，这尽管是一种灵便编程策略，然而对于咱们业务的开发而言，是十分危险的。特地是如果容许用户输出数据的话，会向黑客裸露更宽泛的攻击面，晋升保护的老本。
另外，不要信赖任何外来数据，对于外来数据都要做有罪假设 ，假如所接管的所有内部数据都可能蕴含安全隐患。 尽量提供最小的攻击面，能力尽可能减少危险。
还有，良好的测试笼罩能够帮忙进步代码品质。对于有危险的 Case，要无意识的写测试来笼罩，防止反复的回归。
以上咱们通过回顾极狐 GitLab 的破绽剖析，用 6 个实在案例给大家诠释了 Security Code Review 的作用和意义，心愿对大家有帮忙。