Home page logo

firewall-wizards logo Firewall Wizards mailing list archives

RE: SOAP/XML Protocol and filtering, etc.
From: "Dawes, Rogan (ZA - Johannesburg)" <rdawes () deloitte co za>
Date: Mon, 7 May 2001 16:16:01 +0200

Hi Mark,

The key thing to me is, what happens if the SOAPAction and the URI disagree?

It would be simple to craft a message that would pass the firewall, based on
the SOAPAction header, but turn out to call a completely different function
based on the content of the XML.

This suggests a flaw where one party (the firewall) permits an action, based
on some information (the SOAPAction header), while the next party (the
web-server/application server) takes action based on other information (the
actual content of the XML)

This seems to be asking for trouble.

I would be happier to have a proxy that parsed the XML and took action based
on the same information that the application server would be using.


-----Original Message-----
From: Mark Nottingham [mailto:mnot () akamai com]
Sent: 07 May 2001 07:46
To: firewall-wizards () nfr com
Subject: [fw-wiz] SOAP/XML Protocol and filtering, etc.

[This was originally posted on the main IETF list, and it was
suggested that this was a good place to go for input...]

The W3C's XML Protocol WG [1], which is chartered with developing
XML-based messaging based on SOAP [2], has been debating the merits
of the SOAPAction header in SOAP's HTTP binding. I've taken it upon
myself (with some misgivings ;) to solicit comments on the designs
being discussed.

Briefly, SOAPAction is intended to identify a service being accessed,
independently from its URL. For example, if you're accessing a
StockQuote service, you might put a URI which identifies this type of
service in the SOAPAction header.

The primary motivation of this is to allow firewall and filtering
proxies to identify SOAP messages in HTTP and act appropriately.

Some implementations and/or applications of SOAP also use SOAPAction
for dispatch, but that's out of scope for this discussion.

The three major designs being proposed are:
  - allow any arbitrary URI to be placed in the SOAPAction header [3]
  - 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]
  - removing SOAPAction and requiring that only one service be
    associated with any particular URI [5]

I feel that if we're going to design something to satisfy an external
requirement ("make SOAP play nice with firewalls, so they don't just
block all SOAP messages"), we should consult with the affected

So, I would very much appreciate:
  - constructive comments as to the designs 
  - pointers to mailing lists, etc. of communities that would be
    interested in these issues (firewall admins, etc.)
  - discussion of whether any such hints will be helpful for the
    target audience
  - pointers to filtering/access control techniques already used,
    with particular emphasis on whether or not any current
    implementations can identify HTTP headers and act upon them.

Kind regards,

[1] http://www.w3.org/2000/xp/Group/
[2] http://www.w3.org/TR/SOAP
[3] http://lists.w3.org/Archives/Public/xml-dist-app/2001Apr/0142.html
[4] http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0026.html
[5] http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0055.html

Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)
firewall-wizards mailing list
firewall-wizards () nfr com
firewall-wizards mailing list
firewall-wizards () nfr com

  By Date           By Thread  

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