How to Solve Axis2 Information Leakage from OWASP Testing

[Scott Selvia]

We are running security tests on our Axis2 1.6.2 web services. It has
been pointed out that we have an OWASP information leakage and I'm
trying to figure out how to solve this. We intercept the SOAP request
and <?xml version="1.0" encoding="utf-8"?><!DOCTYPE foo [ to the
request. The response generated is being flagged as an information
leakage:
<soapenv:Fault><faultcode></faultcode><faultstring>java.xml.stream.XMLSt
reamException: DOCTYPE is not allowed</faultstring>



I'm trying to gather information to mitigate the finding:



1. Is the https://hostname/axis2/services/MyWebService?wsdl with
the "axis2/services" in the URL a problem and/or

2. Being able to capture the XMLStreamException and respond with
an appropriate non-descriptive message.



How can we change the "axis2/services" endpoint?



Since we don't even get the request in our code, how do we trap or
override the request coming into the web service engine?

[Arguello, Brando]

Scott,

If you have access to the service one option is..
On the service side, catch the exception, extract the information you need and return an object so it goes through the regular "OutFlow" phase instead of the "FaultFlow"

If you don't have access to the service ..
Can you add a handler on the "InFlow" phase of your client to intercept the response and filter out the leakage and then proceed to your client?

Regards.
-brando

From: Scott Selvia [mailto:***@datamentors.com]
Sent: Wednesday, November 26, 2014 9:53 AM
To: java-***@axis.apache.org
Subject: How to Solve Axis2 Information Leakage from OWASP Testing

We are running security tests on our Axis2 1.6.2 web services. It has been pointed out that we have an OWASP information leakage and I'm trying to figure out how to solve this. We intercept the SOAP request and <?xml version="1.0" encoding="utf-8"?><!DOCTYPE foo [ to the request. The response generated is being flagged as an information leakage: <soapenv:Fault><faultcode></faultcode><faultstring>java.xml.stream.XMLStreamException: DOCTYPE is not allowed</faultstring>

I'm trying to gather information to mitigate the finding:


1. Is the https://hostname/axis2/services/MyWebService?wsdl with the "axis2/services" in the URL a problem and/or

2. Being able to capture the XMLStreamException and respond with an appropriate non-descriptive message.

How can we change the "axis2/services" endpoint?

Since we don't even get the request in our code, how do we trap or override the request coming into the web service engine?

[Scott Selvia]

Brando,



It is our service so we have access to the service code, what I'm not
getting is catching the exception. Can you point me to some examples?



Thanks,



Scott



From: Arguello, Brando [mailto:***@gdc4s.com]
Sent: Wednesday, November 26, 2014 10:31 AM
To: java-***@axis.apache.org
Subject: RE: How to Solve Axis2 Information Leakage from OWASP Testing



Scott,



If you have access to the service one option is..

On the service side, catch the exception, extract the information you
need and return an object so it goes through the regular "OutFlow" phase
instead of the "FaultFlow"



If you don't have access to the service ..

Can you add a handler on the "InFlow" phase of your client to intercept
the response and filter out the leakage and then proceed to your
client?



Regards.

-brando



From: Scott Selvia [mailto:***@datamentors.com]
Sent: Wednesday, November 26, 2014 9:53 AM
To: java-***@axis.apache.org
Subject: How to Solve Axis2 Information Leakage from OWASP Testing



We are running security tests on our Axis2 1.6.2 web services. It has
been pointed out that we have an OWASP information leakage and I'm
trying to figure out how to solve this. We intercept the SOAP request
and <?xml version="1.0" encoding="utf-8"?><!DOCTYPE foo [ to the
request. The response generated is being flagged as an information
leakage:
<soapenv:Fault><faultcode></faultcode><faultstring>java.xml.stream.XMLSt
reamException: DOCTYPE is not allowed</faultstring>



I'm trying to gather information to mitigate the finding:



1. Is the https://hostname/axis2/services/MyWebService?wsdl with
the "axis2/services" in the URL a problem and/or

2. Being able to capture the XMLStreamException and respond with
an appropriate non-descriptive message.



How can we change the "axis2/services" endpoint?



Since we don't even get the request in our code, how do we trap or
override the request coming into the web service engine?

[Arguello, Brando]

Scott,

What OWASP seems to be flagging is the "<soapenv:Fault><faultcode></faultcode><faultstring>java.xml.stream.XMLStreamException:"

In your service..

theObjectYourMethodReturns yourMethod(.....) {

try {
.... The implementation ....
} catch (The exception e) {
Log exception..
return theObjectYourMethodReturns.setExceptionReason(e.getMessage); (catch exception and set reason in returned object)

}
return theObjectYourMethodReturns; (if no exception this returns with whatever your implementation requires)
}

From: Scott Selvia [mailto:***@datamentors.com]
Sent: Wednesday, November 26, 2014 10:41 AM
To: java-***@axis.apache.org
Subject: RE: How to Solve Axis2 Information Leakage from OWASP Testing

Brando,

It is our service so we have access to the service code, what I'm not getting is catching the exception. Can you point me to some examples?

Thanks,

Scott

From: Arguello, Brando [mailto:***@gdc4s.com]
Sent: Wednesday, November 26, 2014 10:31 AM
To: java-***@axis.apache.org<mailto:java-***@axis.apache.org>
Subject: RE: How to Solve Axis2 Information Leakage from OWASP Testing

Scott,

If you have access to the service one option is..
On the service side, catch the exception, extract the information you need and return an object so it goes through the regular "OutFlow" phase instead of the "FaultFlow"

If you don't have access to the service ..
Can you add a handler on the "InFlow" phase of your client to intercept the response and filter out the leakage and then proceed to your client?

Regards.
-brando

From: Scott Selvia [mailto:***@datamentors.com]
Sent: Wednesday, November 26, 2014 9:53 AM
To: java-***@axis.apache.org<mailto:java-***@axis.apache.org>
Subject: How to Solve Axis2 Information Leakage from OWASP Testing

We are running security tests on our Axis2 1.6.2 web services. It has been pointed out that we have an OWASP information leakage and I'm trying to figure out how to solve this. We intercept the SOAP request and <?xml version="1.0" encoding="utf-8"?><!DOCTYPE foo [ to the request. The response generated is being flagged as an information leakage: <soapenv:Fault><faultcode></faultcode><faultstring>java.xml.stream.XMLStreamException: DOCTYPE is not allowed</faultstring>

I'm trying to gather information to mitigate the finding:


1. Is the https://hostname/axis2/services/MyWebService?wsdl with the "axis2/services" in the URL a problem and/or

2. Being able to capture the XMLStreamException and respond with an appropriate non-descriptive message.

How can we change the "axis2/services" endpoint?

Since we don't even get the request in our code, how do we trap or override the request coming into the web service engine?

[Scott Selvia]

Brando,



Thank You!!!



I was going to deep on this, thinking I needed to override the message
listeners.



Regards,



Scott



From: Arguello, Brando [mailto:***@gdc4s.com]
Sent: Wednesday, November 26, 2014 10:55 AM
To: java-***@axis.apache.org
Subject: RE: How to Solve Axis2 Information Leakage from OWASP Testing



Scott,



What OWASP seems to be flagging is the
"<soapenv:Fault><faultcode></faultcode><faultstring>java.xml.stream.XMLS
treamException:"



In your service..



theObjectYourMethodReturns yourMethod(.....) {



try {

.... The implementation ....

} catch (The exception e) {

Log exception..

return theObjectYourMethodReturns.setExceptionReason(e.getMessage);
(catch exception and set reason in returned object)



}

return theObjectYourMethodReturns; (if no exception this returns with
whatever your implementation requires)

}



From: Scott Selvia [mailto:***@datamentors.com]
Sent: Wednesday, November 26, 2014 10:41 AM
To: java-***@axis.apache.org
Subject: RE: How to Solve Axis2 Information Leakage from OWASP Testing



Brando,



It is our service so we have access to the service code, what I'm not
getting is catching the exception. Can you point me to some examples?



Thanks,



Scott



From: Arguello, Brando [mailto:***@gdc4s.com]
Sent: Wednesday, November 26, 2014 10:31 AM
To: java-***@axis.apache.org
Subject: RE: How to Solve Axis2 Information Leakage from OWASP Testing



Scott,



If you have access to the service one option is..

On the service side, catch the exception, extract the information you
need and return an object so it goes through the regular "OutFlow" phase
instead of the "FaultFlow"



If you don't have access to the service ..

Can you add a handler on the "InFlow" phase of your client to intercept
the response and filter out the leakage and then proceed to your
client?



Regards.

-brando



From: Scott Selvia [mailto:***@datamentors.com]
Sent: Wednesday, November 26, 2014 9:53 AM
To: java-***@axis.apache.org
Subject: How to Solve Axis2 Information Leakage from OWASP Testing



We are running security tests on our Axis2 1.6.2 web services. It has
been pointed out that we have an OWASP information leakage and I'm
trying to figure out how to solve this. We intercept the SOAP request
and <?xml version="1.0" encoding="utf-8"?><!DOCTYPE foo [ to the
request. The response generated is being flagged as an information
leakage:
<soapenv:Fault><faultcode></faultcode><faultstring>java.xml.stream.XMLSt
reamException: DOCTYPE is not allowed</faultstring>



I'm trying to gather information to mitigate the finding:



1. Is the https://hostname/axis2/services/MyWebService?wsdl with
the "axis2/services" in the URL a problem and/or

2. Being able to capture the XMLStreamException and respond with
an appropriate non-descriptive message.



How can we change the "axis2/services" endpoint?



Since we don't even get the request in our code, how do we trap or
override the request coming into the web service engine?

[Scott Selvia]

Brando,



Just tried your solution I added an exception around the business logic
of the method and I still get the same response. Any other suggestions?



Regards,



Scott



<?xml version="1.0" encoding="utf-8"?>

<!DOCTYPE foo [

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:ser="http://service.web.datamentors.com">

<soap:Header/>

<soap:Body>

<ser:helloMethod>

<!--Optional:-->

<ser:aMessage>Hello from Client</ser:aMessage>

</ser:helloMethod>

</soap:Body>

</soap:Envelope>



<soapenv:Envelope
xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">

<soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">


<wsa:Action>http://www.w3.org/2005/08/addressing/soap/fault</wsa:Action>

</soapenv:Header>

<soapenv:Body>

<soapenv:Fault>

<soapenv:Code>

<soapenv:Value>soapenv:Receiver</soapenv:Value>

</soapenv:Code>

<soapenv:Reason>

<soapenv:Text
xml:lang="en-US">javax.xml.stream.XMLStreamException: DOCTYPE is not
allowed</soapenv:Text>

</soapenv:Reason>

<soapenv:Detail/>

</soapenv:Fault>

</soapenv:Body>

</soapenv:Envelope>



MyResponse helloMethod(String aMsg)

{

MyResponse response = null;



System.out.println("In Method");



try

{

response = new MyResponse("Good SOAP Message");

}

catch (Exception e)

{

e.printStackTrace();



response = new MyResponse("Bad SOAP Message");

}

}



From: Scott Selvia [mailto:***@datamentors.com]
Sent: Wednesday, November 26, 2014 10:59 AM
To: java-***@axis.apache.org
Subject: RE: How to Solve Axis2 Information Leakage from OWASP Testing



Brando,



Thank You!!!



I was going to deep on this, thinking I needed to override the message
listeners.



Regards,



Scott



From: Arguello, Brando [mailto:***@gdc4s.com]
Sent: Wednesday, November 26, 2014 10:55 AM
To: java-***@axis.apache.org
Subject: RE: How to Solve Axis2 Information Leakage from OWASP Testing



Scott,



What OWASP seems to be flagging is the
"<soapenv:Fault><faultcode></faultcode><faultstring>java.xml.stream.XMLS
treamException:"



In your service..



theObjectYourMethodReturns yourMethod(.....) {



try {

.... The implementation ....

} catch (The exception e) {

Log exception..

return theObjectYourMethodReturns.setExceptionReason(e.getMessage);
(catch exception and set reason in returned object)



}

return theObjectYourMethodReturns; (if no exception this returns with
whatever your implementation requires)

}



From: Scott Selvia [mailto:***@datamentors.com]
Sent: Wednesday, November 26, 2014 10:41 AM
To: java-***@axis.apache.org
Subject: RE: How to Solve Axis2 Information Leakage from OWASP Testing



Brando,



It is our service so we have access to the service code, what I'm not
getting is catching the exception. Can you point me to some examples?



Thanks,



Scott



From: Arguello, Brando [mailto:***@gdc4s.com]
Sent: Wednesday, November 26, 2014 10:31 AM
To: java-***@axis.apache.org
Subject: RE: How to Solve Axis2 Information Leakage from OWASP Testing



Scott,



If you have access to the service one option is..

On the service side, catch the exception, extract the information you
need and return an object so it goes through the regular "OutFlow" phase
instead of the "FaultFlow"



If you don't have access to the service ..

Can you add a handler on the "InFlow" phase of your client to intercept
the response and filter out the leakage and then proceed to your
client?



Regards.

-brando



From: Scott Selvia [mailto:***@datamentors.com]
Sent: Wednesday, November 26, 2014 9:53 AM
To: java-***@axis.apache.org
Subject: How to Solve Axis2 Information Leakage from OWASP Testing



We are running security tests on our Axis2 1.6.2 web services. It has
been pointed out that we have an OWASP information leakage and I'm
trying to figure out how to solve this. We intercept the SOAP request
and <?xml version="1.0" encoding="utf-8"?><!DOCTYPE foo [ to the
request. The response generated is being flagged as an information
leakage:
<soapenv:Fault><faultcode></faultcode><faultstring>java.xml.stream.XMLSt
reamException: DOCTYPE is not allowed</faultstring>



I'm trying to gather information to mitigate the finding:



1. Is the https://hostname/axis2/services/MyWebService?wsdl with
the "axis2/services" in the URL a problem and/or

2. Being able to capture the XMLStreamException and respond with
an appropriate non-descriptive message.



How can we change the "axis2/services" endpoint?



Since we don't even get the request in our code, how do we trap or
override the request coming into the web service engine?

[Martin Gainty]

1)DTDs not been supported by axis for at least 10 years and any/all attempts to implement DTDs will
fubar your axis default installation
you *can* install your own incoming/outgoing message receivers in the messageReceivers in axis2.xml
<messageReceivers>
<messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-only"
class="org.apache.axis2.receivers.RawXMLINOnlyMessageReceiver"/>
<messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-out"
class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/>
<messageReceiver mep="http://www.w3.org/2006/01/wsdl/in-only"
class="org.apache.axis2.receivers.RawXMLINOnlyMessageReceiver"/>
<messageReceiver mep="http://www.w3.org/2006/01/wsdl/in-out"
class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/>
</messageReceivers>
if for any reason you want to accomodate a different content-type then add that messageFormatter here in axis2.xml
<messageFormatters>
<messageFormatter contentType="application/x-www-form-urlencoded"
class="org.apache.axis2.transport.http.XFormURLEncodedFormatter"/>
<messageFormatter contentType="multipart/form-data"
class="org.apache.axis2.transport.http.MultipartFormDataFormatter"/>
<messageFormatter contentType="application/xml"
class="org.apache.axis2.transport.http.ApplicationXMLFormatter"/>
<messageFormatter contentType="text/xml"
class="org.apache.axis2.transport.http.SOAPMessageFormatter"/>
<messageFormatter contentType="application/soap+xml"
class="org.apache.axis2.transport.http.SOAPMessageFormatter"/>
</messageFormatters>
2)if your concern is MIM attack by someone sharking the line
look into encrypting/decrypting your messages with Rampart Security module (i like bouncycastle security provider)
http://axis.apache.org/axis2/java/rampart/download/1.6.2/download.cgi

OWASP Testing guideline might prove useful:
https://www.owasp.org/index.php/Conduct_search_engine_discovery/reconnaissance_for_information_leakage_(OTG-INFO-001)

Personal Note; when working at the bank use of search engines was banned..now i know why

Happy Thanksgiving All
Martin
______________________________________________



Subject: RE: How to Solve Axis2 Information Leakage from OWASP Testing
Date: Wed, 26 Nov 2014 10:40:40 -0500
From: ***@datamentors.com
To: java-***@axis.apache.org

Brando, It is our service so we have access to the service code, what I’m not getting is catching the exception. Can you point me to some examples? Thanks, Scott From: Arguello, Brando [mailto:***@gdc4s.com]
Sent: Wednesday, November 26, 2014 10:31 AM
To: java-***@axis.apache.org
Subject: RE: How to Solve Axis2 Information Leakage from OWASP Testing Scott, If you have access to the service one option is..On the service side, catch the exception, extract the information you need and return an object so it goes through the regular “OutFlow” phase instead of the “FaultFlow” If you don’t have access to the service ..Can you add a handler on the “InFlow” phase of your client to intercept the response and filter out the leakage and then proceed to your client? Regards.-brando From: Scott Selvia [mailto:***@datamentors.com]
Sent: Wednesday, November 26, 2014 9:53 AM
To: java-***@axis.apache.org
Subject: How to Solve Axis2 Information Leakage from OWASP Testing We are running security tests on our Axis2 1.6.2 web services. It has been pointed out that we have an OWASP information leakage and I’m trying to figure out how to solve this. We intercept the SOAP request and <?xml version=”1.0” encoding=”utf-8”?><!DOCTYPE foo [ to the request. The response generated is being flagged as an information leakage: <soapenv:Fault><faultcode></faultcode><faultstring>java.xml.stream.XMLStreamException: DOCTYPE is not allowed</faultstring> I’m trying to gather information to mitigate the finding: 1. Is the https://hostname/axis2/services/MyWebService?wsdl with the “axis2/services” in the URL a problem and/or2. Being able to capture the XMLStreamException and respond with an appropriate non-descriptive message. How can we change the “axis2/services” endpoint? Since we don’t even get the request in our code, how do we trap or override the request coming into the web service engine?

[Scott Selvia]

Martin,



I've enabled DEBUG logging for Axis2, I can see the DOCTYPE is not
allowed. So as you suggest, I need to create my own message listener to
trap this AxisFault with the XMLStreamReader?



Thanks,



Scott



[#|2014-11-26T12:59:39.048-0500|INFO|glassfish3.1.2|javax.enterprise.sys
tem.std.com.sun.enterprise.server.logging|_ThreadID=108;_ThreadName=Thre
ad-2;|[DEBUG] setAction New action is (urn:helloMethod)

|#]



[#|2014-11-26T12:59:39.048-0500|INFO|glassfish3.1.2|javax.enterprise.sys
tem.std.com.sun.enterprise.server.logging|_ThreadID=108;_ThreadName=Thre
ad-2;|[DEBUG] createSOAPEnvelope using Builder (class
org.apache.axis2.builder.SOAPBuilder) selected from type
(application/soap+xml)

|#]



[#|2014-11-26T12:59:39.048-0500|INFO|glassfish3.1.2|javax.enterprise.sys
tem.std.com.sun.enterprise.server.logging|_ThreadID=108;_ThreadName=Thre
ad-2;|[DEBUG] char set encoding set from default =UTF-8

|#]



[#|2014-11-26T12:59:39.048-0500|INFO|glassfish3.1.2|javax.enterprise.sys
tem.std.com.sun.enterprise.server.logging|_ThreadID=108;_ThreadName=Thre
ad-2;|[DEBUG] XMLStreamReader is
org.apache.axiom.util.stax.dialect.WoodstoxStreamReaderWrapper

|#]



[#|2014-11-26T12:59:39.048-0500|INFO|glassfish3.1.2|javax.enterprise.sys
tem.std.com.sun.enterprise.server.logging|_ThreadID=108;_ThreadName=Thre
ad-2;|[DEBUG] org.apache.axis2.AxisFault:
javax.xml.stream.XMLStreamException: DOCTYPE is not allowed

|#]



[#|2014-11-26T12:59:39.048-0500|INFO|glassfish3.1.2|javax.enterprise.sys
tem.std.com.sun.enterprise.server.logging|_ThreadID=108;_ThreadName=Thre
ad-2;|[DEBUG] [MessageContext:
logID=6812b93b1f449a0693d713277a06a0c1e690df9694ec910a]
isFaultRedirected: FaultTo is null. Returning isReplyRedirected

|#]



[#|2014-11-26T12:59:39.048-0500|INFO|glassfish3.1.2|javax.enterprise.sys
tem.std.com.sun.enterprise.server.logging|_ThreadID=108;_ThreadName=Thre
ad-2;|[DEBUG] [MessageContext:
logID=6812b93b1f449a0693d713277a06a0c1e690df9694ec910a]
isReplyRedirected: ReplyTo is null. Returning false

|#]



[#|2014-11-26T12:59:39.049-0500|INFO|glassfish3.1.2|javax.enterprise.sys
tem.std.com.sun.enterprise.server.logging|_ThreadID=108;_ThreadName=Thre
ad-2;|[DEBUG] getAction (null) from
***@2c82fe4f

|#]





From: Martin Gainty [mailto:***@hotmail.com]
Sent: Wednesday, November 26, 2014 12:09 PM
To: java-***@axis.apache.org; Scott Selvia
Subject: RE: How to Solve Axis2 Information Leakage from OWASP Testing



1)DTDs not been supported by axis for at least 10 years and any/all
attempts to implement DTDs will
fubar your axis default installation
you *can* install your own incoming/outgoing message receivers in the
messageReceivers in axis2.xml
<messageReceivers>
<messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-only"

class="org.apache.axis2.receivers.RawXMLINOnlyMessageReceiver"/>
<messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-out"

class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/>
<messageReceiver mep="http://www.w3.org/2006/01/wsdl/in-only"

class="org.apache.axis2.receivers.RawXMLINOnlyMessageReceiver"/>
<messageReceiver mep="http://www.w3.org/2006/01/wsdl/in-out"

class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/>
</messageReceivers>
if for any reason you want to accomodate a different content-type then
add that messageFormatter here in axis2.xml
<messageFormatters>
<messageFormatter
contentType="application/x-www-form-urlencoded"

class="org.apache.axis2.transport.http.XFormURLEncodedFormatter"/>
<messageFormatter contentType="multipart/form-data"

class="org.apache.axis2.transport.http.MultipartFormDataFormatter"/>
<messageFormatter contentType="application/xml"

class="org.apache.axis2.transport.http.ApplicationXMLFormatter"/>
<messageFormatter contentType="text/xml"

class="org.apache.axis2.transport.http.SOAPMessageFormatter"/>
<messageFormatter contentType="application/soap+xml"

class="org.apache.axis2.transport.http.SOAPMessageFormatter"/>
</messageFormatters>
2)if your concern is MIM attack by someone sharking the line
look into encrypting/decrypting your messages with Rampart Security
module (i like bouncycastle security provider)
http://axis.apache.org/axis2/java/rampart/download/1.6.2/download.cgi

OWASP Testing guideline might prove useful:
https://www.owasp.org/index.php/Conduct_search_engine_discovery/reconnai
ssance_for_information_leakage_(OTG-INFO-001)

Personal Note; when working at the bank use of search engines was
banned..now i know why

Happy Thanksgiving All
Martin
______________________________________________








________________________________

Subject: RE: How to Solve Axis2 Information Leakage from OWASP Testing
Date: Wed, 26 Nov 2014 10:40:40 -0500
From: ***@datamentors.com
To: java-***@axis.apache.org

Brando,



It is our service so we have access to the service code, what I'm not
getting is catching the exception. Can you point me to some examples?



Thanks,



Scott



From: Arguello, Brando [mailto:***@gdc4s.com]
Sent: Wednesday, November 26, 2014 10:31 AM
To: java-***@axis.apache.org
Subject: RE: How to Solve Axis2 Information Leakage from OWASP Testing



Scott,



If you have access to the service one option is..

On the service side, catch the exception, extract the information you
need and return an object so it goes through the regular "OutFlow" phase
instead of the "FaultFlow"



If you don't have access to the service ..

Can you add a handler on the "InFlow" phase of your client to intercept
the response and filter out the leakage and then proceed to your
client?



Regards.

-brando



From: Scott Selvia [mailto:***@datamentors.com]
Sent: Wednesday, November 26, 2014 9:53 AM
To: java-***@axis.apache.org
Subject: How to Solve Axis2 Information Leakage from OWASP Testing



We are running security tests on our Axis2 1.6.2 web services. It has
been pointed out that we have an OWASP information leakage and I'm
trying to figure out how to solve this. We intercept the SOAP request
and <?xml version="1.0" encoding="utf-8"?><!DOCTYPE foo [ to the
request. The response generated is being flagged as an information
leakage:
<soapenv:Fault><faultcode></faultcode><faultstring>java.xml.stream.XMLSt
reamException: DOCTYPE is not allowed</faultstring>



I'm trying to gather information to mitigate the finding:



1. Is the https://hostname/axis2/services/MyWebService?wsdl with
the "axis2/services" in the URL a problem and/or

2. Being able to capture the XMLStreamException and respond with
an appropriate non-descriptive message.



How can we change the "axis2/services" endpoint?



Since we don't even get the request in our code, how do we trap or
override the request coming into the web service engine?

[Martin Gainty]

AXIS-2.1.5 wsdl2java<bat/sh> will handle which XMLReader you will implement..here is doc:
org.apache.axis2.wsdl.WSDL2Java --helpUsage: WSDL2Java [options] -uri <url or path> : A url or path to a WSDL
where [options] include: -o <path> Specify a directory path for the generated code. -a Generate async style code only (Default: off). -s Generate sync style code only (Default: off). Takes precedence over -a. -p <pkg1> Specify a custom package name for the generated code.
-l <language> Valid languages are java and c (Default: java). -t Generate a test case for the generated code. -ss Generate server side code (i.e. skeletons) (Default:off). -sd Generate service descriptor (i.e. services.xml). (Default: off). Valid with -ss. -d <databinding> Valid databinding(s) are adb, xmlbeans, jibx and jaxbri (Default: adb). -g Generates all the classes. Valid only with -ss. -pn <port_name> Choose a specific port when there are multiple ports in the wsdl. -sn <service_name> Choose a specific service when there are multiple services in the wsdl. -u Unpacks the databinding classes -r <path> Specify a repository against which code is generated.
-ns2p ns1=pkg1,ns2=pkg2 Specify a custom package name for each namespace specified in the wsdls schema. -ssi Generate an interface for the service implementation(Default: off). -wv <version> WSDL Version. Valid Options : 2, 2.0, 1.1 -S <path> Specify a directory path for generated source -R <path> Specify a directory path for generated resources -em <file path> Specify an external mapping file -f Flattens the generated files -uw Switch on un-wrapping. -xsdconfig <file path> Use XMLBeans .xsdconfig file. Valid only with -d xmlbeans. -ap Generate code for all ports -or Overwrite the existing classes -b Generate Axis 1.x backward compatible code. -sp Suppress namespace prefixes (Optimzation that reduces size of soap request/response) -E<key> <value> Extra configuration options specific to certain databindings. Examples: -Ebindingfile <path> (for jibx) - specify the file path for the binding file -Etypesystemname <my_type_system_name> (for xmlbeans) - override the randomly generated type system name -Ejavaversion 1.5 (for xmlbeans) - generates Java 1.5 code (typed lists instead of arrays) -Emp <package name> (for ADB) - extension mapper package name -Eosv (for ADB) - turn off strict validation. -Ewdc (for xmlbeans) - Generate code with a dummy schema. if someone use this option they have to generate the xmlbeans code seperately ith the scomp command comes with the xmlbeans distribution and replace the Axis2 generated classes with correct classes --noBuildXML Dont generate the build.xml in the output directory --noWSDL Dont generate WSDLs in the resources directory --noMessageReceiver Dont generate a MessageReceiver in the generated sources --http-proxy-host <host> Proxy host address if you are behind a firewall --http-proxy-port <port> Proxy port address if you are behind a firewall -ep <package-name-list> Exclude packages - these packages are deleted after code generation -sin <interface-name> Skeleton interface name - used to specify a name forskeleton interface other than the default one -scn <class-name> Skeleton class name - used to specify a name for skeleton class other than the default one -EbindingFileName <path> (for jaxbri) - specify the file path for the episode file -oaa <override-absolute-address> -change the absolute http addresses to local file addresses generated by wsdl2java tool -ebc <exception-base-class> -generated Exceptions are inherited from this exception rather than the java.lang.Exception class -uon <use-operation-name> -by default the first letter of the generated method name changeed to lowercase. This option stops that and make it same as operation name
Use default style of adb
the stubs service and client and build.xml will be generated for you afterwards
Martin Gainty
______________________________________________



Subject: RE: How to Solve Axis2 Information Leakage from OWASP Testing
Date: Wed, 26 Nov 2014 14:06:04 -0500
From: ***@datamentors.com
To: ***@hotmail.com; java-***@axis.apache.org

Martin, I’ve enabled DEBUG logging for Axis2, I can see the DOCTYPE is not allowed. So as you suggest, I need to create my own message listener to trap this AxisFault with the XMLStreamReader? Thanks, Scott [#|2014-11-26T12:59:39.048-0500|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=108;_ThreadName=Thread-2;|[DEBUG] setAction New action is (urn:helloMethod)|#] [#|2014-11-26T12:59:39.048-0500|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=108;_ThreadName=Thread-2;|[DEBUG] createSOAPEnvelope using Builder (class org.apache.axis2.builder.SOAPBuilder) selected from type (application/soap+xml)|#] [#|2014-11-26T12:59:39.048-0500|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=108;_ThreadName=Thread-2;|[DEBUG] char set encoding set from default =UTF-8|#] [#|2014-11-26T12:59:39.048-0500|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=108;_ThreadName=Thread-2;|[DEBUG] XMLStreamReader is org.apache.axiom.util.stax.dialect.WoodstoxStreamReaderWrapper|#] [#|2014-11-26T12:59:39.048-0500|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=108;_ThreadName=Thread-2;|[DEBUG] org.apache.axis2.AxisFault: javax.xml.stream.XMLStreamException: DOCTYPE is not allowed|#] [#|2014-11-26T12:59:39.048-0500|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=108;_ThreadName=Thread-2;|[DEBUG] [MessageContext: logID=6812b93b1f449a0693d713277a06a0c1e690df9694ec910a] isFaultRedirected: FaultTo is null. Returning isReplyRedirected|#] [#|2014-11-26T12:59:39.048-0500|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=108;_ThreadName=Thread-2;|[DEBUG] [MessageContext: logID=6812b93b1f449a0693d713277a06a0c1e690df9694ec910a] isReplyRedirected: ReplyTo is null. Returning false|#] [#|2014-11-26T12:59:39.049-0500|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=108;_ThreadName=Thread-2;|[DEBUG] getAction (null) from ***@2c82fe4f|#] From: Martin Gainty [mailto:***@hotmail.com]
Sent: Wednesday, November 26, 2014 12:09 PM
To: java-***@axis.apache.org; Scott Selvia
Subject: RE: How to Solve Axis2 Information Leakage from OWASP Testing 1)DTDs not been supported by axis for at least 10 years and any/all attempts to implement DTDs will
fubar your axis default installation
you *can* install your own incoming/outgoing message receivers in the messageReceivers in axis2.xml
<messageReceivers>
<messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-only"
class="org.apache.axis2.receivers.RawXMLINOnlyMessageReceiver"/>
<messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-out"
class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/>
<messageReceiver mep="http://www.w3.org/2006/01/wsdl/in-only"
class="org.apache.axis2.receivers.RawXMLINOnlyMessageReceiver"/>
<messageReceiver mep="http://www.w3.org/2006/01/wsdl/in-out"
class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/>
</messageReceivers>
if for any reason you want to accomodate a different content-type then add that messageFormatter here in axis2.xml
<messageFormatters>
<messageFormatter contentType="application/x-www-form-urlencoded"
class="org.apache.axis2.transport.http.XFormURLEncodedFormatter"/>
<messageFormatter contentType="multipart/form-data"
class="org.apache.axis2.transport.http.MultipartFormDataFormatter"/>
<messageFormatter contentType="application/xml"
class="org.apache.axis2.transport.http.ApplicationXMLFormatter"/>
<messageFormatter contentType="text/xml"
class="org.apache.axis2.transport.http.SOAPMessageFormatter"/>
<messageFormatter contentType="application/soap+xml"
class="org.apache.axis2.transport.http.SOAPMessageFormatter"/>
</messageFormatters>
2)if your concern is MIM attack by someone sharking the line
look into encrypting/decrypting your messages with Rampart Security module (i like bouncycastle security provider)
http://axis.apache.org/axis2/java/rampart/download/1.6.2/download.cgi

OWASP Testing guideline might prove useful:
https://www.owasp.org/index.php/Conduct_search_engine_discovery/reconnaissance_for_information_leakage_(OTG-INFO-001)

Personal Note; when working at the bank use of search engines was banned..now i know why

Happy Thanksgiving All
Martin
______________________________________________

Subject: RE: How to Solve Axis2 Information Leakage from OWASP Testing
Date: Wed, 26 Nov 2014 10:40:40 -0500
From: ***@datamentors.com
To: java-***@axis.apache.orgBrando, It is our service so we have access to the service code, what I’m not getting is catching the exception. Can you point me to some examples? Thanks, Scott From: Arguello, Brando [mailto:***@gdc4s.com]
Sent: Wednesday, November 26, 2014 10:31 AM
To: java-***@axis.apache.org
Subject: RE: How to Solve Axis2 Information Leakage from OWASP Testing Scott, If you have access to the service one option is..On the service side, catch the exception, extract the information you need and return an object so it goes through the regular “OutFlow” phase instead of the “FaultFlow” If you don’t have access to the service ..Can you add a handler on the “InFlow” phase of your client to intercept the response and filter out the leakage and then proceed to your client? Regards.-brando From: Scott Selvia [mailto:***@datamentors.com]
Sent: Wednesday, November 26, 2014 9:53 AM
To: java-***@axis.apache.org
Subject: How to Solve Axis2 Information Leakage from OWASP Testing We are running security tests on our Axis2 1.6.2 web services. It has been pointed out that we have an OWASP information leakage and I’m trying to figure out how to solve this. We intercept the SOAP request and <?xml version=”1.0” encoding=”utf-8”?><!DOCTYPE foo [ to the request. The response generated is being flagged as an information leakage: <soapenv:Fault><faultcode></faultcode><faultstring>java.xml.stream.XMLStreamException: DOCTYPE is not allowed</faultstring> I’m trying to gather information to mitigate the finding: 1. Is the https://hostname/axis2/services/MyWebService?wsdl with the “axis2/services” in the URL a problem and/or2. Being able to capture the XMLStreamException and respond with an appropriate non-descriptive message. How can we change the “axis2/services” endpoint? Since we don’t even get the request in our code, how do we trap or override the request coming into the web service engine?