1. Review of XML web services. 2. Review of WS-Security. 3. Our new formal model for SOAP security. 4. Demo of our new formal tool, TulaFale

Transcription

1 Formal Tools for Securing Web Services Andy Gordon Based on joint work with Karthik Bhargavan, Cédric Fournet, and Riccardo Pucella Microsoft Research Second International Symposium on Formal Methods for Components and Objects Lorentz Centre, Leiden, November 4-7, 2003 Outline 1. Review of XML web services Processors of the SOAP message format 2. Review of WS-Security SOAP messages with embedded crypto 3. Our new formal model for SOAP security A pi-calculus whose messages are XML documents including symbolic crypto (to appear at POPL 2004) 4. Demo of our new formal tool, TulaFale Automatic verification of WS-Security protocols (builds on Bruno Blanchet s ProVerif tool) 2 Part I: Web Services WAN-scale distributed systems based on SOAP, a stateless, unreliable, one-way messaging protocol Components yes, objects no! What s a Web Service? A web service is a web site intended for use by computer programs instead of human beings. (Barclay et al) So XML not HTML LAN-scale example: platform-neutral interconnect for existing systems within an organisation WAN-scale example: Amazon publishes services to let associates into its database Allows associates to sell Amazon s products Allows Amazon to sell associates products 4 A Typical Web Service A Sample SOAP Request Smart client for checking orders PetShopService ws = new PetShopService(); Order o = ws.getorder(20); Implementation via proxy class and HTTP transport Vendor-neutral XML-encoding over HTTP The Internet SOAP Request SOAP Response [WebMethod] public Order GetOrder(int orderid) { return orderwebservice.getorder(orderid); } Implementation via WebService classes in Web Server Pet Shop database 5 <soap:envelope xmlns:soap=" xmlns:xsi=" xmlns:xsd=" <soap:body> <GetOrder xmlns=" <orderid>20</orderid> </GetOrder> </soap:body> </soap:envelope> Says: get me status of order 20 XML not meant to be read by humans, so we ll omit namespace info, and trailing brackets 6 1

2 A Sample SOAP Request <GetOrder> <OrderId>20</> Says: get me status of order 20 XML not meant to be read by humans, so we ll omit namespace info, and trailing brackets that s better A Sample SOAP Response Optional header <Header> <Timestamp> <Created> T23:36:06Z</> <Expires> T23:41:06Z</> <GetOrderResponse> Mandatory body <orderid>20</> <date> </> <userid>adg</> Unlike the client making the request, the server has included a timestamp in the optional Header 7 8 Services Export XML Metadata Interfaces (eg WSDL) Names of exported functions, argument and result types Mature: enables automatic construction of proxies Security Policies (eg WS-Policy) Acceptable crypto algorithms, identity authorities, Coming of age: recent interoperability demos Behavioural Contracts (eg BPEL4WS) Acceptable message order and patterns Infancy: hence, opportunity for basic research Discoverable dynamically Suitable for processing with standard XML toolsets O in SOAP not for Object You d be forgiven for thinking otherwise At the start, 1998, Simple Object Access Protocol By 2003, SOAP 1.2, SOAP not spelt out, just a name Externally, in fact, SOAP is not object-oriented No instances, allocation, de-allocation No distributed garbage collection No classes or inheritance No state at SOAP level but see OGSI for stateful grids Internally, SOAP processors may be object-oriented Code your service in any language you like Don Box Objects are to services what ICs are to devices 9 10 W in WS not for Web Originally, web services were generalization of CGI Seen as RPC over HTTP via XML (Dave Winer, 27-Feb-98) Navigating firewalls via port 80 an explicit goal In fact, SOAP based on asynchronous messaging RPC composition of two symmetric single-shot messages SOAP allows for multiple transports HTTP still the common case TCP web services without a web server! Message Queues common in enterprise data centres SMTP easily supports mobile users SOAP allows for multiple intermediaries Firewalls between trust domains Gateways between transports, eg, SOAP-Mail 11 Part II: SOAP Security WS-Security specifies how to achieve message-level security by embedding crypto into SOAP messages In later parts, we introduce formal tools for verifying certain properties of SOAP security As background, we explain WS-Security by example, and review the standard Dolev-Yao threat model 2

3 The 2002 Security Story The 2002 best practice was to build secure web services using an SSL (as in HTTPS) transport SSL gives transport- not application-level security Messages secured point-to-point not end-to-end Messages cannot securely be filtered or routed Messages not encrypted in files or databases Moreover, SSL has scalability problems Party line (aka Web Services Security Roadmap) security within SOAP envelopes is better: For end-to-end, application-level security, independent of underlying transports Since 2002 IBM/MS plus others publish specs Security Roadmap, Apr 2002 WS-Security spec, Apr 2002 WS-Trust, WS-SecurityPolicy,, Dec 2002 Secure, Reliable, Transacted Web Services, Sep 2003 and release various implementations MS WSE (Web Service Enhancements) 1.0, Dec 2002, implements WS-Security, WS-Routing, etc 2.0, now in beta, implements policy driven security, etc Other products from IBM and others Next, WS-Security by example Sample Security Goals Suppose a human A with password p uses a client I to invoke a web service at URL S S = Without some kind of authentication, anybody could request the private details of anyone else s order Simple solution to require p-based signature of: Message body to show request from A, and has not been modified Timestamp to detect replays, with cache of recent messages Web server S to detect redirection from another server How To Sign a SOAP Message WS-Security specifies how to embed security tokens in an envelope s Security header. Ex: UsernameToken, identifies principal by name Ex: Signature, consisting of SignedInfo: list of digests of items in the envelope to be bound together by the signature SignatureValue: keyed hash of SignedInfo KeyInfo: pointer to signing key, such as a key derived from a user s password Next, the signed SOAP message <Header> UsernameToken assumes A Signed both parties know Request adg s Routing header identifies action and server <path actor="next"> <action> <to> <id>uuid:5ba86b04-3c0f-428b-8dd fe40</> secret password p Password digest = <Timestamp> sha1(nonce+time+p) <Created> T16:49:45Z</> proves knowledge of p <Expires> T16:50:45Z</> <Security> <UsernameToken> <Username>adg</> Nonce to prevent replays; <Password>Ouywn2V6ikNNtWYL29gl9R3CPBk=</> receiver needs to cache <Nonce>cGxr8w2AnBUzuhLzDYDoVw==</> recently seen nonces <Created> T16:49:45Z</> <Signature> <SignedInfo> Each DigestValue is the <Reference URI="#..."><DigestValue>Ego0...</> sha1 hash of the URI target <Reference URI="#..."><DigestValue>5GHl...</> <Reference URI="#..."><DigestValue>efb0...</> <Reference URI="#..."><DigestValue>dFGb...</> URI arrows implemented <Reference URI="#..."><DigestValue>23io...</> using GUID Id attributes <Reference URI="#..."><DigestValue>E4G0...</> <SignatureValue>vSB9JU/Wr8ykpAlaxCx2KdvjZcc=</> <KeyInfo><SecurityTokenReference><Reference URI="#..."/> <GetOrder> Review: The Dolev-Yao Model The threat model is an attacker who can replay, redirect, assemble new messages, but cannot brute force secrets such as passwords Can verify that crypto protocols establish various safety properties in spite of such an attacker: Message authentication against impersonated access Message integrity against parameter manipulation Message confidentiality against eavesdropping Message freshness against replays Much recent progress in automated support, but like all formal or informal methods, certain threats lie outside the model: Disclosure of configuration data hmacsha1(key, SignedInfo) where Unauthorized access via SQL injection or cross-site scripting <orderid>20</> Hence, signature can key=psha1(p+nonce+time) Underlying code defects, eg, buffer overruns prove this is a fresh Compromise of weak passwords message from adg 18 3

4 Rest of my talk MSRC Samoa Project Goal: exploit advances in the analysis of Dolev-Yao threat model in practical setting of XML web services Results so far: Implementation of security attributes for SOAP A. Gordon and R. Pucella, Validating a web service security abstraction by typing. In 2002 ACM Workshop on XML Security Logic-based verification of SOAP-based protocols K. Bhargavan, C. Fournet, A. Gordon, A semantics for web services authentication. In 2004 ACM POPL Actionable feedback to internal group See 19 Part III: A Model of Web Services Security The XML wire format is trees plus pointers, more complex than the abstract trees of typical Dolev-Yao formalisms To reason at this level, we propose an XML model with symbolic crypto, that we embed within the pi calculus To the best of our knowledge, this is the first and only formalism for XML-based authentication protocols XML Model 1: Standard Core XML Data 2: Crypto Label ::= anylegalxmlname element or attribute name String : str ::= any legal XML string XML string Att : att ::= Label="String" attribute Atts : atts ::= Att Atts ε attribute sequence Item : itm ::= Element String item Items : itms ::= Item Items ε item sequence Element ::= <Label Atts>Items</Label> element Sorts str, att, atts, itm, itms Represents valid, parsed XML Adapted from Siméon and Wadler's model (POPL 03) Resembles the W3C Infoset recommendation 21 Bytes : bytes ::= s concat(bytes 1,Bytes 2 ) c14n(item) utf8(string) sha1(bytes) p-sha1(string pw,bytes salt ) hmac-sha1(bytes key,bytes src ) String : str ::= s base64(bytes) principal(s pw ) byte array (not itself XML) pi name, a nonce or key array concatenation canonical bytes of an item UTF8 rep of a string cryptographic digest key from salted password keyed hash XML string pi name, a password Base64-encoding of array from password to principal Symbolic representation of crypto as in XML-DSIG Omitting operations for XML-ENC, destructors, and the equational theory 22 Logical Predicates F ::= V=T U V p(v 1,,V n ) F 1,F 2 p(x 1,,x n ) :- F 1 F m formula term comparison list membership predicate instance conjunction predicate definitions A Horn logic over our many-sorted algebra primitive formulas for equality and list membership, but no recursive predicates Given certain implementability constraints, logic programs may be compiled into the pi calculus How Do We Apply The Model? Use predicates on XML to represent security checks made by SOAP processors Express security goals as correspondences between successful completions and legitimate initiations Embed the predicates and assertions within the pi calculus to represent behaviour of server and clients Prove absence of attacks within pi threat model Our paper follows this recipe for a series of samples, but also discusses threats outside pi model

5 Predicates for Username Signing isusertokenkey(tok:item, A:string, p:string, n:bytes, t:string, k:bytes) :- tok = <UsernameToken _> <Username _>A</> <Created>t</> <Nonce>base64(n)</> A = principal(p), k = p-sha1(p, concat(n,utf8(t))). hasusersignedbody(e:item, A:string, p:string, n:bytes, t:string, b:item) :- hasbody(e,b), hassecurityheaders(e,toks), utok toks, isusertokenkey(utok,a,p,n,t,k), sig toks, issignature(sig,subs, hmac-sha1,k), b subs. Says k is the key derived from password p, nonce n, timestamp t, from token tok for user A Says b is the body of envelope e, signed by A with key derived from p, with nonce n and timestamp t 25 A Concrete XML Protocol Event 1 I logs begin(a,n,t,orderid) Message 1 I S e where hasusersignedbody(e,a,p,n,t,b) and isgetorder(b, orderid) Event 1 S logs end(a,n,t,orderid) Message 2 S I GetOrderResponse(orderInfo) Authenticity formalized as a correspondence Each end has a cause, a preceding begin with same label We describe this protocol as a process Q, and take the opponent O to be any arbitrary process in parallel Theorem: Q O is safe, that is, in every run, every end-event corresponds to a preceding begin-event The paper has results for several SOAP protocols 26 Conclusions, Futures Part IV: TulaFale Demo This summer, Riccardo Pucella has implemented an automatic verifier using Blanchet s ProVerif B. Blanchet, An Efficient Cryptographic Protocol Verifier Based on Prolog Rules, CSFW 01 Successfully bridged gap between theoretical pi threat model and XML used in WS security protocols Driven by real samples, eg, MS Pet Shop Faithful to XML message format Found attacks within threat model Proved theorems about wire-level protocols Future directions Improve usability of the tool Analyse more complex protocols Build SOAP stack in an XML-aware type system MSRC Samoa Project 28 Securing.WS Resources Projects: Samoa, Cryptyc, Proverif Standards tracks and whitepaper My Top Three Web Service Blogs