Nmap Security Scanner
*Intro
*Ref Guide
*Install Guide
*Download
*Changelog
*Book
*Docs
Security Lists
*Nmap Hackers
*Nmap Dev
*Bugtraq
*Full Disclosure
*Pen Test
*Basics
*More
Security Tools
*Pass crackers
*Sniffers
*Vuln Scanners
*Web scanners
*Wireless
*Exploitation
*Packet crafters
*More
Site News
Site Search:
Exploit World
Advertising
About/Contact
Credits
Sponsors:
edgeos network security services platform







Firewall Wizards: Re: SOAP/XML Protocol and filtering, etc.

Re: SOAP/XML Protocol and filtering, etc.

From: Darren Reed <darrenr_at_reed.wattle.id.au>
Date: Tue, 8 May 2001 00:48:01 +1000 (EST)

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
_______________________________________________
firewall-wizards mailing list
firewall-wizards_at_nfr.com
http://www.nfr.com/mailman/listinfo/firewall-wizards
Received on May 07 2001

[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]