[
Lists Home |
Date Index |
Thread Index
]
I'm sold on
1. Training before development of web services.
2. Inspection prior to deployment of web services.
3. Security testing suites.
4. Properly constructed contracts for web services
that include security provisions and remediation clauses.
Which is how the best will do business anyway and buying
less than quality is a mistake to begin with. I think that
list above is a good one for the WSIO to consider.
I'm not sold on but convinced that web services will result
in some web service business types becoming regulated businesses
just as the utilities are. It will take some years and
a change of administration for that to happen, and probably,
a catastrophe to get their attention.
len
-----Original Message-----
From: Michael Brennan [mailto:Michael_Brennan@Allegis.com
> From: Mike Champion [mailto:mc@xegesis.org]
<snip/>
> Is that an appropriate analogy? Is the potential security
> problem we've
> been talking about at the tool level rather than the protocol level?
> And how likely is it that a semi-competent developer using a modern
> web services wizard would "cut his arm off" accidentally?
I think Paul has valid points. But I think the far bigger danger is not SOAP
itself, but these power tools in the hands of *naive* developers.
I recently remembered a real world "security breach" that I thought I'd add
to the discussion. This is something I was informed of by a client when I
worked as a consultant a couple of years ago. For obvious reasons, I won't
go into great detail (or name any names).
While working on an unrelated project, our team found out from the customer
(a company in the travel industry) that their existing web-based reservation
system had been "hacked". The system would present the user with a set of
choices (with associated prices) in their browser. When the user selected
one, it would post a form up to the server with one of the parameters being
the selected price. The system would then go ahead and book the reservation
with that price. See anything wrong here? It didn't take long for some users
to discover they could save the form to disk, edit the price, then post the
form up to the server and get whatever price they wanted. Talk about "name
your price"; this sure beats Priceline!
I'm not making this up. This is a real world example.
These are the sort of "security breaches" we will see with web services --
the same security breaches we are seeing today with web apps. It is not the
technology that is at fault, here.
And even if SOAP is abandoned and everyone is writing REST-ful web services,
what about that will ensure some naive developer doesn't write an
application that accepts an XML document that is PUT to a unique URI, and
trusts the content and invokes business logic with it without sound
verifications letting some malicious user name their price for goods?
Whatever REST contributes to security, here, it is a drop in the bucket.
I've heard some pretty compelling arguments in favor of REST. But based on
what I've seen in the real world, I think the argument that REST leads to
more secure apps is the weakest, least-compelling argument. Properly
allowing a firewall administrator to control access to services makes
obvious sense; but this goes nowhere near far enough to providing the level
of security really needed for web services. I think the focus of criticism
on SOAP is just fostering misconceptions and confusion regarding the real
issues of security with web apps.
I think the discussion of REST is healthy and useful. It's changed my mind
about a number of things. I also think it is good to analyze SOAP and
consider if this is the right way to do things. I'm sold on the idea that
there should be visibility to the firewall. I don't think, though, that the
discussions regarding SOAP and security are highlighting the real issues
that will lead to security breaches, and those issues are the same ones that
are leading to security breaches today.
Those things are:
1) Naive developers writing apps that trust the information they get over
the network.
2) Naive developers thinking that if they don't advertise their web service,
the hackers won't find it.
3) Naive developers trusting that no one is listening in on the
conversation.
4) Vendors focusing on features and time to market, but ignoring security
concerns because that's not what will ultimately sell the product.
5) Vendors selling snake oil that purports to solve your security problems
for you.
6) People thinking a firewall = security.
These are just off the top of my head. But based on my experience, these are
the things that are causing real problems with security today, and I fully
expect this to continue with web services.
I think it is fair to take the vendors to task. But I think there is too
much indictment of SOAP itself based on certain vendors' tools and marketing
hype, and that is not helping the credibility of the criticisms of SOAP
among technical folk.
-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>
|
