UCloud SRC 奖励标准V1.1

公告编号:UCloud SRC 奖励标准 V 1.1作者:admin发布日期:2021/09/09

一、基本说明

1.奖励标准仅针对Ucloud产品和业务有影响的威胁情报。域名包括但不限于*.ucloud.cn,Ucloud发布的产品,对Ucloud业务安全无影响的威胁情报,不计入贡献;
2.对于非Ucloud直接发布的业务或Ucloud第三方平台或云上客户的业务,不计入贡献;
3.由同一个漏洞源产生的多个漏洞一般计漏洞数量为一个,如提交问题已修复但其他位置仍存在该问题则重新计入贡献; 同一个域名的同类问题在七个工作日内重复提交,只计第一个;
4.同一漏洞只对最早提交者计算贡献,在其它平台上提交过的不计入贡献,提交在其他漏洞披露平台已提交的漏洞不计分;
5.提交外界已经公开的漏洞不计入贡献;
6.第三方库导致的漏洞只给第一个提交者计贡献值,等级不高于【中】,且不保证修复时长;不同版本的同一处漏洞视为相同漏洞;
7.各等级漏洞的最终贡献值数量由漏洞利用难度及影响范围等综合因素决定,若漏洞触发条件非常苛刻,则可降低漏洞等级;
8.厂商已知漏洞不重复计算贡献值,漏洞提交后厂商会迅速是否为已知漏洞,并给出回应;
9.以安全测试为借口,利用情报信息进行损害用户利益、影响业务正常运作、修复前公开、盗取用户数据等行为的,将不会计分,同时保留采取进一步法律行动的权利;
10. 已经报告给其他第三方的漏洞,不在给予奖励;

二、测试规范

参考:《SRC行业安全测试规范
1. 注入漏洞,只要证明可以读取数据就行,严禁读取表内数据。对于 UPDATE、DELETE、INSERT 等注入类型,不允许使用自动化工具进行测试。
2. 越权漏洞,越权读取的时候,能读取到的真实数据不超过5组,严禁进行批量读取。
3. 帐号可注册的情况下,只允许用自己的2个帐号验证漏洞效果,不要涉及线上正常用户的帐号,越权增删改,请使用自己测试帐号进行。帐号不可注册的情况下,如果获取到该系统的账密并验证成功,如需进一步安全测试,请咨询管理员得到同意后进行测试。
4. 存储 XSS 漏洞,正确的方法是插入不影响他人的测试 payload,严禁弹窗,推荐使用 console.log,再通过自己的另一个帐号进行验证,提供截图证明。对于盲打类 XSS,仅允许外带 domain 信息。所有 XSS 测试,测试之后需删除插入数据,如不能删除,请在漏洞报告中备注插入点。
5. 如果可以 Shell 或者命令执行的,推荐上传一个文本证明,如纯文本的 1.php、1.jsp 等证明问题存在即可,禁止下载和读取服务器上任何源代码文件和敏感文件,不要执行删除、写入命令,如果是上传的 WebShell,请写明 Shell 文件地址和连接口令。
6. 在测试未限制发送短信或邮件次数等扫号类漏洞,测试成功的数量不超过 50 个。如果用户可以感知,例如会给用户发送登陆提醒短信,则不允许对他人真实手机号进行测试。
7. 如需要进行具有自动传播和扩散能力漏洞的测试(如社交蠕虫的测试),只允许使用和其他账号隔离的小号进行测试。不要使用有社交关系的账号,防止蠕虫扩散。
8. 禁止对网站后台和部分私密项目使用扫描器。
9. 除特别获准的情况下,严禁与漏洞无关的社工,严禁进行内网渗透。
10. 禁止进行可能引起业务异常运行的测试,例如:IIS 的拒绝服务等可导致拒绝服务的漏洞测试以及 DDoS 攻击。
11. 请不要对未授权厂商、未分配给自己的项目、超出测试范围的列表进行漏洞挖掘,可与管理员联系确认是否属于资产范围后进行挖掘,否则未授权的法律风险将由漏洞挖掘者自己承担。
12. 禁止拖库、随意大量增删改他人信息,禁止可对服务稳定性造成影响的扫描、使用将漏洞进行黑灰产行为等恶意行为。
13. 敏感信息的泄漏会对用户、厂商及上报者都产生较大风险,禁止保存和传播和业务相关的敏感数据,包括但不限于业务服务器以及 Github 等平台泄露的源代码、运营数据、用户资料等,若存在不知情的下载行为,需及时说明和删除。
14. 尊重《中华人民共和国网络安全法》的相关规定。禁止一切以漏洞测试为借口,利用安全漏洞进行破坏、损害用户利益的行为,包括但不限于威胁、恐吓SRC要公开漏洞或数据,请不要在任何情况下泄露漏洞测试过程中所获知的任何信息,漏洞信息对第三方披露请先联系 ZSRC 获得授权。企业将对违法违规者保留采取进一步法律行动的权利。

三、威胁情报反馈与处理流程

报告阶段
报告者登录平台,提单反馈威胁情报(状态:待审核)。
处理阶段
- 1 个工作日内,工作人员会确认收到的威胁情报报告并跟进开始评估问题(状态:审核中);
- 5 个工作日内,工作人员处理问题、给出结论并计分(状态:已确认/已忽略);
- 必要时会与报告者沟通确认,请报告者予以协助。
修复阶段
- 业务部门修复威胁情报中反馈的安全问题并安排更新上线(状态:已修复)。修复时间根据问题的严重程度及修复难度而定,一般来说,严重和高风险问题 24 小时内,中风险七个工作日内,低风险三十个工作日内。客户端安全问题受版本发布限制,修复时间根据实际情况确定;
- 报告者复查安全问题是否修复(状态:已复查/复查异议)。
完成阶段
- 威胁情报报告者可以通过报告漏洞获得安全币(1 安全币约为人民币 1 元),通过安全币在虚拟市场置换现金或礼品;

四、业务漏洞评分标准

根据漏洞危害程度分为高、中、低、无四个等级,每个等级评分如下:
高风险
分值范围 6-10,安全币 1000-5000。本等级包括:
- 越权访问敏感信息或大量普通信息。包括但不限于敏感管理后台登录、批量获取任意社区内容、可直接利用的敏感数据泄漏;
- 直接获取权限的漏洞(服务器权限、重要产品客户端权限)。包括但不限于远程任意命令执行、上传 WebShell、可利用远程缓冲区溢出、可利用远程内核代码执行漏洞以及其它因逻辑问题导致的可利用的远程代码执行漏洞;
- 直接导致严重的信息泄漏漏洞。包括但不限于重要 DB 的 SQL 注入漏洞,主要业务系统的存储型XSS漏洞;
- 直接导致严重影响的逻辑漏洞。
中风险
分值范围 3-5,安全币 200-1000。本等级包括:
- 越权访问少量普通信息。包括但不限于通过枚举手段获取特定社区内容;
- 需交互才能获取用户身份信息的漏洞。包括但不限于反射型 XSS(包括反射型 DOM-XSS)、JSON Hijacking、重要敏感操作的 CSRF、普通业务的存储型 XSS;
- 敏感信息泄露、内核拒绝服务漏洞、可获取敏感信息或者执行敏感操作的客户端产品的 XSS 漏洞;
- 普通信息泄漏漏洞。包括但不限于客户端明文存储密码、QQ 密码明文传输、包含敏感信息的源代码压缩包泄漏。
低风险
分值范围 1-2,安全币 100-200。本等级包括:
- 只在特定非流行浏览器环境下(如 IE6 等)才能获取用户身份信息的漏洞。包括但不限于反射型 XSS(包括反射型 DOM-XSS)、普通业务的存储型 XSS 等;
- 轻微信息泄漏漏洞。包括但不限于路径泄漏、SVN 文件泄漏、phpinfo、logcat 敏感信息泄漏;
-远程应用拒绝服务漏洞、客户端本地拒绝服务漏洞。包括但不限于组件权限导致的本地拒绝服务漏洞。
- 低风险的越权访问;
- 难以利用但又可能存在安全隐患的问题。包括但不限于可能引起传播和利用的 Self-XSS、非重要的敏感操作 CSRF 以及需借助中间人攻击的远程代码执行漏洞并提供了有效 PoC。

分值范围 0,安全币 0-5。本等级包括:
- 无关安全的 BUG。包括但不限于网页乱码、网页无法打开、某功能无法用;
- 无法利用的“漏洞”。包括但不限于没有实际意义的扫描器漏洞报告(如 Web Server 的低版本)、Self-XSS、无敏感信息的 JSON Hijacking、无敏感操作的 CSRF(如收藏等)、无意义的源码泄漏、内网 IP 地址/域名泄漏、401 基础认证钓鱼、程序路径信任问题、无敏感信息的 logcat 信息泄漏;
- 无任何证据的猜测。

五、安全情报评分标准

此处的安全情报特指针对UCloud产品和业务漏洞相关的情报,包括但不限于漏洞线索、攻击线索、攻击者相关信息、攻击方式、攻击技术等。根据危害及情报提供情况标准如下:
安全币 100-1000。
- 服务器被入侵且提供了入侵行为方式等相关线索,方便快速定位确认问题点;
- 重要业务数据库被拖取且提供了数据库名或数据库文件等相关线索,方便快速定位确认问题点;
- 重大金融逻辑漏洞线索,例如支付、提现相关严重的逻辑漏洞。
- 攻击者相关信息,如攻击者 QQ、微信、电话等。

六、评分标准通用原则

1. 评分标准仅针对对UCloud产品和业务有影响的威胁情报;
2. 通用型漏洞一般计漏洞数量为一个(如同一个 JS 引起的多个 XSS 漏洞、同一个发布系统引起的多个页面的 XSS 漏洞、框架导致的整站 XSS/CSRF 漏洞、泛域名解析产生的多个 XSS 漏洞、同一域名下同一组件产生的多个 Flash XSS 漏洞等;
3. 对于第三方库(比如 libpng、zlib、libjpeg 等等)导致的客户端漏洞(包括桌面端和移动端),且可以通过升级或者更换第三方库可完成修复的漏洞,仅给首个漏洞报告者计分。同时,从 USRC 获取首个漏洞的反馈时间到第三方首个修复版本发布时间的日期内,对于同一类漏洞均按一个漏洞计分,危害等级取危害最大的一个漏洞来评定;
4. 对于移动终端系统导致的通用型漏洞,比如 WebKit 的 UXSS、代码执行等等,仅给首个漏洞报告者计分,对于其它产品的同个漏洞报告,均不再另外计分;
5. 由于客户端漏洞审核本身比较复杂并且涉及到其它的开发部门,审核时间可能较长,有时可能由于报告者提供的漏洞细节不够详尽,导致 USRC 无法按原定时间内给出结论,请各位白帽子理解。因此请各位白帽子在反馈漏洞时提供 poc/exploit,并提供相应的漏洞分析,以加快管理员处理速度,对于 poc 或 exploit 未提供或者没有详细分析的漏洞提交将可能直接影响评分;
6. 如果同一时间周期内提交同一客户端的多个漏洞,请报告者在反馈漏洞时明确给出导致漏洞和触发漏洞的关键代码,以帮助快速确认是否为相同漏洞,加快漏洞确认时间;
7. 威胁情报报告者复查安全问题时如果发现安全问题仍然存在或未修复好,当作新威胁情报继续计分;
8. 同一条威胁情报,第一个报告者得分,其他报告者不得分;提交网上已公开的威胁情报不计分;
9. 拒绝无实际危害证明的扫描器结果;
10. 以安全测试为借口,利用情报信息进行损害用户利益、影响业务正常运作、修复前公开、盗取用户数据等行为的,将不会计分,同时保留采取进一步法律行动的权利。

七、违规罚则

UCloud安全应急响应中心针对违反测试规范的罚则如下:
1. 对于干扰业务的违规测试行为(包括但不限于以上“测试规范”内容),所提交漏洞积分为0,漏洞奖金将根据业务资损情况判定是否扣除。
2. 如有三次违规测试行为,将取消该年度平台福利、季度奖金和年度奖金资格。
3. 如触犯测试规范第14条,将取消所有奖励(漏洞奖励、平台福利、季度奖励和年终奖励等),同时我们将保留法律追责权力。
4. 以上处罚措施解释权归UCloud应急响应中心所有。