【BurpSuite 插件开发】实战篇（十）权限测试集成配置规则

前言

继上一章我们实现了规则配置的界面，本文就将聚焦“配置规则判断”功能是如何实现。

最终效果如下，文章结尾查看完整代码。

一、配置规则判断逻辑：核心判断标准

在使用“配置规则”功能时，工具会根据测试请求的响应结果，按照以下3条核心规则判断测试结论。这部分是整个功能的“灵魂”，所有代码都是围绕这3条规则展开的。

1.1 规则匹配成功：判定为“可防御”

当测试响应满足用户配置的所有（或任意，取决于逻辑关系）规则时，说明系统按照预期拦截了越权请求，此时判定为“可防御”（DEFENDED）。

举个例子：
假设用户配置规则为“响应状态码等于403”，且逻辑关系为“AND”（因为只有一条规则，所以无需考虑多规则关系）。如果测试响应的状态码是403，则规则匹配成功，结论为“可防御”——意味着系统正确拒绝了越权请求。

1.2 规则匹配失败，且响应体与原始请求相同：判定为“被绕过”

当测试响应不满足配置的规则（规则匹配失败），但测试响应的内容和“原始请求”的响应完全一致时，说明越权请求成功执行（系统没有拦截），此时判定为“被绕过”（BYPASSED）。

这里的“原始请求”指的是“正常权限请求”的响应（比如管理员发送的合法请求）。

举个例子：
用户配置规则为“响应体包含‘无权访问’”，测试响应的响应体是“操作成功”（不满足规则，匹配失败），而原始请求的响应体也是“操作成功”。这说明低权限用户成功执行了管理员操作，系统被绕过了。

1.3 规则匹配失败，且响应体与原始请求不同：判定为“待确定”

当测试响应不满足配置的规则（匹配失败），且响应内容和原始请求的响应不一样时，情况就比较复杂了——可能是系统的防御机制不符合预期规则，也可能是存在其他未知情况，此时判定为“待确定”（POTENTIALLY_BYPASSED），需要人工进一步检查。

举个例子：
用户配置规则为“响应状态码等于403”，测试响应的状态码是500（不满足规则，匹配失败），而原始请求的状态码是200。此时无法直接判定系统是否被绕过（可能是越权导致系统报错，也可能是其他原因），所以需要人工确认。

章节总结

本章节介绍了配置规则判断的3条核心逻辑，它们是工具判断测试结果的“标准”：

• 规则匹配成功 → 可防御；
• 规则匹配失败 + 响应体与原始相同 → 被绕过；
• 规则匹配失败 + 响应体与原始不同 → 待确定。
  这3条逻辑看似简单，却是后续代码实现的核心依据，所有功能都是为了准确应用这3条规则。

二、功能实现流程：从用户操作到结果展示

了解了判断逻辑后，我们再来看这个功能是如何被用户使用的。简单来说，整个流程可以分为4步，从用户操作到工具输出结果，环环相扣。

2.1 开启功能：用户勾选“使用配置规则”

首先，用户需要在工具的界面上勾选“使用配置规则”复选框——这一步是告诉工具：“我要使用自己定义的规则来判断结果，而不是工具默认的规则”。

2.2 配置规则：输入规则列表和逻辑关系

接下来，用户需要配置具体的规则：

• 规则列表：可以添加多条规则，比如“响应状态码等于403”“响应体包含‘无权访问’”等；
• 逻辑关系：当有多个规则时，需要指定规则之间是“AND”（所有规则都满足才生效）还是“OR”（任意一条规则满足就生效）。

比如，用户可以配置两条规则：“状态码等于403”和“响应体包含‘无权访问’”，并选择逻辑关系为“AND”——这意味着只有同时满足这两条规则，才会判定为“可防御”。

2.3 执行测试：点击“开始测试”按钮

配置完成后，用户点击“开始测试”按钮，工具会自动向目标系统发送测试请求（比如低权限用户请求、未授权请求），并获取测试响应结果。

2.4 展示结果：表格中标识结果和颜色

工具根据前面提到的3条判断逻辑，对测试响应进行分析，最终在结果表格中显示结论（“可防御”“被绕过”“待确定”），并通过不同颜色区分（比如绿色表示可防御，红色表示被绕过，黄色表示待确定）。

章节总结

本章节梳理了功能的完整使用流程：用户开启功能→配置规则→执行测试→查看结果。这个流程清晰地展示了“用户操作”与“工具处理”的对应关系——用户的每一步操作（勾选复选框、配置规则、点击按钮）都会触发工具的特定处理，最终通过表格呈现结果。接下来的代码实现，就是将这个流程转化为计算机能理解的指令。

三、核心代码实现：如何让工具“理解”规则

前面介绍了“是什么”和“怎么做”，接下来我们深入代码层面，看看工具是如何实现这些功能的。这部分代码主要用Java编写，我们会避开复杂的语法，重点解释代码的作用和逻辑。

3.1 规则工具类：实现规则判断的“大脑”

RuleUtil是整个功能的核心工具类，它就像一个“大脑”，负责执行所有规则判断的逻辑。我们逐部分来看它的代码。

3.1.1 类的基本信息和常量

package utils;

import burp.api.montoya.http.message.responses.HttpResponse;
import java.util.List;
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.TimeoutException;
import java.util.regex.Pattern;
import java.util.regex.PatternSyntaxException;

import static utils.PermissionTestUtil.evaluateTestResult;

public class RuleUtil {
    // 设置正则表达式匹配的超时时间（毫秒）
    private static final int REGEX_TIMEOUT = 3000;

    // 创建一个单线程的执行器服务用于正则表达式匹配
    private static final ExecutorService regexExecutor = Executors.newSingleThreadExecutor();
    // ... 其他方法
}

代码解析：

• 这里定义了两个重要的“常量”：
  • REGEX_TIMEOUT = 3000：正则表达式匹配的超时时间（3秒）。为什么需要超时？因为有些复杂的正则表达式可能会“卡死”程序（比如恶意构造的正则），设置超时可以避免工具无响应。
  • regexExecutor：一个“单线程执行器”，简单理解就是一个“专门处理正则匹配的工作人员”，确保正则匹配在单独的线程中执行，不会影响工具的其他功能。

3.1.2 核心方法：（根据规则判断结果）

这个方法是RuleUtil的核心，它接收原始响应、测试响应、规则列表和逻辑关系，返回最终的判断结果（可防御、被绕过、待确定）。

public static PermissionTestUtil.TestResult evaluateTestResultWithRules(
    HttpResponse originalResponse,
    HttpResponse testResponse,
    List < RulePanel.Rule > rules,
    String logicRelation) {

    // 如果原始响应或测试响应为空，直接返回“待确定”
    if (originalResponse == null || testResponse == null) {
        return PermissionTestUtil.TestResult.POTENTIALLY_BYPASSED;
    }

    // 如果没有规则，则使用默认判断逻辑
    if (rules == null || rules.isEmpty()) {
        return evaluateTestResult(originalResponse, testResponse);
    }

    // 用于记录规则匹配结果（AND/OR逻辑）
    boolean allRulesMatched = true; // 假设所有规则都匹配（用于AND逻辑）
    boolean anyRuleMatched = false; // 假设没有规则匹配（用于OR逻辑）

    // 遍历每条规则，判断是否匹配
    for (RulePanel.Rule rule: rules) {
        boolean ruleMatched = evaluateRule(testResponse, rule);

        // 如果是AND逻辑：只要有一条规则不匹配，整体就不匹配
        if ("And".equalsIgnoreCase(logicRelation)) {
            if (!ruleMatched) {
                allRulesMatched = false;
                break; // 无需再检查其他规则，直接跳出循环
            }
        } else { // 如果是OR逻辑：只要有一条规则匹配，整体就匹配
            if (ruleMatched) {
                anyRuleMatched = true;
                // 可以继续检查其他规则，但这里不break也不影响结果
            }
        }
    }

    // 根据逻辑关系，确定所有规则是否整体匹配
    boolean rulesMatched = "And".equalsIgnoreCase(logicRelation) ? allRulesMatched : anyRuleMatched;

    // 根据规则匹配结果和响应内容，返回最终结论
    if (rulesMatched) {
        // 规则匹配成功 → 可防御
        return PermissionTestUtil.TestResult.DEFENDED;
    } else {
        // 规则匹配失败，需要对比响应体
        String originalBody = originalResponse.bodyToString();
        String testBody = testResponse.bodyToString();

        if (Objects.equals(originalBody, testBody)) {
            // 响应体相同 → 被绕过
            return PermissionTestUtil.TestResult.BYPASSED;
        } else {
            // 响应体不同 → 待确定
            return PermissionTestUtil.TestResult.POTENTIALLY_BYPASSED;
        }
    }
}

代码解析：
这个方法的逻辑完全对应我们前面讲的3条判断规则，我们一步步拆解：

1. 参数检查：如果原始响应或测试响应为空（比如请求失败），无法判断，直接返回“待确定”。
2. 无规则处理：如果用户没配置规则，就用工具默认的判断逻辑（evaluateTestResult方法，这里不展开）。
3. 规则匹配判断：
   • 定义两个变量：allRulesMatched（用于AND逻辑，初始假设所有规则都匹配）和anyRuleMatched（用于OR逻辑，初始假设没有规则匹配）。
   • 遍历每条规则，调用evaluateRule方法判断当前规则是否匹配测试响应。
   • 对于AND逻辑：只要有一条规则不匹配，就把allRulesMatched设为false，跳出循环（因为AND需要所有规则都满足）。
   • 对于OR逻辑：只要有一条规则匹配，就把anyRuleMatched设为true（即使后面有不匹配的规则，结果也不会变）。
4. 最终结论判断：
   • 如果规则整体匹配（rulesMatched为true），返回“可防御”。
   • 如果规则不匹配，对比原始响应和测试响应的内容：内容相同返回“被绕过”，不同返回“待确定”。

3.1.3 辅助方法：（判断单条规则是否匹配）

evaluateRule方法用于判断单条规则是否匹配测试响应，支持多种规则类型（状态码、响应头、响应体的字符串/正则匹配）。

private static boolean evaluateRule(HttpResponse response, RulePanel.Rule rule) {
    String ruleType = rule.getType(); // 规则类型（比如“状态码等于（数字）”）
    String ruleContent = rule.getContent(); // 规则内容（比如“403”）

    try {
        // 状态码等于（数字）
        if ("状态码等于（数字）".equals(ruleType)) {
            int statusCode = response.statusCode(); // 获取测试响应的状态码
            return Integer.toString(statusCode).equals(ruleContent.trim()); // 比较是否相等
        }
        // 状态码不等于（数字）
        else if ("状态码不等于（数字）".equals(ruleType)) {
            int statusCode = response.statusCode();
            return !Integer.toString(statusCode).equals(ruleContent.trim()); // 比较是否不相等
        }
        // 响应头包含（字符串）
        else if ("响应头包含（字符串）".equals(ruleType)) {
            String headers = response.headers().toString(); // 获取响应头字符串
            return headers.contains(ruleContent); // 判断是否包含目标字符串
        }
        // 响应头不包含（字符串）
        else if ("响应头不包含（字符串）".equals(ruleType)) {
            String headers = response.headers().toString();
            return !headers.contains(ruleContent); // 判断是否不包含目标字符串
        }
        // 响应头包含（正则）
        else if ("响应头包含（正则）".equals(ruleType)) {
            String headers = response.headers().toString();
            return safeRegexMatch(ruleContent, headers); // 用正则匹配响应头
        }
        // 响应头不包含（正则）
        else if ("响应头不包含（正则）".equals(ruleType)) {
            String headers = response.headers().toString();
            return !safeRegexMatch(ruleContent, headers); // 正则匹配不包含
        }
        // 响应体包含（字符串）
        else if ("响应体包含（字符串）".equals(ruleType)) {
            String body = response.bodyToString(); // 获取响应体字符串
            return body.contains(ruleContent); // 判断是否包含目标字符串
        }
        // 响应体不包含（字符串）
        else if ("响应体不包含（字符串）".equals(ruleType)) {
            String body = response.bodyToString();
            return !body.contains(ruleContent); // 判断是否不包含目标字符串
        }
        // 响应体包含（正则）
        else if ("响应体包含（正则）".equals(ruleType)) {
            String body = response.bodyToString();
            return safeRegexMatch(ruleContent, body); // 用正则匹配响应体
        }
        // 响应体不包含（正则）
        else if ("响应体不包含（正则）".equals(ruleType)) {
            String body = response.bodyToString();
            return !safeRegexMatch(ruleContent, body); // 正则匹配不包含
        }
    } catch (PatternSyntaxException e) {
        // 正则表达式语法错误（比如用户输入的正则不合法）
        return false;
    } catch (NumberFormatException e) {
        // 数字格式错误（比如状态码规则里填了非数字）
        return false;
    } catch (TimeoutException e) {
        // 正则匹配超时
        return false;
    } catch (Exception e) {
        // 其他未知错误
        return false;
    }

    // 未知的规则类型，返回false
    return false;
}

代码解析：
这个方法就像一个“规则检查器”，根据规则的类型（ruleType）和内容（ruleContent），对测试响应的状态码、响应头、响应体进行检查：

• 状态码相关：判断响应的状态码是否等于（或不等于）规则中填写的数字（比如规则是“状态码等于403”，就检查响应状态码是不是403）。
• 响应头/响应体字符串匹配：判断响应头或响应体中是否包含（或不包含）规则中填写的字符串（比如规则是“响应体包含‘无权访问’”，就检查响应体里有没有这四个字）。
• 响应头/响应体正则匹配：正则表达式是一种更灵活的匹配方式（比如规则“响应体包含正则error\d+”可以匹配“error123”“error456”等）。这里调用safeRegexMatch方法进行正则匹配，确保匹配过程不会超时。

另外，代码中用try-catch处理了各种可能的错误（比如正则语法错误、数字格式错误），避免因为用户输入错误导致工具崩溃，体现了代码的健壮性。

3.1.4 安全正则匹配：（防止正则卡死程序）

正则表达式虽然灵活，但如果写得不好（比如(a+)+这种容易导致“灾难性回溯”的正则），可能会占用大量时间和资源，甚至卡死程序。safeRegexMatch方法就是为了避免这种情况，给正则匹配加了超时控制。

private static boolean safeRegexMatch(String patternStr, String input) throws TimeoutException {
    // 编译正则表达式（把字符串形式的正则转换成可执行的“模式”）
    Pattern pattern = Pattern.compile(patternStr);

    // 定义一个“任务”：用正则匹配输入字符串
    Callable < Boolean > task = () -> pattern.matcher(input).find();

    // 把任务交给前面定义的“单线程执行器”执行
    Future < Boolean > future = regexExecutor.submit(task);

    try {
        // 等待任务执行结果，最多等REGEX_TIMEOUT（3秒）
        return future.get(REGEX_TIMEOUT, TimeUnit.MILLISECONDS);
    } catch (InterruptedException e) {
        // 任务被中断（比如程序关闭），恢复中断状态并抛出异常
        Thread.currentThread().interrupt();
        throw new RuntimeException("Regex matching interrupted", e);
    } catch (ExecutionException e) {
        // 任务执行出错（比如正则内部错误），抛出异常
        throw new RuntimeException("Regex matching execution error", e);
    } catch (TimeoutException e) {
        // 超时：取消任务并抛出超时异常
        future.cancel(true); // 取消任务，避免继续占用资源
        throw e;
    }
}

代码解析：
这个方法的核心是“超时控制”，步骤如下：

1. 把用户输入的正则字符串（patternStr）编译成可执行的正则模式（Pattern）。
2. 定义一个“任务”（Callable）：用这个正则模式去匹配输入的字符串（input，可能是响应头或响应体）。
3. 把任务交给regexExecutor（单线程执行器）执行，得到一个“未来结果”（Future）——可以理解为一个“结果容器”，任务执行完后会把结果放进去。
4. 调用future.get(3秒)：等待任务结果，但最多等3秒。如果3秒内完成，返回匹配结果；如果超时，就取消任务（future.cancel(true)）并抛出超时异常，避免程序被卡住。

3.1.5 资源释放：（关闭线程池）

当工具关闭时，需要释放资源，否则可能导致内存泄漏。shutdownRegexExecutor方法用于关闭处理正则匹配的线程池。

public static void shutdownRegexExecutor() {
    regexExecutor.shutdown(); // 通知线程池准备关闭，不再接收新任务
    try {
        // 等待5秒，让线程池里的任务完成
        if (!regexExecutor.awaitTermination(5, TimeUnit.SECONDS)) {
            regexExecutor.shutdownNow(); // 5秒后还没完成，强制关闭
        }
    } catch (InterruptedException e) {
        regexExecutor.shutdownNow(); // 关闭过程中被中断，强制关闭
        Thread.currentThread().interrupt();
    }
}

代码解析：

• shutdown()：告诉线程池“可以关闭了，不再接新任务，但正在执行的任务继续做完”。
• awaitTermination(5, TimeUnit.SECONDS)：等待5秒，看线程池是否能正常关闭。
• 如果5秒后还没关闭，调用shutdownNow()强制关闭，确保资源被释放。

3.2 插件面板：连接UI和逻辑的“桥梁”

PermissionTestPanel是工具的界面类，负责把用户的操作（比如勾选“使用配置规则”、输入规则）和RuleUtil的逻辑判断连接起来，最终在表格中显示结果。

以下是核心代码片段：

// 在EDT中更新UI（EDT是Java处理界面的线程，确保界面操作线程安全）
SwingUtilities.invokeLater(() -> {
    tableModel.setValueAt(length, index, 4); // 更新响应长度列

    // 如果未勾选"使用配置规则"，用默认逻辑判断
    HttpRequestResponse originalReqResp = requestResponseList.get(index);
    if (!useConfigRulesCheck.isSelected()) {
        if (originalReqResp != null && originalReqResp.response() != null) {
            PermissionTestUtil.updateTestResult(
                tableModel,
                index,
                originalReqResp.response(),
                modifiedRequestResponse.response(),
                6, // 低权限结果列（表格中第6列显示低权限测试结果）
                index < lowPrivilegeRenderers.size() ? lowPrivilegeRenderers.get(index) : null,
                updateRenderersRef
            );
        }
    } else {
        // 如果勾选了"使用配置规则"，用自定义规则判断
        if (originalReqResp != null && originalReqResp.response() != null) {
            // 获取用户选择的逻辑关系（AND/OR）
            String logicRelation = getLogicRelationFromRulePanel(lowPrivilegeRulePanel);

            PermissionTestUtil.updateTestResultWithRules(
                tableModel,
                index,
                originalReqResp.response(),
                modifiedRequestResponse.response(),
                6, // 低权限结果列
                index < lowPrivilegeRenderers.size() ? lowPrivilegeRenderers.get(index) : null,
                updateRenderersRef,
                lowPrivilegeRulePanel.getRules(), // 用户配置的规则列表
                logicRelation // 逻辑关系
            );
        }
    }
});

代码解析：
这段代码的作用是“根据用户是否勾选‘使用配置规则’，选择不同的判断逻辑，并更新表格结果”，可以分为3步：

1. 线程安全的UI更新：SwingUtilities.invokeLater确保代码在界面线程（EDT）中执行，避免界面卡顿或错乱。
2. 判断是否使用配置规则：
   • 如果未勾选（!useConfigRulesCheck.isSelected()），调用updateTestResult方法，用默认逻辑更新表格（低权限结果列，第6列）。
   • 如果勾选了，调用updateTestResultWithRules方法，用自定义规则更新表格。
3. 传递参数：调用updateTestResultWithRules时，需要传入用户配置的规则列表（lowPrivilegeRulePanel.getRules()）和逻辑关系（logicRelation），这些都是用户在界面上输入的内容。

类似地，代码中还有一段处理“未授权测试结果”的逻辑（表格第7列），和上面的低权限结果处理完全一致，只是操作的表格列和规则面板不同（unauthorizedRulePanel）。

3.3 获取逻辑关系

用户在界面上选择的逻辑关系（AND/OR）需要被传递给判断逻辑，getLogicRelationFromRulePanel方法就是用来获取这个关系的。

/**
 * 从规则面板中获取逻辑关系
 *
 * @param rulePanel 规则面板
 * @return 逻辑关系字符串 ("And" 或 "Or")
 */
private String getLogicRelationFromRulePanel(RulePanel rulePanel) {
    return rulePanel.getLogicRelation();
}

代码解析：
这是一个简单的“ getter 方法”，从规则面板（RulePanel）中获取用户选择的逻辑关系（“And”或“Or”），并返回给调用者（前面的PermissionTestPanel代码）。

3.4 工具类：封装通用操作

PermissionTestUtil是一个工具类，封装了一些通用操作，比如调用规则判断逻辑、更新表格结果等，避免代码重复。

3.4.1 调用规则判断逻辑

/**
 * 根据配置规则判断测试结果
 * 
 * @param originalResponse 原始响应
 * @param testResponse 测试响应
 * @param rules 规则列表
 * @param logicRelation 逻辑关系（AND/OR）
 * @return 测试结果枚举
 */
public static TestResult evaluateTestResultWithRules(HttpResponse originalResponse, HttpResponse testResponse,
    List < RulePanel.Rule > rules, String logicRelation) {
    return RuleUtil.evaluateTestResultWithRules(originalResponse, testResponse, rules, logicRelation);
}

代码解析：
这个方法是RuleUtil.evaluateTestResultWithRules的“包装器”，方便其他类（比如PermissionTestPanel）调用规则判断逻辑，不用直接依赖RuleUtil，体现了代码的“封装性”。

3.4.2 更新表格结果

/**
 * 更新测试结果到表格显示（支持规则）
 *
 * @param tableModel 表格模型
 * @param rowIndex 行索引
 * @param originalResponse 原始响应
 * @param testResponse 测试响应
 * @param resultColumnIndex 结果列索引
 * @param renderer 单元格渲染器（控制单元格颜色）
 * @param updateRenderers 更新渲染器的回调方法
 * @param rules 规则列表
 * @param logicRelation 逻辑关系
 */
public static void updateTestResultWithRules(DefaultTableModel tableModel,
    int rowIndex,
    HttpResponse originalResponse,
    HttpResponse testResponse,
    int resultColumnIndex,
    ColorTableCellRenderer renderer,
    Runnable updateRenderers,
    List < RulePanel.Rule > rules,
    String logicRelation) {
    if (originalResponse != null) {
        // 调用规则判断逻辑，得到结果
        TestResult result = evaluateTestResultWithRules(originalResponse, testResponse, rules, logicRelation);

        // 更新表格中的结果文字（比如“可防御”）
        tableModel.setValueAt(result.getText(), rowIndex, resultColumnIndex);

        // 更新单元格颜色（比如绿色表示可防御）
        if (renderer != null) {
            renderer.setBackgroundColor(result.getColor());
        }

        // 刷新表格显示，让结果立即可见
        if (updateRenderers != null) {
            updateRenderers.run();
        }
    }
}

代码解析：
这个方法负责把判断结果更新到表格中，是“逻辑结果”到“界面展示”的最后一步：

1. 调用evaluateTestResultWithRules得到判断结果（TestResult，包含文字和颜色信息）。
2. 用tableModel.setValueAt更新表格中对应行和列的文字（比如第6列的低权限结果）。
3. 用renderer.setBackgroundColor设置单元格颜色（让结果更直观）。
4. 调用updateRenderers.run()刷新表格，确保用户能立即看到更新后的结果。

3.4.3 关闭资源

/**
 * 关闭正则表达式执行器
 */
public static void shutdownRegexExecutor() {
    RuleUtil.shutdownRegexExecutor();
}

代码解析：
同样是RuleUtil.shutdownRegexExecutor的包装方法，方便其他类（比如插件入口类）调用，关闭正则匹配的线程池。

3.5 入口类：注册卸载监听器

当工具被卸载（关闭）时，需要确保资源被释放（比如关闭线程池）。入口类的代码负责注册一个“卸载监听器”，在工具关闭时执行资源释放操作。

// 注册插件卸载监听器：当插件被卸载时，调用permissionTestPanel的shutdown方法
montoyaApi.extension().registerUnloadingHandler(permissionTestPanel::shutdown);

代码解析：
registerUnloadingHandler是工具提供的一个接口，用于注册“卸载时执行的操作”。这里传入permissionTestPanel::shutdown，表示当工具关闭时，调用permissionTestPanel的shutdown方法——而shutdown方法内部会调用RuleUtil.shutdownRegexExecutor，关闭正则匹配的线程池，释放资源。

章节总结

本章节详细解析了核心代码的实现：

• RuleUtil是“大脑”，实现了规则判断的核心逻辑，包括多规则的AND/OR处理、单规则匹配（状态码、响应头、响应体）、安全的正则匹配（超时控制）等。
• PermissionTestPanel是“桥梁”，连接用户界面操作和逻辑判断，根据用户是否勾选“使用配置规则”选择不同的处理方式。
• PermissionTestUtil是“助手”，封装了通用操作（如结果判断、表格更新），简化代码调用。
• 入口类负责“收尾”，确保工具关闭时释放资源。

这些代码相互配合，最终实现了“用户配置规则→工具判断结果→界面展示”的完整功能。

四、整体总结

本文以插件功能的核心是“让用户自定义判断标准”：通过配置规则（状态码、响应头、响应体的匹配条件）和逻辑关系（AND/OR），工具可以根据测试响应是否满足规则，结合原始响应的对比，得出“可防御”“被绕过”或“待确定”的结论。

代码层面，通过RuleUtil实现规则判断的核心逻辑，PermissionTestPanel连接界面和逻辑，PermissionTestUtil封装通用操作，最终形成一个完整的功能闭环。其中，正则匹配的超时控制、资源的释放等细节，体现了代码的健壮性和安全性。

理解这个功能不仅能帮助我们更好地使用安全测试工具，还能让我们明白：在安全测试中，“灵活适配不同场景”是非常重要的——因为每个系统的防御机制都可能不同，固定的判断标准往往无法满足需求，而可配置的规则正是解决这一问题的关键。

本插件代码开源地址：Gitee代码仓