防止恶意代码通过自定义类加载器注入，关键在于控制行为边界、切断危险路径并全流程嵌入验证：禁用URLClassLoader、白名单限制字节码来源、签名校验、敏感包名拦截、defineClass前钩子检查、JVM TI监控、模块化隔离及禁用高危反射。
防止恶意代码通过自定义类加载器注入，关键不是禁止自定义加载器本身，而是控制它的行为边界、切断危险路径，并在类加载全流程中嵌入验证与拦截点。
严格限制字节码来源与校验机制
自定义类加载器最常被利用的环节是 findClass() 中对原始字节码的加载。攻击者可能从网络、临时目录或内存中拉取未经签名的恶意 class 数据。
- 禁止使用 URLClassLoader 加载远程 JAR 或 class 文件；若必须支持动态加载，只允许从白名单本地路径（如
/opt/app/plugins/）读取，且路径需硬编码或由启动参数安全传入 - 对加载的字节码做基础校验：检查魔数是否为
0xCAFEBABE，版本号是否在允许范围内（如 Java 17–21），避免畸形或过时字节码绕过验证 - 引入强签名机制：要求所有外部类必须附带 JAR 签名或单独的 .sig 文件，加载前用预置公钥验证签名有效性；可结合
java.security.CodeSource在 defineClass 前做权限比对
破坏双亲委派时必须保留核心类隔离
很多攻击依赖绕过双亲委派（例如用线程上下文类加载器加载伪造的 java.lang.System），因此要守住“不可替代”的底线。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 重写 loadClass(String name, boolean resolve) 时，对
java.*、javax.*、sun.*、jdk.*等敏感包名直接抛出SecurityException，不交由父加载器也不自行加载 - 若业务必须打破委派（如 JDBC 驱动），仅允许特定已知类名（如
com.mysql.cj.jdbc.Driver）走反向路径，其余一律拦截 - 在 defineClass 调用前插入钩子，调用
getPackage()检查目标类是否试图伪装成系统包——JVM 不允许用户定义的类出现在java.lang包下，但早期漏洞曾被用于伪造
运行时主动监控与沙箱加固
防御不能只靠静态约束，还要在 JVM 运行期持续感知异常加载行为。
立即学习“Java免费学习笔记（深入）”；
- 启用安全管理器（
SecurityManager已弃用但部分老系统仍用），或改用 JVM 启动参数-Djava.security.manager+ 自定义策略文件，限制RuntimePermission("createClassLoader")和RuntimePermission("getClassLoader") - 利用 JVM TI 或 Java Agent 注入检测逻辑：监听
ClassFileLoadHook事件，对非系统类加载器加载的类记录来源、堆栈、字节码哈希；发现来自tmp目录或 HTTP URL 的加载请求立即阻断并告警 - 配合模块化（Java 9+）：将应用划分为明确的 named module，设置
opens和exports白名单，阻止反射突破封装；模块系统天然拒绝未声明依赖的类加载尝试
禁用高危反射与动态能力
很多内存马依赖反射修改类加载器链或绕过验证，需从源头削弱这类能力。
- 在启动时通过
--illegal-access=deny关闭非法反射访问；对必要反射调用，使用setAccessible(false)并捕获InaccessibleObjectException - 移除或重命名
java.lang.ClassLoader.defineClass的敏感重载（如接收 byte[] 的版本），改用封装后的安全接口，内部自动加签/校验 - 禁止运行时修改线程上下文类加载器（
Thread.setContextClassLoader），可在基类或 agent 中 hook 该方法并抛出异常
