Re: SOAP/XML Protocol and filtering, etc.

[Mark Nottingham <mnot () akamai com>]

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
enforce policy.

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).

Cheers,



On Tue, May 08, 2001 at 12:48:01AM +1000, Darren Reed wrote:
> Hi Mark,
>         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 [3]
>
> 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) [4]
>
> 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 [5].
>
> 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
> SOAP filtering.
>
> Darren

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)
_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://www.nfr.com/mailman/listinfo/firewall-wizards