1 / 51

Using WS-SecurityPolicy to Defend Web Services Attacks

Using WS-SecurityPolicy to Defend Web Services Attacks. Symon Chang, CISSP Staff Software Engineer BEA Systems Inc. February 29 th , 2008. Who Am I?. Implement SOA Web Services security solutions at BEA Systems Working on Web Services security since 2001 CISSP

emele
Download Presentation

Using WS-SecurityPolicy to Defend Web Services Attacks

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. Using WS-SecurityPolicy to Defend Web Services Attacks Symon Chang, CISSP Staff Software Engineer BEA Systems Inc. February 29th, 2008

  2. Who Am I? • Implement SOA Web Services security solutions at BEA Systems • Working on Web Services security since 2001 • CISSP • OWASP member at San Francisco/Silicon Valley Chapter • Voting member of OASIS WS-SX TC, and editor of WS-SecurityPolicy 1.2 Examples Document. • Was member on OASIS WSS TC, WS-I Basic Security Profile WG, W3C WS-Policy WG • Was Sr. Security Architect, at BlueTitan, TIBCO and CommerceOne. • Holds 4 patents pending in the Web Services security policy area

  3. Outline • Introduction of WS-SecurityPolicy • Attacks and How to Defend Them • Implementation Related Issues • The Best Practice • Q & A

  4. Introduction of WS-SecurityPolicy What The Heck Is WS-SecurityPolicy?

  5. Web Services • Standard protocols: XML, SOAP, UDDI, WSDL, etc. • Cross Platforms: BEA, MSFT, IBM, SUN, HP, etc. • Interoperability, Integrations Service Provider XML Msg. Internet XML Msg. Application Service Requester What is missing?

  6. Web Services Security Without Security, Web Services are Dead on Arrival!

  7. Web Services Security Features • Confidentiality – Message can only be viewed by intended recipient(s). • Integrity and non-repudiation – Messages can’t be tampered with while in transit. • Authentication – Who sent the document? C.I.A.

  8. Web Services Security Standards • W3C XML Encryption • http://www.w3.org/TR/xml-encryption-req • W3C XML Digital Signature • http://www.w3.org/TR/xmldsig-core • OASIS Security Assertions Markup Language (SAML) • http://www.oasis-open.org/committees/security/#documents • OASIS WSS (Web Services Security) • SOAP Message Security • http://www.oasis-open.org/specs/index.php#wssv1.1 • http://www.oasis-open.org/specs/index.php#wssv1.0

  9. Web Services Security Confidentiality: XML Encryption Integrity: XML D-Signature Authentication: Username Token,X509, SAML WS-Security for SOAP Envelope • Security: Service Provider XML Msg. Internet XML Msg. Application Service Requester What is missing?

  10. How to Encrypt, how to Sign? • Which encryption algorithm to use? • Which signature algorithm to use? DES AES 3DES RSA DSA MD5 SHA-1 SHA128 Weak Encryption Weak or Strong Encryption Key size: 128 196 256 Internet C14N EXC14N 512 1024 2048 XML Doc. Service Consumer Services Provider Sign then encrypt/ Encrypt then sign Encrypt signature Symmetric/ Asymmetric binding Encrypted Key / Derived Key

  11. Whom: • Whom do we trust? • What to sign? • What to encrypt/decrypt? What: • How to authenticate? • How to sign? • How to encrypt/decrypt? How: And more… What is Security Policy? • Security Policy is the security configuration • It answers the questions of: • For many-to-many interoperability

  12. Web Services Security Policy Without Security, Web Services are Dead on Arrival! Without Security Policy, Web Services Security are Dead on Arrival! Symon Says:

  13. The OASIS Standard • WS-SecurityPolicy version 1.2 • OASIS Standard as July 2007 • Under OASIS Web Services Secure Exchange TC (WS-SX TC) • Policy Language for Web Services Security • WS-Security • WS-SecureConversation • WS-Trust • . . . • One of most rich SOA/Web Services specifications

  14. request XML Msg. XML Msg. response WS-Sec Policy WS-Sec Policy What Security Policy is Used? • Build the out going secured SOAP message • Verify the incoming SOAP message Use policy to verify the incoming response Use policy to verify the incoming request Service Provider Service Requester Internet Use policy to build the response Use policy to build the request

  15. WS-Policy and WS-SecurityPolicy • WS-SecurityPolicy is built on top of WS-Policy What the heck is WS-Policy?

  16. WS-Policy and WS-SecurityPolicy • WS-SecurityPolicy –to express Web Services security requirements/configurations • WS-Policy – to Web Services requirements and configuration can be defined in a standard way: • An XML-based structure to express policy information • Grammar elements to indicate how to apply the policy • WS-Policy 1.5 is W3C standard as September 2007

  17. WS-Policy Model Policy Assertion Policy Alternative Collection of Assertions Policy Assertions Collection of Alternatives “Policy Normal Form” Use XML to represent the configuration information between Web Services

  18. <All> <ExactlyOne><Assertion1> <Assertion2> </ExactlyOne> <ExactlyOne><Assertion3> <Assertion4> </ExactlyOne></All> Isequivalentto <ExactlyOne> <All><Assertion1><Assertion3></All> <All><Assertion1><Assertion4></All> <All><Assertion2><Assertion3></All> <All><Assertion2><Assertion4></All></ExactlyOne>  Compact Form – Nested Operators • <wsp:All> and <wsp:ExactlyOne> operators can be nested arbitrarily • Example • <All> distributes over <ExactlyOne> (Assertion1&Assertion3) | (Assertion1&Assertion4) | (Assertion2&Assertion3) | (Assertion2&Assertion4) (Assertion1|Assertion2) & (Assertion3|Assertion4)

  19. Sample of Complicated Policy

  20. Attacks and How to Defend Them How to defend Web Services Attacks

  21. Man-in-the-middle Attacks • Web Services is end-to-end XML over the internet, and it may go through multiple hops • Hacker can intercept the message to view it or to change the contents of the message Hacker Service Provider XML Msg. XML Msg. XML Msg. XML Msg. MITM Application Service Requester

  22. Use Asymmetric Binding Policy • Use X509 Token for protection • Both sides have public/private key pairs • Use keys to sign and encrypt: • Sign and encrypt the message body • Also sign the timestamp and/or other elements in the header • Hacker in the middle cannot view and change the message

  23. request XML Msg. XML Msg. response WS-Sec Asym Policy WS-Sec Asym Policy Private Key Private Key How Asymmetric Binding Work • Both side has X509 public/private key pair • Use my private key to sign, and other’s public key to encrypt for both request and response Service Provider Service Requester Internet

  24. Authentication with SupportingTokens • Asymmetric policy assertion just for Encryption and Signature • How about Authentication? • WS-SecurityPolicy uses SupportingTokens assertions for the authentication • SupportingTokens assertions describe token which perform additional security operations in respect to the binding policy

  25. Hacker Replay Attacks on Username Token • Username Token has username and password elements • Attacker intercept the message • Copy the UsernameToken element and Paste into attacker’s message Service Provider XML Msg. XML Msg. XML Msg. Application Service Requester

  26. Signed Encrypted Username Tokens • WS-SecurityPolicy version 1.2 has SignedEncryptedSupportingTokens Assertion • For plain-text password in Username Token, it requires to protect it by signature and encryption

  27. WS- Policy WS- Policy SAML For Authentication • Client gets the SAML token from Security Token Services (STS) using WS-Trust • Client puts SAML token into the message • Server verifies SAML token to make authentication and authorization decision Sender XML Msg. Internet XML Msg. WS-Trust Security Token Services (STS)

  28. Hacker Replay Attacks on SAML Token • Intercept the message • Copy the SAML Token Credential • Paste into attacker’s message Service Requester Service Provider XML Msg. XML Msg. XML Msg. Application WS-Trust STS

  29. Sender Voucher Confirmation • Use WS-SP SignedSupportingTokens Assertion • Sign the SAML token together with headers and body • Receiver verify the signature of the sender

  30. Holder of Key Confirmation • The sender’s key is referenced inside the SAML token • Use SAML Token like X509 Token • The sender prove the precession of the Key by use it to sign the message

  31. Implementation Related Issues Unnecessary complications? Over-engineering? Poor performance? Not interoperate? Threaten the security?

  32. Asymmetric vs. Symmetric Binding • WSS 1.1 support Encrypted Key and Derived Key (DK) functions • The key is generated for both signature and encryption • Symmetric is more efficient than Asymmetric Binding • However, to be more secure, Endorsing and Signed Endorsing Tokens is introduced

  33. Symmetric Binding • Has only ProtectionToken assertion • X509 Token with includeToken/Never assertion, the X509 Cert is not included in the message • The key is encrypted with Server’s public key.

  34. request XML Msg. Endorse XML Msg. Endorse response WS-Sec Sym Policy WS-Sec Sym Policy Private Key How Symmetric Binding Work • The key is generated or derived for both signature and encryption • Use Server’s Certificate to protect the key • Use requester’s key to protect the signature (Endorsing) Service Provider Service Requester Internet Use server x509 cert to protect the Key

  35. SupportingTokens Assertions • SupportingToken assertions are for authentication and/or endorsing • Endorsing Token is a token used to sign the message signature • It has the following different types of supporting tokens assertions: • Supporting Tokens • Encrypted Supporting Tokens • Signed Supporting Tokens • Signed Encrypted Supporting Tokens • Endorsing Supporting Tokens • Signed Endorsing Supporting Tokens • Endorsing Encrypted Supporting Tokens • Signed Endorsing Encrypted Supporting Tokens

  36. The Versioning Problems • Different versions of WS-Policy and WS-SecurityPolicy will create interoperability problems • These are not just WS-SecurityPolicy problems, all WS-* protocols have interoperability problems when two sides have different versions of standards • But in WS Security case, not only creates interoperability problem, but will create security holes

  37. The World of Multiple Versions Standards WS-Security 1.0 SOAP 1.1 SOAP 1.2 WS-Security 1.1 WSS SAML 1.1 Token Profile 1.0 WS-Addressing 0.8 WSS SAML 1.1 Token Profile 1.1 SAML 1.1 WSS SAML 2.0 Token Profile 1.1 WS-Addressing 1.0 SAML 2.0 WS-Reliable Messaging 1.0 WS-Secure Conversation 1.2 WS-Reliable Messaging 1.1 WS-Secure Conversation 1.3 WS-Policy 1.2 WS-Trust 1.0 WS-Policy 1.5 WS-Trust 1.3 Other WS-*standards WS-Security Policy pre 1.2 WS-Security Policy 1.2 More versions are coming…

  38. Different Versions of Policy • WS-Policy has two versions: • WS-Policy 1.2 http://schemas.xmlsoap.org/ws/2004/09/policy • W3C WS-Policy 1.5 http://www.w3.org/ns/ws-policy • WS-SecurityPolicy has two versions now: • Pre OASIS WS-SecurityPolicy 1.2 http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512 • OASIS WS-SecurityPolicy 1.2 http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702

  39. WS-Policy Versions • WS-Policy goes by namespace: known wsp elements are operator, and unknown namespace of elements are assertions • How about this:

  40. Signed Username Tokens • No SignedEncryptedSupportingTokens Assertion in WS-SecurityPolicy v1.1 • Some vendors use pre-v1.2, for plain-text password in Username Token, it requires to protect it by signature and encryption under SignedSupportingTokens • If v1.2 client no encryption on SignedSupportingTokens Assertion will create security and interoperability problems

  41. WS1.0 Policy Both WSS1.0 WSS1.1 Policy WS1.1 Policy Policy Alternatives for WSS1.0 and WSS 1.1 • Service defines to accept both WSS 1.0 and WSS 1.1 security format • Different client use proper policy for request WSS 1.0 request WSS10 Msg. WSS 1.0 Msg. WSS 1.0 response WSS 1.1 request WSS11 Msg. WSS 1.1 Msg. WSS 1.1 response

  42. How to Define Multiple Policy Alternatives <wsp:Policy xmlns:wsp=“…" xmlns:sp=“…"> <wsp:ExactlyOne> <wsp:All> </wsp:All> <wsp:All> </wsp:All> </wsp:ExactlyOne> </wsp:Policy> WSS10 Policy WSS11 Policy

  43. WS-Policy Alternative Attacks • When there are multiple policy alternatives in a policy, not all alternative are equally secure • Admin may accidentally insert some insecure alternatives into the policy • Hacker will select an easy-to-hack policy alternative to attack the services

  44. Multiple Policy Alternatives

  45. What is Wrong with This Policy? • Which Policy Alternatives be selected? • Any thing wrong? • What is this: <wsp:All /> Null Alternative Attack

  46. The Best Practice Security Performance Interoperability Availability

  47. Which policy to use? • There are many policies, and user can define even more policies. Which policy should be used? • Depending on user requirements and preference • Performance -- heavy vs. light transaction load • Security -- low vs. high security requirements • Interoperability -- do we need to support different versions? • Credential Availability -- X509 vs. Username Token, clear vs. dingiest password Security Performance Availability Interoperability

  48. Smart Policy Selection • Server should allow multiple policy alternatives for a single port/service • The user can define multiple policy alternatives at the configuration time • At runtime, server will select one from the policy alternatives • Selection base on the client’s preference: • Security • Performance • Interoperability • Select the right one to build the request message • Use the proper one to build the response message

  49. How To Prevent Hackers Will reveal the top secret Don’t want hackers know Please come to my session at RSA Conference 2008, in San Francisco Tuesday, 04/08/2008 03:00 PM Session: SOA-106 To be disclosed then … Shih! Don’t tell hackers 49

  50. Any Tips? • The title of my RSA presentation is: Honey, I hack the WS-SecurityPolicy

More Related