防止Java类加载器加载恶意类需构建多层拦截体系：从类来源（禁用URLClassLoader、白名单+签名校验）、加载行为（禁defineClass、拦截Unsafe、字节码检查）、运行时上下文（沙箱隔离、敏感对象清理、反序列化白名单）及主动监控（类加载追踪、非标加载器熔断、高危调用栈拦截）四维设防。
防止Java类加载器加载恶意类，关键不是堵住某一个入口，而是构建多层拦截体系——从类来源、加载行为、运行时上下文三个维度同步设防。
严格控制类加载来源与路径
恶意类往往来自外部不可信位置，必须从源头卡死：
- 禁用URLClassLoader直接加载远程或本地任意路径的JAR/CLASS文件；确需动态加载时，只允许从签名验证通过的白名单JAR中加载指定包名（如com.myapp.plugin.*）
- 对所有动态加载的类，校验其ProtectionDomain.getCodeSource()是否指向可信位置，且数字签名有效
- 在JVM启动参数中加入-Djava.security.manager启用安全管理器，并在策略文件中明确拒绝RuntimePermission "createClassLoader"
阻断自定义加载器的危险能力
攻击者常通过继承ClassLoader并重写findClass()或defineClass()绕过双亲委派，必须限制其核心能力：
- 禁止用户代码调用ClassLoader.defineClass()：在安全策略中拒绝RuntimePermission "defineClass"
- 拦截Unsafe.defineAnonymousClass等底层类定义接口，可通过JVM参数--illegal-access=deny或模块化隔离禁用
- 若使用Instrumentation，注册ClassFileTransformer，在transform()阶段对字节码做合法性检查（如是否存在Ljava/lang/Runtime;调用）
切断运行时敏感对象访问链
即使恶意类被加载，也要让它“有手没工具”：
立即学习“Java免费学习笔记（深入）”；
- 沙箱内不暴露Runtime.getRuntime()、System或ProcessBuilder实例；所有命令执行必须经由封装后的受控接口（如CommandExecutor.submit(cmd)）
- 对传入沙箱的任意对象递归扫描字段，清理或代理包装ClassLoader、Thread、System等敏感引用
- 重写ObjectInputStream.resolveClass()，强制校验反序列化类是否在白名单内（配合jdk.serialFilter双重防护）
运行时主动监控与熔断
静态策略可能被新型手法绕过，需叠加实时感知能力：
- 开启-XX:+TraceClassLoading，捕获异常加载行为（如非系统加载器加载java.lang.ProcessImpl）
- 定期遍历当前线程的上下文类加载器链，发现非标准加载器（如URLClassLoader）尝试加载敏感类时立即终止线程
- 在Runtime.exec()等高危方法入口埋点，结合调用栈分析：若上三层含defineClass或Unsafe.defineAnonymousClass，直接抛出SecurityException
