XML Web Services & Security

Handy writes "Web Services (SOAP, .net, WSDL ^? , UDDI ^? ) create an even greater need for robust security. Exposed interfaces and fragmented administration coupled with a need for app-level security points to a greater need for a centralized managed security services model."

Comments

FLUFF, FLUFF, FLUFF

[newt_sd]

Not only is this article not saying a single new thing about web application security, the site at the end of the link only has 4 articles on it. This smells of advertising for a new site? Now I am not one to wear a tinfoil hat but I smell a conspiracy going on with news that isn't really news!!

Re:FLUFF, FLUFF, FLUFF

[Target Drone]

This smells of advertising for a new site?

You may be on to something. I tried doing a search on Google for "Westbridge Technology" (the people who wrote the article) to find out more about them. I only got 2 hits with and a sponsored link to the Westbridge Technology home page. Westbridge Technology must be very new for the page to not show up in Google yet.

A whois search also reveals that xwss.org and westbridgetech.com belong to the same people.

And to top it all off Westbridge sells an XML message server. Just what you need to implement all the good stuff talked about in the article.

Duh...

[stoolpigeon]

This was an interesting read and I'm sure it is good info for tech managers- maybe if we keep hammering at them they will get it, but if you write code and you realize that we are connecting systems deeper and deeper - security becomes more and more of an issue. That seems to be a bit of a no brainer.

And all this talk of the computer is the network, and the future of tech and all this stuff - security is the linch pin to making it viable.

I think stability runs a very close second- especially as more critical systems become a part of this big electronic gestalt everyone dreams of- but if it is insecure, I know I wouldn't touch it w/a 10 ft. pole.

.

Conflict of Interest?

[floppy ears]

The drive to get business advantage from XML Web Services will cause turbulent times for IT managers. To successfully navigate these new issues, managers must change their mind set from "fragmented security systems focused on using network perimeter to shield closed business systems" to "consistent managed security systems focused on managing application level security for inherently distributed business systems".

This article was written by Kerry Champion, president and Andy Yang, Senior Director of Product Management at Westbridge Technology, Inc., a provider of security and reliability infrastructure software for XML Web Services networks.
I'm not saying I disagree with their conclusion, but you always have to be suspicious when somebody comes out with an article that concludes that to be successful you have to use their product/service or something like it.

"Paradigm" shift?

[sisukapalli1]

The drive to get business advantage from XML Web Services will cause turbulent times for IT managers. To successfully navigate these new issues, managers must change their mind set from "fragmented security systems focused on using network perimeter to shield closed business systems" to "consistent managed security systems focused on managing application level security for inherently distributed business systems".

Hmm... I know of a manager (very higher up), when asked about security implications of some assumptions in the design of a product (for web services), very confidently responsed, "They [customers] can always configure their firewall". *That* was the solution!

S

an important issue

[tps12]

I can't stress security enough. Too often we see the methodology of "write first, secure second."

No no no no. I'm sorry, that just won't cut it in today's world of scam artists. We need to be building in security on the server side from the ground up.

I am loath to resort to buzzwords, but "proactive" really describes just how I feel.

At my company we have met this challenge head-on by deploying a full server force of Mandrake Linux coupled with Apache 2. Apache 2 picks up where the original left off, with the added features of clones referring to Stormtroopers (as opposed to the original modular system). I find that our server compromises have decreased ~70% since making the switch from an IIS server farm.

I have also heard good things about BSD in regards to security and web apps. Great to see this finally getting the press it deserves.

SOAP Security Issues

[smallpaul]

Here is my take. And here is Bruce Schneier's..

XML security problem: Patents & RAND

[kbonin]

The only real problem w/ XML/SOAP based web-service security is patents. There are a rapidly growing set of patents being issued that cover, or will attempt to cover, every possible variation of method needed to transport XML and related datatypes securely.

This includes a broad patent on form signing which appears to cover most forms of hierarchical documents, such as XML.

SOAP = firewall bypass

[irritating environme]

I fail to see why SOAP exists except to bypass firewalls, since firewalls exist to restrict what calls/ports/protocols can be made in TCPIP. What will happen in two years will be a "firewall" system for SOAP calls, followed two years later by a new protocol to bypass that security layer, billed in an exciting acronym. Repeat ad infinitum.

Maybe I'm missing something . . .

[MaxwellStreet]

I really don't know (flame gently if I'm being ignorant), but I'm hoping someone can explain this simply.

If https is secure... and xml/soap is http-based... what's the giant technical leap preventing https transmission of soap/xml packets?

Also, if you're doing business with say, a vendor of yours, what's stopping the both of you from encrypting the body of the soap messages on both sides by means of a PGP key or something?

I'm just curious as to why the issue seems to be reasonably solved with http web traffic, but isn't with SOAP...

Re:Maybe I'm missing something . . .

[ChrisDolan]

You're talking about the wrong kind of security. Think "bugs" instead of "encryption".

The issue is that SOAP exposes backend functionality to the end-user (or end-developer).

As an example, consider the server that offers the web service that lets you look up your bank balance. Compare it to a CGI program that does the same thing. They have almost the exact same security issues: privacy of the data (solved by https) and authentication (making sure you are who you say you are). Both the web service and the CGI are equally dangerous by themselves.

The difference is that SOAP and other web services add the extra abstraction layer that offers one more place for the developer(s) to screw up. And it makes it one step harder for a sysadmin or developer to find problems.

As the recent SOAP::Lite vulnerabilty points out, this is a non-negligible risk.

Re:Maybe I'm missing something . . .

[Random Feature]

SSL secures the transmission from prying eyes. It does not prevent someone from using your service in a manner you did not intend.

Security issues with Web services go way beyond the fact that it's transmitted in the clear.

All of the issues that have been dealt with in Web forms will reappear. Field type/length validation needs to occur, authentication, etc...

You can't just turn on SSL and expect it to solve all your security problems. Utilizing SSL brings up yet another problem - it disrupts security processes in place. IDS and anti-virus mechanisms at the edge of the network can't decrypt SSL traffic and therefore ignore it.

Unless you are using client certificates - which may be more possible with B2B as opposed to B2C - SSL isn't going to solve the underlying problems, which is verification and validation of a sometimes complex dynamic document that may contain data that is dangerous.

Re:Maybe I'm missing something . . .

[Bobzibub]

Well, here's the deal. Back in the day we have different types of packets going to different ports. (if you have a *NIX box, type cat /etc/services for a listing) Port N is for function X. Port M is for Y. So if you send packets to my server with a certain port, then I can assume it is for a specific service guard against specific things at the firewall level, not at the (less reliable) application level.
Consider what requests had to go through before:
Web browser (or some client used by evil folks) ==> Firewall==> Web Server==> Applications (server?)==>data

Webservers operate on port 80 and so port 80 is mostly open thru the firewall. Webservers also typically have quite a limited function set which makes them easier to secure. Most of the information is handled in limited strings and it is mostly locked down these days.
SOAP also uses the same port 80 (to sidestep firewalls) and *all* functions go through that port. With SOAP (and .Net) protecting specific services via the firewall level is moot now. There will be a rich function set all on the same port 80. This means that in order to have the same level of security in the SOAP framework, applications have to have similar security to that of your old webserver/firewall.
Now that we skip the firewall and the web server:
Web browser (or some client used by evil folks)==>(SOAP)Applications server==>data

Most of the few functions in a webserver are pretty basic. Most of the functions in a SOAP server will be complex. Imagine all the functions used to manipulate your personal information on a .Net server that uses SOAP. This is a very rich function set to check and make secure. And now it is the web applications programmers who do much of the checking, not the web server software/firewall writers.

All this is somewhat simplified but in general, applications are now the "weakest link" on the web. But the same people who write web applications will soon write object interfaces on SOAP servers which are that much closer to the mischevious out there.

I think you can call this 1 degree of seperation. ; )

Cheers,
-b

You mean, like LDAP?

[GOD_ALMIGHTY]

It amazes me how much directory services are overlooked, even for this one simple use.
LDAP is made for doing centralized management. Be it user management or even configuration of services, it's built into every system and OpenLDAP is seriously robust. Just take the 10 minutes or whatever to figure out how to use LDAP and familiarize yourself with the most widely used schemas.

Using LDAP schemas is like going to create a user table in a database and having the table definition laid out for you. Also all applications should be able to follow the structure. Voila, portable services for applications.

Please, go familiarize yourself with LDAP. Not to mention SASL (RFC 2222) is meant as a system independent way of handling authentication and authorization. OpenLDAP, Cyrus IMAP and a number of other server apps handle SASL quite well, not to mention it's included in most distros.
IIRC, the Java Authentication and Authorization APIs also deal with SASL quite well.

The solutions to most of the problems that come up with 'Web Services' (a limited tool being forced on everything) have been solved by a simple trip to the IETF's RFC repository. Now you just need to use a language and environment that has libraries built for the RFC's. C or Java are your best bets, Perl comes in next, but I've found the libraries to be in various states of working, not something I'd bet my next project on.

Uh, can we say "Hailstorm?"

[Jack William Bell]

This issue is exactly why Microsoft thought they could put over Hailstorm. As a centralized model for Web Services with built-in security, user identification, preferences and certificate management Hailstorm looked like a damn good way for Microsoft to break into a new revenue space while consolidating control over the Internet.

Luckily for us Web Services weren't anywhere close to ready, at least compared to the hype for them, and Microsoft fell for their own marketing by introducing Hailstorm too soon. If they had kept it under wraps until Web Services were actually being rolled out (and running into the need for centralized security) they might have been hailed as saviors. Instead they jumped into the fray too soon and, combined with the antitrust problems, found themselves in a world of shit.

I don't know if Micrsoft has abandoned Hailstorm for good -- I do know they don't have a problem walking away from anything that doesn't pan out. But there is a chance Hailstorm, or something very similar (perhaps funded by Microsoft, but not directly owned), will return when the time is right. I expect the best model for this would be for Microsoft (and/or their competitors) to partner with the big banks and credit firms. In this case you have the businesses with the largest need for such services (and who already have significant databases) opening up their system as another revenue source. If my conjecture is valid I would expect to see announcements of such partnerships in the next six months or so.

In any case what I would like to see is an open source 'Hailstorm'. I understand there are a couple of such projects like that out there now. It would be a very Good Thing (tm) if these projects would settle on a single wire format and data model soon. Why? Because the first such system in general use is going to set the standard for everyone that follows. I would like to see both the standard itself and at least one of the implementations of that standard be open and free (as in speach).

A further extension of this concept would be to allow easy, trusted, collaboration between user identification systems. This kind of decentralization would help keep the biggies from controlling the entire dataspace. Unfortunately it may be difficult or impossible to do without compromising security.

Perhaps the best way to start is small and simple: An identification server of some kind. This service would allow you to check with with a trusted authority to make sure someone accessing your service is who they say they are. Such a server should also allow for anomynity by allowing someone to create an identity that cannot easily be traced back to the real person. Such an anomymous identify should be marked as such in some way in order to allow the service provider to decide if they want to accept it or not, but should be set up so that only the original creator of the identity can use it.

I can go on, but then I already have. Haven't I?

Jack William Bell

WS Security

[bburcham]

Well Microsoft, IBM and somebody else have released the WS Security "spec" (whitepaper) to address some security issues with SOAP, namely message-level digital signature and encryption. It's technically clean, if a little light on detail.

Things to note (strategic):

None of SOAP, WSDL, UDDI, and now WS Security are "Royalty Free".

SOAP isn't a de jure standard -- it's a W3C "note".

UDDI was supposed to move into an open standards body in 2001 but still hasn't.

By publishing WS Security on their websites and through no open standards body we see Microsoft, IBM and that other company abandoning even attempts to appear open.

On the technical side -- if you want to see a little deeper into the security issues left unsolved by SOAP, I recommend you look at the OASIS technical committee specification, ebXML Message Service Specification version 2.0 rev C.

Rich DeMillo's article is much better

[Shirotae]

The article by Rich DeMillo (CNet news.com May 15, 2002) is much better. He gets to the underlying issue that we are patching up problems as they arise rather than paying any attention to understanding what we are really trying to achieve. In particular he says "The headlong rush to Web services is going to make things worse."

DeMillo has been around long enough to know what he is talking about, but I expect his wisdom to fall on deaf ears in today's instant gratification culture.