Attacking XML Security Brad Hill Principal Security Consultant brad@isecpartners. com OWASP & WASC App. Sec 2007 Conference San Jose – Nov 2007 http: //www. webappsec. org/ Copyright © 2007 - The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the Creative Commons Attribution-Share. Alike 2. 5 License. To view this license, visit http: //creativecommons. org/licenses/by-sa/2. 5/ The OWASP Foundation http: //www. owasp. org/ 1
Agenda <Introduction 4 Who am I? 4 Why care about XML Security? <How do XML Digital Signatures work? <How to build a cross-platform worm in XML! <Can we use this technology safely? OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 2
Special Thanks to: 4 Alex Stamos & Scott Stender, i. SEC Partners § “Attacking Web Services: The Next Generation of Vulnerable Enterprise Apps” § http: //isecpartners. com/files/i. SEC-Attacking-Web-Services. Sy. Scan. pdf 4 Dan Kaminsky of Dox. Para & IOActive 4 Dr. Laurence Bull of Monash University, Australia 4 Dr. Brian La. Macchia of Microsoft Corporation 4 Andreas Junestam, Jesse Burns, Chris Clark and Chris Palmer of i. SEC Partners OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 3
Introduction <Who am I? 4 Principal Security Consultant for i. SEC Partners 4 Application security consultants and researchers 4 Based in San Francisco and Seattle, USA < To get the latest version of these slides: 4 https: //www. isecpartners. com/speaking. html OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 4
Why care about XML Security? <Web Services have gone mainstream: 4 SOA & B 2 B integration 4 Web Single Sign On <And everybody has XML applications. <It’s lurking more places than you might think: 4 Mobile code manifests 4 Printing 4 DRM & software licensing 4 P 3 P 4 Digital identity systems OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 5
Two years ago… <Alex Stamos & Scott Stender of i. SEC present: 4“Attacking Web Services: The Next Generation of Vulnerable Enterprise Applications” <Web Services can be scary: 4 Valuable 4 Visible 4 Vulnerable OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 6
Web Service application-level attacks <The OWASP Top 10 still apply to Web Services <Old flaws like SQL injection <And new flaws like XML and XPath injection <Plus complexity attacks and denial of services against XML parsers and applications OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 7
Today’s topic is protocol-level attacks <Alex & Scott’s talk has been widely noted. <One of the few things followers have added is… (and which they deliberately didn’t) <WS-Security to save the day! (or not) OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 8
Why XMLDSIG & XMLENC? <For me…I didn’t really set out to look at it, specifically. 4 IANAC (I am not a Cryptographer) 4 I thought: “Just a signature with angle brackets. ” 4 Lots of new applications and platforms being built on Web Services. 4 Not a lot of security testing tools yet. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 9
Building an attack proxy… <I wanted a tool like Web. Scarab or Fiddler for attacking Web Services utilizing WS-Security. <First order of business was fixing up XML Signatures. <Then I found this in the interop vectors while doing unit testing: (© Merlin Hughes, Baltimore Technologies, 2002) OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 10
<? xml version="1. 0" encoding="UTF-8"? > <!DOCTYPE Envelope [ <!ENTITY dsig 'http: //www. w 3. org/2000/09/xmldsig#'> <!ENTITY c 14 n 'http: //www. w 3. org/TR/2001/REC-xml-c 14 n-20010315'> <!ENTITY xpath 'http: //www. w 3. org/TR/1999/REC-xpath-19991116'> <!ENTITY xslt 'http: //www. w 3. org/TR/1999/REC-xslt-19991116'> <!ATTLIST Notaries Id ID #IMPLIED> ]> <!-- Preamble --> <Envelope xmlns: foo="http: //example. org/foo" xmlns="http: //example. org/usps"> <Dear. Sir>foo</Dear. Sir> <Body>bar</Body> <Yours. Sincerely> <Signature xmlns="http: //www. w 3. org/2000/09/xmldsig#" Id="signature"> <Signed. Info> <Canonicalization. Method Algorithm="http: //www. w 3. org/TR/2001/REC-xml-c 14 n-20010315" /> <Signature. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#dsa-sha 1" /> <Reference URI="http: //www. w 3. org/TR/xml-stylesheet"> <Digest. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#sha 1" /> <Digest. Value>60 Nv. Zvtd. TB+7 Unl. Lp/H 24 p 7 h 4 bs=</Digest. Value> </Reference> <Reference URI="http: //www. w 3. org/Signature/2002/04/xml-stylesheet. b 64"> <Transforms> <Transform Algorithm="http: //www. w 3. org/2000/09/xmldsig#base 64" /> </Transforms> <Digest. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#sha 1" /> <Digest. Value>60 Nv. Zvtd. TB+7 Unl. Lp/H 24 p 7 h 4 bs=</Digest. Value> </Reference> <Reference Type="http: //www. w 3. org/2000/09/xmldsig#Object" URI="#object-1"> <Transforms> <Transform Algorithm="http: //www. w 3. org/TR/1999/REC-xpath-19991116"> <XPath> self: : text() </XPath> </Transforms> <Digest. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#sha 1" /> <Digest. Value>zyjp 8 GJOX 69990 Kkqw 8 io. PXGExk=</Digest. Value> </Reference> <Reference Type="http: //www. w 3. org/2000/09/xmldsig#Object" URI=""> <Transforms> <Transform Algorithm="http: //www. w 3. org/TR/1999/REC-xpath-19991116"> <XPath xmlns: dsig="http: //www. w 3. org/2000/09/xmldsig#">. . . OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 11
<Reference Type="http: //www. w 3. org/2000/09/xmldsig#Manifest" URI="#manifest-1"> <Digest. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#sha 1" /> <Digest. Value>qg 4 HFws. N+/WX 32 u. H 85 Wl. JU 9 l 45 k=</Digest. Value> </Reference> <Reference Type="http: //www. w 3. org/2000/09/xmldsig#Signature. Properties" URI="#signature-properties-1"> <Digest. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#sha 1" /> <Digest. Value>ETl. EI 3 y 7 hvv. At. Me 9 w. QSz 7 Lhb. HEE=</Digest. Value> </Reference> <Reference URI=""> <Transforms> <Transform Algorithm="http: //www. w 3. org/2000/09/xmldsig#enveloped-signature" /> </Transforms> <Digest. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#sha 1" /> <Digest. Value>J/O 0 Hhda. PXxx 49 fg. GWMESL 09 Gp. A=</Digest. Value> </Reference> <Reference URI=""> <Transforms> <Transform Algorithm="http: //www. w 3. org/2000/09/xmldsig#enveloped-signature" /> <Transform Algorithm="http: //www. w 3. org/TR/2001/REC-xml-c 14 n-20010315#With. Comments" /> </Transforms> <Digest. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#sha 1" /> <Digest. Value>J/O 0 Hhda. PXxx 49 fg. GWMESL 09 Gp. A=</Digest. Value> </Reference> <Reference URI="#xpointer(/)"> <Transforms> <Transform Algorithm="http: //www. w 3. org/2000/09/xmldsig#enveloped-signature" /> <Transform Algorithm="http: //www. w 3. org/TR/2001/REC-xml-c 14 n-20010315#With. Comments" /> </Transforms> <Digest. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#sha 1" /> <Digest. Value>Mk. L 9 CX 8 ye. ABBth 1 RChy. Px 58 Ls 8 w=</Digest. Value> </Reference>. . . OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 12
<Signature. Value> Wv. ZUJAJ/3 QNqz. Qvwne 2 vvy 7 U 5 Pck 8 ZZ 5 UTa 6 p. Iw. R 7 GE+Po. Gi 6 A 1 kyw== </Signature. Value> <Key. Info> <Retrieval. Method Type="http: //www. w 3. org/2000/09/xmldsig#X 509 Data" URI="#object-4"> <Transforms> <Transform Algorithm="http: //www. w 3. org/TR/1999/REC-xpath-19991116"> <XPath xmlns: dsig="http: //www. w 3. org/2000/09/xmldsig#"> ancestor-or-self: : dsig: X 509 Data </XPath> </Transforms> </Retrieval. Method> </Key. Info> <Object Id="object-1" Mime. Type="text/plain">I am the text. </Object> <Object Encoding="http: //www. w 3. org/2000/09/xmldsig#base 64" Id="object-2" Mime. Type="text/plain">SSBhb. SB 0 a. GUg <Object Id="object-3"> <Non. Commentandus xmlns=""><!-- Commentandum --></Non. Commentandus> </Object> <Manifest Id="manifest-1"> <Reference Id="manifest-reference-1" URI="http: //www. w 3. org/TR/xml-stylesheet"> <Digest. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#sha 1" /> <Digest. Value>60 Nv. Zvtd. TB+7 Unl. Lp/H 24 p 7 h 4 bs=</Digest. Value> </Reference> <Reference URI="#reference-1"> <Digest. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#sha 1" /> <Digest. Value>q. URlo 3 LSq 4 TWQtyg. BZJ 0 i. XQ 9 E 14=</Digest. Value> </Reference> <Reference URI="#notaries"> <Transforms> <Transform Algorithm="http: //www. w 3. org/TR/1999/REC-xslt-19991116"> <xsl: stylesheet xmlns: xsl="http: //www. w 3. org/1999/XSL/Transform" xmlns="http: //www. w 3. org/TR/xhtml <xsl: output encoding="UTF-8" indent="no" method="xml" /> <xsl: template match="/"> <html> <head> <title>Notaries</title>. . . OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 13
<Object Id="object-4"> <X 509 Data> <X 509 Subject. Name> CN=Merlin Hughes, OU=X/Secure, O=Baltimore Technologies Ltd. , ST=Dublin, C=IE </X 509 Subject. Name> <X 509 Issuer. Serial> <X 509 Issuer. Name> CN=Transient CA, OU=X/Secure, O=Baltimore Technologies Ltd. , ST=Dublin, C=IE </X 509 Issuer. Name> <X 509 Serial. Number>1017788370348</X 509 Serial. Number> </X 509 Issuer. Serial> <X 509 Certificate> MIIDUDCCAx. Cg. Aw. IBAg. IGAOz 46 g 2 s. MAk. GByq. GSM 44 BAMwbj. ELMAk. GA 1 UEBh. MCSUUx Dz. ANBg. NVBAg. TBk. R 1 Ymxpbj. Ek. MCIGA 1 UECh. Mb. Qm. Fsd. Gltb 3 Jl. IFRl. Y 2 hub 2 xv. Z 2 ll cy. BMd. GQu. MREw. Dw. YDVQQLEwh. YL 1 Nl. Y 3 Vy. ZTEVMBMGA 1 UEAx. MMVHJhbn. Np. ZW 50 IENB MB 4 XDTAy. MDQw. Mj. Iy. NTkz. MFo. XDTEy. MDQw. Mj. Ix. NTky. NVowbz. ELMAk. GA 1 UEBh. MCSUUx Dz. ANBg. NVBAg. TBk. R 1 Ymxpbj. Ek. MCIGA 1 UECh. Mb. Qm. Fsd. Gltb 3 Jl. IFRl. Y 2 hub 2 xv. Z 2 ll cy. BMd. GQu. MREw. Dw. YDVQQLEwh. YL 1 Nl. Y 3 Vy. ZTEWMBQGA 1 UEAx. MNTWVyb. Glu. IEh 1 Z 2 hl cz. CCAbcwgg. Es. Bgcqhkj. OOAQBMIIBHw. KBg. QDd 454 C+qc. TIWlb 65 NKCt 2 Ptgu. Np. OSn Id 5 wo. Uigu 7 x. Bk 2 QZNAj. Vy. Ih. MEf. SWp 8 i. R 0 Id. KLx+JQLc. NOrcn 0 Wwl 5/hh. W 0 MXsml. S 8 d. M 5 Cq 2 rtm. DHoo. Lxb. GTPqt. ALE 6 vs. XQCk 5 i. Lz 3 Mt. Gh 7 gy. QMZ 7 q 7 HT 5 a 3 I 5 NCh. Ug. Y 1 MMNQVet. RA 1 sus. QIVAIQy 3 BSt. Bjvx 89 Wq 8 Tjr 7 IDP 1 S 8 l. Ao. GBAJ 58 e 4 W 3 Vq. Mxm 7 Zx YJ 2 x. Z 6 KX 0 Ze 10 Wn. KZDy. URn+T 9 i. FIFb. KRFEl. KDeot. Xww. Xw. YON 8 yre 3 ZRGk. C+2+fi. U 2 bdz. IWTT 6 LMb. IMVbk+07 P 4 OZOx. J 6 XWL 9 Gu. Yc. OQc. Nv. X 42 xh 34 DPHdq 4 Xdl. It. MR 25 N A+Od. Z 4 S 8 VVrpb 4 jkj 4 cyir 1628 kg. A 4 GEAAKBg. HH 2 KYoa. QEHnq. Wz. RUu. DAG 0 EYXV 6 Q 4 uc. C 68 MROYSL 6 GKq. NS/AUFbv. H 2 NUx. QD 7 a. Gnt. Yg. YPxi. Ccj 94 i 38 rg. SWg 7 y. SSz 99 MA R/Yv 7 OSd+uej 3 r 6 Tl. XU 34 u++x. Yv. Ro+sv 4 m 9 lb/jm. Xy. ZJKe. C+d. Pqe. U 1 IT 5 k. Cyb. URL ILZfr. Zy. Dsi. U/vhv. Vozow. ODAOBg. NVHQ 8 BAf 8 EBAMCB 4 Aw. EQYDVR 0 OBAo. ECIat. Y 7 SE l. XEOMBMGA 1 Ud. Iw. QMMAq. ACIOGPk. B 2 Mu. KTMAk. GByq. GSM 44 BAMDLw. Aw. LAIUSv. T 02 i. Qj Q 5 da 4 Wpe 0 Bvs 7 Gu. Cc. Vs. CFCEc. Qpbj. Ufnx. XFXNWi. Fy. Q 49 Zr. Wqn </X 509 Certificate> <X 509 Certificate> MIIDSz. CCAwug. Aw. IBAg. IGAOz 46 fw. JMAk. GByq. GSM 44 BAMwbj. ELMAk. GA 1 UEBh. MCSUUx Dz. ANBg. NVBAg. TBk. R 1 Ymxpbj. Ek. MCIGA 1 UECh. Mb. Qm. Fsd. Gltb 3 Jl. IFRl. Y 2 hub 2 xv. Z 2 ll cy. BMd. GQu. MREw. Dw. YDVQQLEwh. YL 1 Nl. Y 3 Vy. ZTEVMBMGA 1 UEAx. MMVHJhbn. Np. ZW 50 IENB MB 4 XDTAy. MDQw. Mj. Iy. NTky. NVo. XDTEy. MDQw. Mj. Ix. NTky. NVowbj. ELMAk. GA 1 UEBh. MCSUUx Dz. ANBg. NVBAg. TBk. R 1 Ymxpbj. Ek. MCIGA 1 UECh. Mb. Qm. Fsd. Gltb 3 Jl. IFRl. Y 2 hub 2 xv. Z 2 ll cy. BMd. GQu. MREw. Dw. YDVQQLEwh. YL 1 Nl. Y 3 Vy. ZTEVMBMGA 1 UEAx. MMVHJhbn. Np. ZW 50 IENB. . . OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 14
That’s no Cryptographic Integrity Primitive… <It’s an application protocol! OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 15
Generality == Complexity == Vulnerability -Tim Newsham, i. SEC Partners <That signature definitely looked like there was fertile ground for misuse by developers and clients. <It’s complex enough to even present a fair bit of trouble for implementers intimately familiar with the specification. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 16
But not a lot of public attention yet. < There have been excellent papers on several of the WS-* security standards in the academic world. < Worth searching the ACM, Springer or IEEE libraries for. < http: //www. zurich. ibm. com/security/identities/ < There are even full formal proofs of some of these protocols. < But they often start with sentences like: “Assume that the participating computers and the user’s browser B are correct. ” OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 17
What the architect designed… A formally correct mechanism for putting burning logs right in the middle of your house, safely. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 18
What the reviewer sometimes finds: Photo Credit: Jeff Leighton, Inspect-It 1 st Property Inspection. Used with permission. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 19
Attack Surface Analysis <Typical for applications – start with a threat model. <Enumerate all the entry points, interfaces and operations. <Which are anonymously accessible? 4 Available to authenticated users? 4 Authorized to all users, administrators, or an individual user? <Locally or remotely accessible? <Complexity of inputs or operations, dependencies, assumptions. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 20
HTTPS (a bit simplified) Symmetric KSESSION derived from X. 509 certs & DH key exchange A TLS Message 1 Messagen B Channel privacy & integrity with K SESSION • Per-session key exchange • Only X. 509 certificates supported as keys • Multiple messages over single session • No preservation of evidence • Difficult to compose with reliable delivery • Opaque to intermediaries • Messages only protected in the channel • Forward secrecy with DH key exchange OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 21
WS-Security (One of many possibilities. ) Kc A Mp 1 Mp 2 Sign KA C Mp 3 Mp 1 M p 2 M Sign KA Sign KC HTTPS JMS TCP B Encrypt KB • Durable security • Selective security • Mixed key/token types • Mixed key exchange • Intermediate actors • Composable assertions • Transport agnostic D OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 KB 22
WS-Actually Get Some Work Done WS-Security WS-Federation WS-Policy WS-Security Policy WS-Secure. Conversation WS-Trust XML Encryption SAML Kerberos X. 509 Security Token Profiles XML Digital Signatures XML, SOAP, WSDL, Schema, WS-Addressing, etc. . Net TCP Channel, Fast Info. Set, etc. HTTP SSL OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 23
SSL OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 24
WS-Security WS-Federation WS-Policy WS-Security Policy WS-Secure. Conversation WS-Trust XML Encryption SAML Kerberos X. 509 Security Token Profiles XML Digital Signatures XML, SOAP, WSDL, Schema, WS-Addressing, etc. HTTP . Net TCP Channel, Fast Info. Set, etc. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 25
Goals of XMLDSIG in WS-Security < Sign arbitrary digital content. < Sign the semantic intent of an XML document, (the “Info. Set”) not an octet stream. (binary XML encoding compatibility) < Cryptographic algorithm and key format agility. < Indirected and flexible referencing of the signed content. < Optionally supply keying info as part of the signature, with flexible referencing thereof. < Allow exclusion of portions of content from the signature. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 26
Counter-intuitive Integrity <Lots of stuff can change without invalidating the signature. <Important if you’re building a complex WS-* processing pipeline with XML firewalls, security gateways, reliable messaging proxies, etc. <But tricky & dangerous when you don’t need all that stuff. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 27
The Structure & Properties of XML Digital Signatures OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 28
Hash Content to Sign 7/XTs. Ha. BSOn. J/j. XD 5 v 0 z. L 6 VKYsk= <XML> Jxk 7 ND 0/Nqxn. U 7522 u. Kzzi 2/vx== JPEG <Signed. Info> URI Reference XML Metadata Key </Signed. Info> Hash MF 298 zmadkae 3/4 nsf 7 a 43 j 8 vn. B Signature ov 3 HOo. PN 0 w 71 N 3 Dd. GNh. N+d. Sz. Qm 6 NJFUB 5 q. GKRp 9 Q 986 n. Vz. Mb 8 w. CIVx CQu+x 3 v. Mtqp 4/R 3 KEc. Pt. EJSao. R+ th. Gq++GPIhm. ZXy. WJs 3 x. Hy 9 P 4 xmo TVwli 7/l 7 s 8 eb. DSmnb. Z 7 x. ZU 4 Iy 1 BSZSx. GKn. RG+Z/0 GJIf. Tz 8 jh. H 6 w. C e 3 l 03 L 4= OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 29
Basic structure of an XMLDSIG <Signed Info 4 Metadata describing the content being signed. <Signature Value 4 Signature of the digest of the Signed Info metadata <Key Info 4 Metadata about or the actual key used. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 30
<? xml version="1. 0" encoding="UTF-8"? > <Signature xmlns="http: //www. w 3. org/2000/09/xmldsig#"> <Signed. Info> <Canonicalization. Method Algorithm="http: //www. w 3. org/TR/2001/REC-xml-c 14 n-20010315" /> <Signature. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#rsa-sha 1" /> <Reference URI="#object"> <Digest. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#sha 1" /> <Digest. Value>7/XTs. Ha. BSOn. J/j. XD 5 v 0 z. L 6 VKYsk=</Digest. Value> <Transforms> <Transform Algorithm="http: //www. w 3. org/TR/2001/REC-xml-c 14 n-20010315"/> </Transforms> </Reference> </Signed. Info> <Signature. Value> ov 3 HOo. PN 0 w 71 N 3 Dd. GNh. N+d. Sz. Qm 6 NJFUB 5 q. GKRp 9 Q 986 n. Vz. Mb 8 w. CIVx. CQu+x 3 v. Mtq p 4/R 3 KEc. Pt. EJSao. R+th. Gq++GPIh 2 m. ZXy. WJs 3 x. Hy 9 P 4 xmo. TVwli 7/l 7 s 8 eb. DSmnb. Z 7 x. ZU 4 Iy 1 BSMZSx. GKn. RG+Z/0 GJIf. Tz 8 jh. H 6 w. Ce 3 l 03 L 4= </Signature. Value> <Key. Info> <Key. Value> <RSAKey. Value> <Modulus> q 07 hpx. A 5 DGFfv. JFZue. Fl/LI 85 Xx. Qxrvqg. Vug. L 25 V 090 A 9 Mrl. LBg 5 Pm. Asx. FTe+G 6 a xv. WJQw. YOVHj/nui. Cn. NLa 9 a 7 u. At. PFi. Tt. W+v 5 H 3 wl. La. Y 3 ws 4 at. RBNOQl. Yk. IBp 38 s. Tf QBkk 4 i 8 PEU 1 GQ 2 M 0 CLIJq 4/2 Akfv 1 wxz. SQ 9+8 o. Wk. Arc= </Modulus> <Exponent> AQAB </Exponent> </RSAKey. Value> </Key. Info> <Object Id="object">some text</Object> </Signature> OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 31
<? xml version="1. 0" encoding="UTF-8"? > <Signature xmlns="http: //www. w 3. org/2000/09/xmldsig#"> <Signed. Info> <Canonicalization. Method Algorithm="http: //www. w 3. org/TR/2001/REC-xml-c 14 n-20010315" /> <Signature. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#rsa-sha 1" /> <Reference URI="#object"> <Digest. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#sha 1" /> <Digest. Value>7/XTs. Ha. BSOn. J/j. XD 5 v 0 z. L 6 VKYsk=</Digest. Value> <Transforms> <Transform Algorithm="http: //www. w 3. org/TR/2001/REC-xml-c 14 n-20010315"/> </Transforms> </Reference> </Signed. Info> <Signature. Value> ov 3 HOo. PN 0 w 71 N 3 Dd. GNh. N+d. Sz. Qm 6 NJFUB 5 q. GKRp 9 Q 986 n. Vz. Mb 8 w. CIVx. CQu+x 3 v. Mtq p 4/R 3 KEc. Pt. EJSao. R+th. Gq++GPIh 2 m. ZXy. WJs 3 x. Hy 9 P 4 xmo. TVwli 7/l 7 s 8 eb. DSmnb. Z 7 x. ZU 4 Iy 1 BSMZSx. GKn. RG+Z/0 GJIf. Tz 8 jh. H 6 w. Ce 3 l 03 L 4= </Signature. Value> <Key. Info> <Key. Value> <RSAKey. Value> <Modulus> q 07 hpx. A 5 DGFfv. JFZue. Fl/LI 85 Xx. Qxrvqg. Vug. L 25 V 090 A 9 Mrl. LBg 5 Pm. Asx. FTe+G 6 a xv. WJQw. YOVHj/nui. Cn. NLa 9 a 7 u. At. PFi. Tt. W+v 5 H 3 wl. La. Y 3 ws 4 at. RBNOQl. Yk. IBp 38 s. Tf QBkk 4 i 8 PEU 1 GQ 2 M 0 CLIJq 4/2 Akfv 1 wxz. SQ 9+8 o. Wk. Arc= </Modulus> <Exponent> AQAB </Exponent> </RSAKey. Value> </Key. Info> <Object Id="object">some text</Object> </Signature> OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 32
<Signature. Value> <The simplest of our elements. <Base 64 encoded signature of the digest of the canonicalized <Signed. Info> element. <Worth repeating: XMLDSIGs are indirected signatures. It is a signature of the hash of the metadata about the signed data. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 33
<? xml version="1. 0" encoding="UTF-8"? > <Signature xmlns="http: //www. w 3. org/2000/09/xmldsig#"> <Signed. Info> <Canonicalization. Method Algorithm="http: //www. w 3. org/TR/2001/REC-xml-c 14 n-20010315"/> <Signature. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#rsa-sha 1" /> <Reference URI="#object"> <Digest. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#sha 1" /> <Digest. Value>7/XTs. Ha. BSOn. J/j. XD 5 v 0 z. L 6 VKYsk=</Digest. Value> <Transforms> <Transform Algorithm="http: //www. w 3. org/TR/2001/REC-xml-c 14 n-20010315"/> </Transforms> </Reference> </Signed. Info> <Signature. Value> ov 3 HOo. PN 0 w 71 N 3 Dd. GNh. N+d. Sz. Qm 6 NJFUB 5 q. GKRp 9 Q 986 n. Vz. Mb 8 w. CIVx. CQu+x 3 v. Mtq p 4/R 3 KEc. Pt. EJSao. R+th. Gq++GPIh 2 m. ZXy. WJs 3 x. Hy 9 P 4 xmo. TVwli 7/l 7 s 8 eb. DSmnb. Z 7 x. ZU 4 Iy 1 BSMZSx. GKn. RG+Z/0 GJIf. Tz 8 jh. H 6 w. Ce 3 l 03 L 4= </Signature. Value> <Key. Info> <Key. Value> <RSAKey. Value> <Modulus> q 07 hpx. A 5 DGFfv. JFZue. Fl/LI 85 Xx. Qxrvqg. Vug. L 25 V 090 A 9 Mrl. LBg 5 Pm. Asx. FTe+G 6 a xv. WJQw. YOVHj/nui. Cn. NLa 9 a 7 u. At. PFi. Tt. W+v 5 H 3 wl. La. Y 3 ws 4 at. RBNOQl. Yk. IBp 38 s. Tf QBkk 4 i 8 PEU 1 GQ 2 M 0 CLIJq 4/2 Akfv 1 wxz. SQ 9+8 o. Wk. Arc= </Modulus> <Exponent> AQAB </Exponent> </RSAKey. Value> </Key. Info> <Object Id="object">some text</Object> </Signature> OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 34
<Signed. Info>: Content Metadata <Canonicalization Method <Signature Method <One or more References 4 Transforms 4 Digest Method 4 Digest Value OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 35
<? xml version="1. 0" encoding="UTF-8"? > <Signature xmlns="http: //www. w 3. org/2000/09/xmldsig#"> <Signed. Info> <Canonicalization. Method Algorithm="http: //www. w 3. org/TR/2001/REC-xml-c 14 n-20010315"/> <Signature. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#rsa-sha 1" /> <Reference URI="#object"> <Digest. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#sha 1" /> <Digest. Value>7/XTs. Ha. BSOn. J/j. XD 5 v 0 z. L 6 VKYsk=</Digest. Value> <Transforms> <Transform Algorithm="http: //www. w 3. org/TR/2001/REC-xml-c 14 n-20010315"/> </Transforms> </Reference> </Signed. Info> <Signature. Value> ov 3 HOo. PN 0 w 71 N 3 Dd. GNh. N+d. Sz. Qm 6 NJFUB 5 q. GKRp 9 Q 986 n. Vz. Mb 8 w. CIVx. CQu+x 3 v. Mtq p 4/R 3 KEc. Pt. EJSao. R+th. Gq++GPIh 2 m. ZXy. WJs 3 x. Hy 9 P 4 xmo. TVwli 7/l 7 s 8 eb. DSmnb. Z 7 x. ZU 4 Iy 1 BSMZSx. GKn. RG+Z/0 GJIf. Tz 8 jh. H 6 w. Ce 3 l 03 L 4= </Signature. Value> <Key. Info> <Key. Value> <RSAKey. Value> <Modulus> q 07 hpx. A 5 DGFfv. JFZue. Fl/LI 85 Xx. Qxrvqg. Vug. L 25 V 090 A 9 Mrl. LBg 5 Pm. Asx. FTe+G 6 a xv. WJQw. YOVHj/nui. Cn. NLa 9 a 7 u. At. PFi. Tt. W+v 5 H 3 wl. La. Y 3 ws 4 at. RBNOQl. Yk. IBp 38 s. Tf QBkk 4 i 8 PEU 1 GQ 2 M 0 CLIJq 4/2 Akfv 1 wxz. SQ 9+8 o. Wk. Arc= </Modulus> <Exponent> AQAB </Exponent> </RSAKey. Value> </Key. Info> <Object Id="object">some text</Object> </Signature> OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 36
Canonicalization (C 14 N) < How to get the One True Bag of Bits in an XML node set. 4 Required for the <Signed. Info> element 4 Optional for a <Reference> (to external, non-XML content) < Eliminate or normalize non-semantic variability from the signed content. 4 Namespaces 4 Whitespace 4 Comments 4 CDATA 4 Entities < Also important for binary XML encoding < Some Type 2 error (false negatives). 4 Difficult to debug, but not especially problematic from a security perspective. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 37
Theme: Mismatched assumptions. <Matching security assumptions and assertions to your audience is important. <Standards committees and architects with deep domain knowledge have a ways to go in learning to think like an average developer. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 38
The Average Developer <Is Lazy. 4 One of the characteristics of all great programmers. <Probably does care about security. 4 But certificates, SSL, Kerberos, etc. are magic. <Trusts the API developer. 4 No choice if you want to get stuff done. 4 A lot of trust for security APIs. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 39
Assumption 1: Complexity & Do. S <Standards Committee: “It’s XML – there are many ways to introduce arbitrary complexity and denial of service is just a given. It’s not our problem. ” OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 40
Assumption 1: Complexity & Do. S <Security-minded developer: “I wish XML were less complex, but if I follow best practices I can do it safely. ” § Don’t allow DTDs § Don’t expand entities § Don’t resolve externals § Limit parse depth § Limit total input size Remember these bestpractices for safe XML processing. We will see how XML Signatures force you to violate almost all of them! <This isn’t actually a bad assumption! OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 41
Assumption 1: Complexity & Do. S <Average Developer: “I authenticate my XML inputs with a signature now, so I don’t have to worry about all that stuff. ” OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 42
C 14 N Entity Expansion Attacks <C 14 N’s treatment of entities requires expansion. <Do. S attacks are possible here using recursive entity expansion. <Have to canonicalize <Signed. Info> to check signature, so this is anonymous attack surface. <DTDs disallowed in SOAP, but this attack can apply to other systems, e. g. SAML processors. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 43
Example Entity Expansion < This document expands to around 2 GB when parsed: <!DOCTYPE foo [ <!ENTITY a "1234567890" > <!ENTITY b "&a; &a; " <!ENTITY c "&b; &b; " <!ENTITY d "&c; &c; " <!ENTITY e "&d; &d; " <!ENTITY f "&e; &e; " <!ENTITY g "&f; &f; " <!ENTITY h "&g; &g; " <!ENTITY i "&h; &h; " <!ENTITY j "&i; &i; " <!ENTITY k "&j; &j; " <!ENTITY l "&k; &k; " <!ENTITY m "&l; &l; " ]> <foo> fooo &m; bar </foo> > > > OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 44
C 14 N is expensive, in general. <A somewhat complex algorithm with large resource requirements. 4 Build a DOM, validate, canonicalize, serialize. <Schema and specification do not limit the number of C 14 N transforms that may be applied to a reference. <Could detect and optimize away redundant C 14 N, but I have not seen anyone do this yet. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 45
<Reference …> <Transforms> <Transform algorithm=“http: //www. w 3. org/TR/2001/REC-xml-c 14 n-20010315”/> <Transform algorithm=“http: //www. w 3. org/TR/2001/REC-xml-c 14 n-20010315”/> … </Transforms> … </Reference> OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 46
C 14 N with Comments & Hash Collisions < OPTIONAL algorithm, but almost always supported < Comments may be semantically significant in the doc. < But are they ever in the <Signed. Info> metadata? 4 Almost certainly not even examined. < An unusual degree of freedom in crafting a hash collision that is still well-formed and doesn’t disturb application semantics. 4 Still beyond today’s state of the art, but maybe not for long. < Paranoid implementation should disallow C 14 N with comments for <Signed. Info> OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 47
<? xml version="1. 0" encoding="UTF-8"? > <Signature xmlns="http: //www. w 3. org/2000/09/xmldsig#"> <Signed. Info> <Canonicalization. Method Algorithm="http: //www. w 3. org/TR/2001/REC-xml-c 14 n-20010315"/> <Signature. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#rsa-sha 1" /> <Reference URI="#object"> <Digest. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#sha 1" /> <Digest. Value>7/XTs. Ha. BSOn. J/j. XD 5 v 0 z. L 6 VKYsk=</Digest. Value> <Transforms> <Transform Algorithm="http: //www. w 3. org/TR/2001/REC-xml-c 14 n-20010315"/> </Transforms> </Reference> </Signed. Info> <Signature. Value> ov 3 HOo. PN 0 w 71 N 3 Dd. GNh. N+d. Sz. Qm 6 NJFUB 5 q. GKRp 9 Q 986 n. Vz. Mb 8 w. CIVx. CQu+x 3 v. Mtq p 4/R 3 KEc. Pt. EJSao. R+th. Gq++GPIh 2 m. ZXy. WJs 3 x. Hy 9 P 4 xmo. TVwli 7/l 7 s 8 eb. DSmnb. Z 7 x. ZU 4 Iy 1 BSMZSx. GKn. RG+Z/0 GJIf. Tz 8 jh. H 6 w. Ce 3 l 03 L 4= </Signature. Value> <Key. Info> <Key. Value> <RSAKey. Value> <Modulus> q 07 hpx. A 5 DGFfv. JFZue. Fl/LI 85 Xx. Qxrvqg. Vug. L 25 V 090 A 9 Mrl. LBg 5 Pm. Asx. FTe+G 6 a xv. WJQw. YOVHj/nui. Cn. NLa 9 a 7 u. At. PFi. Tt. W+v 5 H 3 wl. La. Y 3 ws 4 at. RBNOQl. Yk. IBp 38 s. Tf QBkk 4 i 8 PEU 1 GQ 2 M 0 CLIJq 4/2 Akfv 1 wxz. SQ 9+8 o. Wk. Arc= </Modulus> <Exponent> AQAB </Exponent> </RSAKey. Value> </Key. Info> <Object Id="object">some text</Object> </Signature> OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 48
<Reference> <References describe what is being signed. <Identify the signed content with a URI. <Transforms to refine the specification or canonicalize. <Specify the digest method and digest value. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 49
<Reference> <All references are primarily identified by a URI. 4 Full document reference: URI="" 4 XPointer § Bare: URI="#object" § Object Reference: URI="#xpointer(id('object'))" § Same-document XPath: URI="xpointer(/)" 4 External reference: URI="http: //www. w 3. org/TR/xml-stylesheet" OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 50
<Reference> <Three types of signatures: 4 Enveloping: References are descendants of the signature in the XML document. 4 Enveloped: Signature is a descendant of the signed content. 4 Detached: Signed content is a sibling or at an external location. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 51
External References < Just failed another of our best practices. < An attacker can insert a malicious external reference, and you have to chase it to see if the signature validates. < No simple flag to turn this off in, e. g. Java APIs. 4 Maybe not valid in WS-Security context: “elements contained in the signature SHOULD refer to a resource within the enclosing SOAP envelope” § http: //www. oasis-open. org/committees/download. php/16790/wss-v 1. 1 -spec-os-SOAPMessage. Security. pdf 4 Important to API clients. 4 Callers need to provide a custom URIDereferencer implementation. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 52
Time of Check, Time of Use < What if an external reference changes or becomes unavailable? 4 Fetch on validate, fetch again on use. Provide malicious content the second time, repudiate transaction, etc. < Need to use cached reference retrieval. < Java provides API support, but it is not a default behavior. < Can’t do it in correctly with. Net APIs OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 53
This is bad. <The need to pull from the validation cache makes for a very tight coupling between the security and application layer. <Is there any way to do this correctly from an network-edge security gateway? 4 Similar to Newsham and Ptacek’s work on IDS evasion 4 More research needed here OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 54
XPath & XPointer < References to XML content to be signed can also be identified by an XPath or XPointer expression. < This can be complex and resource intensive. < XPath Filter 2. 0 (intersect, subtract, union) is also available as a Transform. 4 This was specifically created because XPath was becoming an accidental Do. S vector. < Specify an unlimited number of XPath Filters (interleaved with C 14 N for good measure) for a good Do. S. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 55
XPath & XPointer <Another failure of the complexity & Do. S assumption mismatch. <WS-Security recommends against, but again does not forbid, XPath & XPointer reference URIs. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 56
New Theme: “Security’s Worst Enemy is Complexity” <Seen more than a bit of this already. <More to come. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 57
Frisky References <Content referenced by ID or an ambiguous XPath can be moved about in the document without invalidating the signature. <This a document-specific attack, but elements with contextual semantics must be signed in-situ for safety. <E. g. the following two documents both verify with the same signature value: OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 58
Naïvely sign just the price to prevent modification… <order> <item> <name>Box of Pencils</name> <price Id="p 1">$1. 50</price> <quantity>1</quantity> </item> <name>Laptop</name> <price Id="p 2">$2500. 00</price> <quantity>100</quantity> </item> </order> <Signature xmlns="http: //www. w 3. org/2000/09/xmldsig#"> <Signed. Info>. . . <Reference URI="#xpointer(id('p 1'))">. . . </Reference> <Reference URI="#xpointer(id('p 2'))">. . . </Reference> </Signed. Info> <Signature. Value>. . . </Signature. Value> <Key. Info>. . . </Key. Info> </Signature> OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 59
Signature still valid: very different semantics. <order> <item> <name>Box of Pencils</name> <price Id="p 2">$2500. 00</price> <quantity>1</quantity> </item> <name>Laptop</name> <price Id="p 1">$1. 50</price> <quantity>100</quantity> </item> </order> <Signature xmlns="http: //www. w 3. org/2000/09/xmldsig#"> <Signed. Info>. . . <Reference URI="#xpointer(id('p 1'))">. . . </Reference> <Reference URI="#xpointer(id('p 2'))">. . . </Reference> </Signed. Info> <Signature. Value>. . . </Signature. Value> <Key. Info>. . . </Key. Info> </Signature> OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 60
“Element Wrapping Attacks” <Discussed briefly in WS-Security standard with regard to SOAP headers. 4 Moving elements from optional vs. must-understand <“XML Signature Element Wrapping Attacks and Countermeasures” Michael Mc. Intosh & Paula Austel IBM Research, Hawthorne, NY Workshop On Secure Web Services Proceedings of the 2005 Workshop on Secure Web Services ACM Press http: //portal. acm. org/citation. cfm? id=1103026&jmp=cit&coll=ACM&dl=ACM&CFID=14005269&CFTOKEN=77983358#CIT OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 61
Wrapper’s Delight <Not just repositioning signed elements. 4 An attacker can also add or delete content or modify the unsigned portions without breaking the signature. 4 Applies to overly specific XPointers, XPath and Filters as well as references by Id. <Again, need to pull content directly from validation cache. 4 More tight coupling to the security layer 4 More attacks possible against gateway appliances OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 62
<? xml version="1. 0" encoding="UTF-8"? > <Signature xmlns="http: //www. w 3. org/2000/09/xmldsig#"> <Signed. Info> <Canonicalization. Method Algorithm="http: //www. w 3. org/TR/2001/REC-xml-c 14 n-20010315"/> <Signature. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#rsa-sha 1" /> <Reference URI="#object"> <Digest. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#sha 1" /> <Digest. Value>7/XTs. Ha. BSOn. J/j. XD 5 v 0 z. L 6 VKYsk=</Digest. Value> <Transforms> <Transform Algorithm="http: //www. w 3. org/TR/2001/REC-xml-c 14 n-20010315"/> </Transforms> </Reference> </Signed. Info> <Signature. Value> ov 3 HOo. PN 0 w 71 N 3 Dd. GNh. N+d. Sz. Qm 6 NJFUB 5 q. GKRp 9 Q 986 n. Vz. Mb 8 w. CIVx. CQu+x 3 v. Mtq p 4/R 3 KEc. Pt. EJSao. R+th. Gq++GPIh 2 m. ZXy. WJs 3 x. Hy 9 P 4 xmo. TVwli 7/l 7 s 8 eb. DSmnb. Z 7 x. ZU 4 Iy 1 BSMZSx. GKn. RG+Z/0 GJIf. Tz 8 jh. H 6 w. Ce 3 l 03 L 4= </Signature. Value> <Key. Info> <Key. Value> <RSAKey. Value> <Modulus> q 07 hpx. A 5 DGFfv. JFZue. Fl/LI 85 Xx. Qxrvqg. Vug. L 25 V 090 A 9 Mrl. LBg 5 Pm. Asx. FTe+G 6 a xv. WJQw. YOVHj/nui. Cn. NLa 9 a 7 u. At. PFi. Tt. W+v 5 H 3 wl. La. Y 3 ws 4 at. RBNOQl. Yk. IBp 38 s. Tf QBkk 4 i 8 PEU 1 GQ 2 M 0 CLIJq 4/2 Akfv 1 wxz. SQ 9+8 o. Wk. Arc= </Modulus> <Exponent> AQAB </Exponent> </RSAKey. Value> </Key. Info> <Object Id="object">some text</Object> </Signature> OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 63
Transforms <Extra processing instructions 4 Refine selection of signed content 4 Additional steps to arrive at the correct digest <We’ve already seen: 4 Canonicalization 4 XPath Filter 2. 0 <Base 64 <Anything else interesting? OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 64
Enveloped & Enveloping Signatures <Modeled as Transforms. <Extract the signature from the content, or viceversa, before canonicalizing & digesting. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 65
Extensible Stylesheet Language Transforms (XSLT) <XSLT is a language for processing and transforming XML documents. <Used for content extraction or, most commonly, transforming XML content from one format to another. <A pattern-matching template processor takes a source and template document and produces a third document as output. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 66
XSLT <Provide an extremely expressive means to select content for signing. <“Sign what is meant, not what is said. ” <But too clever by half. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 67
Theme: Dependency Analysis <Taking dependencies on other components or code correlates strongly with security defects. <Threat models don’t always match up. 4“What do you mean, my code is reachable from an anonymous network surface? ” <Dependencies evolve independently. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 68
Mismatched Assumptions, Again <XSLT is not just XPath++. <It’s a Turing-complete programming language. <Infinite resource consumption possible with tiny messages. (e. g. loops) <Cryptographers tend to think in terms of pure functions and mathematical operations. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 69
The big collision. <But developers want functionality and functionality is attack surface. <XSLT as specified in 1999 was a functional programming language. <No side effects. No I/O. No access to OS facilities. 4“Just another Do. S. ” OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 70
Not really: More network operations. <Pull in an external stylesheet with xsl: include and xsl: import <Pull in arbitrary external content with the document() function during the transform. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 71
The Killer: XSLT Extensions < All in one place: 4 Insecure Dependencies 4 Complexity 4 Mismatched Assumptions. < XSLT is complicated. Code reuse and modularity is great! Just import somebody else’s implementation. < And its extensions. (whoops) 4 Scripting 4 Arbitrary file system and UNC path writes 4 SQL 4 Bind XML namespaces to the classpath and execute arbitrary code. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 72
<xsl: stylesheet version="1. 0" xmlns: xsl="http: //www. w 3. org/1999/XSL/Transform" xmlns: rt="http: //xml. apache. org/xalan/java. lang. Runtime" xmlns: ob="http: //xml. apache. org/xalan/java. lang. Object" exclude-result-prefixes= "rt, ob"> <xsl: template match="/"> <xsl: variable name="runtime. Object" select="rt: get. Runtime()"/> <xsl: variable name="command" select="rt: exec($runtime. Object, ' c: Windowssystem 32cmd. exe' )"/> <xsl: variable name="command. As. String" select="ob: to. String($command)"/> <xsl: value-of select="$command. As. String"/> </xsl: template> </xsl: stylesheet> OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 73
<xsl: stylesheet xmlns: xsl="http: //www. w 3. org/1999/XSL/Transform" xmlns: xsltc="http: //xml. apache. org/xalan/xsltc" xmlns: redirect="http: //xml. apache. org/xalan/redirect" extension-element-prefixes="xsltc redirect" version="1. 0"> <xsl: template match="/"> <xsltc: output file="blob. xml"> <xsl: text>This ends up in the file 'blob. xml'</xsl: text> </xsltc: output> <redirect: write file="\arbitrary. UNCPath"> <xsl: text>This ends up at an arbitrary UNC path!</xsl: text> </redirect: write> </xsl: template> </xsl: stylesheet> OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 74
<xsl: stylesheet xmlns: xsl="http: //www. w 3. org/1999/XSL/Transform" version="1. 0" xmlns: xalan="http: //xml. apache. org/xalan" xmlns: my-ext="ext 1" extension-element-prefixes="my-ext"> <!--The component and its script are in the xalan namespace and define the implementation of the extension. --> <xalan: component prefix="my-ext" functions= "ownage"> <xalan: script lang="javascript"> // Fun, arbitrary Java. Script in the JVM! BSF also available. </xalan: script> </xalan: component> OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 75
Available on most XSLT processors < Those were examples from Xalan-J. < Dangerous extensions available in: 4 Xalan-XSLTC 4 Saxon 4 jd. xslt 4 Oracle XDK 10 g 4 Sablotron 4 XT 4 Unicorn < <msxml: script>, <msxsl: script>, <ms: script> allow JScript, VBScript and. Net languages 4 Off by default in MSXML 6. 4 But. Net doesn’t have all the same defaults. Haven’t tried yet with System. Security. Cryptography. Xml. Signed. Xml OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 76
Optional, but widely implemented < 2003 reported interoperability results for XSLT Transform < http: //www. w 3. org/Signature/2001/04/05 -xmldsig-interop. html 4 Baltimore (gone, unknown disposition of XMLDSIG technology) 4 HP 4 IAIK 4 IBM 4 Microsoft 4 NEC 4 Phaos (now Oracle) 4 Apache 4 XMLSec 4 Data. Power (now IBM) OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 77
No idea, no API. <XMLSec is the only API I’ve looked at that allows disabling XSLT. 4 In part because it requires you to install the 3 rd party library yourself. <Nobody has any idea that this stuff is there. <Even if they do, they have no way to turn it off. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 78
What next? <We’ve seen the basic structure of references and reference processing. <<Key. Info> will come later. <Why would we execute all this content if it was attacker modified? I trust the people I have keys from, and modified signatures wouldn’t verify. <Let’s see how to verify a signature… OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 79
Validation of an XML Digital Signature http: //www. w 3. org/TR/xmldsig-core/#sec-Core. Validation OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 80
What does this mean? 1) Process every Reference, derive a digest value and compare it. 2) Canonicalize and digest the entire Signed. Info element and compare to the decrypted the “Signature. Value”. 3) According to deep discussion on the mailing lists, this order is non-normative[1], but… THIS IS THE WRONG ORDER OF OPERATIONS. [1] http: //lists. w 3. org/Archives/Public/w 3 c-ietf-xmldsig/2001 Oct. Dec/0064 OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 81
Pure Functions vs. Attack Surface <Cryptographically, the order of operations is not important. <Assuming no side effects. <But we’ve seen some major potential side effects from digest verification. <This order of operations puts all that on the anonymous attack surface. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 82
Correct Order of Operations <First see if the signature is even from a key you trust. <Then validate the Signature. Value against the Signed. Info. <Then verify the digests. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 83
Implementers follow the specification <Combine the wrong order of operations with XSLT extensions. <Anonymous, remote code execution with invalid signature. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 84
The Fallout <About a dozen Sun products – anything using the JSR 105 APIs, including the core JDK 6. <IAIK Java Crypto Toolkits <BEA Jrockit <Several more with Denial of Service vulnerabilities that haven’t patched. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 85
Definitely wormable. < Can include multiple Transforms in a signature. < Same attack surface on the client and server. < Reliable cross-platform execution. < XSLT makes self-duplication easy with select(“/”) < UDDI would make a nice worm propagation directory. 4 UDDI v 3 supports XMLDSIG, and suggests use of XSLT transforms. 4 At least the UBR is dead. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 86
More on order of operations. <Java does expose enough of the internal operations for API clients to do it right -- if they’re cautious. <. Net? Documents the incorrect order in: 4 B. La. Macchia, S. Lange, M. Lyons, R. Martin, and K. Price. . NET Framework Security. Addison-Wesley, Boston, MA, USA, 2002. <APIs of the form: public Key. Info validate(sig) 4 Standard in both. Net and Java. 4 Clearly defective. No opportunity for a trust decision until it is already too late. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 87
Independent Rediscovery of Prior Results “XML Signature Extensibility Using Custom Transforms” Laurence Bull and David M. Squire School of Computer Science and Software Engineering, Monash University, Australia 5 th International Conference on Web Information Systems Engineering, Brisbane, Australia, November 22 -24, 2004 Web Information Systems – WISE 2004, pp 102 -112 Lecture Notes in Computer Science Springer Berlin / Heidelberg ISBN: 978 -3 -540 -23894 -2 http: //springerlink. com/content/qp 0 eyrbgdcn 47 jh 1 OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 88
Bull & Squire < Discuss risks of arbitrary transforms, ‘active’ transforms, and the risks in the implied order of operations for signature validation. < Didn’t appear to pick up on just how bad it was with existing algorithms. < The primary thrust of the paper is suggesting the inclusion into the XMLDSIG specification of arbitrary binary transforms, either inline or pulled from a URI. < It recognizes that this might be a bit dangerous, but suggests that CAs could expand their business model to sign transformations. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 89
NOOOO!! OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 90
Always on the anonymous surface: <Even the correct order of operations leaves unauthenticated complexity. <Parsing & Canonicalization of the Signed. Info. <Key. Info. What does that look like? OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 91
<? xml version="1. 0" encoding="UTF-8"? > <Signature xmlns="http: //www. w 3. org/2000/09/xmldsig#"> <Signed. Info> <Canonicalization. Method Algorithm="http: //www. w 3. org/TR/2001/REC-xml-c 14 n-20010315" /> <Signature. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#rsa-sha 1" /> <Reference URI="#object"> <Digest. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#sha 1" /> <Digest. Value>7/XTs. Ha. BSOn. J/j. XD 5 v 0 z. L 6 VKYsk=</Digest. Value> <Transforms> <Transform Algorithm="http: //www. w 3. org/TR/2001/REC-xml-c 14 n-20010315"/> </Transforms> </Reference> </Signed. Info> <Signature. Value> ov 3 HOo. PN 0 w 71 N 3 Dd. GNh. N+d. Sz. Qm 6 NJFUB 5 q. GKRp 9 Q 986 n. Vz. Mb 8 w. CIVx. CQu+x 3 v. Mtq p 4/R 3 KEc. Pt. EJSao. R+th. Gq++GPIh 2 m. ZXy. WJs 3 x. Hy 9 P 4 xmo. TVwli 7/l 7 s 8 eb. DSmnb. Z 7 x. ZU 4 Iy 1 BSMZSx. GKn. RG+Z/0 GJIf. Tz 8 jh. H 6 w. Ce 3 l 03 L 4= </Signature. Value> <Key. Info> <Key. Value> <RSAKey. Value> <Modulus> q 07 hpx. A 5 DGFfv. JFZue. Fl/LI 85 Xx. Qxrvqg. Vug. L 25 V 090 A 9 Mrl. LBg 5 Pm. Asx. FTe+G 6 a xv. WJQw. YOVHj/nui. Cn. NLa 9 a 7 u. At. PFi. Tt. W+v 5 H 3 wl. La. Y 3 ws 4 at. RBNOQl. Yk. IBp 38 s. Tf QBkk 4 i 8 PEU 1 GQ 2 M 0 CLIJq 4/2 Akfv 1 wxz. SQ 9+8 o. Wk. Arc= </Modulus> <Exponent> AQAB </Exponent> </RSAKey. Value> </Key. Info> <Object Id="object">some text</Object> </Signature> OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 92
<Key. Info> <One of: 4 Key Value 4 Key Name 4 X 509 Data 4 Retrieval Method § URI § Transforms OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 93
Anonymous Attack Surface <Key. Info is not integrity protected. 4 Could be referenced in Signed. Info, but you’d still need to resolve it first to actually validate it. <And it can look a lot like a <Reference> 4 Remote URIs 4 Complex XPath expressions 4 Transforms OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 94
No Safe Order of Operations <All the same risks of <Reference> processing. <Again, APIs fail the user by not providing adequate knobs and switches to harden this. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 95
And, a punt. < Establishing trust in a key is completely out of scope. 4 Reasonable enough. 4 But remember the mediocre developer. < Most SSL APIs enforce chaining certs to a trusted root by default, and many, many developers still get SSL wrong. < The naïve developer who assumes DSIG APIs “just work”, like SSL, accomplishes nothing but increasing his attack surface dramatically. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 96
If it’s hard, fail by default. < The average developer only keeps going until it “works”. < KU/EKU certificate extensions? Chaining? Not a clue. < Failing closed is a signal that the trust model is something that needs consideration. < Re-structure the API to highlight this: 4 public boolean validate(Signature s, Key. Trust. Manager ktm) OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 97
Simplicity is not always good. <XMLDSIG is a great case study where providing only a simple public API to a very complex underlying technology is crippling. <Callers should be enable different transform algorithms and URI/XML resolvers with different properties for the anonymous and the authenticated attack surface. <No APIs I’ve seen come close to providing this. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 98
Any mitigations? <Code Access Security (CAS) and the Java Permissions model ought to be able to constrain the behavior of signature validating code. <But very uncommon to actually see this. <And the Java APIs would fail if run in a Security. Manager until very recently. 4 Reading system properties not wrapped. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 99
XML Encryption (very briefly…) OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 100
XML Encryption (XMLENC) <The other pillar of WS-Security <A great deal builds on XMLDSIG. 4 References 4 Transforms 4 Key. Info <Inherits the same risks. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 101
XML Encryption – What’s new? < Using encryption to hide complexity bombs, malicious signatures, etc. < More layers of validation! < Circular key references and other Do. S opportunities < Spec says: be able to restrict the total amount of processor and network resources that can be consumed. 4 Difficult to do in languages like Java and Java. Script. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 102
So, how can we use this stuff safely? OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 103
Signature Profiles <Mentioned WS-Security recommendations as we went. 4 SOAP adds a few constraints, too. <SAML specification offers more recommendations. 4 Describes how to do cached ref retrieval <P 3 P, Card. Space, WS-Discovery all specify their own OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 104
WS-I Basic Security Profile* (*1. 0 and 1. 1 are both still working group drafts) < http: //www. ws-i. org/ Intended for compatible full WS-* stacks. < Many of the concerns discussed today are addressed by this standard, (e. g. Transforms are highly restricted) though the risks are not made explicit. < Implementers of full SOAP and WS-* stacks write to these standards for interoperability purposes. < Most WS-I BSP 1. 0 or 1. 1 compliant stacks won’t be vulnerable to many of these attacks. (Although complexitybased Do. S is probably always possible. ) OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 105
WS-I Basic Security Profile < Some ambiguity still. < States that Transforms “MUST have a value of” one of a set of four (relatively) safe ones. < This definitely implies that: 4 A compliant implementation MUST NOT produce other transforms. 4 A compliant implementation MUST understand the specified transforms. < A careless implementer might not think it’s necessary that: 4 A compliant implementation MUST REJECT all other transforms, even if it can understand them. < This is, as we have seen, a necessary security property. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 106
No common, “Simple & Secure” profile <And few switches available to the direct API user 4 To build your own profile to meet your needs 4 To lock down your processor <Profiles are inadequate for the general case 4 Little frank discussion of the risks they mitigate 4 Scattered across many specifications 4 Focused on interoperability, not security and emerging attack patterns <A minimally compliant WS-I BSP stack is the best bet for now. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 107
For API callers: <Use schema validation to enforce a profile before performing signature validation. <Constrain the <Signature> element to exactly what you expect it to look like and reject everything else. <But you have to do this out-of-line 4 Schema validation can break signatures. (e. g. default attrs) 4 Not great for performance. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 108
Lessons Learned OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 109
Lessons Learned <Attack surface reduction matters. Complexity matters. Taking dependencies matters. <Signature validation is part of authentication – this is anonymous or, at best, pre-authorization attack surface. <Releasing a kitchen-sink specification, then publishing a compatibility and security profile four years later? Wrong order of operations. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 110
Properties of an Integrity Mechanism <Deterministic resource consumption. <Fast failure. <No side effects. <Simple enough to be an extraordinarily robust building block for everything that rests upon it. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 111
Different classes of problem. < Integrity is a foundational security problem built on core mathematical operations. < Adding XSLT, in any form, adds the problem of mobile code security. < A clear layering violation and an unfair problem to foist upon implementers and clients. < Only could sneak in because of already too-permissive assumptions about complexity and denial of service. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 112
Re-Learning Lessons < “The Complexity Trap: Security’s Worst Enemy is Complexity” < “Cryptographic protocols should not be developed by a committee. ” < “Authenticate not just the message, but everything that is used to determine the meaning of the message. ” < “The properties required of each of the primitive functions used in the system should be clearly documented. ” OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 113
Not written about WS-Security, though it could’ve been. <That was from: <A Cryptographic Evaluation of IPSec 4 Niels Ferguson and Bruce Schneier 4 Counterpane Internet Security, Inc. 1999 OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 114
Takeaways: <Be cautious if writing directly to XML Security APIs. <Various vendors’ WS-* stacks are at different levels of security maturity today. 4 More research needed. <Use WS-Security where use cases demand it. 4 But protect anonymous endpoints with SSL + client cert auth first. OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 115
Ongoing research. <Watch www. isecpartners. com for updates to the deck, advisory white papers, developer best practices and tools. <And the W 3 C is working on updates to the standard: 4 http: //www. w 3. org/2007/xmlsec/ OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 116
Thank you! Questions? Brad Hill brad@isecpartners. com OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 117
Bibliography M. Bartel, J. Boyer, B. Fox, B. La. Macchia, and E. Simon. XML-Signature Syntax and Processing. In D. Eastlake, J. Reagle, and D. Solo, editors, W 3 C Recommendation. World Wide Web Consortium, 12 February 2002. http: //www. w 3. org/TR/2002/REC-xmldsig-core-20020212/ T. Imamura, B. Dillaway and E. Simon. XML Encryption Syntax and Processing. In D. Eastlake, J. Reagle, editors, W 3 C Recommendation. World Wide Web Consortium, 10 December 2002. http: //www. w 3. org/TR/2002/REC-xmlenc-core-20021210/ T. Beth, M. Frisch, and G. J. Simmons, editors. Public-Key Cryptography: State of the Art and Future Directions, volume 578 of Lecture Notes in Computer Science. Springer, 3– 6 July 1992. E. I. S. S. Workshop Oberwolfach Final Report. Extensible Markup Language (XML) 1. 0 (Fourth Edition). T. Bray, J. Paoli, C. M. Sperberg-Mc. Queen, E. Maler and F. Yergeau, editors. W 3 C Recommendation. World Wide Web Consortium, 16 August 2006, edited in place 29 September 2006. D. Eastlake and K. Niles, Secure XML: The New Syntax for Signatures and Encryption, Pearson Education, July 19, 2002 J. Rosenberg and D. Remy, Securing Web Services with WS-Security: Demystifying WS-Security, WSPolicy, SAML, XML Signature and XML Encryption, Sams, 12 May 2004 T. Berners-Lee, R. Fielding, L. Masinter, Uniform Resource Identifier (URI): Generic Syntax. The Internet Society, 2005 M. Howard, J. Pincus and J. M. Wing, Measuring Relative Attack Surfaces, in Computer Security in the 21 st Century, D. T. Lee, S. P. Sheih and J. D. Tygar, editors, pp 109 -137. Springer US, 2005 http: //springerlink. com/content/v 3 l 4450754 m 8 xp 27 OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 118
Bibliography L. Bull and D. Squire, XML Signature Extensibility Using Custom Transforms, in Web Information Systems – WISE 2004, pp 102 -112. Springer Berlin / Heidelberg, November 2004 http: //springerlink. com/content/qp 0 eyrbgdcn 47 jh 1 XSL Transformations (XSLT) Version 1. 0. J. Clark, editor, W 3 C Recommendation, World Wide Web Consortium, 16 November 1999. http: //www. w 3 c. org/TR/1999/REC-xslt-19991116 D. Tidwell, XSLT, O’Reilly Media, 15 August 2001 Brainerd, W. S. , Landweber, L. H. (1974), Theory of Computation, Wiley A. Skonnard, Extending XSLT with JScript, C#, and Visual Basic. NET, MSDN Magazine, Microsoft Corporation, March 2002. http: //msdn. microsoft. com/msdnmag/issues/02/03/xml/ E. Harold, Simple Xalan Extension Functions: Mixing Java with XSLT, IBM developer. Works, 07 November 2006 http: //www-128. ibm. com/developerworks/library/x-xalanextensions. html Xalan-Java Extensions, The Apache Software Foundation, 2005 http: //xml. apache. org/xalan-j/extensions. html XSLT Security, MSDN Library, Microsoft Corporation, 2007 http: //msdn 2. microsoft. com/en-us/library/ms 763800. aspx O. Predescu, et al. , Xalan-Java, The Apache Software Foundation, Hewlett Packard Corporation, IBM Corporation, Sun Microsystems and Lotus Development Corporation 1999 -2007. http: //xml. apache. org/xalan-j/ OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 119
Bibliography Path (computing), Wikimedia Foundation, 2007 http: //en. wikipedia. org/wiki/Path_(computing) MSXML, Microsoft Corporation. 2000 -2007 http: //msdn. microsoft. com/xml/default. aspx M. Kay, SAXON, M. Kay 2007 http: //saxon. sourceforge. net/ J. Döbler, jd. xslt, Aztecrider, 2001 Oracle XML Developers Kit, XDK 10 g Production, Oracle Corporation, 2004 -2006 http: //www. oracle. com/technology/tech/xml/xdk/software/production 10 g/index. html Sablotron, Ginger Alliance 2006 http: //www. gingerall. org/sablotron. html J. Clark and B. Lindsey, XT 2006 http: //www. blnz. com/xt/index. html Unicorn XSLT Processor, Unicorn Enterprises 2000 -2003 http: //www. unicorn-enterprises. com/products_uxt. html Code Access Security, . NET Framework Developer’s Guide, Microsoft Corporation, 2007 http: //msdn 2. microsoft. com/en-us/library/930 b 76 w 0(VS. 80). aspx OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 120
Bibliography T. Bellwood, S. Capell, L. Clement, J. Colgrave, M. Dovey, D. Feygin, A. Hately, R. Kochman, P. Macias, M. Novotny, M. Paolucci, C. Riegen, T. Rogers, K. Sycara, P. Wenzel, and Zhe Wu, UDDI Version 3. 0. 2. UDDI Spec Technical Committee Draft, Dated 20041019, L. Clement, A. Hately, C. Reigen and T. Rogers, editors. , Accenture, Ariba, Inc. , Commerce One, Inc. , Fujitsu Limited, Hewlett-Packard Company, i 2 Technologies, Inc. , Intel Corporation, International Business Machines Corporation, Microsoft Corporation, Oracle Corporation, SAP AG, Sun Microsystems, Inc. , and Veri. Sign, Inc. 2001 -2002, OASIS Open 2002 -2004 http: //uddi. org/pubs/uddi-v 3. 0. 2 -20041019. htm http: //lists. w 3. org/Archives/Public/w 3 c-ietf-xmldsig/2001 Oct. Dec/0064 Java API for XML Processing (JAXP), Sun Developer Network, Sun Microsystems, Inc. 2007 http: //java. sun. com/webservices/jaxp/ Transform Features, Apache Software Foundation, 2005 http: //xml. apache. org/xalan-j/features. html#secureprocessing L. Gong, Java™ 2 Platform Security Architecture, Sun Microsystems, Inc. 2002 -2007 http: //java. sun. com/j 2 se/1. 4. 2/docs/guide/security/spec/securityspec. doc 3. html#19802 Basic Security Profile Version 1. 1, Working Group Draft, M. Mc. Intosh, M. Gudgin, K. S. Morrison, A. Barbir, editors. Web Services Interoperability Organization, 2006 -10 -19 http: //www. ws-i. org/Profiles/Basic. Security. Profile-1. 1. html G. Della-Libera, M. Gudgin, P. Hallam-Baker, M. Hondo, H. Granqvist, C. Kaler, H. Maruyama, M. Mc. Intosh, A. Nadalin, N. Nagaratnam, R. Philpott, H. Prafullchandra, J. Shewchuk, D. Walter, and R. Zolfonoon, Web Services Security Policy Language, C. Kaler and A. Nadalin, editors. International Business Machines Corporation, Microsoft Corporation, RSA Security, Inc. and Veri. Sign, Inc. , July 2005 http: //specs. xmlsoap. org/ws/2005/07/securitypolicy/wssecuritypolicy. pdf OWASP & WASC App. Sec 2007 Conference – San Jose – Nov 2007 121
Скачать презентацию Attacking XML Security Brad Hill Principal Security Consultant
c1490563a9f4c0f9f2586aba011eacf5.ppt