[
Lists Home |
Date Index |
Thread Index
]
Joshua Allen wrote:
>
> > "And one of the simplest, strongest, and safest models is to enforce a
> > rigid separation of data and code. The commingling of data and code is
>
> > responsible for a great many security problems...
>
> What does that have to do with SOAP? SOAP is explicitly *not* about
> mingling code with data. It is impossible for me to imagine how
> "commingling data and code" could become "SOAP".
I agree. SOAP does not co-mingle code with data.
It does, on the other hand, encourage a thin layer between business
logic and implementation rather than a thick one. "Just download the
toolkit, generate your WSDL from your existing COM object and you've got
a web service." That's probably fine within the intranet so I'm not
going to say that the tools are inherently broken but I would strongly
discourage anyone from using them in that way on the public Internet.
> > "Implementation of Microsoft [sic] SOAP, a protocol running over HTTP
> > precisely so it could bypass firewalls, should be withdrawn. According
> to
>
> This is a totally different issue. If the purpose of SOAP were to
> bypass firewalls, I would agree with this statement. But that is
> completely wrong.
No, it isn't wrong. In the early days of SOAP this was exactly how it
was promoted.
http://www.microsoft.com/mind/0100/soap/soap.asp
"Since SOAP relies on HTTP as the transport mechanism, and most
firewalls allow HTTP to pass through, you'll have no problem invoking
SOAP endpoints from either side of a firewall. Don't forget that SOAP
makes it possible for system administrators to configure firewalls to
selectively block out SOAP requests using SOAP-specific HTTP headers."
Here's Don Box:
"The network protocols used by these three technologies tend to require
a non-trivial amount of run-time support to function properly.
Ironically, while Microsoft and the Object Management Group (OMG) were
arguing over whether the Internet would be run on DCOM or CORBA, the
Hypertext Transfer Protocol (HTTP) took over as the dominant Internet
protocol. Like many other successful Internet protocols, HTTP is simple,
text-based, and requires very little run-time support to work properly.
Additionally, many corporate firewalls block DCOM and CORBA traffic,
while happily allowing HTTP packets into their (mostly) guarded
networks."
Over the last couple of years the rhetoric around SOAP has become a
little bit more genteel when CIOs started screaming bloody hell.
* http://www.vnunet.com/News/1103805
* http://rr.sans.org/start/myths.php
But wink, wink, nod, nod, we all know why SOAP is not defined on top of
UDP or even TCP like RPC protocols of the past and modern XML-based
protocols like Jabber and BEEP.
Oops, turns out that even today the rhetoric is not that well tuned:
"Middle-tier business functionality exposed via standard Web protocols
is known as XML Web services. XML Web services utilize HTTP as a
transport allowing remote method requests to pass through enterprise
firewalls."
http://msdn.microsoft.com/vstudio/techinfo/articles/XMLwebservices/webservices.asp
> ... SOAP does not "rely on HTTP as the transport
> mechanism", and just because SOAP *can* use HTTP as a transport
> mechanism, that does not mean that SOAP was designed to circumvent
> security. The statement is shamefully wrong (and I am not sure what
> "Microsoft documentation" that was taken from, but I am sure that it is
> out of context.
See above.
>...
> Melissa spread mostly through SMTP. The issue with Melissa was that the
> mail client allowed commingling of data and code, which is a legitimate
> problem. It had nothing to do with RPC vs. REST.
I agree and pointed this out. There is nothing technically in common
between Melissa and RPC. The only thing in common is a misunderstanding
at the world's biggest software company of how to do security right. The
details of what they've got wrong in the two situations are totally
different.
> > the other hand, I can imagine people getting carried away and making
> all
> > sorts of OS-level stuff accessible via SOAP-RPC without thinking too
> hard
>
> This has nothing to do with RPC vs. REST. I remember when Rob McCool's
> HTTPD first started to proliferate and people started hooking up CGI to
> /bin/sh. It was really cool; you could do http://someserver/sh?rm+-rf+.
>
> REST is about "representation" of resources, and that "representation"
> is assumed to be mediated in some way from the real underlying resource.
> That mediation involves running code, period.
Right, and mediation is a good thing in terms of security of public
services. So REST has that much right, right? And CGI for all of its
flaws, at last *requires* mediation. Where is the mediation in the RPC
example discussed here:
http://msdn.microsoft.com/vstudio/techinfo/articles/XMLwebservices/webservices.asp
By the way, "http://someserver/sh?rm+-rf+"; is classic RPC. You've got an
endpoint. You are sending it methods. It happens to be sh rather than
C#.
> > scenarios where business services are exposed via SOAP? And is it
> > generally accepted that a REST-ful worm couldn't happen, or is this
>
> Of course a worm could occur in REST just as easily as with RPC.
> Actually, I don't think you could claim that any of the recent worms
> have been RPC-based. It is debatable whether they had anything to do
> with REST.
I'm sure that some of them went over HTTP as Microsoft uses HTTP (and
probably REST!) to talk between Outlook Express and HoTMaiL.
>...
> Not true at all. PUT and POST could modify (in pathogenic cases, which
> is what worms exploit) code used to generate the resource
> representation. This has in fact been done with the many Perl-based
> code injection exploits that used to be so common (knowing that the CGI
> used Perl to query the resource allowed people to supply parameters that
> contained special characters to fool the Perl into doing something
> else).
That was a big problem. The Perl world eventually learned the value of
mediation and transformation. Alot of that knowledge was incorported
into HTTP-centric client and server components.
Now we're back to this:
http://msdn.microsoft.com/vstudio/techinfo/articles/XMLwebservices/webservices.asp
I'll repeat, okay on the Intranet. Scary as hell on the Internet. I
don't hear Microsoft, Sun or anyone making that distinction though. Web
Services are easy. Click click, generate a WSDL, deploy to IIS. You're
done. Note that that document doesn't talk about deploying on the
Intranet. It talks about the *Internet*. And all it says about security
is: "For security, use of the Secure Sockets Layer (SSL) protocol is
supported, as well as standard Web authentication techniques." I can
tell from talking to you that you understand as well as I do that
SECURITY IS NOT A CHECKLIST ITEM.
> > mechanism exists for the remote
> > user to execute code directly.
>
> Again, I don't understand this. RPC does not pass code to the server.
> The user does not "execute code directly". The user passes some
> parameters, and the server executes whichever code it has been
> configured to execute in response. Same as happens with REST.
The difference is that at the heart of REST philosophy is
network->implementation mediation as you put it. At the heart of RPC
philosophy is making the network look invisible. Or if it isn't at the
heart of the philosophy it is at least what is being sold.
REST doesn't directly address security. But it indirectly does by:
a) discouraging people from reinventing wheels:
* use the existing namespace
* use the existing protocols
* use the existing methods
* if at all possible, use existing XML vocabularies
b) encouraging people to use standards with well-undersood security
characteristics rather than forcing standards bodies to reinvent wheels
c) encouraging a layer of mediation between implementation (resources)
and interface (representations). If you design in a REST-ful style you
almost cannot avoid this level of mediation because of the gap between
business logic expressed in terms of objects with arbitrary methods and
the Web, with its fixed methods and URI namespace
d) putting everything into a common namespace so that a common UI and
model can be used for permissions.
e) restricting developers to a limited set of methods with security
characteristics that are already understood by security admins.
f) making impossible (at least thus far) the generation of public
interface descriptions from the type signatures of implementations
f) discouraging the tunnelling of one application protocol on top of
another.
g) centralizing protocol design in one or two protocols instead of a
new application protocol for each business problem (which is what you
get when implement on top of RPC)
REST is not a security panacea. There is no silver bullet. All we can do
is evaluate each layer's *contribution* to security. SOAP's is negative.
It detracts from the security of the protocols that it runs on top of.
If that were not the case then you would not be defensive about the idea
that SOAP is designed to bypass firewalls.
Paul Prescod
|
