从最近的微信支付看XXE漏洞
先说下写这篇文章的初衷吧，最近微信支付java_sdk刚爆发了一次xxe漏洞，然后领导赶快用自家的静态代码审计工具做了审计（这里我就不报名字，本来可以帮公司推广下产品是很好的，但我怕本文过于基础会被各位大佬喷出翔来，到时候有辱“司”门就真是罪过罪过了）。
发现能成功找出漏洞点，如下图。
到目前本来是件极好的事情，但是发现使用自己规则修复后依然能扫描出漏洞，这就很能说明问题，于是老大让我对微信支付漏洞做漏洞研究并找出产品出问题的原因。所以才有了这篇文章。由于本文的初衷是为了改进产品，所以本文并不是为了深入研究xxe漏洞，更加适合开发人员看。
微信支付的sdk中提供了WXPayUtil这个工具类，该类中实现了xmltoMap和maptoXml这两个方法，而这次的微信支付的xxe漏洞爆发点就在xmltoMap方法中。
该方法是为了将xml格式的字符串strXML转化为map。由于strXML可由攻击者控制，且程序未作任何防护措施（如禁止引用外部实体；过滤关键字符串等），导致恶意攻击者可利用外部实体注入读取服务器上的文件。当攻击者获取支付加密所用的安全密匙后，完全可以实现0元支付商品。
这里先以微信sdk中的xmlToMap方法为例，复现该xxe漏洞。（由于要完整的实现微信零元支付，需要写比较完整的程序对接微信支付接口，比较耗时间，暂时先不做）。
出现问题的代码是：
DocumentBuilderFactory documentBuilderFactory = DocumentBuilderFactory.newInstance();
org.w3c.dom.Document doc = documentBuilder.parse(stream);
生成documentBuilderFactory后直接去解析流。
构造xml格式的字符串如下:
]>
methodcall>
methodname>&xxe;methodname>
methodcall>
这样mapToXml中DOM解析器解析该字符串时，会访问外部实体中的SYSTEM属性中标识的URL，并将读取的文件内容放入methodccall节点中。然后取出放入map中（实际场景中map中的值最后会被攻击者所获取，我们这里以在控制台输出为例），能成功读取系统文件。
一、完全禁用DTDs，生成documentBuilderFactory后对feature进行设置
documentBuilderFactory.setFeature(“http://apache.org/xml/features/disallow-doctype-decl“,true);
效果如下：
程序会报错，提示将该属性设为true。
二、生成documentBuilderFactory后对feature进行设置
documentBuilderFactory.setXIncludeAware(false); documentBuilderFactory.setExpandEntityReferences(false); documentBuilderFactory.setFeature("http://xml.org/sax/features/external-parameter-entities",false); documentBuilderFactory.setFeature("http://xml.org/sax/features/external-general-entities", false);
效果如下：
程序虽然不会报错，但是已经读取不出系统文件中的内容了。
三、对关键词做过滤，如ENTITY、 DOCTYPE
对以上三种防范方式做分析：推荐使用第一种，能处理掉绝大多数的xxe漏洞；当有需求不能全部禁用掉DTD时，使用第二种方法；不建议使用第三种方法，如果不然很容易被绕过，如使用ENTIENTITYTY等等情况来绕过。
微信支付sdk中使用的是原生的dom解析xml，接下里分别复现使用原生SAX解析xml、使用dom4j解析xml、使用jdom解析xml这三种实现方式的xxe漏洞以及修复方法（修复原理是一样的，方法都类似的，但为了方便之后产品规则的完善，这里全部列举出来）
使用原生SAX解析xml
问题在于生成SAXParserFactory后直接去解析xml了，修复方法添加属性
sf.setFeature(“http://apache.org/xml/features/disallow-doctype-decl“,true);
效果如下：
先说下写这篇文章的初衷吧，最近微信支付java_sdk刚爆发了一次xxe漏洞，然后领导赶快用自家的静态代码审计工具做了审计（这里我就不报名字，本来可以帮公司推广下产品是很好的，但我怕本文过于基础会被各位大佬喷出翔来，到时候有辱“司”门就真是罪过罪过了）。
发现能成功找出漏洞点，如下图。
到目前本来是件极好的事情，但是发现使用自己规则修复后依然能扫描出漏洞，这就很能说明问题，于是老大让我对微信支付漏洞做漏洞研究并找出产品出问题的原因。所以才有了这篇文章。由于本文的初衷是为了改进产品，所以本文并不是为了深入研究xxe漏洞，更加适合开发人员看。
微信支付的sdk中提供了WXPayUtil这个工具类，该类中实现了xmltoMap和maptoXml这两个方法，而这次的微信支付的xxe漏洞爆发点就在xmltoMap方法中。
本文来自无奈人生安全网
该方法是为了将xml格式的字符串strXML转化为map。由于strXML可由攻击者控制，且程序未作任何防护措施（如禁止引用外部实体；过滤关键字符串等），导致恶意攻击者可利用外部实体注入读取服务器上的文件。当攻击者获取支付加密所用的安全密匙后，完全可以实现0元支付商品。
这里先以微信sdk中的xmlToMap方法为例，复现该xxe漏洞。（由于要完整的实现微信零元支付，需要写比较完整的程序对接微信支付接口，比较耗时间，暂时先不做）。
出现问题的代码是：
DocumentBuilderFactory documentBuilderFactory = DocumentBuilderFactory.newInstance();
org.w3c.dom.Document doc = documentBuilder.parse(stream);
生成documentBuilderFactory后直接去解析流。
构造xml格式的字符串如下:
]>
methodcall>
methodname>&xxe;methodname>
methodcall>
这样mapToXml中DOM解析器解析该字符串时，会访问外部实体中的SYSTEM属性中标识的URL，并将读取的文件内容放入methodccall节点中。然后取出放入map中（实际场景中map中的值最后会被攻击者所获取，我们这里以在控制台输出为例），能成功读取系统文件。
一、完全禁用DTDs，生成documentBuilderFactory后对feature进行设置
documentBuilderFactory.setFeature(“http://apache.org/xml/features/disallow-doctype-decl“,true);
效果如下：
程序会报错，提示将该属性设为true。
二、生成documentBuilderFactory后对feature进行设置
documentBuilderFactory.setXIncludeAware(false); documentBuilderFactory.setExpandEntityReferences(false); documentBuilderFactory.setFeature("http://xml.org/sax/features/external-parameter-entities",false); documentBuilderFactory.setFeature("http://xml.org/sax/features/external-general-entities", false);
效果如下：
程序虽然不会报错，但是已经读取不出系统文件中的内容了。
三、对关键词做过滤，如ENTITY、 DOCTYPE
对以上三种防范方式做分析：推荐使用第一种，能处理掉绝大多数的xxe漏洞；当有需求不能全部禁用掉DTD时，使用第二种方法；不建议使用第三种方法，如果不然很容易被绕过，如使用ENTIENTITYTY等等情况来绕过。
微信支付sdk中使用的是原生的dom解析xml，接下里分别复现使用原生SAX解析xml、使用dom4j解析xml、使用jdom解析xml这三种实现方式的xxe漏洞以及修复方法（修复原理是一样的，方法都类似的，但为了方便之后产品规则的完善，这里全部列举出来）
使用原生SAX解析xml
问题在于生成SAXParserFactory后直接去解析xml了，修复方法添加属性
sf.setFeature(“http://apache.org/xml/features/disallow-doctype-decl“,true);
效果如下：
本文来自无奈人生安全网