Shulou(Shulou.com)05/31 Report--

The editor today takes you to understand the example analysis of XML external entity injection vulnerabilities, which are introduced in great detail in this article. Friends who feel helpful can browse the content of the article together with the editor, hoping to help more friends who want to solve this problem to find the answer to the problem. Let's go deep into the knowledge of "sample analysis of XML external entity injection vulnerabilities" with the editor.

I. XML external entity injection

XML external entity injection vulnerabilities are often referred to as XXE vulnerabilities. As a widely used data transfer format, many applications contain code to process xml data. By default, many outdated or improperly configured XML processors refer to external entities.

If an attacker can upload an XML document or add malicious content to an XML document, he can attack a XML processor that contains a flaw through vulnerable code, dependencies, or integrations. The emergence of XXE vulnerabilities has nothing to do with the development language. As long as the xml data is parsed in the application, and the data is controlled by the user, the application may be attacked by XXE. This article takes the java program as an example to introduce the causes and repair of XXE vulnerabilities. For more information on XXE vulnerabilities, please see CWE-611: Improper Restriction of XML External Entity Reference ('XXE') (http://cwe.mitre.org/data/definitions/611.html).

II. XML external entity injection

XXE vulnerabilities can be used to extract data, execute remote server requests, scan internal systems, perform denial of service attacks, and other attacks. The business impact depends largely on the affected referrals and data protection requirements.

Since 2018, CVE has released a total of 92 vulnerability messages related to it. Some of the CVE are as follows:

CVE-2018-8027Apache Camel 2.20.0 to 2.20.3 and 2.21.0 Core contain a XXE vulnerability in the XSD authentication processor. A XXE vulnerability exists in the WXPayUtil class in CVE-2018-13439 WeChat Pay Java SDK. CVE-2018-1000548 in Umlet with version number less than 14.3, there is a XML external entity injection vulnerability in file parsing, which may lead to confidential data disclosure, denial of service, and server-side request forgery. This attack can be carried out through a specially crafted UXF file. CVE-2018-1364

IBM Content Bavigator 2.0 and 3. 0 are vulnerable to XML external entities (XXE) attacks when processing XML data. Remote attackers can exploit this vulnerability to expose sensitive information or consume memory resources. Sample code 3.1 defect code

This section uses the sample code source for an open source payment Java SDK (https://pay.weixin.qq.com/wiki/doc/api/jsapi.php?chapter=11_1), source file name: WXPayUtil.java, file path is: java-sdk-v3\ src\ main\ java\ com\ github\ wxpay\ sdk.

In the above code, you can see that the data is passed in through the xmlToMap parameter at 25 lines, the data is not filtered, and the XML processor parses the data at 32 lines without security settings. In the actual scenario, the parameter strXML is also controlled by the attacker, so the attacker may carry out XXE attacks by constructing malicious strXML.

Using the 360Code Guardian to detect the above sample code, you can detect a "risky XML external entity injection" defect in line 32 of the file. As shown in figure 1:

Figure 1 detects risky XML external entity injection

3.2 fix the code

Line 28 in the above fix code uses a xml utility class, WXPayXmlUtil, to generate a secure xml processor. The most important thing in the WXPayXmlUtil class is line 16, which causes the generated xml processor to disable DTDS completely through setFeature. As you can see from figure 2, the 360 Code Guardian did not detect defects in the repaired code.

Figure 2 example of XXE vulnerability repair

Fourth, how to avoid XXE loopholes

Common ways to avoid:

1. Use simple data formats (such as JSON) as much as possible to avoid serializing sensitive data

two。 Fix or update all XML processors and libraries used by the application or underlying operating system in a timely manner. At the same time, update SOAP to version 1.2 or later through dependency detection

3. Disable XML external entities and DTD processes in all XML parsers of the application. For specific implementation, please refer to "OWASP Cheat Sheet 'XXE Prevention'" (https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet))

The following code is an example of protecting against XXE vulnerabilities when using DocumentBuilderFactory to parse xml in a java application:

4. Input validation: use whitelists for input validation and filtering on the server side to prevent malicious data in XML documents, headers, or nodes.

5. Verify that the XML and XSL file upload functions use XSD verification or other similar verification methods to verify uploaded XML files

6. The DAST tool requires additional manual steps to detect and exploit XXE vulnerabilities, while using the ASAT tool can discover XXE vulnerabilities by detecting dependencies and security configurations.

Thank you for your reading. The above is the whole content of "sample Analysis of XML external entity injection vulnerabilities". Friends who learn to learn to do it quickly. I believe that the editor will certainly bring you better quality articles. Thank you for your support to the website!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.