Simple Object Access Protocol (SOAP) is the primary transport mechanism for the Web services architecture. It is a lightweight protocol that can replace more complicated, distributed object technologies for many applications. However, SOAP’s use of Web servers to tunnel through firewalls may limit its usefulness because it potentially opens corporations to external access. As it becomes more ubiquitous, SOAP may increasingly find itself in the sights of security personnel.
To discuss the potential security limitation of SOAP services, an understanding of how the architecture works is important. SOAP was developed because of the limitations and complexities in current distributed application technologies. Although it was initially designed by Microsoft, UserLand, and Developmentor as a protocol for the BizTalk architecture [1], SOAP quickly gained momentum as IBM, Sun, Lotus, CommerceOne, and other proponents took interest in its development. The SOAP protocol has been submitted to the World Wide Web Consortium (W3C) to ensure it remains an open specification.
SOAP is based on XML and HTTP. Extensible Markup Language (XML) is a simple, text-based method for describing most types of data, including strongly typed method parameters. Because XML is structured and marked with tags, it is extremely readable to computer applications, and it is usually readable to humans as well. XML is rapidly becoming a standard method for transferring data between applications.
Hypertext Transfer Protocol (HTTP) is the transfer mechanism for Web pages. Each click of a Web page link initiates an HTTP transfer and normally results in the display of a new Web page. HTTP is a stable specification; the W3C has closed the HTTP Activity because it “achieved its goals of creating a successful standard” [4].
Because SOAP is based on the simple and open technologies of XML and HTTP, it is poised to become a new standard for distributed objects communication. Coupled with Web Service Description Language and the Universal Description, Discovery, and Integration (UDDI) registry, SOAP is an integral part of the popular Web services architecture [2].
Two Perspectives of Firewalls
Every organization must find a balance between the need for security and the desire for remote user access. Remote salespeople, distributed offices, vertical and horizontal partners, and other e-commerce activities require external Internet connections to internal services. Each connection potentially opens the organization to security threats. These needs breed two often opposing perspectives in organizations: a security focus and a functionality focus. Some may see SOAP as a mediating force between the two needs, but for reasons discussed later, this view may be premature.
Security. As organizations have become more connected to the rest of the world, opportunities for external hackers to gain unauthorized access to internal systems have increased dramatically. For example, my relatively uninteresting, university-based server is scanned four to six times daily by would-be attackers. Since many services run with root or administrator privileges, remote intruders need only compromise one application to gain significant access to internal systems.
To best protect their internal resources, network security personnel limit outside access as much as possible. Unnecessary services are deactivated and required services are placed behind firewalls that provide a single point of entry for external access to internal corporate applications, such as FTP servers, HTTP (Web) servers, and directory services. Incoming Internet traffic is inspected for required sources, destinations, traffic type, protocol, or other parameters. In addition, recent services have been engineered to run under unprivileged accounts, so even if they are compromised, intruders have few rights.
Functionality. Remote application programmers are charged with creating applications that give external users access to internal corporate behavior. Firewalls constrain programmer ability—they limit the exact behavior programmers are charged to create. Traditional remote access architectures, such as Remote Procedure Call (RPC), the Common Object Request Broker Architecture (CORBA), and Remote Method Invocation (RMI), require multiple ports to be open through firewalls. In some systems, entire port ranges or protocols must be allowed through firewalls to allow applications to work correctly.
To enable sophisticated connections to remote personnel and outside organizations, programmers must be allowed some degree of freedom to connect services to each other. While most programmers understand the need for security, firewalls limit and add complexity to their applications.
The SOAP Solution
SOAP is much simpler than traditional object communication technologies. It is free and uses open technologies such as XML, and it provides much of the functionality of traditional architectures. But most importantly from the functionality perspective—it requires no additional ports or access beyond standard Web servers that exist in almost every organization. Since Web servers play integral roles in most corporate strategies, serving an organization’s home page, for example, programmers can feel relatively secure that Web servers will not be firewalled. In effect, SOAP can tunnel through firewalls without any concessions from network security personnel.
SOAP transmits messages by placing a routing engine (part of the SOAP processor) behind the Web server. Requests are sent through the Web server to the processor, where they are routed to the appropriate internal application. Responses are sent back through the Web server to the remote client. Most firewalls inspect packets moving through an organization’s Internet gateway. Once packets pass through the firewall, they enter a trusted domain and route to internal application servers. SOAP traffic is normally trusted because existing firewalls see it as “Web page requests” rather than powerful application messages. Once packets pass through the firewall, the SOAP processor unpacks embedded messages and routes them to internal application servers. The figure depicts differences between traditional message routing and SOAP message routing.
Some may see SOAP as a solution to the balance between security and functionality: application access is granted and firewall integrity is superficially maintained. However, the underlying goals of firewall security are circumvented by this behavior. One of the principles of security is any external access to internal functionality potentially opens the organization to intrusion. As SOAP becomes more popular, network security administrators may see it as an “end run” around security.
Most of today’s SOAP-based applications are custom-built for specific organizational needs—thus achieving a level of security through obscurity. However, future distributed applications may be purchased as commercial, off-the-shelf software, similar to the way users purchase standard applications such as FTP and Web servers. Indeed, enterprise frameworks such as Sun’s Enterprise JavaBeans or Microsoft’s .NET platform encourage the development of common, server-side components by third parties. These standard packages allow enterprise applications to be built quickly by plugging existing components together.
As common SOAP services become widely deployed, potential intruders will certainly discover their weaknesses. As these services become accessible on corporate networks, security personnel will likely have the same concerns as they do regarding traditional distributed architectures. SOAP applications currently bypass firewalls easily because SOAP uses an accepted protocol that represents simple Web traffic. However, as this protocol is increasingly used to access potentially powerful internal services, firewalls may filter its use. This effect has already been seen with email, as many organizations now strip potentially virus-laden attachments from all incoming and outgoing email.
While most firewalls are not currently configured to filter Web traffic, they can be set to monitor SOAP traffic based upon its unique content type (text/xml-SOAP). Firewalls can even see which methods are being called and can filter based on specific functionalities [3]. While the need to filter SOAP requests is not widespread yet it will likely occur as SOAP becomes more popular. Such filtering may undermine one of SOAP’s primary benefits.
From Ports to the Web Server
From a more general perspective, SOAP is the latest phase in a decade-long trend to route traffic through port 80. Since the early days of CGI scripts in the 1990s, Web programmers have been using the Web server to route traffic through to internal functionality. Traditionally, Internet traffic is routed via transmission control protocol (TCP) through the use of ports: Web traffic routes through port 80, SSH traffic routes through port 22, and email traffic routes through port 25.
Current firewalls are built and configured to provide security in this model, but as companies provide more functionality through the Web server (Web services, Web-based email, Web-based intranet applications, and so on), traffic is increasingly routed via the Web server rather than port. As shown in Figure 1, the switching point is moving behind ports and firewalls to the scripting area of Web servers. While many companies use SSL to protect Web-based functionality, SSL is only a first step toward security. New security models are needed to protect internal services that use the Web server to route traffic.
Conclusion
SOAP is a powerful technology that will likely become a new standard for remote object communication. It easily passes through today’s firewalls and is relatively simple to use. However, if developers are not wise with its application, SOAP may lose the ability to tunnel through firewalls as security personnel increasingly firewall it. Because the security vs. functionality debate is a non-technological, non-trivial issue, future versions of SOAP will never entirely solve the issue with technological solutions or protocol enhancements. Whether the technology is RPC, CORBA, SOAP, or some future communications mechanism, security personnel and programmers will always have to work together to balance the needs of security and functionality, regardless of the architecture being used.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment