[
https://issues.apache.org/jira/browse/CXF-4684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533793#comment-13533793
]
Aki Yoshida commented on CXF-4684:
----------------------------------
Hi Glen,
Yes. This touches exactly that security point. There was a discussion thread
started by Bin.
http://cxf.547215.n5.nabble.com/SOAPFault-message-improvement-in-CXF-when-there-is-unchecked-NPE-tc5719398.html#a5719568
Initially I suggested for the exceptionCauseEnabled property. However, this
property only wrote the cause message but not the cause itself (e.g. NPE). In
addition, Ivan pointed us to the jaxws spec section 10.2.2 that specifies that
the faultstring must come from the cause.toString() in some cases.
So, I asked at dev@cxf asking the interpretation of this rule.
http://cxf.547215.n5.nabble.com/interpretation-of-jaxws-10-2-2-exception-handling-tc5719946.html#a5720008
The rest is stated in my comment from Dec 12 above.
Personally, I think the jaxws spec could have left this toString rule out of
its normative part. I am not really concerned about just writing the class name
like NPE. But I am more concerned about some unknown user extended runtime
exception that overwrites its toString to do more than writing its class name.
However, this rule is there, so we need to comply to it right? Or supposing the
jaxws 10.2.2 itself is a security issue, should we only enable this rule with
an option? That was the point of my original question in dev@cxf. Any
definitive answers will be appreciated.
Thanks.
regards, aki
> SOAPFault message improvement in CXF when there is unchecked NPE
> ----------------------------------------------------------------
>
> Key: CXF-4684
> URL: https://issues.apache.org/jira/browse/CXF-4684
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
> Affects Versions: 2.6.2
> Reporter: Bin Zhu
> Assignee: Aki Yoshida
> Attachments: CXF-4684.patch
>
>
> When there is unchecked NPE thrown, the SOAPFault in CXF will only throw the
> "Fault occurred while processing." message rather than the original NPE
> message.
> Analysis:
> 1. In org.apache.cxf.binding.soap.interceptor.Soap11FaultOutInterceptor and
> org.apache.cxf.binding.soap.interceptor.Soap12FaultOutInterceptor,
> It will check fault.getMessage() :
> if (fault.getMessage() != null) {
> if (message.get("forced.faultstring") != null) {
> writer.writeCharacters((String)
> message.get("forced.faultstring"));
> } else {
> writer.writeCharacters(fault.getMessage());
> }
> } else {
> writer.writeCharacters("Fault occurred while
> processing.");
> }
> But for NPE, the fault.getMessage() will return null instead of the
> "java.lang.NullPointerException" in the getMessage() in NPE.
> 2.
> Fault.getMessage will return null in the NPE scenario while it's super class
> Throwable will not.
> When there is NPE, the message attribute in Fault is null while the
> detailMessageAtrribute is "java.lang.NullPointerException".
> Details:
> SoapFault->Fault->UncheckedException->RuntimeException->Exception->Throwable.
> // SoapFault->Fault means SoapFault class extends Fault class
> UncheckedException.getMessage:
> public String getMessage() {
> if (null != message) {
> return message.toString();
> }
> return null;
> }
> Throwable.getMessage:
> public String getMessage() {
> return detailMessage;
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
