Security Issues in Web-based Collaborative Systems

Lukasz Beca, Marek Podgorny
CollabWorx and Syracuse University

Abstract: Web-based collaborative services are becoming increasingly popular. Examples include chat rooms, virtual meetings, and distance learning environments. In this paper we analyze functionality and architecture of two types of real-time collaborative systems: a system for supporting online meetings and a system for supporting distance learning sessions. We discuss security issues that arise during design, deployment, and use of these systems, such as authentication, authorization, communication security, auditing, and integration with existing security frameworks. We identify currently available security solutions and evaluate their applicability in addressing identified issues. We also propose new solutions where currently used technologies do not seem adequate.

Index Terms: security, World Wide Web, collaborative systems

I.     INTRODUCTION

The diversity of the services available on the World Wide Web is growing. The users, apart from accessing the most popular applications such as browsing documents and performing purchases, can also participate in online auctions, chat rooms, virtual meetings, distance learning sessions and other activities. The World Wide Web is becoming increasingly a virtual place where people not only operate in isolation but also interact with other Web users. Still, even though the existing infrastructure supports relatively secure Web browsing and purchasing transactions, there is no generic framework for building secure systems for on-line real-time collaboration.

Some of the already available solutions can be adopted (for example SSL [18], digital certificates), but not all of them are sufficient or appropriate because of requirements imposed on real-time collaborative systems, which are different from the requirements imposed on standard Web applications. For example, the HyperText Transfer Protocol (HTTP) [7] does not provide ability to notify a Web client about changes in the content managed by Web servers. A notification mechanism is one of the several services that might be used to implement collaborative applications, which must receive updates about changes in the shared application state. In absence of the notification mechanism, new communication protocols must be used by such applications. This approach in turn causes a number of problems related to integration of the system communication infrastructure with already existing security solutions–for example deployed firewalls.

 In this paper we address general issues of security in Web-based collaborative systems. The paper is organized as follows: In Section II we discuss how various aspects of the Web environment can be of benefit to collaborative systems. In Section III we discuss two typical collaborative applications and, based on a case study, we define generic system architecture for collaborative systems. In Sections IV to VIII we discuss various security aspects and available solutions. Section IX provides an overview of the integration issues related to the existing Internet security infrastructure. Conclusions are provided in Section X .

II.     Web-based Real-Time Collaborative Systems

Development of the World Wide Web is a phenomenon with many different facets. Socially, WWW transformed perception of computers from an obscure and arcane technology used by technical and business people to a home appliance and a subject of casual party conversations. In this aspect, computers and information access capabilities became a part of everyday social life. Technologically, the broad demand for these new, hitherto exotic services, led to an unprecedented explosion in creativity of system architects. In a span of just several years, the Internet evolved from a simple collection of few dozens of web servers into an advanced distributed computing system.

Computer Supported Collaborative Work (CSCW) premises and concepts predate the Web but it is one of the fields that is being profoundly affected by the Web: CSCW is traditionally concerned with human-computer interfaces, and its focus is computer support of human collaborative activities. With the social change of attitude towards every-day use of computers, CSCW is poised to leave its laboratory confines and move towards mainstream computing.

The Web environment offers significant benefits to the developers of collaborative systems. The most important features are: global scope, high availability, rich content, multi-platform clients, and ability to host executable content. All these properties make the Web a powerful platform for building collaborative applications. In fact, many of the new industrial groupware systems (for example WebEx [19], Lotus SameTime [14], PlaceWare [16]) are Web based.

This trend is accelerated by the nature of Web technology. Its social and technological impact on groupware makes Web –based collaborative systems increasingly sophisticated, and, slowly but surely, improves their acceptance. As the Web-based collaborative systems gain industrial acceptance, they will have to undergo the evolution from laboratory tools to strategic IT tools. This, among other things, implies making them secure and integrating them with the existing Internet security infrastructure.

III.     Case Study

Initially, most of the groupware applications developed on the Web enabled only asynchronous collaboration (for example, BSCW [9]). These applications were build using Web technologies such as HTML pages, CGI scripts, or Java servlets. As a result, security problems encountered in such applications could be addressed using standard Web solutions (for example form based authentication and HTTPS protocol). Some of these technologies are also useful for development of real-time (synchronous) collaborative systems. However, inherently different requirements imposed on real-time collaborative systems force developers to combine Web technologies with non-Web solutions. Such hybrid systems are not entirely covered by the security models currently used on the Web.

In this section we describe our efforts to create two secure Web-based real-time collaborative services: a web conferencing system (called virtual meeting) and a distance learning system (called virtual classroom), based on TANGO Interactive framework [3] developed jointly by Syracuse University and by CollabWorx. We wanted to build the systems in such a way that:

§         After deployment at a Web site they do not decrease security of already present solutions.

§         The potential users of the environment can trust other participants of the interaction; the content of the interaction is protected from capture or malicious modifications.

§         Deployed security solutions do not impose computation or communication overhead that would be unacceptable to the service users or service hosts.

A.     Functionality

Virtual meeting system provides functionality of scheduling and holding online meetings. The meetings can be scheduled and accessed only by authorized users. Usually one of the participants prepares presentation to be displayed for other users during the meeting through shared web browser. Communication with other participants is provided through audio/video links, and chat application. Whiteboard tool can be used to clarify presentation issues. Moreover, participants have an option to share their screens or selected applications. All users have access to the list of meeting participants.

Virtual classroom system enables delivering lectures to the geographically students in real-time. It supports structured patterns of interactions appropriate for teaching. The instructor has active role; he or she coordinates activities in the classroom to ensure efficient learning process. The students receive lecture content, they can ask questions and they can take control over certain tools while monitored by the instructor. The tools for signaling questions or continuous evaluation of the lecture presentation enable better interaction between students and the instructor. Our experience (the system was used to deliver fully accredited, semester-long graduate courses from Syracuse University to geographically remote colleges) indicates that in some cases, when the number of students is large (i.e., above 15), it is useful to introduce another type of a session participant – an assistant. Such person is responsible for monitoring activities of the students and responding to the questions related to technical problems that may develop during a virtual lecture. Many problems during the class sessions stem from the fluctuations in the available bandwidth of the Internet connections and this factor influences quality of the service delivered to the students.

B.     Architecture vs. security

The applications described in the previous section have similar architectures since they are built using the same collaborative framework–TANGO Interactive (hereafter referred to as TI). Figure 1. presents the architecture of the TI system.

TI system is built according to several basic principles. The most important are:

• The entire system is browser-based. It is started from a Web link, and most of the client side code executes in a browser.
•  Collaborative tools are implemented as Java applets, scripted Web pages, or as ActiveX components. However, the framework takes a pragmatic approach and allows native collaborative tools. Native tools can be implemented in C/C++, as Java applications, or in other programming language. Functionally identical APIs are provided for each supported language.
• The system allows tools to be downloaded at runtime or installed on local machine.
• If the tools are downloaded by the system, they can originate from an arbitrary Web server. The tools can, in turn, request additional data. TI framework treats Web servers as a primary repository for both the tools code and data. This holds even for the native applications.
• Collaborative tools share the state using event-sharing mechanism. The events are shared via a special middleware layer, denoted as TI plug-in Figure 1., and via a real-time messaging server, called TI Meeting Engine (TIME). TIME does not have to be collocated with any of the Web code and data servers. It is implemented as a Java application.
• Collaborative tools, either in-browser or native, can communicate with TIME only via the middleware (plug-in). Importance of this arrangement is discussed below.
• The bi-directional communication for sending and retrieving messages between the collaborative tools and the middleware is provided. Browser supported document object model is extensively used.

Two critical components of the system are the plug-in [1] (middleware), and the Meeting Engine. Middleware has been introduced to ensure high system reliability. It also plays important role in system security. The crucial idea behind middleware is that collaborative tools cannot communicate directly with the messaging server. Instead, they use middleware method calls for such communication. The middleware acts as a message filter and multiplexer, preventing applications from sending ill-formed or illegal messages. An ill-behaved tool might not work but it would not disturb the overall system operation.

Use of the plug-in as data multiplexer simplifies implementation of the messaging server. Each system client connects to the engine just once. A proprietary protocol provides all services necessary to identify message sources and addresses. In absence of the multiplexing plug-in, each application would have to open a separate connection to the messaging server. Such a solution practically precludes implementation of strong and coherent security mechanisms. As described in further sections, in TI framework secure communication is implemented between the plug-in and the messaging server.

Since the messaging server is a central element of the system, it may become a target of attacks executed by hackers that want to take control over the environment. The server has been designed with security in mind. It is primarily responsible for message routing. In contrast to data servers such as HTTP or FTP, TIME does not perform any local file operations. For its authentication and authorization functionality, TIME communicates through encrypted connection with the database placed behind the firewall. In addition, digital certificates may be used for authentication during database access to eliminate possibility of TIME spoofing. The database is accessed by TIME in read-only mode. The reason for this approach to TIME security design is that the messaging server cannot be placed in a highly secure environment without seriously impairing its basic function of message routing (see Section IX.B ). In the case that TIME is broken into, the server does not provide any means to further compromise OS or data source security.

As shown in Figure 1., TI framework has one special collaboration tool, the Session Manager. The tool is implemented as a Java applet, and, depending on system configuration, it may present system user with a graphical interface, or it may be hidden, in which case its operation is defined by startup scripts. Session Manager (SM) uses special protocol to communicate with the plug-in. This protocol supports complex and potentially unsafe operations such as loading the application code and data and starting application execution on remote machines. SM tool participates in user authentication and authorization, and it also provides unified mechanism for meeting floor control. Under these circumstances, code and communication protection of SM is critical. TI solves this problem by digitally signing both the SM and middleware code and by verification of digital signatures before communication can be established.

The final comment about the architecture is related to the peer-to-peer communication channel between the instances of a collaborative tool. In Figure 1, a dashed line connects the two instances of “Native Application”. This schematically denotes a peer-to-peer communication model. Since we have stated above that TI framework uses messaging server to establish message routing between collaborative tools, the addition of peer-to-peer communication pattern may be confusing. Let us hence explain this issue in some detail.

TI framework achieves scalability and high performance by making a careful distinction between the data and event communication channels. Let us consider a shared browser tool. In the popular shared display (a.k.a. shared screen) mode of collaboration, a master browser would download the data from a Web server, and then the system such as NetMeeting would replicate display of the Internet Explorer on the workstations of all shared browser session participants. This clearly is not an optimal solution. TI framework works differently: under the control of Session Manager, a shared browser tool is started on multiple workstations. The session chair, or master, selects a URL to load into the browser. The browser sends the URL to TIME, which, in turn, distributes it to other instances. The “slave” instances download the URL from the same Web server or, if the system URL mapping facility is used, from a replicated server. With properly configured topology of the system it is possible to have sharing of HTML documents while incurring only minimal network traffic. The same principle can be now used to capture browser events such as page scrolling, DHTML layer control etc. Shared browser perfectly demonstrates all advantages of event sharing.

Clearly, the same principle can be used to implement a shared whiteboard, or a shared world described by a VRML scene graph. Event-sharing methodology of state sharing works best if the amount of information necessary for state synchronization is small compared to the amount of “static” data. In our solution, dynamic data is distributed via messaging server; static data always comes from Web infrastructure. Similar approach is applied in case of a chat application. We can distribute chat messages via TIME, since chat messages are short and, being generated by humans, infrequent.

The paradigm breaks with applications such as audio-video conferencing. The data streams become “fat” and they are also time-sensitive. In such case, TI framework uses TIME only to establish collaborative sessions of the specialized tools, such as an audio or video conferencing, and it allows the tools to use their private communication channels. This is a mechanism very similar to the H.323 [11] approach, where Q.931 and T.245 protocols are used to establish the “calls” and then RTP protocol is used to distribute data streams in the peer-to-peer mode, optionally using IP multicast to optimize network bandwidth. TI framework provides security only for the session setup phase. Security of the media stream distribution is not supported. The media conferencing tools have to implement this functionality on their own. TI framework makes this process a little simpler since it can be used to, for instance, exchange the secret encryption keys and security policy parameters between instances of the tool.

IV.     Identified Security Issues

Collaborative environments have a number of the requirements related to the security of these systems. In general, they can be broadly divided in two parts. One set of problems is related to traditional security measures such as authentication, authorization, and communication security. Each of these issues has new aspects in the context of collaboration systems. We will discuss these new aspects in detail. The second group of problems is related to integration of collaborative systems with the existing Internet security infrastructures.

Authentication of the users is necessary so that meeting participants can determine who they are interacting with and possibly have access to the information about other group member. Such approach increases trust among meeting participants and leads to more efficient interactions. Authorization mechanisms are necessary to determine access rights to the collaborative application resources. They can be used to limit the group of users that can participate in the online meetings or virtual classroom sessions. They can also be used to impose structure on the interaction by applying restrictions in access to the system resources. Another important issue is security of communication channels used for exchange of control and application data among collaborative clients and servers. Without protection the protocol messages can be intercepted and used to gain access to the system. Moreover, potential attacker can get access to the application data exchanged between collaborative client and server. Finally, there are numerous security solutions already deployed on the Web (for example, security models implemented by Web browsers, firewalls on corporate networks) and collaborative environments that operate in this environment should be able to integrate their security solutions with already present infrastructure.

V.     Authentication

Activities performed during regular real-life meetings (for example, presentations, discussions, decision making) require that participants know and trust each other. The same necessity applies to the online meetings. One of the important features of the collaborative system that supports this requirement is assurance that the users that participate in online interactions are really the individuals who they claim to be. In this way, the participants of the meeting know that the specific identifier denotes certain real person that they probably met in real life or exchanged a number of e-mail messages and can expect specific type of behavior. The issue of authentication is also essential in other types of distributed applications, for example, distributed operating systems [4].

A number of technologies are available that support authentication. Kerberos [13] was designed to provide authentication services for large distributed systems. Currently, it is included in several operating systems. However, it is not widely used in the Web environment. SSL protocol provides mechanisms for authentication, which allow Web clients to authenticate Web servers and vice versa. The authentication is based on the X.509 certificates [1] installed in the Web browsers and servers. Simpler solutions use form-based authentication supported by Web browsers. It is also possible to embed authentication solutions in the protocol used for communication between collaboration server and client.

In our solution we use combination of two mechanisms: X.509 certificate authentication mechanism provided by the HTTPS protocol and authentication messages embedded in the protocol used for communication between collaboration client and server (that correspond to plug-in and TIME as described in section III.B ). The first mechanism is used to gain the access to the Web site where the users can enter meetings. Another mechanism is used when the user enters specific virtual meeting or virtual classroom session. At that point the participant must submit user name and password. The information about users with corresponding passwords is stored in the database and it is accessible to the collaboration server (TIME), which can check validity of user login operation. We use SHA [13] algorithm for scrambling passwords. Since the password is sent without encryption from the client to the server, the communication channel must be protected (see section VII for more details). The described authentication mechanism provides base for enforcing authorization polices defined for specific types of environments (for example virtual classroom).

VI.     Authorization

Authentication enables verification of the user’s identity and this information can be used to define user’s access to various resources and services provided by the system. In the first approach we can define all-or-nothing policy. The user that was recognized by the system as authorized is allowed to participate in collaborative sessions and use the system without any restrictions. This approach may be appropriate for on-line virtual meetings where participants are subject to social norms that in natural way impose limits on the interactions. However, in certain situation more structured patterns of interactions are required; ability of defining such structure may be achieved by introducing refined access control mechanisms. A type of session management policy [5], access to specific collaborative tools, and modes of floor control [8] – all these parameters can be used to shape collaborative policy targeted for particular application.

For example, in the virtual classroom environment, an instructor needs to maintain control over collaborative activities at all times in order to deliver the content of the lecture efficiently. On the other hand, the students should have access only to limited functionality that would not allow them to disturb other receivers of the lecture. In our solution we addressed this problem by the introduction of the simple role based access control (RBAC) mechanism (for extensive description of this topic see [6] and [12]). Each participant in virtual classroom session has a role assigned. Example roles include a professor, a student, and an assistant. The roles in turn are used to describe access permissions to collaborative sessions, tools, or control tokens. Depending on the role, the system may decide to allow the participant to enter the meeting, start specific tool, or use already started tool with limited or full functionality. As a result, it is possible to control collaborative functionality that is accessible to specific user precisely and relatively easily.

VII.     Communication Security

One of the assumptions that must be made when building distributed application operating on the Internet is that all messages exchanged among application components over the network can be intercepted, fabricated, spoofed, or stored and retransmitted later by malicious users. The commercial Web sites that perform financial transactions use HTTPS (HTTP over SSL) to provide secure access to their services. Real-time collaborative systems are also vulnerable to this type of threat. The messages exchanged between collaboration server and clients (TIME and plug-ins as described in section III.B ) contain protocol messages (for example login message with user name and password) and application data that can be potentially used to harm collaborative session participants (for example, if the confidential business information is presented during a virtual meeting). Also, a malicious user can try to send messages that simulate actions of one of the meeting participants. Therefore two properties must be satisfied in order to provide secure communication among collaborative application components: confidentiality and integrity.

In order to provide these features in implementation of TI framework we used SSL as an underlying layer of our communication protocol (we evaluated BSAFE—SSL Java libraries developed by RSA [17]). SSL has a number of properties that make it feasible as a mechanism providing communication security for collaborative environments. It provides mechanisms for client and server authentication, channel encryption, and message authentication. Moreover, it allows selection of various cipher suites from the strongest (but slowest) to the weakest (but fastest) so that requirements of various types of user groups can be accommodated. The users that can accept lower performance for the benefit of improved security can use the strongest cipher suite. On the other hand when the security requirements are more relaxed, faster algorithms can be employed.

Obviously, additional protocol layer adds computational overhead to the message processing. This overhead is almost unnoticeable for applications with low bandwidth requirements such as chat or whiteboard that exchange data in form of small state updates. However, the overhead can be significant for applications that require high bandwidth, for example screen sharing applications. Also, applications that transmit large volumes of delay-sensitive data (audio/video conferencing tools) using connectionless protocols (UDP) cannot use SLL to provide communication security. In such situation, phone conference call can be used to provide secure audio link.

In our implementation of virtual meeting and virtual classroom systems, SSL (in combination with X.509 certificates) is also used to authenticate collaboration server (TIME) to the clients. Such approach enables control over deployed engines and makes difficult establishing unauthorized installations. However it requires creating infrastructure for issuing and management of keys and certificates used by the system (PKI framework can be used for that purpose [1]).

VIII.     Auditing

If the intrusion into the system already happened the mechanisms should be in place to allow discovery of the break-in. Auditing (recording of important events related to accessing the system functionality) can be used to enable such detection. In our solution the collaboration server (TIME) maintains a log of the most important events in the system. Each entry in the log contains following data:

• Operation type: system login and logout, session join and leave, session creation and termination.
• Target: objects affected by the operation.
• User identity: the system assigns temporary identifiers to the users upon successful completion of login procedure, the identifier is later used to tag actions executed by the particular user in the log
• Status: provides information about whether operation was executed successfully or not. In case of failure, the reason is provided
• Timestamp of the operation

Analysis of the information contained in the log can give insight into activities of the users and can help in detection of the potential intrusion.

IX.     Integration with Existing Security Frameworks

Designers of the Web-based applications must take into account security technologies already deployed in the Internet environment. In this section we concentrate on the security model implemented by Web browsers for executable objects and on methods of implementing communication across firewalls.

A.     Web browsers and executable objects

The systems that use objects executable in Web browser environment (for example Java Applets or ActiveX controls) must take into account security models implemented by the Web browsers (Netscape Navigator and Internet Explorer). Java applet by default is not allowed to access any resources placed on local machine. Also, it is forbidden to open socket connections to the machine other than the one where the Web server that hosts the applet is placed. The latter limitation is particularly significant if we want to deploy a collaboration server on the machine other than the one from which the client was downloaded. Fortunately, it is possible to overcome mentioned restrictions by using appropriate mechanisms [10] provided by browser platforms. These mechanisms are based on capabilities model in which principals (digitally signed Java applets) can get access to certain targets (protected system resources). Authorization of access is represented by the privileges associated with the principal and related to particular target. As a result, in order to access a particular resource managed by the Web browser, the principal must explicitly ask for the privilege to use the resource (the code of the applet must contain an appropriate method call). After the privilege is granted, the resource can be used without restrictions.

In practice, before letting an applet to execute a potentially dangerous operation (for example, opening socket connection to arbitrary host on the Internet) the browser displays a window with information about the feature that is supposed to be accessed, information about object signer, and controls that enable user to make decision to grant or deny appropriate privilege.

Our system requires access to several restricted resources such as: socket connections to arbitrary hosts (necessary to connect to TIME) or ability to execute applications on client’s machine. The access to this functionality is acquired through the capabilities mechanism described above.

B.     Firewalls

For collaboration systems, whether Web-based or not, firewalls create a set of major problems. These problems are not widely known, and they have not been extensively discussed in the literature. This is probably due to the fact that academic campuses, where most of the CSCW research work is done, usually do not use firewalls, relying instead on other network protection mechanisms, such as tight traffic monitoring and policy enforcement via administrative methods. Academic institutions also enjoy a privileged access to the IP addressing space, eliminating the need for network address translation. Yet, the problem of traversing firewalls is critical for successful deployment of collaboration systems. Our experience with such deployment on corporate and DoD networks provided us with a body of evidence on how existing security infrastructure can break deployment plans for collaborative applications.

The most frequent reasons for the problems we have encountered in practice are:

• Network administrators responsible for security do not want to compromise firewalls by “punching holes” for additional network connection necessary for collaboration systems to function. For example, the popular NetMeeting application from Microsoft [15] requires opening of a number of TCP ports and all UDP ports with numbers above 1024! Deployment of applications that use UDP protocol is particularly difficult to negotiate, as many secure corporate networks block all UDP traffic. Similarly, H.323-compliant conferencing products require a block of both TCP and UDP ports to traverse the firewall.
  
  
• An alternative to opening ports in firewalls is installation of proxy servers integrated with firewall. The problem with this solution is that, with exception of SOCKS [20] proxy servers, all proxy servers are application protocol-specific. This means that every application requires a separate proxy to communicate through firewall. Installation of proxy servers incurs additional software license and maintenance cost. Further, proxy servers are only available for popular protocols such as HTTP and FTP. Certain application vendors provide proprietary proxy servers (a good example is Oracle Connection Manager, which provides proxying of the entire Oracle Net8 protocol suite), but for many other application a network-layer SOCKS proxy is the only available solution, which slowly is becoming a standard. Still, configuration of a SOCKS proxy server for real-time groupware is relatively complex.

Figure 2: Secure deployment of a web-based collaboration service