mailing list archives
Re: SOAP/XML Protocol and filtering, etc.
From: Mark Nottingham <mnot () akamai com>
Date: Mon, 7 May 2001 08:42:43 -0700
Darren and all,
Thanks for the comments. Please keep them coming.
I tend to think of SOAPAction this way, recently;
A malicious user cooperating with an external server can easily work
to get arbitrary messages through a firewall or proxy that allows
HTTP to pass through. This possibility is independent of SOAP; while
they might use SOAP toolkits for convenience, they could just as
easily modify them, or cook them up separately.
So, SOAPAction is useless in terms of stopping or detecting malicious
users. However, it *may* provide value in that it can be used to
For example, a company may decide that it doesn't
want purchase orders to be sent by SOAP, but doesn't mind other
services, like stock quotes. If option #2 were implemented, it could
block any messages with a SOAPAction containing the namespace URI of
known purchase order messages.
The questions that this brings up, then, are:
- does this offer significant value over traditional URI filtering?
- does it cause more harm than good because people will think of it
as a security mechanism?
Re: DTD - I think you mean valid, not well-formed. I'm not sure what
value this would add, except to get errors back more quickly ;)
AFAIK, I don't think there can be a DTD for SOAP documents, because
they're not strictly valid; they contain tags from a number of
namespaces, and are dynamically constructed from modules (what we're
calling 'blocks' now).
On Tue, May 08, 2001 at 12:48:01AM +1000, Darren Reed wrote:
Let me add some thoughts....I've been playing with XML of late
and have found it an interesting game, along with DTD's and such.
The three major designs being proposed are:
- allow any arbitrary URI to be placed in the SOAPAction header 
Has any consideration been given to a maximum length ?
- force the content of the SOAPAction header to be the same as the
top-level XML namespace in the message body, thereby identifying
what kind of message it is (making this information available in
the header removes the requirement that the intermediary parse
the XML) 
I don't agree with that argument. What it does allow is for the firewall
to enforce a proper relationship between SOAPAction and the XML document.
Who's to say that both endpoints involved in the SOAP communication are
bug free with respect to enforcing this rule?
So where does that put you?
You can't trust the SOAPAction to be correct (if the message is transitting
a firewall) so you may as well ignore it. Thus you're going to need to parse
the SOAP document anyway to verify that SOAPAction matches the first element.
I.e. what's the point of having the SOAPAction there in the first place?
Also, why repeat the same information twice?
In some sense it's like saying the MIME type is an authorative comment on
what the content of an email body actually is. This is far from the truth,
even though 9 times out of 10 it will be a match because that's where the
real benefit comes from for users, today.
Hmmm, the more I think about what's going on there, the more I agree with
your comments in .
What I'm curious about is how and why the URI in SOAPAction might be
different to that in the HTTP method. i.e why shouldn't they both start
at / ? What if a firewall sees a SOAPAction and HTTP method that are
vastly different after the leading / ? Since XML/SOAP is self describing
using text and the content type is already xml, what real meaning or role
can SOAPAction apart from being a dangerous shortcut?
Something I notice that is missing from the SOAP document and that's a DTD.
That'd be of real value to a firewall since it could use that to enforce
all SOAP documents were well formed before allowing them through. It might
take CPU and a few milliseconds, but it does give you added value in your
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)
firewall-wizards mailing list
firewall-wizards () nfr com