Biztonság a WCF-ben

Készítette: Erdősi Lajos2011.11.20.

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

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…

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ó

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

Főbb alapelvek

• Felhasználó-szintű– Authentication– Authorization– Impersonation (Megszemélyesítés)– Message Integrity– Message Confidentiality

• Infrastruktúra-szintű– Transport Security – Message Security

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)

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

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

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

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.

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

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

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

Ü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.

Ü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

Ü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 >– < !-- Removed for simplicity -- >– < /o:Security >

Ü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 >– < KeyInfo xmlns=”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

Á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

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

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

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

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 Szállítási biztonság Windows Auth-tal (NTLM vagy Kerberos)

NetMsmqBinding Szállítási biztonság Windows Auth-tal (NTLM vagy Kerberos)

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.

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

Példa

• Konfigurációs modellben:– < wsHttpBinding >– < binding name=”helloWorld” >– < security mode=”TransportWithMessageCredential” > < /security >– < /binding >– < /wsHttpBinding >

• Kódban:– WSHttpBinding binding = new WSHttpBinding();– binding.Security.Mode = SecurityMode.TransportWithMessageCredential;

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.

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

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.

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; }

}

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

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.

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

None Megegyezik az Üzenet biztonságival.

Windows Megegyezik az Üzenet biztonságival.

Certificate Megegyezik az Üzenet biztonságival.

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.

Példa• Konfigurációs modellben:

< 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;

Köszönöm a figyelmet!

• Vége…