基本原则

 

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

58集团非常重视白帽子的合法权益，若白帽子对漏洞评定存在争议，可依据《58SRC审核争议解决办法》进行申诉，解决争议问题；

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

 

业务分类(测试范围)

 

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

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

一般业务：转转、找靓机、58金融、58心宠、58车、驾校一点通、中华英才网、星火、58内部系统等

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

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

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

• 非58资产，跟58为合作关系但是用了*.58.com的域名的业务若存在命令执行漏洞，算外包合作类业务；
• 任何资产，若存在可以读取到58.com域名下的cookie的XSS漏洞，算核心业务；

 

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

 

漏洞处理流程

 

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

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

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

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

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

 

漏洞评分标准

 

漏洞等级对应表

 

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

金币:RMB = 1:10

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

月度奖励详见《2022年58SRC额外奖励标准》

 

评分计算公式

 

漏洞价值 = 漏洞权重 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】垂直越权（含权限绕过）

【8】SQL注入

【8】服务端加密数据可逆（含敏感数据）

【8】回显型SSRF

【8】58集团、用户敏感信息泄露

 

权重区间【6-7】：一般的敏感信息泄露/越权访问，包括但不限于

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

【7】水平越权（含权限绕过）

【7】XSS+CSRF蠕虫

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

【6】后台密码泄露

【6】API接口列表泄露

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

【6】源码泄漏

【6】授权秘钥硬编码

 

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

【5】XSS（存储型、DOM-BASED）

【4】CSRF

【4】JSONP劫持

【4】CORS

【4】短信轰炸（需有5分钟内连续发送50条以上的短信证明截图）

【3】Broadcast消息伪造

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

【3】其他存在轰炸缺陷的功能（需存在实际影响）

【3】无回显SSRF

 

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

【2】配置信息泄露（phpinfo、debug日志）

【2】url跳转

【1】异常信息、服务器物理路径信息

【1】HTTP站点明文传输

 

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

无直接安全问题/无法直接利用/无法证明漏洞存在/利用成本过高的漏洞，包括但不限于

 - 反馈处无限提交垃圾数据

 - 非服务器上的信息泄漏（.DS_Store、.idea、.vscode等文件夹）

 - 网页乱码、样式混乱

 - 静态文件目录遍历

 - CRLF注入

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

 - 无意义的异常信息泄漏、内网 IP 地址/域名泄漏（如果可结合其他漏洞打组合拳，请一起提交）

 - 如收藏、点赞、添加购物车等CSRF

 - 需要二次交互的URL跳转（如扫描二维码）

 - 遍历手机号发短信

 - 长度超过8位的爆破

 - 遍历判断账号是否已注册

 - 邮箱轰炸

 - HTTPS站点的未加密传输

 - 超过一年且无重要敏感信息的网盘、Github泄露

 - 不属于隐私密号策略内的手机号码泄露

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

 - 业务线明确可承受危害，不影响系统安全的业务逻辑漏洞

 

影响范围

 

对于以下情况，影响范围权重/2:

业务权重为非核心业务，且网站用户量远低于1000

对于极其难以利用的漏洞(需要耗费大量时间、人力或物力)，若单次利用影响有限（如：只影响少量用户或数据）

 

利用难度

 

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

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

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

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

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

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

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

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

 

报告质量分关系表

 

 

其他规则

 

活动加倍

同源75%

 

同源条件

 

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

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

 

审核通用原则

 

 - 白帽子如果主动要求忽略漏洞重新提交，可能在下次提交前会有其他人提交该漏洞，需要自行承担重复风险。

 - 如未单独声明，对于同一系统如果短时间内被提交多个同类型漏洞，例如：刚上线的业务多处类似接口存在SQL注入，则按照漏洞类型分别对最先提交的2个漏洞正常收录和评分，随后对该系统业务所有该类型进行排查，规定最大期限为一个月，从漏洞确认 开始算起直至修复完成，期间漏洞状态为修复中，此时同类型漏洞被提交按忽略处理，完成修复后漏洞状态变为修复完成，若依旧存在该类型漏洞，则可继续正常提交给分，此类型不属于同源。

 - 正常建议每份报告提交单个漏洞，如果为漏洞组合利用则需要打包提交。

 - 密码泄露只收录业务后台系统，测试系统，必须提供密码来源方式，同一系统的多个密码泄露问题算作同一漏洞。

 - 如果您或其他白帽子通过新的报告提交了某个已修复漏洞的绕过方式，该报告会被定为同源漏洞，无实际漏洞等级，会按照原漏洞奖励的75%给分。

 - 修复某个漏洞的同时也会带来对该漏洞点所在功能的额外排查，因此可能会修复该漏洞以外的其他漏洞，所以如果新提交的漏洞与状态为‘修复中’的漏洞同源，可能会被忽略处理。

 - 由某个漏洞产生的多个影响，按原漏洞评定权值，影响程度视具体危害评定。如：核心业务后台密码泄露导致大量用户简历信息泄露，后台查看用户简历为正常功能，漏洞权重会定为后台密码泄露（6）而非敏感信息泄露（8），但实际的影响为严重影响（18），评分约为230（严重）。

 - 由同一漏洞源产生的多个同类型漏洞算一个漏洞。如：框架导致的整站漏洞，同一个JS引发的多个漏洞，同一个功能模块引起的多个页面的漏洞。

 - 因任何原因忽略的报告统一显示为误报。

 - 无论漏洞报告是同源还是忽略，审核人员都会在漏洞评论处给出token，方便对相似漏洞进行溯源、归类。

 - 评分标准仅适用于58集团相关产品和对内对外业务系统、可威胁到58集团产品和业务相关的情报。与58集团完全无关的漏洞和情报，不计贡献值。

 - 第三方产品漏洞只给第一个提交者计算贡献，不同版本的同一处漏洞视为相同漏洞。

 - 同一漏洞或情报首位报告者计算奖励，其他报告者不计，由于情报的时效性，报告已知或已失效的情报不计分。

 - 已公开的漏洞或情报不记贡献，存在刷洞嫌疑的不进行奖励。

 - 人为自行制造安全威胁或安全事件情报的不计分，涉及到58集团的所有漏洞和情报在58集团主动公开前公开给除58集团授权的任何人，均不计分，同时58集团将保留采取进一步法律行动的权利。

 

禁止行为

 

 - 所有漏洞禁止传播，尤其是，白帽子之间禁止交流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等文件格式上传漏洞报告，会不利于审核。若无特殊情况，不要使用上传附件上传漏洞报告。

上传附件主要针对于需要上传利用脚本，利用视频等资源。

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

 

版本管理

 

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集团安全应急响应中心负责本标准的解释和修订，并在法律允许的范围内有权进行解释。