2019年的一部分总结-安全小百科

2020过去了近一个月，今年过年不回家了，虽然和疫情没关系，但是正好可以借此机会躲避一下。呆在北京也没啥别的事，想想去年一年都做了些什么。

XRay

去年一年忙的最多的当然是工作，去年应该说大部分的时间都在做XRay吧。最初做XRay的想法只是想把洞鉴里的一些有趣的功能拿出来自己用，能闲来无事时挖挖SRC，为此我最初用Mitmproxy写了一个简单的Demo，并用这个Demo挖到过一些漏洞：

架构非常简单，因为Mitmproxy支持自定义Addons，只需要编写好一个个的Addon，即可作为被动式扫描器使用了。

但我后来被@koalr说服了，Python并不适合做一个扫描器，主要原因有三点：

性能瓶颈
复杂的并发问题
弱类型导致代码的可靠性下降

这几点问题其实在博客里的XRay旅行记 – 从内部项目到社区项目的蜕变这个PPT里就说过了。后来我们选择用Golang做开发，并逐渐将公司的项目也用新的Go版XRay重写了，后面的实际情况也证明这个选择是无比正确的。

当然，其实XRay的整体架构大部分都是@koalr和@virusdefender做的，包括HTTP代理、HTTP请求基础库、证书认证、反连平台等等。我做的工作更多和安全相关，主要是XRay里的一些安全检测模块，比如XSS、POC框架、敏感目录和文件扫描等等，其实只占整个项目的一小部分。

这些安全插件是大家最容易看到的部分，但离开底层架构他们都将失去意义，这也是我自己曾经多次想做一个完整的扫描器项目然而都折戟的原因，底层架构上的问题会比简单的安全扫描插件要多得多，特别是企业级的项目。

幸运的是，我们有一个团队去做这件事，而且我们曾经在Python版中遇到过相当多的问题，积累了很多经验。

XRay社区版技术上无疑是一个成功的项目，最早我们的初心之一就是想多挖点漏洞赚点钱，但最后我们自己其实并没有很多时间去用它，反而是社区里很多白帽子通过XRay收获了大量的奖金，当然这样收获的成就感不亚于自己闷声发大财。

关于XRay，我个人接下来非常想做一件事情，就是努力推广POC格式，希望把它做成一个统一的POC标准，希望能成为类似于NASL的语言。如果本文的读者还不熟悉XRay的POC，可以看看这篇文章https://xray.cool/xray/

安全研究团队

2019年末的一段时间，我开始组建一支团队，说安全研究也不是那么准确，但我们暂且可以称之为安全研究团队。

大部分人对安全研究的认识应该还是在漏洞挖掘上，安全和漏洞是不分家的，再一个，很多公司的安全研究也免不了接触一些安服的工作，最后变成高级安服，普通安服完成不了的工作让高级安服来做。不过，我们作为产品研发部门的安全研究团队，究竟有什么不同呢？

所以我有时候也不好意思自称安全研究了，我们大部分的时间并没有研究到能与我司真正的安全研究部门研究的议题相比较的程度。我们做的事情主要和产品有关，我们的目标是让我们公司所有的产品安全能力变得更强。

“安全能力”的边界一直是很模糊的，什么东西是安全能力？比如一个流量检测引擎，他可以用来检测用户是否注入了SQL语句，也可以用来检测社区用户是否说了什么违规言论，是否有发表色情图片。前者是安全能力，后者是否是安全能力？这两个算法究竟有多少区别，会是同一个部门来负责这两个外人看起来完全不相关的引擎吗？侠义上来看，通常安全部门是不会来负责后者工作的，但如果后者的架构与算法也能很快移植到前者来，那么安全的边界究竟是什么？

值得深思。

公司被阿里巴巴收购以后，对于我来说其实没什么太大区别，没有所谓的一夜暴富，当然也还没有迎来福报。不过带团队以后确实会忙一些，需要经常思考一些非技术上的问题，努力把技术上的自由交给团队里其他同学。

总的来说，任重而道远，需要不断努力。

『代码审计』知识星球

从2016年开始决心建立这个星球开始，这已经成我生活里的一部分，就像朋友圈一样，只不过是一个面向安全圈的朋友圈。

2019年我开始建立星球自己的官网，打通整个用户体系。其实2019年以前就已经有这个网站了，只不过当时未对外公开，只是一个备份自己的知识星球的一个小工具，最初的原因是知识星球曾有过好几次整改的经历，我不得不为自己的东西做一个保存，以免再次重演乌云的悲剧。

随着这个工具的不断成熟，我觉得我可以把它公开给圈子内的用户使用了。但如果想打通用户体系，你一定避免不了几个问题：

内容的同步
用户的同步
额外的资源

内容的同步我在做备份工具的时候就已经做完了，几年下来效果非常不错，所有的内容基本都能下载下来，而且个人觉得使用起来比星球官方更加方便（就网页版来说）。

用户的同步其实是一个大难题，因为知识星球官方没有提供任何API，我们无法直接走正常的途径来验证一个用户是否是圈子内的用户。所以不得不想一些新的方法：

人工认证，这个显然是不科学的，圈子里已经有2000多个用户，工作量是不能承受的
通过昵称认证再人工审核。这个方法是可行的，不过因为昵称是对所有人公开的，所以审核标准是什么？另外审核其实也是占用人力的，没必要给自己找麻烦。
通过机器自动认证。

我最终当然选择了第三个方法，但这样就需要研究出一种方法：用户可以在星球内的途径找到机器人，且其他人无法看到这个过程。

最早自然会想到星球内的私信，但研究了一圈发现私信的API藏的太深，可能是为了防止垃圾信息吧，所以后面我另辟蹊径选择用“提问”的方式来解决这个点：用户可以给机器人提问，在机器人不回复这个问题的情况下，其他用户无法看到这个提问。这其实就解决了我们的所有需求，而且提问的API非常好拿。

通过提问，我将官网和知识星球的用户绑定在一块，已加入星球的同学就可以直接登录官网。

打通了用户体系，我们可做的事情就非常多了，之后所有的内容都可以成为星球成员的福利，也就是额外资源。暂时看起来额外资源还不太多，但之后的发展是充满无限想象的。

另外，前几页星球官方也给我推送的2019年的年终总结和周总结，对于数据我是比较满意的，希望2020年能更上一层楼：

Vulhub

Vulhub也是个人对外能力输出的一部分，这一部分主要输出在开源社区。

这应该是我维护最久的一个开源项目，从2017年开始到今天也经历了1019天，1300个commit，5300多个Star，150个漏洞环境，26个来自国内外的贡献者。

去年初，Offensive-Security（Kali和OSCP的母公司）的CEO找到我说我们可以一起合作一点东西，原因是他们找到Vulhub，觉得这是一个不错的项目。

这也让我开始认为Vulhub已经影响外国人了，越来越多来自世界的人开始为Vulhub提交Issue和PR，这也间接让我更坚定于全球化Vulhub的内容（最早开始帮助我们翻译Vulhub的是一个来自美国的小姐姐）。虽然这一条路其实不太好走，但不得不承认这样是有意义的。

去年下半年其实对Vulhub的贡献减少了许多，因为工作上占用了大部分时间，而且与offsec的合作也和Vulhub项目的内容类似，间接也导致Vulhub更新的环境变少。但其实主要原因还是自己拖延症很严重，有时候目标是什么，就越不想做什么，假设这时候目标突然变成别的了，我可能反而又会来做这个。不知道是不是心理疾病。

好在，一直还有社区的小伙伴关心这个项目，也经常会有人来提交PR，这让Vulhub一直没有断更超过一个月。2020年立一个小flag吧：完成所有环境的英文文档。