I think you have left out one option, which would be ideal, though less
likely :-)
The application itself is well (securely) coded, and comes by default with
no transactions enabled. Those transactions required must be specifically
enabled.
Rogan
-----Original Message-----
From: Nigel Willson [mailto:NWillson_at_tbg.com]
Sent: 09 May 2001 08:37
To: 'Dawes, Rogan (ZA - Johannesburg)'; 'Mark Nottingham';
firewall-wizards_at_nfr.com
Subject: RE: [fw-wiz] SOAP/XML Protocol and filtering, etc.
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_at_deloitte.co.za]
> Sent: Monday, May 07, 2001 7:16 AM
> To: 'Mark Nottingham'; firewall-wizards_at_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_at_akamai.com]
> Sent: 07 May 2001 07:46
> To: firewall-wizards_at_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_at_nfr.com
> http://www.nfr.com/mailman/listinfo/firewall-wizards
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards_at_nfr.com
> http://www.nfr.com/mailman/listinfo/firewall-wizards
>
_______________________________________________
firewall-wizards mailing list
firewall-wizards_at_nfr.com
http://www.nfr.com/mailman/listinfo/firewall-wizards
Received on May 10 2001
Intro
