黑客接单诚信黑客_一次对GitHub Wiki页面的把玩测验

作者: admin 分类: 新闻动态 发布时间: 2022-07-01 15:30

在做缝隙众测的时分,缝隙的界说其实是十分广泛的,就看你怎样来看待它了,所以当方针项目相关的某项新功用新特点出现时,你能够细心研讨,结合实践进行一些安全剖析。本文中,作者就针对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/wikihttps://github.com/gollum/gollum/wikihttps://github.com/g0v/dev/wikihttps://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美金,从别的一家公司得到了称谢。

黑客接单诚信黑客_一次对GitHub Wiki页面的把玩测验

更多阅读