On Mon, Sep 3, 2018 at 11:48 AM, Nadeeshani Pathirennehelage < [email protected]> wrote:
> Hi Indunil, > > On Mon, Sep 3, 2018 at 11:05 AM, Indunil Upeksha Rathnayake < > [email protected]> wrote: > >> Hi, >> >> This is to identify the best approach for unmarshalling an XML document >> to a java object, with proper prevention of XML injections. >> >> AFAIK, it would be better to use JAXB unmarshaller to unmarshall XML to >> java. Some other ways for unmarshalling would be as follows. >> >> - SAX - Involves more code and more complexity than JAXB and doens't >> provides random access like JAXB and DOM. >> - DOM - Uses the JAXP DOM approach which will required more code than >> any JAXB approach and memory usage is higher. >> >> >> When umarshalling a XML document, we need to prevent using the XMLs for >> variety of attacks such as file retrieval, server side request forgery, >> port scanning, or brute forcing. So that, in the parser, we need to prevent >> common XML Injections like XML Bomb and XXE attack. >> >> - XML Entity Expansion Injection (XML Bomb) - If the parser uses a >> DTD, an attacker might inject data that may adversely affect the XML >> parser >> during document processing. These adverse effects could include the parser >> crashing or accessing local files. >> >> >> - XML External Entity Injection (XXE attack) - This is a specific >> type of Server-side Request Forgery (SSRF) attack against an application >> that parses XML input, whereby an attacker is able to cause Denial of >> Service (DoS) and access local or remote files and services. This attack >> occurs when untrusted XML input containing a reference to an external >> entity. >> >> >> Since a JAXB Unmarshaller does not support any flags for disabling >> XXE/XML Bomb, it’s imperative to parse the untrusted XML through a >> configurable secure parser first, generate a source object as a result, and >> pass the source object to the Unmarshaller. >> > >> There are several commonly used XML parsers which can be used with JAXB >> unmarshaller. The default settings for most of those java XML parsers is to >> have XXE/XML Bomb enabled. To use these parsers safely, we have to >> explicitly disable XXE/XML Bomb in the parser. >> >> >> Following is an example of using "sampleXml" XML content into object type >> "A" using SAXParser with JAXB while enabling following preventions in >> parser level. >> >> - http://apache.org/xml/features/nonvalidating/load-external-dtd - To >> ignore the external DTDs (External Entities) completely. Disabling DTDs >> also makes the parser secure against denial of services (DOS) attacks such >> as Billion Laughs. >> >> >> - http://xml.org/sax/features/external-parameter-entities - Not to >> include external parameter entities or the external DTD subset. >> >> >> - http://xml.org/sax/features/external-general-entities - Not to >> include external general entities. >> >> >> - http://javax.xml.XMLConstants/feature/secure-processing - Instructs >> the implementation to process XML securely. This may set limits on XML >> constructs to avoid conditions such as denial of service attacks. >> >> >> *SAXParserFactory spf = SAXParserFactory.newInstance();* >> *spf.setNamespaceAware(true);* >> *spf.setXIncludeAware(false);* >> >> *try {* >> * spf.setFeature(Constants.SAX_FEATURE_PREFIX + >> Constants.EXTERNAL_GENERAL_ENTITIES_FEATURE, false);* >> * spf.setFeature(Constants.SAX_FEATURE_PREFIX + >> Constants.EXTERNAL_PARAMETER_ENTITIES_FEATURE, false);* >> * spf.setFeature(Constants.XERCES_FEATURE_PREFIX + >> Constants.LOAD_EXTERNAL_DTD_FEATURE, false);* >> * spf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);* >> *} catch (SAXException | ParserConfigurationException e) {* >> * log.error("Failed to load XML Processor Feature " + >> Constants.EXTERNAL_GENERAL_ENTITIES_FEATURE + " or " +* >> * Constants.EXTERNAL_PARAMETER_ENTITIES_FEATURE + " or " + >> Constants.LOAD_EXTERNAL_DTD_FEATURE +* >> * " or secure-processing.");* >> *}* >> >> *JAXBContext jc = JAXBContext.newInstance(A.class);* >> *UnmarshallerHandler unmarshallerHandler = >> jc.createUnmarshaller().getUnmarshallerHandler();* >> *SAXParser sp = spf.newSAXParser();* >> *XMLReader xr = sp.getXMLReader();* >> *xr.setContentHandler(unmarshallerHandler);* >> >> *ByteArrayInputStream inputStream = new >> ByteArrayInputStream(sampleXml.getBytes(StandardCharsets.UTF_8));* >> *InputSource inputSource = new InputSource(inputStream);* >> *xr.parse(inputSource);* >> *inputStream.close();* >> *return (A) unmarshallerHandler.getResult();* >> >> >> >> Is there any better approach for unmarshalling while preventing XML >> injections? >> > > To prevent this we can use the an *XMLStreamReader* that has the > *IS_SUPPORTING_EXTERNAL_ENTITIES* and/or *XMLInputFactory.SUPPORT_DTD* > properties set to false as well [1]. > > We discussed both of these approaches and decided that using > SAXParserFactory is better than using the XMLStreamReader since > XMLStreamReader approach is only set the security properties into that > particular StreamReader. So the approach that you have suggested is better > for unmarshalling. > > Other than XML Bomb and XXE attack, any other security measures that we >> need to consider? >> > > In our context, we only consider these issues in the unmarshalling > scenario. > @Nadeeshani: Thanks a lot for your feedback. > > Thank You, > Nadeeshani. > -- > Pathirennehelage Nadeeshani > Software Engineer | WSO2 Inc. > Platform Security Team > mobile : +94 716545223 > > -- Indunil Upeksha Rathnayake Senior Software Engineer | WSO2 Inc Email [email protected] Mobile 0772182255
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
