Firewall Wizards mailing list archives
Re: SOAP/XML Protocol and filtering, etc.
From: Bill_Royds () pch gc ca
Date: Mon, 7 May 2001 10:42:18 -0400
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
Current thread:
- SOAP/XML Protocol and filtering, etc. Mark Nottingham (May 07)
- Re: SOAP/XML Protocol and filtering, etc. Darren Reed (May 07)
- Re: SOAP/XML Protocol and filtering, etc. Mark Nottingham (May 07)
- Re: SOAP/XML Protocol and filtering, etc. Darren Reed (May 08)
- Re: Re: SOAP/XML Protocol and filtering, etc. Barney Wolff (May 08)
- Re: SOAP/XML Protocol and filtering, etc. Mark Nottingham (May 07)
- <Possible follow-ups>
- Re: SOAP/XML Protocol and filtering, etc. Bill_Royds (May 07)
- RE: SOAP/XML Protocol and filtering, etc. Dawes, Rogan (ZA - Johannesburg) (May 07)
- RE: SOAP/XML Protocol and filtering, etc. Nigel Willson (May 10)
- RE: SOAP/XML Protocol and filtering, etc. Dawes, Rogan (ZA - Johannesburg) (May 10)
- Re: SOAP/XML Protocol and filtering, etc. Darren Reed (May 07)