1 / 12

Links and Security

Dive into language-based security for web services, exemplified by TulaFale tool to secure SOAP messages, analyze vulnerabilities, including XML rewriting attacks. Explore tradeoffs and implementations.

mrusso
Download Presentation

Links and Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Links and Security Andy Gordon (TulaFale is joint work with Karthik Bhargavan, Cédric Fournet, and Riccardo Pucella) Microsoft Research Links Meeting, Edinburgh April 6, 2005

  2. Security and Web Languages • Don’t focus just on web apps at the expense of web services – latter increasingly important • Research languages (such as Jif, Flow Caml, KLAIM) are source of modestly sized security-related programming tasks • In particular, TulaFale exemplifies some common web services security protocols • Language-based security requires delicate tradeoffs • Many have arisen over the past decade • I mention three a new design should address

  3. XML Request XML Response 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 Client • Service messages in SOAP format: • Envelope/Header – addressing, security, and transactional headers • Envelope/Body – actual payload • By now, serious money in web services • eBay, Yahoo, Google, MSN, FlickR, del.icio.us • Amazon has >65k devs signed up Server

  4. Securing SOAP Messages UsernameToken assumes both parties know Alice’s secret password p <Envelope> <Header> <Security> <UsernameToken Id=1> <Username>"alice" <Nonce>"mTbzQM84RkFqza+lIes/xw==" <Created>"2004-09-01T13:31:50Z" <Signature> <SignedInfo> <SignatureMethod Algorithm=hmac-sha1> <Reference URI=#2> <DigestValue>"U9sBHidIkVvKA4vZo0gGKxMhA1g=“ <SignatureValue>"8/ohMBZ5JwzYyu+POU/v879R01s=" <KeyInfo> <SecurityTokenReference> <Reference URI=#1 ValueType=UsernameToken> <Body Id=2> <TransferFunds> <recipient>"bob" <amount>"1000" <Security> header defined by OASIS WS-Security 2004 includes identity tokens, signatures, encrypted message parts Each DigestValue is a cryptographic hash of the URI target hmacsha1(key, SignedInfo) where keypsha1(p+nonce+created)

  5. The adversary has intercepted and rewritten the message <Envelope> <Header> <Security> <UsernameToken Id=1> <Username>"alice" <Nonce>"mTbzQM84RkFqza+lIes/xw==" <Created>"2004-09-01T13:31:50Z" <Signature> <SignedInfo> <SignatureMethod Algorithm=hmac-sha1> <Reference URI=#2> <DigestValue>"U9sBHidIkVvKA4vZo0gGKxMhA1g=“ <SignatureValue>"8/ohMBZ5JwzYyu+POU/v879R01s=" <KeyInfo> <SecurityTokenReference> <Reference URI=#1 ValueType=UsernameToken> <BogusHeader> <Body Id=2> <TransferFunds> <recipient>"bob" <amount>"1000" <Body> <TransferFunds> <recipient>“Phil" <amount>"5000" Implementations of WS-Security may be vulnerable to a range of XML rewriting attacks Here, without cracking the password, an adversary can alter the interpretation of a signed message The indirect signature of the body, now hidden in BogusHeader, may still appear valid One fix is to check for duplicate Body elements

  6. TulaFale : Tool for WS TulaFale = pi + XML + predicates + assertions In work published at FMCO’03 and POPL’04, we designed and implemented TulaFale, and hand-wrote models for series of WSE protocols What TulaFale does TulaFale script predicatelibrary WSE 1.0out of the box TulaFale C# code intermediate pi-calculus WSE 1.0 CLR (IL) ProVerif analyzer OK, orNo because… SOAP processing

  7. Describing Messages TulaFale predicates defined by Horn clauses with message equalities For example, this predicate used in two different modalities to construct and parse Message 1 TulaFale messages are terms in a many-sorted algebra with sorts:

  8. Deriving a Key Set of symbolic crypto primitives (including psha1) defined equationally

  9. Checking a Message TulaFale library includes predefined predicates for XML signatures and encryption

  10. Faithful to the XML wire format, unlike most work on symbolic crypto which ignores the details Embedding of symbolic crypto within XML allows specs more concise and rigorous than the official WS specs and standards Automatic verification of secrecy and authentication via ProVerif Simple, Iota-style type system for XML Direct execution still ongoing Would eliminate “semantic gap” between model and code Bidirectional predicates overrated Functional style would ease implementation with little loss of expressiveness TulaFale: Pros and Cons

  11. Three Delicate Tensions • Between interoperability and security • Ex: WS policy language very flexible for interoperability, and yet incredibly easy to misconfigure • Want small easy-to-use set of “secure channel” abstractions, plus means for experts to customize • Between source and target semantics • Ex: mismatch between Java & JVM led to holes • Theoretically speaking, a failure of “full abstraction” • Mismatches between Links and JS,JVM,SQL, anyone? • Between static and dynamic verification • Ex: Cryptyc checks for security properties via a dependent type and effect system, entirely statically • Ex: Perl tags data from untrusted input channels as “tainted”, and keep tag until explicitly endorsed • Ex: Java has mixture – b/c verifier, stack inspection

  12. The End

More Related