在做缝隙众测的时分，缝隙的界说其实是十分广泛的，就看你怎样来看待它了，所以当方针项目相关的某项新功用新特点出现时，你能够细心研讨，结合实践进行一些安全剖析。本文中，作者就针对GitHub Repository Wiki Pages页面做了一次相似的归纳剖析，归纳形成了缝隙危险进行了上报。
GitHub Repository Wiki Pages介绍
按照 Wiki 的界说，它是一种能够多人一起修正的网页，每个人都能够在上面恣意的修正页面数据，像百度百科和 *** 相同。GitHub也有Wiki页面？是的。
GitHub 用户创立每一个项目都有一个独立完好的 Wiki 页面，咱们能够用它来完成项目信息办理，为项目供给愈加完善的文档。咱们能够把 Wiki 作为项目文档的一个重要组成部分，将冗长、详细的文档整理成 Wiki，将精简概述性的内容，放到项目中或是 README.md 里。
GitHub 的 Wiki 页面在如图所示选项卡下，默许应该是敞开的，并且新建时是空的，咱们能够点击中心那个绿色的 Create the first page 按钮创立一个页面。

安全危险
从GitHub Wiki页面的上述描述中，咱们能够发现问题所在：只需具有Github账户的人，都能够对那些敞开Wiki页面的项目，进行Wiki 页面的恣意创立修正。如下：

现实是，一些大公司的开发人员或工程师们或许底子不会介意这个默许设置，那么，这些大公司项目的Wiki页面就能被恣意Github用户进行恣意修正修正了，不是吗？这难道不是一个安全问题吗？当然是……。比方以下顺手搜的一些敞开Wiki页面的Github项目：
https://github.com/phachon/mm-wiki/wiki
https://github.com/gollum/gollum/wiki
https://github.com/g0v/dev/wiki
https://github.com/ndunning/testing123/wiki/
还有一些原因是，假如一些工程师们把某个项目从私有状况转为揭露状况，可是这种情况下，本来应该制止的Wiki页面依然处于敞开形式，那么，不仅仅是项目合作者或内部公司人员能够修正Wiki页面了，连任何Github用户都能够具有这样的操作权限。值得留意的是，项目一切者底子不会知道Wiki页面的任何修正操作，由于Github自身就没有这样的告诉或奉告装备。
缝隙影响
这种安全危险的影响十分直观，能够总结为：
1、恣意Github用户，能够对敞开Wiki页面的项目，进行Wiki页面的恣意修正；
2、歹意进犯者能够在这些可修正的Wiki页面顶用markdown办法嵌入超链接、图片或其它内容；
3、这样很简单履行某些社工进犯，利诱特定用户去装置某些歹意代码库，或是导航至进犯者操控的 *** 资源中去。
4、这种行为还能够导致某种程度上的声誉受损，歹意进犯者能够在Wiki页面中刺进与公司规则不和谐的一些内容。
缓解办法
关于一些大公司来说，他们在Github上布置有许多项目，形似Github上没有能一键办理设置Wiki页面的功用，所以，只要经过勾选Github设置中的”Restrict editing to collaborators only”（仅限项目合作者进行修正），来进行约束了。（权限设置可参阅： Changing access permissions for wikis）

其它办法还有：
除非需求，不然禁用Wiki页面；
提示开发人员留意这个问题；
开发插件服务对Wiki页面的修正做出提示；
用我开发的Wiki页面审计脚本进行审计 github-wiki-auditor.py
禁用Wiki页面的办法为，去掉勾选的Wiki选项：

Wiki页面审计脚本 github-wiki-auditor.py
针对以上问题，我编写了一个python脚本，专门来用审计Github项目中的可修正Wiki页面，它能够迭代查询相关Github账户上的一切项目，查看敞开Wiki页面的状况，然后回来可修正音讯。它不会对Wiki页面做出修正，仅仅仅承认可修正状况。
Usage: github-wiki-auditor.py [-h] –accounts_file ACCOUNTS_FILE [--username USERNAME] [--password PASSWORD] [--output_file OUTPUT_FILE]
以下是对我个人Github项目的一个审计：（其间的account.txt包含了Github的账户暗码）

上报缝隙
这种问题当然不是Github的错了，但怎样报呢？我想许多大公司都存在相似问题，之后，我又对我的上述脚本进行了改善，测验从开设缝隙众测的公司中来勘探此类问题。终究，我从HackerOne、BugCrowd等开源渠道上收集了100多家存在此类问题的公司，从中挑选一些影响力大的公司进行上报。
在向10多家公司上报了之后，反应并不太好，大部份的回复是说这种问题曾经有人报过，并且不存在实践安全要挟。之后，我收到了两家公司安全团队的活跃回应，他们没在第三方众测渠道运转缝隙测验项目，所以，从这个层面上来说，这种公司不太会成为很多白帽的测验方针，并且对缝隙要求的门槛也相对较低。终究，我从其间一家公司收成了$500美金，从别的一家公司得到了称谢。