《58集团漏洞标准V4.2》
58安全应急响应中心 最后更新于 2023-12-19 19:22:46

本标准将于2023年1月4日0:00起生效

基本原则

58集团非常重视自身产品和业务的安全,我们承诺对每一份报告都有专人及时跟进处理,给出漏洞评定结果以及原因,并给予白帽子与之匹配的利益。

58SRC非常希望您在提交漏洞前认真阅读平台《58SRC漏洞评分标准》、《58SRC漏洞审核策略》以及《白帽子常见FAQ》,这能帮助您避免未来很多不必要的漏洞争议

58集团非常重视白帽子的合法权益,若白帽子对漏洞评定存在争议,请先查看《白帽子常见FAQ》若您的争议不再上述文档中,请先在漏洞评论区解决问题,若对结果依旧不满意,则可依据《58SRC审核争议解决办法》进行申诉,解决争议问题;

本规则会根据实际运营结果不定期做内容补充或调整;

在提交漏洞时,会提醒需要先同意该规则,默认所有提交者都已知晓该规则内容,我们将严格按照本规则来进行处理流程,请遵守该平台规则;

如您对本评分标准有任何建议或疑问,可联系58SRC运营或向我们反馈:src@58.com

业务分类(测试范围)

域名仅供参考, 部分合作类业务可能也会使用58的域名解析,具体以实际影响的资产为准《58SRC资产收录范围》

核心业务:58同城(招聘、房产、本地服务、大学)、58同镇、赶集网、安居客

一般业务:转转、找靓机、58金融、58心宠、58车、驾校一点通、中华英才网等

其他业务:其他不在上述内容中,但确实是58资产的业务,如:58魔方、英才企业站等

外包合作类业务:跟58为合作关系 或 58不负责其安全运营的业务,如:爱房、58天鹅到家、伯小乐。如对58没有直接影响则不收录

注:业务权重会以实际受漏洞影响的业务进行评估,并非单纯按照域名进行划分,如:

  • 业务并非按照域名划分,需要查看漏洞影响具体业务,有可能出现58.com域名系统为驾校一点通业务

  • 非58资产,跟58为合作关系但是用了*.58.com的域名的业务,算外包合作类业务(即使是存在命令执行漏洞)

  • 任何资产,若存在可以读取到58.com域名下的cookie的XSS漏洞,算核心业务;

业务分类将会不定时更新,如有其他遗漏业务欢迎与我们反馈:src@58.com

漏洞处理流程

白帽子漏洞提交成功后,漏洞状态为【待审核】

审核官开始审核漏洞是否有效后,漏洞状态为【确认中】

审核官对部分漏洞需要进行业务影响研判,漏洞状态为【定级中】

58SRC审核确认漏洞有效后,漏洞单状态为【修复中】

如漏洞无影响需忽略或重复提交,58SRC工作人员将与报告者联系或漏洞报告中留言,再将漏洞单状态更改为【已忽略】

有效漏洞在修复完成后,漏洞单状态更新为【已修复】,如白帽子在复测时发现漏洞依然存在,可再次提交。

如您在漏洞处理流程中有疑问,可先在漏洞中评论或联系58SRC运营

注:联系工作人员时,请勿夹带个人情绪,注意言语行为,禁止在未经允许的情况下私自联系工作人员

漏洞评分标准

漏洞等级对应表

表中的N为基础漏洞分。活动奖励,报告质量分不在此表展示。

金币:RMB = 1:10

外包合作类业务最高漏洞等级为中危

月度奖励详见58SRC月度奖励标准(2023年8月1日开始执行)

评分计算公式

漏洞价值 = 漏洞权重 x ((影响强度+影响范围)^2 x 0.024 + (影响强度+影响范围) x 利用难度 x 0.048) + 漏洞权重 x 0.6

最终评分 = 其他规则 x 漏洞价值 x 业务权重 [+报告质量分数]

58SRC的漏洞等级会根据漏洞价值自动计算

漏洞等级只跟漏洞价值有关,与业务权重等无关

漏洞权重

如果有未包含的漏洞类型,欢迎您向我们反馈:src@58.com

权重区间【8-10】:对服务器造成影响/越权访问/逻辑漏洞,包括但不限于

【10】远程命令执行

【10】代码执行

【10】脚本文件上传/覆盖(如getshell,静态资源除外)

【9】任意帐号登录、任意密码重置

【9】可直接能够刷钱的支付相关漏洞

【8】集团核心数据库或可以泄露大量敏感数据的SQL注入

【8】服务端加密数据可逆(含敏感数据)

【8】回显型SSRF

权重区间【6-7】:严重信息泄露/设计缺陷,包括但不限于

【7】越权操作可导致对业务核心功能及核心数据的增删改查

【7】通过越权、未授权访问、注入或接口泄露等原因导致的严重信息泄露,如核心数据库SQL注入

【7】业务拒绝服务(业务逻辑错误导致资源消耗过高的拒绝服务)

【7】XSS+CSRF蠕虫

【7】移动客户端任意代码执行

【6】不能刷钱却能够给集团造成营收资金损失的漏洞,如业务上第三方应用多次免费使用、媒体资源绕过绕过付费等

【6】外部实体注入(XXE)

【6】授权秘钥硬编码

权重区间【3-5】:需要交互/普通逻辑缺陷/普通信息泄露,包括但不限于

【5】影响客服、管理员并可获取到敏感数据或可登录相应管理平台的XSS(存储型、dom-base)(注:XSS盲打类需明确攻击触发点)

【5】越权操作可导致对业务非核心功能及非核心数据的增删改查

【5】通过越权、未授权访问、注入或接口接口等原因导致普通信息泄露且无法进一步利用,如非核心数据库SQL注入

【4】可对指定用户或手机号无限制的短信轰炸(需有5分钟内连续发送50条以上的短信证明截图)

【4】邮件等信息伪造

【3】重要敏感操作的CSRF、Jsonp劫持敏感信息、CORS劫持敏感信息

【3】客户端明文存储密码

【3】其他存在轰炸缺陷的功能(导致业务存在影响)

【3】无回显SSRF

权重区间【1-2】:轻微信息泄露/影响有限的设计缺陷或流程缺陷,包括但不限于

【2】轻微敏感信息泄露

【2】无交互的任意url跳转

【1】HTTP站点明文传输

以下类型的漏洞若无严重影响,均忽略处理

  • 影响数据皆为测试数据

  • 反馈或线索处无限提交垃圾数据

  • 网页乱码、样式混乱

  • 静态文件目录遍历

  • CRLF注入

  • 除dom-based外的反射型XSS、Self-XSS

  • 无重要敏感操作的CSRF(如收藏、点赞、添加购物车等)

  • 需要二次交互的URL跳转(如扫描二维码)

  • 账户及手机号枚举

  • 长度超过8位的密码及认证信息爆破

  • 邮箱轰炸

  • HTTPS站点的未加密传输

  • 运营预期之内或无法造成资金损失的问题,包括但不限于可使用多个账号领取小额奖励的正常业务活动

影响强度

影响强度为漏洞权重在影响维度中的名称,若无以下情况则影响强度与漏洞权重系数相同(以下数相除存在余数的情况将抛弃小数,例如漏洞权重为7,但影响强度满足下述情况,则实际影响强度为3)

  • 对于极其难以利用的漏洞(需要耗费大量时间、人力或物力),若单次利用影响有限(如:只影响少量用户或数据),影响强度/2

  • 影响系统为新上线系统、月活低于1000的非核心业务系统、影响强度/2

  • 业务权重为核心业务,系统月活远低于1000,影响强度/2

影响范围

【0】 对系统无任何影响,可造成系统某个接口或功能业务逻辑错误,但不影响系统效率,其系统业务处理能力不受任何影响,影响的数据及功能对业务毫无商业价值,漏洞无法造成安全事件,业务恢复系统正常运行付出代价可忽略不计

【1-2】受到轻微的系统影响:包括但不限于可造成系统某个接口或功能短暂中断,影响系统效率,使其系统业务处理能力受到影响,影响的数据及功能对业务毫无商业价值,恢复系统正常运行和消除漏洞造成的安全事件负面影响所需付出的代价较小。漏洞造成的安全事件对个别公民、法人或其他组织的利益可能会造成损害。(核心业务为2,非核心业务为1)

【3-4】受到一般的系统影响:包括但不限于可造成系统某个接口长时间中断,明显影响系统效率,使其系统业务处理能力受到影响,但影响数据以及功能对业务存在商业价值,恢复系统正常运行和消除漏洞造成的安全事件负面影响所需付出的代价较大,漏洞造成的安全事件波及到一个或多个地市的部分地区,或者影响到公众利益。(核心业务为4,非核心业务为3)

【5-6】受到较大的系统影响:包括但不限于可造成系统自身大面积功能或局部瘫痪,使其业务处理能力受到极大影响,恢复系统正常运行和消除安全事件负面影响所需付出的代价巨大,但对于事发组织是可承受的。漏洞造成的安全事件波及到一个或多个地市的大部分地区,对集团有重大的负面影响,或者损害到公众利益。(核心业务为6,非核心业务为5)

【7-9】受到严重的系统影响:包括但不限于可造成系统自身整体长时间中断,使其丧失业务处理能力,恢复系统正常运行和消除漏洞造成的安全事件负面影响所需付出的代价十分巨大,对于事发组织是不可承受的。波及到一个或多个省市的大部分地区,对集团有极其恶劣的负面影响,或者严重损害公众利益(核心业务为9,一般及其他业务为8,外包合作类业务为7)

【10】特别严重的系统影响:不仅影响到漏洞所在系统,对集团机房、网络、服务器、也会造成重大安全威胁(核心业务为10)

利用难度

不需要交互方即可证明的漏洞

【4, 5】能在半分钟内利用漏洞造成影响,如布尔型、回显型、报错型的SQL注入,越权漏洞等。

【2, 3】需要更多时间(三分钟内)才能利用漏洞造成影响,如4位数字遍历爆破,基于时间的SSRF、SQL注入等。

【1】需要大量时间才能利用漏洞造成影响,如5位数字遍历爆破。

需要交互方才可证明的漏洞

【3, 4】无需引诱交互方无需特殊操作,正常使用业务即可触发,如script标签的存储型XSS,image标签的csrf等。

【2】需要交互方在合理情况下进行特殊操作,但依然在正常使用业务范围内,如onclick、onmouseover等事件的存储型XSS。

【1】需要交互方打开异常页面,诱导用户进行特殊操作,或打开多个页面才能进行触发(如点击劫持)等极其难以利用的漏洞。

【1】URL跳转类需要登录或注册固定域名来跳转的

报告质量分关系表

其他规则

活动加倍

同源75%

同源条件

已修复的漏洞如果被绕过(包括漏洞完全未修复)则视为同源漏洞

同源漏洞按照源漏洞奖励75%进行奖励,没有漏洞等级。不参与任何漏洞活动以及额外奖励。

审核通用原则(分类)

请参考平台公告最新的《58SRC漏洞审核策略》

禁止行为

  • 所有漏洞禁止传播,尤其是,白帽子之间禁止交流58业务漏洞,如有发现,扣除20金币,情节严重者永久禁封账号。

  • 员工、外包、代理商体系、渠道体系禁止提交漏洞,非对外公开系统不收录漏洞,特殊情况除外。

  • 测试漏洞仅限证明性测试,严禁破坏性测试,严禁权限维持等行为,若无意中造成危害,应及时报告,同时测试中进行的敏感操作,例如删除,修改等操作,请在报告中说明。

  • 禁止在内网大范围扫描,不建议在系统后台进行功能测试。若造成业务系统或网络不可用会酌情扣除部分或全部漏洞奖励,情节恶劣的将进行账号封停或按相关法律处理。

  • 禁止系统/产品研发运维人员自己上报所负责系统/产品的漏洞,一经发现取消漏洞上报资格。

  • 参与过某系统/某产品安全评估的人员禁止上报此系统/产品的漏洞。

  • 测试漏洞的应尽量避免直接修改页面、重复弹框(xss验证建议使用console.log)、盗取cookie、使用获取其他用户信息等攻击性较强的payload。如不慎使用了攻击性较强的payload,请及时删除,否则58SRC有权追究责任。

  • 禁止下载任何代码、配置等58集团内部信息,一经发现严格处理,发现有复制、分享、传播等危害58集团信息保密、安全等行为,一律发起法律途径处理。

账号说明

目前58SRC平台允许一人拥有多个58SRC平台账户,各账户之间互相承担连带责任,但一个58SRC平台账号仅能对应一人;

一个人仅能享受一个58SRC平台账号的关于58SRC平台的活动奖励权利,禁止一人享受其拥有的多个58SRC平台账号关于58SRC平台的活动奖励。如有发现白帽子通过其拥有的多个58SRC平台账号恶意刷积分、刷排名等恶意行为,以获取享受多个58SRC平台账号关于58SRC平台的活动奖励的,58SRC平台有权对该白帽子以及该白帽子拥有的58SRC平台账号进行警告整改、积分清零、禁封账号处理;

在符合法律法规的情况下,如果白帽子需要转让、赠予或让他人继承自己58SRC平台的账号,58SRC平台有权要求白帽子提供合格的文件材料并按照58SRC平台要求的操作流程办理。

标准漏洞报告要求

漏洞报告需包含:

  • 危害描述

  • 接口地址(Target)

  • 来源地址(Referer)

  • Payload数据包(Raw)

  • 漏洞细节

漏洞中涉及到的POC, 需要用户提供文本型的raw包(至少要包含接口地址)

因涉及到分享过期、敏感信息泄露的问题,白帽子在提交漏洞时不允许将报告内容传至第三方网盘。

不能将不同类型,不同业务线的漏洞在同一漏洞报告中提交。

漏洞报告标题内容相符、业务线正确选择、漏洞类型相符。

请直接将漏洞详情写入页面编辑器中,若使用word等文件格式上传漏洞报告,会不利于审核。若无特殊情况,不要使用上传附件上传漏洞报告。

上传附件主要针对于需要上传利用脚本,利用视频等资源,如果漏洞详情通过word等。

若漏洞报告信息有误或不完善,不利于复现,会酌情做忽略处理,需补充完整情况后再次提交。

版本管理

2023年01月04日 0时0分 版本更新 《58集团漏洞评分标准 V4.2》

2022年02月17日 0时0分 版本更新 《58集团漏洞评分标准 V4.1》

2022年01月01日 0时0分 版本更新 《58集团漏洞评分标准 V4.0》

2021年01月01日 0时0分 版本更新 《58集团漏洞评分标准 V3.0》

2019年06月30日 0时0分 版本更新 《58集团漏洞评分标准 V2.2》

2019年02月26日 0时0分 版本更新 《58集团漏洞评分标准 V2.1》

2018年11月16日 0时0分 版本更新 《58集团漏洞评分标准 V1.3》

2018年06月15日 0时0分 版本更新 《58集团漏洞评分标准 V1.2》

2018年03月07日 0时0分 版本更新 《58集团漏洞评分标准 V1.1》

2018年01月01日 0时0分 发布版本 《58集团漏洞评分标准 V1.0》

 

*58集团安全应急响应中心负责本标准的解释和修订,并在法律允许的范围内有权进行解释。