Készítette: Erdősi Lajos

Az előadások a következő témára: "Készítette: Erdősi Lajos"— Előadás másolata:

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

2 Miről is lesz szó... Mi is az a WCF biztonság
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:
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 Infrastruktúra-szintű Felhasználó-szintű Authentication
Authorization Impersonation (Megszemélyesítés) Message Integrity Message Confidentiality Infrastruktúra-szintű Transport Security Message Security

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ó, Kerberos jegy, 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 Atomic Authorization

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 (Impersonation Token). Szintek: Anonymous Identify Impersonate Delagate

10 Message Integrity 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 Message Confidentiality
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 (Secure Socket Layer) TLS (Transport Layer Security) Point-to-Point kommuniká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=” wss/2004/01/oasis wss-wssecurity-secext-1.0.xsd” > < u:Timestamp u:Id=”uuid-ea4659dc-85e b0c- c674f0128e7f-11” > < u:Created > T20:03:36.830Z < /u:Created > < u:Expires > T20:08:36.830Z < /u:Expires > < /u:Timestamp > < !-- Removed for simplicity -- > < /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=” xmlns:e=” > < e:EncryptionMethod Algorithm=” > < /e:EncryptionMethod > < KeyInfo xmlns=” > < o:SecurityTokenReference xmlns:o=” oasis wss-wssecurity-secext-1.0.xsd” > < o:Reference ValueType=” URI=”#uuid-ea4659dc-85e b0c-c674f0128e7f-10” > < /o:Reference > < /o:SecurityTokenReference > < /KeyInfo > < e:CipherData > < e:CipherValue > < /e:CipherValue > < /e:CipherData > < /e:EncryptedData

19 Áttekintés Eddig: Ezután: Á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-ben II. 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. Kötések Beállítások WsHttpBinding
Üzenet biztonság Windows Auth-tal (NTLM vagy Kerberos) BasicHttpBinding Nincs biztonság WsFederationHttpBinding Üzenet biztonság Befogadott Auth-tal (Issue Token) NetTcpBinding Szállítási biztonság Windows Auth-tal (NTLM vagy Kerberos) NetNamedPipeBinding NetMsmqBinding

24 Példa < wsHttpBinding > < binding name=”UsernameBinding” >
< security mode=”Message” > < message clientCredentialType=”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 Mode property-jével érhető el

26 Példa Konfigurációs modellben: Kódban: < wsHttpBinding >
< binding name=”helloWorld” > < security mode=”TransportWithMessageCredential” > < /security > < /binding > < /wsHttpBinding > Kódban: WSHttpBinding binding = new WSHttpBinding(); binding.Security.Mode = SecurityMode.TransportWithMessageCredential;

27 Biztonsági mód II. Mód Leírás None
A szolgáltatás mindenki számára elérhető, az üzenetek nincsenek védve. Transport A Szállítási biztonsági modellt használja. Message Az Üzenet biztonsági modellt használja. Both Hybrid mód, csak MSMQ kötéssel használható. TransportWithMessageCredentials Szállítási modell, támogatva az üzenetek védelmével. Az autentikációs bizonyítvány az üzenet részeként kerül szállításra. TransportCredentialOnly A kliensek autentikálására a Szállítási modellt használja. Szolgáltatások nincsenek hitelesítve, az üzenetek sima szövegként kerülnek átvitelre.

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 „Message Security” 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. Név Működés None Nincs üzenet védelem Sign
Csak az üzenet integritása garantált. EncryptAndSign Az üzenet integritása és titkosítása is garantált.

30 Példa Attribútumokon keresztül állíthatóak be:
[MessageContract(ProtectionLevel = ProtectionLevel.None)] public class HelloWorldRequestMessage { [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
None A kliensek nincsenek autentikálva. Megegyezik az Anonymous autentikációval. Windows A kliensek autentikálásához a szabványos Windows autentikálást használja Kerberos vagy NTLM-en keresztül. Username A kliens a felhasználói név és jelszó megadásával kerül autentikálásra egy szolgáltatás által. Certificate A kliens egy X.509-es tanúsítvány megadásával kerül autentikálásra egy szolgáltatás által. IssueToken A kliens Http Windows Integrated Authentication – nel kerül autentikálásra.

33 Kliens bizonyítvány típus - Szállítás
None Megegyezik az Üzenet biztonságival. Windows Certificate Basic A kliens with Http Basic Authentication –nel kerül autentikálásra. Digest A kliens with Http Digest Authentication–nel kerül autentikálásra. NTLM A kliens with Http Windows Integrated Authentication–nel kerül autentikálásra.

34 Példa Konfigurációs modellben: Kódban: < wsHttpBinding >
< binding name=”helloWorld” > < security mode=”Transport” > < transport clientCredentialType=”Windows”/ > < message clientCredentialType=”Windows”/ > < /security > < /binding > < /wsHttpBinding > Kódban: WSHttpBinding binding = new WSHttpBinding(); 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… 