捕获 saxparseexception 是验证 xxe 防护是否生效的关键手段，需在调试或测试中用 try-catch 检查异常类型及含“disallowed”消息，而非用于生产异常处理。
捕获 SAXParseException 本身不是防御手段，而是验证防护是否生效的关键信号。它不用于“处理”XXE攻击，而用于确认禁用 DOCTYPE 的配置已真实起效——当恶意 XML 包含 ..> 时，解析器应明确拒绝并抛出该异常。
为什么必须捕获 SAXParseException？
仅设置安全特性（如 disallow-doctype-decl）后不校验结果，等于没设。JDK 版本差异、Xerces 实现兼容性、IDE 运行环境（如 IDEA 默认用嵌入 JRE）都可能导致配置静默失效。而 SAXParseException 是唯一能直接反映“DTD 被拦截”的可观察行为。
- 抛出信息含
"DOCTYPE is disallowed"→ 配置成功，攻击被阻断 - 静默返回空文档、或报
FileNotFoundException（如尝试读取file:///etc/passwd）→ 防护未生效，存在绕过 - 无异常但外连发生（如 DNSLog 收到请求）→ 特性设置遗漏或顺序错误
如何正确捕获并用于验证？
在本地调试或单元测试中，对解析逻辑包裹 try-catch，重点检查异常类型和消息内容：
- 必须用
catch (SAXParseException e)，不能只捕获通用Exception - 打印或断言
e.getMessage()是否包含"disallowed"或"DOCTYPE"关键字 - 配合恶意样本测试：构造含
]>的 XML 字符串
常见误判场景与规避方式
不是所有 SAXParseException 都代表 XXE 防护成功；需排除语法类误报：
- 标签未闭合、编码错误、非法字符等也会触发该异常 → 应先用合法 XML（如仅含根元素的最小文档）做基线测试
- 若同一段代码在 IDE 中抛异常，但打包后运行不抛 → 检查生产环境 JDK 版本（OpenJDK 17+ 才完全支持
disallow-doctype-decl，Java 8u191 前有绕过漏洞） - 使用 Spring 或 Tomcat 容器时，工厂实例可能被容器重置 → 每次创建
SAXParser前都需重新调用setFeature，不可依赖单例配置
捕获之后不该做什么？
不要在生产代码中用 catch 吞掉异常并继续解析——这会掩盖真实问题，且无法阻止已加载的恶意实体。捕获仅用于调试验证；上线前应确保配置 100% 生效，运行时不应再出现此类异常。
- 避免写
catch (SAXParseException e) { log.warn("忽略XXE校验异常"); return null; } - 不要用异常流控代替配置检查，例如“没抛异常就认为安全”
- 不建议将捕获逻辑放入业务主流程，应分离至独立的校验模块或测试用例中
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
