security issues in the soap binding

Colleagues,

I tried to write up a definitive note on the security issues in
the current SOAP binding, but I ended up with this rambling thing.
I figure it will be a hot topic today, so I'm opting to get it out
earlier rather than later.  Hope you find it useful.

        /r$

In this note, I use the term "refp's" to refer to both reference
properties and parameters; most of them time it doesn't matter.

The current SOAP binding says that each refp element within an
endpoint reference becomes a SOAP header block; see example 2-1
in the SOAP binding document.  I call this process "promotion"
because it takes an element embedded within an EPR and pushes it
up into the SOAP header as a first-class element.  I am not aware
of any other spec that does this kind of promotion; is anyone?

So let me summarize, using this terminology:
    There are security issues with promoting ws-addr refp's

SOAP is architected for multi-hop processing, and we must not
break that, either through direct action, or -- in my opinion
-- by weakening the security architecture.  It seems to me that
header promotion requires close coupling among application layers,
or else breaks security.  I admit that's a loaded term, "breaks
security";  I don't use it lightly.  While almost anything is
theoretically possible, it's very important that the security
approach be practical.

For example, a solution that requires the recipient to parse,
understand, and trust *two* signers is probably not practical unless
one of them is the recipient itself.  Our systems (and WS protocols)
are barely at the point where a receiver can be configured to
trust the right client to send a message.  I claim that doubling
the number of signatures, and mandating that different parts of a
SOAP message be signed by Alice, while another set of parts must
be signed by Eve, is too difficult to define and implement, and
therefore breaks security.

(There is also the overhead of doubling the signatures; allow around
1K per signature as a rough measure.)

In an earlier message,
http://lists.w3.org/Archives/Public/public-ws-addressing/2004Nov/0562.html
I tried to explain some of the multi-hop scenarios.  I hope
I don't repeat myself here.  Instead, let me summarize:  without
end-to-end security, a sender of a message must trust that every
intermediate (be it SOAP intermediary, store-and-forward server
like BizTalk, XML security appliance like ours, etc.), must be fully
trusted.  This includes the software itself, as well as anyone who
could possibly have access to the machine.

That's a pretty big trust boundary.  Luckily we probably don't have
to worry about the IP-level routers, firewalls, etc.  But still, does
ws-addr want to make the requirement that a sender must have complete
trust in every XML-processing node that sees a SOAP message as it
makes it way to the ultimate recipient?  The answer is clearly no.
Therefore, we must have end-to-end security.

There are three types of attacks on promoted headers: modification,
deletion, and injection.  Our only end-to-end protection against all
of these is through use of XML-DSIG.

It is easy to notice a modification of a promoted message header; the
signature will not verify.  This assumes that the header was signed,
which has issues, but we can consider this to be a solved problem.

Detecting that a promoted header was deleted has some interesting
subtleties.  How can the recipient know that a header was deleted?
Either the signature must contain a list of signed headers, so
that the server can identify omissions (the signature will fail
to verify), or the server itself must Fault the message if any of
its headers are omitted.  This places an implementation constraint
on the server that may not be acceptable: for a given operation,
the server must always require the same refp's.  (Of course, some
can be empty, but they must be there.)

The final attack, header injection, also brings complications.
The promoted headers must be tied to the specific message, else an
adversary can strip them off and replay them with another message.
If Eve sends a message to Alice with signed headers, Mallory can make
a copy and add them to Bob's message.  How can this be prevented?
Either the headers must be attached to Alice's message, or the *lack
of headers* must be indicated in Bob's message.  The only way to
do this is to have Alice and/or Bob aware of the promoted headers.

Let me emphasize that because WS-Addressing is the only spec that
does promotion, it's important to realize that this is *not* an
attack on the general SOAP processing model.  In most other cases,
either the originator will have composed the entire message, or the
individual WS-xxx parts will have injected self-identifying headers.
It is only with WS-Addressing, that the generic SOAP headers are
created.

It is important to be able to simply state the security policy.
It helps security implementors (who need all the help they can
get:), it helps application developers make informed decisions,
and it helps an organization prove compliance with internal rules
or external regulations.

For example, "sign the message body, any WS-ReliableMessaging header,
and the WS-Addressing headers" is a reaonable policy.  Because of
promotion, however, it now becomes necessary to explicitly list the
QName's of the new headers that must be signed. This must be dynamic,
since reference properties can vary per-operation.  Implementing
a policy to sign addressing headers requires that the holder of the EPR
convey the information to the WS-Security layer.  It probably also
requires that WS-Security happen after WS-Addressing, or that WS-Sec
does the SOAP binding work for WS-Addressing.

Either way, it seems to require a fairly close coupling, for every
operation, between the message originator and the security layer.
I could be quite wrong, and would love to see examples of something like
a Websphere (or other j2ee) config file that shows otherwise, or the set
of annotations one could put on an Indigo or WSE C# class.

The only way to avoid per-message tight coupling is to make the promoted
headers be self-identifying, either by generic wrapper with a well-known
QName, or by using a well-known attribute.  An attribute gets messy,
it requires an XPath transformation in the digital signature:
    <tns:myheader wsa:Use="wsa:RefProp">
        <...>
    </tns:myheader>
needs this XPath
    not(ancestor-or-self::tns:myheader/@wsa:Use)
but this is already getting too long, so I'll stop.

-- 
Rich Salz                  Chief Security Architect
DataPower Technology       http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
XML Security Overview      http://www.datapower.com/xmldev/xmlsecurity.html

Received on Tuesday, 7 December 2004 16:48:22 UTC