Upload
dylan-powell
View
220
Download
0
Tags:
Embed Size (px)
Citation preview
T-110.455 Network Application Frameworks and XML
XML Security Basics
30.3.2005
Sasu Tarkoma
Based on slides by Pekka Nikander
Contents
High-level view to WS security WS Application level security Standardization landscape Basic XML security Summary
Topics are continued in the next lecture
Need for XML security
XML document can be encrypted using SSL or IPSec this cannot handle the different parts of the
document documents may be routed hop-by-hop different entities must process different parts of the
document SSL/TLS/IPSec provide message integrity and
privacy only when the message is in transit We also need to encrypt and authenticate the
document in arbitrary sequences and to involve multiple parties
High-level view to WS security
Security is as strong as the weakest link The options for an attacker are:
Attack the Web Service directly Using ”unexpected” XML
Attack the Web Services platform Attack a WS security tool Attack the underlying operating system or
network connection Let’s have examples from different
security functions’ point of view and highlight key specifications
Authentication I
End-users authenticate (their identity is verified) using username/password, SecurID or such, or biometrics End-users do not send SOAP messages
Authentication for SOAP means authenticating the sender Authentication of an application, not a person
Client-side SSL, when HTTP is used Digital certificates and signatures in
SOAP messages Core specification: XML Signature
Authentication II
SAML (Security Assertion Markup Language) A XML-based framework (schemas) for the
exchange of authentication and authorization information
Mainly for integration, up to relying parties to decide to what authentication authority to trust
Assertions can convey information about authentication acts performed by subjects, attributes of subjects, and authorization decisions about whether subjects are allowed to access certain resources
Authentication statements merely describe acts of authentication that happened previously
SAML & WS-Security allow a SOAP message to include information about the end-user’s authentication status
Authorization
Once the sender or end-user is authenticated, are they allowed to access the resource which they are requesting?
XACML (XML Access Control Markup Language) defines how to represent access control rules in XML
WS-Policy defines web service policies (algorithms, tokens, privacy requirements, encodings,..) between senders and receivers Also other policies, declarative & conditional
assertions SAML (Security Assertion Markup Language) Existing tools for authorization to websites
Distinguish resources as URLs A single URL can contain many Web Services
Integrity
Has this message been tampered with? Checksums, digital signatures PKCS#7 signature
Predates XML, ASN.1 binary format How to sign only parts of a document (of a
tree)? XML Signature
Has the system been tampered with? Intrusion detection Tamper control
Confidentiality
Can the message be read while in transit? Transport (or below) level security: HTTPS,
IPSEC Message-level security: XML Encryption, WS-
Security Can the message be read while it is stored?
XML Database security Access control
Is the data private? Gated access to private data Audit trails of access
Audit
Are transactions stored? Does the storage alter the format? (e.g.
splitting an XML message into elements in order to store it into a database)
Is reporting available? Who can run / access the reports?
Availability
Preventing denial-of-service attacks Blocking unwanted message ”storms”
Use of load-balancers For XML communication platforms For XML Gateways / Firewalls
Design of underlying protocols
Administration
Ease of setting up security policies Ability to inherit from a pre-existing policy Ability to ”push” security policy to
multiple Web Services, and Web Services platforms
Possibility of exporting a policy, and importing it into a different system Plain text, SQL, XACML
XKMS (XML Key Management) PKI for XML-based security
Non-repudiation
Preventing users (and services) from denying a transaction occurred
Requires a combination of the security requirements which we have seen so far
Notoriously difficult to implement
Lecture outline
High-level view to WS Security WS Application-level security
Standardization landscape Basic XML security Summary
Web Application Security
Application layer security has existed long before SOAP
Application layer security for Web servers involves securing both the Web server itself, and Web applications which use the Web server as their platform
Focus on attacks on Web applications rather than the platforms on which the Web applications run Remember various CGI application attacks
These attacks are specific to individual Web applications
When bound to HTTP, SOAP itself can be seen as a Web application – albeit a more formalized one
Example – SQL Injection
SOAP Book Lookup Message
Firewall
<SOAP-ENV:Envelope xmlns:SOAP-ENV=”..”><SOAP-ENV:Header><SOAP-ENV:Header><SOAP-ENV:Body><BookLookup:searchByISBN xmlns:Booklookup=”..”><BookLookup:ISBN>1234567810</BookLookup:ISBN></BookLookup:searchByISBN></SOAP-ENV:Body></SOAP-ENV:Envelope>
VB.NET code:Set myRecordset = myConnection.execute(”SELECT * FROM myBooksTable WHERE ISBN=”’” & ISBN_Element_Text & ”’”)
BecomesSELECT * FROM myBooksTable WHERE ISBN = ’1234567810’
IISSOAPstack
ASP .NET SQL server
Windows Server 2003
SQL
Attack: SQL InjectionSOAP Book Lookup Message
Firewall
<SOAP-ENV:Envelope xmlns:SOAP-ENV=”..”><SOAP-ENV:Header><SOAP-ENV:Header><SOAP-ENV:Body><BookLookup:searchByISBN xmlns:Booklookup=”..”><BookLookup:ISBN>’; exec master..xp_cmdshell ’net user Joe pass /ADD’;--</BookLookup:ISBN></BookLookup:searchByISBN></SOAP-ENV:Body></SOAP-ENV:Envelope>
VB.NET code:Set myRecordset = myConnection.execute(”SELECT * FROM myBooksTable WHERE ISBN=”’” & ISBN_Element_Text & ”’”)
BecomesSELECT * FROM myBooksTable WHERE ISBN = ’’; exec master..xp_cmdshell ’net user Joe pass /ADD ’;—
IISSOAPstack
ASP .NET SQL server
Windows Server 2003
SQL
Solution
SOAP Book Lookup Message
Firewall
IISSOAPstack
ASP .NET SQL server
Windows Server 2003
SQL
Ensure the format of incoming SOAP parameters<simpleType name=”isbn”><restrictions base=”string”><pattern value=”[0-9]{10}”/></restriction></simpleType>
Validate this Schema against the data isolated by the following XPath expression:/Body/BookLookup:searchByISBN/BookLookup:ISBN
1234567810 passes’exec master..xp_cmdshell ’net user Joe pass /ADD’-- fails
XML Schema Solution
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace = "https://www.books.com/Lookup" xmlns="https://www.books.com/Lookup" elementFormDefault="qualified"> <simpleType name="isbn"> <restriction base="string"> <pattern value="[0-9]{10}"/> </restriction> </simpleType></xsd:schema>
Content Inspection of XML
Integrity Check integrity of data using XML Signature, WS-
Security Schema Validation
Verify request structure against XML Schema Content Validation
Check content matches criteria specified in an XPath expression
Schemas can be used to specify part of the content (for example ISBN) but they have limits XPath is more expressive Schema validation may always be applied to Body
of SOAP msgs (rpc/literal vs. document/literal)
Application-layer Security
Identity-based security Authentication and authorization information
shared across security domains Content-based security
Protecting against buffer overflow and CGI-like attacks
Must have knowledge about the applications to which these messages are directed
Accountability or non-repudation Need message level security Maintain integrity, archived audit trails
The standards and specifications mentioned earlier address these issues
Lecture outline
High-level view to WS Security WS Application-level security
Standardization landscape Basic XML security Summary
Standardization landscape
Who are specifying the basic standards? Who are specifying the higher level
standards? Who is implementing the standards?
Who are specifying the standards?
Joint IETF/W3C XML Signature (www.w3.org/Signature)
W3C XML Encryption (www.w3.org/Encryption/2001) XML Key Management (XKMS) (www.w3.org/2001/XKMS)
OASIS WS-Security
SOAP Message Security specification etc. SAML: Security Assertion Markup Language XACML: Extensible Access Control Markup language Electronic Business XML (ebXML) (with UN/CEFACT)
Web Services Interoperability Organization (WS-I) Basic security
Standardization Groups
XML EncryptionXML Encryption
XML SignatureXML Signature XKMSXKMS
XrMLXrML
WS-SecurityWS-Security
ProvisioningProvisioning
BiometricsBiometrics
XACMLXACMLSAMLSAML
W3C OASIS
Security Assertion Markup language
XML Common Biometric Format (XCBF)
Extensible Rights Markup Language
eXtensible Access Control Markup Language (XACML)XML Key Management
Specification
Standardization Groups
XML EncryptionXML Encryption
XML SignatureXML Signature XKMSXKMS
XrMLXrML
WS-SecurityWS-Security
ProvisioningProvisioning
BiometricsBiometrics
XACMLXACMLSAMLSAML
W3C OASIS
XML Signature XML Encryption
Kerberos profile
XrML profile
X.509profile
XCBF profile
Username profile
SAML profile
WS-SecureConversation
WS-Federation WS-Authoriz.
WS-SecurityPolicy
WS-Trust WS-Privacy
WS-Security (framework)
Who are specifying the higher level standards?
Liberty Alliance Identity-based specifications (single sign-on,
identity federation) Specifications build on SAML, SOAP, WAP, and
XML. Microsoft (Passport,..) Open Mobile Alliance (OMA) Object Management Group (OMG) European Telecommunications Standards
Institute (www.etsi.org) Organization for the Advancement of Structured
Information Standards (OASIS) (www.oasis-open.org)
Who are implementing the standards?
A lot of companies / initiatives Microsoft, Sun, NEC, Fuijtsu, RSA, IBM,
Entrust, HP, DSTC, IAIK, Baltimore, Apache
Lecture outline
High-level view to WS Security WS Application-level security
Standardization landscape Basic XML security Summary
Basic XML Security
XML Digital Signatures (XMLDSIG) XML Encryption XML Canonicalization XML Key Management
Digital Signatures
MessageDigest
MessageDigest
Message
Private key Public keyAsymmetric Key Pair
SIGN VERIFYSignature Pass/Fail
Need to know the message, digest, and algorithm (f.e.
SHA1)
XML Digital Signatures
Digests calculated and a <Reference> created <Reference (URI=)? (Id=)? (Type=)?>
(Transforms)?(DigestMethod)(DigestValue)</Reference>
Then a <Signature> element created from <Reference>, keying information, signature algorithm, and value The signature is actually calculated over the
SignedInfo subset of this information NOTE: This means that the actual signature
algorithm is ALWAYS applied to XML
XML Digital Signatures (cont.)
<Signature ID?> <SignedInfo> <CanonicalizationMethod/> <SignatureMethod/> (<Reference URI?>
(<Transforms>)? <DigestMethod></DigestMethod>
<DigestValue></DigestValue> </Reference>)+ </SignedInfo> <Signaturevalue></Signaturevalue> (<KeyInfo>)? (<Object ID?>)*</Signature>
detached signature of the content of the HTML4 in XML specification
[s01] <Signature Id="MyFirstSignature" xmlns="http://www.w3.org/2000/09/xmldsig#"> [s02] <SignedInfo> [s03] <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> [s04] <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/> [s05] <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/"> [s06] <Transforms> [s07] <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> [s08] </Transforms> [s09] <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>[s10] <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> [s11] </Reference> [s12] </SignedInfo> [s13] <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue> [s14] <KeyInfo> [s15a] <KeyValue> [s15b] <DSAKeyValue> [s15c] <P>...</P><Q>...</Q><G>...</G><Y>...</Y> [s15d] </DSAKeyValue> [s15e] </KeyValue> [s16] </KeyInfo>
Canonicalization method: whitespaces etc. Applied to
SignedInfo
Signature algorithm: DSA (encryption), SHA-1 (digest)Reference to HTML 4 XML
spec (detached)
This gets signed!Mandatory processes: validation of the
signature over SignedInfo and validation of each Reference digest within
SignedInfo.
This is the output of canonic.+ digest + encrypt. For
SignedInfo
Digest value calculated over the identified data aftertransformations
KeyInfo indicates the key to be used to validate the signature
XML Digital Signatures (cont.)
The data being signed can be inside the <Signature>, within an <Object> element (enveloping), or
external to the <Signature> in the same document or elsewhere (detached), or
surrounding the <Signature> (enveloped), or
any combination of these.
Enveloping Signature
Signature
SignedInfo
Reference
Object
Signed Data
SignedInfo refers to object (sig is parent), object digested & thus in SignatureValue. Can be useful for
SOAP messages
Detached Signatures
XML Document
Signed Data
Signature
SignedInfo
Reference
Reference
Signed Data
Signed data can be anywhere in theLocal document
Or in some other location. Note that this SignedInfo refers to multiple docs.
Enveloped Signature
Signed Document
Signature
SignedInfo
Reference
The sig is in the signed document
as a child. For example: insert data to SOAP
msgs
XML Signatures (cont.)
To verify an XML digital signature Verify the digests in each Reference, and Verify the signature value over the SignedInfo
with the appropriate key and given signature algorithm
Note that transformations are symmetric for creation / verification! (different from transformations for encryption)
What about <Transforms>?
A way to specify a sequence of algorithmic processing steps to apply to the results retrieved from a URI to Produce the data to be signed, verified, or
decrypted. Can include compression, encoding, subset
extraction, etc. For example using XPath Not needed in simple cases, but essential in
complex cases
Basic XML Security
XML Digital Signatures (XMLDSIG) XML Encryption XML Canonicalization XML Key Management
Encryption
Public key Private keyAsymmetric Key Pair
Encrypt Decrypt
XML Encryption
Provides two similar elements: <EncryptedData> and <EncryptedKey>
Such elements provide the encryption algorithm, keying information, and either the ciphertext or a URL to the ciphertext
Default ciphers: symmetric block ciphers 3DES, AES
Key sharing (RetrievalMethod) application context using KeyName using EncryptedKey
Include the symmetric key by encrypting it using recipient’s public key
Diffie-Hellman may also be used (Agreement method)
XML Encryption
<EncryptedData Id? Type? MimeType? Encoding?> <EncryptionMethod/>? <ds:KeyInfo> <EncryptedKey>? <AgreementMethod>? <ds:Keyname>? <ds:RetrievalMethod>? <ds:*>? </ds:KeyInfo> <CipherData> <CipherValue>? <CipherReference URI?>? </CipherData><EncryptionProperties>?</EncryptedData>
Example: Element<?xml version='1.0'?> <PaymentInfo xmlns='http://example.org/paymentv2'> <Name>John Smith</Name> <CreditCard Limit='5,000' Currency='USD'> <Number>4019 2445 0277 5567</Number> <Issuer>Example Bank</Issuer> <Expiration>04/02</Expiration> </CreditCard> </PaymentInfo>
<?xml version='1.0'?> <PaymentInfo xmlns='http://example.org/paymentv2'> <Name>John Smith</Name> <EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element' xmlns='http://www.w3.org/2001/04/xmlenc#'> <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData> </PaymentInfo>
Example: Element Contents<?xml version='1.0'?> <PaymentInfo xmlns='http://example.org/paymentv2'> <Name>John Smith</Name> <CreditCard Limit='5,000' Currency='USD'> <Number>4019 2445 0277 5567</Number> <Issuer>Example Bank</Issuer> <Expiration>04/02</Expiration> </CreditCard> </PaymentInfo>
<?xml version='1.0'?> <PaymentInfo xmlns='http://example.org/paymentv2'> <Name>John Smith</Name> <CreditCard Limit='5,000' Currency='USD'> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' Type='http://www.w3.org/2001/04/xmlenc#Content'> <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData> </CreditCard> </PaymentInfo>
Why Encryption is Easier than Signature
Ways are the same: Communicating the keying / algorithm /
protocol information Communicate some ”random” binary
information The encrypted data or the signature
These are not too hard
Why Encryption is Easier than Signature
For signature only, you must communicate the original data that was signed This data is usually changed as it is stored,
transmitted, parsed, and processed e.g. Character set and encoding Numeric / data / time representation Line endings XML Namespace prefixes
Requirement for canonical representation of XML
Basic XML Security
XML Digital Signatures (XMLDSIG) XML Encryption XML Canonicalization XML Key Management
Why Canonicalization is Hard
Exactly the same sequence of data bytes must be used for signing as for verifying Problem of DTDs & Schemas Problem of white space Curse of namespaces The usual:
Encodings & character sets (UTF-8,..) Representations (<foo/>, <foo></foo>) Reordering of attributes
XML Canonicalization: DTDs and Schemas
XML provides for DTDs which can define abbreviations (”entities”), insert default attribute values, and change the normalization of attributes XML Schemas do similar things
DTDs and Schemas can be internal or external and the same DTD/Schema processing must be done at both signing and verification
XML Canonicalization: White Space
Indenting of XML makes it look free form With secure XML, this is an illusion
You can never tell if white space in element content is significant, so it must be preserved
<e>stuff and nonsense</e> <e> <f>foo</f> <g/> </e>
White space in start and end tags is not significant: <e z=”v ” a =’v2’ >foo</e>
XML Canonicalization: Namespaces
Element and attribute names can be qualified with a ”namespace” prefix The prefix represents a URI tag
URIs are bound to arbitrary prefix names For brevity and because namespace prefixes are
separated by a colon This binding effects all nested XML, until
overridden When using signatures, namespace prefixes are
signed also, if signature is inserted into another document the namespace definitions may change verification problem, for instance with SOAP
XML Canonicalization: Namespaces Example
<e xmlns="http://a.test" xmlns:foo="ftp://b.example"> <default id="mumble"> <foo:bar q="value">
abc efg hijklmn opqrstuv
</foo:bar>
</default>
<barbar foo:r="value">..</barbar></e>
XML Canonicalization: Namespaces Solution
Canonical XML specification imports ancestor namespace declaration Protects against moving XML to a different context Changes in namespace binding invalidates
signature Exclusive XML Canonicalization excludes, as
much as practical, ancestor namespace declarations Permits XML to be encapsulated and de-
capsulated without breaking signatures W3C Recommendation
http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/
XML URI Format
Before XML Security, there was no standard way of serializing URIs with miscellaneous UNICODE in them %xx hex espace only espaces bytes, not
characters Conversion to UTF-8 octets, which are hex
escaped Canonicalization must specify a
particular encoding (UTF-8) and exactly how to handle every special character on serializing and parsing URIs
Basic XML Security
XML Digital Signatures (XMLDSIG) XML Encryption XML Canonicalization XML Key Management
XML Key Management (XKMS)
A Web Service that provides an interface to a PKI Abstracts PKI certificates Towards centralized PKI management (an
enterprise resource vs. configured by end-clients) Designed to manage the sharing of public keys
Managing includes verifying signatures Also includes encrypting messages
XKMS takes complexity from the applications Originally from
VeriSign, Microsoft, webMethods XKMS 1.0
W3C Note 30 March 2001 XKMS 2.0
W3C Candidate Recommendation 5 April 2004
XML Key Management (XKMS)
The XML Key Management Specification (XKMS) comprises two parts the XML Key Information Service
Specification (X-KISS), and Retrieval of information about keys
the XML Key Registration Service Specification (X-KRSS). Store of information about keys
Uses the SOAP 1.1 protocol for communication, XML Schema, WSDL 1.0
Based on XML Signatures
XKMS: XKRSS
XKRSS – XML Key Registration Service Specification The X-KRSS specification defines a
protocol for a web service that accepts registration of public key information. Once registered, the public key may be used in conjunction with other web services including X-KISS.
Allows registering key pairs Saves the key pairs as <KeyBinding>
elements Supports backing up & restoring keys Four services: register, recover, reissue,
revoke
XKMS: XKISS
XKISS – XML Key Information Service Specification defines a protocol for a Trust service that resolves
public key information contained in XML-SIGelements.
The X-KISS protocol allows a client of such a service to delegate part or all of the tasks required to process <ds:KeyInfo> elements
Enables clients to request <KeyBinding>’s associated with <KeyInfo> elements
LOCATE operation – locates a requested key VALIDATE operation – validates <KeyBinding>s The underlying PKI may be based upon a different
specification such as X.509/PKIX, SPKI or PGP.
XKMS Key Concepts
Messages to & from a trusted server These messages are bound to the SOAP
protocol Uses XML Signatures for key ownership Allows users to request a reply format
<RespondWith> Can specify what key is used for
<UseKeyWith>
Lecture Summary
Topic to be continued next time
XML security vs. security in general Application level security Basic standards
XML Signatures, XML Encryption