[
https://issues.apache.org/jira/browse/CXF-8061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike M. updated CXF-8061:
-------------------------
Description:
We found an issue when a CXF server is being called from a .NET client with
WebService Security in place. The relevant part of the stack trace looks like
this:
{code}
Caused by: org.apache.wss4j.common.ext.WSSecurityException: Attachment not found
at
org.apache.wss4j.dom.util.EncryptionUtils.decryptEncryptedData(EncryptionUtils.java:215)
at
org.apache.wss4j.dom.processor.EncryptedKeyProcessor.decryptDataRef(EncryptedKeyProcessor.java:602)
at
org.apache.wss4j.dom.processor.EncryptedKeyProcessor.decryptDataRefs(EncryptedKeyProcessor.java:533)
at
org.apache.wss4j.dom.processor.EncryptedKeyProcessor.handleToken(EncryptedKeyProcessor.java:232)
at
org.apache.wss4j.dom.processor.EncryptedKeyProcessor.handleToken(EncryptedKeyProcessor.java:90)
at
org.apache.wss4j.dom.engine.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:340)
at
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessageInternal(WSS4JInInterceptor.java:320)
... 54 common frames omitted
Caused by: org.apache.wss4j.common.ext.WSSecurityException: Attachment not found
at
org.apache.wss4j.dom.util.EncryptionUtils.decryptXopAttachment(EncryptionUtils.java:376)
at
org.apache.wss4j.dom.util.EncryptionUtils.decryptEncryptedData(EncryptionUtils.java:207)
... 60 common frames omitted
{code}
So at first, it looks like the incoming message has issues with Attachment IDs.
Our actual request looks like this (shortened for readability):
{code}
POST /myservice HTTP/1.1
Host: localhost
MIME-Version:1.0
Content-Type:multipart/related;
type="application/xop+xml";start="<http://tempuri.org/0>";boundary="uuid:fad7c6a9-85d1-498b-a456-748c87de4d7d+id=1";start-info="text/xml"
--uuid:fad7c6a9-85d1-498b-a456-748c87de4d7d+id=1
Content-ID: <http://tempuri.org/0>
Content-Transfer-Encoding: 8bit
Content-Type: application/xop+xml;charset=utf-8;type="text/xml"
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/";>
<s:Header>
[...]
<Security>
[...]
<CipherData>
<CipherValue>
<xop:Include
href="cid:http%3A%2F%2Ftempuri.org%2F1%2F636966400494014846"
xmlns:xop="http://www.w3.org/2004/08/xop/include"/>
</CipherValue>
</CipherData>
[...]
</Security>
[...]
</s:Header>
<s:Body>
<EncryptedData>[...]</EncryptedData>
</s:Body>
</s:Envelope>
--uuid:fad7c6a9-85d1-498b-a456-748c87de4d7d+id=1
Content-ID: <http://tempuri.org/1/636966400494014846>
Content-Transfer-Encoding: binary
Content-Type: application/octet-stream
[...binary data...]
--uuid:fad7c6a9-85d1-498b-a456-748c87de4d7d+id=1--
{code}
Now, if you compare {{<xop:Include>}}'s {{href}} value with the {{Content-ID}}
in the attachment part header, you'll see that it is the same value, just
URL-Encoded in the former.
As weird as this may seem, It's actually specified that way in those locations:
https://www.w3.org/TR/xop10/#xop_href
{quote}
The href attribute information item has:
A [normalized value] which is a representation of a URI referencing the part of
the package containing the data logically included by the [owner element]
(i.e., the xop:Include element information item). The [normalized value] MUST
be a valid URI per the cid: URI scheme (see [RFC 2392]). In addition, the
[normalized value] MUST be a valid lexical form of the XML Schema xs:anyURI
datatype (see [XML Schema Part 2: Datatypes Second Edition]3.2.17 anyURI).
{quote}
https://tools.ietf.org/html/rfc2392
{quote}
2. The MID and CID URL Schemes
The URLs take the form
content-id = url-addr-spec
message-id = url-addr-spec
url-addr-spec = addr-spec ; URL encoding of RFC 822 addr-spec
cid-url = "cid" ":" content-id
{quote}
So the value of {{<cop:Include>}}'s {{href}} attribute must always be
URL-Encoded.
As for the attachment part header, RFC2392 specifies the following:
{quote}
A "cid" URL is converted to the corresponding Content-ID message
header [MIME] by removing the "cid:" prefix, converting the % encoded
character to their equivalent US-ASCII characters, and enclosing the
remaining parts with an angle bracket pair, "<" and ">".
Reversing the process and converting URL special characters to their
% encodings produces the original cid.
{quote}
It looks to us as if CXF didn't take that URL-Encoding from the Specifications
into account when looking up MIME Attachments.
When I tried to reproduce the issue by forcing some special characters (in the
form of a prepended "http://";) into the generated Attachement-ID in
{{org.apache.xml.security.stax.impl.util.IDGenerator}}, it became apparent that
when CXF generates those Attachement-IDs, it doesn't take the URL Encoding into
account either. It generated:
{{code}}
<xop:Include href="cid:http://75f2d83d-026b-44bf-8825-6bd2b693d60e"/>
[...]
Content-ID: <http://75f2d83d-026b-44bf-8825-6bd2b693d60e>
{{code}}
... which violates the spec imho as {{<xop:Include>}}'s {{href}} contains
non-URL-Encoded characters.
That last bit (CXF generating messages) wouldn't be too much of an issue to me
personally, but CXF failing with what appears to be Spec-Compliant messages
must be considered a bug imho.
To reiterate: this issue prevents CXF from being compatible with the .NET SOAP
/ WebService Security stack and is a blocker for us.
was:
We found an issue when a CXF server is being called from a .NET client. The
relevant part of the stack trace looks like this:
{code}
Caused by: org.apache.wss4j.common.ext.WSSecurityException: Attachment not found
at
org.apache.wss4j.dom.util.EncryptionUtils.decryptEncryptedData(EncryptionUtils.java:215)
at
org.apache.wss4j.dom.processor.EncryptedKeyProcessor.decryptDataRef(EncryptedKeyProcessor.java:602)
at
org.apache.wss4j.dom.processor.EncryptedKeyProcessor.decryptDataRefs(EncryptedKeyProcessor.java:533)
at
org.apache.wss4j.dom.processor.EncryptedKeyProcessor.handleToken(EncryptedKeyProcessor.java:232)
at
org.apache.wss4j.dom.processor.EncryptedKeyProcessor.handleToken(EncryptedKeyProcessor.java:90)
at
org.apache.wss4j.dom.engine.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:340)
at
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessageInternal(WSS4JInInterceptor.java:320)
... 54 common frames omitted
Caused by: org.apache.wss4j.common.ext.WSSecurityException: Attachment not found
at
org.apache.wss4j.dom.util.EncryptionUtils.decryptXopAttachment(EncryptionUtils.java:376)
at
org.apache.wss4j.dom.util.EncryptionUtils.decryptEncryptedData(EncryptionUtils.java:207)
... 60 common frames omitted
{code}
So at first, it looks like the incoming message has issues with Attachment IDs.
Our actual request looks like this (shortened for readability):
{code}
POST /myservice HTTP/1.1
Host: localhost
MIME-Version:1.0
Content-Type:multipart/related;
type="application/xop+xml";start="<http://tempuri.org/0>";boundary="uuid:fad7c6a9-85d1-498b-a456-748c87de4d7d+id=1";start-info="text/xml"
--uuid:fad7c6a9-85d1-498b-a456-748c87de4d7d+id=1
Content-ID: <http://tempuri.org/0>
Content-Transfer-Encoding: 8bit
Content-Type: application/xop+xml;charset=utf-8;type="text/xml"
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/";>
<s:Header>
[...]
<Security>
[...]
<CipherData>
<CipherValue>
<xop:Include
href="cid:http%3A%2F%2Ftempuri.org%2F1%2F636966400494014846"
xmlns:xop="http://www.w3.org/2004/08/xop/include"/>
</CipherValue>
</CipherData>
[...]
</Security>
[...]
</s:Header>
<s:Body>
<EncryptedData>[...]</EncryptedData>
</s:Body>
</s:Envelope>
--uuid:fad7c6a9-85d1-498b-a456-748c87de4d7d+id=1
Content-ID: <http://tempuri.org/1/636966400494014846>
Content-Transfer-Encoding: binary
Content-Type: application/octet-stream
[...binary data...]
--uuid:fad7c6a9-85d1-498b-a456-748c87de4d7d+id=1--
{code}
Now, if you compare {{<xop:Include>}}'s {{href}} value with the {{Content-ID}}
in the attachment part header, you'll see that it is the same value, just
URL-Encoded in the former.
As weird as this may seem, It's actually specified that way in those locations:
https://www.w3.org/TR/xop10/#xop_href
{quote}
The href attribute information item has:
A [normalized value] which is a representation of a URI referencing the part of
the package containing the data logically included by the [owner element]
(i.e., the xop:Include element information item). The [normalized value] MUST
be a valid URI per the cid: URI scheme (see [RFC 2392]). In addition, the
[normalized value] MUST be a valid lexical form of the XML Schema xs:anyURI
datatype (see [XML Schema Part 2: Datatypes Second Edition]3.2.17 anyURI).
{quote}
https://tools.ietf.org/html/rfc2392
{quote}
2. The MID and CID URL Schemes
The URLs take the form
content-id = url-addr-spec
message-id = url-addr-spec
url-addr-spec = addr-spec ; URL encoding of RFC 822 addr-spec
cid-url = "cid" ":" content-id
{quote}
So the value of {{<cop:Include>}}'s {{href}} attribute must always be
URL-Encoded.
As for the attachment part header, RFC2392 specifies the following:
{quote}
A "cid" URL is converted to the corresponding Content-ID message
header [MIME] by removing the "cid:" prefix, converting the % encoded
character to their equivalent US-ASCII characters, and enclosing the
remaining parts with an angle bracket pair, "<" and ">".
Reversing the process and converting URL special characters to their
% encodings produces the original cid.
{quote}
It looks to us as if CXF didn't take that URL-Encoding from the Specifications
into account when looking up MIME Attachments.
When I tried to reproduce the issue by forcing some special characters (in the
form of a prepended "http://";) into the generated Attachement-ID in
{{org.apache.xml.security.stax.impl.util.IDGenerator}}, it became apparent that
when CXF generates those Attachement-IDs, it doesn't take the URL Encoding into
account either. It generated:
{{code}}
<xop:Include href="cid:http://75f2d83d-026b-44bf-8825-6bd2b693d60e"/>
[...]
Content-ID: <http://75f2d83d-026b-44bf-8825-6bd2b693d60e>
{{code}}
... which violates the spec imho as {{<xop:Include>}}'s {{href}} contains
non-URL-Encoded characters.
That last bit (CXF generating messages) wouldn't be too much of an issue to me
personally, but CXF failing with what appears to be Spec-Compliant messages
must be considered a bug imho.
To reiterate: this issue prevents CXF from being compatible with the .NET SOAP
/ WebService Security stack and is a blocker for us.
> MTOM Content-Id handling doesn't comply with RFC2392: .NET issues
> -----------------------------------------------------------------
>
> Key: CXF-8061
> URL: https://issues.apache.org/jira/browse/CXF-8061
> Project: CXF
> Issue Type: Bug
> Affects Versions: 3.3.2
> Reporter: Mike M.
> Priority: Blocker
>
> We found an issue when a CXF server is being called from a .NET client with
> WebService Security in place. The relevant part of the stack trace looks like
> this:
> {code}
> Caused by: org.apache.wss4j.common.ext.WSSecurityException: Attachment not
> found
> at
> org.apache.wss4j.dom.util.EncryptionUtils.decryptEncryptedData(EncryptionUtils.java:215)
> at
> org.apache.wss4j.dom.processor.EncryptedKeyProcessor.decryptDataRef(EncryptedKeyProcessor.java:602)
> at
> org.apache.wss4j.dom.processor.EncryptedKeyProcessor.decryptDataRefs(EncryptedKeyProcessor.java:533)
> at
> org.apache.wss4j.dom.processor.EncryptedKeyProcessor.handleToken(EncryptedKeyProcessor.java:232)
> at
> org.apache.wss4j.dom.processor.EncryptedKeyProcessor.handleToken(EncryptedKeyProcessor.java:90)
> at
> org.apache.wss4j.dom.engine.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:340)
> at
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessageInternal(WSS4JInInterceptor.java:320)
> ... 54 common frames omitted
> Caused by: org.apache.wss4j.common.ext.WSSecurityException: Attachment not
> found
> at
> org.apache.wss4j.dom.util.EncryptionUtils.decryptXopAttachment(EncryptionUtils.java:376)
> at
> org.apache.wss4j.dom.util.EncryptionUtils.decryptEncryptedData(EncryptionUtils.java:207)
> ... 60 common frames omitted
> {code}
> So at first, it looks like the incoming message has issues with Attachment
> IDs. Our actual request looks like this (shortened for readability):
> {code}
> POST /myservice HTTP/1.1
> Host: localhost
> MIME-Version:1.0
> Content-Type:multipart/related;
> type="application/xop+xml";start="<http://tempuri.org/0>";boundary="uuid:fad7c6a9-85d1-498b-a456-748c87de4d7d+id=1";start-info="text/xml"
> --uuid:fad7c6a9-85d1-498b-a456-748c87de4d7d+id=1
> Content-ID: <http://tempuri.org/0>
> Content-Transfer-Encoding: 8bit
> Content-Type: application/xop+xml;charset=utf-8;type="text/xml"
> <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/";>
> <s:Header>
> [...]
> <Security>
> [...]
> <CipherData>
> <CipherValue>
> <xop:Include
> href="cid:http%3A%2F%2Ftempuri.org%2F1%2F636966400494014846"
> xmlns:xop="http://www.w3.org/2004/08/xop/include"/>
> </CipherValue>
> </CipherData>
> [...]
> </Security>
> [...]
> </s:Header>
> <s:Body>
> <EncryptedData>[...]</EncryptedData>
> </s:Body>
> </s:Envelope>
> --uuid:fad7c6a9-85d1-498b-a456-748c87de4d7d+id=1
> Content-ID: <http://tempuri.org/1/636966400494014846>
> Content-Transfer-Encoding: binary
> Content-Type: application/octet-stream
> [...binary data...]
> --uuid:fad7c6a9-85d1-498b-a456-748c87de4d7d+id=1--
> {code}
> Now, if you compare {{<xop:Include>}}'s {{href}} value with the
> {{Content-ID}} in the attachment part header, you'll see that it is the same
> value, just URL-Encoded in the former.
> As weird as this may seem, It's actually specified that way in those
> locations:
> https://www.w3.org/TR/xop10/#xop_href
> {quote}
> The href attribute information item has:
> A [normalized value] which is a representation of a URI referencing the part
> of the package containing the data logically included by the [owner element]
> (i.e., the xop:Include element information item). The [normalized value] MUST
> be a valid URI per the cid: URI scheme (see [RFC 2392]). In addition, the
> [normalized value] MUST be a valid lexical form of the XML Schema xs:anyURI
> datatype (see [XML Schema Part 2: Datatypes Second Edition]3.2.17 anyURI).
> {quote}
> https://tools.ietf.org/html/rfc2392
> {quote}
> 2. The MID and CID URL Schemes
> The URLs take the form
> content-id = url-addr-spec
> message-id = url-addr-spec
> url-addr-spec = addr-spec ; URL encoding of RFC 822 addr-spec
> cid-url = "cid" ":" content-id
> {quote}
> So the value of {{<cop:Include>}}'s {{href}} attribute must always be
> URL-Encoded.
> As for the attachment part header, RFC2392 specifies the following:
> {quote}
> A "cid" URL is converted to the corresponding Content-ID message
> header [MIME] by removing the "cid:" prefix, converting the % encoded
> character to their equivalent US-ASCII characters, and enclosing the
> remaining parts with an angle bracket pair, "<" and ">".
> Reversing the process and converting URL special characters to their
> % encodings produces the original cid.
> {quote}
> It looks to us as if CXF didn't take that URL-Encoding from the
> Specifications into account when looking up MIME Attachments.
> When I tried to reproduce the issue by forcing some special characters (in
> the form of a prepended "http://";) into the generated Attachement-ID in
> {{org.apache.xml.security.stax.impl.util.IDGenerator}}, it became apparent
> that when CXF generates those Attachement-IDs, it doesn't take the URL
> Encoding into account either. It generated:
> {{code}}
> <xop:Include href="cid:http://75f2d83d-026b-44bf-8825-6bd2b693d60e"/>
> [...]
> Content-ID: <http://75f2d83d-026b-44bf-8825-6bd2b693d60e>
> {{code}}
> ... which violates the spec imho as {{<xop:Include>}}'s {{href}} contains
> non-URL-Encoded characters.
> That last bit (CXF generating messages) wouldn't be too much of an issue to
> me personally, but CXF failing with what appears to be Spec-Compliant
> messages must be considered a bug imho.
> To reiterate: this issue prevents CXF from being compatible with the .NET
> SOAP / WebService Security stack and is a blocker for us.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
