 | |||
|
Wednesday June 6 2001 Security Implications of Web Services Web Services need all the security features of any web-based operation, and more While Web Services promise advantages for developers and users, security implications definitely require consideration. Of course, this would be true of any web-based operation with server-side functionality. However, Web Services include several new aspects, such as B2B orientation, which deserve special scrutiny. Who Do You Trust? Since Web Services should only allow access to sanctioned clients, authenticating those clients is the first order of business. In a way, this is similar to the username-and-password authentication of users that ordinary web sites may require. The difference here is that the clients are other computers that want to use the Web Service. It may be that the Web Service has been licensed to client computers with known IP addresses, in which case the access can be limited to precisely those computers. However, this is not usually the case, since clients could be anyone. The best bet is to take advantage of the standard authentication features of whichever protocol (probably HTTP) you are using. SSL is the customary choice, although you may want to move to digital certificates for especially sensitive connections. Dealing with Data Take, for example, an organization that decides to expose an internal application as a Web Service, possibly to allow easier access by employees. It may have to make supporting databases available to that application. That is certainly convenient for the application and expeditious for execution, but is it safe? Special care is necessary to protect that data, either by encryption (which introduces a performance hit) or by guarding its accessibility. Similarly, data may be in danger of interception as it is being processed. For example, as a Web Service works on a user request, the temporary data that the Web Service uses locally may be exposed to prying eyes if unauthorized users gain access to the machine. Again, encryption or reduced accessibility may be necessary for this local data. Getting Input Web Services need to provide the same safeguards on input as web sites do, to protect against similar problems. Users send requests to Web Services over ordinary HTTP, which can be vulnerable to snoopers. "You can specify using SSL and HTTPS," notes Gary Devendorf, senior product manager for languages and technology at Lotus (Cambridge, Mass., USA). "Then all a snooper will see are encrypted packets." SOAP can be used to define an acceptable value for all input parameters in a Web Service. This is especially pertinent for numerical values, which require defined upper and lower bounds, or ranges. You do not want your application going haywire simply because someone entered a negative number. You especially don't want an unexpected value to dump the user into some operations level, where they can pull nasty tricks. Of course, a malicious user can still bombard the service with requests. This denial of service attack prevents legitimate users from accessing the service, which can be serious if it disrupts paying customers. Furthermore, the coupled nature of Web Services means that an avalanche of requests on one component can propagate to other components, affecting them all in a domino effect. Since component A may receive requests from sources B and C, this means that an attack on B disrupts A, but may also affect users of C. Not much can be done to prevent a denial of service attack, but such attacks can be handled in the same way that ordinary web sites do. One strategy is to permit scaling of resources to handle the increased workload temporarily, which may buy time to put other remedies into effect. Another strategy is to determine the domains of origin of the requests (usually only a few), and block access from those domains temporarily. Yet another strategy is to send the equivalent of busy signals back to all requests and wait until the attack blows over. For businesses trying to accommodate legitimate users, however, the goal is to prevent disruption of service at all costs. Stuck in the Middle Since Web Services are generally stateless, that is, they don't keep client information around after processing requests, components need to authenticate on every hit, which can take time. Instead, according to Devendorf, "Web Services components can use cookies to grant trust for specific period of time". Of course, some Web Services do preserve states, and others may gain that ability by moving to the VS.NET WebForms expected in the near future, making this problem moot. The coupled nature of Web Services leads to other security issues. The chain of components always has its proverbial weakest link, the one component that is most vulnerable to attack. It may be a component that the organization has nothing to do with directly, but its vulnerability can certainly have direct effects. If a hacker can compromise such a weak-link component, they can exploit their conquest in a variety of ways. First, they can intercept any data that flows to that particular component from either direction. This may give them access to web addresses, usernames and passwords, which can lead to bigger and far worse things. They may also be able to acquire sensitive, personal, or valuable information using these methods. Secondly, they can manipulate the streams of data in various ways. They may alter some of the data slightly, so that incorrect results are returned, with the intention of deliberately messing up the handler of a user or another component. They may redirect data to incorrect destinations. They may even use the commandeered component and its data flow as part of a zombie strategy, using innocent servers to mount denial of service attacks from the inside. Finally, they may simply shut down the component, denying its functionality to the other components that depend upon it. This will effectively disrupt many users from many different access points. Naturally, you are doing all you can to safeguard your own components. However, there's not much you can do about a component that you don't control. The use of only trusted elements as components is probably the best strategy. "Companies need to establish trusted relationships between partners," Joe Aloia, CTO of e-business service firm Tybio (King of Prussia, Pa., USA), emphasizes. "Currently, this is a manual process. However, in the future, the UDDI may include standardized representations of types of security to search on." Effective Output Eavesdroppers may be more interested in the information that users get back from a Web Service than in the information that the user sent. After all, users may be requesting proprietary or valuable information as part of their legitimate use of the application. However, if this output can be intercepted on its way to the user, the hacker may be able to cause real problems for your organization. Again, the use of SSL encryption for returned information is one way to deal with this possibility, although SSL can decrease the speed of the SOAP call, inflicting a deficit on performance. Closing the Gaps Careful attention to all the existing safeguards is the most important key to the security of Web Services. Use the data definitions available to handle inputs. Employ encryption on sensitive data, even if it seems to be flowing within a secure chain of components. Code and test applications so that they are not vulnerable to wacky inputs or outside manipulation. Always assume the worst-case possibility in any situation: the rough and tumble world of the Web often justifies your assumption. Finally, stay tuned for security updates for Web Services technologies (like digital signatures in SOAP headers), and be ready to implement them as the standards change for the better. Keep up to date with all the new articles and features on
Web Services Architect: |
