这部分内容的填写也是我们需要具体关注的。虽然对于漏洞的识别来说它并没有任何的作用，但是一个规范良好的detail是方便双方的存在，同时，一些必要的信息输出也有利于使用者对漏洞后续的操作 detail在代码中的体现是一个结构体，并不是一个Map。一般来说，detail本身必须被声明，且内部需要我们进行填写的只有author与links两项 但如果有一些信息需要被输出的时候，就需要关注一下当前的插件有哪些内容需要被输出

​
完整字段（Full field）

detail:
  author: # 作者（个人主页）
  links:
    - # 参考链接
    - # 可以是多个链接
  warning: # 一些警告信息，也就是该poc可能会产生的问题，比如产生脏数据等
  description: # 对该poc/漏洞的描述
  fingerprint: # 当该插件为指纹插件时才需要填写，且一般会自动生成
    id: # 指纹库id，一般自动生成，可以不用填写
    name: # 通用名称，一般自动生成，可以不用填写
    version: '{{version}}' # 用来接收指纹插件匹配到的版本信息，一般直接用这样的固定格式即可，会自动将output中匹配到的内容渲染过来
    cpe: # 输出该指纹对应的产品的cpe，一般自动生成，可以不用填写
    xxxx: # 一些希望被输出的内容，输出时，xxxx就是字段名称，后面就是输出值
  vulnerability: # 当该插件为漏洞插件且需要输出一些内容时才需要填写，且一般会自动生成
    id: # 漏洞库id，一般自动生成，可以不用填写
    level: # 漏洞危害等级，一般自动根据漏洞信息生成，可以不用填写
    match: # 一些证明漏洞存在的信息，比如信息泄露泄露的一些敏感数据等
    xxxx: # 一些希望被输出的内容，输出时，xxxx就是字段名称，后面就是输出值

​
检测“用户注册”相关问题（Registration）

在检测漏洞的时候，可能会有注册用户然后利用的行为，或者验证一些任意用户注册漏洞的时候，我们要求，需要将创建的用户的用户名和密码输出，便于后续会脏数据的处理 此时就需要在vulnerability中添加额外的字段来记录这些内容，大概可以写成下述样例： 
detail:
  author: test
  links:
    - https://test.com
  vulnerability:
    user: '{{user}}'
    passwd: '{{passwd}}'
需要注意，因为username和password在内部是保留字段，如果使用这两个作为key，会出现一些冲突，所以建议使用样例中的字段进行输出

​
关于author

author就是作者的名称，一般来说这个内容是根据我们个人的意愿进行填写的，当私人使用时可以填写任何内容。但是当提交到平台且被收录后公用的时候，这个内容是会展示到我们的漏洞报告中去的(命令行界面中红色输出部分就有这些内容)，为了统一规范与避免推广滥用，我们要求
  • author中的名称必须是编写者本人的昵称，需要与提交站点上提交人相对应
  • 如果想补充个人链接，名称后可以使用()包裹个人的github等链接内容
links表明了该漏洞相关的信息，通过查阅这些链接中给出的信息后，我们能够对漏洞的利用手段以及触发条件有一个大致的了解
在一些漏洞的编写过程中，由于时间或保密性等原因，这些漏洞的细节内容并没有被公开，基本处于0信息的状态。那么对于这种类型的漏洞我们并不强求填写links内容，可以选择留空而不是填写一些无关紧要的内容，例如产品的官网等链接
那么在能填写links的poc中，我们一般有以下的要求
  • 链接需要是公共的，能够长时间进行访问的，不可以使用私人站点的链接进行填写
  • 不建议使用个人的一些博客链接进行填写，一方面考虑到个人隐私相关问题，另一方面一些个人博客的链接也是需要访问权限的
  • 不建议直接使用漏洞的详情页当作links进行填写，例如cve.mitre.org，cnvd.org.cn等
不强求一定需要填写过多的链接，只需要填写一些常见且表明了漏洞具体出处和利用手法的链接即可