Bezpečnost v ASP.NET. Ladislav Mrnka

Bezpečnost v ASP.NET Ladislav Mrnka [email protected]

Motto If anyone tells you that security ends with the OS, they are dead wrong. Many times excellent network and hostbased security has been bypassed exposing the very heart of the enterprise: all because of poor SQL Server configuration. That said...there is no "patch" for stupidity. -from www.sqlsecurity.com

Obsah „ „ „ „ „ „ „ „ „ „ „ „ „ „ „

Úvod Základní pojmy Typy útoku Základní pravidla obrany Konfigurace ASP.NET Nastavení IIS autenitizace IPrincipal a IIdentity Autentizace v ASP.NET Windows authentication Forms authentication .NET Passport authentication Autorizace v ASP.NET Komunikace přes SSL Závěr Zdroje

Úvod „

„ „

„

Bezpečnost je základní součástí každé business aplikace. Váže se přímo k účelu a funkci aplikace. Nelze ji časem „dodělat“, musí být plánována od samého počátku designu aplikace. V praxi se nejedna pouze o práci vývojáře aplikace, ale také o práci správce webového serveru. Vývojář většinou nemá dostatečná práva ke změnám na serveru, kde bude aplikace nasazena. Pro vlastní vývoj by však měl být schopný provádět nastavení na svém lokálním/testovacím serveru.

Základní pojmy „

„

„

„

Authentication – proces, při kterém se ověří identita uživatele, tj. přihlášení uživatele/ověření uživatele Authorization – proces, při kterém se ověří přístupová práva uživatele, tj. kontrola přístupu k jednotlivým částem aplikace podle uživatelského účtu, role, atd. Bezpečná komunikace – komunikace mezi klientem a serverem je kryptovaná, tj. obsah zpráv není posílán jako plain text, např. komunikace přes SSL Impersonalization – spuštění procesu ASP.NET workera s právy daného uživatelského účtu. Používá se také ke kontrole přístupu anonymního uživatele ke zdrojům na serveru.

Typy útoku - rozdělení „

„

„

„

Útok z webu se dá rozdělit do dvou základních skupin: pasivní a aktivní. Pasivní útoky pouze sledují komunikaci mezi klientem a serverem. Jedná se o základ pro další zákeřnější útoky. Aktivní útoky mění a falšují zasílané zprávy, případně blokují službu, např. zaplavováním serveru falešnými požadavky. Úspěšný útok může způsobit poškození důležitých dat, či snížit reputaci firmy.

Typy útoku – příklad (pasivní) „

„

Naslouchání – založeno na používání ad hoc programů, které umožňují číst nekryptované pakety procházející sítí. Jedná se o jeden z nejtěžších bezpečnostních problémů – řešení : kryptování obsahu zpráv a umístění intranetu za kvalitní firewall. Man-in-the-Middle – třetí uživatel tajně filtruje komunikaci mezi dvěma uživateli (klient/server). Tento typ útoku je více aktivní než naslouchání, umožňuje přesměrování paketů.

Typy útoku – příklad (aktivní) „

„

„

„

Modifikace dat – typicky další krok po Man-in-the-Middle útoku. IP address spoofing – založeno na programech, které umožňují vytvořit IP pakety, které jsou totožné s pakety od důvěryhodné IP uvnitř firemní sítě. Password attack – útočník se vydává za někoho jiného, tj. má cizí identitu. DoS (Denial-of-Service) – cílem tohoto útoku je znemožnit funkci dané služby, např. zaplavováním serveru falešnými požadavky.

Základní pravidla obrany „

„

„

Při návrhu bezpečné aplikace je nutné začít od samotného kódu = secure coding Nedůvěřovat – klíčové pravidlo, nedůvěřovat uživatelskému vstupu, každý vstup od uživatele je potencionální útok, každý vstup musí být ověřen Co nejnižší oprávnění – povolit pouze to co aplikace skutečně potřebuje, v extrému se dá říci, že co aplikace nepotřebuje při více než 80% operací je nadbytečné a mělo by být vypuštěno a zakázáno. Služby, které nejsou často používány se většinou nemonitorují = jsou vhodné pro napadení.

Základní pravidla obrany „

SQL Injection = konstruování SQL dotazů v aplikaci. Většinou se SQL dotazy vytvářejí spojováním řetězců, do kterých se připojují hodnoty, které zadal uživatel. Zde obzvlášť platí důležitost validace uživatelského vstupu. Příklad : StringBuilder sb = new StringBuilder(); sb.Append(“SELECT * FROM students WHERE id=‘”); sb.Append(id); // string id - uživatelský vstup sb.Append(“’”);

Co když id = “150’ DROP TABLE students --“ ? Obranou je validace řetězců a zdvojování escape znaků (zde ‘), další problémy lze řešit např. používáním uložených procedur.

Základní pravidla obrany „

„

Cross-Site Scripting – vyvarovat se předáváním dat, které přišli v požadavku (Request) přímo do odpovědi (Response). Opět je nutné data validovat, protože např. v query stringu může být schován nějaký nepěkný JavaScript. Strong Password – při používání hesel, používat hesla, která mají minimálně 8 znaků a skládají se z velkých a malých písmen, číslic a některých alfanumerických znaků (-,_,*,#,$, atd.), navíc je nutné heslo měnit po každých 90 dnech. Lze zavést i historii hesel, aby uživatel neměl pouze dvě hesla, která bude střídat.

Základní pravidla obrany „

„

Neexistuje 100% bezpečné úložiště hesel, proto by hesla měla být ukládána kryptovaně. Vhodné použít třídy z System.Security.Crypthography „

DESCryptoServiceProvider – symetrický algoritmus

„

RSACryptoServiceProvider – asymetrický algoritmus

Objevit všechna slabá místa aplikace není jednoduché, ovšem vývojář má proti útočníkovi silnou výhodu, ví jak se jmenují používané databázové tabulky, soubory, atd. Proto se může vžít do role útočníka a svojí aplikaci testovat. Základem je validace uživatelského vstupu, která dokáže zabránit velkému množství problémů.

Konfigurace ASP.NET ƒ Standardně běží ASP.NET worker (aspnet_wp.exe) pod ƒ

účtem s omezenými uživatelskými právy. Účet ASPNET je vytvořen při instalaci .NET Frameworku. Nastavení lze měnit v souboru machine.config. Změna se projeví po restartu IIS. <processModel enable=“true” userName=“machine” password=“AutoGenerate” … />

ƒ

machine je „přezdívka“ pro ASPNET účet, při instalaci .NET Frameworku se vytvoří 14ti bytové heslo, které se uloží do LSA serveru. Toto nastavení nemůže být přepsáno v souboru web.config.

Konfigurace ASP.NET „

„

Pro změnu účtu pod kterým běží ASP.NET worker, stačí přepsat userName a password v machine.config. To ovšem vyžaduje do souboru přímo zapsat heslo. Od verze 1.1 .NET Frameworku je možné využít ASP.NET Set Registry Tool (aspnet_setreg.exe). To umožňuje použít kryptované heslo uložené v registrech serveru. ASPNET účet silně omezuje možnosti přístupu k souborům a ostatním zdrojům.

Konfigurace ASP.NET – práva ASPNET účtu „

ASPNET účet je odvozen od User skupiny ve Windows. Oprávnění jsou omezena na : „ „ „ „ „

„

Přístup k počítači ze sítě Zakázáno lokální přihlášení Zakázáno přihlášení z terminálových služeb Přihlásit jako dávku Přihlásit jako službu

Dále má účet přirazen tyto NTFS oprávnění k čtení z těchto složek : kořenový adresář .NET Framework, dočasné soubory ASP.NET (i zápis), GAC, systémový adresář Windows, kořenový adresář aplikace, kořenový adresář webové stránky

Konfigurace ASP.NET impersonalizace „

Pro spuštění procesu ASP.NET workera s uživatelskými právy přihlašovaného uživatele (IIS Windows authentication – viz dále) se nastaví

„

„

Identity lze na rozdíl od processModel použít i ve web.config Lze přepsat původní nastavení z machine.config a pro každou aplikaci nastavit jiný účet, pod kterým se bude proces ASP.NET workera pouštět.

„

Tímto nastavením ve web.config se pro spuštění procesu ASP.NET workera přiřadí uživatelský účet, který překryje nastavení z machine.config.

Konfigurace ASP.NET – anonymní přihlášení „

Při zakázání impersonalizace se přihlášení bere jako anonymní.

„

„

Pro anonymní přihlášení se používá účet nastavený v IIS, typicky IUSR_SERVER, kde server je NetBios jméno počítače, na kterém IIS běží. Používá se tzv. pre-request impersonalizace. Proces ASPNET workera je spuštěn pod ASPNET účtem. Pod tímto účtem jsou prováděny všechny operace, které nastanou před obsluhou požadavku. Samotný požadavek je obsluhován účtem pro anonymní přihlášení, tj. tento účet se používá pouze pro kód stránky.

Konfigurace ASP.NET – kontext aplikace „

„

„

„

Model imporsonalizace je lokální v rámci vláken, tj. bezpečnostní kontext v rámci vláken. CLR poskytuje možnost asynchronně zpracovávat služby běžící v různý vláknech. Impersonalizace je proto vhodná pouze pro aplikace, které nepotřebují přepínání vláken. Tento nedostatek lze řešit mechanismem izolace, zajišťující izolaci aplikace na úrovni procesu, a mechanismem code access security, kde se oprávnění přístupu k prostředkům vyhodnocuje jak podle identity volajícího tak podle identity volaného.

Nastavení IIS autentizace „

„

Autentizace se nejprve provádí na webovem serveru, který hostí webovou aplikaci a teprve poté v samotné ASP.NET aplikaci. Tyto dva procesy je nutné odlišovat. IIS nabízí tyto možnosti autentizace : „ „ „ „ „

„

Anonymous Basic Digest Windows Integrated Certificate

Pokud má ASP.NET aplikace nastavenou autentizaci na Windows, je zcela odkázána na autentizaci v IIS, naopak při Passport a Forms se v IIS nastavuje anonymous.

Nastavení IIS autentizace „

„

„

„

„

Ovládání IIS – Ovládací panely -> Nástroje pro správu -> Internetová informační služba Nastavení autentizace v IIS se provádí ve vlastnostech serveru, složky či souboru – záložka Zabezpečení adresáře či Zabezpečení souboru. Serverové certifikáty lze nastavovat pouze pro server, nikoliv pro adresáře a soubory. Basic, Digest a Anonymous autentizace se nastavují v panelu Nastavení anonymního přístupu a ověřování. Dále je možné přístup omezovat podle domén a IP adres.

Nastavení IIS autentizace „

„

Anonymous – používá se v případě, že není potřeba klienta autentizovat již v IIS, tj. k autentizaci dochází až v ASP.NET (Forms nebo Passport) nebo se jedná o anonymní přihlášení. (viz Konfigurace ASP.NET – anonymní přihlášení). Pokud je použito, pokouší se IIS provádět anonymní autentizaci jako první, i když jsou povoleny i jiné metody. Basic – uživatel je identifikován uživatelským jménem a heslem. Přihlašovací údaje jsou zasílány nekryptovaně (používá se pouze kódování Base64), proto by se tento mód měl používat pouze v kombinaci se SSL nebo jinou formou bezpečné komunikace. Kompatibilní i s jinými prohlížeči než MS Internet Explorer.

Nastavení IIS autentizace „

„

Digest – tento mód byl uveden v IIS 5.0. Je stejný jako Basic autentizace, ale přihlašovací údaje jsou kryptované. Vyžaduje MS Explorer 5.0 a vyšší, dále musí být uživatel členem domény, která obsahuje doménový řadič Windows 2000 nebo novější. Uživatel musí mít učet v systému Windows uložený v řadiči domény v Active Directory. IIS musí běžet na Windows 2000 nebo novějších. Windows Integrated – používá výměnu kryptovaných přihlašovacích údajů mezi MS Internet Explorerem a webovým serverem. Lze použít jen v intranetu, kde je zakázán anonymní přístup. Používá protokol Kerberos 5 nebo NTML.

Nastavení IIS autentizace „

„

Certificate – využití klientských certifikátů, které jsou zaslány jako součást požadavku (vlastnost ClientCertificates objektu HttpWebRequest). Tyto certifikáty jsou pak v IIS mapovány na konkrétní uživatelský účet. Certifikát slouží k vytvoření bezpečného spojení mezi klientem a serverem, zároveň v případě klientského certifikátu slouží i k ověření klienta. Pro práci s certifikáty slouží v .NET Frameworku jmenný prostor System.Security.Cryptography.X509Certificates

IPrincipal a IIdentity „

„

„

„

Bezpečnost v .NET Framework je vystavěna nad systémem bezpečnosti ve Windows. Základem bezpečnosti v .NET Framework jsou rozhraní IPrincipal a IIdentity, definované v jmenném prostoru System.Security.Principal. Používají se k reprezentaci uživatelů a spolu tvoří základ pro ověřování podle role uživatele. Všechny objekty představující Principal (uživatel) nebo Identity (informace o uživateli) musí implementovat tato rozhraní. Zjistit bezpečnostní kontext běžícího vlákna lze z vlastnosti Thread.CurrentPrincipal, která vrací objekt implementující IPrincipal.

IPrincipal a IIdentity „

Rozhraní IPrincipal umožňuje zjistit, zda je uživatel v dané roli a vrátit jeho identitu. public interface IPrincipal { bool IsInRole( string role ); IIdentity Identity {get;} }

„

Toto rozhraní implementují třídy GenericPrincipal a WindowsPrincipal.

IPrincipal a IIdentity „

Rozhraní IIdentity poskytuje další rozšiřující údaje, uživatelské jméno, typ autentizace a zda je uživatel autentizován. public interface IIdentity { string authenticationType {get;} bool IsAuthenticated {get;} string Name {get;} }

„

Toto rozhraní implementují třídy GenericIdentity, WindowsIdentity, FormsIdentity a PassportIdentity.

IPrincipal a IIdentity - Windows „

„ „

„

„

Třídy WidnowsPrincipal a WindowsIdentity reprezentují .NET verzi systému bezpečnosti ve Windows. Používá se spolu s Windows autentizací. Používáním těchto tříd se vkládá důvěra v operační systém. WindowsPrincipal – uchovává role přiřazené uživateli. Role jsou v tomto případě uživatelské skupiny v operačním systému Windows. WindowsIdentity – uchovává identity bezpečnostního kontextu aktuálního uživatele. Identitu uživatele, který spustil aktuální vlákno lze získat statickou metodou WindowsIdentity.GetCurrent() – odpovídá funkci GetUserName z Win32 API.

IPrincipal a IIdentity - Generic „

„

„

Třída GenericPrincipal se používá v případě, kdy není použita Windows autentizace nebo kdy není potřeba komplexní reprezentace jako u WindowsPrincipal. Důvěra se vkládá v aplikaci, která vytvořila instanci třídy GenericPrincipal. V souvislosti s touto třídou se používá několik typů identit : „

„

„

GenericIdentity – reprezentace informací o logickém uživateli, který se nevztahuje k žádnému operačnímu systému. Používá se například pro vlastní metody autentizace a autorizace. FormsIdentity – identita autentizovaná při Forms autentizaci. Obsahuje FormsAutenticationTicket s informacemi o autentizaci. PassportIdentity – identita autentizovaná při Passport autentizaci.

Autentizace v ASP.NET „ „

Autentizace v ASP.NET probíhá až po autentizaci v IIS. ASP.NET umožňuje tři módy autentizace : „ „ „

„

Windows – defaultní mód autentikace Forms Passport

Autentizaci není nutné provádět dvakrát, proto se většinou používají kombinace Basic, Digest, Windows Integrated, Certificate v IIS a Windows v ASP.NET aplikaci nebo Anonymous v IIS a Forms nebo Passport v ASP.NET aplikaci.

Autentizace v ASP.NET „

Mód autentizace pro ASP.NET aplikaci se nastavuje v souboru web.config. <system.web>

„

„

Mód autentizace může být nastaven jen ve web.config v kořenovém adresáři aplikace. Tato autentizace se vztahuje jen na ASP.NET soubory, nikoliv na čisté HTML soubory. Lze mapovat HTML soubory na ASP.NET, ovšem snižuje to výkon serveru.

Windows authentication „

„

„ „

Při tomto módu se ASP.NET plně spoléhá na autentizaci v IIS. Po úspěšné autentizaci v IIS obdrží aplikace bezpečnostní token. Tento mód se používá především ve firemním intranetu, kde mají všichni uživatelé Windows účet. Dále se používá spolu s klientskými certifikáty. Pro použití Windows autentizace stačí do souboru web.config napsat :

Windows authentication „

„

Používá se především s FileAuthorizationModule HTTP modulem, ale lze jí použít i s URLAuthorizationModule HTTP modulem (viz Autorizace v ASP.NET). Tento mód je zajištěn WindowsAuthenticationModule HTTP modulem. Během autentizace je možné reagovat v souboru global.axax na Authenticate událost. protected void WindowsAuthentication_OnAuthenticate(object sender, WindowsAuthenticationEventArgs e) {…}

„

WindowsAuthenticationEventArgs obsahují vlastnosti „ „ „

HttpContext Context WindowsIdentity Identity IPrincipal User

Windows authentication „

V kódu ASP.NET stránky se pak v každém volání Page_Load jednoduše zjistí zda je uživatel autentizován : public void Page_Load(object sender, EventArgs e) { if (User.Identity.IsAuthenticated) // User je vlastnost objektu Page { // uživatel autentikován } else { // uživatel není autentikován} }

„

Často se kombinuje s impersonalizací. Uživatel je nejprve autentizován a poté se stránka spustí přímo s právy jeho účtu nebo s právy konkrétního impersonalizovaného účtu. Tím se řídí i autorizace přístupu ke zdrojům na serveru.

Forms authentication „

„ „

„

Při tomto módu je celý proces autentizace ošetřen v aplikaci. Uživatele jsou ověřování např. na základě registrovaných uživatelů uložených v databázi. Jedná s o nejčastější řešení pro internetové aplikace. Tento mód je zajištěn FormsAuthenticationModule HTTP modulem. Pro použití Forms autentizace je nutné do souboru web.config napsat :

Forms authentication „

Tag forms má několik atributů, které nastavují proces autentizace „

„ „ „

„

„

„

loginUrl – url, na kterou je přesměrován požadavek pokud není nalezeno autentizační cookie = uživatel není autentizován name – jméno autentizačního cookie, defaultně .ASPXAUTH path – cesta k autentizačnímu cookie, defaultně / protection – forma zabezpečení cookie, lze zvolit mezi All, Encryption, None, Validation. Defaultní je All. requireSSL – pokud je true, je autentizační cookie zasíláno na server jen v případě, že je použita bezpečná komunikace (SSL). slidingExpiration – pokud je true, je timeout resetován při každém požadavku. Defaultně je false. timeout – počet minut, po kterých autentizační cookie vyprší. Defualně je 30.

Forms authentication „

„

„ „

Tento autentizační mód ztrácí význam (nic nedělá), pokud jsou k přístupu autorizování anonymní uživatelé (viz dále Autorizace v ASP.NET). Již na úrovní IIS je uživatel brán jako anonymní, a proto pokud je autorizován k přístupu, login formulář se vůbec neobjeví. Autentizační cookie se nazývá autentizační tiket, je představováno třídou FormsAuthenticationTicket. Pro kryptování cookie se používá Triple-DES algoritmus. Pro ověření uživatele se používá databáze uživatelů v SQL Serveru (nebo jiném databázovém serveru), Active Directory nebo výčet uživatelů v souboru web.config.

Forms authentication „

V případě, že ke stránce bude přistupovat pouze malý počet uživatelů, lze přihlašovací údaje pro autentizaci vložit přímo do souboru web.config (statický výčet) : <user name=“…” password=“…” />

„

passwordFormat může nabývat hodnot Clear (plain text), MD5, SHA1. Podle této hodnoty se zapisuje helso do atributu v tagu user. Pro MD5 a SHA1 je zapsáno kryptovaně.

Forms authentication „

V případě zadání přihlašovacích údajů do souboru web.config se ověření uživatele stává velice jednoduché : if(FormsAuthentication.Authenticate(name, password)) { // autentizován FormsAuthentication.RedirectFromLoginPage(name, true); }

„

Nutno použít jmenný prostor System.Web.Security Funkce RedirectFromLoginPage se používá k přesměrování na stránku původního požadavku. Při volání této funkce se vytvoří autentizační cookie, které je v odpovědí odesláno klientovi. První argument je dále použit při URL autorizaci. Druhá udává zda se vytvoří cookie se sliding expiration.

Forms authentication „

„

„

„

Pokud jsou hesla v souboru web.config ukládána kryptovaně, je nutné heslo přijaté od uživatele převést do hashované podoby a teprve tu ověřit. Pro převod slouží funkce třídy FormsAuthentication HashPassportForStoringInConfigFile(pwd,metoda), kde metoda je SHA1 nebo MD5. Pro logout se používá FormsAuthentication.SignOut(), tato funkce odstraní autentizační cookie z klientského prohlížeče. Je vhodné používat čítač pokusů o přihlášení a při určitém počtu zakázat další pokusy z dané IP nebo nastavit timeout, po kterém bude možné přihlášení opakovat.

Forms authentication „

„

„

„

„

Při autentizaci z externího zdroje musí programátor vytvořit všechny potřebné funkce pro ověření uživatele. Externí zdroj přihlašovacích dat umožňuje přidávat uživatele dynamicky. Pokud je uživatel se zadaným heslem nalezen v externím zdroji, použije se opět metoda RedirectFromLoginPage, která vytvoří cookie a vrátí uživatele na stránku z původního požadavku. Typicky se používá datebáze. Primárním klíčem do tabulky s ověřovacími údaji je uživatelské jméno. Heslo je vhodné ukládat kryptovaně! Pro ověření hesla je nutné zadané heslo nejdříve převést na kryptované.

Forms authentication „

„

Programátor nemusí k přesměrování z login stránky používat metodu RedirectFromLoginPage. Třída FormsAuthentication nabízí metody pro získání původního URL požadavku – GetRedirectUrl a pro práci s cookie : „ „

„

„

SetAuthCookie – vytvoření autentizačního cookie FormsCookieName – získání jména autentizačního cookie

Vlastní obsluha je důležitá v případě, že cílový klient nepodporuje cookie. Pak je nutné informace o přihlášení vhodně vložit do query stringu. Programátor může využít tyto metody a poté použít klasické přesměrování Response.Redirect

Forms authentication „

Výsledná obsluha je o trochu složitější než při volání metody RedirectFromLoginPage. string redirectURL= FormsAuthentication.GetRedirectUrl(userName, false); FormsAuthentication.SetAuthCookie(userName, flase); string cookieName = FormsAuthentication.FormsCookieName; HttpCookie cookie = Response.Cookies[cookieName]; cookie.Expires = DateTime.Now.AddMinutes(20); Response.Redirect(redirectURL);

„

Další možností (nejsložitější) je přímo vytvoření tiketu, tj. třídy FormsAuthenticationTicket. Do konstruktru této třídy se vkládá verze tiketu, uživatelské jméno, datum vytvoření, datum expirace, perzistence tiketu a uživatelovi role (pole stringů).

Forms authentication „

„

Výhodou tiketu je, že v sobě nese informaci i o uživatelových rolích. Není tedy nutné při každém požadavku kontrolovat v externím zdroji do jakých rolí uživatel spadá. Stejně tak není nutné pro role dělat speciální cookie. FormsAuthenticationTicket at = new FormsAuthenticationTicket(1, userName, DateTime.Now, DateTime.Now.AddMinutes(20), false, userRoles); // kryptování tiketu string encryptedAt = FormsAuthentication.Encrypt(at); HttpCookie atCookie = new HttpCookie(FormsAuthentication.FormsCookieName, encryptedAt); Response.Cookies.Add(atCookie); Response.Redirect(FormsAuthentication.GetRedirectUrl(userName, false));

Forms authentication „

„

„

V souboru global.asax lze v metodě Application_AuthenticateRequest reagovat na autentizační proces. Tato metoda se využívá např. k vytvoření objektu GenericPrincipal. Obecně se pro reprezentaci uživatele ve Forms autentizaci používá objekt GenericPrincipal. Pokud je ale nutné provádět nějaké speciální funkce založené na rolích, je nutné vytvořit vlastní třídu, která bud implementovat rozhraní IIPrincipal.

Forms authentication „

„

Výhoda použití principala je především v aplikacích, které v kódu často testují roli. Jedná se o „čistější“ řešení. // ukázka vytvoření a přiřazení principala, bez chybových testů string cookieName = FormsAuthentication.FormsCookieName; HttpCookie atCookie = Context.Request.Cookies[cookieName]; FormsAuthenticationTicket at = Forms.Decrypt(atCookie.Value); string[] roles = at.UserData.Split(new char[] {‘|’}); FormsIdentity id = new FormsIdentity(at); GenericPrincipal principal = new GenericPrincipal(id, roles); Context.User = principal;

.NET Passport authentication „

„

„

„

.NET Passport je centralizovaná autentizační služba poskytovaná společností Microsoft. Jakmile se uživatel jednou zaloguje, může libovolně procházet všechny aplikace, které používají tento autentizační mód. Pro používání .NET Passport je nutné z MSDN stáhnout .NET Passport SDK. Toto SDK je volně dostupné pro vývoj a testování aplikace. Při nasazení aplikace je nutné splnit licenční podmínky, které kladou striktní bezpečnostní požadavky na aplikaci.

.NET Passport authentication „

„

„

„

Každá aplikace používající .NET Passport musí zaručit, že informace o uživateli budou uchovány v bezpečném prostředí a jejich přenos bude pouze přes bezpečnou komunikaci. Dále musí zajistit smazání PII (Personally Identifiable Information) cookie po logoutu klienta. .NET Passport vyžaduje, aby webová aplikace implementovala SII (single sign-in) službu a další služby zabývající se profily. Atd. Pouze pokud aplikace splní všechny podmínky, obdrží kryptovací klíč a další části potřebné k nasazení aplikace. Některé služby, které .NET Passport vyžaduje nejsou zadarmo.

.NET Passport authentication „

„

„ „

Tento mód je zajištěn PassportAuthenticationModule HTTP modulem. Pokud přijde na stránku, která používá tento autentifizační mód, požadavek, HTTP modul zkontroluje zda je v požadavku obsažen Passport ticket. Pokud ne je vrácen kód 302 a stránka je přesměrována na Passport Logon service. V query stringu jsou předány kryptované informace o původním požadavku. Po zadání přihlašovacích údajů je uživatel přes SSL přesměrován zpět na původní stránku. Po přihlášení je vytvořen tzv. Passport ticket, který se kryptovaný přenáší v požadavku. Používá se Triple DES kryptování. Každá aplikace má přiřazen vlastní kryptovací klíč.

.NET Passport authentication „

Pro použití .NET Passport autentizace se ve web.config nastaví :

„

V souboru global.asax Authenticate

lze

reagovat

na

událost

protected void PassportAuthentication_OnAuthenticate(object sender, PassportAuthenticationEventArgs e) { … Context.User = new GenericPrincipal(e.Identity, roles); …} „

V kódu se pro práci s .NET Passport používá třída PassportIdentity. Tato třída poskytuje informace o uživateli, Passport ticketu a metody pro přihlášení a odhlášení.

.NET Passport authentication „

Získání objektu PassportIdnetity : PassportIdnetity psId = Context.User.Identity as PassportIdentity;

„

Informace o autentizaci jsou na klientském počítači uloženy v pěti Cookies : „ „ „ „ „

„

MSPProf MSPAuth MSPSecAuth MSPProfC MSPConsent

Všechny tyto Cookies musí být smazány při odhlášení z aplikace (nastavit vlastnost Expires na DateTime.Now).

Autorizace v ASP.NET „

„

Autorizace je proces, při kterém se kontroluje zda má autentizovaný uživatel přístup k daným zdrojům na serveru. Autorizaci lze zajistit dvěma základními způsoby. „

„

„

FileAuthorizationModule – autorizace na základě přístupových práv v souborovém systému serveru. UrlAuthorizationModul – autorizace na základě povolených uživatelů a rolí v konfiguračním souboru aplikace.

Další možností řešení autorizace je vytvořit při autentizaci objekt Principala a přiřadit ho do Context.User. Pak lze v kódu metodou IPrincipal.IsInRole testovat autorizaci na základě role.

Autorizace v ASP.NET „

„

„

„

„

Základním způsobem je autorizace přes souborový systém. V NTFS souborovém systému se dá jednotlivým prvkům nastavit přístupová práva různých uživatelů a uživatelských skupin. Pokud se uživatel z webové aplikace pokusí přistoupit k prostředku, ke kterému nemá autorizaci, je v kódu vyhozena výjimka. Klient obdrží přístup odepřen. Tento způsob autorizace lze použít pouze s Windows autentizací. Používá se spolu s impersonalizací.

Autorizace v ASP.NET „

„ „

Druhá metoda autorizace je založena na informaci uložené v souboru web.config. Lze definovat pozitivní i negativní autorizaci (allow / deny). Struktura elementu pro autorizaci je <element users=“…” roles=“…” verbs=“…” /> „ „ „ „

„ „

Element je allow nebo deny users obsahuje výčet uživatelských jmen. roles obsahuje výčet rolí. verbs obsahuje výčet typů HTTP požadavků, na které se autorizace vztahuje (lze použít GET, POST, HEAD). Alespoň jeden za atributů users a roles musí být použit. Atribut verbs je nepovinný.

Autorizace v ASP.NET „

Pro definování přístupu lze použít dva zástupné znaky : „ „

„

„

* představuje všechny uživatele ? představuje anonymní uživatele

Lze vytvářet hierarchie. V kořenovém adresáři aplikace se nastaví základní přístupová práva. V podadresářích lze pro další aplikace v souborech web.config nastavit nová prává, která mají vyšší váhu než práva z nadřazeného adresáře. Vzniká tím hierarchie přístupových práv, kdy se v podadresáři použijí všechna práva z nadřazeného adresáře, kromě práv kolidujících s nově vytvořenými. Účet pod danou doménou musí být při autorizaci zadán ve tvaru doména\uživatel

Autorizace v ASP.NET „

Ukázka Forms autentizace a autorizace : <deny users=“?” /> <deny roles=“User, PowerUser” verbs=“POST” />

Komunikace přes SSL „

„ „

„

„

„

SSL zajišťuje bezpečnou komunikaci mezi dvěma počítači. Komunikace probíhá přes protokol HTTPS – port 443. Používá komplexní kryptografické řešení. Snižuje výkonnost serveru a prodlužuje dobu odezvy. Především navázání komunikace je časově a výkonově náročné. Výkonnost lze zvýšit redukováním obsahu stránek, které jsou přes HTTPS poslány – redukování množství textu a obrázků. Je potřeba tzv. certifikát, který je vydávaný třetí stranou (tzv. autorizační autoritou). Není zadarmo.

Komunikace přes SSL „

„

„

„

Certifikát funguje jako autorizace. Je nutné ho nainstalovat na server. Pokud klient začne komunikovat se severem přes HTTPS, vyžádá si certifikát a prověří si ho v seznamu důvěryhodných serverů u autorizační autority. Některé autorizační autority poskytují zadarmo certifikáty pro testování a vývoj aplikace. Při navazování komunikace se používá výkonnostně náročné asymetrické kryptování založené na veřejném a privátním klíči. Při této komunikaci se vymění veřejné klíče pro symetrické kryptování, které je použito dále při komunikaci.

Komunikace přes SSL „

„

Autorizační autorita tedy vydává certifikáty, generuje kryptovací klíče a ověřuje identitu serveru. Pro použití SSL ve webové aplikaci je třeba udělat několik věcí : „ „ „ „

„

V IIS vygenerovat požadavek na certifikát Vyžádat si certifikát od autorizační autority Nainstalování certifikátu na server s IIS Pokud se používá testovací certifikát, je nutné ho nainstalovat do klientského prohlížeče. Požití zabezpečené komunikace.

Komunikace přes SSL „

Vygenerování požadavku na certifikát – Ovládací Panely -> Nástroje pro správu -> Internetová informační služba. Vybrat výchozí webový server -> Vlastnosti -> záložka Zabezpečení adresáře -> Certifikát serveru. Po dokončení průvodce vznikne souboru .cer. Tento soubor představuje požadavek. „

Pokud se bude na serveru používat zabezpečená komunikace, je nutné začít s nastavováním od rootu, tedy od Výchozího webového serveru. Poté je možné nastavovat certifikáty i pro jednotlivé adresáře aplikací.

Komunikace přes SSL „

Vyžádání certifikátu – tato část je zcela závislá na vybrané autorizační autoritě. Vyžádání se provádí na jejich internetových stránkách. Ve formuláři se vyplní základní údaje a připojí se .cer soubor. „

„

Obecně nabízejí autorizační autority různé typy podpory a jištění (uhrazení škody do částky závislé na typu služby, který si zaplatíte) za různé částky. Např. společnost VeriSign nabízí základní certifikát (jištění $100000) za $349 ročně. Cena certifikátů se dále liší podle kryptování, které s nimi lze využít (Certifikáty se 128 bitovým kryptováním jsou výrazně dražší).

Komunikace přes SSL „

„

Instalace certifikátu – po obdržení certifikátu (.cer soubor nebo část emailové zprávy, kterou je nutné do .cer souboru zkopírovat), je nutné certifikát na server nainstalovat. Stejně jako pří vytváření požadavku se spustí wizard, ve kterém se certifikát nainstaluje. Použití zabezpečené komunikace – zabezpečená komunikace se použije ve chvíli, kdy klient použije požadavek na HTTPS nebo kdy aplikace přesměruje klienta na HTTPS. Pozor – pokud se dále v aplikaci používají relativní adresy, používá se stále protokol HTTPS. Pro návrat k protokolu HTTP je nutné zadat absolutní adresu s tímto protokolem.

Komunikace přes SSL „

„

Pokud má být komunikace s aplikaci či stránkou možná jen přes SSL, je třeba si to vynutit. Vybrat danou složku či soubor v ovládání IIS -> Vlastnosti -> Zabezpečení adresáře (souboru) -> Zabezpečená komunikace, tlačítko Upravit. V tomto dialogu lze nastavit : „ „ „ „

„

Nutnost použití SSL Nutnost použití SSL se 128 bitovým kryptováním Ignorování/Akceptování/Vyžadování klientských certifikátů Mapování klientských certifikátů na Windows uživatelské účty.

Vhodné, aby úvodní stránka aplikace nebyla HTTPS, většinu uživatelů nenapadne (nebo nezná rozdíl mezi http a https), že se aplikace schovává za https a zadá jen http.

Závěr „

„

Cílem této přednášky bylo poskytnout informace o tom co je bezpečnost a jak jí použít při vytváření webových aplikací v .NET Framework. Nejedná se o tutorial, který by čtenáře „vedl za ručičku“. Je to material, který ukazuje cestu kudy se vydat při vlastní implementaci.

Zdroje „

„

„

„ „

Programming Microsoft ASP.NET by Dino Esposito, Microsoft Press, 2003 Developing Web Applications with Microsoft Visual Basic .NET and Visual C# .NET by Jeff Webb, Microsoft Press, 2003 Building Secure ASP.NET applications, Microsoft Press, 2002 IIS Help MSDN