Securing SOAP

The lead­ing con­tender for the com­mu­ni­ca­tions pro­to­col that facil­i­tates the world’s busi­ness trans­ac­tions is designed to trans­mit data over HTTP, in the clear. Although some of the cre­ators of Sim­ple Object Access Pro­to­col (SOAP) have expressed con­cern, the con­sor­tium respon­si­ble for redraft­ing SOAP into the new Exten­si­ble Markup Lan­guage (XML) Pro­to­col is near­ing agree­ment that secu­rity is, sim­ply put, not their problem.

In the mean­time — and pos­si­bly as a result– Microsoft and Verisign have just announced a new secu­rity pro­ce­dure for person-to-person SOAP trans­ac­tions, but a work­able mech­a­nism for secur­ing Inter­net trans­ac­tions between soft­ware and soft­ware may be years away.

Some of SOAP’s archi­tects con­tend that build­ing secu­rity into their pro­to­col would only sac­ri­fice its sim­plic­ity, and that the HTTP ses­sions that SOAP trans­ac­tions rely on can already be secured at the ses­sion level, with pro­to­cols such as SSL. More­over, secur­ing ses­sions from out­side inter­cep­tion, secu­rity experts believe, can­not pro­tect trans­ac­tions from two other per­ceived threats: inter­cep­tion from the inside and bad pro­gram­ming. With a pro­to­col exten­sion to SOAP for mes­sage attach­ments in the works, a third pos­si­ble threat emerges — one that too many have become famil­iar with: mali­cious scripts.

Chris Dix, a SOAP pro­gram­mer with FMStrate­gies, sides with the major­ity in believ­ing that it may now be incum­bent upon devel­op­ers to endow appli­ca­tions with the spe­cific secu­rity mea­sures they need to com­mu­ni­cate on open net­works: If you opened up your [program’s com­mu­ni­ca­tion] inter­face to be broad enough to accept things that might be dan­ger­ous, Dix says, then it would be your respon­si­bil­ity as a devel­oper to make sure that the requests that might be dan­ger­ous came from peo­ple who knew what they were doing, and that you built in security.

Unlike the exchange of doc­u­ments — spread­sheets and word proces­sor files — between two peo­ple who can use pub­lic key infra­struc­ture (PKI) or other mea­sures to iden­tify each other, dis­trib­uted soft­ware com­po­nents will com­mu­ni­cate with one another with­out human inter­ven­tion. In the new net ser­vices plat­forms such as Microsoft’s .Net, Novell’s One Net and Genuity’s Black Rocket, dis­trib­uted soft­ware com­po­nents will be every­where, plac­ing remote pro­ce­dure calls (RPCs) to one another using the XML pro­to­col. So why is the W3C close to decid­ing that secu­rity is not an issue, at least for them?

Should W3C Address Secu­rity Concerns?

The secu­rity debate began last May, when Ken MacLeod, an engi­neer of XML-RPC — a SOAP fore­run­ner — pub­lished an arti­cle and posted a link to it in the W3C mail­ing list used by SOAP’s key engi­neers. While some rig­or­ously devel­oped appli­ca­tions may be thor­oughly screened for secu­rity holes, MacLeod wrote, the vast major­ity of appli­ca­tions will never have secu­rity as a high pri­or­ity. He went on to write that the syn­tax and con­tent of RPCs are based on APIs, and that APIs are sub­ject to fre­quent change. Every time an API is altered or amended, wrote MacLeod, secu­rity ana­lysts would need to reassess the implications.

Many who began dis­miss­ing SOAP in the belief that it would be inse­cure, accord­ing to pro­fes­sional devel­oper James Snell, author of a forth­com­ing SOAP book for O’Reilly, may have done so because it was orig­i­nally mar­keted as a great way to do RPC.”

Spec­u­la­tion arose that SOAP could lead to a night­mare sit­u­a­tion where one pro­gram could auto­mat­i­cally hook deep into another pro­gram — and the owner would have no idea what had been done, and no way to pre­vent it.

There’s been a lot of con­cern it’s not a secure pro­to­col because they didn’t define any secu­rity, says Snell. He explained, how­ever, that secu­rity was never SOAP’s inten­tion: It’s just an enve­lope for pack­ag­ing data. In other words, you can’t blame an enve­lope for not being a safe. To reas­sure those who are still wor­ried, Snell adds, Noth­ing in SOAP is auto­matic; just by using SOAP, your sys­tem doesn’t auto­mat­i­cally open up.

Snell’s view­points are shared by many at W3C, includ­ing rep­re­sen­ta­tives of Xerox, who recently posted this:

Authen­ti­ca­tion, encryp­tion and reli­able deliv­ery are already addressed at the level of pro­to­cols like HTTP and SMTP.

RPCs and the ses­sions that bind them are inher­ently com­plex, the Xerox engi­neers wrote, and any attempt by the XML Pro­to­col to address these com­plex­i­ties would be redundant.

The XML Pro­to­col is evolv­ing into a way of using XML to encode data in a way that any­body can read it, no mat­ter what oper­at­ing sys­tem or lan­guage, accord­ing to Snell.

Peo­ple should think more about the con­cept of inter­op­er­abil­ity than merely RPC. SOAP is more like a uni­ver­sal API. With­out SOAP, you’re con­stantly writ­ing spe­cific APIs between appli­ca­tions — CORBA apps can speak only to CORBA apps, COM apps to COM apps. With SOAP, CORBA can natively inter­act with COM and vice versa. It’s an Inter­net stan­dard way of com­mu­ni­cat­ing — no sin­gle com­pany can get a lock in.

Secur­ing Remote Pro­ce­dure Calls

As the com­pany best known world­wide for being able to get a lock in, Microsoft is rec­og­nized today as SOAP’s lead­ing pro­po­nent. Microsoft pro­motes SOAP as a light­weight pro­to­col for the exchange of both infor­ma­tion and RPCs in a decen­tral­ized, dis­trib­uted, net­worked environment.

The prin­ci­ple of RPCs dates back to Microsoft’s cre­ation of the Com­po­nent Object Model (COM), a way for small parts of pro­grams (libraries) to be linked together as one pro­gram at the time the user runs the appli­ca­tion, as opposed to the time the pro­gram­mer com­piles its source code. To move COM out of the con­fines of a sin­gle proces­sor and over the Inter­net, Microsoft devel­oped Dis­trib­uted COM (DCOM), which let Win­dows appli­ca­tions make RPCs to other Win­dows apps.

Iron­i­cally, devel­op­ers were orig­i­nally attracted to SOAP, says Dix, because of some of the secu­rity night­mares they faced when try­ing to do DCOM over the Inter­net. It just was hard to get work­ing, if you could do it at all. The secu­rity issues were just awful. CORBA had its own com­plex­i­ties as well. SOAP was writ­ten with the intent that peo­ple have to work inside of a cor­po­rate envi­ron­ment with a fire­wall, and need to be able to per­form the sort of func­tion­al­ity. I know, the IT man­agers, as soon as you start talk­ing about send­ing remote pro­ce­dure calls as HTTP, get a chill down their spine.

SOAP’s depen­dence on HTTP and Inter­net port 80 as its pri­mary trans­fer medium is a method that has been affec­tion­ately dubbed tun­nel­ing over fire­walls. Although this sounds like a built-in mea­sure for secu­rity breaches, Dix says, the tech­nique actu­ally relies upon most fire­walls’ open accep­tance of port 80 to get the mes­sage across. Because SOAP is XML and because it is trans­port inde­pen­dent, he says, it can be — and in the early exam­ples, it has been — applied to send­ing mes­sages as HTTP over port 80, and thereby cir­cum­vent­ing some of the secu­rity issues with the fire­wall. Within the pro­to­col and the spec­i­fi­ca­tion, how­ever, there are ways of iden­ti­fy­ing and using HTTP head­ers, and SOAP head­ers as well. As Dix explains, tar­get­ing SOAP mes­sages for port 80 can enable con­tent fil­ters at the receiv­ing end to scan for explic­itly labeled SOAP mes­sages — which could, if an admin­is­tra­tor deemed it nec­es­sary, be blocked.

Here’s one exam­ple of a con­ceiv­ably com­mon SOAP ses­sion: A word proces­sor could use HTTP to place a remote call in XML to a lan­guage trans­la­tion appli­ca­tion, request­ing that its doc­u­ment be trans­lated into a for­eign lan­guage. The remote appli­ca­tion would respond with an XML doc­u­ment con­tain­ing the trans­la­tion, in such a way that the end user would never be aware of the remote application.

How would these appli­ca­tions iden­tify one another, and how is the exchanged data secured? Inten­tion­ally, SOAP by itself addresses nei­ther ques­tion. Mes­sages between appli­ca­tions are sent in the clear, mean­ing that any­one who inter­cepts the trans­mis­sion and can read basic XML will have access to this information.

To pro­tect your­self, advises Snell, you should at the very least encrypt the memo, as you would with con­fi­den­tial e-mail. In addi­tion, you could send it over SSL, rather than inse­cure HTTP. Fur­ther, you could encrypt the SOAP enve­lope itself. A method for doing pre­cisely that last item may have just arrived.

XKMS: A Solu­tion In The Works?

The recent announce­ment by Microsoft, VeriSign and web­Meth­ods of a secure XML spec­i­fi­ca­tion for dig­i­tal sig­na­tures and encryp­tion, called XML Key Man­age­ment Spec­i­fi­ca­tion (XKMS), promises to pro­vide some secu­rity and peace of mind, at least for users. XKMS is a spec­i­fi­ca­tion for man­ag­ing pub­lic keys used to sup­port dig­i­tal sig­na­tures or encryp­tion, or other appli­ca­tions of pub­lic keys, Verisign’s chief tech­nol­ogy offi­cer War­wick Ford tells us. So, it’s designed to work specif­i­cally along­side, and in con­junc­tion with, the recent XML sig­na­ture stan­dard pre­pared jointly by IETF and W3C.

XKMS offers tools for dig­i­tally sign­ing and encrypt­ing doc­u­ments shared between SOAP appli­ca­tions. So con­ceiv­ably, a spread­sheet sent between com­put­ers could be both pro­tected and authen­ti­cated, with­out engi­neers need­ing to amend SOAP itself. Although exam­ples of XKMS for dis­trib­uted object sign­ing have yet to be inves­ti­gated, Ford says, XKMS sup­ports sign­ing of XML objects…like busi­ness trans­ac­tions. But it’s not lim­ited to that. So, indeed, if you wanted to build some kind of soft­ware dis­tri­b­u­tion sys­tem, which was itself an XML appli­ca­tion, then you could use this mech­a­nism for sign­ing those objects.

Design­ing appli­ca­tions prop­erly is the best way to min­i­mize secu­rity holes, says Snell. It goes back to good appli­ca­tion design — any appli­ca­tion is inse­cure if you use it improp­erly. If a devel­oper uses SOAP to write an appli­ca­tion that accepts appli­ca­tion code and then exe­cutes that code with­out first dis­cov­er­ing where that code is com­ing from — ensur­ing that trusted rela­tion­ship — that devel­oper should be fired.

Dix sug­gests that secu­rity could be built into a SOAP enabled appli­ca­tion by restrict­ing the num­ber of func­tions it exposes to the out­side world — in devel­oper par­lance, by lim­it­ing its inter­face. Almost exclu­sively, says Dix, SOAP appli­ca­tions would not open up [broad] access to the com­po­nents that exist on the server. Instead, he says, devel­op­ers should adopt a very focused solu­tion, one that was geared to expos­ing the func­tion­al­ity of one or a hand­ful of com­po­nents that you might have on the server.

As late as this week, pro­pos­als were being enter­tained by W3C to drop ref­er­ences to secu­rity mea­sures in its upcom­ing XML Pro­to­col draft, in favor of encour­ag­ing appli­ca­tions devel­op­ers to build secu­rity into their own pro­grams, and net­work admin­is­tra­tors to mon­i­tor the com­mu­ni­ca­tions chan­nel. What­ever group pro­vides the final answer to the XML Pro­to­col secu­rity dilemma, it is now fair to assume that SOAP’s inner cir­cle of engi­neers will not be part of it. Devel­op­ers and secu­rity experts may have a rough job ahead.