> ## Documentation Index > Fetch the complete documentation index at: https://docs.xray.cool/llms.txt > Use this file to discover all available pages before exploring further. # 简述 > 这篇文章主要对日常审核中常见的一些情况进行了分析和梳理，如果仍有编写不完善的地方，欢迎各位师傅提出意见并进行补全 漏洞的发掘和识别是一个将漏洞利用过程中的点与点串联起来的过程。在这种串起来的过程中，我们摒弃掉不需要或者有危害的内容，并加以特征辅助识别，剩下的就是poc的核心内容 ## 关于高质量poc 我们考量一个POC是否优质，是否高质量，主要是参考以下的内容： * payload是否无害 * payload是否合理 1. 是否随机化 2. 是否已经是最精简的探测 * payload是否通用 * 对返回包的判断是否严谨 * 整体的请求是否符合逻辑 在这些内容中我们首要关注的便是**危害性**，然后借用[《漏洞检测的那些事儿》](https://paper.seebug.org/9/)中提到的三个编写标准“**随机性、确定性、通用性**”，便构成了高质量POC ### 危害性（Harmfulness） 对于一个POC，我们首先要看的就是有没有危害。 * 文件上传时，上传了shell并没有删除 * 文件上传覆盖了源文件 * 测试了任意文件删除漏洞 * 修改了用户密码 * 对数据库进行了数据的操作：添加，修改，删除 * ... ### 随机性（Stochasticity） PoC 中所涉及的关键变量或数据应该具有随机性，切勿使用固定的变量值生成 Payload，能够随机生成的尽量随机生成（如：上传文件的文件名，Alert 的字符串，MD5 值） **文件上传：** 例如上面的例子，其中的文件名称便没有随机化，且不说webshell的问题，如果是一个正常的文件上传，在文件名称固定的情况下，就有可能出现几种情况： 1. 文件名重复，上传失败，无法检测出漏洞，造成漏报 2. 文件名重复，上传成功，被重命名，无法获取到上传后的文件名称地址，无法检测出漏洞，造成漏报 3. 文件名重复，上传成功，覆盖测试目标的文件内容，造成危害 ### 确定性（Deterministic） PoC 中能通过测试返回的内容找到唯一确定的标识来说明该漏洞是否存在，并且这个标识需要有针对性，切勿使用过于模糊的条件去判断 1. 尽量不要仅使用单一条件来判断，比如只判断 response.status 或者 response.content\_type会造成误报 2. 不要使用容易变化的值来判断，比如 content length， 会造成漏报 3. 不要使用容易出现的值来判断, 比如 1. response.body\_string.contains("upload success") 会造成误报 2. 计算了一个空页面/空图片的md5值用于判断 4. 不要使用很常见的值来判断漏洞命中，比如“admin”、“root” 本着在保证准确性的前提下尽可能少发包的原则，切忌在第一个规则中的expression只使用一个`response.status == 200`这样的规则，这样基本等于会多发一个请求，理论上多少都应该有一些特征。 ### 通用性（Versatility） PoC 中所使用的 Payload 或包含的检测代码应兼顾各个环境或平台 测试命令执行、文件读取类漏洞，请考虑Linux和Windows下的情况，POC里不要执行类似id、uname、/etc/passwd等操作，否则可能不兼容Windows环境。同时id等命令返回的信息也比较弱。 ## 为什么需要高质量poc poc的内容主要影响的就是扫描的效果，其影响效果可以简单的看作：**漏报、误报、危害**。 对于poc来说，虽然说最后写入程序后我们就完全无需关心他们的格式是什么，程序只要发出正确的内容即可；但是我们的POC在加载到扫描器后，会遇到**非常多的目标**，所以如果不编写一个高质量的POC，就很容易出现上述我们所提到的情况 同时从普通poc优化到高质量poc的过程中时，我们大概会有以下内容的提升 * 能够更加精炼，准确地描述出漏洞的利用方式，便于我们日常过程中的总结与分析 * 提高匹配的精度，尽可能地减少误报漏报的数量 * 尽可能地提高执行时的效率，让poc的匹配速度和准确程度达到一个比较平衡的状态 * ... ## 如何筛选高质量poc 当提交者提交相关poc内容到对应站点后，就需要我们审核人员对这些内容进行审核，判断所给出的内容能否符合我们日常使用的标准 审核就是筛选编写优良的poc，同时对于那些并不是很符合我们的定义的poc提出修改建议的流程。通过提出合理的建议，让互相都能认识到哪些地方是我们所需要修改的，哪些地方是我们在之后的编写流程中所需要注意的，达到互相优化的目的 那么为了规范这个流程，我们制定了相关的规范，这些内容请参考后续章节中的内容