Language-Based Anomaly Detection in Client-Cloud Interaction

Author Harald Lampesberger, MSc

Submission Christian Doppler Laboratory for Client-Centric Cloud Computing, Institute for Application Oriented Knowledge Processing

First Supervisor Prof. Dr. Klaus-Dieter Schewe

LANGUAGE-BASED Second Supervisor Prof. Dr. Joachim Biskup

ANOMALY DETECTION April 2016 IN CLIENT-CLOUD INTERACTION

Doctoral Thesis to confer the academic degree of Doktor der technischen Wissenschaften in the Doctoral Program Technische Wissenschaften

JOHANNES KEPLER UNIVERSITY LINZ Altenberger Str. 69 4040 Linz, Austria www.jku.at DVR 0093696

Sworn Declaration

I hereby declare under oath that the submitted Doctoral Thesis has been written solely by me without any third-party assistance, information other than provided sources or aids have not been used and those used have been fully documented. Sources for literal, paraphrased and cited quotes have been accurately credited. The submitted document here present is identical to the electronically submitted text document.

Linz, 20th April 2016 Harald Lampesberger

iii iv Abstract

For consuming a cloud service, clients and services need to communicate using a variety of languages and protocols. The Extensible Markup Language (XML) is the foundation of electronic data exchange in many existing and upcoming cloud standards and subject of this thesis. XML-based protocols are usually declared in the industry standard XML Schema (XSD), and schema validation is a first line of defense against syntactically undesirable protocol messages. However, schemas are not enforced in some XML-based protocols and may not be available, and XSD best practices recommend extension points for loose composition. Schema extension points are in fact wildcards. They exist in many protocol specifications, and they break schema validation. An attacker can add arbitrary content into a document at an extension point without being rejected by schema validation. This is exploited by various attacks, i.e., the signature wrapping attack, and in the last years, several signature wrapping attacks were successfully executed against cloud management interfaces and identity providers. Syntactic schema validation can be effective against this attack but requires a language representation without extension points. In this thesis, I propose a security monitor for language-based anomaly detection in XML-based interaction. The security monitor has a learner and validator component. The learner infers an automaton from syntactically acceptable messages, and the validator utilizes the automaton for identifying syntactically non-acceptable messages in an interaction. Only learning from positive examples is considered because XML attacks are highly service specific, and violating examples are usually not available. The first contribution is extending XML visibly pushdown automata (XVPAs) toward datatyped XVPAs (dXVPAs) for representing mixed-content XML in the learner. A dXVPA is translated to a character-data XVPA (cXVPA) for efficient stream validation in the validator. The second contribution is a lexical datatype system for generalizing text contents in mixed-content XML by inferring datatypes according to lexical subsumption and a preference heuristic. The third contribution is a set of algorithms for an incremental and set-driven learner. For dealing with poisoning attacks in realistic deployments, the learner has unlearning and sanitization capabilities for removing once-learned examples and trimming low-frequent states and transitions. A prototype has been experimentally evaluated in two synthetic and two simulated scenarios. Realistic data was generated from an Apache Axis2 web service by simulating state-of-the-art XML attacks. The proof of concept showed promising results: the learner only needed a few examples to converge to a stable language representation. Detection rates for all datasets were between 82.35% and 100% without false positives and outperformed traditional schema validation. Poisoning attacks were also successfully removed by unlearning and sanitization. Use cases for integrating the proposed security monitor are, e.g., a middleware security component, an anomaly detection component in XML firewalls, and a client browser plug-in for filtering XML-based resources.

v vi Kurzfassung

Für die Nutzung eines Cloud-Services müssen Klienten und Services mit einer Vielfalt an Sprachen und Protokollen kommunizieren. Die Extensible Markup Language (XML) nimmt hier eine spezielle Rolle ein, da viele aktuelle und zukünftige Standards im Cloud Computing auf XML-basierten Protokollen aufbauen. XML steht deshalb im Zentrum dieser Arbeit. XML-basierte Protokolle sind typischerweise im Industriestandard XML-Schema (XSD) spezifiziert. Schema-Validierung ist daher eine erste Instanz um syntaktisch unerwünschte Protokollnachrichten zu filtern. Schemas sind in manchen Protokollen jedoch nicht zwingend erforderlich und daher möglicherweise nicht verfügbar, und sogenannte Erweiterungspunkte haben sich in XSD für die lose Komposition von Schemas durchgesetzt. Schema-Erweiterungspunkte sind Platzhalter, die in vielen Protokollspezifikationen auftreten und letztendlich Schema- Validierung aushebeln. Konkret kann ein Angreifer trotz Validierung beliebigen Inhalt in einem XML-Dokument platzieren. Das kann für verschiedene Angriffe ausgenützt werden, z.B. für einen Signature-Wrapping-Angriff. In den letzten Jahren wurden mehre- re erfolgreiche Signature-Wrapping-Agriffe auf Cloud-Management-Schnittstellen und Identitätsprovider demonstriert. Syntaktische Validierung von Dokumenten könnte den Signature-Wrapping-Angriff verhindern, wenn keine Erweiterungspunkte in der Sprach- repräsentation sind. Diese Dissertation beschreibt einen Sicherheitsmonitor für sprachbasierte Anoma- lieerkennung in XML-basierter Interaktion. Der Sicherheitsmonitor hat eine Lern- und eine Validierungskomponente. Die Lernkomponente erlernt einen Automaten aus syntaktisch akzeptablen Protokollnachrichten, und die Validierungskomponente benützt diesen Automaten, um syntaktisch nicht-akzeptable Protokollnachrichten in der Interaktion zu identifizieren. Das Lernverfahren konzentriert sich ausschließlich auf Positivbeispiele, da XML-Angriffe sehr servicespezifisch sind und dadurch die Verfügbarkeit von Gegenbei- spielen üblicherweise nicht gegeben ist. Der erste Beitrag umfasst Erweiterungen des XML Visibly Pushdown Automaten (XVPA) mittels Datentypen (dXVPAs) als Sprachdarstellung von mixed-content XML in der Lernkomponente. Ein dXVPA lässt sich wiederum in einen character-data XVPA (cXVPA) übersetzen, welcher für effiziente Stream-Validierung in der Validierungskom- ponente herangezogen wird. Der zweite Beitrag ist ein lexikalisches Datentypensystem für das Generalisieren von Textinhalten in mixed-content XML durch Datentypen. Pas- sende Datentypen für einen Textinhalt werden durch lexikalische Subsumtion und einer Präferenzheuristik ermittelt. Der dritte Beitrag umfasst Algorithmen für einen schrittwei- sen und mengenbasierten Lerner. Um den praktischen Umgang mit Poisoning-Angriffen in realistischen Umgebungen zu erleichtern, hat der Lerner zusätzliche Fähigkeiten: er kann bereits gelernte Beispiele wieder vergessen, und durch das Entfernen von wenig frequentierten Zuständen und Zustandsübergängen können versteckte Poisoning-Angriffe bereinigt werden.

vii Ein Softwareprototyp wurde experimentell in zwei synthetischen und zwei simulierten Szenarios evaluiert. Mithilfe eines Apache-Axis-2-Webservices und durch Simulation von aktuellen XML-Angriffen wurden realistische Daten erzeugt. Die Experimente zeig- ten vielversprechende Ergebnisse. Der Lerner benötigte in allen Szenarien nur wenige Beispiele für die Konvergenz zu einer stabilen Sprachrepräsentation. Des Weiteren waren die Erkennungsraten in allen Szenarien zwischen 82,35% und 100%, frei von Falschalar- men und übertrafen traditionelle Schema-Validierung. Poisoning-Angriffe konnten durch gezieltes Vergessen und Bereinigen erfolgreich entfernt werden. Anwendungsfälle für die Integration des vorgeschlagenen Sicherheitsmonitors wären eine Middleware-Sicherheitskomponente, eine Anomalieerkennungskomponente in einer XML Firewall, und ein klientenseitiges Browser Plug-In für die Analyse von XML- basierten Webressourcen.

viii Acknowledgments

First and foremost, I wish to thank my advisor Prof. Dr. Klaus-Dieter Schewe for his excellent guidance, continuous support, and patience over the last four years. He has taught me the rigorous way, sparked my interest in theoretical computer science, and given me the scientific freedom to pursue my ideas. Becoming a scientist under your supervision was a great experience, and I will forever be thankful to you. I would also like to express my gratitude to Prof. Dr. Joachim Biskup who kindly agreed to act as a co-advisor and to examine my work. Thank you for having given me the opportunity to discuss my research at TU Dortmund and for the invaluable feedback at an important stage of my dissertation project. Many thanks also go to fellow labmates and friends, Dr. Károly Bósa, Andreea Buga, Ursula Haiberger, Roxana Holom, Tania Nemes, Mariam Rady, Mircea Boris Vleju, and Ciprian Zavoianu.˘ Thank you for all the fruitful discussions, the funny moments, the nice atmosphere in the laboratory, and all the mental support during writing this thesis. Furthermore, I would like to thank my friends Matthias Pfötscher, Florian Wex, and Philipp Winter for the inspiring discussions in- and outside academia. Lastly, and most importantly, I send my sincerest gratitude to Verena, for all your love and support throughout my doctoral studies. My deepest gratitude goes to my loving parents Maria and Alois, who enabled me to pursue an academic education and helped me through all the years, and to my sisters Bettina, Barbara, Karin, and Andrea for the moral support. This work is dedicated to you.

ix x Contents

Sworn Declaration iii

Abstractv

Kurzfassung vii

Acknowledgments ix

Abbreviations xix

1 Introduction1 1.1 Motivation...... 3 1.1.1 Language-Theoretic Security...... 4 1.1.2 XML Attacks and Schema Validation...... 6 1.2 Objectives...... 8 1.3 Outline...... 9 1.4 Contributions...... 9

2 Background: Interaction and Monitoring 11 2.1 Client-Cloud Interaction...... 11 2.1.1 Historical Context...... 12 2.2 Languages for Content and Media...... 13 2.2.1 Data Serialization Formats...... 13 2.2.2 Container Formats...... 14 2.3 Service Interaction Patterns...... 14 2.3.1 Single-Transmission Bilateral Patterns...... 15 2.3.2 Single-Transmission Multilateral Patterns...... 15 2.3.3 Multi-Transmission Patterns...... 15 2.3.4 Routing Patterns...... 16 2.4 Protocols for Computer Networks...... 16 2.4.1 Transport Layer Protocols...... 17 2.4.2 Application Layer Protocols...... 19 2.5 Cloud Interaction Architectures...... 22 2.5.1 Web Architectures...... 23 2.5.2 Service Architectures...... 25 2.5.3 Cloud Computing Aspects...... 33 2.6 Monitoring of Client-Cloud Interaction...... 34 2.6.1 Cloud Monitoring...... 35 2.6.2 Observation Points...... 36

xi 2.7 Implications of Technological Trends...... 40

3 Literature Review 43 3.1 Anomaly-Based Intrusion Detection...... 43 3.1.1 Network Layer Anomaly Detection...... 45 3.1.2 Operating System Layer Anomaly Detection...... 46 3.1.3 Service, Middleware, and User Layer Anomaly Detection... 46 3.1.4 Language-Theoretic View on Intrusion Detection...... 47 3.1.5 Intrusion Detection Evasion...... 49 3.1.6 Kernel-Based Anomaly Detection in Tree-Structured Data... 49 3.1.7 XML Anomaly Detection...... 53 3.2 The Extensible Markup Language...... 53 3.2.1 Namespaces...... 54 3.2.2 Parsing...... 54 3.2.3 Schema Languages...... 55 3.2.4 XPath...... 58 3.2.5 Syntactic Optimizations...... 58 3.3 XML Attacks...... 59 3.3.1 Parsing Attacks...... 59 3.3.2 Semantic Attacks...... 61 3.3.3 Schema Extensibility and Effects on Validation...... 62 3.3.4 XML Signature Wrapping Attack...... 63 3.3.5 Language-Theoretic View on XML Attacks...... 68 3.4 Stream Validation...... 68 3.4.1 Visibly Pushdown Automata...... 68 3.4.2 XML Visibly Pushdown Automata...... 69 3.4.3 VPAs in XML Research...... 71 3.5 Schema Inference...... 71 3.5.1 DTD Inference...... 71 3.5.2 XSD Inference...... 73 3.6 Wrapper Inference for Information Extraction...... 75

4 Language-Based Anomaly Detection 77 4.1 Problem Description...... 78 4.1.1 Architecture and Assumptions...... 78 4.1.2 XML Stream Validation...... 79 4.1.3 Grammatical Inference...... 80 4.1.4 Applicability...... 80 4.2 Methodology...... 81 4.2.1 Datatyped Language Representation...... 81 4.2.2 A Lexical Datatype System for Datatype Inference...... 82 4.2.3 Learning from Positive Examples...... 82 4.2.4 Anomaly Detection Refinements...... 84 4.2.5 Experimental Evaluation...... 85 4.3 Use Cases...... 85

xii 5 Grammatical Inference of XML 87 5.1 Document Event Stream Representation...... 87 5.2 Models for Datatypes and Text Content...... 88 5.2.1 Datatyped EDTD...... 88 5.2.2 Datatyped XVPA...... 90 5.2.3 Character-Data XVPA for Stream Validation...... 92 5.3 A Lexical Datatype System for Datatype Inference...... 93 5.3.1 Lexical Subsumption...... 94 5.3.2 Linear-Time Lexical Subsumption Computation...... 95 5.3.3 Preference Heuristic...... 97 5.3.4 Datatyped Event Stream for Learning...... 98 5.3.5 Combining Datatypes and Incremental Update...... 98 5.4 Learning from Positive Examples...... 99 5.4.1 The k-Testable Regular Languages for Element Locality.... 100 5.4.2 Schema Typing Mechanisms for Type Contexts...... 101 5.4.3 Visibly Pushdown Prefix Acceptor...... 103 5.4.4 State Merging for Generalization...... 107 5.4.5 Generating dXVPAs...... 109 5.4.6 Parameter Semantics...... 112 5.5 Learner Properties...... 113 5.5.1 Computational Complexity...... 114 5.6 Anomaly Detection Refinements...... 115 5.6.1 Event Stream Security Heuristics...... 115 5.6.2 Filtering...... 116 5.6.3 Unlearning and Evolution...... 116 5.6.4 Sanitization...... 120

6 Experimental Evaluation 123 6.1 Implementation...... 123 6.2 Measures...... 123 6.2.1 Detection Performance...... 124 6.2.2 Learning Progress...... 125 6.2.3 Operational Performance...... 125 6.3 Evaluation Scenarios...... 126 6.3.1 Synthetic Datasets...... 127 6.3.2 Simulated Datasets...... 127 6.4 Performance Results...... 128 6.4.1 Detection Performance...... 128 6.4.2 Learning Progress...... 131 6.4.3 Operational Performance...... 132 6.4.4 Unlearning...... 133 6.4.5 Sanitization...... 133

7 Conclusions 137 7.1 Summary...... 137 7.2 Objectives...... 138 7.3 Assumptions, Restrictions, and Design Choices...... 139 7.4 Discussion of Results...... 141

xiii 7.5 Open Questions...... 142 7.5.1 Extended and Comparative Evaluation...... 142 7.5.2 Modeling and Learning Improvements...... 143 7.5.3 Query Learning...... 144 7.5.4 Architectural Aspects...... 144

A XML Schema Datatype Hierarchy 145

B Additional Experiments 147

Bibliography 157

Curriculum Vitae 187

xiv List of Figures

1.1 A client and a service exchange messages over some transport mechanism in an agreed communication protocol for interaction...... 1 1.2 LangSec threat model...... 4 1.3 Relationships of the relevant sets of inputs and their approximations by language-based intrusion detection methods (reproduced from [58, p. 357]) 5 1.4 Classical XML signature wrapping attack [393]...... 7

2.1 Concepts and relationships identified in communication technologies226 [ ] 11 2.2 Service interaction patterns for messaging between parties [37, 38]... 15 2.3 The Internet model [67] and client-cloud communication protocols... 16 2.4 An URL identifies and locates a resource...... 19 2.5 Web- and service-oriented view on cloud interaction architectures [226] 23 2.6 Publish-subscribe architectures for multilateral interaction...... 28 2.7 Architectures for message-oriented middleware [104]...... 30 2.8 High-level components of a monitoring system (based on [58, p. 359]). 34

3.1 Anomaly detection errors in a binary classification setting with respect to the relevant sets of behaviors, states, or inputs (reproduced from [58, p. 357])...... 48 3.2 Vector space embeddings of a tree [355, 356]...... 50 3.3 Global and local anomaly detection in feature space [359]...... 51 3.4 XML document and it’s tree representation...... 54 3.5 XML parsing steps...... 55 3.6 Schema extension points in the SOAP XSD schema...... 63 3.7 Informal grammar of XML Signature taken from the specification [453] 64 3.8 The three types of XML Signature [453]...... 65 3.9 XPathFilter2 expression for referencing elements in XML Signature.. 65 3.10 Examples for XML signatures in SAML assertions...... 66 3.11 An exemplary XVPA and an accepted document event stream...... 71 3.12 PTA constructed from examples ac, abbcd, abc, acddd, abbbcd and { } annotated by frequencies...... 73 3.13 Lexical-subsumption datatype inference reproduced from related work. 74

4.1 Proposed language-based anomaly detection architecture...... 78 4.2 Value and lexical spaces of XSD datatypes...... 82 4.3 Learning from positive examples...... 83 4.4 The proposed learning process...... 84 4.5 CCIM architecture and components...... 86

5.1 Symbolic StAX event stream...... 88

xv 5.2 A dXVPA accepting the same documents as the dEDTD in Example4. 91 5.3 Ordering on lexically distinct XSD datatypes...... 94 ≤lex 5.4 Ordering on kinds of lexical datatypes...... 98 ≤s 5.5 Symbolic datatyped event stream...... 98 5.6 PTA and corresponding 2-testable DFA...... 101 5.7 Typing of an element...... 102 5.8 VPPA construction examples...... 106 5.9 State merging with parameters k = 1,l = 2 for the example in Figure 5.8d 108 5.10 Generated dXVPA from the VPA in Figure 5.9...... 112

6.1 Two dXVPAs inferred from dataset Carsale...... 130 6.2 Learning progress highlights...... 132 6.3 Effects of increased k and l for dataset VulnShopOrder...... 133 6.4 Effects of multiple poisoning attempts and delayed unlearning..... 134 6.5 Effects of a single poisoning attempt and later sanitization...... 135

7.1 Learning from positive examples and queries...... 144

A.1 XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes [463]. 145

B.1 Additional unlearning and sanitization experiments...... 147 B.2 Carsale learning progress using ancestor-based states...... 148 B.3 Carsale learning progress using ancestor-sibling-based states...... 149 B.4 Catalog learning progress using ancestor-based states...... 150 B.5 Catalog learning progress using ancestor-sibling-based states...... 151 B.6 VulnShopOrder learning progress using ancestor-based states...... 152 B.7 VulnShopOrder learning progress using ancestor-sibling-based states.. 153 B.8 VulnShopAuthOrder learning progress using ancestor-based states... 154 B.9 VulnShopAuthOrder learning progress using ancestor-sibling-based states 155

xvi List of Tables

2.1 Interaction patterns in communication protocols [226]...... 22 2.2 Interaction patterns in web architectures [226]...... 25 2.3 Interaction patterns in service architectures [226]...... 33

6.1 The binary confusion matrix for classification...... 124 6.2 Properties of the evaluation datasets...... 127 6.3 Baseline detection performance using schema validation...... 128 6.4 Detection performance highlights...... 129

xvii xviii Abbreviations

1PPT 1-Pass Preorder Typing

AJAX Asynchronous JavaScript and XML

AMQP Advanced Message Queuing Protocol

API Application programming interface

ASCII American Standard Code for Information Interchange

ASM Abstract State Machine

ASN.1 Abstract Syntax Notation One

BOSH Bidirectional-streams over synchronous HTTP

BPEL Business Process Execution Language

BPMN Business Process Model and Notation

CCIM Client-Cloud Interaction Middleware

CDATA Unparsed character data

CHARE Chain regular expression

CoAP Constraint Application Protocol

COM+ Microsoft Component Services

CORBA Common Object Request Broker Architecture

CORS Cross-origin resource sharing

CSP Content Security Policy

CSS Cascading Style Sheets cXVPA Character-data XVPA

DCCP Datagram Congestion Control Protocol

DCFL Deterministic context-free language

DDS Data Distribution Service for Real-Time Systems

DDoS Distributed Denial of Service

xix dEDTD Datatyped EDTD

DFA Deterministic finite automaton

DIME Direct Internet Message Encapsulation

DNS Domain Name System

DOM Document Object Model

DPI Deep Packet Inspection

DTD Document Type Definition

DTLS Datagram Transport Layer Security dXVPA Datatyped XVPA

ECFG Extended context-free grammar

EDC Element Declarations Consistent

EDSM Evidence-driven state merging

EDTD Extended Document Type Definition

EDTDst Single-type EDTD

EDTDrc Restrained-competition EDTD

FTP File Transfer Protocol

FQDN Fully qualified domain name

HTML Hypertext Markup Language

HTTP Hypertext Transfer Protocol

HTTPS HTTP Secure

IaaS Infrastructure-as-a-Service

IANA Internet Assigned Numbers Authority

IDL Interface definition language

IDPS Intrusion detection and prevention system

IDREF Identifier-based reference

IDS Intrusion detection system

IIOP Internet Inter-ORB Protocol i-ORE i-occurrence regular expression

IP Internet Protocol

xx IPS Intrusion prevention system

IPv6 Internet Protocol Version 6

JSON JavaScript Object Notation

LangSec Language-Theoretic Security

MDL Minimum description length

MIME Multipurpose Internet Mail Extensions

MML Minimum message length

MOM Message-oriented middleware

MPTCP MultiPath TCP

MQTT Message Queue Telemetry Transport

MSMQ Microsoft Message Queue

MTOM Message Transmission Optimization Mechanism

NFA Nondeterministic finite automaton

OWL Web Ontology Language

PaaS Platform-as-a-Service

PCDATA Parsed character data

PTA Prefix tree acceptor

QUIC Quick UDP Internet Connections

REG The class of regular languages

RDF Resource Description Framework

REST Representational State Transfer

RPC Remote procedure call

RPNI Regular Positive and Negative Inference

RSS Rich Site Summary

RTPS Real-Time Publish-Subscribe

RUDP Reliable UDP

SaaS Software-as-a-Service

SAML Security Assertion Markup Language

SAX Simple API for XML

xxi SCTP Stream Control Transmission Protocol

SIEM Security information and event management

SGML Standard Generalized Markup Language

SMTP Simple Mail Transfer Protocol

SNMP Simple Network Management Protocol

SOAP Simple Object Access Protocol

SOCKS Sockets Secure

SORE Single-occurrence regular expression

SOXSD Single-Occurrence XSD

SQL Structured Query Language

SSE Server-Sent Events

SSL Secure Sockets Layer

SSRF Server-side request forgery

StAX Streaming API for XML

STOMP Streaming Text Oriented Messaging Protocol

SVDD Support Vector Data Description

SVM Support Vector Machine

TCP Transmission Control Protocol

TLS Transport Layer Security

UDDI Universal Description, Discovery, and Integration

UDP User Datagram Protocol

UPA Unique Particle Attribution

URI Uniform resource identifier

URL Uniform resource locator

VPA Visibly pushdown automaton

VPL Visibly pushdown language

VPPA Visibly pushdown prefix acceptor

VTD Virtual Token Descriptor

W3C World Wide Web Consortium

xxii WADL Web Application Description Language

WebRTC Web Real-Time Communications

WSDL Web Service Description Language

WS-* Web service standards and specifications

XDR External Data Representation

XML Extensible Markup Language

XMPP Extensible Messaging and Presence Protocol

XOP XML-binary Optimized Packing

XPath XML Path Language

XRDL XML-RPC Description Language

XSD XML Schema

XSLT Extensible Stylesheet Language Transformations

XSRF Cross-site request forgery

XSS Cross-site scripting

XVPA XML visibly pushdown automaton

xxiii xxiv Chapter 1

Introduction

Cloud computing [32] is a paradigm for providing computational resources, e.g., hardware, storage, and software, as an Internet-accessible service to consumers. A pay-by-use business model and a highly automated multi-tenant architecture on the provider side are key characteristics of a cloud, so a client can provision resources on demand from a sheer endless pool. This so-called elasticity enables a client to rapidly deploy services and to scale resource usage. The National Institute of Standards and Technology [256] has defined widely accepted deployment and service delivery models to categorize clouds. Deployment models include private, community, public, and hybrid clouds, and typical service delivery models are Infrastructure-as-a-Service (IaaS), Platform-as-a- Service (PaaS), and Software-as-a-Service (SaaS). Interaction between distributed service providers and consumers needs communication over a computer network, i.e., the Internet, as illustrated in Figure 1.1.A service is an IT resource that is made accessible through an interface by some system in the cloud [166, 336]. A service consumer system on the client side, i.e., a client, is typically operated by a user for accessing a service. Client and service are considered heterogeneous systems that participate in an architecture and exchange messages in an agreed communication protocol. For service-to-service interaction in a composition, a service participates as a client to consume other services. A service can also coordinate two clients for client- to-client or peer-to-peer interaction. On a technological level, cloud computing benefits from well-established web and enterprise service technologies [226]. However, by consuming a cloud service, a client becomes dependent on the service provider. As cloud computing accumulates data on the provider side, clouds and their clients become attractive targets for attackers. In particular, the Cloud Security Alliance [93] has identified nine security threats to cloud computing: data breaches, where

User Message System System Protocol Role: client Role: service Message

Interface Figure 1.1: A client and a service exchange messages over some transport mechanism in an agreed communication protocol for interaction

1 CHAPTER 1. INTRODUCTION an attacker gains access to client data; tampering or loss of data; hijacking of accounts or service communication; insecure application programming interfaces (APIs) for service access, management, and orchestration; Denial of Service; malicious insiders; abuse of cloud services for attacks; insufficient due diligence; and shared technology vulnerabilities in multi-tenant architectures. The increasing need for cloud security coincides with a strong momentum in cloud security research as pointed out by Fernandes et al. [123].

Monitoring and Intrusion Detection One way of raising assurance that security properties such as availability, integrity, and confidentiality are met is monitoring [58, ch. 11]. In particular, intrusion detection is a variant of monitoring for identifying attacks in a computer system or network [378]. An intrusion detection system (IDS) assumes that evidence or symptoms are observable in case of an attack, and detection methods are distinguished into misuse- and anomaly-based methods. A misuse-based IDS monitors for known patterns of “undesirable accesses”, i.e., so-called attack signatures. On the other hand, an anomaly-based IDS assumes that an attack causes anomalies with respect to a reference model of “acceptable usages”, which is derived from a specification or learned from observations. Misuse-based detection identifies known attacks but fails when an attack is unknown (i.e., a zero-day attack). Bilge and Dumitras [55] have studied attacks in malicious software (i.e., malware) in the time between 2008 and 2011, and results indicate that zero-day attacks are more frequent than previously thought. Furthermore, polymorphism and obfuscation can customize attacks for evading signatures [396]. Anomaly detection can, in theory, identify zero-day and obfuscated attacks but learning-based approaches suffer from inherent problems, especially the cost of false alarms. The distribution of normal observations and attacks is unknown and could be heavily skewed; even an anomaly-based IDS with a very low false-alarm rate could still generate an unacceptable number of false alarms [34]. Also, the presence of an anomaly does not always imply an attack, training data for learning-based approaches could be contaminated with zero-day attacks, and the notions of “acceptable usages” and “undesirable accesses” of the system under observation can evolve over time [150, 392].

Language-Based Anomaly Detection in XML This thesis addresses language-centric monitoring of messages received at insecure client or service interfaces. The focus is on the Extensible Markup Language (XML) [451] because it is a platform-independent data serialization format used in many cloud communication protocols, e.g., the Simple Object Access Protocol (SOAP) [8, 447] for traditional web services, the Extensible Messaging and Presence Protocol (XMPP) [186, 369] for message-oriented middleware in clouds, the Security Assertion Markup Lan- guage (SAML) [304] for cloud single sign-on access control, and as a data serialization format in Representational State Transfer (REST) [129, 130] web service architectures. XML is a complex language, and XML-based protocols are susceptible to entire classes of implicit and explicit security problems [202, 227]. XML-based protocols are typically specified in the industry-standard XML Schema (XSD) [443], and like a grammar, a schema characterizes a set of XML documents. Schema validation then checks whether a document is generated by a particular schema. Validation at the client or service interface should be a first line of defense against “undesirable protocol messages”. But XML and XSD suffer from two fundamental problems:

2 1.1. MOTIVATION

• XML is usually treated as a tree-based format, but in many protocols this is not the case because of integrity constraints. For example, ID-based references in a document entail a graph structure, and processing and validating a document correctly become computationally harder.

• Best practices in XSD recommend extension points in schemas for loose composition [400]. But extension points enable an attacker to add arbitrary unchecked content in a document, e.g., for a signature wrapping attack [255].

An XML attack manifests in a document’s structure or in text contents of elements. I propose a language-based anomaly detection approach in terms of an interface-centric security monitor on the client or service side. The contributions are XML language representations for the learner and validator components in the security monitor, algorithms for incremental and set-driven learning of syntactically acceptable messages, and an experimental evaluation of the proposed monitor in four scenarios. For representing sets of documents, XML visibly pushdown automata (XVPAs) [10, 223] are extended toward datatyped XVPAs (dXVPAs) for mixed-content XML, where text content is allowed between subsequent tags in a document. A dXVPA translates into a character-data XVPA (cXVPA) for efficient stream validation. For learning, all text contents in a document are generalized by minimally required datatypes, and datatypes are inferred by a proposed lexical datatype system based on lexical subsumption and a preference heuristic. XML attacks that undermine semantics, i.e., signature wrapping attacks, are highly client or service specific, and “undesirable examples” are considered unavailable for learning. Therefore, as a first step, the assumed learning scenario is learning from positive examples, where an incremental learner infers a dXVPA for characterizing the “acceptable messages” at a particular client or service interface. A dXVPA is then translated to a cXVPA for efficient validation of observed messages in the proposed security monitor. To minimize errors, i.e., false positives and negatives, this language-based anomaly detection approach respects the language properties of XML by inferring a good-enough approximation of the acceptable language. Poisoning attacks in training data are a threat to learning-based approaches. Therefore, operations for unlearning and sanitization are provided. Unlearning removes a once learned example from a dXVPA, e.g., when a poisoning attack is uncovered at a later time, and sanitization trims low-frequent states and transitions from a dXVPA for removing hidden poisoning attacks under the assumption that poisoning attacks are rare. For a proof of concept, the proposed algorithms have been experimentally evaluated in two different settings: a synthetic scenario, where XML is used as a data serialization format, and a simulated scenario, where state-of-the-art attacks are executed on an actual web service which has been solely implemented for testing purposes.

1.1 Motivation

My thesis is motivated by the state of software security. Despite increased efforts in securing systems and program code, software is still vulnerable and new threats arise everyday [91]. The removal and mitigation of exploitable vulnerabilities is a requirement by users.

3 CHAPTER 1. INTRODUCTION

1.1.1 Language-Theoretic Security Language-theoretic security (LangSec) is an attempt to understand the root causes of software insecurity [69, 70, 376]. More specifically, LangSec is a design and programming philosophy that focuses on formally correct and verifiable input handling throughout all phases of the software development process [331]. Special emphasis is given to secure parsing because parsing happens in practically every program that manipulates data, and the majority of attacks exploit weaknesses in input handling [68]. Figure 1.2 shows the LangSec threat model, and the illustrated entities are defined in accordance to Biskup [58, ch. 11]. The crossed-out values denote a traditional view: a computing system executes a program that consumes input data and exhibits behavior in the process. A computing system could be software or hardware, but this is not further specified; it is assumed that the possible states and the possible state transitions abstractly define the computing system. For simplicity, the resulting behavior from consuming a particular input is a sequence of state changes, i.e., a trace.A security policy defines “acceptable usages” and “undesirable accesses” in terms of acceptable and violating behavior, i.e., acceptable and violating traces and states. A successful attack then causes violating behavior.

Program Interpreter Behavior Input Program

Figure 1.2: LangSec threat model

However, this simplified view has shortcomings in reality, e.g., a security policy might be incomplete or flawed, the declaration language for policies usually has limited expressiveness to stay decidable, there could be errors and flaws in the program that introduce unknown states and state transitions, and reasoning about non-trivial properties of the program is undecidable in the general case [58, 70, 68]. LangSec embraces an attacker’s view: a computing system parses input, parsing drives the behavior, and an attacker wants to cause violating behavior. In Figure 1.2, the computing system is therefore considered to be an interpreter, and input data is treated as a program for the interpreter. A so-called exploit is then specially crafted input that leads execution toward an insecure trace or state. Accepting good input and rejecting bad input is a MEMBERSHIP decision problem in the LangSec view, and decidability depends on the input language class. Input languages and compositions thereof, e.g., layered protocol design and character encodings, are in fact the foundation for all communication protocols and data formats today. Unfortunately, ad hoc notions of input validity, ambiguous interpretations of informal protocol specifications, mixing of input recognition and logical processing steps in program code, and ungoverned software development (e.g., by adding new features to protocols) can lead to accidentally Turing-complete input languages in the worst case [68, 331]. The LangSec community argues that these accidental increases in input language expressiveness are the root cause of today’s software vulnerabilities. Deciding MEMBER- SHIP can become intractable or undecidable with increasing accidental expressiveness, and a computer system would not be able to reject an exploit even when a specification of the acceptable inputs is available [69, 376]. The expressiveness of the input language therefore needs to be understood and controlled.

4 1.1. MOTIVATION

Classifications of Inputs The “undesirable accesses” and “acceptable usage” are semantic notions for a computing system and must be properly defined. The following classifications are based on Biskup [58, ch. 11]. A security policy syntactically describes semantically acceptable and violating behaviors of a computing system. But a policy declaration language usually has expressiveness and decidability restrictions, and only a minor fraction of syntactically permitted behaviors can be considered semantically acceptable [58, p. 358]. The LangSec philosophy embraces a syntactic characterization of relevant sets of inputs with respect to semantically acceptable and violating behaviors. Figure 1.3 illustrates the relationships between the relevant sets.

• The possible inputs are all the inputs that can be sent to the computing system.

• The syntactically acceptable inputs are exactly the inputs that result in semantically acceptable behavior when consumed by a computing system.

• Explicitly permitted inputs are syntactically correct inputs with respect to the input language specification in a computing system’s parser. These inputs canbe consumed, and this set strictly contains the acceptable inputs. Explicitly permitted inputs do not necessarily result in semantically acceptable behavior.

• Exploits (attacks) are syntactically violating inputs that cause semantically violating behavior, and a computing system should definitely reject those.

Anomaly detection Misuse detection

Acceptable Violating Explicitly permitted

Possible

Figure 1.3: Relationships of the relevant sets of inputs and their approximations by language-based intrusion detection methods (reproduced from [58, p. 357])

Language-Theoretic Security and Intrusion Detection The LangSec view explains some of the problems encountered in intrusion detection when language-based methods are used. Figure 1.3 also visualizes the relationship between intrusion detection methods and relevant sets of inputs. On the one hand, the violating inputs are usually unknown, and security experts discover exploits over time. On the other hand, the acceptable inputs are often also not exactly known, e.g., when the input language is composed from several protocols or defined ad hoc in program code.

5 CHAPTER 1. INTRODUCTION

An IDS that observes inputs has to classify acceptable and violating inputs efficiently. Algorithms are usually engineered for a tractable language class, and models of acceptable and violating inputs are therefore approximations. While anomaly detection approximates the acceptable inputs from a specification or by learning, misuse detection approximates violating inputs from discovered exploits and generalizations thereof, e.g., in terms of patterns. The consequences of approximation are however false-positive and false- negative detection errors. Two problems emerge in the worst case when the language classes of an IDS and observable inputs are not equally expressive [376]:

• Some exploits could universally evade detection by a misuse-based IDS, e.g., by obfuscation or polymorphism.

• An anomaly-based IDS might not be able to learn the acceptable inputs even after exhaustive training.

Respecting the language class of inputs is therefore a precondition for accurate intrusion detection, but approximations are inevitable in some cases. In this thesis, the focus is on XML because of its role in cloud computing. XML is a text-based format, where well-matched tags syntactically encode a tree of elements, but the semantic data model of a document is not necessarily a tree because of integrity constraints. These constraints are specified in schemas, and they assign special semantics to attributes, elements, and text contents for allowing more expressive data models. However, there is only little syntactic evidence in documents whether an attribute, element, or text content is actually part of an integrity constraint. The focus in this thesis is therefore on the syntactic structure of elements and text contents only. Key mining in XML is a research field on its own [29]. The proposed language-based anomaly detection approach learns a good-enough approximation of the acceptable documents. Language representation by dXVPAs and cXVPAs is beneficial for efficient stream processing in a monitor but fundamentally an approximation because integrity constraints are ignored, and documents are simply treated as well-matched event streams. This approximation is still good enough for identifying the majority of XML attacks:

• An inferred dXVPA is free of extension points, and an attacker cannot place arbitrary elements in a document anymore.

• When a document syntactically differs from acceptable training examples, e.g., because of violating element structures and text contents, it is rejected.

1.1.2 XML Attacks and Schema Validation XML provides several schema languages, e.g., Document Type Definition (DTD) [451], XSD [443], and Relax NG [292], to specify sets of documents. A schema is like a grammar and defines a language, and a document is valid if all schema production rules are satisfied. Schema validation is therefore a first line of defense against document structures and text contents that are not explicitly permitted. However, there are two observations that motivate a learning-based approach. First, RESTful web services are popular for SaaS implementations, but they do not enforce the presence of a schema nor validation of an XML-based resource. The input language is eventually defined ad hoc in the program code. Second, extension points in XSD

6 1.1. MOTIVATION are in fact wildcards, and they are found in practically all protocol specifications today, e.g., SOAP, XMPP, and SAML. When extension points are present, schema validation is rendered ineffective as an attack countermeasure because an element at an extension point is just skipped. Various parsing and semantic XML attacks can therefore be placed while the document stays explicitly permitted. Moreover, checking integrity constraints is costly because they change the data model of a document. In particular, sequential and cyclic references can turn the data model into an infinite tree, and checks and operations become computationally harder [489]. The XML signature wrapping attack [255] is a consequence of these problems. XML Signature [453] specifies a cryptographic signature for the text representations of oneor more elements in a document. A signature is stored in its designated element, and as shown in Figure 1.4a, a reference points to the signed part. The vulnerability is basically a discrepancy between the cryptographic verification and the business logic in the receiving system. Figure 1.4b illustrates an example of an attacker’s message. As a prerequisite, the attacker needs to have access to a message already signed by another user, e.g., from network sniffing and crawling cloud service provider support forums[393].

soap:Envelope soap:Header wsse:Security soap:Envelope ds:Signature soap:Header ds:SignedInfo wsse:Security ds:Reference ds:Signature Wrapper @URI #123 ds:SignedInfo soap:Body ds:Reference @wsu:Id 123 @URI #123

verified MonitorInstances soap:Body soap:Body @wsu:Id 123 @wsu:Id attack MonitorInstances CreateKeyPair verified, processed processed (a) Original XML message (b) Modified XML message

Figure 1.4: Classical XML signature wrapping attack [393]

For the attack, the signed element is moved into a wrapper element at an extension point to evade schema validation, e.g., the Wrapper element in the figure, and the attacker places a violating element at the original position instead. Due to the discrepancy in the service’s implementation, the cryptographic verification succeeds, but the business logic interprets the violating element. Nonetheless, the originally signed element must remain in the document and causes anomalous structure. Somorovsky et al. [394] have demonstrated a signature wrapping attack on SAML. In SAML, an identity provider signs a client’s authentication and authorization claims, and a successful attacker is able to impersonate other users or issue arbitrary claims. The majority of publicly available SAML implementations were vulnerable because of the extension points in the SAML schema. Jensen et al. [204] show that schema validation can be an effective defense against signature wrapping attacks but requires a hardened schema without extension points. All schemas in a service must be known beforehand, so they can be unified into a single schema that represents the acceptable documents. The unification process is however

7 CHAPTER 1. INTRODUCTION computationally hard because of combinatorial effects from embedding schemas at extension points, and restrictions are needed. Also, the large size of a hardened schema imposes a penalty on validation performance in the experiments [204]. The proposed learning-based approach circumvents the problems encountered in schema hardening by inferring a language representation of acceptable documents directly from examples.

1.2 Objectives

Objective 1. The first objective is to review the state-of-the-art in today’s technological landscape for client-cloud interaction and to understand the interplay between languages, protocols, architectures, and service interaction patterns in cloud service integration. This knowledge is the foundation for understanding today’s attack surfaces, and a result of this objective is the importance of XML and XML-based protocols in cloud computing.

Objective 2. Monitoring of a computing system is an approach to gain insight about correctness in execution and security. Language-based anomaly detection must be capable of monitoring the exchanged messages in an interaction. To understand the technical feasibility, the second objective is therefore to review the state-of- the-art in client-cloud interaction monitoring and, most importantly, to identify the available observation points and their limitations.

Objective 3. The third objective has three sub-objectives. First, the state-of-the-art in anomaly-based intrusion detection needs to be studied to understand the existing methods and their limitations. Second, the proposed approach focuses on XML as a result of Objective 1, and XML attacks therefore need to be reviewed. Third, it should be clear what countermeasures are currently available for protecting against XML attacks. A particular result of this objective is that stream validation without extension points can mitigate several XML attacks, and XVPAs are a suitable foundation for representing the acceptable inputs in terms of document event streams.

Objective 4. Specifying the proposed security monitor and its components, including the necessary language representations and algorithms, is the fourth objective. First, XVPAs need to be extended for text contents in mixed-content XML because text contents are not modeled in XVPAs. Second, text contents can be from an arbitrary language class and affect the learning process. A generalization of text contents is therefore necessary. Third, algorithms for learning from positive examples have to be specified. Fourth, the learner has to operate in a potentially adversarial environment, where an attacker might be able to poison the training data. Additional mechanisms for dealing with poisoning attacks are therefore necessary. The results of this objective is an incremental and set-driven learner and operations for unlearning and sanitization in case of poisoning attacks.

Objective 5. A learned automaton from XML documents is a heuristic, and the fifth objective is to deliver a proof of concept. First, the algorithms for the proposed security monitor need to be implemented. Second, appropriate experiments need

8 1.3. OUTLINE

to be defined. This includes test cases, where the state-of-the-art XML attacks are simulated, and effectiveness of the monitor can be measured.

1.3 Outline

This thesis is structured as follows. Chapter2 investigates the background by summa- rizing the state-of-the-art technologies for client-cloud interaction, the motivation for client-cloud interaction monitoring, and available observation points for implementing a monitoring solution (Objective 1 and 2). The literature review in Chapter3 surveys intrusion detection and, in particular, anomaly-based intrusion detection as security monitoring strategies. Kernel methods in machine learning are considered the state-of-the-art for anomaly detection in tree- structured data and are therefore explained in greater detail. Furthermore, XML and XML attacks are discussed, and related work on stream validation and schema inference is presented (Objective 3). The approach towards language-based anomaly detection in XML is introduced in Chapter4 by proposing a security monitor architecture and its components, defining an attacker model, stating the domain-specific problems, introducing the methodology with respect to grammatical inference, and discussing use cases for a learning-based security monitor (Objective 4). Chapter5 is the main contribution, in particular, the definition of dXVPAs and cXVPAs as extensions of XVPAs for validating mixed-content XML. Text content is generalized by minimally required datatypes, and an incremental and set-driven learner for inferring a reference model of acceptable inputs in terms of a dXVPA is specified. For dealing with poisoning attacks during the learning process, operations for unlearning and sanitization are proposed (Objective 4). The learner and validator components of the proposed security monitor are experimentally evaluated in Chapter6 for a proof of concept. Remarks on the implementation are given, and measures for effectivity are defined. The implementation has been evaluated in two synthetic and two simulated scenarios, where state-of-the-art XML attacks were executed, and results are presented (Objective 5). Chapter7 concludes this thesis by elaborating on the experimental evaluation results. The treatment of the objectives is summarized, and for completeness, all assumptions, restrictions, and design choices in the proposed approach are recalled. The chapter closes by stating open research questions for future research opportunities. The reader should be familiar with the fundamentals in computer security [58] and basic concepts in formal language theory [216], in particular, regular languages, regular expressions, and deterministic finite automata (DFAs).

1.4 Contributions

The main contributions in this thesis are: 1. the dXVPA and cXVPA language representations for mixed-content XML and efficient stream validation

2. a lexical datatype system for inferring a set of minimally required datatypes from text content based on lexical subsumption and a preference heuristic

9 CHAPTER 1. INTRODUCTION

3. an incremental and set-driven learner with unlearning and sanitization capabilities for inferring a dXVPA from example documents

The learner and validator components of the proposed security monitor have been implemented and experimentally evaluated. The proof of concept evaluation uses four generated datasets representing two synthetic and two simulated scenarios. While the synthetic scenarios were generated using the ToXGene tool [35], the simulated datasets were collected from a SOAP/WS-* web service called VulnShopService which was also implemented in the course of this thesis. State-of-the-art attacks were generated manually and automatically by the WS-Attacker [253] tool. The proposed approach was able to achieve promising results on all four datasets compared to the baseline performance of traditional schema validation. Only few examples were needed for the learner to converge to a stable dXVPA representation, and attack detection rates were between 82.35% and 100% without false positives in all experiments.

Publications. All the main results and contributions presented in this thesis have been published or are accepted at the time of writing:

• Lampesberger, H.: An incremental learner for language-based anomaly detection XML. In: 2016 IEEE Symposium on Security and Privacy Workshops, LangSec’16. IEEE (2016). (To appear)

• Lampesberger, H., Rady, M.: Monitoring of client-cloud interaction. In: Correct Software in Web Applications and Web Services, Texts & Monographs in Symbolic Computation, pp. 177–228. Springer International Publishing (2015)

• Lampesberger, H.: Technologies for web and cloud service interaction: A survey. Service Oriented Computing and Applications (2015). DOI: 10.1007/s11761-015- 0174-1

• Lampesberger, H.: A grammatical inference approach to language-based anomaly detection in XML. In: 2013 International Conference on Availability, Reliability and Security, ECTCM’13 Workshop, pp. 685–693. IEEE (2013)

10 Chapter 2

Background: Interaction and Monitoring

Cloud clients and services operate in different jurisdictions, and both parties need to communicate for interaction. Monitoring of observable input-output behavior is a well-known approach in computer security, e.g., network firewalls, and the LangSec threat model regards the language for communication as a major origin of vulnerabilities. However, today’s cloud computing is more of a paradigm than a defined set of technologies, and a wide range of languages and compositions thereof are available for integration. This chapter provides a detailed review of technologies that enable client-cloud interaction and investigates how interaction can be monitored. Section 2.1–2.5 summarize standardized languages, conceptual service interaction patterns, communication protocols, and interaction architectures for clouds respectively. The presented study indicates that XML is a foundation for data serialization and communication protocols, and monitoring of XML is therefore a viable approach under the LangSec threat model. Section 2.6 then analyzes the goals and limitations in client-cloud interaction monitoring, and technically feasible observation points are reviewed. Sec- tion 2.7 closes the chapter by drawing conclusions from technical trends, in particular, pervasive encryption and multihoming render traditional network security tools, e.g., IP firewalls, incapable of observing interaction. A future-proof monitor therefore needsto operate as a client or service component or in a middleware.

2.1 Client-Cloud Interaction

Figure 2.1 highlights the identified relationships between languages, service interaction patterns, protocols, architectures, and implementations. A language is essential for encoding information in a transportable format and defines an alphabet, syntax, and

Service interaction pattern

Protocol Architecture

Language Implementation

Figure 2.1: Concepts and relationships identified in communication technologies [226]

11 CHAPTER 2. BACKGROUND: INTERACTION AND MONITORING semantics. Structured data or multimedia content is represented as a message or sequence of messages in a particular language, and standards for cloud computing are covered in Section 2.2. In literature, interaction of services is primarily discussed in terms of patterns [1, 38, 37, 184, 496]; however, today’s implementations in clients and clouds often resort to ad hoc specifications, and standardization efforts are usually community-driven. Section 2.3 recalls the conceptual service interaction patterns by Barros et al. [38, 37] as a taxonomy for further discussions on protocols and architectures in later sections. For a message transport mechanism, a communication protocol defines the rules of engagement, i.e., low-level interaction patterns, for a language. A protocol can also integrate other protocols into a so-called protocol stack to achieve sophisticated transport mechanisms, e.g., order and delivery guarantees. Section 2.4 reviews communication protocols that are currently in use for cloud computing. An architecture for client-cloud interaction then specifies supported transport mechanisms, languages for message formats, and high-level interaction patterns for message exchange. An architecture is in a sense a blueprint for service delivery and implemented in software by consumers and providers. Section 2.5 investigates popular architectures for cloud integration.

2.1.1 Historical Context From a historical point of view, the evolution of the web and enterprise services converges in today’s technologies for client-cloud interaction. Enterprise architectures to access and share network-based resources and use remote functionality in a program go back to the 1970s [484]. In the 1980s, the remote procedure call (RPC) framework by Birrell and Nelson [57] introduces location transparency for network-accessible procedures, where a shared type system couples programs tightly. Object orientation and RPC have led to distributed objects [310] in the 1990s that still need tight coupling, and scalability suffers from communication complexity. Message passing between loosely- coupled services became popular at the end of the 1990s as a more scalable enterprise architecture which ultimately led to today’s message-oriented middleware and service- oriented architecture (SOA) [303]. In the meantime, the foundation for a World Wide Web of interlinked nonlinear text, i.e., hypertext, was established by Berners-Lee [468] in 1989, and in 1997, the first Hypertext Markup Language (HTML) recommendation was announced. The web has evolved since then from simple hypertext exchange towards rich client applications, user-provided content, web mashups, and social platforms [120]. In the last decade, web applications have begun to integrate enterprise service paradigms and, on the other hand, the Hypertext Transfer Protocol (HTTP) and web paradigms have literally been abused for creating enterprise services that are Internet and web compatible [72, 336]. Today, cloud computing integrates technologies from both enterprise services and the web to deliver a service across heterogeneous devices and platforms using widely accepted protocols and formats [32]. However, the definition of the term “service” varies in literature [380]. In this thesis, a service is therefore considered as a distributed, network- accessible software component that offers functionality by communicating messages at a specified service interface. The involved peers or parties in client-to-service interaction are a consumer (client) that accesses a service offered by a service provider. For service- to-service interaction, a service adopts the role of a client to access another service. In

12 2.2. LANGUAGES FOR CONTENT AND MEDIA client-to-client interaction, a third-party service typically coordinates two clients, so they can engage directly. However, some control needs to be handed to the service in this case which leads to integration difficulties.

2.2 Languages for Content and Media

An alphabet is a finite set of symbols, and a language is usually an infinite set of strings over an alphabet [185]. Languages for encoding content or media in information exchange are typically referred to as data serialization format, and communicating peers can parse a message if the language’s syntax is well defined. The expressiveness of a language affects the computational complexity of parsing, and with increasing complexity, software implementations become more vulnerable [376]. Digital systems rely on a binary alphabet, and bytes are a common unit of data in computing and Internet applications. Based on the interpretation of bits and bytes, content can be distinguished into text-based and binary. While binary content is a machine- readable representation of information, text-based content is human readable by applying a character encoding to map bits and bytes into human-readable symbols. Popular character encodings are the seven-bit ASCII (American Standard Code for Information Interchange), which is restricted to English text, and ASCII-compatible UTF-8 [494], which encodes human-readable symbols in Unicode [421]. A type is a general concept shared by a set of objects [226]. A content type has a unique identifier and specifies the alphabet, eventually some character encoding, the syntax, and semantics for a language. Content types enable modular software, where an appropriate parsing component for some content is chosen during runtime, e.g., a web browser selects a proper module for data returned by a web server based on the data’s content type. Today, the Multipurpose Internet Mail Extensions (MIME) [137] standardize the notion of a MIME content type in Internet applications, i.e., Internet media type, and an example for UTF-8 encoded text is the MIME type text/plain; charset=utf-8.

2.2.1 Data Serialization Formats The most notable examples for text-based semi-structured languages are HTML, XML, and JavaScript Object Notation (JSON). An HTML document encodes a website, has MIME type text/html, and up to version 4.01 [431], HTML it is an application of the Standard Generalized Markup Language (SGML), which requires a complex parser. Versions are distinguished in a document’s preamble, and today’s HTML5 [471] is an unambiguous syntactic specification, independent from SGML. A web browser parses an HTML document into a Document Object Model (DOM) [438]. XML [451] uses well-matched tags to serialize structured information and is considered the lingua franca of electronic data exchange. A schema, expressed in some schema language, is like a grammar and characterizes a set of document by restricting document structure and eventually text contents. Examples for schema languages are DTD [451], XSD [443], and Relax NG [292]. Extended DTD (EDTD) [328] is a conceptual schema language primarily used in theoretical work. As argued in this chapter, XML is a core technology for client-cloud interaction and also the center of this thesis. The language properties are therefore discussed in greater detail in Section 3.2. Unrestricted XML has MIME type application/xml, and well-known subtypes are specified by schemas, e.g.,

13 CHAPTER 2. BACKGROUND: INTERACTION AND MONITORING the re-specification of HTML as XHTMLapplication/xhtml+xml ( ) and Scalable Vector Graphics (image/svg+xml). JSON [71] is a text-based key-value data interchange format, popular for web applications, and the MIME type is application/json. The syntax of JSON is a valid JavaScript program that evaluates to an object in a JavaScript runtime environment. Other text-based data serialization formats are markup languages Candle [79] and YAML [42], the Open Data Description Language [236], the Ordered Graph Data Language [424] for serializing data graphs, and comma-separated values for relational data. Base16, Base32, Base64 [205], percent-encoding [45], and quoted-printable encoding [136] are so-called binary-to-text encoding schemes to translate a binary value, i.e., a bit string, into a string of printable ASCII characters. Base64 is especially popular for embedding binary content in text-based data serialization formats such as XML or JSON. Binary formats are intended for machine readability and typically not human readable, e.g., video and audio formats. A well-known standard for specifying information structure and encoding rules is Abstract Syntax Notation One (ASN.1) [115], e.g., for encoding of X.509 certificates in a public key infrastructure352 [ ]. Furthermore, several binary encoding schemes for text-based JSON have been proposed for optimized processing, e.g., Binary JSON [77], Concise Binary Object Representation [65], and MessagePack [141]. Binary formats are often found in RPC architectures for call and argument serialization, e.g., Apache Avro [25], Etch [23], and Thrift [22]; External Data Representation (XDR) [268]; Protocol Buffers [157]; and Hessian [81].

2.2.2 Container Formats

Conceptually, a container integrates arbitrary contents of varying content types into a single object or message. A popular container format is the MIME multipart content type [137]. A multipart message has a text-based header that defines a boundary string to separate the message into parts. Every part has an individual header that specifies its local content type and additional metadata. Examples of multipart content types are multipart/message for emails with attachments and S/MIME [350] multipart/encrypted and multipart/signed for encrypting or signing content. MIME multipart has a limitation: The format of a container is only consistent if the boundary string does not appear in any part of the container. Another container format, similar to MIME multipart but with improved boundaries, is Microsoft’s Direct Internet Message Encapsulation (DIME) [263].

2.3 Service Interaction Patterns

A content type specifies a message format, so clients and services can understand communicated messages. This section recalls service interaction patterns, as introduced by Barros et al. [37, 38], to characterize how messages are conceptually exchanged between communicating parties. Figure 2.2 summarizes the service interaction patterns that have been defined based on three dimensions: number of participants, number of message exchanges, and whether third parties are involved. Consequently, there are four groups: single-transmission bilateral and multilateral patterns, multi-transmission patterns, and routing patterns. In this section, A, B, C, etc. are considered to be communicating parties.

14 2.3. SERVICE INTERACTION PATTERNS

Send Single-transmission Receive bilateral Send-receive Racing incoming messages Single-transmission One-to-many send Service multilateral One-from-many receive interaction One-to-many send-receive patterns Multi-responses Multi-transmission Contingent requests Atomic multicast notification Request with referral Routing pattern Relayed request Dynamic routing

Figure 2.2: Service interaction patterns for messaging between parties [37, 38]

2.3.1 Single-Transmission Bilateral Patterns Send. A sends a message to B. Related to: unicast, point-to-point send.

Receive. A waits for a message. Related to: listener, event handler.

Send-receive. A sends a message to B, and B sends a response message to A. The dual of this pattern is receive-send, where A responds to incoming messages. Related to: RPC, request-reply, request-response.

2.3.2 Single-Transmission Multilateral Patterns Racing incoming messages. A waits for the first message from a number of potential senders and messages. After receiving the message, A reacts according to the message type or sender, and later arriving messages are eventually ignored. Related to: deferred choice.

One-to-many send. A sends n messages of the same type to B1 ...Bn; however, message contents are not necessarily the same. Related to: multicast, broadcast, publish- subscribe, fan-out, event notification, scatter.

One-from-many receive. A awaits messages from B1 ...Bn for a certain time span, so messages are logically linked together. Related to: gather, fan-in, event aggregation.

One-to-many send-receive. A sends n request messages to B1 ...Bn and awaits n responses for a certain time span. The dual of this pattern is one-from-many receive- send, where A awaits n requests from B1 ...Bn for a certain time span and returns n responses after processing. Related to: scatter-gather.

2.3.3 Multi-Transmission Patterns Multi-responses. A sends a request to B, and B returns responses until some stop- condition is met, e.g., explicit stop request from A, temporal conditions, inactivity, or explicit end notification by B. Related to: streamed responses, message stream.

15 CHAPTER 2. BACKGROUND: INTERACTION AND MONITORING

Contingent requests. A sends a request to B1, and if there is no response in time, the request is resent to B2, and so on. A continues until some Bi returns a response. Related to: send with failover.

Atomic multicast notification. A sends notifications to B1 ...Bn. At least i and at most j recipients are required to accept. When i = j = n, all recipients are expected to accept. Related to: transactional notification.

2.3.4 Routing Patterns Request with referral. A sends a request to B, and based on certain conditions, e.g., message content, responses are forwarded to C or C1 ...Cn. Related to: reply to.

Relayed request. A sends a request to B, and B forwards it to C1 ...Cn, who then respond to A. B observes the interaction between A and C1 ...Cn. Related to: delegation.

Dynamic routing. Routing conditions define how a message is forwarded by aparty, and conditions can be content-dependent and change over time. A message from A is eventually forwarded to B1 ...Bn based on the conditions. B1 ...Bn eventually forward the message to C1 ...Cm, and so on. Related to: routing slip, content-based routing.

2.4 Protocols for Computer Networks

Layered communication protocols for computer networks are an industry standard for delegating communication complexity, and reference models are the OSI model [499] and the simplified Internet model [67]. A transport mechanism for messages is a protocol stack, so the required properties like reliable transport or acknowledgments are satisfied. The state-of-the-art communication protocols used for transport mechanisms in today’s client-cloud interaction are summarized in Figure 2.3. While link layer protocols specify how connected devices can physically transmit information, e.g., Ethernet or Wi-fi networking, the Internet layer considers communication beyond physical boundaries by logical addressing of hosts and packet-based routing.

Content & Media Data Serialization WebRTC CoAP MQTT WebSocket RTPS AMQP Application SPDY SMTP STOMP DNS HTTP FTP XMPP Transport Optional security: SSL, TLS, DTLS Internet MPTCP QUIC UDP Lite DCCP Link TCP SCTP UDP RUDP IP, IPv6

Figure 2.3: The Internet model [67] and client-cloud communication protocols

16 2.4. PROTOCOLS FOR COMPUTER NETWORKS

Today’s Internet Protocol (IP) [343] and its successor IP Version 6 (IPv6) [110] constitute the backbone of the Internet. Both protocols specify dynamic routing of packets for bilateral packet exchange between hosts identified by logical IP addresses. Every packet has a header that stores the sender and destination address, similar to an envelope, and a byte-oriented payload. Packets are forwarded to their destination or discarded when the destination is unreachable—there are no delivery guarantees. Also, if a packet is too large for a single link layer frame, the packet is either fragmented or discarded. For one-to-many send interaction, multiple destinations can be addressed by broadcast and multicast in IP or multicast in IPv6. However, multicast is typically disabled in clouds because of an increased load on the provider’s network infrastructure [272].

2.4.1 Transport Layer Protocols Transport layer protocols enable payload-neutral inter-process communication. Char- acteristics to distinguish protocols are: uni- or bidirectional communication, stateful or stateless connection, message- or stream-oriented exchange, ordering guarantees, reliable delivery, data integrity, and congestion control. The Transmission Control Protocol (TCP) [344] and User Datagram Protocol (UDP) [342] are the most prominent transport protocols today and available in all modern operating systems. To enhance mobile and web experience when consuming a cloud service, other protocols such as MultiPath TCP (MPTCP) [132], the Stream Control Transmission Protocol (SCTP) [401], and Google’s Quick UDP Internet Connections (QUIC) [363] have been proposed.

Transmission Control Protocol. TCP establishes a bidirectional, stateful connection between two endpoints, i.e., processes, and information is bidirectionally exchanged in byte streams [344]. For compatibility with packet-based transmission, TCP transfers byte-stream segments with a distinguished header. To identify the endpoints, the header refers to a source and destination port number. The protocol synchronizes the connection in a three-way handshake during establishment and guarantees integrity and order for both streams using acknowledgments, retransmissions, and checksums. Furthermore, TCP supports flow control to adapt segment sizes in case of path congestion. TCPisa client-server protocol, i.e., a server waits for an incoming connection, and the connection can be terminated by both. In terms of interaction patterns, an established TCP connection supports bilateral send and receive interaction. To minimize handshake delay, the TCP Fast Open [86] extension introduces faster synchronization between familiar endpoints.

Multipath TCP. MPTCP is another TCP extension to introduce multihoming, i.e., the simultaneous presence of a host in multiple physical networks [132]. An MPTCP connection behaves similar to a TCP connection but actually aggregates multiple TCP connections over all available links, so the connection stays available even if one of the links is disrupted. In terms of interaction patterns, MPTCP is identical to TCP.

User Datagram Protocol. UDP is a minimalistic transport protocol with little over- head and stateless interaction [342]. An endpoint sends a byte-oriented message, i.e., a datagram, to another endpoint without delivery guarantees or ordering when multiple messages are sent. Similar to TCP, endpoints are referenced by a source and destination port, and a datagram checksum guarantees integrity. However, UDP does not specify retransmission in case of an incorrect checksum. In terms of patterns, UDP supports

17 CHAPTER 2. BACKGROUND: INTERACTION AND MONITORING bilateral send and receive and one-to-many send by resorting to IP broadcast or multicast. There exist several UDP-inspired protocols that distinguish in their features, but no applications in the web or cloud environments were found. Examples are the unreliable Datagram Congestion Control Protocol (DCCP) [214] that provides congestion control, relaxed checksum calculation in UDP Lite [232], and Reliable UDP (RUDP) [66] supporting retransmissions, acknowledgments, and flow control.

Stream Control Transmission Protocol. SCTP has been designed as an alternative to TCP [401]. SCTP establishes a stateful association between two endpoints in a four-way handshake to eliminate the security threat of TCP SYN flooding118 [ ]. As in UDP and TCP, endpoints are identified by a source and destination port number. The protocol supports multihoming and multiplexing, i.e., the simultaneous transmission of byte- oriented messages within an association. For reliability, SCTP provides checksums, ordering and delivery guarantees for messages are optional, and congestion control is supported. In terms of interaction patterns, an established SCTP association supports bilateral send and receive interaction. However, transportation of SCTP over the Internet is not guaranteed because of its limited support in networking devices, also referred to as middleboxes.

Quick UDP Internet Connections. The experimental QUIC protocol by Google is an attempt to reduce latency and redundant transmissions in web environments [363]. QUIC operates on top of UDP for Internet compatibility, establishes a stateful connection for bilateral send and receive between two endpoints, and integrates the multiplexing concept from SCTP for simultaneous transmissions within a connection. The protocol also minimizes synchronization delays between familiar hosts like TCP Fast Open. QUIC features transparent data compression, checksums, forward error correction using an error-correcting code, retransmissions, and congestion control.

Transport Security Transport layer protocols transmit byte-oriented messages or streams and are therefore payload neutral. There are several standards that extend this payload neutrality to provide application-independent secure sessions for confidentiality, integrity, and authenticity. The two most prominent standards that operate on top of TCP are the Secure Sockets Layer (SSL) [138] and its successor Transport Layer Security (TLS) [113]. Both protocols provide bidirectional byte-oriented streams on top of TCP. An SSL or TLS handshake to establish a secured session typically follows after the TCP handshake. TLS explicitly supports an application-triggered handshake to upgrade an already established TCP connection at a later time [352]. SSL and TLS require the ordering and delivery guarantees of TCP or the handshake will fail. In case of MPTCP, TLS sessions can be established for the individual TCP connections in the aggregated MPTCP connection [379]. However, for multiplexed protocols, like SCTP and QUIC, TLS is not a good op- tion. When simultaneous interactions are multiplexed over a single TLS session, a single incorrect byte would stall all parallel interactions. Furthermore, SCTP supports partial reliability which conflicts with the reliability requirements of TLS. Datagram TLS (DTLS) [353] is an alternative secure session protocol on top of UDP, and it has been specified for other transport protocols, e.g., DTLS over DCCP [339] and DTLS for

18 2.4. PROTOCOLS FOR COMPUTER NETWORKS

SCTP [419]. The individual cryptography protocol in Google’s QUIC is motivated by TLS and active by default, so an interaction cannot be modified by middleboxes [231].

2.4.2 Application Layer Protocols Application layer protocols specify inter-process communication on top of transport protocols. Informally, these protocols can be distinguished by: transport layer requirements, the use of a text-based or binary protocol syntax, stateful or stateless interaction, and whether data and control are transferred in the same or separated channels. For example, the File Transfer Protocol (FTP) [345] and the Simple Mail Transfer Protocol (SMTP) [211] are two popular protocols that are stateful and support TLS. While FTP separates binary data and text-based control into two TCP connections, SMTP interleaves the text-based commands and the email message in a single TCP connection. As transport protocols are payload neutral, an out-of-band agreement on the application protocol is necessary. One approach is to assign default application protocols to listening server ports. The Internet Assigned Numbers Authority (IANA) [192] therefore maintains a public list of port assignments, e.g., port 25/TCP is the default listening port for SMTP.

Domain Name System One of the core Internet protocols is the Domain Name System (DNS) [275], a distributed database for assigning human-readable names to numerical IP addresses. A fully-qualified domain name (FQDN) is the hierarchical name of a host, and this abstraction is used by the majority of Internet clients and services to locate endpoints and even for dynamic service discovery [87]. The DNS protocol for querying the distributed database is a stateless send-receive binary protocol. DNS operates on top of UDP for minimal latency but also supports TCP for large queries or DNS transactions. To assure correctness and authenticity of queries and responses, DNSSEC [30] introduces cryptographic methods. While DNS locates hosts in a network, a uniform resource identifier (URI) [45] identifies some resource as human-readable string. A uniform resource locator (URL) is a special type of URI that also locates a resource, and an example is illustrated in Figure 2.4. The application protocol for accessing the resource is defined by its URI scheme, and the transport protocols and ports for schemes are maintained in an IANA database. The authority part locates the host of a resource either by IP address or FQDN, and the path identifies the actual resource. Alternating port information or user credentials canalsobe embedded in the authority part. Authority and path represent the location of a resource, and a URL can additionally contain an optional query part and fragment to address a location within the resource. The so-called origin of a URL is the triple of its scheme, FQDN or IP address, and port [40].

Hierarchical part (location) http://www.ex.com/dir/fotos.php?action=view#page2 Scheme Authority Path (identity) Query Fragment

Figure 2.4: An URL identifies and locates a resource

19 CHAPTER 2. BACKGROUND: INTERACTION AND MONITORING

The Hypertext Transfer Protocol

HTTP is another core Internet protocol. It is text-based, stateless, and originally intended for bilateral send-receive interaction over TCP. Both data and control are interleaved in the same connection, and HTTP specifies message formats for requests and responses using delimiters, a header, and an optional body. Today’s version HTTP/1.1 [127] supports eight methods: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, and CONNECT. The header of a request states the method, a URI path of a resource, protocol version, additional headers, and eventually a body. A service returns a response, where the header states a status code, and the requested resource is attached as body if available. The MIME content type of a body is declared in a dedicated header field. HTTP/1.1 adds various features to the original specification, e.g., the Upgrade header to request an application protocol switch after a send-receive cycle, persistent connections and request pipelining for minimizing delays, Content-Encoding and Transfer-Encoding for body compression, and ETag and conditional GET for caching mechanisms. Furthermore, HTTP/1.1 adds support for client- or service-driven content negotiation [128]. A client can announce its User-Agent, accepted content types, character and content encodings, and accepted languages in a request header, so the service can return a suitable representation. On the other hand, a service can return a multiple- choices status when multiple resource representations are available. Also, HTTP/1.1 adds cookie support for stateful HTTP sessions, i.e., a string identifier in request headers for application state tracking [39]. HTTP Secure (HTTPS) [351] is the default for SSL/TLS protected HTTP interaction and has its own URI scheme (https:). To prevent clients from accessing resources over insecure connections, HTTP Strict Transport Security [181] specifies a policy exchange to notify clients about HTTPS-only access.

Push Technology. Send-receive interaction in HTTP can only be initiated by the client. Push technology [7] refers to techniques that enable asynchronous send and receive interaction without breaking the HTTP specification, e.g., a service can push an event to the client. First attempts have been client-side long polling, where the requests hangs and the service delays its response until an event or timeout occurs. By exploiting an HTTP/1.1 persistent connection, Comet [366] (HTTP Streaming, HTTP server push) immediately responds with a multipart/x-mixed-replace container and gradually returns container parts as events. In terms of patterns, Comet is a multi-responses pattern. An approach using the Upgrade header, called Reverse HTTP [147], switches the roles of client and service after an initial send-receive cycle; the original service can then initiate interaction by sending HTTP requests, i.e., client-side receive-send interaction. Bidirectional streams over synchronous HTTP (BOSH) [330] establishes two TCP connections between client and service; the client uses the first connection for outgoing requests, and a hanging request in the second connection waits for asynchronous service responses. The state-of-the-art of push technologies are server-sent events (SSE) [461] and Web- Socket [462]. SSE is similar to Comet; a response of MIME type text/event-stream gradually delivers events as byte chunks, i.e., a multi-responses pattern, and the client reconnects automatically in case of a timeout. WebSocket uses the Upgrade header to establish a bidirectional byte-oriented connection that has similar properties like TCP. WebSocket supports TLS, it provides two URI schemes for unencrypted and encrypted connections (ws:, wss:), and in terms of patterns, an established WebSocket connection

20 2.4. PROTOCOLS FOR COMPUTER NETWORKS supports bilateral send and receive. However, an explicit application protocol within a WebSocket session needs to be negotiated during the HTTP Upgrade phase using designated HTTP headers.

HTTP Performance. A website concurrently requests multiple resources, but the number of simultaneous TCP connections to a HTTP server are restricted, and persistent connections or pipelining are still sequential; the performance is therefore limited. Do- main sharding [397] is a workaround for the connection limit by distributing resources across different authorities to increase the maximum number of parallel connections. HTTP-NG [429], structured stream transport [133], HTTP over SCTP [283], and SMUX [430] are experimental standards that propose multiplexed resource access in a single connection to overcome the parallel connection limit. However, none of the experimental standards has reached practical relevance. Google SPDY [409] is the state-of-the-art for improving HTTP performance. SPDY introduces multiplexed resource access, prioritization, service-initiated push of related resources, and transparent content and header compression. SPDY is an augmentation for HTTP; it changes the HTTP wire format, but the semantics stay the same. In terms of patterns, SPDY enables send-receive and multi-responses interaction. An encrypted TLS session is mandatory, and SPDY support is negotiated between client and service during the TLS handshake using TLS Next Protocol Negotiation (NPN). Furthermore, the transport protocol QUIC was specifically designed for SPDY to minimize delays. The upcoming HTTP/2 standard will integrate WebSocket and concepts from SPDY as two core technologies [327]. However, the negotiation part will be replaced with TLS Application Layer Protocol Negotiation (APLN) in the final draft [41].

Web Client-to-Client Communication The increasingly popular client-side web browser extension for web real-time communications (WebRTC) [467] enables direct client-to-client bidirectional send and receive interaction. However, for discovery, signaling between clients, and dealing with firewalls, a third-party service is still required. Motivated by video and audio streaming, WebRTC is DTLS based and also allows data exchange over an RTCDataChannel. This channel is in fact an SCTP over DTLS association and features optional ordering and message delivery guarantees. The clients still need to agree on an application protocol because an RTCDataChannel is payload neutral.

Messaging Protocols As message-oriented middleware receives an increased interest in cloud services, the messaging solutions also bring their proprietary and standardized application protocols into the cloud. For example, Microsoft Message Queuing (MSMQ) [265] has proprietary wire formats for interaction over UDP and TCP. The MSMQ Version 3.0 also supports message exchange over HTTP or HTTPS, and IP multicast for addressing multiple recipients. Proprietary messaging solutions are provided by TIBCO, e.g., XML-based formats over TCP or WebSockets in the enterprise message service [415] or proprietary formats over UDP and IP multicast in Rendezvous services [416]. Other implementation- specific wire formats found in messaging solutions arethe OpenMQ binary wire format in Java Glassfish154 [ ], the binary format OpenWire [20] for Apache ActiveMQ [19],

21 CHAPTER 2. BACKGROUND: INTERACTION AND MONITORING the binary format in TCP-based Apache Kafka [27], and the binary frame format for the intelligent socket library ZeroMQ [190]. With respect to open messaging standards, the Advanced Message Queuing Proto- col (AMQP) [302] is the most prominent open standard for messaging. The AMQP transport model specifies a multiplexed binary protocol over TCP or SCTP that supports message flow control, authentication, and TLS encryption. AMQP provides a self-contained datatype system to interconnect heterogeneous platforms, and peers exchange so-called frames within an established session. The Extensible Messaging and Presence Protocol (XMPP) [369] is another open standard for exchanging XML stanzas in client-to-service or service-to-service open-ended XML streams over TCP. For web compatibility, XMPP also supports interaction over HTTP and BOSH [329], and XMPP over WebSocket is an ongoing standardization effort [404]. Another messaging protocol, motivated by HTTP, is the Streaming Text Oriented Messaging Protocol (STOMP) [402]. STOMP has a text-based format and operates over bidirectional streams, e.g., TCP or WebSocket. With respect to lightweight messaging in the Internet of Things, three open messaging standards are MQ Telemetry Transport (MQTT) [189], the Constrained Application Protocol (CoAP) [389], and Data Distribution Service for Real-Time Systems (DDS) [308]; all of them have binary message formats. MQTT has a small fixed-size header and operates over TCP with SSL/TLS support. CoAP is intended for HTTP compatibility but its messaging is done asynchronously over UDP, and CoAP supports IP multicast for group interaction. The binary wire protocol Real-Time Publish-Subscribe (RTPS) [309] is used in DDS for messaging over TCP and UDP, and IP multicast for group interaction is also supported. Table 2.1 summarizes the interaction patterns in communication protocols.

Table 2.1: Interaction patterns in communication protocols [226]

Protocol Interaction patterns and properties

IPv4, IPv6 Bilateral send and receive, multilateral one-to-many send (multicast, broadcast), dynamic routing TCP Bilateral send and receive, bidirectional byte streams with delivery and order guarantees UDP Bilateral send and receive, multilateral one-to-many send (IP multicast) MPTCP Bilateral send and receive, multihoming and multiplexing over individual TCP connections SCTP Bilateral send and receive, multihoming, multiplexing, byte-oriented messages, optional delivery and order guarantees QUIC Bilateral send and receive on top of UDP, multiplexing HTTP, HTTPS Client-to-service send-receive Comet Multi-responses from service to client, exploits HTTP persistent connections Reverse HTTP Client-side receive-send, switched roles after an HTTP send-receive cycle BOSH Bilateral send and receive, two TCP connections for HTTP, hanging request for service send SSE Multi-responses from service to client, similar to Comet WebSocket Bilateral send and receive, similar to TCP, established in an HTTP send-receive cycle SPDY Client-to-service send-receive, optimization of HTTP wire format, multi-responses WebRTC Client-to-client send and receive, SCTP with DTLS CoAP UDP-based alternative to HTTP in the Internet of Things, client-to-service send-receive, one-to-many send, One-to-many send-receive

2.5 Cloud Interaction Architectures

An architecture integrates transport mechanisms, languages, and high-level interaction patterns, into a blueprint for service delivery. Based on the historical evolution of cloud interaction technologies, architectures are discussed in a web-oriented and a service- oriented view, and Figure 2.5 summarizes the considered architectures.

22 2.5. CLOUD INTERACTION ARCHITECTURES

Web application Web-oriented view Web syndication Web mashup Architectures Remote procedure calls SOAP/WS-* web services Service-oriented view RESTful services Message-oriented middleware Figure 2.5: Web- and service-oriented view on cloud interaction architectures [226]

2.5.1 Web Architectures The World Wide Web has evolved from a Web 1.0 of static and non-interactive hypermedia contents, that were created only by few, to a more interactive and dynamic Web 2.0 with a strong social community aspect in publishing hypermedia content [98]. Personalization based on content semantics, including social, mobile, and location aspects, is considered to be a characteristic of Web 3.0, so the user experience goes beyond merely following hyperlinks [120]. Hypermedia delivery to clients is typically achieved by web applications, and web syndication and web mashups provide means of composition.

Web Application A web application is a service, hosted on a web server, to deliver websites and multimedia to clients. A website composes multiple web resources, in particular, HTML/XHTML hypertext that is parsed into a DOM by the client, Cascading Style Sheets (CSS) to specify the visual representation of the DOM, multimedia resources, and eventually JavaScript program code for dynamically modifying the DOM during runtime. All resources are located using URLs, and a web user agent, e.g., a web browser, retrieves the resources using HTTP or HTTPS as transport mechanism. In terms of interaction, a traditional web application inherits bilateral send-receive from HTTP. Web applications can also exploit HTTP for media streaming by multi-responses delivery of stream chunks. Hyperlinks use URLs to point to nonlinear continuations of the hypertext or additional multimedia content. A resource’s content type is predefined in the hypertext or announced in the HTTP response, and a user agent chooses a module for interpretation during runtime. In other words, messages in the web are dynamically typed. HTTP cookie headers, unique identifiers in URLs, and hidden form fields are then used to track application stateacross multiple requests, e.g., for authenticated sessions. The fundamental security model of web applications for coarse access control is the same-origin policy on the client side that isolates DOMs, HTTP cookies, JavaScript APIs, and read access to foreign web resources of simultaneously active websites according to their origins. This policy prevents a web browser from dynamically composing a DOM from different origins, e.g., by using JavaScript. Content Security Policy (CSP) [459] enables more fine-grained access control policies for allowing dynamic read accessto trusted third-party resources based on content type families. Web Distributed Authoring and Versioning (WebDAV) [116] has been one of the first user collaboration extensions for HTTP, and derived specifications like CalDAV106 [ ] and CardDAV [105] are widely used in services. The Web 2.0 introduces dynamic web applications for improved user experience, and

23 CHAPTER 2. BACKGROUND: INTERACTION AND MONITORING

Asynchronous JavaScript and XML (AJAX) [149] provided the technical means. AJAX enables client-side JavaScript code for dynamically requesting resources over HTTP or HTTPS, so the DOM in context of the script code can be dynamically updated when client-side events are triggered or the requested content becomes available. HTTP push technology for asynchronous service-initiated interaction typically relies on a client- side AJAX API, e.g., Comet. Furthermore, AJAX refers to XML for updates but any processable content type in JavaScript is accepted, e.g., JSON. However, the same- origin policy applies to AJAX too, and only resources from the same origin can be requested. Methods to circumvent the same-origin policy restriction are cross-origin resource sharing (CORS) [469] and JSON with padding [193]. Hypertext is natural language oriented, and the Semantic Web [466] is a W3C initiative toward standardization of machine-interpretable data and reasoning, i.e., Unicode and XML for a unified format; the Web Ontology Language (OWL) [460] for expressing relations; and the Resource Description Framework (RDF) [439] as a collection of vocab- ularies, a metadata data model, and formats for serialization. RDF-compatible standards for application in today’s web are RDF through attributes (RDFa) [465] for HTML and XHTML, HTML5-based Microdata [464], and JSON for Linking Data (JSON-LD) [472]. An independent approach to annotation-based semantics is Microformats [261]. The state-of-the-art HTML5 [471] combines an unambiguous hypertext syntax and a set of assisting technologies to resolve ambiguities in former versions that have led to incompatible user agents. HTML5 has been a major driver for the success of the Web 2.0 and its rich web applications because dependencies on third-party plugins, e.g., Adobe Flash, are dissolved. HTML5 includes Microdata for semantics, audio and video formats, offline storage in an App Cache, a File System API, Web Storage and IndexedDB for local storage, Web Workers for concurrency, Web Messaging between active DOMs, SSE and WebSocket for asynchronous interaction, and Geolocation. Popular technologies on the client side that are available in many modern browsers but not yet part of HTML5 are WebGL [207] for 3D rendering support, WebCL [208] for JavaScript access to parallel computing hardware, and WebRTC for client-to-client interaction.

Web Syndication

Interaction in web applications is bilateral between a client and a service, and a client needs push technology to recognize changes. Service-to-client and service-to-service notification are therefore aspects of web syndication. A webhook [239] is a service-side URL that is called by a client or another service to notify a change. This callback principle will eventually lead to an Evented Web [240] for service-to-service send interaction and sophisticated messaging between web applications and cloud services. Also, clients or services can subscribe to a feed or channel to receive updates, and two standards using XML messages are Rich Site Summary (RSS) [364] and Atom [288]. Atom defines an HTTP-based publishing protocol (AtomPub) [168]. Web feeds are multilateral publish-subscribe messaging architectures for one-to-many send interaction, where clients and services subscribe to a publishing service and wait for updates by polling or asynchronous notification over webhooks or push technology for services or clients respectively.

24 2.5. CLOUD INTERACTION ARCHITECTURES

Web Mashup Web components are reusable web resources, e.g., multimedia, JavaScript libraries, gadgets [158] and services like Google Maps. The success of the Web 2.0 is also attributed to the mashup principle of composing web components. Web mashups are distinguished into service-side and client-side mashups [367]. While a service-side mashup is a service that gathers the web components and composes an integrated view for clients on the service side, a client-side mashup is a service that returns an HTML markup skeleton and JavaScript code, so web components are gathered and integrated by the client. So-called Open APIs have gained popularity for publishing API specifications of web components, and OpenSocial [318] is an initiative to ease the integration of the Web 3.0 social dimension in web applications. The integration of web components typically involves JavaScript code and proper encapsulation is required to suppress unintended information flows between web components [244]. Client-side content policies lead to two extreme cases of local script code interaction: no separation or isolation by direct embedding in the same DOM using a script tag and strong separation and isolation by embedding in isolated DOMs using object or iframe HTML elements. Ryck et al. [367] survey the state-of-the-art for more fine-grained controls in mashups, and they distinguish four categories of web component integration restrictions: separation of components and interaction by specified channels, e.g., HTML5 Web Messaging; isolation of JavaScript execution by static checking to enforce an isolation policy; cross-domain communication restricted by CSP, CORS, and AJAX proxy services; and behavior control for policy runtime enforcement through information flow control, object access mediation, and reference monitors. Table 2.2 summarizes the identified service interaction patterns in web architectures.

Table 2.2: Interaction patterns in web architectures [226]

Architecture Interaction patterns and properties

Web application HTTP or HTTPS send-receive interaction, multi-responses for audio and video streaming, push technology and AJAX for asynchronous send and receive, dynamically typed Webhook Service-to-service send between web applications, callback URLs, for web routing patterns Web feed One-to-many send, i.e., publish-subscribe, service-to-client: by client polling or push technology, service-to-service: by webhooks Mashup Multiple simultaneous web interactions

2.5.2 Service Architectures Communication protocols for enterprise application integration have a strong focus on local-area networks, and they are often not correctly forwarded over the Internet and its middleboxes. Web technology has therefore increased the Internet compatibility of services [8]. Based on the accepted language, services can be distinguished: • Static typing. An interface definition language (IDL) specifies the accepted language, e.g., an XSD or ASN.1 specification, so a parser or stub code couldbe automatically generated. • Dynamic typing. The service interface accepts a family of content types or languages. The interpretation of a message is therefore runtime dependent, and a proper parser is chosen based on the content type or an embedded message specification.

25 CHAPTER 2. BACKGROUND: INTERACTION AND MONITORING

Typing affects how strong clients and services are coupled. While the web is dynamically typed and therefore loosely coupled, static typing restricts interoperability and flexibility, and the consequence is tighter coupling. RPC, web services, RESTful services, and message-oriented middleware are reviewed for the state-of-the-art in architectures for cloud service delivery.

Remote Procedure Calls RPC is a bilateral send-receive architecture, where a client calls a network-accessible procedure to get a return value [57]. An RPC service is specified by a transport mechanism, e.g., HTTP, a data serialization format, e.g., ASN.1, and an agreement on addressing and binding of functions. Historically, the Open Network Computing RPC [414] was the fist API widely available in all major operating systems. Call and return messages are serialized in XDR and exchanged over TCP and UDP. Distributed objects [427] are an evolution of RPC, and three well-known middleware standards are Microsoft Component Services (COM+) [264], the Common Object Request Broker Architecture (CORBA) [310], and Java Remote Method Invocation (RMI) [322]. All three rely on TCP as transport mechanism and have individual data serialization formats, in particular, DCE/RPC [411] for COM+; the Internet Inter-ORB Protocol (IIOP) [311] for CORBA; and the Java Remote Method Protocol, Oracle Remote Method Invocation, and the CORBA-compatible RMI over IIOP [323] for Java RMI. Interfaces are statically typed, and stub code on the client side abstracts away the network interaction for object allocation, transactions, and garbage collection. The Internet Communications Engine [498] is conceptually similar to CORBA and resorts web protocols for interaction. XML-RPC [385] serializes call and return messages in XML, uses HTTP as transport mechanism, and a service is identified by its URL. There is no schema for aservice interface and messages are therefore dynamically typed. The XML-RPC Description Language (XRDL) [493] is an IDL attempt to enable stub code generation. JSON- RPC [279] is similar to XML-RPC, but uses JSON for serialization and the transport mechanism is not restricted. Apache Avro [25], Apache Etch [23], and Apache Thrift [22] have been proposed for high performance cloud backend RPC services. Avro is a serialization format and a transport-agnostic RPC mechanism for big data analysis in Apache Hadoop, where messages are dynamically typed by an attached description in JSON. Etch uses TCP as transport mechanism and specifies an IDL-like service description language anda data serialization format. Messages are statically typed, and stub code for clients and services can be generated from a service description. The Thrift framework by Facebook specifies an IDL that also enables stub code generation for statically typed messages. The framework is kept abstract, but some default procedures are provided, e.g., JSON over TCP or HTTP. Twitter Finagle [420] is based on Thrift and introduces multiplexing of parallel Thrift interactions over a single TCP connection. Similar to ASN.1, Google Protocol Buffers [157] is a specification language for abstract data structures and a binary data serialization format. Transport mechanisms are unrestricted, and stub code for the statically typed messages can be generated. Hes- sian [81] relies on HTTP as transport mechanism and specifies web-based RPC. The compact binary serialization format allows messages to be dynamically typed. Burlap [80] is basically the same protocol; however, the message serialization is XML based.

26 2.5. CLOUD INTERACTION ARCHITECTURES

SOAP/WS-* Web Services To overcome complexity problems from shared state in distributed objects and platform restrictions in tightly coupled architectures, web services have been proposed [8, 335]. Web services rely on open standards and self-contained messages for loose coupling. The Simple Object Access Protocol (SOAP) [447] for XML-based messaging is a core technology, and it is extended for reliability, security, transactions, orchestration, and business process aspects by web service standards (WS-*). SOAP supports in theory any transport mechanism, including message-oriented middleware; however, HTTP or HTTPS are recommended in the WS-I Basic Profile [481] for interoperability.

Technologies. The Web Services Description Language (WSDL) [433] is XML based for describing a web service by defining XSD message formats for available operations at an interface. Message bodies are therefore statically typed. Every interface has a bilateral message exchange pattern, e.g., in-only (client-side send), out-only (client-side receive), or in-out (client-side send-receive). Furthermore, a WSDL defines an interface binding (i.e., transport mechanism) and endpoints (i.e., web service URLs). To discover a WSDL description of a service, Universal Description, Discovery, and Integration (UDDI) [293] specifies a registry that is also published as a web service. Alonso et al. [8] characterize service interaction in four layers: HTTP or HTTPS as transport mechanism, messaging in the SOAP format, meta-protocols for service coordination, and high-level middleware properties for reliability, security, transactions, and orchestration.

Messaging. The XSD SOAP schema defines a root element envelope that holds an optional header and a body for the specified message formats. To transport arbitrary binary content in a SOAP message, small binary contents can be stored directly in the SOAP message as text using Base64 encoding. Larger binary contents can be more efficiently handled by encoding the SOAP message in a container format like Microsoft DIME, SOAP Messages with Attachments (SwA) [440], or the Message Transmission Optimization Mechanism (MTOM) [445]. SOAP messaging is similar to RPC because operations are only available at the WSDL- defined endpoints. Endpoint references and message addressing in WS-Addressing [441] introduce multilateral and routing patterns. An endpoint reference is a URL plus parameters that address an endpoint of a service. Endpoint references for destination or error handling are then referred to in the SOAP header. WS-Eventing [458] and WS- Notification [294] for multilateral interaction on top of WS-Addressing are two competing standards for different publish-subscribe architectures as shown in Figure 2.6. While the publisher in peer-to-peer publish-subscribe has to handle subscriptions directly, a broker allows to address an anonymous group of subscribers. HTTPS does not ensure confidentiality when SOAP messages are dynamically routed over multiple services. WS-Security [295] therefore specifies the wsse:Security element in a SOAP header, security tokens, and methods, i.e., XML Encryption [435] and XML Signature [453], for end-to-end encryption and cryptographically signed messages. Further extensions are WS-Trust [306] and WS-SecureConversation [301] to establish a security context for speedier cryptographic key exchange. Reliable SOAP message delivery based on acknowledgments is standardized in WS-Reliability and WS- ReliableMessaging [300]. The definition and exchange of policy assertions, e.g., Quality-

27 CHAPTER 2. BACKGROUND: INTERACTION AND MONITORING

Publisher Publisher publish publish Broker

subscribe subscribe subscribe

Subscriber1 Subscriber2 Subscriber1 Subscriber2 (a) Broker-based publish-subscribe (b) Peer-to-peer publish-subscribe

Figure 2.6: Publish-subscribe architectures for multilateral interaction of-Service parameters, is then standardized in the WS-Policy [448] framework which is extended by WS-SecurityPolicy [305] for security-centric assertions. On a higher level of interaction, WS-Coordination [299] is a standard for coordinating service activities, e.g., business activities in WS-BusinessActivity [298] and transactions in WS-AtomicTransaction [297]. Standards for composition, orchestration, and modeling of composed web services on a business process level are studied by Beraka et al. [44], and examples are WS-Choreography [446], the Business Process Model and Notation (BPMN) [312], and the Business Process Execution Language (BPEL) [296].

RESTful Services A key principle of Representational State Transfer (REST) is resource orientation, i.e., abstraction of information as a resource for a unified interface between components129 [ ]. REST defines four rather abstract interface constraints without protocol restrictions; however, REST has been strongly influenced by web technology, where HTTP or HTTPS are default transport mechanisms. The four interface constraints are: identification of resources using URIs, manipulation of resources through their representations, self-descriptive messages, and hypermedia as the engine of application state. A RESTful service offers a set of resources that are identified by URIs. A representation is a binary sequence of a certain content typethat captures the state of resource. Methods then apply operations on a resource in send-receive fashion, i.e., HTTP method GET to read, PUT to create, POST to update, and DELETE to delete a resource. The advantage of using HTTP methods is the compatibility with existing cache infrastructures in the Internet, so services and clouds can scale easily. Furthermore, the messages in REST, e.g., HTTP requests and responses, are self descriptive according to their MIME content type and therefore dynamically typed. Metadata of a resource, i.e., HTTP headers, enable content negotiation, checksums, authentication, and access control during interaction [336]. A RESTful service is stateless in an interaction, and contrary to a web application, a client needs to track application state in self-contained send-receive interactions. Finally, REST promotes dynamic discovery of resources using hypertext. A client only needs to know the service entry point, i.e., a bookmark, and hyperlinks in the returned bookmark hypertext present the client further continuations from its current state.

Technologies. To describe a RESTful service, APIs and entry points are often just explained in natural language, e.g., Open APIs. WSDL Version 2.0 introduces support

28 2.5. CLOUD INTERACTION ARCHITECTURES for fine-grained HTTP bindings, so a RESTful service could be described in amachine- readable format too. The Web Application Description Language (WADL) [455] is XML based and expresses a set of resources, interrelations, supported HTTP methods, and MIME content types of resources for web applications and RESTful services. For XML- based resource representations, WADL natively supports XSD and Relax NG as schema languages. Dynamic service discovery is a registry of entry bookmarks, and examples are DNS service records [87], web syndication services as bookmark feeds, and the Google API discovery service [160]. Interaction in HTTP-oriented REST is bilateral send-receive. Security in REST is limited to secure transport, i.e., HTTPS, and there are is no standardized reliable delivery or transaction handling. Any content type for a representation is valid as long as it is supported by the client. With respect to composition, resources in RESTful services are often used as web components in web mashups. JOpera [332] is a framework for REST composition, and BPEL for REST [333], BPMN for REST [334], and the JavaScript-based S language [63] are examples for workflow orchestration. HTTP-oriented REST is designed to use four HTTP methods for resource operations; however, many clients such as web browsers are restricted to HTTP methods GET and POST. Pautasso et al. [336] therefore distinguish Hi-REST and Lo-REST. While Hi-REST is capable of all four HTTP methods and resources are by default represented in XML, Lo-REST relies on workarounds, e.g., an extra HTTP header or a hidden form field, to deal with restricted HTTP methods.

Constrained RESTful Environments. The Internet of Things is considered to be an environment with restricted computational power and memory [388]. CoAP [389] has therefore been proposed as an HTTP replacement for RESTful services in constrained environments. CoAP and HTTP share concepts, e.g., methods, content types, and URI paths, for compatibility reasons. However, CoAP adds certain features specifically for constrained environments, like separated acknowledgment responses, multicast support for one-to-many send interaction, and service discovery.

Message-Oriented Middleware Message-oriented middleware (MOM) [104] provides an infrastructure for scalable, flexible, reliable, and loosely coupled inter-process communication between peers, and examples are an enterprise service bus or message queuing in clouds. A message typically has a header and a body and represents some event as a self-contained, autonomous entity. A message queue, e.g., a first-in-first-out queue, allows storing, forwarding, and transforming messages for asynchronous interaction in MOM. Figure 2.7 presents the two approaches to messaging architectures. While broker-based messaging reduces communication complexity, peer-to-peer messaging minimizes delays by a unified component in every peer for coordinating discovery and direct interaction. A peer can then participate as a client, service, or both [104]. In general, MOM enables sophisticated interaction in a group of peers ranging from bilateral send, receive, and send-receive exchange to dynamic routing. According to Curry [104], a MOM is characterized by a messaging specification, filtering mechanisms, message transformation methods, and additional properties to increase the overall Quality-of-Service. The messaging specification includes message formats, transport mechanisms, and adapters for interconnecting two MOM systems.

29 CHAPTER 2. BACKGROUND: INTERACTION AND MONITORING

Peer1 Peer2 Peer3 Peer2 Peer3 Message-oriented middleware Peer1 Peer4

Peer6 Peer5 Peer4 Peer6 Peer5 (a) Broker-based messaging (b) Peer-to-peer messaging

Figure 2.7: Architectures for message-oriented middleware [104]

Message filtering in a MOM is distinguished into channel-based, subject-based, content- based, and composite systems. In a channel-based system, a client subscribes to a channel for a certain class of events. A subject-based system allows a client to subscribe messages, where the header matches a certain pattern, e.g., the header subject. A content- based system is similar to subject-based systems, but pattern matching is also performed on the message body. A composite system then extends content-based matching to sets or sequences of messages. The middleware can also provide APIs for message transformation, e.g., XML transformation, when messages of varying content types originate from heterogeneous peers. Finally, a MOM can offer features for increasing integrity, reliability, and availability of messaging, e.g., by transactions and atomic multicast notification, delivery guarantees using acknowledgments, reliable delivery, message prioritization, load balancing, and clustering for fault tolerance.

Messaging APIs. To hide the technical complexity of messaging, a MOM is typically accessed through an API, and there are several attempts toward system-independent APIs to relax vendor lock-in in heterogeneous messaging systems. Java Message Ser- vice (JMS) [321] is a popular transport-agnostic API that offers high-level operations to create, send, receive, and read messages. According to the content type in a message’s header, the message body is dynamically typed. The Open Middleware Agnostic Messaging API (OpenMAMA) [317] is an open- source library for a unified API across multiple messaging infrastructures to ease application development and relax vendor lock-in. A MOM has to provide a so-called OpenMAMA bridge implementation. The RESTful Messaging Service (RestMS) [485] is another web-compatible API specification based on REST principles and using HTTP or HTTPS for transport. RestMS specifies URLs to post or receive dynamically typed messages using MIME content types, e.g., XML and JSON. The API specification also includes bridge profiles for integration of messaging systems, e.g., AMQP.

Proprietary Messaging Solutions. Microsoft MSMQ [265] is a peer-to-peer MOM, where networked queues are hosted in the operating system, and processes can send to or receive from a queue. MSMQ provides routing and prioritization of messages, transactions, delivery guarantees, authentication and encryption, and a type system for message bodies. As transport mechanism, MSMQ has an individual protocol or resorts to COM+. Furthermore, Microsoft .NET Windows Communication Framework (WCF) supports MSMQ as a transport mechanism for services; however, message bodies are then restricted to XML, binary, or ActiveX format. MSMQ allows bilateral asynchronous interaction and supports IP multicast for multilateral one-to-many send interaction, where

30 2.5. CLOUD INTERACTION ARCHITECTURES multiple queues are addressed. Other proprietary solutions are Microsoft SQL Server Service Broker [267] for a broker architecture, TIBCO Rendezvous [416] for a peer-to-peer architecture, Terracotta Universal Messaging [390], and Oracle Tuxedo Message Queue [320] in the Tuxedo cloud application server.

Open-Standard Messaging Solutions. AMQP [302] is motivated by the lack of interoperability of proprietary messaging solutions, and it therefore specifies an open transport model, i.e., an agreed wire format, and a semantic queuing model for messaging. A queue in AMQP supports ordering, searching, and transactions. Using a self-contained type system, a message has a dynamically typed body and also a header with a distinguished routing key. A binding relates a queue with a broker-like exchange. A message is sent to an exchange and forwarded to all queues with a matching binding. With respect to message filtering capabilities, there are four types of exchanges: direct, topic, fan-out, and headers exchange. A direct exchange forwards a message to queues, where the binding matches exactly the routing key, i.e., a channel-based system. A topic exchange supports routing key patterns in bindings and therefore enables a subject-based system. A fan-out exchange forwards a message to all queues without filtering, and a headers exchange matches predicate arguments on a message header, i.e., a content-based system. In terms of interaction patterns, AMQP supports one-to-many send to address multiple queues over exchanges, but also send and receive interaction is possible. There exist URI schemes for exchanges (amqp:, amqps:), so brokerage can be offered as a service. AMQP also provides authentication, encryption, transactions, and delivery guarantees. XMPP [369], originally known as Jabber, has a history in Internet chat applications for instant messaging, presence information, and contact lists. However, XMPP also has middleware properties and supports bilateral send and receive of XML-based messages, where an XMPP service acts as a broker for clients or interacts with other XMPP services in a federated architecture. XMPP can use any bidirectional protocol, e.g., TCP, HTTP, or WebSocket, as a transport. Extensions for XMPP are managed in a community process, e.g., Base64-encoded binary content [370], RPC over XMPP [5], automated service discovery [179], publish-subscribe architectures for one-to-many send interaction [269], addressing for dynamic routing [180], reliability guarantees [270], and end-to-end encryption using S/MIME containers. XMPP messages are XML stanzas with untyped text-based content. For middleware application, either a custom protocol, e.g., XMPP bits of binary [370] and SOAP [134], or out-of-band agreement is necessary. The text-based STOMP [402] is for asynchronous send and receive interaction in a broker architecture. A client establishes a session to a broker service, and both start to exchange so-called frames for messages, receipts, and errors. Similar to an HTTP request or response, a frame has a header, including a MIME content type field, and a dynamically typed body according to content type. STOMP supports transactions and message acknowledgments for reliability. With respect to interaction, STOMP provides bilateral interaction between client and service or multilateral one-to-many send in a broker-based publish-subscribe architecture. MQTT [307] is an open standard for lightweight messaging in the Internet of Things. Supported transport mechanisms are TCP, TLS, and WebSocket. With respect to interaction, MQTT is intended for broker-based publish-subscribe architectures, i.e., one- to-many send interaction, and a message transports up to 256 megabytes of untyped content. An out-of-band agreement on the content type is therefore required. MQTT uses

31 CHAPTER 2. BACKGROUND: INTERACTION AND MONITORING acknowledgments and retransmissions for reliability but does not support transactions. DDS [308] is another open standard for machine-to-machine interaction in the Internet of Things and supports a peer-to-peer publish-subscribe architecture, i.e., one-to-many send interaction, with scalability, high throughput, and real-time delivery in mind. Publish- ers, subscribers, and topics are partitioned into domains. Messages for a certain topic are statically typed according to an IDL specification. When a subscriber requests a certain topic, the publishers in the domain use peer-to-peer interaction for message delivery. DDS provides dynamic discovery for locating peers, negative acknowledgments for reliable delivery, and rich Quality-of-Service policies for transmission over the RTPS [309] wire protocol. Authentication and encryption are not yet part of the official standard [313]. Apache Kafka [27] is a software implementation that specifies a broker-based publish- subscribe architecture, i.e., one-to-many send interaction, for high-performance applications. Messages are sent over TCP and the Kafka server implementation supports clustering, message replication, and persistent storage for fault tolerance. A producer publishes messages for a certain topic, and consumers subscribe to a topic, i.e., a channel- based system. Moreover, a Kafka cluster manages a partitioned log for every topic, where every partition is an ordered list of already published messages. The partitions are replicated in the cluster, so the ordering of published and consumed messages is guaranteed. Messages are deleted after a certain timespan from the log. A consumer maintains an offset in the ordered list of messages for a subscribed topic, so older messages are still accessible if they have not expired yet. The body of a message is an untyped byte sequence, so an out-of-band agreement on the content type is required. ZeroMQ [190] is an intelligent socket library that uses network protocols, e.g., TCP, UDP, and IP multicast, to provide various interaction patterns between peers. A process or thread maintains a local message queue that is accessible through a socket. ZeroMQ supports bilateral send, receive, and send-receive interaction; dynamic routing; and publish-subscribe one-to-many send interaction. There is no dedicated broker in ZeroMQ; however, a broker can be implemented using the library. Message bodies are untyped byte sequences, and an out-of-band agreement on content-types is necessary. Software examples are NullMQ [241], a WebSocket-based JavaScript library that bridges ZeroMQ into a web browser using a modification of STOMP, and ZeroRPC [114] for web-based RPC using JSON-based MessagePack as dynamically typed data serialization format.

Message Queuing as a Service. A MOM broker is a critical component in a messaging infrastructure, and needs for scalability and fault tolerance have motivated message queuing in the cloud. One of the first service offerings was Simple Queue Services (SQS) [11] by Amazon Web Services. SQS provides HTTP and HTTPS access to an internal SOAP/WS-* service stack and supports untyped text messages of limited size. Pull Queues [162] and Push Queues [163] are used for messaging and task distribution in Google’s App Engine. Messages in JSON format are sent or received over a RESTful API for both queue types. For message delivery on the client side, pull queues need to be polled, and push queues use webhooks. Cloud Pub/Sub [161] is a broker-based publish-subscribe service for the Google App Engine or web clients. A publisher sends a JSON-based message of a certain topic to a RESTful API, and the message is stored in subscriber queues, so message delivery can be tracked. Subscribers then poll the API or get notified over a webhook. Azure Queues and Service Bus Queues [262] are Microsoft cloud services. Azure Queues provide a RESTful API for bilateral exchange of untyped text messages between

32 2.5. CLOUD INTERACTION ARCHITECTURES two peers. Multilateral interaction such as broker-based publish-subscribe or dynamic routing is then enabled by Service Bus Queues, where messages carry content types. AMQP brokerage is offered by IronMQ [194], StormMQ [403], and CloudAMQP [94]. CloudMQTT [95] offers message brokerage for complex event processing. A RESTful broker-based publish-subscribe architecture is offered by Rackspace Cloud Queues [347]. Table 2.3: Interaction patterns in service architectures [226]

Architecture Interaction patterns and properties

XML-RPC HTTP send-receive, dynamically typed JSON-RPC Send-receive, dynamically typed Apache Avro Send-receive, dynamically typed Apache Etch TCP send-receive, dynamically typed Apache Thrift Send-receive, statically typed Protocol Buffers Send-receive, statically typed Hessian, Burlap HTTP send-receive, dynamically typed SOAP Send, receive, send-receive, statically typed WS-Adressing Multilateral interaction and routing patterns, e.g., relayed request WS-Eventing, WS- One-to-many send or one-from-many receive, e.g., publish-subscribe architectures Notification REST Send-receive, i.e., HTTP or CoAP, dynamically typed JMS Transport-agnostic API, dynamically typed OpenMAMA Middleware-agnostic messaging API RestMS REST-based messaging API JMS-compatible OpenMQ, IBM Websphere MQ, TIBCO Enterprise Message Service Proprietary TIBCO Rendezvous, Oracle Tuxedo, Terracotta Universal Messaging MSMQ Peer-to-peer, send, receive, one-to-many send (using network multicast), routing patterns, broker- based: SQL Server Service Broker AMQP Broker-like exchanges, send, receive, one-to-many send, dynamically typed XMPP Broker-based send and receive; with extensions one-to-many send, i.e., publish-subscribe, untyped or dynamically typed STOMP Send and receive, broker-based one-to-many send, i.e., publish-subscribe, dynamically typed MQTT Broker-based one-to-many send, untyped DDS Peer-to-peer one-to-many send, i.e., publish-subscribe, statically typed Apache Kafka Broker-based one-to-many send, i.e., publish-subscribe, untyped ZeroMQ Untyped socket abstraction, various patterns

2.5.3 Cloud Computing Aspects Service interaction patterns in communication protocols and architectures for cloud interaction are summarized in Table 2.1, Table 2.2, and Table 2.3 respectively. For implementation examples, the reader is referred to the survey [226]. For state-of-the-art link layer technologies in cloud datacenters, the reader is referred to Bitar et al. [59]. Transport mechanisms in cloud computing are primarily for bilateral interaction between a client and a service. Multilateral interaction, e.g., provided by UDP over IP multicast, could offer advantages for media applications; however, according to Mitchell [272], today’s cloud providers disable multicast because of the increased network load. Therefore, architectures such as SOAP with WS-Addressing, publish-subscribe services, and MOM provide multilateral interaction patterns between a group of peers on a higher level using transport mechanisms as building blocks. Today’s cloud PaaS and SaaS paradigms primarily focus on web transport mechanisms and architectures because they are compatible with the Internet and reliably forwarded. Examples are HTML5 web applications and mashups, RPC over HTTP, SOAP/WS-* web services, and RESTful web services. Also, a trend toward web-compatible and platform- independent messaging has been observed, e.g., XMPP over HTTP or WebSocket, SOAP

33 CHAPTER 2. BACKGROUND: INTERACTION AND MONITORING over XMPP, MQTT over WebSocket, AMQP over WebSocket, RESTful APIs for message brokers, and NullMQ. XML his a fundamental building block in many technologies, e.g., XHTML websites, AJAX updates in XML, RSS and Atom web feeds, XML-RPC, SOAP/WS-* messaging, resource representation in REST, and XMPP messaging. Grozev and Buyya [170] and Toosi et al. [417] review the state-of-the-art in inter- cloud computing which is a natural evolution of the cloud paradigm toward federations of clouds. Messaging over XMPP has been proposed as a foundation for inter-cloud communication [46, 82] and inter-cloud interoperability [47]. SOAP/WS-* web services [78] and AMQP [46] are also considered as candidates for inter-cloud.

2.6 Monitoring of Client-Cloud Interaction

A monitor or monitoring system observes the behavior of another system to verify correctness properties, e.g., for security, fault analysis, failure recovery, or debugging [111]. With respect to cloud computing, this section recalls the components and purpose of a monitor, and state-of-the-art observation points for data acquisition in cloud computing are reviewed. In accordance to Biskup [58, p. 359] and Schroeder [384], Figure 2.8 illustrates the high-level components of a monitoring system. An observation component senses raw data from an observation point in the system under observation and generates audit data, e.g., events, by preprocessing the raw data. Audit data can be stored in an audit database for offline analysis or processed directly for online analysis. Based on a configured monitoring policy, the audit data, and eventually knowledge from cooperating remote agents, the analysis component generates alerts in case of policy violations. Alerts are forwarded to a reaction component. In accordance to configured reaction templates, alerts are usually reported for logging purposes, e.g., to an administrator. Behavior of the system under observation could be enforced as a response, e.g., by graceful termination or degradation, recovery procedures, and corrective measures. Finally, the monitoring system eventually informs cooperating remote agents about an alert.

Audit database Monitoring policy Reaction templates

Audit data Analysis Alert Reaction Offline Observation Online Response Report Coop.

Raw data System Enforce under Cooperating agents Observation point observation Administrator

Figure 2.8: High-level components of a monitoring system (based on [58, p. 359])

34 2.6. MONITORING OF CLIENT-CLOUD INTERACTION

The fundamental motivation for monitoring according to Plattner and Nievergelt [341] is that software developers have better intuition about certain system state aspects than about implemented code. Historically, execution monitoring [237, 382, 384] has been the first attempt toward debugging, checking correctness, and runtime verification. To- day’s monitoring use cases also include dependable systems [33], fault tolerance [111], online failure prediction [372], safety in distributed systems [156], Service Level Agree- ments (SLAs) [97], and web services [201]. Monitoring also has a strong interconnection to security, in particular, intrusion detection [233] and access control [373].

2.6.1 Cloud Monitoring When a client consumes a cloud service, both enter a relationship, often agreed in a contract, and it is in the interest of both parties to verify their claims. Several aspects of cloud computing strengthen the need for monitoring. First, a client entrusts data to a service and loses governance [32]. Monitoring the service could assure the client that the service behaves as agreed. Furthermore, a cloud provider offers an execution environment that could use black-box components, e.g., software libraries, internal services, and hidden procedures. A client could be forced to use these black-box components but has no means of verifying their internal state, and the consequence is an incomplete model [197]. The cloud’s execution environment needs hidden routines to implement elasticity and scalability; however, these hidden distributed computations could lead to randomness and operational nondeterminism in a service’s run [197]. Hidden routines and shared computational resources can furthermore lead to cross-tenant information flows that cannot be observed or verified by the client [123]. Finally, a cloud is typically restricted to certain platforms, technologies, or programming languages. These restrictions can result in insufficiencies and motivate workarounds; the consequences could be untreated exceptional states [197]. Given the historical background, the following three high-level goals of monitoring have been identified for cloud monitoring:

• Correct execution. A monitor derives internal and external state of the system under observation from its behavior. States and state transitions of a run are checked with respect to a monitoring policy, e.g., according to a specification or correctness conditions. This enables the monitor to take action if an unexpected state is reached or conditions are violated.

• Dependability. Hardware and software are assumed to be faulty, and unexpected or exceptional states can occur anytime and need to be handled appropriately, so the offered service by the system under observation satisfies dependability requirements. Examples are online failure prediction and intrusion detection.

• Measurement. When service consumption is defined in a contract, e.g., in anSLA, the service quality requirements need to be described in measurable quantities. Monitoring measures and verifies quality metrics with respect to the contract. Actions in case of a violation include automated claims and content negotiation.

Aceto et al. [4] review the state-of-the-art in cloud monitoring, in particular, the landscape of commercial and open-source monitoring platforms and Monitoring-as-a- Service offerings. The surveyed monitoring systems are distributed systems that resort to agents and probes to collect data from facility, hardware, networks, operating systems,

35 CHAPTER 2. BACKGROUND: INTERACTION AND MONITORING applications, middleware, and users. The monitoring systems are furthermore characterized according to properties such as scalability; elasticity; resilience, reliability, and availability; adaptability; timeliness; autonomicity; comprehensiveness, extensibility, and intrusiveness; and accuracy. This section highlights the available observation points for monitoring of client-cloud interaction.

2.6.2 Observation Points The observation points are categorized according to structural layers for hardware, networks, operating systems, services, middleware, and users in clouds.

Hardware Layer On-chip sensors in hardware record health information, e.g., performance and activity counters, failures, temperature, voltage, and clock frequency. In clouds, this information is typically available to the cloud provider and needs to be collected by a software agent. However, when a client has direct hardware access, e.g., the graphics processors in Amazon EC2 for parallel computing, some performance counters can be read. Mobile devices also have sensors for device motion [12] and geographical position [159] that could be exposed as client-side hardware sensors by an agent.

Network Layer Monitoring of network communication on the client or service side is a popular technique when the system under observation is considered as a black-box component. Section 2.4 already studies protocol stacks and architectures for client-cloud network communication, and observation points are located on the different layers of the protocol stack. Packet delivery in IP and IPv6 networks is based on the IP packet header, i.e., destination address, and a router should leave the payload untouched. However, an increasing number of network devices inspect also packet payloads for routing and filtering decisions which is generally referred to as Deep Packet Inspection (DPI) [43].

Simple Network Management Protocol. The UDP-based Simple Network Manage- ment Protocol (SNMP) [175] has a long history in network monitoring. An SNMP architecture distinguishes a manager and network devices that utilize agents. An agent maintains variables, i.e., Object Identifiers (OIDs), for device-specific network measurements and configuration settings. Variables are organized in a hierarchical namespace referred to as Management Information Base (MIB). A manager then gets or sets OIDs on network devices using SNMP, and measurements can serve as observation point [413].

Packet Headers. Monitoring of IP packet header information, including a view on transport protocol headers, e.g., TCP segment headers, UDP datagram headers, and Internet Control Message Protocol (ICMP) messages, can reveal inter-process communication behavior. The communicated payloads are left untouched. Examples are network firewalls that implement an access policy based on IP addresses and TCP and UDPports of services.

36 2.6. MONITORING OF CLIENT-CLOUD INTERACTION

Packet Payload. DPI technology for packet payload observation collects data from packets beyond protocol headers. The payload of an IP packet is a fragment of a higher- layer protocol, e.g., a TCP segment or UDP datagram. Actual messages or byte streams can however span over multiple packets. This view is limited for encrypted protocols, e.g., SSL, TLS, and DTLS. In this case, only the negotiation of encryption parameters is observable in clear text. Payload-based inspection can be further distinguished into:

• Packet-level payload inspection. Each observed packet payload is considered an independent event, and conversations on higher-layer protocols are ignored for the sake of simplicity.

• Reassembling payload inspection. Higher-layer protocol messages or streams are reconstructed by the monitor by reassembling packet payloads from TCP segments or fragmented UDP datagrams. However, characteristics of higher protocols need to be correctly implemented, e.g., TCP allows out-of-order segments and retransmissions [487].

Network Flows. Another approach to network observation is to collect network flows, and techniques have been reviewed by Celedaˇ and Krmícekˇ [423]. A network flow is a record that summarizes a uni- or bidirectional flow of packets that share source and destination address, transport protocol, and port information [486]. For example, a TCP session is reduced to one bidirectional flow or two unidirectional flows, depending onthe actual technique, and measurements include a timestamp, number of packets and total number of bytes in the flow. As payload data is not stored in a flow, less privacy concerns are raised, and also encrypted sessions can be recorded. Two notable standards are Cisco NetFlow [90] and IPFIX [183]. A network device or software agent exports network flows to a so-called collector for further analysis.

Circuit-Level Gateway. The concept of circuit-level gateway has been proposed as transport layer policy enforcement point in a network [410], and today, Sockets Se- cure (SOCKS) [235] is the most popular standard. A client first establishes a session with the gateway, so the gateway can exchange TCP segments and UDP datagrams on behalf of the client and independent from application protocols. The circuit-level gateway has an unadulterated view on bidirectional TCP byte streams or UDP datagrams; however, client configuration is necessary.

Operating System Layer While cloud platforms and services are run on operating systems under control of the service provider, IaaS clouds offer virtualization, so clients can run individual operating systems [32]. Observation points in the operating system are potential data sources for client- and service-side monitoring.

Logs and Audit Trails. Operating systems maintain log files to store errors, failures, notifications, and debugging events in chronological order for administrative purposes. A log record includes a timestamp, location, type and classification, and a log message. An example is Syslog [152] which specifies a record format and also a protocol for network propagation. Also, an explicit audit trail for security-relevant events can be provided by

37 CHAPTER 2. BACKGROUND: INTERACTION AND MONITORING the system under observation, e.g., access logs, the Linux audit framework [319], and the Basic Security Module (BSM) [418].

System Activity. Operating systems record system activity properties of the kernel, run- ning processes, and interfaces, e.g., processor utilization, system load, network interface statistics, and memory utilization. Furthermore, many of these metrics are collected and individually exposed for every process, e.g., the /proc and /sys file systems in Linux.

System Calls. The interface between processes and the kernel of an operating system is a special software interrupt referred to as system call, e.g., to open a file or fork a process. The motivation for system call monitoring in Linux and Unix systems is that the behavior of a process reflects in an ordering of system calls [145], e.g., for dynamic analysis of malware [119]. For auditing and debugging, a modern operating system is usually capable of exposing system calls, e.g., strace [234] and dtrace [167].

Call Stack Inspection. A modern operating system isolates processes from each other, and every process has an individual call stack of activation frames. A frame stores function-local variables and program position, and a function call stores a new frame on the stack for later continuation. Variable values and ordering of frames on the stack are a potential observation point, and a kernel modification for call stack inspection has been proposed by Feng et al. [122].

API Hooking. The Microsoft Windows API is a set of operating system functions that are conceptually comparable to system calls in Linux and Unix [119]. A so-called API hook redirects an API function call to some handler for monitoring of calls, arguments, and behavior enforcement. Examples for API hooking also include dynamic malware analysis [119].

Virtual Machine Introspection. Techniques like API hooking, call stack inspection, or a modified kernel interfere with the operating system and could be identified byarunning process. This problem especially exists in behavioral analysis of potentially malicious software, where malware changes its behavior when a monitor has been detected [119]. Virtual machine introspection is an approach toward resilient monitoring. The target operating system runs in a virtual machine, e.g., in a cloud, and a virtual machine monitor provides access to the virtualized hardware. A monitor then needs to reconstruct the state of the operating system and processes from activity in the virtualized hardware [146, 282].

Service Layer

Based on the cloud delivery model, applications that provide a service are implemented by the provider (i.e., SaaS) or the client (i.e., PaaS). Observation points for the behavior of applications and services are therefore considered. Applications often maintain an event log for auditing and debugging which could serve as observation point, e.g., transaction logs, performance logs, and event notifications.

38 2.6. MONITORING OF CLIENT-CLOUD INTERACTION

Code Instrumentation. Code instrumentation gathers data such as function call traces, conditions, and variable values directly from an application or service during runtime. Techniques for code instrumentation are distinguished into manual instrumentation, where a developer explicitly adds pre- and post-conditions that emit the information during runtime, and automated code instrumentation. Automated code instrumentation can be further distinguished into bytecode instrumentation [18, 56, 285], code rewriting [284], and aspect-oriented programming by inserting advice statements [289, 290, 354]. While static code instrumentation inserts the monitoring statements at compile time, dynamic code instrumentation rewrites the code before or during interpretation. For example, Magazinius et al. [246] present a dynamically inserted reference monitor for JavaScript code. Historically, code instrumentation has been used for debugging and profiling, and monitoring use cases are information-flow security [368] and control-flow integrity enforcement [2].

Middleware Layer The middleware layer considers message exchange and architectures that enable clients and services to interact. Technologies have already been discussed in previous sections. A middleware implementation, e.g. for SOAP/WS-* web services or MOM, typically supports logging for auditing purposes, e.g., audit frameworks [482], message flow logs [375], and brokerage logs [483].

RPC Filter. In RPC-based architectures for client-cloud architectures, the procedure call and return arguments are serialized in an agreed format, and a web-compatible transport mechanism is used for interaction. An RPC filter is then similar to a function hook that intercepts calls and returns.

Message Queue Filter. Message queues are found at the client and the service. A message queue filter478 [ ] is a software component that observes messages in a queue. Furthermore, in broker-based messaging, the broker receives incoming messages at a certain endpoint, and a monitor could be integrated by replicating messages, e.g., by adding a blind-copy endpoint reference in WS-Addressing for SOAP/WS-* web services.

Web Proxy. For caching and content filtering in web architectures, a web proxy forwards HTTP requests and responses between a client and a service [245]. Web proxies can be distinguished into forward and reverse web proxies [407]. A forward proxy establishes interaction with a web application on behalf of a client, and a reverse proxy accepts interaction on behalf of a web application or RESTful web service. Both types of web proxies observe complete HTTP requests and responses, and a proxy can also enforce actions. However, a web proxy cannot observe encrypted sessions and either just blocks or forwards encrypted data. An X.509 certificate for SSL/TLS in HTTPS is issued fora certain domain name, so a client can verify the identity of a service based on the domain name. A forward proxy would need a fake X.509 certificate or influence the encryption handshake to gain access to the clear-text requests and responses [245].

Suffix Proxy. A suffix proxy245 [ ] is similar to a web forward proxy by interacting with a service on behalf of a client; however, a suffix proxy supports inspection of HTTPS traffic because two independent SSL/TLS sessions are established, i.e., client-to-proxy

39 CHAPTER 2. BACKGROUND: INTERACTION AND MONITORING and proxy-to-service. There is no need for explicit configuration in the client. A suffix proxy is in fact a service for a certain DNS domain, e.g., suffix.org, so requests and responses are transparently forwarded to web applications identified by the prefix ofthe domain. For example, HTTP requests to google.com.suffix.org are forwarded by the proxy to google.com. However, a suffix proxy needs to adapt all forwarded requests and responses to update hyperlinks.

Integrator. In a client- or service-side web mashup, an integrator composes web components by using JavaScript, and it can be seen as a middleware [120]. By instrumenting JavaScript code, an integrator can add monitoring statements for integration-driven monitoring, e.g., an observation point for HTML5 Web Messaging between isolated web components or inline JavaScript security monitors [245].

User Layer To monitor the operations and behavior of users is another observation point, in particular, for cloud services that exhibit social aspects. PaaS and SaaS implementations often provide logs for auditing or service adaptation based on user preferences, e.g., authentication, access, geolocation, and user history logs. Actively emulating user behavior in web architectures is primarily concerned with monitoring of availability and performance of a service and referred to as synthetic user monitoring [103]. However, the emulation cannot provide insights into behaviors that occur when many real users interact with a service. To observe the behavior of real users of a service, e.g., by monitoring whether requests are served in time, is referred to as real user monitoring [103]. This procedure collects data passively from interacting users. Examples are JavaScript injection for client-side monitoring, client-side agents, and user-centric network observation.

2.7 Implications of Technological Trends

Today’s technologies for client-cloud interaction promote higher-level messaging between clients and services; however, services are often black-box components and cannot be monitored directly by the client [249]. However, according to the LangSec threat model, complete messages need to be observed for accurate monitoring. Observation points on the service, network, and middleware layer are natural choices for observing the exchanged messages, but there are several trends that indicate difficulties for network monitoring, especially for DPI technology. Multiplexing in transport mechanisms between client and service aims to minimize latency in connection establishments when multiple parallel interactions take place, e.g., SPDY and HTTP/2. To monitor multiple parallel message transmissions, sent in a single TCP connection, a DPI system needs to demultiplex and reassemble individual messages. Also, DPI observation of network traffic is restricted to a physical domain, and mobile devices can have multiple active links outside of the monitored physical domain, e.g., 3G/4G networks. Multihoming transport protocols like MPTCP in mobile devices [28] utilize available links for increased service availability, and a DPI monitor has therefore an incomplete view. There is also a trend toward pervasive encryption in transport mechanisms, so network interaction cannot be monitored, e.g., SSL/TLS-secured HTTPS, SPDY, MPTCP, and

40 2.7. IMPLICATIONS OF TECHNOLOGICAL TRENDS

QUIC. A DPI monitor would need to break the encryption, which is hard, or introduce forged X.509 certificates in a man-in-the-middle attack. So far, forging of certificates has worked by compromising or cooperating with a certificate authority. These authorities are usually shipped with client software and implicitly trusted, so issued certificates for services are automatically trusted too. However, there is an increasing distrust in certificate authorities as a consequence of misuse188 cases[ ], and an observed trend is so- called certificate pinning [326]. Additional information like service-specific restrictions on trustworthy certificate authorities or fingerprints of expected public keys in certificates are shipped with clients, so man-in-the-middle attacks by DPI monitors can be detected. Examples are Google Chrome [408] and reverse engineering protections in modern mobile phone apps [324]. Consequently, DPI technology is not future proof for monitoring the language in an actual message exchange. With respect to the proposed security monitor in this thesis, observation points need to be situated in the client or service software or on the middleware layer, e.g., in a message broker or suffix proxy.

41 CHAPTER 2. BACKGROUND: INTERACTION AND MONITORING

42 Chapter 3

Literature Review

This chapter studies the state-of-the-art with respect to the language-based anomaly detection approach. First, anomaly-based intrusion detection is reviewed in Section 3.1, including the language-theoretic view on intrusion detection and resulting evasion methods. The section furthermore investigates related work on anomaly detection for tree-structured data in greater detail. XML and schema languages are introduced in Section 3.2 in a nutshell. XML attacks are the motivation of this research, in particular, the signature wrapping attack, and Section 3.3 therefore summarizes known attacks and limitations in countermeasures. Section 3.4 reviews stream validation as a countermeasure against attacks and introduces the notions visibly pushdown automata for XML. Learning a language representation is related to schema inference, and the state-of-the-art is therefore introduced in Section 3.5. To close the chapter, Section 3.6 presents related work in wrapper inference for information extraction.

3.1 Anomaly-Based Intrusion Detection

Scarfone and Mell [378] define an intrusion detection system (IDS) as a system that monitors another system or network for symptoms or evidence of violated security constraints, i.e., attacks. Intrusion detection capabilities are present in many security products today, e.g., intrusion detection and prevention systems (IDPSs and IPSs), next- generation firewalls, unified threat management appliances, web application firewalls, web and service security gateways, security information and event management (SIEM), sandbox appliances, and breach detection systems. From a historical point of view, IDS types are distinguished according to the location of the monitor into host and network based. Furthermore, a detection technique for intrusion detection is categorized into misuse or anomaly based.

• Misuse-based intrusion detection is also called knowledge-based intrusion detection because observations are matched for patterns or signatures of well-known attacks, e.g., tokens, patterns, and regular expressions.

• Anomaly-based intrusion detection evaluates observations in a reference model of normal behavior, e.g., a finite state machine, stochastic model, or machine learning profile, and an attack is assumed to deviate from the reference model.

Snort [362] is a well-known misuse-based IDS for network monitoring. A Snort attack signature describes a network-based attack using tokens and regular expressions,

43 CHAPTER 3. LITERATURE REVIEW and IP packet payloads, UDP datagrams, or reassembled byte streams in TCP connections are matched. Suricata [316] is an alternative IDS supporting Snort signatures. Bro [337] is a network monitoring framework for event processing and capable of byte stream reassembling in TCP connections, dynamic application protocol detection, and protocol parsing. The framework includes a policy scripting language, so events and actions can be specified by, e.g., pattern matching in protocol fields and payloads. Bro isoften called network-based IDS; however, it is more powerful because the policy language is Turing-complete. For anomaly detection, there are two approaches in finding a reference model: constructing from a specification or learning from previous observations. A learning approach requires some form of training to construct a model, and detection techniques based on a specification are often treated as the independent category of specification-based anomaly detection because no training is required [378]. Misuse- and anomaly-based intrusion detection have different advantages and draw- backs. From a conceptual view, misuse detection accurately identifies already known attacks while the number of false alarms is kept to a minimum; however, it misses attacks that are not yet publicly disclosed (i.e., zero-day attacks) or deliberately evade the detection technique (e.g., targeted attacks). Bilge and Dumitras [55] analyze the prevalence of zero-day attacks in malware, and their results indicate that zero-day attacks have become a frequent threat. While anomaly detection can, in theory, identify zero-day attacks, several problems that challenge the practical applicability arise [392]:

• representativeness and quality of training data

• unstable normality because of system updates and evolution (i.e., concept drift)

• sensitivity to false alarms when training data is incomplete

• the semantic gap whether an anomaly is actually an attack

• understandability of anomalies by a human operator

Nonetheless, the theoretical capability of identifying zero-day attacks is a strong motivator for research in anomaly-based intrusion detection. The first anomaly-based IDS, proposed by Denning [112], has six components, i.e., subjects, objects, audit records, profiles, activity rules, and anomaly records. The behavior of subjects with respect to objects is stored in statistical profiles that are instantiated from predefined templates and automatically updated during runtime according to activity rules. The IDS monitors audit trails of an operating system, matches audit records to profiles, initiates associated activities of matching profiles, and eventually generates anomaly records. Notable surveys on intrusion detection are given by Debar et al. [109], Lazarevic et al. [233], and Scarfone and Mell [378]. Modi et al. [276] provide a more recent survey of intrusion detection techniques in cloud computing that also discusses IDS and IPS architectures for the provider side. Anomaly detection in general is studied by Chandola et al. [84] because identifying deviating observations has many application domains, e.g., credit card fraud detection. An observable instance (i.e., event) in this study has a set of attributes, and events eventually have relationships such as ordering in a time series or graph structured data. Based on relationships between events, the survey distinguishes three types of anomalies: point, contextual, and collective anomaly.

44 3.1. ANOMALY-BASED INTRUSION DETECTION

Techniques for point anomaly detection are classification, nearest neighbor, clustering, statistics, information-theoretical measures, and spectral detection. For contextual and collective anomaly detection, techniques either reduce to a point anomaly detection problem, e.g., by embedding events in a vector space, or utilize structure, e.g., sequence modeling using automata and Markovian techniques. In follow-up research, Chandola et al. [85] focus on techniques for anomaly detection in discrete sequential data. They distinguish three detection scenarios: an anomaly in a sequence, an anomalous subsequence in a sequence, and an anomalous frequency of a pattern in a sequence. Techniques are then reviewed and distinguished into sequence based, e.g., Markovian techniques and hidden Markov models; continuous subsequence based, e.g., window scoring; and pattern based, e.g., substring matching.

3.1.1 Network Layer Anomaly Detection Network anomaly detection focuses on network packets and their payloads, e.g., IP headers, TCP segments, and UDP datagrams. Higher-layer application protocols are not assumed; however, all of the reviewed techniques have been evaluated in a web context. The eBayes TCP [422] system performs specification-based anomaly detection by monitoring network packet headers. The reference model is specified as Bayes network approximation of expected TCP connections, and during operation, this Bayes network is continuously updated. Two notable systems for learning-based anomaly detection in networks are Packet-Header Anomaly Detection (PHAD) [251] and Application-Layer Anomaly Detection (ALAD) [250]. Both systems update nonstationary probabilistic models of predefined network traffic properties, i.e., packet header properties inPHAD and keyword frequencies in packet payloads in ALAD. Zanero and Savaresi [497] present a two-stage approach for learning-based anomaly detection. In the first stage, header data is extracted and an unsupervised self-organizing map (SOM) classifies packet payloads. The second stage then analyzes a sliding temporal window over decoded header data and associated payload classes, and a second SOM approximates inter-packet relationships. Wang and Stolfo [480] introduce the payload-based anomaly detector (PAYL). For a destination port and payload length, PAYL learns a payload profile in terms of a statistical histogram over payload bytes. Mean and standard deviation of a profile then allow identifying anomalous packet payloads. While PAYL models 1-grams of payload bytes, Anagram [479] stores distinct payload n-grams1 in a Bloom filter during training and calculates the ratio of unknown n-grams to total n-grams in an observed packet as an anomaly score. PAYL computes a profile for packets of same length. Bolzoni61 etal.[ ] extend PAYL toward POSEIDON which learns PAYL-like profiles for payload classes instead of packet lengths, where an unsupervised machine learning algorithm performs the classification. McPAD [338] is a multi-classifier system that resorts to an ensemble of one-class Support Vector Machines (SVMs) to increase detection accuracy. Informally, an SVM is a geometric large-margin classifier, where an optimal hyperplane for separating a vector space is learned by maximizing the margin between the two classes of examples. One-class SVMs are particular interesting for anomaly detection because only one class of examples is assumed. In McPad, the one-class SVMs are trained from different vector- space embeddings of training data using various kinds of n-grams. HMMPayl [31] is

1Substrings of length n of a string are referred to as n-grams, .e.g., 2-grams(abcd) = (ab,bc,cd).

45 CHAPTER 3. LITERATURE REVIEW another multi-classifier system that models ordering of payload bytes in multiple hidden Markov models. Network flow monitoring is claimed to be more privacy-friendly than DPI monitoring because only metadata about transport protocol interaction is collected, and Sperotto et al. [399] argue that flow-based detection should be seen complementary to packet inspection. The flow-based anomaly detection approach by Lakhina224 etal.[ ] identifies attacks or failures by observing the distributions of certain network traffic features. Changes in flow entropy can correlate with violating activity, e.g., Wagner and Plattner [475] propose Kolmogorov complexity to detect the spread of Internet worms, Tellenbach et al. [406] investigate a traffic entropy spectrum to generalize entropy metrics, several entropy measures have been evaluated by Nychis et al. [291], and Winter et al. [486] provide an algorithm based on exponential smoothing to detect anomalies in an entropy time series. Sperotto and Pras [398] propose time-series analysis using a hidden Markov model to identify dictionary attacks on Secure Shell (SSH) services.

3.1.2 Operating System Layer Anomaly Detection Audit trail and system call monitoring have a tradition in intrusion detection; however, considerable problems arise when traces from various origins are interleaved, e.g., multi- threaded execution and procedures in linked libraries. With respect to specification-based anomaly detection, Ko et al. [212] present a program policy specification language to formalize security properties of a program, and a Unix tool to monitor audit trails for conformance. Follow-up research extends this approach to distributed systems [213]. Wagner and Dean [476] propose techniques to extract a reference model from program code in terms of a finite-state machine over system calls; however, the bisimulation during runtime is computationally intense and simplifications are necessary. The Janus framework [145] resorts to a kernel module in a Linux operating system for intercepting system calls, querying a policy engine, and eventually blocking of calls. Experiences indicate practical problems, e.g., race conditions, indirect resource paths, incorrect state replication, and unpredictable side effects if a system call is blocked. Forrest et al. [135, 182] present a host-based IDS that learns a reference model for anomaly detection by instrumenting n-grams of system call traces, and follow-up research introduces call delays and blocking [391]. Also, several techniques resort to automaton learning from strace system call traces [260, 387]. VtPath [122] uses a modified operating system kernel to directly monitor the call stack and its return addresses of a process to learn execution paths between program execution points. Mutz et al. [281] further extend the system call monitoring approach by combining multiple types of reference models for increased accuracy and including system call arguments in the models. Other techniques that consider system call arguments are presented by Maggi et al. [247] and Frossi et al. [140]; both learn stochastic models from system call traces as reference models for anomaly detection.

3.1.3 Service, Middleware, and User Layer Anomaly Detection One of the first approaches that highlights the importance of application layer protocol language is the service-specific anomaly detection approach by Kruegel et al. [217]; the proposed system learns protocol-specific distributions of segments of bytes in protocol messages.

46 3.1. ANOMALY-BASED INTRUSION DETECTION

Model-based anomaly detection for web applications, deployed in a web proxy, has been introduced by Kruegel and Vigna [218]. The system observes HTTP interaction and extracts six anomaly detection measures from HTTP headers (e.g., character distribution and attribute lengths) to detect attacks that affect header fields, e.g., in query parameters in a requested URI path. Follow-up research includes inferring attack types using heuristics [361], leveraging concept drift in web applications [248], and querying a knowledge base when training data is scare [360]. Masibty [102] operates as a reverse proxy in front of a web application and additionally monitors SQL database calls performed by the web application. Both headers and content in web requests and responses are analyzed by multiple anomaly detection modules, and Masibty correlates web requests, triggered SQL queries, and web responses to identify violating return values. Kirchner [209] and Krüger et al. [219] present two approaches also operating as a web reverse proxy. Both techniques extract features from web requests and responses, and while Kirchner’s approach resorts to a nearest neighbor technique for anomaly detection, the TocDoc system by Krüger et al. implements an ensemble of anomaly detection techniques and supports automatic healing of web requests. In follow-up research, Krüger et al. [220] resort to vector space methods, i.e., matrix factorization, to automatically extract sections that co-occur in network payloads, and use cases include anomaly detection. Several network-based anomaly detection techniques are strictly tailored for HTTP as application protocol, where web requests and responses are analyzed for anomalies. The proposed technique by Ingham et al. [191] tokenizes request headers and learns a finite automaton as reference model. Spectrogram [395] resorts to multiple Markov chains for analyzing the URI-path structure in an HTTP GET request and payload in an HTTP POST request. Multiple hidden Markov models in HMM-Web [99] analyze the sequential structure of URI paths in web requests. In own previous research [228, 229], we propose analysis of web request URI paths using an online learning variable-order Markov model that continuously adapts to the observed service. Boggs et al. [60] presents a distributed anomaly detection system, where so-called content anomaly detectors are distributed over varying websites to detect wide-spread simultaneous attack activity. Detectors exchange low-confidence identifications for a collaborative decision to increase accuracy and reduce false alarms, and every detector implements an n-grams-based technique from Anagram [479]. For monitoring the internal state of a web application, Cova et al. [100] present Swaddler. The system automatically instruments web application code when executed in the PHP interpreter by inserting monitoring statements, and events are forwarded to an analyzer component that constructs profiles, e.g., for variable values, using various anomaly detection techniques. Xie and Yu [490, 491] propose monitoring of user browsing behavior to protect web applications from distributed Denial-of-Service attacks. Web request headers provide resource descriptions, i.e., URI paths and content types, and references that identify users. The normal browsing behavior of users in terms of sequential resource accesses is then modeled in a hidden semi-Markov model.

3.1.4 Language-Theoretic View on Intrusion Detection The LangSec view [69, 376] explains practical problems encountered in intrusion detection when there is an expressiveness gap between anomaly or misuse detection model and the audit data, e.g., network packets, HTTP requests, protocol messages, and system

47 CHAPTER 3. LITERATURE REVIEW and API call traces. An IDS in fact monitors the language in an interaction or emitted by runtime behavior and decides MEMBERSHIP. The true power of the observed language could be Turing-complete in a worst case (e.g., a JavaScript program), but an IDS needs to decide MEMBERSHIP efficiently. Analysis techniques for intrusion detection are usually language approximations, and the consequences are errors. Figure 3.1 shows the types of errors in anomaly-based intrusion detection. While a true negative refers to an acceptable observation, a true positive identifies an anomalous observation, i.e., non-acceptable inputs. It should be noted that an anomaly is not necessarily an attack. An IDS is an approximation that could be incomplete or overly generous. An acceptable input wrongly classified as anomaly is therefore a false positive or false alarm, and a false negative refers to non-acceptable inputs that are classified as acceptable by the IDS.

Anomaly detection reference model True negative False negative

Violating Acceptable

Explicitly permitted

Possible

False positive True positive

Figure 3.1: Anomaly detection errors in a binary classification setting with respect to the relevant sets of behaviors, states, or inputs (reproduced from [58, p. 357])

As an example, suppose a misuse-based IDS uses regular expressions, i.e., the class of regular languages (REG), to describe attack signatures and matches the signatures on observed content. If the expressiveness of the observed content is more powerful than the IDS technique, e.g., Turing-complete JavaScript, then there could be up to infinitely many ways to rewrite an attack, so no signature matches. This form of detection evasion is also referred to as polymorphic attack [396]. The language-theoretic effects haven been encountered by Hadžiosmanovic´ et al. [172] in an experimental evaluation of anomaly detection techniques for networks, i.e., PAYL, POSEIDON, Anagram, and McPAD. These techniques learn from byte-based n-grams, but n-grams are equivalent to stochastic k-testable languages in a strict sense, and this language class can only model local and short-term language constraints strictly within the regular languages [425]. Furthermore, the assumption of a byte-based alphabet is not always sound. The evaluated scenarios are two binary protocols for Windows RPC and the industrial control system protocol Modbus. Both protocols contain length fields which are in fact self references that indicate high expressiveness [376]. The comparative analysis indicates that none of the detection techniques is capable of high detection rates and low false-alarm rates at the same time. The expressiveness gap between actual language class and n-grams in the LangSec view would explain this problem.

48 3.1. ANOMALY-BASED INTRUSION DETECTION

Wressnegger et al. [488] also investigate n-grams with respect to anomaly detection and classification. Three criteria for audit data, i.e., perturbation, density, and variability, have been developed to decide whether an anomaly detection or classification approach is suitable for a certain application scenario. The criteria reflect language properties and completeness of training data, and several showcase examples indicate that anomaly detection based on n-grams is unreliable, when perturbation is high.

3.1.5 Intrusion Detection Evasion An attacker does not want to be detected by an IDS, and three popular approaches to circumvent detection routines are: exploiting the computational complexity of preprocessing and analysis in a monitor, evading detection, and poisoning of training data in an anomaly-based IDS. If an attacker knows the detection algorithms in place, a high system load in the IDS could be provoked, e.g., Denial-of-Service by exploiting the exponential slowdown of some regular expression implementations [325]. First techniques to circumvent the observation of network-based attacks, especially for DPI monitors, have been presented by Ptacek and Newsham [346]. A network monitor needs to fully model network protocols; however, some characteristics require computation or memory and are ignored for the sake of efficiency. An attacker can exploit incomplete observations, e.g., by deliberate IP fragmentation, small-sized packets from misuse of TCP flow control, bogus packets with reduced IP Time-To-Live that falsify observations, overlapping TCP segments, provoking timeouts, misuse of TCP Urgent Pointer, and content encodings. Some countermeasures are presented by Handley et al. [173], but Niemi et al. [287] summarize the state-of-the-art in network evasion and show that many evasion techniques still work today. Another form of detection evasion is to avoid known attack patterns in misuse-based detection, and examples are polymorphic exploits [396]. Anomaly detection is conceptually capable of detecting polymorphic attacks; however, Wagner and Soto [477] introduce the notion of mimicry attack that mimics inputs in such a way that the observation is classified as normal. For example, PAYL resorts to a histogram-based reference model over bytes in the content, and a mimicry attack called polymorphic blending [131] adds byte padding, so the overall byte distribution is considered normal. Anomaly detection estimates a reference model from training data, but if an attacker is able to modify or influence the training data, future attacks will not deviate fromthe trained model. Tampering with training data is referred to as poisoning [365]. A special poisoning attack for online learning techniques is described by Chan-Tin et al. [83] as frog-boiling attack: the attacker sends explicitly permitted messages to continuously weaken the reference model until the true attack is considered as acceptable. Poisoning and learning under the presence of an adversary has motivated research in adversarial machine learning [36, 187].

3.1.6 Kernel-Based Anomaly Detection in Tree-Structured Data Elements in XML syntactically encode a tree structure, even when the semantic data model is a graph. Recent geometric approaches using kernel methods, in particular, tree kernels, have shown promising results in detecting anomalies in tree-structured data [117, 153, 219, 355, 358, 359].

49 CHAPTER 3. LITERATURE REVIEW

Tree Vector-Space Embedding. By turning an arbitrary structure, i.e., a message, from domain X into a vector, tools from geometry become available for analysis. The n- grams method is popular for embedding strings into a vector space of Σn dimensions by | | counting the occurrences of grams. However, n-grams cannot be applied to tree structures, and Rieck [355] therefore proposes vector-space embeddings for parse trees of network application layer protocol messages. Parse trees are ordered, labeled trees t, where x t are the nodes. A feature map ∈ φ : X RN for vector-space embedding translates a tree into an N-dimensional vector, → and vector values are typically frequencies of particular nodes or subtrees in a tree. The considered nodes and subtrees for counting are defined in a so-called embedding set, and the following three embedding sets have been characterized [355]: • Bag-of-nodes. Nodes in a tree are considered independent symbols, and the embedding set is therefore the set of labeled nodes. Figure 3.2b is an example for the tree from Figure 3.2a. • Selected-subtrees. The embedding set is defined by a selection predicate over node labels that defines the roots of relevant subtrees for counting. The example in Figure 3.2c assumes a selection predicate that holds for symbols b and c. • All-subtrees. If the definition of a selection predicate for restricting the embedding set is impossible, all possible subtrees need to be counted. However, the size of this embedding set can then be huge or infinite, and checking the presence of subtrees in the embedding set becomes computationally expensive. An example is in Figure 3.2d.

⎛1⎞ a(a(b,c),b(c),c) ⎜1⎟ a(a,b,c) ⎜ ⎟ ⎜1⎟ a(b,c) a ⎜ ⎟ ⎜1⎟ b(c) ⎜ ⎟ φ(t) = ⎜.⎟ . ⎜.⎟ . = a b c ⎛ ⎞ ⎛ ⎞ ⎜ ⎟ t 2 a 1 b(c) ⎜2⎟ a ⎜ ⎟ φ(t) = ⎝2⎠ b φ(t) = ⎝2⎠ b ⎝2⎠ b b c c 3 c 3 c 3 c (a) A tree (b) Bag-of-nodes (c) Selected-subtrees (d) All-subtrees

Figure 3.2: Vector space embeddings of a tree [355, 356]

Kernel Function. A kernel κ : X X R is a symmetric, real-valued function × → that defines a pairwise similarity measure of two elements from domain x,y X as ∈ inner product κ(x,y) = ϕ(x),ϕ(y) in feature space F , and ϕ : X F maps domain ⟨ ⟩ → elements into this feature space [383]. Many geometric relationships in the feature space can be expressed purely in terms of a kernel, e.g., norms, angles, and distances. The mapping ϕ and feature map φ are clearly related (ϕ := φ is a valid feature map for a linear kernel), however, ϕ is more general. Any symmetric, positive semi-definite similarity measure function κ : X X R is a kernel, even when mapping ϕ is not explicitly × → specified [259, 355]. Kernel-based learning methods build hypotheses from geometric relationships in a feature space using a kernel function as fundamental operation that can be efficiently

50 3.1. ANOMALY-BASED INTRUSION DETECTION computed. Furthermore, by choosing a nonlinear kernel function, where the inner product is calculated in an higher-dimensional feature space and ϕ is implicit, nonlinear relationships can be learned efficiently. The reader is directed to Schölkopf and Smola[383] for more information. For example, in SVMs for classification, a hyperplane in feature space represents the decision boundary between vector representations of samples. A Support Vector Data Description (SVDD) [405] is a special one-class SVM, where a hypersphere encloses the training examples in feature space, and anomalies are outside the hypersphere. With respect to anomaly detection, kernels are proposed for global and local geometric detection approaches [355, 359].

Tree Kernel. A kernel can be specified for arbitrary structures (i.e., convolution kernels), and first applications with respect to structured data have been parse tree analysis in natural language processing [96]. Intuitively, the number of shared subtrees between two trees is a valid inner product and therefore a similarity measure. However, a naive recursive counting algorithm leads to a runtime exponential in the number of tree nodes. Rieck [355] defines a generic tree kernel as

κ(s,t) = φ(s),φ(t) = ∑ ∑ c(x,y). ⟨ ⟩ x s y t ∈ ∈ Function c is a counting function for a particular embedding, i.e., bag-of-nodes, selected-subtrees, or all-subtrees. To handle the exponential runtime for the selected- subtrees and all-subtrees embedding, a dynamic programming algorithm is proposed [355]. Rieck et al. [356] furthermore introduce the notion of approximate tree kernel for runtime improvement: to avoid counting of all subtrees in the all-subtrees embedding set, an optimization routine precomputes an approximated selection predicate for a selected-subtree embedding that reduces runtime while retaining as much expressiveness as possible.

Global Anomaly Detection. Rieck [355] considers anomaly detection as an unsupervised learning task using two functions: a learning function for calculating a model from normal examples, and a prediction function for assigning labels to samples based on the learned model. An intuitive model for global detection is a hypersphere that encloses the feature vectors of normal training data, and the assumption is that attacks reside outside the hypersphere. Figure 3.3a demonstrates the concept, and there are two approaches for hypersphere-based anomaly detection: center-of-mass and SVDD hypersphere.

Sample Sample

R µ Training examples

(a) Hypersphere in feature space (b) Neighborhoods in feature space

Figure 3.3: Global and local anomaly detection in feature space [359]

51 CHAPTER 3. LITERATURE REVIEW

In the center-of-mass approach, the central vector µ is the average of all training examples. By “kernelizing” the learning and prediction functions, all geometric operations are expressed in terms of kernel operations, and an arbitrary kernel can be chosen. However, if feature map ϕ is implicit (e.g., in a nonlinear kernel), µ cannot be directly calculated, and computing the distance of a sample to the hypothetical center then requires a kernel computation with every example in the training data. The prediction function is then a threshold on the distance of a sample to the center. It should be noted that the hypersphere in the center-of-mass approach is not necessarily optimal. Krueger et al. [219] resort to a center-of-mass approach over byte content n-grams in the content anomaly detector in the TokDoc web application firewall. The SVDD approach considers the learning function as an optimization problem to find the center µ∗ of a volume-minimal hypersphere in feature space. This approach can also be rephrased in terms of kernel operations, so the center becomes implicitly defined by a set of weighted feature vectors in the sphere’s decision boundary, the so-called support vectors. The prediction function is again a threshold on the distance of a sample to the center of the hypersphere. If kernel mapping ϕ is explicit, µ∗ is also explicit, and the distance can be computed straightforwardly. If ϕ is implicit, the distance of a sample necessitates a kernel operation for every support vector. Düssel et al. [117] resort to an SVDD approach for anomaly detection in HTTP interaction.

Local Anomaly Detection. While nonlinear kernel functions enable nonlinear decision boundaries for hypersphere approaches, there is still a global perspective. To consider local perspectives of neighborhoods in feature space, Rieck [355] proposes kernelized variants of the k-nearest neighbors method, in particular, the Gamma and Zeta anomaly scores and prediction based on a score threshold. The Gamma anomaly score [174] of a sample is the mean distance to the k-nearest neighbors in feature space, however, this score is density-dependent and it could be impossible to set a good threshold. The Zeta anomaly score [357, 358] normalizes the Gamma score by the mean inner-clique distance. It should be noted that both Gamma and Zeta scores can be expressed purely in terms of kernel operations, and they do not require an explicit learning phase. However, prediction is computationally more intensive because the sample’s distances to all examples have to be computed using kernel functions. For finding an optimal threshold, a calibration based on cross validation is proposed. Rieck and Laskov [357, 358] and Rieck et al. [359] experimentally evaluate the Zeta anomaly score approach for intrusion detection in network traffic and Voice-over-IP infrastructures respectively.

Active Learning. Both global and local anomaly detection assume an unsupervised learning scenario and require attack-free training data. But attack-free training data is expensive compared to unlabeled data. Görnitz et al. [164, 165] rephrase anomaly-based intrusion detection as active learning task to facilitate expert knowledge. The authors propose an active learning strategy, and the ActiveSVDD model considers both labeled and unlabeled examples for finding an optimal hypersphere. First, an initial hypersphere is computed from unlabeled examples. The active learning strategy then chooses examples that are both near the decision boundary and member of a small cluster of potential anomalies with respect to a k-nearest neighbor graph. An expert is queried to provide labels for the chosen examples, and an improved hypersphere is computed. Several alternations of this procedure are typically necessary until a stable reference model is reached. The approach also supports online learning.

52 3.2. THE EXTENSIBLE MARKUP LANGUAGE

Kernel methods for tree-structured data seem promising; however, it is not clear how well the language properties of XML are captured.

3.1.7 XML Anomaly Detection For anomaly detection in XML, Menahem et al. [257, 258] propose a feature extraction process to translate a training corpus of documents into an unlabeled dataset, so existing machine-learning algorithms can be applied. An XSD schema for the corpus is assumed to be available, and based on XSD element definitions, the feature extraction component maps structured XML documents to flattened fixed-length vectors. Some information is lost in the process, in particular, structural properties. For anomaly detection, the authors then describe a one-class classification approach that estimates multiple univariate models from the translated dataset and calculates an aggregate normality score for testing a sample document. This approach focuses on text content, and the idea is not further pursued in this thesis because a schema is assumed, which is not always the case, and the lossy feature extraction violates language-theoretic properties.

3.2 The Extensible Markup Language

XML [451] is the lingua franca of the Internet and electronic data exchange, and its roots go back to SGML. The syntactic specification of XML covers:

• open- and close tags for element names

• element attribute names

• namespaces for element and attribute names

• allowed characters for text content and attribute values, and entities to denote special characters

• comments

• declaration of DTD element types, attribute lists, entities, and notations

• processing instructions for the parser, e.g., XML version and character encoding in the first line of the document

Syntactically, the tags form a tree structure, but an XML document is logically not necessarily a tree. An example is given in Figure 3.4. With respect to element and attribute content, the XML standard only distinguishes two datatypes for text content: parsed character data (PCDATA) as the default for text content and unparsed character data (CDATA) for attribute values and CDATA blocks. Furthermore, XML allows so-called mixed content for markup language characteristics, i.e., tags are allowed within text content, and the review element in Figure 3.4a is an example. A document is said to be well-matched if there is a single root element and open- and close-tags are correctly nested. Therefore, traversing a document from left to right (i.e., document order) equals a depth-first traversal of the syntactic tree. The XML syntax still allows ambiguities, e.g., there are two ways of expressing an element without content. XML Information Set [442] defines a data model for XML to remove such ambiguities. A

53 CHAPTER 3. LITERATURE REVIEW

movie @year 1968 title 2001: A Space Odyssey 2001:A Space Odyssey director </ title> @nid nm0040 <director nid="nm0040"> S. Kubrick S. Kubrick </ director> review <review> A Agood movie. </ review> em good </ movie> movie. (a) XML document with attributes, data and (b) Tree with data nodes mixed contentFigure 3.4: XML document and it’s tree representation document is said to have an infoset if it is well-formed and all namespace constraints are satisfied.An “ infoset is a logical view of the XML document, rather than the document as stored in a text file”[426, ch. 2].3.2.1 Namespaces Qualified names help to distinguish elements that have the same name but different semantics. To uniquely qualify an element or attribute name in an XML document, a name is associated with a namespace URI, a human-readable string to identify a resource in the web [454]. Namespaces are declared in reserved attributes in the open tag of an element, and the scope of the namespace ranges until the close tag; however, nested elements can freely declare their own namespaces. The XML standard distinguishes default namespace and prefixed namespace, and the following example uses both of them: <?xml version="1.0"?> <movie xmlns="http://my.uri/movies" xmlns:director="http://my.uri/directors" xmlns:crossref="http://my.uri/crossreferences"> <name release="en">2001:A Space Odyssey</ name> <director:name crossref:nid="nm0040">Stanley Kubrick</ director:name> </ movie>The default element namespace is declared in the xmlns attribute, so the qualified name of the first child is the pair (http://my.uri/movies, name). The qualified name of the second child is (http://my.uri/directors, name) because of its prefixed namespace. Attributes are usually considered unqualified, i.e., an attribute is considered part of it’s element’s context and the default namespace does not apply. However, prefixes allow to explicitly declare an attribute from a foreign namespace.3.2.2 Parsing The two most notable parsing models for XML are based on a tree representation in a DOM and a sequential representation of start-element, end-element, and characters events according to the Simple API for XML (SAX) [377]. While SAX implements event handling in callback functions which are pushed by the parser, the Streaming API for XML (StAX) [200] works the other way around and pulls a stream of events from a document. Virtual Token Descriptor (VTD) [492] is another parsing model for XML.54 3.2. THE EXTENSIBLE MARKUP LANGUAGEAccording to Lam et al. [225], an XML document is parsed in three steps which are summarized in Figure 3.5. While character conversion and lexical analysis are unambiguously specified for all parsing models in the XML specification451 [ ], syntactic analysis creates infoset items in the style of a chosen parsing model, e.g., tree-structured DOM nodes or SAX events. Inline DTD declarations are handled in the syntactic parsing step. Infoset items are then made available to the business logic through the parsing model’s API.Business logic Semantic analysis AccessParsing model APIDOM nodes, SAX/StAX events Infoset items Syntactic analysis Schema validation Token sequence Lexical analysis Parsing Character sequence Character conversion Bit sequenceXML document Figure 3.5: XML parsing steps3.2.3 Schema Languages XML is a language family because the standard only characterizes the syntax of documents, but the tree structure of elements and attributes is left unrestricted. A schema is in fact a grammar to characterize a set of XML documents. Schema languages typically operate at the infoset level [426], and there exist several schema languages for XML, e.g., DTD [451], XSD [443], Relax NG [292], and EDTD [223]. The simplest and least expressive schema language is a DTD.Definition 1 (Document Type Definition (DTD)254 [ ]). A DTD is a triple D = (Σ,d,e0), where Σ is a set of elements, production rules d : Σ REG(Σ) map element names to → regular expressions, and e0 is the distinguished start element. The right-hand side of production rules is called content model, and L(D) is the set of documents that satisfy d. Example 1. The following DTD is satisfied by the document in Figure 3.4. Attributes are encoded as special elements, and production rules range over elements Σ = movie, { @year, title, director, @nid, review, em . For readability, production rules map to } ε if not explicitly defined. With e0 = movie, production rules d are defined as movie @year title director review+, ↦→ · · · director @nid, ↦→ review em∗. ↦→55 CHAPTER 3. LITERATURE REVIEWDTD defines the document structure by restricting an element’s content model using a regular expression, and in XML, these production rules can be stated in a DOCTYPE declaration in the preamble of a document. Formally, DTDs correspond to the local tree languages in the definitions by Murata et al.[280]. While a conceptual DTD describes structure, an actual DOCTYPE declaration also necessitates datatypes, i.e., CDATA for attributes and PCDATA for text contents. DTD is simple but has limitations: context- dependent constraints on children of an element cannot be expressed. The industry standard XSD introduces types of elements, so production rules are expressed over types instead of elements to increase expressiveness, and fine-grained datatypes for restricting text content are provided. EDTD, introduced by Papakonstantinou and Vianu [328], is a generalization of XSD with respect to tree structure, and the expressible language class is equivalent to the unranked regular tree languages [286].Definition 2 (Extended DTD (EDTD) [328]). An EDTD is a tuple D = (Σ,M,d,m0, µ), where Σ is a set of elements, M is a set of types, µ : M Σ assigns element names to → types, and D′ = (M,d,m0) is a DTD over types. Function µ is a surjection, so an element name can denote different types depending on its context. A document w satisfies D if there is a typing w′ with w = µ(w′), where element names are mapped to types and w L(D ) holds. The type assignment w is called witness for w, and L(D) denotes all ′ ∈ ′ ′ the documents that satisfy D. An EDTD does not specify element and attribute contents.Example 2. Refining Example1 with types leads to an EDTD with start type m0 = Movie. Again, for readability, production rules d map to ε by default, and others are defined as Movie @MYear MName Director Review+, ↦→ · · · Director @DirId DName Bio, ↦→ · · Review @RYear AName RText, ↦→ · · RText Emph∗. ↦→Mapping µ assigns element names to types and is defined as Movie movie, ↦→ @MYear,@RYear @year, ↦→ MName,DName,AName name, ↦→ Director director, ↦→ Review review, ↦→ @DirId @nid, ↦→ Bio biography, ↦→ Review review, ↦→ RText text, ↦→ Emph em. ↦→Schema Validation and Typing Formally, a schema generates a language, i.e., a set of XML documents, and schema validation of a document becomes a MEMBERSHIP decision problem. Stream validation56 3.2. THE EXTENSIBLE MARKUP LANGUAGE is then to decide membership in a single pass over the document. With respect to EDTDs, validation coincides with type checking. Typing is then to assign every element in a document a unique type from production rules. For example, semantics in the business logic could be specified by assigning procedures to types, so a procedure is called when a type is encountered during parsing. However, EDTDs can be ambiguous because mapping µ is surjective, and two or more types could be assigned to the same element during typing. Ambiguity is a source of nondeterminism, but determinism is required for efficient schema validation and typing. DTD and XSD resort to syntactic restrictions to guarantee deterministic content models. In particular, regular expressions in DTD production rules must be one-unambiguous regular expressions [73]. A regular expression is deterministic, if while traversing the input every next symbol matches at most one symbol in the expression. For example, the expression (a + b)∗a∗c is clearly not deterministic because in the string ac the prefix a matches in two different factors. XSD, also has syntactic determinism restrictions in production rules, in particular, the Element Declarations Consistent (EDC) and Unique Particle Attribution (UPA) constraints [254]. Informally, EDC forbids two elements that share the same name but have different types in the same content model, and UPA requires every regular expression over types to be one-unambiguous when types are replaced by their elements from mapping µ. Relax NG corresponds to regular tree grammars and allows schema ambiguity in general.Schema Expressiveness Syntactic restrictions in schema languages affect expressiveness and consequently schema composability, and effects have been studied by Murata et al. [280] and Martens et al. [254]. First, Relax NG is as expressive as unrestricted EDTD. With respect to XSD, the EDC and UPA constraints guarantee that every type of an element is derivable from ancestor elements only, and because of this single-type restriction, the expressible language class of XSD is EDTDst. Due to this restriction, typing a document in streaming fashion is possible because an element’s type is clear when the open tag is read. However, EDC and UPA are overly strict, and Martens et al. [254] characterize the 1-Pass Preorder Typing (1PPT) property of schemas as a more robust class capable of efficient validation and deterministic typing in a streaming scenario. This property is syntactically enforced in restrained-competition EDTDs (EDTDrc) as defined by Murata et al. [280]. Informally, a production rule restrains competition if the type of an element is determined by its left siblings. The relation between schema languages in terms of expressiveness is therefore DTD ( EDTDst ( EDTDrc ( EDTD.Integrity Constraints So far, the discussed expressiveness of schemas is concerned with syntactic tree structures of infosets. But in reality, the practical schema languages DTD and XSD also enable integrity constraints that raise the expressiveness significantly. DTD, as defined in the XML standard, supports declaration of keys (ID) and key references (IDREF, IDREFS) for attributes. References can be distinguished into sequential references, cyclic references and mixtures thereof. The logical data model of an infoset with integrity constraints is therefore not a tree but a directed acyclic graph or infinite tree in case of cycles, and operations such as queries become computationally harder [489].57 CHAPTER 3. LITERATURE REVIEWFurthermore, XSD introduces additional constraints (unique, key, and keyref ) over text contents, attribute values, and combinations thereof. Checking integrity constraints during schema validation requires significantly more time and space for constructing indices or traversing the data model multiple times, or constraints are not properly checked at all, e.g., stream validation often requires that keys must be declared before referencing them with respect to the document order [24]. It should be stressed that integrity constraints are explicitly defined in a schema, and syntactically, there is no difference between a regular attribute and a reference [451]. Without a schema, there is hardly any evidence in a document about referential semantics of attributes, elements, or text contents. Attributes id and ref are regularly used for ID-based references in standards like XHTML [434], but it cannot be inferred that an attribute ref is universally an ID-based reference to a corresponding id attribute. Key mining in XML is a research field for its own [29].3.2.4 XPathThe XML Path Language (XPath) [432, 456, 474] allows to address nodes in the logical data model of XML using a path notation, and there are three versions of the language continuously extended by functional capabilities for arithmetic and string operations. XPath has a slightly different data model [449] which is based on XML Information Set. It is furthermore the foundation for XPointer [436], document transformation in XQuery [457], and Extensible Stylesheet Language Transformations (XSLT) [450]. The syntax of XPath is designed to be compatible with URIs and PCDATA, so XPath expressions can be embedded as HTTP query part or text. An XPath expression evaluates either to a set of tree nodes, a Boolean truth value, a number, or a string. For example, the node-selecting expression /movie/director applied to the document in Figure 3.4a returns the singleton director element.3.2.5 Syntactic OptimizationsThe text-based document format has information redundancies, e.g., repeated element names in open- and close-tags, and there are several approaches to optimize document representation. For text-based optimization, SXML [210] provides an alternative syntax for XML using more compact S-expressions instead of tags. Another approach is to store the document’s infoset in a compact binary format, e.g, Efficient XML Interchange [470], .NET Binary XML [266], ASN.1-based Fast Infoset [196], and Binary MPEG Format for XML [195]. Transporting binary data in XML text content typically requires a binary-to-text encoding scheme like Base64 to satisfy character constraints in element or attribute content. However, this leads to increased length, and another optimization is XML-binary Optimized Packaging (XOP) [452]. XOP is a multipart container format for XML based on MIME type multipart/related, where the document is the first container part, and binary data are natively embedded as subsequent parts. Elements in the document then refer to these parts using the W3C MIME type extensions [444], and XOP is applied in MTOM for SOAP attachments.58 3.3. XML ATTACKS3.3 XML AttacksMany technologies for client-cloud interaction depend on XML as language for content types and protocols: websites in XHTML or XML-compatible HTML5 [473] markup, selective AJAX updates in a web application, web syndication updates in RSS and Atom, call and return serialization in XML-RPC, all specifications for SOAP/WS-* web services, resource representation in RESTful services, and XMPP messaging. An XML document must therefore have an unambiguous interpretation under language-theoretic security principles. However, processing of XML and its schema languages DTD and XSD can be vulnerable in the various steps of parsing. This section reviews the state-of-the-art in XML attacks with respect to parsing and semantics in the business logic, and countermeasures are argued. A special kind of vulnerability, XML signature wrapping [255], is discussed independently because of the relevance to this thesis. Notable surveys of attacks that focus on XML in SOAP/WS-* web services are given by Jensen et al. [202] and Morgan and Ibrahim [278]. Also, the WS-Attacks website [121] provides a comprehensive repository of web service attack descriptions, and the following summary is based on the stated resources.3.3.1 Parsing AttacksOversized Tokens. A simple Denial-of-Service attack is placing long tokens in an XML document, e.g., large text contents and long attribute values; long element, attribute, and processing instruction names; many attributes in an element or processing instruction; and large comments. The attack aims for resource exhaustion during lexical and syntactic analysis, so processing slows down or fails. Also a large number of elements can cause Denial-of-Service in a DOM parser that needs to allocate memory for every infoset item. Schema validation could mitigate oversized tokens but a schema is still vulnerable to many repeating elements if repetitions are unbounded [202]. The following XML document is an example: <?xml version="1.0" encoding="utf-8"?> <movie veryLongAttrName1="large␣value" veryLongAttrName2="large␣value" ...> <title>Very Long Text Very Long Text ...

Coercive Parsing. Another Denial-of-Service attack is coercive parsing [121]. Syn- tactic analysis typically resorts to a pushdown automaton for processing of nested element tags, and a large amount of nested structures that also declare a large number of namespaces exhaust the pushdown automaton’s stack and namespace data structure. While schema validation can fend of deeply nested structures early during parsing, neither the number of namespace declarations per element nor the length of namespace URIs are bounded in the XML standard [202]. An example looks as follows: ...

59 CHAPTER 3. LITERATURE REVIEW

Entity Expansion Attack. XML parser libraries typically support an inline document type declaration (i.e., DOCTYPE) for specifying a DTD grammar and entities in the preamble of an XML document. An entity is a macro in a document, and it can be declared internal or external. The entity expansion attack, also known as “billion laughs” attack or XML bomb, expands exponentially many internal entities to use up memory and time [121]. Any implementation that supports inline DOCTYPE declarations is potentially vulnerable, and the best countermeasure is to disable inline declarations at all. The following XML document is an example: ... ]> &x100;

External Entities. Another vulnerability that arises from inline DOCTYPE declarations is resource inclusion through external entities [121]. An external entity can refer to a URL, including local file systems, and syntactic analysis retrieves the resource during parsing if the feature is not explicitly disabled in the parser. Again, the best defense is to disable inline entity declarations. The following example is a message sent to an XML-processing service that updates a database. Instead of a name, the service retrieves the name value from a local file, stores it in the database, and the file contents are revealed when the attacker queries the database: ]> 1000 &file;

Server-Side Request Forgery. Depending on the parser implementation, various URI schemes are directly supported for external entity retrieval in the parser, including HTTP GET operations. A knowledgeable attacker can therefore invoke URLs, e.g., an HTTP- based attack, originating from the service while the attacker stays hidden to the victim. This attack is also referred to as server-side request forgery (SSRF), and instead of external entities, the following example uses the DOCTYPE declaration to call an internal web service [278]: Morgan and Ibrahim [278] furthermore discuss an SSRF attack that exploits namespace declarations in XML elements. In an element, the attributes xsi:schemaLocation and xsi:noNamespaceSchemaLocation are hints for the parser, where the schema for a certain namespace or default namespace can be found, and an SSRF attack would be triggered. However, the parser needs to explicitly support the feature of automatic schema retrieval, and strict schema validation is a countermeasure by restricting attributes. An example looks as follows:

60 3.3. XML ATTACKS

3.3.2 Semantic Attacks Business logic accesses a document’s infoset items by, e.g., handling a stream of SAX/S- tAX events or walking over tree nodes in a DOM. Moreover, XPath expressions can select a set of nodes in the tree representation. The fundamental idea of a semantic attack is to modify the infoset and its text contents, so the target’s business logic accesses and processes violating data that leads to violating behavior by the program, its software components, or other contacted services.

CDATA Field Exploitation. A generalized approach to exclude character data from further parsing in a document is a CDATA field428 [ ]. XML strictly specifies the allowed characters in text content; however, CDATA allows a much larger character set. Lexical analysis considers a CDATA block as a single token and only strips the CDATA brackets. It is the foundation for many other attacks. CDATA allows to store XML fragments in text content without creating infoset items, and a potential application is XML injection, e.g., when an XML-based message is exchanged, parsed, and serialized by several services, so at some location, a CDATA block could become valid XML. Strict schema validation in a service detects violating structures and text contents.

XML Injection. Consider a service, where a user provides some value for an operation, and the service composes an XML message to call a second service, where the user-provided value and fixed parameters are arguments. The business logic ofthe second service then resorts to XPath expressions to select nodes from the message. If the user-provided value is unfiltered XML, an attacker could inject a fragment that changes semantics of the message, e.g., the user-provided value in following document creates additional infoset items when parsed by the second service: value< p2>maliciousValue< p1>value fixedValue

In this case, the XPath expression //p2[1] returns the first node, where the element name matches p2. The fixedValue is acceptable; however, the injected XML fragment matches the query before. Injecting XML fragments into a document can affect XPath access and even affect state in SAX parsers if tree contexts are not handled correctly [121]. Schema validation is a countermeasure.

Attacks in Text Content. The business logic often involves other software components and services, and an inconsistent datatype could lead to violating behavior. Exam- ples are: path traversal in file systems, when text is interpreted as file system path;

61 CHAPTER 3. LITERATURE REVIEW injection of XPath, Structured Query Language (SQL), Lightweight Directory Access Pro- tocol (LDAP), and command fragments; memory corruption to manipulate control or data flow in the business logic or one of its components; and cross-site request forgery (XSRF) and cross-site scripting (XSS) with respect to web applications [428, 206, 202]. The following document demonstrates a command injection. In the example, the business logic assembles a Unix shell command by concatenating an internal command template with the value of param, and a knowledgeable attacker can therefore inject arbitrary Unix commands: 7313

CDATA fields enable various injection attacks, e.g., the following document hides JavaScript code, encapsulated by a script tag, in text content. When the value is accessed by the business logic and stored as text in a database, the CDATA fields are stripped. If the database value is reused in a web application, an accessing web client executes this JavaScript code: script]]> alert(’This is JavaScript code’) /script]]>

3.3.3 Schema Extensibility and Effects on Validation Attacks in inline DTD in a document can be prevented by disabling inline DTD support in the parser. Strict schema validation, including datatype checking for text content, can further mitigate parsing and semantic attacks because wrong interpretation by the business logic is minimized. XSD is the industry standard and designed to be extensible. There are two philoso- phies of code reuse and modularity: schema subtyping by reusing complex types, type extensions and restrictions, and substitution groups [242, 243]; and schema extension points for loose coupling based on xs:any. While schema subtyping shares similarities with classes in object-oriented programming, a schema extension point is similar to a wildcard for any kind of infoset item in a document. In case of schema subtyping, validation of a document is unchanged; however, a schema extension point permits any nested element at the particular location in documents and therefore introduces a potential vulnerability. The schema fragment in Figure 3.6 is from the SOAP specification447 [ ] and demonstrates extension points. SOAP defines types for envelope, body, and header of a SOAP message. Nested elements are not further specified by placing xs:any elements as extension points in the schema. According to the XSD specification, the processContents="lax" attribute has a tremendous effect on schema validation: If the item has a uniquely determined declaration available, it must be -valid- with respect to that declaration, that is, -validate- if you can, don’t worry if you can’t [443]. In other words, the uniquely determined declaration refers to an XSD schema associated

62 3.3. XML ATTACKS with an element’s namespace. This schema is either already present in the parser’s environment or dynamically retrieved from a schema location. In case of an error, e.g., unknown namespace or failed schema retrieval, schema validation skips the element. As a consequence, a knowledgeable attacker can place arbitrary content in a document, even when schema validation is activated, if a schema has extension points with the processContents="lax" attribute.

...

Figure 3.6: Schema extension points in the SOAP XSD schema

SOAP and XMPP are two relevant XML-based protocols in today’s client-cloud interaction technologies, and they rely on schemas that have extension points. Even XSD best practices refer to the any element wildcard for flexibility by arguing that it is better to err on the side of too many wildcards than too few [400]. Schema extension points can easily emerge by accident because in XSD, the default element type is anyType if not explicitly specified. A schema extension point turns a validating XML parser vulnerable to many parsing and semantic attacks. Furthermore, schemas are not always available for validation, e.g., RESTful web services, and AJAX web applications support XML as resource format but do not enforce the presence of a schema. In 2010, the general problem of ad hoc XML document design has been studied by Grijzenhout and Marx [169]. To understand the quality of XML data in the web, the authors gathered a large XML corpus for analysis, where 85.4% are shown to be well-formed. Only 25% of the documents refer to a DTD or XSD schema, and only 8.9% of all documents are actually valid. The study however focuses on XML that can be retrieved from the web, including XHTML websites, and the results do not translate to SOAP/WS-* web services, where all protocols are specified in XSD.

3.3.4 XML Signature Wrapping Attack The XML signature wrapping attack [255], also referred to as XML rewriting attack, is a semantic attack. The fundamental problem is that signature verification is treated as an independent Boolean decision over a document, and the business logic is not prevented from reading an unchecked element. Moreover, the XML signature wrapping attack exploits schema extension points, so validating parsers cannot reject the attack.

63 CHAPTER 3. LITERATURE REVIEW

XML Signature XML Signature [453] is a W3C digital signature standard for integrity, message authentication, and signer authentication in XML. Figure 3.7 shows the informal XML structure of a signature according to the standard. A ds:Signature has a parameter structure to be signed (ds:SignedInfo), a signature value that verifies the parameter structure (ds:SignatureValue), optional information about the signer and his cryptographic keys (ds:KeyInfo), and eventually some referenced elements (ds:Object). The parameters of a signature define how to canonicalize XMLds:CanonicalizationMethod ( ) to get an unambiguous text representation for calculating the signature and hash values, the cryptographic method (ds:SignatureMethod), and the referenced elements (ds:Reference). Every ds:Reference locates an element using its URI attribute and has specific preprocessing operationsds:Transforms ( ), e.g., XPath transform. The ds:DigestMethod defines the hashing algorithm to be applied on the transformed referenced element, and ds:DigestValue stores the hash value.

( ()? )+ ()? (