Analysis of security aspects of web services By Lavanya Kanchanpalli, Mahesh Mutham and Raghu Ram Ala 1. Introduction XML Web services provide programmatic access to application logic using standard Web protocols, such as XML and HTTP. XML Web services can be either stand-alone applications or sub-components of a larger Web application. XML Web services are accessible from just about any other kind of application, including other XML Web services, Web applications, Windows applications and console applications. The only requirement is that the client must be able to send, receive, and process messages to and from the XML Web service. Project aims at analyzing and comparing different protocols or technologies, which could be used to secure web services. Various protocols providing same kind of security service are studied and compared as first part of the project. In the second part, deeper analysis and comparison of protocols provide one of the five basic security services, namely confidentiality is done by implementation using tools like Visual Studio.Net. Acronyms WSDL: Web Service Description Language SOAP: Simple Object Access Protocol HTTP: Hyper Text Transport Protocol XML: eXtensible Markup Language SSL: Secure Socket Layer SAML: Secure Assertion Markup LanguageXACL: XML Access Control Language RBAC: Roll Based Access Control TLS: Transport Layer Security XML Encryption: eXtensible Markup Language Encryption XML Signature: eXtensible Markup Language Signature 2. Problem Description and Proposals Considered XML Web services enable the exchange of data and the remote invocation of application logic using XML messaging to move data through firewalls and between heterogeneous systems. Although remote access of data and application logic is not a new concept, but doing so in a loosely coupled fashion is. Hence it poses new challenges. Overview of security services related issues in web services is as follows. 2.1. Authentication Design of web services requires support for end-to-end Authentication. SSL does not support end-to-end Authentication of chains of entities, where each entity is capable of inspecting and modifying the information of the message Consider the following figure Figure 11. User accessing a website which calls a Web Service The problem is that if the Web service uses transport level security to authenticate and authorize the incoming SOAP request, it only has visibility of the other side of the communication - i.e. the website. The Web service doesn’t know on whose behalf the SOAP request is being generated. With SSL authentication alone, there is no way of knowing the identity of the end-user. The different proposed techniques include SAML, XML digital signatures. 2.2. Authorization/Access Control In web services it’s entirely up to the programmer to define and enforce security policies by implementing the appropriate security checks in the site-specific code. 2.2.1. A typical web server maps all the requests from the clients into a single privileged entity (some server process), thereby reducing the performance.2.2.2. The HTTP protocol is mostly stateless, making it difficult to check, for instance, the order in which certain actions need to occur, or to check and validate input parameters to the post methods. 2.2.3. The security policies, as well as site implementations, change frequently. Keeping the two up to date and match with each other is operationally difficult task, where the omission of a check can result in a security breach. Proposed Techniques are SAML, XACL, RBAC 2.3. Confidentiality: Web service application topologies include all sorts of devices, PCs, proxies, demilitarized zones, gateways etc. Consequently, many intermediaries come between two communicating parties. SSL/TLS may secure the path between any two, but not from one end to the other. Consider the figure1. SSL can provide confidentiality between client and the website and between website and web service, but not between client and web service. The user credentials go encrypted from browser to website in a secured channel. The web server then needs to decrypt the message and re-encrypt and send it to the web service. Hence confidentiality is lost. The proposed solution is to use XML encryption with SOAP messages. 2.4. Integrity: Web Services need end–to–end integrity. SSL may ensure integrity between any two points in the web service application topology but not from one end to the other. This is because at each intermediary point there is a possibility of message getting modified. The proposed solution is to use XML encryption and XML signatures with SOAP messages. 2.5. Non-Repudiation: Achieving end-to-end authentication is not possible; non-repudiation (capability to show some third party that a particular transaction occurred) is not possible. 3. Tentative list of questions seeking an answer to • Are web services secured? • Do the present protocols address the security challenges posed by web service technology? • How are the security needs of web services different from other applications? • What protocols are proposed to provide confidentiality, authentication, integrity, non-repudiation, authorization and access control for web services? • In what way are the protocols different from the ones, which failed toaddress the security requirements of web services? • What are the differences and similarities between various protocols, which address the same kind of security concern for web services? • Assessing the penalty in terms of public key encryption and symmetric encryption of SOAP messages (exchanged by web services for communication). 4. Procedure for verifying the results of our investigation • Study and analysis of protocols mentioned in section 2 to find an answer to questions in Section 4. • Make a deeper analysis of the protocols providing confidentiality to web services by implementing a few of them. • XML encryption of SOAP messages can be done is two ways a. Encryption of complete message b. Encryption of partial message • Following factors are considered in determining the effectiveness of
View Full Document
Unlocking...