# Presentation: 079434

## XML Security Threat Analysis

**Christopher J. “Kit” Lueder**
**E-mail: kit@mitre.org  **
**Phone: 703-883-5205**
**January 8, 2002**
**DRAFT -- Work In Progress**
**© 2001 The MITRE Corporation. All Rights Reserved**

**Notes:**
This is a high-level briefing "XML Security Threat Analysis" (draft) to identify potential treats or vulnerability areas pertaining to the deployment of XML-based technologies. 
This is the first step of the security analysis, since you can't defend against attacks that you don't anticipate in advance.
The family of XML-related specifications is listed, along with specific XML security-related specifications. General categories of XML-related threats are listed, and then security implications of specific technologies is discussed: SOAP, Firewalls, Registry/Repository, Embedded Code. Finally, areas for further investigation are identified.

## XML Security Analysis Outline

- Family of XML-related specifications
- Security-related specifications for XML
- Categories of XML-related threats
- Discussion of specific technologies
- SOAP
- Firewalls
- Registry/Repository
- Embedded Code
- Areas for further investigation

## Broad scope of XML Standards/Protocols

- Extensible Markup Language (XML)
- Schema specifications
- Document Type Definition (DTD)
- XML Schema Definition (XSD)
- Microsoft XML Data Reduced (XDR)
- Extensions to XML
- XML Name Space (NS)
- XML Linking Language (XLink)
- XML Pointer Language (XPointer)
- XML Path Language (XPath)

## XML Document Processing Specifications

- Extensible Style Language Transformations (XSLT)
- XML Query Language (XQL)
- Document Object Model (DOM) API
- Simple API for XML (SAX)
- Java DOM (JDOM) API (JSR 102)
- [And various vendors’ XML parsing products (MSXML)]

**Notes:**
Java Document Object Model (JDOM) will become part of Java specification(JSR 102)

## XML Web/Repository Specifications

- Web Services Description Language (WSDL)
- Web Interface Definition Language (WIDL)
- Web Services Flow Language (WSFL)
- Universal Description, Discovery, Integration (UDDI)
- Resource Description Framework (RDF)
- Cascading Style Sheets (CSS)
- Java support
- Java Specification Request JSR-110: Java APIs for WSDL
- JSR-93: Java API for XML Registries 1.0 (JAXR)

## XML Exchange Specifications

- Wireless Application Protocol (WAP)
- Wireless Markup Language (WML)
- XML Middleware
- Simple Object Access Protocol (SOAP) v1.1
- SOAP Message With Attachments (SWA)
- Electronic Business XML (ebXML) Message Service Specification (MSS)
- Blocks Extensible Exchange Protocol Core (BEEP), RFCs 3080 & 3081
- SOAP v1.2 [Future]
- Java support
- JSR-101: Java APIs for XML RPC
- JSR-82: Java APIs for Bluetooth

## XML Format-Specific Specifications

- XML versions of X12, UN/EDIFACT, HL7 EDI
- Portable Network Graphics (PNG)
- Scalable Vector Graphics (SVG)
- Synchronized Multimedia Integration Lang. (SMIL)
- VoiceXML
- Directory Services Markup Language (DSML)
- Structured Query Language (SQL) specifications
- Oracle XML SQL (XSQL)
- SQL Extract Query Language (SXQL)
- XML for Microsoft SQL Server in .NET (XMLSQL)
- Thousand specific vertical-market definitions

**Notes:**
Vertical-market definitions are registered at Biztalk.org, Oasis.org

## Security-Specific XMLStandards/Implementations

- XML Signature Syntax and Processing (XMLDsig)
- Signature at element or document level
- XML Encryption Syntax and Processing
- Encryption at element or document level
- Platform for Privacy Preferences Project (P3P)
- XML Key Management (XKMS), for interface to PKI
- BEEP security mechanisms [Future]
- Java XML security processing APIs not standard yet:
- JSR-104: XML Trust Service APIs
- JSR-105: XML Digital Signature APIs
- JSR-106: XML Digital Encryption APIs

## Security-Specific XMLStandards/Impl. (contd)

- OASIS Security Assertion Markup Language (SAML)
- XML Access Control Markup Lang. (IBM AlphaWorks)
- Digital signature extensions to SOAP
- XML Canonicalization (consistent XML doc rendition)
- DOMHASH algorithm (hash/signature processing)
- XML-specific compression mechanisms (XMill)
- Intelligence Community Markup Language (ICML),a security DTD (ICML-SM), based on CAPCO specs.
- UDDI v3 security support [Future--March 2002]
- XML Schemas also provide some document integrity

**Notes:**

SAML replaces: AuthXML authentication & Security Services Markup Language (S2ML)
"Controlled Access Program Coordination Office” (CAPCO)

## Use of OtherSecurity Mechanisms

- Secure Socket Layer (SSL), Secure HTTP (HTTP/S), Transport Layer Security (TLS), RFC 2246
- Secure MIME e-mail (S/MIME)
- EDI-INT (S/MIME or PGP/MIME with signed receipt)
- PKI, Virtual Private Network (VPN)
- Kerberos authentication, RFC 1510
- Simple Auth. and Security Layer (SASL), RFC 2222
- Operating system security, access controls
- Security toolkits (e.g., RSA CertJ, SSLJ and JSAFE)
- Java support
- Java general security
- Cryptography Extension (JCE)
- Java Authentication and Authorization Service (JAAS)

## Categories of XML-related threats

- New technology
- XML-related standards immature from security perspective
- Implementation catch up with standards; s/w version control
- New tools/products need to be debugged
- Pervasive use of XML inside application software suites
- New supporting technologies (Microsoft .NET, C# language, Common Language Runtime (CLR), J# Java for .NET)
- Best practices, evolving architectures, not fully worked out
- Open-source software, internals are visible to hackers
- New services
- XML-encoded real-time web services, listed in registry
- SOAP RPC calls over HTTP network (SOAP proxy server?)
- New mechanisms for old technology
- Embed SQL query inside XML (SXQL, XSQL, XMLSQL)
- Excel Spreadsheet dynamic import of external XML data
- Many standards & APIs, new manipulation capabilities

**Notes:**
XMLSQL: Support for XML embedded within Microsoft SQL Server in .NET architecture

## Categories of XML-related threats (contd)

- Interoperability concerns
- Transition from DTD to XML Schema, Microsoft XDR
- DTD has weak validation, Schema can enforce stronger validation
- Version control issues in XML or schema documents, Deprecation of old registered XML objects
- Browser interoperability: Netscape vs. MS Internet Explorer
- Architectures: ebXML, Rosettanet, Biztalk/.Net, cXML, xCBL
- .NET, C#, XLANG not available for Unix platform
- ebXML standardizes the architecture, not document format
- No reference implementation, just specification documents
- Different registries (ebXML, UDDI, DoD SHADE, MS .NET)
- Different XML vertical specs, separately designed
- Oasis.org, Biztalk.org repositories
- Core component element definitions still in progress
- XML Namespace reference can point to real Internet resource, which may not be accessible
- Interoperation with old s/w lacking XML support

**Notes:**
UDDI registry useful for public repository for source discovery
ebXML registry useful for private repository for interface discovery and application integration

## Categories of XML-related threats (contd)

- Disclosure/visibility concerns
- Publish document content structure in schema documents
- XML content can be searched, indexed, aggregated
- Microsoft Discovery of Web Services (DISCO), .NET
- Discover web services/features provided by a particular host or IP address (similar to ping probes)
- Legal concerns
- Legal meaning of signature
- Integrity of certificate, binding to specific user
- Definition of electronic contract
- Archiving, integrity requirement for long-term archive
- Stylesheet (XSLT) changes the visible content to the user

## Categories of XML-related threats (contd)

- Reliance on Schema documents
- Risk of central schema/DTD files being hacked/corrupted
- Trust organization providing/storing schema/DTD files
- Extensible Content Model, validate XML using different schema files
- Changed default values, added mandatory elements/attributes
- Entity definitions (e.g., “&amp;”) can be substituted, to insert other text into XML document
- Synchronization of schema files copied to several systems
- Denial of Service (DOS) attack
- E.g., schema files or server unavailable during XML processing
- Inheritance of properties/objects from other documents
- Schema can have application-specific instructions (appinfo)
- Change namespace URI changes validation of document

## Categories of XML-related threats (contd)

- Hyper-linking concerns
- Security mechanisms bypassed by linked data
- Signed document content/meaning changes if linked data changes
- Data sharing vs. validation of data and its sources
- Data’s significance depends upon its context & source domain
- Handling of broken hyper-links
- Parsing vulnerabilities if errors in XML document
- Malformed documents will not parse at all; can’t parse the portion above the error
- XML is text-based, prohibits special characters or binary content inside XML data (must escape or base-64 encode)

## Categories of XML-related threats (contd)

- Plus, same threats, security requirements as before
- Spoofing a valid user
- Data aggregation risk
- Denial of Service (DOS) (malicious attacks or accidental)
- Wireless low-bandwidth devices may be vulnerable to DOS
- Software bugs (OS, messaging, web/portal systems)
- Buffer overflow for unvalidated XML requests
- Standardization (common methods = common attacks)
- Internet anonymity
- Connectionless network communications
- Anonymous Internet access
- Attacks from innocent third parties
- Reliance on commercial companies for security services:
-  Microsoft Passport/HailStorm, Verisign, Entrust, RSA, ...
- Privacy concerns: potential to track/monitor Internet users

## Categories of XML-related threats (contd)

- Potential for web-based attacks using XML content
- May resemble current HTML malicious code attacks
- Malicious text may be carried within valid XML element tags
- Unicode text attacks hard to filter, infinite encoding options
- No XML-specific attacks publicly identified yet
- Oracle9iAS Web Cache
- Buffer-overflow vulnerability includes web XML port  (CERT Advisory CA-2001-29)
- Microsoft Internet Information Services (IIS) 5.0
- MS IIS Unicode text exploit  (Vulnerability Note VU111677)

## Specific technologies:SOAP

- SOAP Introduction
- Core part of ebXML, .Net/Biztalk Framework
- XML message eBusiness exchange, Internet RPC
- HTTP, HTTP/S: share TCP/IP ports with web service
- Uses Http Get or Post to submit SOAP Request, Http Response for optional SOAP Response.
- SOAP is currently stateless (no sessions, cookies)
- Can use other transports: SMTP, S/MIME
- SWA can carry any arbitrary content as an attachment
- SOAP can apply to other technologies (e.g., CORBA ORB)
- SOAP software status
- Open source toolkits somewhat mature for server-side
- Client-side toolkits immature
- Limited proxy server support
- Incompatibilities: Apache & MS SOAP “BigDecimal” data type differ,vendor-specific proprietary extensions

**Notes:**
SOAP uses HTTP to define headers for remote procedure calls (commands), and XML to define payloads.
CORBA ORB: Object Request Broker

## Specific technologies:SOAP (contd)

- SOAP Processing
- SOAP server maps SOAP commands to enterprise services
- Undefined services not available via SOAP
- “MustUnderstand” flag in SOAP header, fail if unrecognized
- Don’t directly execute SOAP commands (e.g., “delete *.*”)
- Don’t pass SQL commands; parse and check variables before submitting to RDBMS
- Can provide anonymous access from any client
- Risk of replay of a previously sent (signed) SOAP message
- SOAP Fault element for error report may advertise problems
- Standard tags: faultcode, faultstring, faultactor, detail
- Risk of future hidden, embedded and backdoor SOAP
- SOAP Security
- Server SSL certificate can be used for confidentiality
- Client SSL cert. can provide access control of SOAP client
- Ongoing W3C SOAP security efforts (digital signature)

**Notes:**
SOAP does not provide encryption, authentication, type safety, versioning, co-routines, message grouping, call-by-reference, or complex operations on objects.  Because it does not assume object-orientedness, SOAP is easy to use for small and simple servers, like sensor devices, and server languages, like PHP. 

## Specific technologies:Firewalls

- General firewall considerations
- Don’t currently parse or filter XML embedded data
- HTTP Headers Extension (M-POST) mandates headers be recognized and understood before processing the request
- Proxy servers can act as a point of failure, or add processing delays (depending on server loading)
- Can deploy a web server on DMZ that receives XML, parses and validates it, and forwards allowable content to Intranet

## Specific technologies:Firewalls (contd)

- SOAP-specific firewall considerations
- May be open to SOAP Http Get traffic
- Usually block SOAP Http Post on inbound traffic
- Recognize SOAP messages by their Content-Type: text/xml
- Can filter based on the interface and method name exposed via Http header (e.g., SoapAction: “some-uri” header)
- HTTP Headers Extension (M-POST) mandates headers be recognized and understood before processing the request
- Firewalls (Raptor) may strip content of SOAP response
- Greater SOAP filtering capability should evolve in firewalls
- E.g., process SOAP manifest field (describes SOAP contents)
- SOAP 1.2 will use MIME type application/soap or /soap+xml
- But SOAP security (S/MIME) may hide content from firewall
- .Net Remoting: .Net systems exchange across firewall

## Specific technologies:Registry/Repository

- Repository stores registered objects
- Registry contains metadata about registered objects
- Public visibility of services provided
- Common access methods (UDDI binding template)
- Discovery/retrieval of services, XML documents
- Information model (syntax & semantics)
- Supported interfaces for access
- Interoperability/conformance tests
- WSDL port, port type, binding, data message & type
- Different user access controls & rights
- Content owner; Registry administrator; Registry guest
- Several competing/diverging registry efforts/services
- Trust relationship between different or distributed registries

## Specific technologies:Embedded Code

- Mobile code intermixed with XML data content
- Java Server Page (JSP): Java code embedded within:
- XML, HTML, XSLT documents (e.g., using JSP custom tags)
- Tags used to insert code into a page: <SCRIPT>, <OBJECT>, <APPLET>, <EMBED>
- Special strings may be used in command hacking attempts:“|” (Unix pipe), “%00” (Unix null), “%20” (space), “<?” (PHP), “;” (command separator), “.” “..” “...” (Unix change directory),“>” “<“ (Unix input/output redirection), “`” (Perl command), “/bin/ls” (Unix ls, or other commands)
- SXQL, SQL commands embedded within XML RPC
- XHTML (web page with XML content)
- Execute on server, take on access rights of server?
- Risk of quick, hand-coded parsers having ASP-type weaknesses with JavaScript

## Areas for Further Investigation

- SOAP
- Firewall requirements/functionality for content-specific filtering of SOAP Http, SMTP, or S/MIME messages
- Filtering of compressed/encrypted messages, Unicode text
- Implementation of SOAP Proxy server
- DOS vulnerabilities (SOAP flood consumes resources)
- Access control, integrity
- XLink/XPointer document hyperlink references
- Denial of service concerns
- If no access to Schema files, DOS on XML validation
- If registry-based service, DOS attack on registry
- Embedded code methods (analogous to CGI attacks)
- Microsoft .NET potential security vulnerabilities
- Passport service (reuse persistent cookies to spoof user?)
- C# & CLR security capabilities, robustness, acceptability

## Thank You

- Please send comments or suggestions to:
- Kit Lueder
- E-mail: kit@mitre.org
- Phone: 703-883-5205
- Address: The MITRE Corporation, 7515 Colshire Dr., Mailstop W658, McLean, VA 22102-7508