Re: SOAP/XML Protocol and filtering, etc.

[Bill_Royds () pch gc ca]

There was an earlier conversation about this that looked at risks with SOAP
through HTTP. THe feeling was that we feared that SOAP would allow anything to
be tunneled over HTTP, necessitating restricting SOAP altogether.
The main problem is ensuring that the syntax of the proposal is strict enough
that the limits on semantics are captured.
Since a firewall is looking at a stream for syntax violations for the most part
and not actually executing the command, it has difficulty with commands that are
open ended in syntax, as witness the recent problems with Unicode on IIS. Having
a match between HTTP headers and bodies helps to bound the possible states to
check.
Thus option 1 is not firewall friendly becaue it allows actions in SOAPaction
header to be combined with essentially aribtrary data. Option 2 is safest while
3 is similar to what happens now.
 Something else that would be useful for firewalls is a way to maintain state
over a SOAP session. An arbitrary but inique identifier in HTTP header (part of
SOAPaction header perhaps)created by first SOAPaction request and echoed on
further transactions linked to that request would allow the application firewall
to maintain the stream and preven cross URI transfer of data if not allowed by
security policy.
  Most present application gateway firewalls like Raptor, Sidewinder, Gauntley
et al. do match the HTTP actions and headers with argument checking.
So, for example, a GET command must have a valid URI following it follwed by a
HTTP version command or nothing separated by blanks. Extra stuff on the line
will cause it to be rejected.
  Most of the time, Application gateways look at the HTTP part (headers) for
control and the body part for syntax only (terminated properly with CR/LF blank
line between headers and body etc.). They don't normally ahve the ability to
actually parse the HTML or XML.
So it is important to have the SOAPaction header match the SOAP xml code in the
body. That at least provides some place for authentication. If the body allowed
arbitrary SOAP commands with the header indicating anything, security would
require rejecting any SOAP.




Mark Nottingham <mnot () akamai com> on 05/07/2001 01:45:56 AM
                                                              
                                                              
                                                              
 To:      firewall-wizards () nfr com                            
                                                              
 cc:      (bcc: Bill Royds/HullOttawa/PCH/CA)                 
                                                              
                                                              
                                                              
 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
communities.

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
http://www.nfr.com/mailman/listinfo/firewall-wizards