Towards Secure Web Services-based e-Businesses - School of ...

Towards Secure Web Services-based e-Businesses* Betrand Iwunna Ugorji

Nasser Abouzakhar

School of Computer Science University of Hertfordshire College Lane, Hatfield, United Kingdom [email protected]

School of Computer Science University of Hertfordshire College Lane, Hatfield, United Kingdom n.abouzakhar.herts.ac.uk

John Sapsford

Richard Collman

School of Computer Science University of Hertfordshire College Lane, Hatfield, United Kingdom [email protected]

Acoustical Control Engineers Ltd/Belair Research Ltd Broadway, Bourn, Cambridge [email protected]

Abstract— Many of nowadays e-businesses wish to collaborate to offer different online services such as e-banking, order processing and e-payment. Web services play a significant role in achieving such collaboration. E-businesses use various software frameworks to implement their Web service applications. Consequently, each e-business individual approach to security has to interoperate with other e-businesses. Therefore, there’s a need for a structured approach to security in any e-business collaboration to ensure that the joint Web service offering is secure. This paper investigates the current Web services application-level technologies and the security protocols that are associated with the use of signatures and certificates for end-toend security and proposes a particular Web services-based ebusiness scenario with the necessary security infrastructure for SOAP Web services. The proposed solution model would consider some security strategies and practices to provide protection against online fraud as well as other e-business risks. Keywords— e-business; Web services; Security protocols; Security interoperability.

I.

INTRODUCTION

According to the World Wide Web Consortium (W3C), a Web service is a software system that has an interface described in a machine-processable format specifically Web Service Description Language (WSDL), designed to support interoperable machine-to-machine interaction over a network [1]. Thus, Web services are service-oriented, self-contained and self-describing application components discoverable by other applications with Universal Description, Discovery and Integration (UDDI) via the major common platform independent open protocols; XML and HTTP. There are two major classes of Web services, Big Web services in which the service may expose arbitrary set of operations and Representational State Transfer (REST) compliant Web services in which the main aim of the service is to manipulate various representations of Web resources using a uniform set of "stateless" operations [2] [3]. SOAP and WSDL are widely used in developing Big Web services while URI and MIME are widely used in developing RESTful web services. Web services are popular because of their

ISBN: 978-1-902560-27-4 © 2013 PGNet

interoperability, extensibility, machine processability, selfdescriptions and their ability to be combined in a loosely coupled fashion to achieve complex operations. Therefore, it is easier to build huge business-to-business Web services within a relatively small time frame. Several works has been done in the area of Web service security some of which involved using XML digital signatures, XML Encryption, XKMS (XML Key Management Specification), XACML (Extensible Access Control Markup Language), SAML (Secure Assertion Markup Language), WS-Security, HTTP Authentication and Web Service Security (WSS), however, none of these provide a complete solution. Subsequent sections of this paper will present some related research, e-business security requirements, SSL limitations, web service security standards and mechanisms. We will present a model secure e-business application’s risk analysis, proposed solution model, its security designs, security implementation, some tests and results. We will also present the application’s evaluation and conclusion. The development and testing tools used for the model application are: • Oracle JDK1.7 update 21 and Glassfish Server 3.1 • Windows 7 and NetBeans IDE 7.3 II.

BACKGROUND RESEARCH

The cause of most Web service application security flaws has been attributed to bad software thus, the enforcement of Web service security from the design phase of application development through to deployment and maintenance has been advocated [4]. Although Web services have attracted many organizations and enabled them realize their vision; the security of Web services still remains a major concern. Juraj and Tibor described a chosen ciphertext attack on XML Encryption which in their argument, cannot be mitigated by XML signatures if Web services are protected with only WS-Security Policy [5]. In a related work by Jason, a step by step description of procedures which organizations that wish to conduct B2B transactions over Web services were given in relation to enhancing the security of Web services for ebusiness [6]. There are many other related works on the security mechanisms for Web services-based applications.

A. E-business Security Requirements Due to the Service Oriented Architecture (SOA) of web services-based applications and their ability to quickly build a very complex intertwingled network of borderless communication, persons or organizations must define policies on how their e-business resources must be protected. Figure 1 below depicts a person’s or an organization’s Web services security policy model.

Fig. 1. Web services security policy model [7].

To achieve security services such as authentication, authorization, confidentiality, integrity, nonrepudiation etc., an e-business Web service may be required to: • Secure messages in-between intermediaries against eaves-dropping. • Secure only a portion of a message. • Secure different portions of a message with different encryption keys. • Sign, encrypt and/or archive messages. • Retrieve archived messages and their signatures. • Authenticate messages etc. B. Limitations of SSL A web service client may communicate with a web service provider without requiring a human agent or traveling through the http layer [8] [9]. Therefore, SSL and some other security mechanisms employed in securing web-based applications are not enough for securing Web services-based applications. For instance, SSL protects SOAP messages in the transport layer, but once a SOAP message enters the SOAP engine SSL cannot protect it [10]. In a web servicesbased application, a SOAP message can travel over several hubs before reaching its final destination; consequently, it is important to protect a SOAP message throughout the entire path it travels during a communication. SSL does not offer the flexibility of securing only a portion of the SOAP message or securing messages inbetween intermediaries. The requirement to encrypt different

parts of a message to be acted upon by different agents with different keys cannot be achieved with only SSL. There may also be a need to retrieve archived messages for settlement of transaction disputes. SSL does not provide a complete solution to most security requirements of Web services-based ebusiness applications, especially when an end-to-end security is a requirement. C. Web Service Security Standards and Specifications Web Service Security (WSS) specification is a means to achieving end-to-end security. It is the use of XML Encryption, Digital Signature and other XML-based security standards to incorporate security information into SOAP messages [6]. WSS employs the use of different security tokens such as username and password token, X.509 Certificates, SAML, Kerberos token, STS issued tokens with derived keys message authentication, XML digital signature and XML encryption in solving the problem of Web servicessecurity interoperability for a complex system communication. Fine grained inline protection of message contents using different keys are supported by XML digital signatures and XML encryption; they are also used in providing message integrity, nonrepudiation and confidentiality respectively. This is possible given Web Service Standards such as WS-Policy, WS-Security, WS-Trust, WS-I Basic Security Profile, WSSecureConversation and WS-Federation which govern all systems in providing interoperable secure Web services. D. Security Mechanism There are various mechanisms employed in protecting Web services based e-business applications against online fraud. These usually involve some web application server, application-specific or Web Service Security Standards configurations. Web service compliant Web-application servers such as JBoss, Apache Tomcat, Jetty, Oracle WebLogic, Microsoft IIS and Glassfish have inbuilt web service message security providers which developers configure to suite their message security requirements usually from either the administration console or the command line interface. Further application-specific message security properties may be added to a Web service endpoint when the message security provided by a web-application server does not suite the message security requirements of the application. Securing e-business Web services using the above mechanisms are efficient but lack security interoperability. To close this gap, security mechanisms such as Web Service Interoperability Technologies (WSIT) may be employed. WSIT bundles together several web services security standards and specifications such as WS-SecureConversation, WS-Trust, WS-Security, WS-Policy and WS-Security Policy to extend Web services interoperability such as security, reliable messaging, message optimization, configuration technology and bootstrapping. Our motivation is to produce a model secure e-business application that provides security interoperability, end-to-end message confidentiality, integrity and security solutions against XML/SQL injection, dictionary attacks, unauthorized access, repudiation and forgeries.

III.

E-BUSINESS RISK ANALYSIS

This section presents the use-cases, abuse cases, and threat and solution models of the model secure e-business web service. For simplicity in our analysis, we will assume names for the model Web service-based application components. • Payment-service is an e-payment Web service. • Order-service is an order processing Web service. • Order-client is order processing Web service client. • Currency-service is a currency conversion provider. A. Use Cases The model application would have these use cases: • Query and View shop departments & items for purchase in any shop department. • Register/update user accounts, delivery addresses & credit cards. • Login using username/password and a one-time passcode used for 2-Factor authentication. • Add items to cart view & update items in cart. • Perform currency conversion between any two currencies. • Checkout and process payment for purchase items. • Send email confirmations & notifications to users. B. Abuse Cases The model application may be abused as follows: • A client with nonconforming security properties tries to consume Payment-service or Order-service. • A user tries to add items to cart or view cart on Order-client without authentication. • An attacker tries to access any of our services without subscription. • An attacker injects malicious data as inputs such as to conduct XML injection or SQL injection attack. • Attacker attempts dictionary attack on passwords. • An authenticated user abandons his session. C. Threat Models We have presented the use cases and the abuse cases of the model application. In this section, we will explore some possible threats to the model application. See figures 2, 3, 4 & 5 and their respective attack scenarios. A malicious user views confidential order or epayment data on the wire. If the switch is attacked and compromised or the router password is compromised and the router poisoned [11], then an attacker could sniff switch and router traffic using a protocol analyzer, and view HTTP and SOAP messages if they are not protected. Fig.2. Malicious user views confidential order or e-payment data

An attacker masquerades as a genuine user to perpetrate fraud. If (1) above is true, and an attacker has access to confidential credentials of a genuine user such as username and password or credit card details then the attacker can masquerade as the genuine user to carry out fraudulent activities. Fig.3. Attacker masquerades as a genuine user to perpetrate fraud. A malicious user manipulates epayment or order processing data. If threat 1 is true or the database and/or the confidential data stored in it are not protected and an attacker has access to the data then he can modify the e-payment and/or order data en route or in storage. Fig.4. Attacker manipulates order data or e-payment data. An attacker denies service to legitimate users. If the deployment Operating system (OS) is not protected & if the application does not manage the number of threads, a DOS is possible if the network interface is flooded or many running threads consume OS resources & either crashes or slows down the system. Fig.5. Attacker denies service to legitimate users.

D. Solution Models The developed secure e-business application incorporates some of these layered security controls and mechanisms as specified below at different layers as security solutions: • HTTP and SOAP messages are protected in route by using authenticated encryption and digital signatures for end-to-end security. All traffic that must contain confidential data is sent over a secure channel using SSL. A virtual private network (VPN) may be used for all B2B connections. • Confidential data such as credit card numbers, security codes, user passwords and mother’s maiden names are not stored as clear text in the database but are hex-encoded and hashed using strong hashing algorithms in this case, SHA512 and Bcrypt. PBKDF2WithSHA512 may also be used. Password hash collision is reduced by timestamps. All SOAP messages are signed, encrypted, transferred through a secure channel and is authenticated on receipt.

•

•

•

The system emails securely any users action outcomes to the users e-mail such that any action that was not initiated by a user that may lead to a fraud is reported and mitigated. SOAP messages are also time stamped so that any message that exceeds a certain maximum time limit before getting delivered to the recipient or that does not fit into the sequence would be ignored. The database is SSL enabled and protected from unauthorized access by use of wellchosen strong passwords. The client application is designed to support only a single system sign-on such that once a user is logged onto the application; no other user with the same user credential can log in on the application from another system to prevent session hijacking. Time-out services are used to inactivate idle client sessions thereby killing the threads spawning them to prevent denial of service. Secure conversation between provider and client web services is enabled. The application monitors login failures from a particular client IP and blocks requests from the client after 3 login failure attempts but unblocks the client after 3 hours. Sensitive program logics such as password encryption logic reside on the server. IV.

ensuring that even if two users share the same passwords, the hash values of those passwords in the identity storage may not be the same. For all co-corporate users, user’s email accounts must be their corporate emails. 2-Factor authentication is employed during account logins and updates. Following the authentication of a user’s password, a user must also provide the correct one-time-passcode sent to his email to prove true ownership of the account being accessed. It employs and enforces least privilege principle by ensuring that admins can only create corporate user accounts but cannot activate the accounts. Only an account owner can activate his account. Figure 7 shows part of the password encryption pseudo code. 1. Browser - presents the user interface and communicates the provider through the consumer or directly using JavaScript or JQuery to construct and send SOAP messages. All Input texts are validated, only SSL connection is supported & browser is timed out after 30 minutes [14].

SECURITY DESIGN

This security design aims to meet the security requirements of the model Web-services-based e-business application comprising of payment-service, order-service, currency service and order-client in providing authentication, authorization, identity recognition, access control, session management, time-out services, data confidentiality and nonrepudiation. This design also prevents dictionary attacks and SQL injection. It enforces the validation and sanitization of all data inputs. See figure 6 for more details. The Payment service, Order service & Currency service are Web service providers while the Order client is a Web service consumer. The Order service is also a Web service client. Their security properties are outlined in bullet points 3, 4, 5 & 6 and 2 & 3 in figure 6 respectively. The Java EE framework is used in this design in figure 6 but this does not mean that the security design is strictly for Java Web service applications [12] [13]. The security design enforces security demarcations using 6 layers classified as browser, consumer, provider, service, persistence and database; where a user is an application the browser layer may be omitted. This design forms four modules namely – the web, the service, the business logic and the persistence module. Each module of the application component is decoupled from the other and may be deployed on a separate OS. This security design pushes the gap between the user and the data at storage in the database farther apart for better security checks, and enforces data tracking, validation and sanitization. The application ensures that the likelihood of any two user’s password hashing to the same hash value is reduced, by

6. Database - Stores the enterprise data. Supports only SSL connections. Authenticates all connections. Supports data checks, encryption and hashing. 5. Persistence – Maps entities to database tables using object relational mapping and used by the service through the entity manager API to perform CRUD operations in the database. Validates data by defining data constraints, data types, patterns and precisions using design-bycontract principle. Hashes data as required by the service using Bcrypt and SHA512 algorithms with nonces.

2. Consumer - the client side presentation logic can only send SOAP message to the provider if it adheres to the provider’s security policies specified in the providers WSDL policy file. It supports only SSL connection with the provider. Encrypts and signs & appends Authentication token to all SOAP requests sent to the provider. Authenticates all SOAP responses from the provider. 3. Provider - provides security and interoperability. Avails the services of an e-business through the service layer. Provides message freshness using a timestamp. Prevents replay attacks using nonces. Uses Secure Conversation specification to improve performance. Uses Derived Session Keys for key generation. Authenticates all SOAP message requests received and responses. Encrypts all responses using Triple DES Algorithm suite. Uses X.509 message Authentication Token. Manages transaction and assures high quality of service. Publishes the Web service security policies. Accepts request and response only over SSL connections. 4. Service - Interfaces between the provider and the EJBs that handle the business logic of the enterprise - heavy calculations, processing, transaction management etc. Enforces confidentiality, integrity, authentication, authorization and access controls. Validates, sanitizes and reconstructs input data. Tags data, tracks and prevents replay attacks. Avoids string concatenation in SQL queries thus prevents SQL injection by using entity manager to execute Named and Criteria (prepared-statement) queries against the database.

Fig. 6. Solution Model Security design.

The above security design ensures smooth security interoperability between the implementation of each layer.

@RolesAllowed("Manager") public void saveUserLoginCredentials(String username, String email, String name) throws Exception { validateInput(username, email, name); ifEmailIsFromValidDomain(email); User user= new User(username, email, generateOneTimePass(), name); em.persist(user); emailer.sendUserAccountActivationLink(user); } @RolesAllowed("User") public void activateUserAcount(String username, String password) throws Exception { User user = em.find(Users.class, username); validateInput(user); user.setUserpassword(encryptPassword(password)); user.setCreationTime(currentTime); user.setKey(passwordKey); em.merge(user); } Fig. 7. Account creation & activation pseudo code.

We employed the WSIT security framework discussed earlier as it provides a more complete solution for end-to-end message security. The WSIT ensures that each of the providers (payment, order or currency service) via secure channel registers its WSDL containing its security policy in the UDDI. The consumer (order service or order client) discovers the provider via the UDDI and securely requests its WSDL and generates the client stubs necessary to send SOAP requests to the provider. The provider only accepts request from the consumer (may be a browser) when its security policy is met and would pass the request to the service which processes the request using EJBs which will use the persistence entity objects to communicate with the database. V.

TEST & RESULT

We conducted tests against all the security requirements of the secure model application as described in the solution model section. However, due to space constraints we have only outlined some of the tests conducted and their results using log records produced by the application while in action against the security violations such as invalid digital signature, invalid security header, invalid security binding and access control. A. Signature verification A client Web service with an unverifiable signature sends a SOAP message to the Payment-service. The request failed with an exception indicating there was an error in verifying the client Web service signature (see fig. 8).

Fig. 8. Payment-service rejects SOAP request for invalid client signature.

B. Message Authentication A client Web service sends a SOAP request with wrong security header. The request failed with an exception indicating invalid security header was received (see fig. 9).

Fig. 9. Payment-service rejects SOAP request for invalid security header.

C. SSL The order-service Web service sends a SOAP message to the payment-service through an unsecure channel. The request is rejected with an exception indicating insecure security binding (see fig. 10). SEVERE: WSS1601: Security Requirements not met - Transport binding configured in policy but incoming message was not SSL enabled SEVERE: WSITPVD0035: Error in Verifying Security in Inbound Message. Fig. 10. Payment-service rejects SOAP request for invalid security binding.

D. Authorisation & Access Control An Order-client user invokes a privileged operation with a limited right, service denies access to operation (see fig. 11).

Fig. 11. Order-service denies request due to insufficient access privilege.

VI.

EVALUATION OF TEST RESULTS

The tests conducted were based on the security and functional requirements of the model Web service-based ebusiness application. In other to simulate attacks on the secure model application, client Web service applications that did not adhere to the required security policies of the providers were developed as well as those that adhered to them. This served in testing the model application against various signature and certificate based security violations. The model application provider refused connections from those clients that did not adhere to its WSIT security policies while allowing communication with those that did. We tested the ability of the model e-business application to: • Verify valid signatures used in signing messages. • Authenticate messages. • Verify certificates. • Validate and enforce timestamps policy. • Authenticate, authorize and control user access. • Protect confidential information in storage. • Enforce data integrity and confidentiality en route. • Enforce database integrity and data confidentiality.

The results obtained from these tests proved that the model e-business application met its signature and certificate security requirements. Some non-signature and certificate related security requirements the application provided were: • Secures user session by invalidating inactive session after 30 minutes. • Restrict users to single system sign-on to preserve system resources & prevent DOS attacks. • E-mails users on action outcomes, recovers and emails administrators on security violations or attacks. • Conducts secure real time credit card verification and online payment service. • Offers order processing and currency rate services. • Detects session hijacking and prevents it by invalidating the session and locking out the attacker. • Tracks failed logins, user locations and prevents Dictionary Attacks after 3 failed logins. • Prevents SQL and XML Injection attacks through type safe SQL queries and use of EJBs respectively. SSL was used to provide confidentiality and integrity by using encryption to protect messages on the wire; this ensured that even if router or switch traffic is captured and analyzed, confidential data cannot be viewed and if the encrypted data is modified in transit the message may not decrypt correctly. We used X.509 authentication token to provide message authentication, so if a message is tampered or is not from the right source it will be noticed. We used a timestamp to ensure freshness of messages. Freshness is important to void replay attacks. Non-repudiation was achieved by signing the message which was configured by specifying the Require Signature Confirmation attribute in WSIT to ensure that all messages were signed and verified. The Algorithm suite (3DES) we employed uses a key length of 168 bits for message encryption which has no known threats presently [15]. The consumer communications were secured using SSL and the application deployment environment with VPN. We employed a dedicated stateful firewall to ensure fine grain traffic filtering and host based access control. Security performance was optimized by enabling Secure Conversion, this ensured that a security context was created and establishing trust for each message exchange was not required, this reduced the overhead of encryption. Require Derived Keys for Secure Session was enabled to ensure that new session keys were derived from existing session key for each message exchange, this makes cryptanalysis even more difficult and produced an overall end-to-end secure Web service-based e-business scenario. VII. CONCLUSION It has become obvious that there is need to re-evaluate security mechanisms based on XML encryption and the security community advocates a new encryption scheme to

replace XML encryption. One of the most effective ways to secure Web services based e-businesses is WSIT because of its ease of use, security interoperability and adaptability. In the WSIT, the service endpoint security policy contract declares, describes and governs the conditions of use, interoperability and of the available services without any prior recourse or consideration of who its subscribers would be, but rather of what resources, risks and security threats the service provider protects. Therefore, it is the decision of the subscriber to either accept the contract and operate under the web service provider’s security policies or reject it. Securing Web services based e-businesses using WSIT achieves end-to-end security and guarantees security and interoperability to the clients that wish to communicate with the web service provider provided the clients satisfy the contract requirements advertised in the providers security policy file. Nevertheless, we must employ a security-in-depth approach to securing Web service-based ebusinesses. Therefore, we recommend not only WSIT but a layered security approach that ensures that data is protected from unauthorized access at every layer of the application as we implemented in the security design presented in this paper. REFERENCES [1] [2] [3] [4] [5] [6]

[7]

[8] [9] [10] [11] [12] [13] [14] [15]

H. Hugo, and B. Allen, “Web Services Glossary”, W3C Working Group. http://www.w3.org/TR/ws-gloss/, Retrieved June 10th, 2012. Vinoski, S. (2002). Web Services Interaction Models — Part 1: Current Practice. IEEE Internet Computing, 6(3), 89-91. P. Cesare, Z. Olaf, and L. Frank, “Proceedings of the 17th International Conference on the World Wide Web,” pp. 805-814, 2008, Retrieved June 10th, 2012, http://wwwconference.org/www2008/. K.M. Upendra, and K.D. Sravan, “Designing Dependable Service Oriented Web Service Security Architectures Solutions,” International Journal of Engineering and Technology vol. 2, 81-86, 2010. S. Juraj, and S. Jorg, “Technical Analysis of Countermeasures against attacks on XML Encryption – or – Just Another Motivation for Authenticated Encryption: Services,” IEEE, 2012, vol. 10, pp. 171-178. N.C.R. Jason, and S.E. Jane, “BOF4WSS: A Business-Oriented Framework for Enhancing Web Services Security for e-Business. Fourth International Conference on Internet and Web Applications and Services,” IEEE, 2009, vol. 48, pp. 286-291. P. Addison, T. Mary, S. Felix, W3C, IBM, and Yahoo, “Web Services Internationalization (WS-I18N),” W3C Working group, Retrieved 1 September 2012, http://www.w3.org/TR/2012/NOTE-ws-i18n20120522/. U. Dittmer, “Web Service Security Part 1: Authentication,” Accessed 12 August 2012, http://www.javaranch.com/journal/200603/WSSecurity.html. H. Eben, “Java SOA cookbook,” Cambridge: O'Reilly Media, Inc. 2009. P. Kearney, J. Chapman, N. Edwards, M. Gilfford, and L. He, “An overview of Web Services Security,” BT Technology Journal, vol. 22, pp. 27- 42, 2004. Y. Gilard, and Herzberg, “A defence against IP spoofing and flooding attacks,” ACM Transaction Inf. Syst. Security, vol. 15, Article 6, 2012. S.C. Robert, “Secure coding in C & C++,” Addison-Wesley Professional, Massachusetts. G.G Mark and W.V.R. Kenneth, “Secure coding: principles & practices,” O'Reilly, California. Oracle Corporation, “Java Enterprise Edition: The Java EE 6 Tutorial,” Oracle USA, 2011, unpublished. S. William, “Cryptography and network security principles and practice,” 5th Ed, Pearson Education Limited, New Jersey, 2010.