XXE

XML 外部实体处理可能让解析器按照文档提供的引用，使用应用自身的权限获取资源。具体解析器及配置不同，结果可能是读取文件，也可能是向其他服务发起请求。支持 XML 不等于必然存在漏洞；需要先识别真正使用的库、已启用功能、资源解析器和后续处理步骤，才能判断输入究竟能够触发什么操作。 外部访问与内部展开不是一回事 外部解析实体可以用系统标识符指向资源。应用启用解析、进程又有能力访问时，读取文档便可能加载它。把内容反射到响应中只是泄露的一种形式；即使响应没有带回资源，向外发出的请求本身仍可能产生影响。访问范围同时受到解析策略、文件权限、网络控制和目标服务认证的限制，并不是一个 URL 就能保证拿到任意内部秘密。 内部实体则可以完全在文档中展开，不需要文件或网络。在保护不足的解析器中，重复嵌套替换可能消耗大量资源，这与 XXE 是不同问题。一个有明确上限的一千字符示例，只证明发生了替换，不能证明现代解析器允许无限放大。实体递归引用自身不符合 XML 规则，受支持的实现还可能在内存耗尽之前就拒绝过度放大，不能把所有解析器都描述成必然陷入死循环。 在解析开始前确定政策 输入格式不需要 DTD 时，应使用解析器支持的策略或回调拒绝文档类型声明。同时按具体实现关闭不需要的外部普通实体、参数实体和外部子集。库与版本的默认行为不同，仅禁止网络访问可能仍允许读取本地文件；只做 schema 校验，也可能已经晚于危险的初次解析。应检查实际入口怎样构建解析器，而不是在配置文件中找到一个相似名字就认为已经完成防护。 确实需要外部资源时，只把明确批准的标识映射到受控资源。schema 导入、XInclude 与转换器要单独审阅，XXE 开关未必控制这些加载器。还要限制字节数、嵌套深度与资源消耗，并维护解析库版本。一个短包装函数不可能自动抵御全部畸形输入、压缩炸弹或后续处理风险，政策边界应如实写明。 坏掉的样子 只在原始字节中搜索 ASCII 的 DOCTYPE 拼写，可能漏掉 UTF-16 之类编码后的声明；简单文本搜索又会误杀包含该字样的普通注释。应让理解编码和语法的解析器识别结构，再在声明边界执行政策。成功拒绝一条熟悉攻击字符串，不等于覆盖了入口接受的所有编码，也不等于找到了所有可能读取资源的路径。 SVG 上传可能进入服务器端 XML 解析器或图像转换器。该环节的配置决定是否加载外部引用，不能因为文件是 SVG，就声称每种浏览器都会自动解析外部实体。应检查预览、导入以及后续重解析的每一环；第一个解析器安全，不会替第二个开启不同加载器的组件提供保护。测试对象应当是实际管线，而不是只看文件扩展名。 启用断言的原样 Expat 夹具支持有界解析行为，不证明外部资源访问、全部处理器与编码，也不保证通用安全。 快速验证 保存为 xxe_probe.py，使用受维护的 Python 3 执行 python3 xxe_probe.py。须启用断言，不使用 -O 或 PYTHONOPTIMIZE：优化模式会跳过 assert 内的参数实体设置调用和正例检查。实验采用 Expat 回调、固定内存字节与小规模限制，不配置打开文件或发起网络请求的资源加载回调。拒绝声明中的路径与域名只是测试输入，不会访问对应资源，也不会读取真实系统文件。 ...