Re: [Dev] Unmarshalling with prevention of XML Injection

2018-09-03 Thread Indunil Upeksha Rathnayake
On Mon, Sep 3, 2018 at 11:48 AM, Nadeeshani Pathirennehelage <
nadeesha...@wso2.com> wrote:

> Hi Indunil,
>
> On Mon, Sep 3, 2018 at 11:05 AM, Indunil Upeksha Rathnayake <
> indu...@wso2.com> 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 

Re: [Dev] Unmarshalling with prevention of XML Injection

2018-09-02 Thread Nadeeshani Pathirennehelage
Hi Indunil,

On Mon, Sep 3, 2018 at 11:05 AM, Indunil Upeksha Rathnayake <
indu...@wso2.com> 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 b

[Dev] Unmarshalling with prevention of XML Injection

2018-09-02 Thread Indunil Upeksha Rathnayake
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?
Other than XML Bomb and XXE attack, any other security measures that we
need to consider?

Appreciate your ideas on this.


Thanks and Regards
-- 
Indunil Upeksha Rathnayake
Senior Software Engineer | WSO2 Inc
Emailindu...@wso2.com
Mobile   0772182255
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev