资源提交标准


特征标准

特征提交方式

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

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

特征格式标准

  1. 特征提交规范:
    1. 厂商名称:厂商的名称,如Adobe
    2. 应用名称:该应用的名称,可以包含中文。全称、简称均可,可搜索到的名称。如:Wordpress博客管理系统,不区分到版本
    3. 应用指纹名称:即插件里调用的时候的名称。如fingerprint.wordpress,应用指纹名对应的是wordpress 。
    4. 特征简介:简单介绍该应用的用途等信息。
    5. 指纹内容:详见主要内容
    6. 测试地址:至少提供2个可用的测试URL。越多越好,利于自动抓取分词特征的程序运行。
  2. 指纹内容 指纹是若干个(路径,特征文本)构成的元组(路径开头不带"/") 如:
    [
    ["robots.txt","wp-admin"],
    ["admin.php","wordpress"],
    ["css/main.css", "wp-nightmode"],
    ["theme/logo.png", "b99ebbec34e04c9726714dfc8735c38b"]
    ]
    
    指纹分为两类:
    文本类
    通常使用:
    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. 按照要求填写各项漏洞信息

漏洞格式标准

基本要求
  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. 如果执行出错:小错误顺手改掉。错误不宜修改的*标记等待修改,原因编写错误*
      
  4. 查看是否正常输出security_func的结果
    1. 如不输出、检查是否是本地测试环境
       1. 非本地测试环境:*标记等待修改、原因为不能验证*
       2. 本地测试环境:检查是否有截图,如无,*标记等待修改、原因为不能验证*
      
  5. 是否是通用漏洞
    1. 检查测试网站数量,如较多不同网站、且CMS为一般常见应用。则可认为是通用漏洞
    2. 如果只有一个测试网址,可询问编写者询问更多情况,或根据测试网站中的Powered by 、inurl等信息尝试搜索,根据搜索结果判断是否是通用。或访问相应CMS所属厂商查看信息。
    3. 对于不确定的,标记已初审。留言给编写者。
  6. 是否对目标造成威胁
    1. 检查是否符合插件运行标准。

插件提交标准

1.命名规范:

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

2.内容规范:

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

插件奖励标准

符合插件提交标准:插件基础评分为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:其他
    特殊加成
    因为各种各样的插件都有,此处如果有各类脑洞插件、实用性插件,经过审核人员评定后可以给予加成分数。 对于新爆发的漏洞,在爆发时间后短时间内提交且审核通过的插件,可获得紧急响应奖励。

results matching ""

    No results matching ""