附件二：众测漏洞定级标准（先知安全情报）

通用奖励计划

企业可设置严重、高危、中危、低危漏洞的奖励金额，以吸引更多的白帽子发现漏洞，以下标准都是参考标准。平台奖励积分是白帽子虚拟荣誉值，积分越高的白帽子代表对平台贡献越大。

漏洞等级

根据漏洞的危害程度将漏洞等级分为严重、高危、中危、低危。由先知平台结合利用场景中漏洞的严重程度、利用难度等综合因素给予相应分值的贡献值和漏洞级别。以下是每种等级包含的评分标准及漏洞类型。

• 严重漏洞

  严重漏洞是指，发生在核心系统业务系统（核心控制系统、域控、业务分发系统、堡垒机等可管理大量系统的管控系统），可造成大面积影响的，获取大量（依据实际情况酌情限定）业务系统控制权限，获取核心系统管理人员权限并且可控制核心系统。

  包括但不限于：

  • 控制内网多台机器。
  • 核心后台超级管理员权限获取且造成大范围企业核心数据泄露，可造成巨大影响。
• 高危漏洞
  • 获得系统的权限（getshell、命令执行等）。
  • 系统的SQL注入（后台漏洞降级，打包提交酌情提升）。
  • 敏感信息越权访问。包括但不限于绕过认证直接访问管理后台进行敏感操作、重要后台弱密码、获取大量内网敏感信息的SSRF等。
  • 读取任意文件。
  • 涉及金钱的交易、绕过支付逻辑（需最终利用成功，优惠券相关问题除外）。
  • 严重的逻辑设计缺陷和流程缺陷。包括但不限于任意用户登录漏洞、批量修改任意账号密码漏洞、涉及企业核心业务的逻辑漏洞等。验证码爆破除外。
  • 大范围影响用户的其他漏洞。包括但不仅限于重要页面可自动传播的存储型XSS、可获取管理员认证信息且成功利用的存储型XSS等。
  • 大量源代码泄露。
• 中危漏洞
  • 需交互方可影响用户的漏洞。包括但不仅限于存储型XSS、涉及核心业务的CSRF等。
  • 平行越权操作。包括但不限于绕过限制修改用户资料、执行用户操作等。
  • 由验证码逻辑导致任意账户登录、任意密码找回等系统敏感操作可被爆破成功造成的漏洞。
  • 本地保存的敏感认证密钥信息泄露，需能做出有效利用。
  • 四位验证码爆破重置密码或者登录账号。
  • 心脏滴血漏洞。
  • XML注入。
  • 普通的后台或者边缘系统的后台。
  • 任意文件上传（例如上传html导致存储XSS，其他情况除外）。
• 低危漏洞
  • 普通信息泄露（纯静态文件泄露不收取，例如JS、CSS等）。
  • 反射型XSS（包括DOM XSS、Flash XSS）。
  • 普通的垂直越权。
  • 普通CSRF。
  • URL跳转漏洞。
  • 一些影响有限的越权（不涉及敏感信息，例如修改个人描述等）。
  • 短信炸弹。
  • 无回显的且没有深入利用成功的SSRF。
  • 无法利用的GITHUB信息泄露（无敏感信息的泄露可能会不收取）。
• 暂不收取的漏洞类型
  • SPF邮件伪造漏洞。
  • 接口穷举爆破已注册用户名类漏洞。
  • self-xss或post型反射XSS。
  • 邮件炸弹。
  • 非敏感操作的CSRF问题。
  • 单独的安卓APP android:allowBackup=”true” 问题，本地拒绝服务问题等（深入利用的除外）。
  • 修改图片size造成的请求缓慢等问题。
  • Nginx、Tomcat等版本泄露的问题。
  • 一些功能BUG，无法造成安全风险的问题。
  • 其他危害较低、不能证明危害的漏洞（如无法获取到敏感信息的CORS漏洞）。

重点金融行业企业奖励计划

企业可设置高危、中危、低危漏洞的奖励金额，以吸引更多的白帽子发现漏洞，以下标准都是参考标准。平台奖励积分是白帽子虚拟荣誉值，积分越高的白帽子代表对平台贡献越大。

漏洞等级

漏洞提交规范

• 漏洞请求包或url（文字，非截图）或操作步骤（例如：设置->个人信息设置->图像上传处存在问题）。
• 漏洞payload。
• 漏洞危害证明（根据危害进行评级）。
• APP需要备注测试的版本信息。

评分标准通用原则

• 该标准仅适用于入驻先知平台的企业，并且只针对企业已明确说明接收漏洞的产品及业务。企业已明确说明不接收的漏洞将做驳回处理。企业已明确说明的漏洞等级调整将以企业为准。企业边缘业务将根据其重要程度适当调低漏洞等级。

• 各等级漏洞的最终贡献值数量由漏洞利用难度及影响范围等综合因素决定，若漏洞触发条件非常苛刻，包括但不限于特定浏览器才可触发的XSS漏洞，则可跨等级调整贡献值数量。

• 同一个漏洞源产生的多个漏洞计漏洞数量为一。例如同一个接口引起的多个安全漏洞、同一个发布系统引起的多个页面的安全漏洞、框架导致的整站的安全漏洞、泛域名解析产生的多个安全漏洞；因为厂商未做身份校验导致的同一系统多个接口越权或者是未做token校验导致的多个CSRF漏洞；同一文件的不同参数、同一参数出现在不同文件、同一文件在不同目录等。

• 第三方产品的漏洞只给第一个提交者计贡献值，等级不高于中，包括但不限于企业所使用的WordPress、Flash插件以及Apache等服务端相关组件、OpenSSL、第三方SDK等；不同版本的同一处漏洞视为相同漏洞。

• 通常，同一漏洞，首位报告者给予奖励，其他报告者均不计；同一漏洞，后提交的利用方式比第一个提交的利用造成的影响差距过大时，两个漏洞都通过，从第二个漏洞中分一部分奖金费第一个提交的同学。

• 不可公开已提交的漏洞细节，违者取消测试资格或封停账号。

• 报告网上已公开的漏洞不给予奖励。

• 漏洞打包。

  • 存在前后关系的漏洞，比如同一人提交的弱口令进入后台，后台SQL注入或者越权的漏洞合并处理，审核可以酌情提高漏洞等级。若已提交，后面又发现，则补充到该漏洞下面，可以提高奖金金额。
  • 对于漏洞拆分提交者，由管理员对漏洞进行打包，漏洞等级按打包漏洞中危害最高的计算，奖金按标准的最低额度发放，后期项目分配率会减低。对于严重拆分漏洞，刷漏洞等恶意行为进行冻结账户、甚至封号处理。
  • 若存在以下情况者，小黑屋1个月。

    存在前后关系，先提交后者的。例如：发现邮箱弱口令，从邮箱中获知后台管理员密码，提交漏洞时先提交后台弱口令，再提交邮箱弱口令者。

• 以测试漏洞为借口，利用漏洞进行损害用户利益、影响业务运作、盗取用户数据等行为的，将不会计贡献值，同时先知平台将联合入驻企业保留采取进一步法律行动的权利。

• 对于提交描述不清的漏洞，将会直接驳回处理；每个漏洞需要明确产生漏洞的URL地址、文字细节、完整的截图、清晰的语言表达。

• SQL注入需要证明可以注入出一条数据，单纯报错提交会忽略。

• 弱口令问题（正常对外可注册的系统不算在弱口令范围内）：

  • 对于同一个人发现同一系统的不同的弱口令，将合并处理（如果厂商已经处理了之前的弱口令，后面再次提交的降级处理，第二次以后提交的都会合并处理）。
  • 对于默认的初始密码，只按照一个漏洞进行处理（比如邮箱的初始密码都是同一个密码，视为一个漏洞）。
  • 对于非重点系统，审核过程只正常确认该系统的第一个弱口令，后续提交的弱口令酌情忽略处理。
  • 对于重点系统或者核心业务，在评级过程中只正常确认前2个弱口令，后续的提交弱口令问题酌情降级或者忽略处理。

• 对于边缘或废弃业务系统，根据实际情况酌情降级。

• 存在前后关系的漏洞，比如同一人提交的弱口令进入后台，后台SQL注入的漏洞合并处理，可以提高漏洞等级，希望大家不要拆分漏洞，先知将根据实际情况对严重拆分漏洞，刷漏洞等恶意行为进行冻结账户、甚至封号的处理。

• 信息泄露类的漏洞如github信息泄露，memcache、redis等未授权访问等，根据存储的内容的有效、敏感程度进行确认评级，单独的危害较低的信息泄露如路径泄露，phpinfo信息泄露等将会忽略处理。

• 对于已经得到Webshell的情况，如果想打包源代码审计，请事先联系审核人员，审核人员将会与厂商沟通相关事宜，如果厂商同意审计，再进行后续操作，发现的漏洞可单独提交。否则，禁止下载源代码，将视为违规操作、一经发现行冻结账户、甚至封号的处理。

• 对于使用采用低版本的CMS导致的漏洞，每个漏洞类型只确认第一个提交的安全问题。

• 切勿进行可能引起业务异常运行的测试，例如：IIS的拒绝服务或者slow_http_dos等漏洞。

• 前台撞库、爆破类漏洞，需有成功案例证明；后台爆破，仅收取成功登录的案例，仅能爆破但没有进入后台的漏洞将驳回。

• 对于一些难以利用的安全漏洞，例如：HTTP.sys远程命令执行类漏洞，只确认一个提交的漏洞，评为低危漏洞，只是为了提示厂商做对应的升级。

• 对于PC端和APP端同一接口同一套代码的两个漏洞（即使域名可能不同），同一白帽子分开提交平台将会合并处理，主动合并会酌情提高奖励；不同的白帽子分别提交，在厂商未修复之前，评为重复漏洞。

• 对于信息泄露相关漏洞（包括GITHUB，提交的时候请说明，有哪些特征可以证明是某厂商的），可以深入利用造成很大危害的，一般为高危或者严重；对于是厂商线上对外核心应用服务配置、代码等信息泄露，一般为中危；如果不能做出有效利用且非核心业务的，一般为低危或者驳回处理。

• 严禁进行内网渗透，安全测试点到为止即可。

厂商保护机制

如果同一个系统中短时间发现了大量的同类型高危漏洞（如SQL注入、命令执行等），审核人员判定该系统几乎没有做任何防护，会与厂商沟通该系统的该类型漏洞是否要继续收取；若厂商表示该类漏洞已知不再收取，则平台方正常审核前三个该类型漏洞，发布通知前同系统其他同类型漏洞均降级处理，发布通知后同系统同类型漏洞均不再收取，直到厂商重新开放该漏洞类型收取。对于厂商漏洞修复被绕过或者代码回滚的原因导致漏洞还能被继续利用的，一年内再次提交降级收取。

注意事项

• 白帽子在测试SQL注入漏洞时，对于UPDATE、DELETE、INSERT 等注入类型，使用手工测试，禁止直接使用工具测试。

• 测试过程中，社工企业员工，注意分寸，切勿对个人造成名誉影响。

• 禁止修改厂商的任何数据，包括数据库内容、账户密码、数据库连接密码等。

• 不允许使用扫描器对后台系统进行扫描。

• 对于不在客户测试范围内的系统的测试，属于未授权测试，平台和厂商有权追究其责任。

• 以上所有漏洞级别可视应用场景再具体定级，如SQL注入涉及到的数据为边缘系统或者测试数据则降低漏洞等级等。

• 以上所有漏洞级别为厂商参考的基础标准，可视应用业务场景再具体定级，具体定级主要是由厂商反馈而定。

奖金发放相关

• 请一定确认好，自己填写的收款账号和姓名一致（不要填写*）.

• 奖金发放周期，对于提交的漏洞，厂商复盘完成后，可以马上发放奖金，最快可做到当天，但是因为厂商结合业务评估或者内部推动需要时间周期，对于超过一个月仍未复盘完成的漏洞，平台会默认先发放奖金（即默认发放周期是一个月）。

争议解决办法

在漏洞报告处理过程中，如果报告者对流程处理、漏洞定级、漏洞评分等有异议的，可以通过漏洞详情页面的留言板或者通过即时通讯联系在线工作人员及时沟通。先知平台将按照漏洞报告者利益优先的原则与企业三方协调处理，必要时可引入外部安全人士共同裁定。