Az előadás letöltése folymat van. Kérjük, várjon

Az előadás letöltése folymat van. Kérjük, várjon

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

Hasonló előadás


Az előadások a következő témára: "Biztonság a WCF-ben Készítette: Erdősi Lajos 2011.11.20."— Előadás másolata:

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

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 á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) – 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=”http://docs.oasis- open.org/ – wss/2004/01/oasis wss-wssecurity-secext-1.0.xsd” > – – T20:03:36.830Z – T20:08:36.830Z –

18 Üzenet biztonság IV. Példa a body módosítására: – – < e:EncryptedData Id=”_1” Type=”http://www.w3.org/2001/04/xmlenc#Content” – xmlns:e=”http://www.w3.org/2001/04/xmlenc#” > – – < o:SecurityTokenReference xmlns:o=”http://docs.oasis-open.org/wss/2004/01/ – oasis wss-wssecurity-secext-1.0.xsd” > – < o:Reference ValueType=”http://schemas.xmlsoap.org/ws/2005/02/sc/dk” – URI=”#uuid-ea4659dc-85e b0c-c674f0128e7f-10” > – –..... – – < /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-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ésekBeállítások WsHttpBindingÜzenet biztonság Windows Auth-tal (NTLM vagy Kerberos) BasicHttpBindingNincs biztonság WsFederationHttpBindingÜzenet biztonság Befogadott Auth-tal (Issue Token) NetTcpBindingSzállítási biztonság Windows Auth-tal (NTLM vagy Kerberos) NetNamedPipeBindingSzállítási biztonság Windows Auth-tal (NTLM vagy Kerberos) NetMsmqBindingSzállítási biztonság Windows Auth-tal (NTLM vagy Kerberos)

24 Példa 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 = new WSHttpBinding(); – binding.Security.Mode = SecurityMode.TransportWithMessageCredential;

27 Biztonsági mód II. MódLeírás NoneA szolgáltatás mindenki számára elérhető, az üzenetek nincsenek védve. TransportA Szállítási biztonsági modellt használja. MessageAz Üzenet biztonsági modellt használja. BothHybrid mód, csak MSMQ kötéssel használható. TransportWithMessageCredentialsSzá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. TransportCredentialOnlyA 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évMűködés NoneNincs üzenet védelem SignCsak az üzenet integritása garantált. EncryptAndSignAz ü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 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.

34 Példa Konfigurációs modellben: 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…


Letölteni ppt "Biztonság a WCF-ben Készítette: Erdősi Lajos 2011.11.20."

Hasonló előadás


Google Hirdetések