No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
WS-SecurityPolicy Decision and Enforcement for Web Service Firewalls
Abstract
A known weakness of Web Services is their vulner- ability to Denial of Service attacks exploiting XML processing characteristics. To protect Web Services from these attacks, extended validation of SOAP messages—considering WS-Security and WS-SecurityPolicy—is made. For SOAP security is message oriented, the processing of the security content itself is vulnerable to Denial of Service attacks. Hence, it is necessary to combine WS-Security processing and DoS protection. In this paper, we present our solution for WS-SecurityPolicy- based policy decision within Web Service Firewalls. For this, we give a technical description and an algorithm addressing major parts of policy decision, as well as a proposal for enhancing message signature identification. Further, we argue for advancing protection of Web Services by improved policy enforcement. This paper contributes to understanding the complexity of protecting Web Services by security gateways. I. INTRODUCTION
... Since a SOAP message can contain many signatures, identification of the message signature is necessary. As shown in an earlier paper [9], this identification can be assured by claiming the exclusive signing of the WS-Addressing element <wsa:Action> within the security policy. ...
Access control and ensuring availability are important tasks for securing Web Services. Both requirements are not well studied on Web Services and especially not their interactions. However, considering this interaction is crucial. On one hand, access control is an established mechanism for protecting services from attacks targeting the service¿s availability. On the other hand, enforcing access control on Web Services is a complex task and therefore access control implementations potentially offer new possibilities for attacks. In this paper a solution for Web Service access control enforcement is presented using an event-based processing model focusing on ensuring Web Service availability.
... This means, a SOAP message must contain exactly the security tokens specified by the security policy—not less, not more. As pointed out in [6], this limitation does not restrict the functionality, but enables the detection of attacks using oversized cryptography and can help to mitigate their effects. ...
Being regarded as the new paradigm for Internet communication, Web Services have introduced a large
number of new standards and technologies. Though founding on decades of networking experience, Web Services
are not more resistant to security attacks than other open network systems. Quite the opposite is true:
Web Services are exposed to attacks well-known from common Internet protocols and additionally to new kinds
of attacks targeting Web Services in particular. Along with their severe impact, most of these attacks
can be performed with minimum effort from the attacker’s side.
This article gives a survey of vulnerabilities in the context of Web Services. As a proof
of the practical relevance of the threats, exemplary attacks on widespread Web Service implementations were
performed. Further, general countermeasures for prevention and mitigation of such attacks are discussed.
Security is a major concern of today's enterprise Web Services due to its distributed nature and message oriented communication. Web Service messages containing confidential information can be transmitted over unsecured networks thus should have appropriate mechanisms to protect them from possible attacks. To cater these requirements, Web Services Security specification defines enhancements to SOAP messaging providing authentication, message integrity, and confidentiality without losing interoperability. Web Services use a security policy language to express security requirements and capabilities. Thus security policy processing plays a vital role in any web service security engine. Security policy processing model should be both efficient and invincible to potential attacks. In this paper, we evaluate the current Web Service security processing models and discuss their weaknesses. We propose an improved security processing model for Web Services security which is more efficient and less vulnerable to attacks such as Denial of Service (DoS) attacks.
With SOAP-based web services leaving the stadium of being an explorative set of new technologies and entering the stage of mature and fundamental building blocks for service-driven business processes-and in some cases even for mission-critical systems-the demand for nonfunctional requirements including efficiency as well as security and dependability commonly increases rapidly. Although web services are capable of coupling heterogeneous information systems in a flexible and cost-efficient way, the processing efficiency and robustness against certain attacks do not fulfill industry-strength requirements. In this paper, a comprehensive stream-based WS-Security processing system is introduced, which enables a more efficient processing in service computing and increases the robustness against different types of Denial-of-Service (DoS) attacks. The introduced engine is capable of processing all standard-conforming applications of WS-Security in a streaming manner. It can handle, e.g., any order, number, and nesting degree of signature and encryption operations, closing the gap toward more efficient and dependable web services.
For service-oriented business processes, an important security requirement is confidentiality of transmitted data. Here, existing Web Services security standards provide suitable solutions for single invocations, but fail to cover service composition scenarios properly, especially for securing business process data against partners. In this paper, we investigate the issues regarding the realization of process level confidentiality in WS-BPEL-based Web Service compositions.
For Web Services in Cloud Computing contexts, the efficient processing of XML documents is a major topic of interest. Especially for WS-Security-enriched messages, processing performance nowadays tends to become a major issue. Streaming XML processing approaches lead to valuable optimization due to lower resource consumption, but their adoption requires major conceptional changes in the processing application.In this paper, we present a pattern for architectural concepts that employ the SAX-based streaming processing approach. Its major benefit--apart from providing the performance advantage--consists in a convenient, modular architecture that can easily be extended with new modules and new types of events without modification of existing modules.
The rising need for security in SOA applications requires better support for management of non-functional properties in Web-based business processes. Here, the model-driven approach may provide valuable benefits in terms of maintainability and deployment. Apart from modeling the pure functionality of a process, the consideration of security properties at the level of a process model is a promising approach. In this work-in-progress paper we present an extension to the ARIS SOA architect that is capable of modeling security requirements as a separate security model view. Further we provide a transformation that automatically derives WS-security policy-conformant security policies from the process model, which in conjunction with the generated WS-BPEL processes and WSDL documents provides the ability to deploy and run the complete security-enhanced process based on Web service technology.
SOAP-based Web Services enable flexible software system integration especially in heterogeneous environments and is a driving technology for inter-organization business processes. Yet, the verbosity of the XML-based protocol and its accompanying standards poses performance challenges which need to be addressed and solved to obtain the efficiency and scalability required by large information systems.This paper proposes a novel approach to overcome these performance issues in scenarios where multiple service invocations occur between a requester and a service. A protocol is introduced which allows negotiating common and distinctive parts of the SOAP message. Thereby, a session is established between these two peers in which only distinctive parts of the SOAP message are subsequently transferred over the wire. This results in a significant efficiency improvement regarding transmission as well as processing costs.
Being regarded as the new paradigm for Internet communication, Web Services have introduced a large number of new standards and technologies. Though founding on decades of networking experience, Web Services are not more resistant to security attacks than other open network systems. Quite the opposite is true: Web Services are exposed to attacks well-known from common Internet protocols and additionally to new kinds of attacks targeting Web Services in particular. Along with their severe impact, most of these attacks can be performed with minimum effort from the attacker's side. In this paper we present a list of vulnerabilities in the context of Web Services. To proof the practical relevance of the threats, we performed exemplary attacks on widespread Web Service implementations. Further, general countermeasures for prevention and mitigation of such attacks are discussed.
This document specifies XML (Extensible Markup Language) digital signature processing rules and syntax. XML Signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere.
Naive use of XML Signature may result in signed documents remainingvulnerable to undetected modification by an adversary. In thetypical usage of XML Signature to protect SOAP messages, anadversary may be capable of modifying valid messages in order togain unauthorized access to protected resources.This paperdescribes the general vulnerability and several related exploits,and proposes appropriate countermeasures. While the attacksdescribed herein may se obvious to security experts once they areexplained, effective countermeasures require careful securitypolicy specification and correct implentation by signed messageproviders and consumers. Since these implenters are not alwayssecurity experts, this paper provides the guidance necessary toprevent these attacks.
Sabotageangriffe, im Englischen auch als „Denial of Service Attacks (DoS-Attacks)“ bezeichnet, zielen darauf ab, die Verfügbarkeit bestimmter Systeme oder Dienste für berechtigte Nutzer zu reduzieren bzw. die entsprechenden Systeme und Dienste vollständig außer Betrieb zu setzen. In diesem Beitrag wird ein Überblick über in Sabotageangriffen verwendete, grundlegende Techniken und prinzipielle Abwehrmaßnahmen gegeben.
Web Services Addressing provides transport-neutral mechanisms to address Web services and messages. Web Services Addressing SOAP Binding (this document) defines the binding of the abstract properties defined in Web Services Addressing Core to SOAP Messages.
This document is a glossary of policy-related terms. It provides abbreviations, explanations, and recommendations for use of these terms. The document takes the approach and format of RFC 2828, which defines an Internet Security Glossary. The intent is to improve the comprehensibility and consistency of writing that deals with network policy, particularly Internet Standards documents (ISDs).
The Web service security challenge is to understand and assess the risk involved in securing a Web-based service today, based on our existing security technology, and at the same time track emerging standards and understand how they will be used to offset the risk in new Web services. Any security model must illustrate how data can flow through an application and network topology to meet the requirements defined by the business without exposing the data to undue risk. In this paper we propose a mechanism for the client to provide authentication data, based on the service definition, and for the service provider to retrieve those data. We also show how XML Digital Signatures and encryption can be exploited to achieve a level of trust.
WS-SecurityPolicy is a declarative language for configuring web services se- curity mechanisms. We describe a formal semantics for WS-SecurityPolicy and propose a more abstract language for specifying secure links between web ser- vices and their clients. We present the architecture and implementation of tools that (1) compile policy files from link specifications, and (2) verify by invoking a theorem prover whether a set of policy files run by any number of senders and receivers correctly implements the goals of a link specification, in spite of active attackers. Policy-driven web services implementations are prone to the usual sub- tle vulnerabilities associated with cryptographic protocols; our tools help prevent such vulnerabilities. We can verify policies when first compiled from link specifi- cations, and also re-verify policies against their original goals after any modifica- tions during deployment. Moreover, we present general security theorems for all configurations that rely on compiled policies.
We identify common security vulnerabilities found during security reviews of web services with policy-driven security. We describe the design of an advisor for web services security configurations, the first tool both to identify such vulnerabilities automatically and to offer remedial advice. We report on its implementation as a plu- gin for Microsoft Web Services Enhancements (WSE).
To enable checking of SOAP messages for compliance to a given security policy, extensions to the classical ,,Schema-only'' validation of SOAP messages are required. These extensions check, if the WS-Security elements found in a SOAP message fulfill the Web Service security specification that is laid down in the WS-SecurityPolicy document. In this paper, we discuss to what extent the proposed extended validation of SOAP messages can be accomplished by an event-based validation system. We prefer this type of processing for use in network appliances like e.g.Web Service-level firewalls, because it is suited to resist DoS attacks that aim at memory exhaustion. We identify some of the constraints on the use of both WS-Security and WSSecurityPolicy that must be introduced to allow for event-based parsing, and finally present an initial prototype for extended validation together with some performance figures.
Though Web Services become more and more popular, not only inside closed intranets but also for inter-enterprise communications, few eorts have been made so far to secure a Web Service's availability. Existing security standards like e.g. WS-Security only address message integrity and confidentiality, and user authentication and authorization. In this article we present a system for protecting Web Services from Denial-of-Service (DoS) attacks. DoS attacks often rely on misformed and/or overly long messages that engage a server in resource-consuming computations. Therefore, a suitable means to prevent such kinds of at- tacks is the full grammatical validation of messages by an application level gateway before forwarding them to the server. We discuss specific kinds of DoS attacks against Web Services, show how message grammars can automatically be derived from formal Web Service descriptions (writ- ten in the Web Service Description Language), and present an application level gateway solution called "Checkway" that uses these grammars to filter Web service messages. The paper closes by giving some performance figures for full grammatical validation.
This specification defines the Document Object Model Level 1, a platform- and
language-neutral interface that allows programs and scripts to dynamically
access and update the content, structure and style of documents.
The Document Object Model provides a standard set of objects for
representing HTML and XML documents, a standard model of how these
objects can be combined, and a standard interface for accessing and
manipulating them. Vendors can support the DOM as an interface to their
proprietary data structures and APIs, and content authors can write
to the standard DOM interfaces rather than product-specific APIs,
thus increasing interoperability on the Web. The goal of the DOM
specification is to define a programmatic interface for XML and HTML. The DOM
Level 1 specification is separated into two parts: Core and HTML. The
Core DOM Level 1 section provides a low-level set of fundamental
interfaces that can represent any structured document, as well as
defining extended interfaces for representing an XML document. These
extended XML interfaces need not be implemented by a DOM implementation
that only provides access to HTML documents; all of the fundamental
interfaces in the Core section must be implemented. A compliant DOM
implementation that implements the extended XML interfaces is required to
also implement the fundamental Core interfaces, but not the HTML
interfaces. The HTML Level 1 section provides additional, higher-level
interfaces that are used with the fundamental interfaces defined in the
Core Level 1 section to provide a more convenient view of an HTML
document. A compliant implementation of the HTML DOM implements all
of the fundamental Core interfaces as well as the HTML interfaces.
Denial of service is becoming a growing concern. As our systems communicate more and more with others that we know less and less, they become increasingly vulnerable to hostile intruders who may take advantage of the very protocols intended for the establishment and authentication of communication to tie up our resources and disable our servers. Since these attacks occur before parties are authenticated to each other we cannot rely upon enforcement of the appropriate access control policy to protect us. Instead we must build our defenses, as much as possible, into the protocols themselves. This paper shows how some principles that have already been used to make protocols more resistant to denial of service can be formalized, and indicates the ways in which existing cryptographic protocol analysis tools could be modified to operate within this formal framework
Basic Profile Version 1.1
- K Ballinger
- D Ehnebuske
- C Ferris
- M Gudgin
- C K Liu
- M Nottingham
- P Yendluri
K. Ballinger, D. Ehnebuske, C. Ferris, M. Gudgin, C. K. Liu, M. Nottingham, and P. Yendluri, "Basic Profile Version 1.1," WS-I Organisation,
2004.
- A Nadalin
- C Kaler
- R Monzillo
- P Hallam-Baker
A. Nadalin, C. Kaler, R. Monzillo, and P. Hallam-Baker, "Web Services
Security: SOAP Message Security 1.1 (WS-Security 2004)," 2006.
Attacking and Defending Web Service
- P Lindstrom
P. Lindstrom, "Attacking and Defending Web Service," A Spire Research
Report, 2004.
Simple API for XML -SAX 2.0.1
- Sax The
- Project
The SAX Project, "Simple API for XML -SAX 2.0.1," 2002.
Eventbased and Policy-driven Web Service Firewall
- R Herkenhöner
R. Herkenhöner, "Eventbased and Policy-driven Web Service Firewall,"
Diploma thesis, 2005.
Web services addressing 1.0 -soap binding
- M Gudgin
- M Hadley
- T Rogers
M. Gudgin, M. Hadley, and T. Rogers, "Web services addressing 1.0 -soap binding," W3C Recommendation, May 2006.