自己动手打造Github代码泄露监控工具之改进篇

0×00 为什么

自从小弟上次发布了《自己动手打造Github代码泄露监控工具》（https://www.freebuf.com/articles/web/173479.html）一文后，承蒙各位客官老爷捧场，阅读量已经好几十万了，Github也受到了一些大佬的关注。本着精益求精的黑客精神（其实是上次的工具版本存在许多不足)，经过一段时间的运行后，确实工具存在一定精确性的问题，故有此文章。

0×01 怎么改进

改进主要从以下几个方面入手：

1.搜索排序方式变更

上篇文章通过Github搜索排序Best Match来爬去前面6页来查找泄露信息，优点在于：可以匹配到最符合关键词的项目，比如匹配域名为baidu.com的相关代码。然后在最匹配的关键词中寻找payload,如password，username等；缺点较为明显：主关键词单一，虽然可以加入多个主关键词，但是匹配结果却不能收录最新的记录或代码。最为严重的问题是最新泄露的符合关键词的敏感信息可能无法获取到。

2.搜索方式变更

单一的域名关键词搜索内容有限，Github呈现的结果也非常多。另外Github的内部搜索算法的影响也会让搜索结果不尽人意。举个栗子，搜索baidu.com, Github呈现如下图：

看图可知，最匹配的代码结果其实可能没有包含我们想要的诸如password, username, database等敏感信息。有兴趣的童鞋可以自行搜索。细心的童鞋可能看到收录的时间五花八门，有6月29的，7月6号的等等。现在是11月了啊，这结果根本不是最新的，不准确性和非及时性的问题体现出来了。即便是搜索到几十页，上百页，也可能没有包含我们关注的信息泄露代码，所以必须改进。

3.存储方式和呈现效果变更

此前Github仓库的链接爬去后都通过excel来存储，Python处理这种IO还算性能不差。不过用excel来存储信息确实略显陈旧，新版本则采用sqlite来存储url和代码，这是存储方式的变更。另外在呈现效果虽然还是通过邮件来呈现，但是加入了代码部分的展现，关键词高亮显示，方便监控者阅读。具体效果如下：

接下来我们将针对提出的改进要点来修改监控工具~_~

0×02 具体改进方法

1.搜索排序方式改进

这个要点的变更，其实变更代码比较少，只是变更搜索代码的url即可：

通过变更排序方式，把最新收录的排在前面，这样就可以得到最新的代码收录信息。

对比先前版本url:

2.搜索方式改进

搜索方式由单一关键词更改为关键词组合，例如，公司域名为：“example.com, 需要查找的敏感关键词为：password，那么我们组合为：“example.com + password” 进行搜索。新的改进版本不仅会收录可能存在代码泄露仓库的url，同时也会收录简要代码部分。然后在后续加入到邮件报警和数据库的代码中进行example 和 password进行匹配，如果两个关键词都存在，则再比对数据库中的基线里面是否存在对应代码的url，如果存在则不加入基线中，反之，加入到基线中。我来看代码部分：

正如代码中的注释所讲，获取泄露地址的url还是采用xpath的解析。然而在泄露的代码部分，使用的是正则。

为什么使用正则，第一，为了把包含泄露代码的table获取下来以便发送邮件（发送邮件时只需要简单加入css样式即可）；第二，这样避免利用xpath去解析table下的行，这样做稍显麻烦。

其实在考虑这部分逻辑的时候遇到一个坑，那就是有些可能存在泄漏的仓库，有url，却没有代码部分，没有代码部分就不会存在’

’ 这个div，这样获取的url和代码就不能一一对应，会发现url和代码错位了，根本就不准确。所以要先获取 ‘

‘ 的父div即’

’，然后判断是否存在代码部分，如果不存在则泄露代码的列表当前位置为空或空格，存在则搜索代码泄露部分加入到列表中。这样避免了有url没有code的问题。

同时，在加入泄露代码的列表时，通过正则匹配进行css的替换把获取的table标签中的标签替换为。这样以后发送的邮件正文中关键词则被标红。

最后在异常处理部分加入了出现异常就写入文件，并且把trackback一并写入文件，以后排查错误时可以更准确方便。

3.存储方式和呈现方式改进

存储方式变更为数据库存储采用sqlite3，简单易用，小型存储需求可以满足。创建了Baseline表,包含url和code两个字段。如图所示：

此数据库主要用于对比去重，基线建立，如数据库中不存在泄露的url则加入其中，然后通过邮件发预警。反之则不发送邮件预警。代码如下：

0×03 预警逻辑和基线建立

预警逻辑和基线建立代码都放在了主函数中，读取配置文件与之前Github信息泄露监控工具无异。而在关键词和payload读取时则进行了改动，搜索关键词由原来的单一，变为组合型关键词，即keyword + payload。搜索代码中存在的关键词和payload又将两者拆分，这样就保证了监控者关注的关键词和payload 100%存在于Github新收录的条目中，关键代码如下：

首先进行数据库文件查找，如果是首次运行，那么会在程序目录下生成一个db文件，名称为hunter。然后进行keyword和payload查找，当keyword和payload都存在于爬下来的泄露代码中，那么则加入到target_codes中用于邮件预警，最后进行数据库写入操作创建基线；如果数据库存在则说明基线存在，那么则进行新增数据查找。同理，当keyword和payload存在泄漏代码中，并且还必须满足获取的泄露地址url不存在于数据库Baseline表中则加入到target_codes，最后写入表中。在加入target_codes时还写入了换行符，css样式等，具体可参考上面代码。程序最后发送预警邮件，如target_codes有数据，那么进行预警。如果不存在数据则进行通知。

0×04 效果呈现

具体效果如下图所示：

图中被抹去的是关键词，keyword和payload都以红色显示。根据自己需求进行修改即可。

0×05 总结

所谓人无完人，程序也是一样，只有通过不断改进，才能达到近乎完美得到自己想要的效果。我觉得最重要的是改进的过程，在这个过程会遇到各种问题，各种难题，我们要做的是去一个个克服，不能半途而废。只有这样才能不断的提升自己，提高自己的各项技能水平。安全之路还长，吾将上下而求索！谢谢各位客官老爷耐心读完！最新完整代码还是那个地址：

https://github.com/Hell0W0rld0/Github-Hunter

自己动手打造系列下期预告：自己动手打造自动化安全扫描平台

*本文作者：ztencmcp，转载请注明来自FreeBuf.COM