Biztonság a WCF-ben

1. Biztonság a WCF-ben Készítette: Erdősi Lajos 2011.11.20.

2. Miről is lesz szó... • Miért van szükség a szolgáltatások biztonságára? • Mi is az a WCF biztonság • Biztonság fejlődése webszolgáltatások esetében • Főbb alapelvek a web szolgáltatások biztonságában • Szállítási biztonság és üzenetek biztonsága • WCF biztonság használat közben • Első lépések a biztonságossá válásban

3. Mi ellen kell védekezni? • Autentikáció • Hálózat lehallgatása • Jogosultságkezelés • Érzékeny adatok kiadása • Sessionkezelés • Man-In-The-Middle • Érvényességellenőrzés • SQL-Injection • Cross-Site Scripting • Stb…

4. Biztonság fejlődése • Web szolgáltatások két meghatározó pontja: • Biztonság • Együttműködés (Interoperability) • Web szolgáltatások és biztonság • 90-es évek vége: SOAP üzenet – Üzenetek nem biztonságosak -> Szállítási rétegre bízzák • HTTP -> nem biztonságos üzenet átvitel • HTTPS -> garantálja a titoktartást • Üzenetek biztonságossá tétele-> WS-* specifikáció

5. WS-Security • 2004. április 19.-én vezették be, a WS-* Specifikáció biztonsági részeként • Ez már az üzenetek szintjén biztosította a web szolgáltatásokat • Microsoft kiadja a WSE (Web Service Enhancements) első verzióját • 2006-ban ez megszűnik (utolsó verzió: WSE 3.0)-> WCF bemutatása

6. Főbb alapelvek • Felhasználó-szintű • Authentication • Authorization • Impersonation (Megszemélyesítés) • MessageIntegrity • MessageConfidentiality • Infrastruktúra-szintű • TransportSecurity • MessageSecurity

7. Authentication • A folyamat, ahol egyedülállóan azonosítják a résztvevőket, melyek az üzenetek forrásaként szerepelnek. • Az authentikáció alapvetően két kérdés köré épül: • Ki vagy te? • Hogy bizonyítod ezt be? • Azonosítás fajtái: • Felhasználói név és jelszó, Kerberosjegy, X.509 – es tanúsítvány, stb… • Veszély: • Phishing, „Szótát” alkalmazásos támadás, stb… • Lehetséges védekezés: kettős azonosítás (kliens és service is)

8. Authorization • A folyamat, ami eldönti, hogy milyen erőforrásokhoz férhet hozzá, illetve milyen műveleteket végezhet a hitelesített felhasználó. • Alapvetően a website dönt arról, hogy a hitelesített felhasználónak milyen engedélyeket ad • Ezt megteheti: • Hozzáférési listák alapján • Képesség alapján • 3. fél hitelesítés alapján • AtomicAuthorization

9. Impersonation • Ez a fajta hitelesítés csak akkor lehetséges, ha a felhasználó egy Windows Account-tal rendelkezik, ami hitelesíti őt. • Alapvetően a hozzáférés ellenőrzéshez hasonló a működése, azonban a felhasználót (személye, jogok, stb…) egy token tárolja (ImpersonationToken). • Szintek: • Anonymous • Identify • Impersonate • Delagate

10. MessageIntegrity • Garantálja, hogy az üzenet nem módosul a feladástól számítva a kézbesítésig • Az integritás megőrzése alapvetően a titkosítási technikákon alapul: • Digitális aláírás • Hashing • Üzenet autentikációs kódok • Az integritásőrzés kifejezetten jó megoldás a MITM támadás elhárítására

11. MessageConfidentiality • A folyamat, hogy biztosan privát és titkos maradjon az üzenet, azaz hogy egy külső fél ne férjen hozzá az adatokhoz. • Szintén az adatok titkosításán alapul • A legbiztosabb az aszimmetrikus kulcson alapuló titkosítás, mint az RSA • A titkosításnak köszönhetően kivédhető a MITM támadás és az Eavesdropping.

12. Szállítási biztonság I. • Ez a fajta biztonság szélesebb körben használt gyorsasága és interoperabilitása miatt. • Mivel ebben az esetben az üzenetek nem biztonságosak, azaz a szállítási réteg felelős a biztonság megőrzése miatt egy 3. fél olvasni tudja az üzenet adatait • A biztonságos szállítás érdekében a következőeket használja: • SSL (SecureSocketLayer) • TLS (TransportLayerSecurity) • Point-to-Pointkommunikáció esetén alkalmazható, ami azt jelenti, hogy biztonságos az átvitel a küldő és fogadó fél között • Probléma azonban, ha egy 3. fél is csatlakozik a kommunikációhoz

13. Szállítási biztonság II. • Ha csak a kliens és a szerver szerepel a kapcsolatban, akkor biztonságos az üzenetek átvitele • Ha vannak köztes média elemek, akkor a továbbítás során új SSL kapcsolat jön létre. • Ha az üzenet elhagyja a szállítási réteget, akkor tovább már nincs biztonságban az üzenet • Nagy előny az Üzenet biztonsággal szemben, hogy a feleknek nem kell teljes mértékben ismerniük a WS-Security specifikációt, ezáltal nagy az interoperabilitása a különböző platformok vagy szolgáltatások között • A függetlenség két fő faktorból ered: • A WS-Security specifikáció komplexitásából • A web szolgáltatások végső implementációjának különbözőségéből

14. Szállítási biztonság III. • Működése: • A kliens, mely csatlakozik a szerverhez elküldi az elérhető titkosítási algoritmusokat • A szerver visszaküldi tanúsítványának másolatát, majd választ egy algoritmust • A kliens kinyeri a szerver publikus kulcsát a tanúsítványból, mellyel hitelesíti a szervert • A kliens létrehoz egy session kulcsot, majd ezzel a kulccsal titkosítja az adatokat, melyek cserélésre kerülnek a kliens és szerver között

15. Üzenet biztonság I. • Minden biztonsági metaadatot a SOAP üzenet tartalmaz: • Digitális aláírás, Titkosított elemek, Felhasználói bizonyítvány, Titkosítási kulcsok, stb… • Ez a modell a WS-Security specifikáción alapszik, mely nagyban meghatározza, hogy: • Hogyan írjuk alá és titkosítsuk a SOAP borítékokat • Milyen különböző algoritmusokat és kulcsokat használjunk • Mint egy XML implementáció, a WS-Security lehetőséget ad különböző típusú bizonyítványok használatára • …vagy akár újakat is létrehozhatunk.

16. Üzenet biztonság II. • A fő különbség a Szállítási biztonsággal szemben, hogy: • Az üzenetek továbbíthatóak más szolgáltatásokhoz vagy közvetítő rendszerekhez a biztonság megsértése nélkül • Az üzenetek mindig biztonságosak maradnak, még akkor is ha elhagyják a szállítási réteget • Az üzenet küldő módosítja az üzenetet: • Az üzenet testét titkosítja • Módosítja az üzenet fejrészét, egy speciális SOAP headerrel (Security) • Ha az üzenet kézbesítésre kerül: • Megvizsgálják ezt a Security fejrészt, hogy: • Az üzenet tartalmaz-e titkosított részt • Milyen módon lett titkosítva

17. Üzenet biztonság III. • Példa a header módosítására: • < o:Security s:mustUnderstand=”1” xmlns:o=”http://docs.oasis-open.org/ • wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd” > • < u:Timestamp u:Id=”uuid-ea4659dc-85e5-4054-9b0c- c674f0128e7f-11” > • < u:Created > 2009-07-27T20:03:36.830Z < /u:Created > • < u:Expires > 2009-07-27T20:08:36.830Z < /u:Expires > • < /u:Timestamp > • < !-- Removedforsimplicity -- > • < /o:Security>

18. Üzenet biztonság IV. • Példa a body módosítására: • < s:Body u:Id=”_0” > • < e:EncryptedData Id=”_1” Type=”http://www.w3.org/2001/04/xmlenc#Content” • xmlns:e=”http://www.w3.org/2001/04/xmlenc#” > • < e:EncryptionMethod Algorithm=”http://www.w3.org/2001/04/xmlenc#aes256-cbc” > • < /e:EncryptionMethod > • < KeyInfoxmlns=”http://www.w3.org/2000/09/xmldsig#” > • < o:SecurityTokenReference xmlns:o=”http://docs.oasis-open.org/wss/2004/01/ • oasis-200401-wss-wssecurity-secext-1.0.xsd” > • < o:Reference ValueType=”http://schemas.xmlsoap.org/ws/2005/02/sc/dk” • URI=”#uuid-ea4659dc-85e5-4054-9b0c-c674f0128e7f-10” > < /o:Reference > • < /o:SecurityTokenReference > • < /KeyInfo > • < e:CipherData > • < e:CipherValue > ..... < /e:CipherValue > • < /e:CipherData > • < /e:EncryptedData

19. Áttekintés • Eddig: • Áttekintettük, hogy milyen támadások vannak • Hogyan lehet ezek ellen védekezni • Mik azok az Infrastruktúra-szintű alapelvek • Ezután: • Megnézzük, hogy milyen lehetőségeket biztosít a WCF minderre

20. Biztonság a WCF-ben I. • Támogatja: • Szállítási biztonság • Üzenet biztonság • Hybrid (Szállítási biztonság + Üzenet bizonyítvány) • A WSE 3.0 tapasztalatai alapján támogat „minden” tipikus biztonsági sémát • Azonban lehetőséget biztosít saját biztonsági sémák létrehozására

21. Biztonság a WCF-benII. • Fő belépési pontok a WCF biztonsági alrendszerébe: • Kötés (Binding) • Viselkedés (Behavior) • A megfelelő biztonsági séma és politika beállítása függ: • Üzenetek védelmétől • Autentikáció fajtájától • Autorizáció fajtájától

22. Kötések I. • A kötések határozzák meg: • Kommunikációs protokollt • Szolgáltatások kódolását • Üzenet védelmi beállításokat • Autentikációs sémát • A kötés kiválasztása hatással van a konfigurációs beállításokra • Pl.: BasicHttp esetén csak Szállítási biztonságot használhatunk • A tévedések elkerülése érdekében, ha nincsenek speciális beállítási igényeink, használhatjuk a WCF által előre definiált konfigurációs sémákat

23. Kötések II.

24. Példa • < wsHttpBinding > • < bindingname=”UsernameBinding” > • < securitymode=”Message” > • < messageclientCredentialType=”UserName”/ > • < /security > • < /binding > • < /wsHttpBinding > • A példában „Message” biztonsági mód látható, illetve „username” biztonsági token profil. A további biztonsági beállításai a kötésnek az alap (default) beállítások.

25. Biztonsági mód I. • Két alap biztonsági nézetet határoz meg: • Az üzenet védelem biztonsági modelljét • Támogatott kliens autentikációs sémákat • Azonban ezek a nézetek megkötéseket is vonnak magukkal. • Pl.: Befogadott Autentikáció csak üzenet autentikáció esetén érhető el • Ezen beállítás a konfigurációs modell „security” elem Modeproperty-jével érhető el

26. Példa • Konfigurációs modellben: • < wsHttpBinding > • < bindingname=”helloWorld” > • < securitymode=”TransportWithMessageCredential” > < /security> • < /binding > • < /wsHttpBinding > • Kódban: • WSHttpBindingbinding = newWSHttpBinding(); • binding.Security.Mode = SecurityMode.TransportWithMessageCredential;

27. Biztonsági mód II.

28. Védelmi szint I. • Alapvetően a WCF minden üzenetet titkosít és aláír, hogy biztosítsa a titoktartást és integritást. • Ha „MessageSecurity” módot használunk, akkor felüldefiniálhatjuk ezt, így kikapcsolhatjuk a WCF ezen szolgáltatásait. • A védelmi szint beállítható: • Szolgáltatás szinten a szerződés definíciójában • Műveleti szinten • Ha mindkettő beállításra került, akkor a műveleti felüldefiniálja a szolgáltatás szintűt

29. Védelmi szint II.

30. Példa • Attribútumokon keresztül állíthatóak be: [MessageContract(ProtectionLevel = ProtectionLevel.None)] publicclassHelloWorldRequestMessage { [MessageHeader] public string SampleHeader { get; set; } [MessageBodyMember()] public string Message { get; set; } }

31. Kliens bizonyítvány típus I. • Nagyon fontos • A szolgáltatás által használt autentikációs sémát állítja be • Meghatározza, hogy a kliens vagy a szolgáltatás „fogyasztója” milyen hitelesítéssel kell rendelkeznie

32. Kliens bizonyítvány típus - Üzenet

33. Kliens bizonyítvány típus - Szállítás

34. Példa • Konfigurációs modellben: < wsHttpBinding > < bindingname=”helloWorld” > < securitymode=”Transport” > < transportclientCredentialType=”Windows”/ > < messageclientCredentialType=”Windows”/ > < /security > < /binding > < /wsHttpBinding > • Kódban: WSHttpBindingbinding = newWSHttpBinding(); binding.Security.Mode = SecurityMode.Transport; binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Windows; binding.Security.Message.ClientCredentialType = MessageCredentialType.Windows;

35. Köszönöm a figyelmet! • Vége… 