资源提交标准

特征标准

特征提交方式

  1. 点击社区导航栏中“资源”列表中的“提交特征” 资源提交标准 - 图1

  2. 按照要求填写特征信息，提交即可。更多问题在提交页面中有说明。可在BugScan—漏洞插件社区—指纹列表中查看该应用是否已存在。

特征格式标准

  1. 特征提交规范：
    1. 厂商名称：厂商的名称，如Adobe
    2. 应用名称：该应用的名称，可以包含中文。全称、简称均可，可搜索到的名称。如：Wordpress博客管理系统，不区分到版本
    3. 应用指纹名称：即插件里调用的时候的名称。如fingerprint.wordpress，应用指纹名对应的是wordpress 。
    4. 特征简介：简单介绍该应用的用途等信息。
    5. 指纹内容：详见主要内容
    6. 测试地址：至少提供2个可用的测试URL。越多越好，利于自动抓取分词特征的程序运行。
  2. 指纹内容 指纹是若干个（路径，特征文本）构成的元组（路径开头不带”/“） 如：
    1. [
    2. ["robots.txt","wp-admin"],
    3. ["admin.php","wordpress"],
    4. ["css/main.css", "wp-nightmode"],
    5. ["theme/logo.png", "b99ebbec34e04c9726714dfc8735c38b"]
    6. ]
    指纹分为两类：
    文本类
    通常使用：
    1. robots.txt文件
    2. css、js资源
    3. 特殊链接指向的页面等。 特征文本使用：
    4. 其中的带有应用名的字眼。
    5. 比较特殊的代码片段、变量名称等。尽量使用英文字符。
      图片资源类
      通常使用：
    6. favicon.ico
    7. 背景图片、按钮icon。不宜更改的、不显眼的图片。 特征文本使用相应图片资源的MD5。

特征审核标准

  1. 已有特征的应用依然可以进行提交
  2. 提交特征时应给出测试的URL，至少两个。
  3. 特征不能过于简单，严禁存在误报隐患的特征通过
  4. 特征以单个产品为划分粒度，同一产品的不同特征指纹都属于一个应用。
  5. 正常情况下一个应用至少要有一个文本类特征和一个图片类特征。
  6. 一个应用特征内容过多的情况下审核员应根据情况进行删减，最多指纹不超过7个。但若特征内容为某版本独有且在特征简介中进行说明，则不计入上限中。

特征奖励标准

  1. 提交特征时按照指纹内容的个数进行Rank奖励，每个特征奖励 1 Rank。
  2. 当特征内容超过7个时，由管理员视情况对特征内容进行删减，保留不超过七个指纹。即无论提交多少个特征内容，单个特征最高获可获得7 Rank.

漏洞标准

漏洞提交方式

  1. 点击社区导航栏中“资源”列表中的“提交漏洞” 资源提交标准 - 图2
  2. 按照要求填写各项漏洞信息

漏洞格式标准

基本要求
  1. 每个插件都要有对应的漏洞信息
  2. 漏洞可以对应不同的插件，也可以不对应插件
  3. 对于社区而言，漏洞只能是通用漏洞
    内容标准
  4. 漏洞类型：漏洞对用现行分类里的哪个类型
  5. 特征：插件上线需要指定相应的特征才能上线，即该漏洞对应的应用/系统等
  6. 漏洞标题，应做到：
    1. 表明漏洞的CMS类型、位置、类型，建议包含版本号，一般形式为”应用名 +（版本号）+ 漏洞位置（路径+参数） + 漏洞类型”
      • 如：dedecms V3.0 index.php id参数 SQL注入漏洞
      • 适用空格进行分割
      • 漏洞类型尽量使用中文说明，如SQLI应写为SQL注入
    2. 不能出现例如最新、通杀、某版本等模糊或有歧义字样。
    3. 不能出现具体漏洞站点或站点标题、名称。如：百度主站www.baidu.com存在XSS，这种会暴露某些站点漏洞信息的是标题不允许的。
  7. 漏洞详情：说明该漏洞的危害性。该漏洞若对应其他漏洞库漏洞编号的，可在漏洞详情结尾另起一行，放入json格式说明，（漏洞利用+加分）

    {“cve”:”CVE编号”, “cnnvd”:”CNNVD编号”}

  8. 漏洞成因：说明该漏洞的形成原因。
  9. 引用地址：请给出该漏洞的来源地址。
  10. 修复建议：如能给出可靠修复建议，详细给出。如不能、给出临时修复建议。 修复建议的基本原则：
    1. 能根据建议执行可操作的步骤；
    2. 能给出引用链接的，尽量给出引用链接；
    3. 语言要求言简意赅。英文专有名词可以直接使用英文，避免因翻译问题搜索时搜不到的麻烦；
    4. 如现无修复方案，可以导流到CMS应用的官方修复方案页面，建议用户关注；
      区分标准
  11. 漏洞以漏洞位置进行区分
  12. 若同一参数但路径不同，区分为不同漏洞。
  13. 若不同版本号但路径及参数一致，且漏洞成因一致，则划分为相同漏洞

漏洞审核标准

  1. 仅收录通用型漏洞，不收录具体站点的漏洞。相关具体站点的漏洞可能会被删除。(重要)
  2. 漏洞应符合其格式标准要求，内容标准中的信息缺一不可，审核人对于不符合格式内容要求的漏洞给出修改建议，等待提交者修改。
  3. 0DAY漏洞第一时间向厂商进行汇报。

漏洞奖励标准

  1. 对于符合格式要求且通过的漏洞，视漏洞的实时性、影响性、以及相关描述的完整性奖励1～2个Rank。
  2. 对于路由器、摄像头、智能硬件等物联网或工控相关漏洞，可视漏洞影响性+1～2个Rank

插件标准

基本标准

  1. 运行后会不会造成主机崩溃（如DOS、溢出类）
  2. 不能关闭、重启、注销目标主机
  3. 不能更改关键文件。
  4. 不能直接获取主机敏感数据，如注入不能直接获取账号密码等。
  5. 不能添加持久的账户、弱口令进入目标主机。
  6. 不能增加后门、开放端口、转发端口
  7. 可以生成临时文件、临时账户并删除
  8. 可以使用无意义的字符串或MD5值
  9. 可以为了验证漏洞只读某些特殊文件
  10. 可以执行简单的、无危害的代码 （插件名称）

    插件格式标准

  11. assign函数：其中判断service类型和简单处理arg
  12. audit函数：主要测试代码在这个函数完成。按照不同类型的漏洞有不同标准，详见插件编写doc。
  13. 测试代码：在SDK下调用下的测试代码，应写在if __name__ == '__main__' 下面
  14. 具体插件编写格式见：BugScan 插件开发文档

插件审核标准

  1. 检查是否重复的步骤
    1. 搜索插件中的CMS类型名称
    2. 搜索漏洞类型
    3. 检查标题中的页面名称是否重复
    4. 检查参数是否重复
    5. 检查payload是否重复
    6. 如果进行到第五步，说明重复，进行对比流程。
  2. 检查插件格式是否符合标准
    1. 检查assign、audit函数是否存在
    2. 检查if __name__=='__main__' 是否存在并在其下有测试代码
    3. 如不符合标准，标记等待修改，原因不符合提交标准
  3. 是否正常执行
    1. 在沙盒执行，查看是否有语法错误
      1.  1. 如果执行出错：小错误顺手改掉。错误不宜修改的*标记等待修改，原因编写错误*
  4. 查看是否正常输出security_func的结果
    1. 如不输出、检查是否是本地测试环境
      1.  1. 非本地测试环境：*标记等待修改、原因为不能验证*
      2.  2. 本地测试环境：检查是否有截图，如无，*标记等待修改、原因为不能验证*
  5. 是否是通用漏洞
    1. 检查测试网站数量，如较多不同网站、且CMS为一般常见应用。则可认为是通用漏洞
    2. 如果只有一个测试网址，可询问编写者询问更多情况，或根据测试网站中的Powered by 、inurl等信息尝试搜索，根据搜索结果判断是否是通用。或访问相应CMS所属厂商查看信息。
    3. 对于不确定的，标记已初审。留言给编写者。
  6. 是否对目标造成威胁
    1. 检查是否符合插件运行标准。

插件提交标准

1.命名规范:

  1. 1. 应用名称_版本号_插件名称_漏洞位置_攻击类型漏洞
  2. 2. 攻击类型按照以下分类对应
  3.     sql注入/xss/命令执行/代码执行/伪造/任意文件下载/任意文件上传/任意文件写入/任意文件读取/任意文件删除/
  4.         文件包含/目录遍历/未授权访问/越权/绕过/信息泄露/xxe/url跳转/其他
  5. 3. 不能出现具体漏洞站点或者站点标题，名称(针对事件型漏洞)
  6. 4.不应出现任何与bugscan,个人,厂商相关的信息(标题跟内容中均不能出现，注释除外)
  7. 5. 插件中不能出现例如:"最新"，"某版本"等模糊或者"0day"字样
  8. 6. 特殊插件命名格式: "相关应用_功能_攻击类型漏洞"

2.内容规范:

  1. 1.插件内容中需要标明的:
  2.     #漏洞参考链接
  3.     #应用官网地址
  4. 2.插件验证:
  5.     本地验证:留言需要标明漏洞成因，本地脚本测试截图，源码包。
  6.     线上验证

插件奖励标准

符合插件提交标准：插件基础评分为1,以下为加分项

  • 影响范围 0～2
  • 危害程度 0～2
  • 编写难度 0～2
  • 物联网、工控加成 0～2
  • 特殊加成 0～10
    影响范围Rank评定
    2：影响范围极大，例如Apache、Nginx的核心框架（不包含组件）本身的漏洞，Windows、Linux系统漏洞 1：影响范围较大，例如WordPress这类国际主流CMS或者、Dedecms这种国内常见的CMS、系统服务、常见框架的组件等。 0：影响范围一般，例如某些校园系统、定制系统、主流应用的插件导致的漏洞。
    危害程度
    2：危害极为严重，可直接获取目标权限的，例如无限制的远程命令执行。 1：危害严重，可获取读取系统文件或数据库数据的、或者可以通过其他方法简介获取目标权限的。例如SQL注入、任意文件读取，任意文件上传。 0：危害一般。
    编写难度
    此项为审核人员主观评价，结合插件功能和插件使用技术两方面对编写难度进行评价。分值区间0～2。
    物联网、工控加成
    2：工控相关插件 1：物联网相关插件 0：其他
    特殊加成
    因为各种各样的插件都有，此处如果有各类脑洞插件、实用性插件，经过审核人员评定后可以给予加成分数。 对于新爆发的漏洞，在爆发时间后短时间内提交且审核通过的插件，可获得紧急响应奖励。