OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] SOAP-RPC and REST and security

[ Lists Home | Date Index | Thread Index ]

"Bullard, Claude L (Len)" wrote:
> Paul:
> "But the whole point of web services was that we would put services on
> the public Web as we put websites on the public Web."
> http://www.prescod.net/rest/security.html
> Be sure that only idiots would expose their non-trivial business documents to
> "the Web" through any kind of interface.  Nothing gives a competitor such advantages as
> to be able to see this stuff.  

How does a competitor get through the authentication? They steal a
password? If they can do that, why can't they steal a password to your
VPN or your webserver?

> ... That is why contracts for proposal responses include language
> about the public dissemination of the documents submitted.

Highly secret documents can be "on the web". If you don't have the
password you don't get the document. Putting it behind six layers of RPC
adds no security. It boils down to: if you don't have the password you
don't get the document. (where password is broadly interpreted as
password, capability, private key, etc.)

> Now step back from the "idiots" who bought the story Tim Berners-Lee sold them, and take a look
> at how serious business professionals design software.  They use requirements derived from contracts
> derived from proposals sent in response to requests.  No where in there is security deprecated
> or overlooked.  We have whole sections of responses dedicated to security.  We will not expose
> objects to the web that expose security holes.  We are much more likely to partition the web
> away from vital assets and use proper and well-understood techniques of dissemination management.

You're building this wonderful system based on the software you get on
MSDN CDs. And you trust it to maintain your security more than you do

If the secret to security is "business professionals using requirements
derived from contracts derived from proposals" then I guess we'll soon
see an end to all of the hacking going around. All they need is a few
more dollars on business professionals and requirements, right? That's
enough to stop Microsoft from having any more massive holes in their
operating system. That'll stop IBM's 4758 cryptographic co-processor
from being hacked next time. It will prevent security leaks at the
Japanese State Agency and major computer theft at Barclay's bank?
Security is a discipline. It has nothing to do with how many layers of
firewalls you have between your database and your public interface. It
has to do with discipline. Schneier is famous for understanding how to
apply the discipline. You ignore him at your peril. He takes Microsoft
to task because they are famous for lack of discipline. That's why Bill
Gates got a tounge lashing from George Bush's cyber security advisor. If
you care about security I have no idea why you want to follow them down
the MSDN path.

I think that people who appreciate the discipline of security will
understand what I've written here[1] and probably add to it. But it's
brand new and time will tell.

> That said, RPCs for intranet and URIs for extranet are just fine.  The Network Is NOT the Computer.
> Using services at the public level will require intense scrutiny.  If your managers are idiots,
> they may let you do things that are stupid, just as the NRC, DoD, and others did with URLs.

Len, I have no idea what you are talking about. URLs can be used
stupidly. Yes. So? Nobody said that you should turn off access controls.
At some level your business documents have to interface with the Web.
They flow to your business partners over HTTP. The only question is
whether you take advantage of that and use the Web to secure them or
just stack security flaws in SOAP implementations on top of whatever
security flaws there may be in HTTP implementations.

 Paul Prescod

[1] http://www.prescod.net/http/query_alternatives.html


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS