The leading contender for the communications protocol that facilitates the world’s business transactions is designed to transmit data over HTTP, in the clear. Although some of the creators of Simple Object Access Protocol (SOAP) have expressed concern, the consortium responsible for redrafting SOAP into the new Extensible Markup Language (XML) Protocol is nearing agreement that security is, simply put, not their problem.
In the meantime — and possibly as a result — Microsoft and Verisign have just announced a new security procedure for person-to-person SOAP transactions, but a workable mechanism for securing Internet transactions between software and software may be years away.
Some of SOAP’s architects contend that building security into their protocol would only sacrifice its simplicity, and that the HTTP sessions that SOAP transactions rely on can already be secured at the session level, with protocols such as Secure Sockets Layer (SSL). Moreover, securing sessions from outside interception, security experts believe, cannot protect transactions from two other perceived threats: interception from the inside and bad programming. With a protocol extension to SOAP for message attachments in the works, a third possible threat emerges — one that too many have become familiar with: malicious scripts.
Chris Dix, a SOAP programmer with FMStrategies, sides with the majority in believing that it may now be incumbent upon developers to endow applications with the specific security measures they need to communicate on open networks: “If you opened up your [program’s communication] interface to be broad enough to accept things that might be dangerous,” Dix says, “then it would be your responsibility as a developer to make sure that the requests that might be dangerous came from people who knew what they were doing, and that you built in security.”
Unlike the exchange of documents — spreadsheets and word processor files — between two people who can use public key infrastructure (PKI) or other measures to identify each other, distributed software components will communicate with one another without human intervention. In the new net services platforms such as Microsoft’s .Net, Novell’s One Net and Genuity’s Black Rocket, distributed software components will be everywhere, placing remote procedure calls (RPCs) to one another using the XML protocol. So why is the World Wide Web Consortium (W3C) close to deciding that security is not an issue, at least for them?
<strong>Should W3C Address Security Concerns? </strong>
The security debate began last May, when Ken MacLeod, an engineer of XML-RPC — a SOAP forerunner — published an article and posted a link to it in the W3C mailing list used by SOAP’s key engineers. “While some rigorously developed applications may be thoroughly screened for security holes,” MacLeod wrote, “the vast majority of applications will never have security as a high priority.” He went on to write that the syntax and content of RPCs are based on APIs, and that APIs are subject to frequent change. Every time an API is altered or amended, wrote MacLeod, security analysts would need to reassess the implications.
Many who began dismissing SOAP in the belief that it would be insecure, according to professional developer James Snell, author of a forthcoming SOAP book for O’Reilly, may have done so because “it was originally marketed as a great way to do RPC.” Speculation arose that SOAP could lead to a nightmare situation where one program could automatically hook deep into another program — and the owner would have no idea what had been done, and no way to prevent it.
“There’s been a lot of concern it’s not a secure protocol because they didn’t define any security,” says Snell. He explained, however, that security was never SOAP’s intention: “It’s just an envelope for packaging data.” In other words, you can’t blame an envelope for not being a safe. To reassure those who are still worried, Snell adds, “Nothing in SOAP is automatic; just by using SOAP, your system doesn’t automatically open up.”
Snell’s viewpoints are shared by many at W3C, including representatives of Xerox, who recently posted this: “Authentication, encryption and reliable delivery are already addressed at the level of protocols like HTTP and SMTP.” RPCs and the sessions that bind them are inherently complex, the Xerox engineers wrote, and any attempt by the XML Protocol to address these complexities would be redundant.
The XML Protocol is evolving into a way of “using XML to encode data in a way that anybody can read it, no matter what operating system or language,” according to Snell. “People should think more about the concept of interoperability than merely RPC. SOAP is more like a universal API. Without SOAP, you’re constantly writing specific APIs between applications — CORBA apps can speak only to CORBA apps, COM apps to COM apps. With SOAP, CORBA can natively interact with COM and vice versa. It’s an Internet standard way of communicating — no single company can get a lock in.”
<strong>Securing Remote Procedure Calls </strong>
As the company best known worldwide for being able to “get a lock in,” Microsoft is recognized today as SOAP’s leading proponent. Microsoft promotes SOAP as a lightweight protocol for the exchange of both information and RPCs in a decentralized, distributed, networked environment.
The principle of RPCs dates back to Microsoft’s creation of the Component Object Model (COM), a way for small parts of programs (libraries) to be linked together as one program at the time the user runs the application, as opposed to the time the programmer compiles its source code. To move COM out of the confines of a single processor and over the Internet, Microsoft developed Distributed COM (DCOM), which let Windows applications make RPCs to other Windows apps.
Ironically, developers were originally attracted to SOAP, says Dix, “because of some of the security nightmares they faced when trying to do DCOM over the Internet. It just was hard to get working, if you could do it at all. The security issues were just awful. CORBA had its own complexities as well. SOAP was written with the intent that people have to work inside of a corporate environment with a firewall, and need to be able to perform the sort of functionality. I know, the IT managers, as soon as you start talking about sending remote procedure calls as HTTP, get a chill down their spine.”
SOAP’s dependence on HTTP and Internet port 80 as its primary transfer medium is a method that has been affectionately dubbed “tunneling over firewalls.” Although this sounds like a built-in measure for security breaches, Dix says, the technique actually relies upon most firewalls’ open acceptance of port 80 to get the message across. “Because SOAP is XML and because it is transport-independent,” he says, “it can be — and in the early examples, it has been — applied to sending messages as HTTP over port 80, and thereby circumventing some of the security issues with the firewall. Within the protocol and the specification, however, there are ways of identifying and using HTTP headers, and SOAP headers as well.” As Dix explains, targeting SOAP messages for port 80 can enable content filters at the receiving end to scan for explicitly labeled SOAP messages — which could, if an administrator deemed it necessary, be blocked.
Here’s one example of a conceivably common SOAP session: A word processor could use HTTP to place a remote call in XML to a language translation application, requesting that its document be translated into a foreign language. The remote application would respond with an XML document containing the translation, in such a way that the end user would never be aware of the remote application.
How would these applications identify one another, and how is the exchanged data secured?
Intentionally, SOAP by itself addresses neither question. Messages between applications are sent “in the clear,” meaning that anyone who intercepts the transmission and can read basic XML will have access to this information.
To protect yourself, advises Snell, you should at the very least encrypt the memo, as you would with confidential e-mail. In addition, you could send it over SSL, rather than insecure HTTP. Further, you could encrypt the SOAP envelope itself. A method for doing precisely that last item may have just arrived.
XKMS: A Solution In The Works?
The recent announcement by Microsoft, VeriSign and webMethods of a secure XML specification for digital signatures and encryption, called XML Key Management Specification (XKMS), promises to provide some security and peace of mind, at least for users. “XKMS is a specification for managing public keys used to support digital signatures or encryption, or other applications of public keys,” Verisign’s chief technology officer Warwick Ford tells us. “So, it’s designed to work specifically alongside, and in conjunction with, the recent XML signature standard prepared jointly by IETF [Internet Engineering Task Force]and W3C.”
XKMS offers tools for digitally signing and encrypting documents shared between SOAP applications. So conceivably, a spreadsheet sent between computers could be both protected and authenticated, without engineers needing to amend SOAP itself. Although examples of XKMS for distributed object signing have yet to be investigated, Ford says, “XKMS supports signing of XML objects…like business transactions. But it’s not limited to that. So, indeed, if you wanted to build some kind of software distribution system, which was itself an XML application, then you could use this mechanism for signing those objects.”
Designing applications properly is the best way to minimize security holes, says Snell. “It goes back to good application design — any application is insecure if you use it improperly. If a developer uses SOAP to write an application that accepts application code and then executes that code without first discovering where that code is coming from — ensuring that trusted relationship — that developer should be fired.”
Dix suggests that security could be built into a SOAP-enabled application by restricting the number of functions it exposes to the outside world — in developer parlance, by limiting its interface. “Almost exclusively,” says Dix, “SOAP applications would not open up [broad] access to the components that exist on the server.” Instead, he says, developers should adopt “a very focused solution, one that was geared to exposing the functionality of one or a handful of components that you might have on the server.”
As late as this week, proposals were being entertained by W3C to drop references to security measures in its upcoming XML Protocol draft, in favor of encouraging applications developers to build security into their own programs, and network administrators to monitor the communications channel. Whatever group provides the final answer to the XML Protocol security dilemma, it is now fair to assume that SOAP’s inner circle of engineers will not be part of it. Developers and security experts may have a rough job ahead.