[
Lists Home |
Date Index |
Thread Index
]
Michael Brennan wrote:
>
>...
>
> Personally, I think you make valid points. What I take issue with is the
> notion that SOAP has introduced something fundamentally new into the mix.
Thread 1:
Q: "Why do you use SOAP?
A: "Because it is SO EASY to wrap up business logic into a component and
throw it onto the Web and have a web service. Microsoft has a tool to do
it."
Thread 2:
Q: "How is SOAP any different from other abuses of HTTP?"
A: "Because it is *specifically designed* to make doing things the wrong
way easy."
Is SOAP in and of itself a security hole? No. Will it give rise to more
security holes than other approaches? I'll wrap myself again in the
Bruce Schneier flag.
> ... I
> still think the focus on RPC misses the point. It's still just XML over
> HTTP,
XML over HTTP is not necessarily abuse of HTTP. SOAP is abuse of HTTP.
If you show me a particular example of XML over HTTP then I'll tell you
whether or not it is working against the security of the Web.
Barring RPC, it is much, much easier to use XML over HTTP in a way that
respects HTTP than to try and work around it. So people do. But RPC
makes it easier to use XML over HTTP in the *wrong way*. You're
simplifying the mechanism for doing things in the wrong way and thus
introducing a bias against doing things the right way.
> ... and I don't see how the RPC approach to SOAP is really fundamentally
> different from the applications developers are doing that accept HTML form
> posts.
It's radically different because there is no easy way to build a bridge
from form posts to arbitrary COM objects, is there? It takes effort. It
takes mediation. The extra effort introduces a layer of indirection
which makes security holes less likely.
If you continue to think the issue RPC is irrelevant than I'll ask again
why no RPC protocol (not an RPC-based protocol, but an RPC protocol) has
ever become popular on the public Internet. And if SOAP does so by
working around the firewalls that system administrators put in to *stop
RPC* will it be an accomplishment?
> In fact, with existing tools its easier for me to expose logic via an
> HTTP post using HTML forms than it is for me to use SOAP, and I'm hiding
> things just as much as with SOAP.
Expose logic, yes. Expose your applications internal behaviours? No.
Because your application is probably a COM object and nothing could be
easier than spewing out a SOAP layer from a COM object through visual
studio.
> ... I fail to see how pointy brackets vs.
> name/value pairs poses an inherent new security risk. You can use either to
> invoke logic behind the firewall.
Pointy brackets have nothing to do with it.
* It's about the semantics. Application protocols have application
semantics. RPC protocols do not.*
* It's about the semantics. Application protocols have application
semantics. RPC protocols do not.*
* It's about the semantics. Application protocols have application
semantics. RPC protocols do not.*
Bruce S. says this. Roy Fielding says this. I say this. Long before I
had heard of SOAP I thought it was common knowledge that you don't let
RPCs through your firewall because *you can't know what they are doing
because they have no application semantics*. If I run "netstat" and see
that I'm running with an open SMTP port then I know exactly what kinds
of data will come through that port...email. If I see port 80 then I
know (or used to know) that that's web traffic and will go to IIS. But
when RPC starts streaming through, any packet could be directed to any
application and do anything whatsoever because RPC protocols have no
application semantics.
> SOAP-RPC seems to me to just be building upon the approach toward building
> web systems that started with CGIs. I don't see SOAP as having introduced
> anything fundamentally new into the mix in this regard. I've found this
> whole REST debate to be interesting and enlightening. I feel those of us
> building web apps could learn quite a bit from REST. What I don't see is why
> some folks are picking on SOAP so much and suggesting that this is somehow
> intrinsically worse than all of those CGI programs out there accepting a
> bunch of form posts through one big fat honking resource -- all with content
> that is just "application/x-www-urlencoded" or "multipart/form-data".
It seems to be damning SOAP with faint praise to say that it isn't much
worse than other abuses of the infrastucture that you can already pull
off. Somehow it seems a little different to me when a lone programmer
engages in an abuse versus the world's biggest software company.
> ... That I
> don't understand. Developers are left with the impression from Bruce
> Shneier's criticism (and that of others) that there is something
> fundamentally new about SOAP that poses greater security risks to the
> network.
Just wait until someone installs a SOAP-DCOM bridge inside a big
corporation. We'll see the sparks fly then, baby. Please describe what
the analogous bridge looks like for HTTP and CGI. You could implement it
but you'd be reimplementing SOAP. And why would you do that when you
could just use ... SOAP. SOAP was always designed to allow the routing
of DCOM over firewalls.
Think about it...all of the infrastructure software companies in the
world are working together to sell FIREWALL SUBVERSION TECHNOLOGY. And
they advertise it as such. Doesn't that seem a little strange to you???
If system administrators wanted to allow RPC through their firewalls
they could have done it six years ago. They don't need Microsoft's help.
>...
> On the other hand, if the criticism is simply over vendors failing to put
> enough emphasis on security issues, I don't disagree. The vendor push behind
> SOAP is pouring gasoline on the fire with regard to pervasive security
> problems in software today. But I don't see anything inherent in SOAP that
> is making things worse than they already are.
SOAP is designed to make things worse. It is designed to evade detection
at the firewall and to make it "easy" to expose your application's logic
to the network.
Paul Prescod
|
