From: Jim Whitehead (ejw@ics.uci.edu)
Date: Thu Aug 31 2000 - 13:56:07 PDT
> This is kind of a red herring, no? GET requests can have the same
> semantic effects on the back-end database of a server as a POST or PUT
> can, depending on the code processing them. If I choose to architect my
> application that way, I can get around all the 'community approval' of
> the semantics of HTTP.
I disagree -- this kind of analysis has to be based on conventional use of
the protocol. It's axiomatic that, if a protocol provides a way to transmit
information from client to server, this information channel could be used to
host an arbitrary RPC.
The fact that an RPC *can* be hosted on information stored in URLs doesn't
mean that a security analysis cannot be performed based on the normal use of
the protocol. Such extra-protocol RPCs should be taken into consideration
when performing the analysis, but they can be considered as exceptions to
normal use security. With SOAP and general RPC, it is not even possible to
do this normal use security analysis -- it is all risky, from day 1.
> The real issue is that the web is so fundamental to so many companies
> doing business these days that HTTP can't really be blocked at the
> firewall.
This is true, although it is based on HTTP after it has achieved lock-in.
SOAP hasn't achieved lock-in, and so discussing such issues as how firewall
administrators will perceive the security of SOAP is still relevant.
- Jim
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 14:09:20 PDT