You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rampart-dev@ws.apache.org by "Amila Jayasekara (JIRA)" <ji...@apache.org> on 2010/08/09 19:10:16 UTC

[jira] Commented: (RAMPART-303) Incorrect XML Passed to Digest Algorithm when XML Elements Belong to Empty Namespace

    [ https://issues.apache.org/jira/browse/RAMPART-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12896624#action_12896624 ] 

Amila Jayasekara commented on RAMPART-303:
------------------------------------------

Hi Niall, 
 I was able to reproduce this issue. The cause this issue lies within axiom to dom conversion code. Let me explain the issue in detail.

Rampart uses xmlsec implementation for xml encryption and signing operations. But axis2 uses a its own xml object model called Axiom. When a request comes Rampart has to convert message from axiom implementation to DOM implementation. This was done by introducing a new model called DOOM. In this model an Element implements DOM interfaces and Axiom interfaces. XmlSec uses 2 DOM interface methods during canonicalization. They are Element.hasAttribute() and Element.getAttributes(). The way these 2 methods implemented in DOOM is not correct. The Element.hasAttribute() method returns true only if namespaces are not null for current node. So if we have an element like "<drivingdirections xmlns="">", the Element.hasAttribute() will return false in DOOM implementation. But according to DOM interfaces method Element.hasAttribute() should return true for "<drivingdirections xmlns="">" as there is a namespace attribute attached to it.

I file an issue for this in [1] under WS-COMMONS and also submit a fix for that.

[1] https://issues.apache.org/jira/browse/WSCOMMONS-557

Also you are correct about https://issues.apache.org/jira/browse/RAMPART-128. That is this issue shows resemblance of RAMPART-128. When the namespace of  drivingdirections is set to null, all namespaces underneath that element are also set to null. Therefore Element.hasAttribute() method returns false for all underneath elements.

If possible please apply the patch in [2] and see whether your issue is resolved. You need to apply this to AXIOM code (http://svn.apache.org/repos/asf/webservices/commons/${your axiom version}/modules/axiom).

[2] https://issues.apache.org/jira/secure/attachment/12451599/WSCOMMONS-557.diff

Thank you
AmilaJ
   

> Incorrect XML Passed to Digest Algorithm when XML Elements Belong to Empty Namespace
> ------------------------------------------------------------------------------------
>
>                 Key: RAMPART-303
>                 URL: https://issues.apache.org/jira/browse/RAMPART-303
>             Project: Rampart
>          Issue Type: Bug
>          Components: rampart-core
>    Affects Versions: 1.5
>         Environment: Windows XP
>            Reporter: Niall Tierney
>            Assignee: Ruchith Udayanga Fernando
>         Attachments: correct.dat, driving_with_wspolicy.wsdl, DrivingClient.java, incorrect.dat, input.xml
>
>
> I am using Axis2 1.5.1 and Rampart 1.5 to sign a SOAP request and validate the signature on the response, however I am getting a mismatch between the actual digest in the XML Signature in the response message and the digest produced by Rampart.
> To investigate this issue, I implemented a simple Crypto provider that implemented the SHA1 digest algorithm.  The provider just writes out the data that was sent to it to digest to a file.   It then just calls the default Sun implementation to actually compute the digest.  This allowed me to see the XML that Rampart was passing to the digest algorithm.
> The attached input.xml is the initial signed response document.
> When verifying the signature on the response body, rampart produces the following output:
> > WARNING: Expected Digest: uf7xYFDKnUgQgxBg3SJTSIY/osk= 
> > 26-Jul-2010 10:54:56 org.apache.xml.security.signature.Reference verify
> > WARNING: Actual Digest: uGqjmTDx7IDyniF7hh5eaQ2ZWjU=
> I've taken the message and verified it successfully with a number of XML signature implementations, including the Apache one at 
> https://svn.apache.org/repos/asf/xml/security/tags/J_1_4_2, which is the version that rampart actually uses (i.e. xmlsec-1.4.2.jar ships with Rampart 1.5).
> The attached file correct.dat is the c14n'd form of the body such that SHA1(correct.dat) matches the digest in the signature:
> > $ openssl sha1 -binary correct.dat | openssl base64
> > uf7xYFDKnUgQgxBg3SJTSIY/osk= 
> You can see that this digest matches the "Expected Digest" in the Rampart trace above, which is the digest in the XML Signature.
> The attached file incorrect.dat is the data as passed to the digest via rampart:
> > $ openssl sha1 -binary incorrect.dat | openssl base64
> > uGqjmTDx7IDyniF7hh5eaQ2ZWjU= 
> You can see that this digest matches the "Actual Digest" produced by Rampart in the trace above.
> The differences between the two inputs looks as follows:
> >
> > --- correct.dat 2010-07-26 11:08:54.000000000 +0100
> > +++ incorrect.dat       2010-07-26 11:08:54.000000000 +0100
> > @@ -1,8 +1,8 @@
> > <soap:Body xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
> >
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurit
> y-utility-1.0.xsd" 
> > wsu:Id="Id-0000012a0e1a1572-00000000010a6723-3">
> > <GetDirectionsResponse xmlns="http://www.ecubicle.net/webservices/">
> > <GetDirectionsResult>
> > - <drivingdirections xmlns="">
> > - <route distanceToTravel=" 500 m" finalStep="false" id="0">
> > + <drivingdirections>
> > + <route>
> >                          Head south on Grove St
> > </route>
> > <totalDistance>739 km</totalDistance>
> You can see that rampart has dropped the xmlns="" attribute/namespace declaration from the "drivingdirections" element, and also the attributes from the route element (indeed, it seems that neither the attribute or namespace axes have been entirely eliminated).
> Experimentation shows that naiively deleting the default namespace declaration (i.e. xmlns="") from the drivingdirections element actually produces a signature that rampart can verify, so it is not just systematically eliminating theses axes.
> This bug seems to resemble Issue 128, but this was logged in December 2007 for Rampart 1.3 and is still open.  And since i had a bit more information I thought I'd add it in as a new issue.
> https://issues.apache.org/jira/browse/RAMPART-128
> You can see an example of a Web Service that returns elements in the empty namespace (i.e. xmlns="") here:
> http://www.ecubicle.net/driving.asmx?wsdl

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.