> ## 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. # 常见问题 ## 一、如何衡量匹配内容多与匹配内容精确的关系？（plurality and accuracy） 这个问题在某些漏洞之中可能非常常见。有的时候通过漏洞返回的页面信息非常丰富，我们能够从中选取非常多的信息填写到我们的条件表达式中；但是有时候有的漏洞返回的内容却寥寥无几，可能还是不相关的其他信息。这些情况无论是在漏洞审核还是漏洞编写中都是棘手的存在 > 对于反连平台的匹配内容这里不做说明，只要明确了漏洞只能通过反连平台进行检测，且能够写出相关的利用方式，那么我们直接使用反连平台进行匹配即可，基本不会出现漏报和误报的现象 > 同时关于常见的概念，这里暂且定义为一般在网站中会经常出现的内容。这些内容在系统的开发过程中被广泛使用 这个问题在现在的审核方式中，一般会按照以下的内容进行判断 * 在表达式中尽量不出现`常见`的匹配内容，例如user，passwd等常见字符串。但是如果这些内容是漏洞的一部分，可以保留，但是一定要增加匹配站点中其他的信息 * 表达式的编写可以广撒网，但是匹配的内容一定至少有一项是和不发生漏洞时的站点产生的内容相互斥的信息 * 同时精确的内容匹配也不完全是好事，过于精确的匹配可能会导致在一些过于自定义化的站点中发生漏报的问题。那么我们完全需要精确匹配的内容就只能限定到两项上，一个是我们输入的经过处理后的内容；另一项就是无论如何改，站点中一定会出现的特征内容，比如该框架的css/js名称，特殊的厂商信息等等 ## 二、真的需要强随机化吗？（Enhanced randomisation） 随机化的问题在poc的编写过程中一直存在，有的时候我们能随心所欲地给各种我们想验证的内容给出随机的内容，但有的时候因为系统的各种限制，导致我们不是很方便地写出随机化的内容 一般来说，我们设置随机化的内容是为了达成以下的目的： * 访问随机化的内容，避免因为系统先前的状态（存在已上传的同名文件，各种缓存，一些页面中各种想象不到的神奇内容等）而造成的直接命中 * 尽可能地减少蜜罐等安全设备的影响 * 希望路径对于普通人来说更难获得访问路径，尽可能地减少对目标系统的影响，防止他人的恶意利用 所以这里需要明确的就是，**在能够找到随机化的利用方法时，`一定一定`要按照规范去编写poc的内容**，这样我们才能够认为这是一个较高质量的poc，反之可以直接pass 同时对于那些写不出来随机化内容的poc，现在大概有两种处理方法 * 等待go poc，使用完整语言的能力去验证漏洞的存在（推荐） * 在尽可能减少发包的情况下，增加匹配只有漏洞系统才存在的特殊规则，保证前置规则尽可能地强 综上，随机化也许并不是必须的，但是一定是需要我们在不同系统中寻求匹配方法时时刻注意的 ## 三、使用网页特征和实际利用方法去验证，我需要去选择哪一种？（Feature Match） 首先比较下两者的优缺点 | 方法 | 优点 | 缺点 | | :------- | :---------------------------------------- | :---------------------------------------------- | | 使用网页特征匹配 | 简单便捷，发包量低，基本只要发一个包就能确定是不是漏洞版本 | 可能会因为实际的网络环境，难以对漏洞进行利用，或者在一些特征变更不明显的系统中，发生误报的问题 | | 使用实际利用方法 | 准确，只要验证成功且匹配规则无问题，就能够说明目标系统绝大多数情况下都是存在漏洞的 | 相比特征匹配来说，可能需要寻求更加严谨的利用方式，且返回的结果可能会受安全设备的影响 | 两种各有千秋，并不好直接说某一种就是我们的最优解，这是需要我们依据漏洞的类型与利用的难易程度进行衡量，选择对于当前漏洞的最优解，达到`尽可能地减少发包量，同时尽可能地减少误报程度`的目的。当然这些内容并不是强求的 但是依据以往情况下审核过后的结果，我们大致可以分为这么几种情况 #### 1. 漏洞有可验证的利用方式，且漏洞无危害，发生漏洞时站点无明显特征 此种情况最为简单，即然能够验证漏洞，且漏洞无危害，那么直接使用漏洞原理显然是最为稳妥的方式。只要expression编写恰当，就能形成一个相对节省资源且稳定的poc #### 2. 漏洞有可验证的利用方式，且漏洞无危害，发生漏洞时站点有明显特征 和上边一种情况类似，我们也可以选择使用原理去进行检查。但是这种情况下，如果能够确认我们所寻找出的是唯一的，是能够取缔掉后边的原理检查的，那么我们也可以使用这些内容去直接匹配 #### 3. 漏洞有可验证的利用方式，但是难以利用，且漏洞无危害，发生漏洞时站点有明显特征 这种情况和上一种情况相似，参考上一种情况的要求写出特征内容的匹配即可 #### 4. 漏洞有可验证的利用方式，但是难以利用，且漏洞无危害，但无法确定漏洞站点有无特征 这种情况下首先推荐保留现有的内容，直接挂起，等待xray2.0发布完整的go插件系统后，再用完整的语言内容去进行实现 #### 5. 漏洞有可验证的利用方式，但漏洞有危害，且无法确定漏洞站点有无特征 那么这种情况下，直接使用原理去验证貌似并不是我们的最优解。这种情况下，我们就需要尝试去寻找网页特征(版本或者其他信息)以及指纹去侧方位地去验证目标系统是可能存在漏洞的 但是这里我们就要求寻找的特征一定是漏洞发生时才能够存在的，例如 * 判断版本区间时一定要注意目标系统有无补丁的存在。如果无，那么正常进行版本匹配即可；如果有，那么就需要放弃这条内容，寻找其他信息 * 使用网页内容去进行匹配时，尽可能地对所有可能出现的情况进行判断，尽可能地减小漏报的范围 * ... #### 示例 ```yaml theme={null} name: poc-yaml-test-test transport: http rules: r0: request: method: GET path: /aaa.aspx?PicID=0 follow_redirects: false expression: >- response.status == 200 && response.body.bcontains(b'ioffice.js') && (response.body.bcontains(b'ctl00_cntForm_cmdUpFile') || response.body.bcontains(b'ctl00$cntForm$cmdUpFile') || response.body.bcontains(b'ctl00_cntForm_lblEmpPhotoEx')) expression: r0() detail: author: chaitin ``` 例如这个poc的内容就符合上述内容中情况3，也就是有有利用方式，但是能够使用非常明显的特征去进行匹配。而且后边所匹配的cntForm等内容覆盖了现有框架内能出现的所有情况，同时这些内容也是只有漏洞版本所会出现的 那么通过上边的判断，我们可以认为这个poc的内容是可以取代实际的原理去验证漏洞的存在的 ## 四、如果目标漏洞是登录后才能够进行利用的，能给出相关cookie进行验证吗 首先对于这个问题，这里的回答是不能。对于这个问题大概有以下的解答 * 如果提供了个人的cookie等验证内容去辅助验证，在这个poc被收录且共用的时候，很大概率上会有信息泄露的风险 * 同时个人所提供的身份验证内容如果并不是管理员等通用内容，很大概率上只能在一定范围的系统中有效，并不具有通用性 * 且一定程度上会增加发包的数量，当扫描的量级变大时，这些基本无用的内容会占用很多资源 * ... 虽然说我们并不收取拥有固定用户认证凭证的内容，但是以下几种情况仍然在我们的收录范围之内 * 对于能够注册随机账号的情况，可以选择注册随机账号后再去验证漏洞的存在，同时在验证完成后删除产生的这些内容 * 如果给出的认证凭证是用户无关的，同时能够直接获取到系统中的某些权限，那么这种情况也是能够进行提交的 #### 当目标不出网的时候，我们大致应该如何去进行匹配（offline） 从现在poc的提交情况来看处于内网，不能访问外部环境的poc基本没有，但是我们仍然需要考虑这种情况的存在，毕竟在扫描的过程中这种情况也是非常常见的 那么按照现在的经验，这里大概可以分为三个步骤去进行排查 1. 目标不出网，但是漏洞是有回显的，能展示各种漏洞下的执行结果 那这个情况属于是最为简单的情况，我们只需要正常写出poc内容匹配漏洞产生的结果即可 2. 目标不出网，同时漏洞无回显，但是我们能够通过发生漏洞时的某一种特征去进行匹配 那虽然要多加注意，但是这里也是非常鼓励将无回显的漏洞转换为有特征输出的漏洞去进行匹配，在一定程度上平衡漏洞检出和漏洞误报之间的关系 3. 目标不出网，且发生漏洞时目标站点返回的信息极为简单，基本没有有效信息的时候 那么如果到了这个阶段，我们才能够考虑使用相关的版本特征等去进行匹配，尽可能地锁紧条件，减少误报的几率