Firewall Wizards mailing list archives
RE: SOAP/XML Protocol and filtering, etc.
From: Nigel Willson <NWillson () tbg com>
Date: Wed, 9 May 2001 12:36:50 -0600
Which leads to the notion that the last line of defense is the application server that will process the request and is most capable. Firewalls are well past their sell-by date and if any port is open then a protocol can be layered/tunnelled through it -- rendering the Firewall only a primary defense layer. Let them do the thing they do best. Proxies are typically a second line of defense, with more intelligence and ability to filter the traffic once the noise has been screened. The issue is developing proxies and keeping pace with the sophistication of evolving fluid applications. So the bottom line seems the be that the application server itself, 1. needs a firewall service on its listening ports so that it is protected according to its role and policy, 2. needs a "proxy" policy-based pre-processor that will parse transactions and discard those not authorized/specifically allowed/malicious.
-----Original Message----- From: Dawes, Rogan (ZA - Johannesburg) [mailto:rdawes () deloitte co za] Sent: Monday, May 07, 2001 7:16 AM To: 'Mark Nottingham'; firewall-wizards () nfr com Subject: RE: [fw-wiz] SOAP/XML Protocol and filtering, etc. 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. Rogan -----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 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 _______________________________________________ firewall-wizards mailing list firewall-wizards () nfr com http://www.nfr.com/mailman/listinfo/firewall-wizards
_______________________________________________ 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)