cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aki Yoshida (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CXF-4684) SOAPFault message improvement in CXF when there is unchecked NPE
Date Mon, 17 Dec 2012 09:48:13 GMT

    [ 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

Mime
View raw message