BAKALÁŘSKÁ PRÁCE Marek Pavelek
Un ico rn Co lle ge 20 11 Un ico rn Co lle ge, V K ap slo vn ě 27 67 /2, P ra h a 3, 1 30 00 Ná ze v p rá ce v ČJ: Ná ze v p rá ce v AJ: Be zp e čno st AS P. NET ap lika cí AS P. NE T W eb Ap p licat io n Se cu rit y Au to r: Ma re k P a ve le k Aka de m ický ro k: 20 10 /2 0 11 Ko nt a kt: E -ma il: pa ve le kma re k@ gma il. co m Te l. : (+4 20 ) 6 06 72 9 8 52
1. ZADÁNÍ 3
2. ABSTRAKT Tato bakalářská práce je zaměřena na oblast bezpečnosti v prostředí ASP.NET. Cílem práce je analyzovat toto prostředí a popsat, jaké prostředky je možné pro zabezpečení aplikace implementované v ASP.NET využít. Významnou částí je popis způsobů ověřování pomocí operačního systému Windows, služby Passport a formulářů a s tím spojený popis autorizace neboli přidělování práv těmto ověřeným uživatelům a jejich přiřazování do rolí. V další části práce vysvětluje, jak zabezpečit komunikaci s aplikací tak, aby tuto komunikaci útočníci nemohli odposlouchávat ani nijak měnit. Dále jsou popsána nejčastější zranitelná místa webových aplikací představující určité hrozby a jim odpovídající řešení v prostředí ASP.NET. V poslední části je popsána implementace multiuživatelské aplikace uchovávající citlivá data uživatelů za využití určitých bezpečnostních prvků ASP.NET ve Visual Studio 2010. Aplikace využívá vestavěných komponent pro ukázku efektivnosti práce s webovými aplikacemi nad.net frameworkem. Klíčová slova: bezpečnost ASP.NET aplikací, ověřování ASP.NET, autorizace ASP.NET, role v ASP.NET, šifrování dat v ASP.NET, zranitelná místa webové aplikace, hrozby webové aplikace, zabezpečená komunikace. 4
3. ABSTRACT This Bachelor thesis focuses on security in the ASP.NET environment. The thesis aims to analyze the ASP.NET environment and to describe available means of securing applications implemented in this environment. A significant portion of the thesis is devoted to the description of methods of verification through the Windows operating system, the Passport service and forms and the related description of authorization or, in other words, allocation of rights to these verified users and assignment of users to roles. The thesis goes on to explain how to secure communication with an application so that hackers cannot tap into or alter this communication. This is followed by a description of the most vulnerable spots in and potential threats to web applications and a description of the corresponding solutions in the ASP.NET environment. The last part describes implementation of a multi-user application that stores sensitive user data by using certain security elements of ASP.NET in Visual Studio 2010. The application makes use of built-in components to demonstrate the effectiveness of work with web applications over the.net framework. Keywords: security of ASP.NET applications, ASP.NET verification, ASP.NET authorization, ASP.NET roles, data encryption in ASP.NET, vulnerable spots in web applications, threats to web applications, secured communication. 5
4. PROHLÁŠENÍ Prohlašuji, že svou bakalářskou práci na téma jsem vypracoval samostatně pod vedením vedoucího bakalářské práce a s použitím odborné literatury a dalších informačních zdrojů, které jsou v práci citovány a jsou též uvedeny v seznamu literatury a použitých zdrojů. Jako autor uvedené bakalářské práce dále prohlašuji, že v souvislosti s vytvořením této bakalářské práce jsem neporušil autorská práva třetích osob, zejména jsem nezasáhl nedovoleným způsobem do cizích autorských práv osobnostních a jsem si plně vědom následků porušení ustanovení 11 a následujících autorského zákona č. 121/2000 Sb. V Praze dne.. Marek Pavelek 6
5. PODĚKOVÁNÍ Děkuji vedoucímu bakalářské práce Petru Buchlákovi a konzultantu Petru Pušovi za účinnou metodickou, pedagogickou a odbornou pomoc a další cenné rady při zpracování mé bakalářské práce. 7
6. OBSAH 1. 2. 3. 4. 5. 6. 7. Zadání... 3 Abstrakt... 4 Abstract... 5 Prohlášení... 6 Poděkování... 7 Obsah... 8 Úvod... 10 7.1 Použité konvence... 10 8. Model zabezpečení ASP.NET aplikací...11 8.1 Architektura zabezpečení... 11 8.1.1 Principál... 12 8.2 Ověřování... 13 8.2.1 Ověřování systému Windows...14 8.2.2 Ověřování pomocí účtu služby Passport...19 8.2.3 Ověřování založené na formulářích...21 8.2.4 Režim ověřování None... 23 8.3 Autorizace... 23 8.3.1 Způsoby autorizace v ASP.NET...24 8.3.2 Role... 27 8.3.3 Možnosti autorizace na business vrstvě...29 8.3.4 Zabezpečení konfiguračních souborů...31 8.4 Členství... 32 8.4.1 Architektura API členství... 33 9. Zabezpečení komunikace... 35 9.1 Zajištění zabezpečené komunikace...35 9.1.1 Utajení a integrita... 35 9.1.2 Certifikáty... 35 9.1.3 SSL (Secure Sockets Layer)...37 10. Kryptografie... 38 10.1 Symetrická kryptografie... 39 10.1.1 Implementace symetrických šifer v ASP.NET...40 10.2 Asymetrická kryptografie... 41 10.2.1 Implementace asymetrických šifer v ASP.NET...42 10.3 Jednosměrná kryptografie (heš, otisk)...43 10.3.1 Implementace hešů v ASP.NET...44 10.4 Zabezpečení klíče... 45 11. Hrozby... 46 11.1 SQL Injection... 46 11.2 Cross-Site Scripting (XSS)... 47 11.3 Session hijacking... 48 11.4 Man-In-The-Middle... 49 11.5 Denial of Service (DoS)... 50 11.6 Automatizované zakládání účtů...52 11.7 Kritická bezpečnostní chyba... 53 12. Multiuživatelská aplikace... 54 12.1 Implementační technologie... 54 12.2 Popis aplikace... 54 12.2.1 Big picture řešení... 55 12.2.2 Use-case diagram... 56 12.2.3 Přehled aktérů... 57 12.2.4 Přehled use-case... 57 8
12.3 Základní struktura... 58 12.4 Nastavení formulářové autentizace...58 12.5 Přistup k databázi... 59 12.6 Zabezpečení WCF... 59 12.7 Dostupnost pouze pro členy... 59 12.8 Konfigurace rolí... 60 12.9 Klíčové stránky aplikace... 61 12.9.1 Přihlašovací stránka (~/Anonym/Login.aspx)...61 12.9.2 Registrační stránka (~/Anonym/Register.aspx)...61 12.9.3 Práce s kartou (~/Prihlasen/AktivacePlatebniKarty.aspx)...62 12.9.4 Informace o kartě (~/Prihlasen/PlatebniKartaInfo.aspx)...64 12.9.5 Hodnocení zájezdů (~/Prihlasen/rozcestnik.aspx)...65 13. Závěr... 67 14. Conclusion... 68 15. Seznam použité literatury... 69 16. Seznam použitých internetových zdrojů...70 17. Seznam použitých symbolů a zkratek...72 18. Seznam obrázků... 73 19. Seznam tabulek... 74 20. Seznam zdrojových kódů... 75 21. Seznam příloh... 76 Příloha 1 Vlastnosti a metody důležitých tříd API rolí...77 Příloha 2 Vlastnosti a metody důležitých tříd API členství...78 Příloha 3 CD obsahující projekt představené aplikace, projekt představené aplikace pro otestování s přiloženým manuálem a SQL skripty...79 9
7. ÚVOD ASP.NET slouží pro vývoj dynamických stránek, webových aplikací a webových služeb běžících na straně serveru. Tato technologie zapadá do.net Frameworku a její obrovskou výhodou je poskytování již předem naimplemetovaných částí aplikace, které by programátor sám musel zdlouhavě psát. Webové aplikace lze vyvíjet v mnoha programovacích jazycích díky CLR (Common Language Runtime). V této práci je použit programovací jazyk C# a integrované prostředí Visual Studio 2010. Bezpečnost je základní součástí implementace systémů a měla by se plánovat již od samého počátku. To platí zejména u webových aplikací, k nimž má přístup kde kdo. Spousta webových stránek se tomuto oboru nevěnuje a je velice snadné na ně provést útok. Cílem této práce je analyzovat prostředí ASP.NET z hlediska zabezpečeného přístupu a správy citlivých dat. Analýza definuje i nejčastější zranitelná místa webové aplikace a s tím spojené řešení na eliminaci těchto míst. Práce je určena pro čtenáře, kteří již mají určité zkušenosti s programováním v jazyce C# a základní znalosti tvorby webových aplikací pomocí ASP.NET. Případné neznámé pojmy a zkratky jsou uvedeny v poznámkách pod čarou, nebo na konci práce v kapitole 16. 7.1 Použité konvence 1. Neproporcionální písmo objekty, odkazy v textu, soubory, fragmenty kódu jsou psaný tímto písmem. 2. Tučné písmo je použito pro důležité informace. 10
8. MODEL ZABEZPEČENÍ ASP.NET APLIKACÍ První kapitola popisuje, s čím klient komunikuje, když přistupuje k ASP.NET aplikaci, s čím komunikuje samotná aplikace a zdali je to bezpečné. Dále jsou vysvětleny pojmy jako ověřování, autorizace a sepsány jejich možné způsoby a jak tyto způsoby obecně implementovat. 8.1 Architektura zabezpečení Při komunikaci klienta s ASP.NET aplikací prochází klient přes Internet Information Services(IIS). IIS je aplikace umožňující realizovat webový server. Jejím obsahem je Správce IIS, díky kterému můžeme pohodlně spravovat webový server. V případě přístupu klienta na server je nejprve provedeno ověření IIS, pokud je aktivní, a až poté je klient ověřen ASP.NET aplikací. Obrázek 1: Bezpečnostní architektura technologie ASP.NET Zdroj: technet.microsoft.com/cs-cz/library/cc737863.aspx, vlastní úprava Jak již bylo zmíněno, konfiguraci IIS serveru provádíme pomocí Správce IIS. Aplikace ASP.NET se konfiguruje v souborech s příponou.config (Web.config, machine.config..). Aplikaci ASP.NET je umožněno využívat nízkoúrovňové zabezpečovací funkce platformy.net Framework. Jedná se konkrétně o zabezpečení přístupu ke kódu, které má za úkol omezit přístup 11
škodlivého kódu, a zabezpečení založené na rolích, které je reprezentováno jmenným prostorem System.Security.Permissions. (technet.microsoft.com/cs-cz/library/cc737863.aspx) 8.1.1 Principál Slouží jako základ bezpečnosti v.net Frameworku a je reprezentován jmenným prostorem System.Security.Principal. Jmenný prostor definuje rozhraní IPrincipal a IIdentity. IPrincipal slouží pro ověření, zda je uživatel obsažen v určité roli metodou IsInRole(), a poskytuje identitu tohoto uživatele. Pomocí rozhraní IIdentity můžeme získat informace o identitě konkrétního uživatele, jako jsou například jméno, typ ověřování a odpověď na otázku, zda je uživatel ověřen. Spolu tvoří základ pro ověřování podle rolí. Tato rozhraní jsou přidružena k jednotlivým vláknům aplikace. Pro zjištění kontextu zabezpečení aktuálního uživatele slouží třída Thread.CurrentPrincipal. Obrázek 2: Implementační třídy rozhraní IPrincipal a IIdentity Zdroj: Microsoft Corporation (2004), vlastní úprava Rozhraní obsahují jednotlivé implementace tříd pro různé způsoby ověřování. WindowsPrincipal slouží pro aplikace používající ověřování systému Windows. GenericPrincipal pak pro aplikace používající formulářovou, passportovou a vlastní autentizaci. WindowsIdentity obsahuje informace o uživateli v systému Windows. Tyto informace získáme zavoláním statické metody WindowsIdentity.GetCurrent(). V objektu WindowsIdentity je umístěna i vlastnost Token, která vrací token uživatelského účtu. 12
FormsIdentity nese informace o uživateli ověřeném formulářovou autentizací. V objektu FormsIdentity je WindowsIdentity umístěna vlastnost na rozdíl od vlastnosti Ticket FormsAuthenticationTicket s v případě informacemi o autentizaci uživatele. GenericIdentity reprezentuje informace o logickém uživateli, jež není spravován žádným operačním systémem. Používá se v případě vlastní implementace ověřování a autorizace. PassportIdentity obsahuje informace o ověřeném uživateli ve službě Passport včetně informací o profilu této identity. 8.2 Ověřování Proces, ve kterém se zkoumá identita určitého subjektu. Pokud je identita známá, je subjekt považován za ověřený a je mu povolen přístup do zabezpečené části systému. Nejčastěji se zkoumá identita uživatele na základě uživatelského jména a hesla, nebo předloženého certifikátu. Jako další subjekt, u kterého se zkoumá identita, si můžeme představit systém, který přistupuje k jinému systému. Je známo, že rozsáhlé aplikace obsahují mnoho subsystémů, mezi kterými se také musí aplikovat ověřování, a byla by veliká bezpečnostní chyba u nich identitu neověřovat. Proces ověřování si lze představit v reálném životě. Jste například budoucí zaměstnanec Jaderné elektrárny Temelín. Nejprve vás musí zaměstnavatel přijmout. To znamená, že mu předložíte například vaše CV a občanský průkaz. Poté, co jste přijat, obdržíte jako každý zaměstnanec pracovní oděv a kartičku s přístupovými údaji, na níž je uvedeno i vaše jméno a příjmení. Tedy kartička a pracovní oděv vás neustále identifikují jako zaměstnance Temelína. Celkový proces ověřování má za úkol identifikovat uživatele. Zde si musíme uvědomit, že ověřování neprovádíme pouze jednou a to konkrétně při přihlašování uživatele do systému, ale ověřování provádíme pro každý požadavek. (MACDONALD, FREEMAN, SZPUSZTA, 2010, s. 27) Režimy ověřování v prostřední ASP.NET Žádné Ověřování systému Windows Ověřování založené na formulářích Ověřování pomocí účtu služby Passport 13
Totožnost uživatele tedy získáme způsobem, kterým se řídí zvolený typ ověřování. Ověřování můžeme také využít pro přizpůsobování, například pro nastavení vzhledu webu a vkládání vlastního obsahu. Možností je samozřejmě mnoho, nejedná se tedy pouze o personalizaci. Důležitým faktem je, že ověřování nemůže omezovat procesy uživatele. K tomuto účelu slouží autorizace (viz kapitola 8.3). (MICROSOFT CORPORATION, 2004, s. 42) Režim ověřování se v ASP.NET nastavuje v souboru Web.config, který se nachází v kořenovém virtuálním adresáři aplikace. Jedná se konkrétně o část kódu: <authentication mode="none Windows Passport Forms"> Do uvozovek se uvádí pouze jeden z těchto čtyř režimů ověřování. Každý z nich je popsán v následujících podkapitolách. 8.2.1 Ověřování systému Windows Tento způsob ověřování se využívá hlavně ve firemním intranetu, kde mají uživatelé vytvořený účet ve Windows, přes který se do systému přihlašují. Systém tedy využívá již existující údaje o uživatelích a jejich členství ve skupinách. Největším přínosem této metody je, že lze provádět neviditelné ověřování, při němž (v závislosti na použitých nastaveních a architektuře sítě) není nutná samostatná přihlašovací procedura. Ověřování není implementováno v ASP.NET, ale provádí se na úrovni Internetové informační služby (IIS). Díky tomu odpadají starosti spojené s přihlašovací stránkou a vše, co k ní náleží (validita dat, přístup do databáze a další věci s tím spojené). Jedna z obrovských výhod spočívá v použití nástroje Správce služby IIS, v kterém se provádí veškerá konfigurace tohoto režimu. (MACDONALD, FREEMAN, SZPUSZTA, 2010, s. 115-116) Důležitým bezpečnostním prvkem v ověřování systému Windows je zosobnění, jenž nám dává možnost dočasně měnit identitu využívanou ASP.NET k provádění určitých úloh. Zosobnění je ve výchozím nastavení zakázáno. To znamená, že jsou úlohy prováděny pod stejným uživatelským účtem (většinou ASPNET účet). Pro povolení zosobnění v aplikaci musíte do souboru Web.config přidat prvek < identity >. Povolení zosobnění pro aplikaci <identity impersonate="true"/> Zosobnění uživatele pro všechny požadavky aplikace <identity impersonate="true" username="unicorn\pavelekm" password="pass"/> 14
Pro dočasné provádění úloh pod zvolenou identitou slouží metoda WindowsIdentity.Impersonate(), kterou voláme přímo v kódu programu. Metoda pracuje buď s tokeny účtů, a nebo instancí. Token obsahuje informace o ověření uživatele. (207.46.16.252/cs-cz/library/cc787120(WS.10).aspx) Pokud máme token již uložený v proměnné, zosobnění vyvoláme velice jednoduše: WindowsIdentiy.Impersonate(token); Samotná instance aktuálně přihlášeného uživatele se volá následovně: (WindowsIdentity)HttpContext.Current.User.Identity; Obrázek 3: Identita protéka přes síťové hopy Zdroj: MacDonald, Freeman, Szpuszta (2010), vlastní úprava Se zosobněním souvisí i pojem delegování. Při použití zosobnění nelze přistupovat na jiný server v síti pod dočasnou identitou. Delegování je založeno na stejném konceptu jako zosobnění, ale přístup na jiný server umožňuje způsobem, který převezme ticket ověřeného uživatele a pošle ho jinému serveru v síti. Delegování lze využít v integrovaném ověřování systému Windows jen v případě, pokud má původní server patřičná oprávnění a je zde ověřovací protokol Kerberos (více o protokolu Kerberos v kapitole 9.1.1.3). V metodě ověřování algoritmem digest není delegování možné, naopak v základním ověřování lze delegování uplatnit po splnění určitých podmínek. (MACDONALD, FREEMAN, SZPUSZTA, 2010, s. 136-137) 15
Obrázek 4: Ověřování systému Windows Zdroj: MacDonald, Freeman, Szpuszta (2010), vlastní úprava 16
8.2.1.1 Základní ověřování Obrázek 5: Přihlašovací okno základního ověřování s varováním Zdroj: http://poorperformance.com /wiki/index.php? title=website_authentication Uživatel zadá své uživatelské jméno a heslo do přihlašovacího okna. To se mu zobrazí při přístupu do systému, který žádá ověření. Na základě tohoto pověření se prokáže identita uživatele. Jedná se o internetový standard založený na specifikaci RFC 26171. Heslo uživatele je kódováno algoritmem Base64 ještě před jeho odesláním do sítě. Základní ověřování není bezpečné a mělo by se používat společně v kombinaci se SSL šífrováním nebo s jinou formou bezpečné komunikace (viz kapitola 9) a to z důvodu nekryptování přihlašovacích údajů po jejich odeslání od klienta na server. Nekryptovaná data jsou lákavou kořistí pro potencionální útočníky, pro něž je získání přihlašovacích dat tímto způsobem velice jednoduché. Microsoft z tohoto důvodu umístil do přihlašovacího okna varování, ve kterém zmiňuje, že odeslání vyplněných údajů není bezpečné. (MACDONALD, FREEMAN, SZPUSZTA, 2010, s. 118) 1 Stránky tohoto standardu jsou: http://www.faqs.org/rfcs/rfc2617.html 17
Obrázek 6: Proces základního ověřování Zdroj: Vlastní ilustrace 8.2.1.2 Ověřování algoritmem Digest Byl zaveden v IIS 5.0. Stejně jako základní ověřování požaduje od klienta zadání jeho ověřovacích údajů v podobě přihlašovacího okna. Jeho výhodou oproti základnímu ověřování je zdokonalené zabezpečení při odesílání pověření uživatele v rámci sítě pomocí heše MD5 2. Nevýhodou tohoto ověřování je, že ho lze použít jen v případě, kdy klient používá webový prohlížeč Internet Explorer 5.0 a vyšší verze. V případě, že potencionální útočník získá heš, není mu k ničemu. Původní heslo se z něho získat nedá a ani ho nelze použít pro opakované útoky (více o heši v kapitole 10.3). (207.46.16.252/cs-cz/library/cc782661(WS.10).aspx) Obrázek 7: Proces ověřování algoritmem Digest Zdroj: Vlastní ilustrace 2 Algoritmus s délkou heše 128-bit používaný pro ukládání hesel 18
8.2.1.3 Integrované ověřování systému Windows Tato metoda ověřování je velice zajímavá v tom, že ověřování se provádí automaticky bez nutnosti zadávat uživatelské jméno a heslo na straně klienta. Samotné ověření pak probíhá přes server IIS, který zažádá klienta, aby se ověřil. Webový prohlížeč klienta automaticky odešle token reprezentující účet aktuálního uživatele systému Windows. V případě odmítnutí tokenu IIS serverem je uživateli zobrazeno běžné přihlašovací okno. Metoda ověřování před odesláním jednosměrně zakóduje přihlašovací údaje, díky tomu je tato metoda považována za bezpečnou. Jako jediný webový prohlížeč, který tuto metodu podporuje, je Internet Explorer. Z tohoto důvodu je většinou implementován v intranetových řešeních. Pro fungování musí být také na straně IIS serveru zakázáno anonymní ověřování. (MACDONALD, FREEMAN, SZPUSZTA, 2010, s. 119) První ověřovací protokol využívající Integrované ověřování systému Windows se nazývá Kerberos 5. Tento protokol je extrémně bezpečný a lze ho využít v případě, že na straně klienta a serveru je nainstalován systém Windows 2000 nebo vyšší a pracují v doméně Active Directory 3. Vysoce bezpečný je i druhý protokol NTLM (NT LAN Manager), který využijeme tam, kde Kerberos využít nelze. Rozdíl mezi těmito protokoly z pohledu ověřování klientů je následující. NTLM ověřuje klienty mechanismem výzva/odezva, zatímco Kerberos pracuje na principu ticketů. Nutno zmínit, že Kerberos oproti NTLM podporuje i delegování. (cs.wikipedia.org/wiki/kerberos_(protokol)) 8.2.2 Ověřování pomocí účtu služby Passport Služba Passport je poskytována společností Microsoft bezplatně. Během vývoje této služby ji Microsoft několikrát přejmenoval a nyní nese název Windows Live ID. Myšlenka spočívá v jednotném přihlášení uživatele pod určité webové servery podporující tuto službu. Díky tomu se uživatel, který chce získat přístup k chráněným prostředkům určitého webového serveru, nemusí znovu přihlašovat a pamatovat si tak různá uživatelská jména a hesla k těmto webovým serverům. Některé webové servery požadují například i vaši adresu, telefonní číslo a ostatní osobní informace. Samozřejmě je velice nepříjemné vyplňovat tyto informace při každé registraci na webovou stránku. I na straně druhé musí provozovatelé služeb bezpečně uchovávat citlivá uživatelská data a nakládat s nimi podle stanovených norem daného státu. (www.lupa.cz/clanky/microsoft-passport-v-koncich-nebo-na-zacatku/?labelsboxlabelid=38&do=labelsbox-switch) 3 Adresářová služba od společnosti Microsoft. 19
Z pohledu bezpečnosti používá služba Windows Live ID standardní bezpečnostní technologie šifrující pověření uživatele při každém jeho přenosu. Proces ověřování neprobíhá na straně webového serveru, který ověření žádá. Pouze klienta přesměruje na stránku služby Windows Live ID, kde potřebné přihlašovací údaje vyplní. Posléze je ověřený klient znovu přesměrován na původní stránku. Obrázek 8: Proces ověřování službou Passport Zdroj: http://www.extremeexperts.com/net/articles/implementingpassportauth.aspx, vlastní úprava Domovská stránka této služby je www.passport.com. Zde si můžete vytvořit váš vlastní Windows Live ID účet a využívat přednastavených služeb jako Hotmail 4, Messenger5, SkyDrive6 a jiné. Pokud chcete Windows Live ID implementovat do ASP.NET aplikace, má Microsoft přichystané velice jednoduché řešení. Nese název Windows Live ID Web Authentication Software Development Kit (SDK) a můžete si ho zdarma stáhnout na stránkách Microsoftu. (zdrojak.root.cz/clanky/implementace-prihlasovani-pomoci-live-id/) 4 E-mail zdarma od společnosti Microsoft 5 Klient pro instant messaging od společnosti Microsoft 6 Služba pro uchovávání dat od společnosti Microsoft 20
8.2.3 Ověřování založené na formulářích Toto téma rozeberu podrobněji než předchozí způsoby ověřování, jelikož se jedná o nejpoužívanější ověřování v ASP.NET aplikacích a toto ověřování jsem použil i v mé multiuživatelské ASP.NET aplikaci. Jak je již z názvu patrné, ověřování je prováděno na základě formuláře. Ve většině případů je tento formulář umístěn na přihlašovací stránku webu a obsahuje textová pole pro zadání uživatelského jména a hesla. Tyto údaje jsou následně odeslány na server a porovnány s daty v datovém zdroji. Formulářová autentizace je založena na ověřovacích lístcích. V případě, že se uživatel úspěšně přihlasí do systému, je mu vygenerován lístek obsahující základní informace o uživateli, pomocí něhož se prokazuje v budoucí komunikaci se serverem. Jesliže lístek uživatel nevlastní a přistupuje na část stránky, kde jej vlastnit musí, ASP.NET ho automaticky přesměruje na přihlašovací stránku. Předávání se provádí převážně pomocí cookies, které se ukládají v klientském počítači. Taktéž je možno lístek předávat v URL požadavku, kde je lístek zakódován. Pokud uživatel přistupuje na server, který mu již cookies odeslal, jeho internetový prohlížeč tato data odešle zpět serveru. (www.aspnet.cz/articles/188-jak-funguje-forms-authentication-a-autentizacni-tickety) Obrázek 9: Proces formulářové autentizace bez existence autentizační Cookie Zdroj: Vlastní ilustrace Autentizační lístek obsahuje následující informace: Náhodná hodnota - osm náhodně vygenerovaných bajtů Verze obsahuje číslo formátu lístku Uživatelské jméno obsahuje uživatelské jméno, kterému slouží toto pověření Datum a čas vystavení který den a v kolik hodin byl lístek vystaven Datum a čas vypršení kdy a v kolik hodin lístek vyprší 21
Uživatelská data tato hodnota je naplněna libovolnou informací, kterou sem může vložit programátor Délka trvání - uvádí se zde, zdali je pověření trvalé, či nikoliv V textu výše jsem zmínil, že se jedná o nejpoužívanější způsob ověřování, ale neřekli jsme si přoč. Prvním důvodem je volnost provedení. Na rozdíl od ověřování pomocí Windows nebo služby Passport si zde můžete určovat, jak bude ověřování implementováno, kam se budou citlivé informace ukládat, jak dlouho zůstane ticket u klienta, popřípadě jaký bude mít vzhled vaše přihlašovací stránka. Dalším rozdílem je funkčnost ve všech webových prohlížečích. Pro zpřístupnění formulářové autentizace nemusíte nastavovat atribut <authentication mode=""> v souboru Web.config, jelikož je tento atribut při vytvoření nového projektu implicitně nastavena na Forms. Značka <forms> v sekci <authentication> představuje důležité volby ověřování. Tyto volby jsou shrnuty v následující tabulce. Tabulka 1: Atributy pro element <forms> Atribut Možnost Popis name Určuje název HTTP cookie pro ověřování. Výchozí hodnota je nastavena na.aspxauth. V případě, že na jednom serveru běží více jak jedna aplikace, je potřeba tuto hodnotu změnit pro každý Web.config aplikace. loginurl Určuje, kam bude uživatel přesměrován v případě, že nevlastní ověřovací cookie. Základním nastavením je stránka default.aspx. protection Určuje typ šifrování, které se pro ověřovací cookies použije. Původní hodnota je nastavena na All. All Ověřovací cookie se šifruje (pomocí šifry Triple-DES) a podepisuje. None Tato možnost není doporučována a znamená, že ověřovací cookies se nešifrují ani nepodepisují. Encryption Ověřovací cookie se šifruje použítím šifry Triple-DES nebo DES Validation Ověřovací cookie se podepisuje timeout Udává počet minut do vypršení platnosti ověřovací cookie. Původní hodnota je nastavena na 30. path Specifikuje cestu pro cookies zaslaných aplikací. Původni hodnota je /. requiressl Určuje, zdali je SSL připojení vyžadováno pro přenost ověřovacích cookie. Původní hodnota je nastavena na false. true Pokud na webovém serveru není aktivováno SSL, webový prohlížeč nebude přenášet ověřovací cookie. To znamená, že 22
formulářová autentizace nebude funkční. flase SlidingExpir ation Na webovém serveru není vyžadováno aktivní SSL Určuje, zda se bude doba života ověřovacího cookie prodlužovat (vyresetováním expirační doby) na základě nově vytvořených požadavků. Původní hodnota je nastavena na false. true Klouzavá expirační doba je aktivována. false Klouzavá expirační doba není aktiví. cookieless Specifikuje, zda bude ASP.NET aplikace zasílat ověřovací cookie klientovi. UseCookies Bude zasílat klientovi ověřovací cookie. V případě, že klientský prohlížeč cookie nepodporuje, ověření nebude fungovat a uživatel se nikdy nepřihlásí. UseUri Ověřovací lístek se nebude zasílat v cookies, ale bude zakódován do URL. AutoDetect Pokud prohlížeč cookies podporuje, ověřovací lístek je předáván pomocí cookies, v opačném případě bude kódován do URL. UseDeviceP Ověřovací lístek je předán volbou specifikovanou v profilu zařízení. Tento profil je uložen na webovém serveru. rofile Zdroj: msdn.microsoft.com/en-us/library/1d3t3c61.aspx 8.2.4 Režim ověřování None Nedochází k zádnému ověřování. Pokud plánujete vytvořit vlastní ověřování například pomocí jiné služby než Passport, je tento režim na místě. 8.3 Autorizace Proces autorizace je v zabezpečených systémech nezbytný. Nastává hned po ověření subjektu a jeho úkolem je stanovovat práva a omezení tomuto subjektu. Pomocí autorizace tedy docílíme dalšího stupně bezpečnosti systému v podobě omezení přistupu k zabezpečeným prostředkům nepověřeným subjektům. Stejně jako u ověřování si autorizaci můžeme představit v reálném životě. Pokračujme tedy se zaměstancem Temelína, který je již ověřen. Zaměstnanec má stanovenou určitou práci, kterou má za úkol vykonat. Tato práce je uskutečněna v některém ze segmentů této elektrárny. Zaměstnanec tedy musí projít určitým počtem segmentů, aby se dostal k tomu svému, kde má práci vykonat. K tomuto účelu slouží jeho karta, která ho identifikuje. Díky ní prochází segmenty, které má od zaměstnavatele povoleny. V případě, že chce zaměstnanec projít segmentem, ve 23
kterém nic dělat nemá, zabezpečovací dvěře (popřípadě ochranka) ho do tohoto segmentu nepustí. Nebylo by zrovna vhodné, aby zaměstnanec obsluhující stroj pro odvoz jaderného odpadu měl přístup k panelu pro manipulaci s jadernými tyčemi. 8.3.1 Způsoby autorizace v ASP.NET 8.3.1.1 Autorizace podle souboru Provádí se na základě práv v souborovém systému serveru. Jak jistě víte, v souborovém systému NTFS lze nastavovat uživatelská a skupinová oprávnění k souborům. Autorizace podle souboru je prováděna modulem FileAuthorizationModule. V případě, že chce uživatel přistoupit k souboru, FileAuthorizationModule se podívá na oprávnění tohoto uživatele vztahující se k tomuto souboru, a pokud tato práva nevlastní, vyhodí výjimku, při které je uživateli zobrazena informace ohledně zamezení přístupu. Samozřejmě tento způsob autorizace lze uplatnit pouze s ověřováním systému Windows. K souborům je možné připojit seznamy ACL (Access Control Lists), pomocí nichž lze řídit oprávnění přístupu k těmto souborům. (MRNKA, 2005, s. 51-52) Obrázek 10: Proces autorizace podle souboru Zdroj: Vlastní ilustrace 24
8.3.1.2 Autorizace podle adresy URL Prováděna modulem UrlAuthorizationModule. Mapuje uživatele a role na části oboru názvů URL. Modul implementuje pozitivní i negativní autorizační výroky. To znamená, že modul lze použít k selektivnímu povolení nebo odepření přistupu k libovolným částem oboru názvů URL pro určité skupiny, uživatele nebo role. (technet.microsoft.com/cs-cz/library/cc779441(ws.10).aspx) Autorizace podle adressy URL nastavuje sekce <authorization> v souboru Web.config. První element uvádí o jakou autorizaci se jedná. Allow udává pozitivní a deny negativní. Za tímto elementem následují atributy users=".." a roles="..". Pro správnou funkčnost musí být alespoň jeden z atributů uveden. Do uvozovek za atributem users se uvadí přihlašovací jména uživatelů a do atributu roles víčet rolí. Dalším a posledním atributem, jež lze zde zadat je verbs="..". Atribut určuje, na jaké požadavky se autorizace vztahuje. Do atributu verbs se vkládá hodnota GET, POST nebo HEAD7. (MRNKA, 2005, s. 53) Obrázek 11: Proces autorizace podle URL Zdroj: Vlastní ilustrace 7 Metody požadavku protokolu HTTP 25
Do uvozovek atributů lze uvést dva zástupné znaky. První znak * zastupuje všechny uživatele. Druhý znak? zastupuje pouze anonymní uživatele. Těchto znaků můžete využít například pokud máte v ASP.NET projektu vytvořenu hierarchii pomocí složek a potřebujete zabezpečit určité stránky tak, aby na ně mohli pouze ověření uživatelé. Stačí vytvořít soubor Web.config například pomocí klávesové zkratky CTRL+SHIFT+A v této složce a konfigurační soubor nastavit následovně: <configuration> <system.web> <authorization> <deny users="?" /> </authorization> </system.web> </configuration> Toto nastavení zamezí přistupovat neověřeným uživatelům k čemukoliv ve složce. Pokud adresář obsahuje podadresář, ve kterém je také soubor Web.config, nastavení v něm má vyšší váhu než nastavení práv adresáře nadřazeného. Při práci s autorizací v souboru Web.config využijeme i element <location> s atributem path="..". To konkrétně v případě aplikace práv pouze na jednotlivé soubory. Do elementu se vkládá cesta ke stránce, ke které se nastavení autorizace vztahuje. <location path="stranka.aspx"> <system.web>... </system.web></location> 26
8.3.2 Role Zastupuje určitý počet subjektů a jsou na ni mapována práva a omezení. V příkladu se zaměstnancem jsou také využity role. Není možné, aby společnost, která má nad 1000 zaměstnanců, určovala práva a omezení pro každého zaměstnance zvlášť. To by znamenalo, že v případě každého nově příchozího/odchozího zaměstnance by se mu musela práva a omezení přidělovat/odebírat zvlášť. Samozřejmě by toto řešení zabralo spoustu času a díky použití rolí pouze nově příchozího zaměstnance do určité role obsadíme a automaticky dostane práva a ověření vztahující se k této roli. Ve webových systémech se s ničím jiným než s rolemi nesetkáme. Možná se najdou unikáty aplikující práva na jednotlivé uživatele, ale dovolím si tvrdit, že je to pouze z nezkušenosti daného programátora. ASP.NET má pro práci s rolemi předem vytvořené API (Application Programming Interface)8. Pomocí tohoto API můžete spravovat role velice jednoduše. Lze ho využít jak pro ověřování založené na formulářích, tak i ověřování systému Windows. Pro aktivaci API stačí přidat do souboru Web.config element <rolemanager> s atributem enabled="true". <configuration> <system.web> <rolemanager enabled="true" /> <providers>... </providers> </system.web> </configuration> Poskytovatelé rolí se konfigurují v podelementu <provider> elementu <roleman- ager>. Podrobnější konfigurace je ukázána v kapitole 12.6. 8 Rozhraní obsahující třídy, funkce a jíné. Programátor pak tohoto obsahu může využívat. 27
8.3.2.1 Architektura API rolí v ASP.NET Skládá se ze čtyř hlavních částí: Ověřovací prvky pro bezpečnost Vestavěné bezpečnostní komponenty ASP.NET. Například pomocí komponenty LoginView můžeme vytvářet rozdílné pohledy v závislosti na rolích. API pro role V této části jsou umístěny třídy API rolí jmenného prostoru System.Web.Security. Všechny metody a vlastnosti tříd jsou znázorněny v příloze 1. Nejdůležitější třídy jsou: Třída Roles obsahuje metody a vlastnosti pro správu rolí. Jedna z hojně využívaných metod je IsUserInRole(), která zjistí, zda je uživatel v roli umístěné ve vstupní hodnotě metody. Třída RolePrincipal Dědí z třídy IPrincipal a úkolem této třídy je spojovat role s autentizovaným uživatelem. Třída RoleManagerModule Zajišťuje, že aktuálně přihlášenému uživateli budou přiděleny role pro každý jeho požadavek. Poskytovatelé rolí Implementují přístup k úložišti dat API rolí. Pro poskytovatele je základní třída RoleProvider, z které ostatní poskytovatelé dědí. ASP.NET obsahuje tři zabudované poskytovatele rolí: Poskytovatel SQL Serveru Pracuje s databázemi SQL serveru. Je reprezentován třídou SqlRoleProvider. Samotné uložení dat do databáze probíhá přes connectionstring definovaný u konkrétního poskytovatele v souboru Web.config. Pro práci s API rolí je nutno importovat určité tabulky představující úložnou strukturu rolí do SQL databáze pomocí spouštěcího souboru aspnet_regsql.exe umístěného v adresáři: [disk]:\windows\microsoft.net\framework[verze] Poskytovatel Authorization Store Mapuje role z Microsoft Authorization Manager (AzMan) do rolí v ASP.NET. Je reprezentován třídou AuthorizationStoreRoleProvider. Poskytovatel Windows Token Získává informace o rolích pro ověřeného uživatele Windows založeného na asociacích skupiny Windows. (MACDONALD, FREEMAN, SZPUSZTA, 2010, s. 143, 158) 28
Obrázek 12: Architektura API rolí Zdroj: http://www.sharepointsecurity.com/sharepoint/sharepoint-development/the-definitive-guideto-moss-pluggable-authentication-providers, vlastní úprava 8.3.3 Možnosti autorizace na business vrstvě Jak již jistě víte, většina webových aplikací pracuje na třívrstvé architektuře 9. Výše zmíněné možnosti autorizace pracují na vrstvě prezentační. ASP.NET obsahuje možnosti autorizace i na business vrstvě. Při použití takovéto autorizace je aplikace schopna povolit, či nepovolit uživateli k volání metod, vytváření instancí tříd atp. Jedná se konkrétně o: 9 Skládá se ze tří vrstev : Prezentační vrstva funkce uživatelského rozhraní. Aplikační vrstva logika aplikace. Datová vrstva funkce pro přístup k datům. 29
8.3.3.1 Role-based security Model autorizace je založen na principálovi (viz kapitola 8.1.1), kde ke zjištění, zda je uživatel obsažen v roli, slouží metoda IsInRole(). Pro tento model však existuje ještě jeden způsob pro práci s autorizací. Využívá se třídy PrincipalPermission. Při vytváření instance této třídy se uvádí jako jeden ze vstupních parametrů název role. Po zavolání metody Demant() na vytvořené instanci třídy PrincipalPermission se vyhodnotí, zda aktuálně přihlášený uživatel do role patří. Pokud uživatel do role nepatří, je vyhozena bezpečnostní výjimka. Tento model lze implementovat i pomocí atributu PrincipalPermission, který se přiřazuje určité třídě nebo metodě. Kód pak může vypadat následovně: Použití třídy PrincipalPermission PrincipalPermission kontrola = new PrincipalPermission(null, "Administrators"); Použití atributu PrincipalPermission [PrincipalPermission(SecurityAction.Demand, Role= "Administrators")] (MACDONALD, FREEMAN, SZPUSZTA, 2010, s. 151-152) 8.3.3.2 Code Access Security (CAS) Veškeré Windows aplikace mají přístup k prostředkům jako registry systému Windows, místní disky, protokoly událostí atd. Může se tedy snadno stát, že v případě spuštění škodlivého kódu se tyto prostředky poškodí (např. smazání důležitých souborů operačního systému, editace registrů). CAS tyto prostředky systému chrání před záludnými kódy. Tedy říká kódu, co má povoleno dělat a co ne podle jeho stupně důvěryhodnosti. Pokud CLR věří kódu natolik, aby ho spustil, a kód začne dělat něco, na co nemá právo, je vyhozena bezpečnostní výjimka. CAS je založeno na těchto pojmech: Oprávnění Určuje to, co má kód povoleno dělat. Je vydáváno pro jednotlivé kódové skupiny. 30
Sady oprávnění Abychom skupinám nemuseli přiřazovat jednotlivá oprávnění, existují právě sady oprávnění, které jednotlivá oprávnění sdružují. Mezi ně patří například FullTrust (neomezený přístup k chráněným prostředkům), UIPermission (oprávnění k využívání uživatelského rozhraní). Kódové skupiny Sady oprávnění nejsou přidělovány jednotlivým knihovnám, ale skupinám, do kterých jsou knihovny přiřazeny. Řazení probíhá na základě vlastností. Každá skupina řadí knihovny pouze podle jediné vlastnosti. Nejvyužívanější je vlastnost zóna, která určuje, odkud knihovna pochází. Knihovna však může patřit do několika skupin, v takovém případě je provedeno sjednocení oprávnění z těchto skupin. (NAGEL, EVJEN, GLYNN, SKINNER, WATSON, 2008, s. 602-603) 8.3.4 Zabezpečení konfiguračních souborů Při práci s ASP.NET by vás mohlo zajímat, co se stane v případě, zadáte-li do prohlížeče adresu k souboru Web.config. Budete s ním moci manipulovat? Odpověď zní - samozřejmě ne. Webový server IIS má registrované přípony souborů, mezi ně patří i přípona.config. Server IIS tedy zamezí stahování konfiguračních souborů ASP.NET. Není vhodné ukládat všechny konfigurační informace do jednoho konfiguračního souboru. Například nechcete, aby zaměstnanec firmy mohl spravovat a vidět jiný obsah než sekci <pages>. Toho lze dosáhnout pomocí externalizace sekcí konfiguračních souborů. Jednoduše se vytvoří nový konfigurační soubor např. Pages.config, který bude uchovávat již zmíněnou sekci <pages>. Do souboru Web.config stačí k sekci <pages> přidat atribut configsource="pages.config", ať ví, kde má hledat. Zaměstnanci pak zamezíme přístup k souboru Web.config a přidáme potřebná oprávnění na soubor Pages.config. Pokud chcete bezpečnost konfiguračních souborů ještě zvýšit, ASP.NET podporuje šifrování částí kódu v konfiguračních souborech. Je doporučeno šifrovat sekci <connectionstrings>, protože se jedná o velice citlivé informace nesoucí uživatelské jméno a heslo pro přístup k databázi. Šifrování sekcí konfiguračních souborů lze provést pomocí nástroje aspnet_regiis umístněného v [disk]:\windows\microsoft.net\framework\[verze]. Lze si zde i zvolit, pomocí jakého algoritmu budou data šifrována. 31
8.4 Členství Internetové aplikace pracují většinou s uživateli a jejich správou. Jak již bylo zmíněno, bezpečnostní architektura ASP.NET obsahuje různé způsoby ověřování a autorizace uživatelů. Nebylo však nic řečeno o jejich vytváření, odstraňování, změnách hesla apod. Tato oblast je implementována pomocí API členství (membership API). Tohoto API se využívá spolu s ověřováním založeném na formulářích. Členství zpřístupníme a nakonfigurujeme v souboru Web.config elementem <membership>. V něm se například určuje, v jaké formě bude uloženo heslo uživatele, zda je povolena změna hesla atd. <configuration> <system.web> <Membership> <providers>... </providers> </system.web> </configuration> Tento element obsahuje podelement <providers>, ve kterém jsou poskytovatelé členství. Podrobnější konfiguraci tohoto elementu popisuje kapitola 12.5. 32 definováni
8.4.1 Architektura API členství Je velice podobná architektuře API rolí. Skládá se také ze čtyř hlavních částí: Ovládací prvky pro bezpečenost Microsoft Visual Studio obsahuje vestavěné bezpečnostní komponenty pro formulářovou autentizaci a infrastrukturu členství. Ty lze snadno přizpůsobovat a tím dosáhnout efektivní práce v poměru s časovou náročností na jejich implementaci. Komponenty Login, LoginStatus, LoginView, CreateUserWizard a ostatní jsou umístěny ve skupině Login panelu ToolBox. API pro členství Obsahuje třídy pro API členství umístěné ve jmenném prostoru System.Web.Security. Všechny metody a vlastnosti tříd jsou znázorněny v příloze 2. Nejdůležitější jsou třídy Membership a MembershipUser. Třída Membership Obsahuje statické metody a vlastnosti pro správu uživatelů, jejich ověřování a pro přístup k jejich rolím. Tyto metody pracují se základním poskytovatelem aplikace pro členství. Třída MembershipUser Ztvárňuje jedniného uživatele a obsahuje metody a vlastnosti pro práci s ním. Poskytovatelé členství Implementují přístup k úložišti dat API členství. Pro poskytovatele je základní třída MembershipProvider, z které ostatní poskytovatelé dědí. ASP.NET obsahuje dva zabudované poskytovatele členství: Poskytovatel SQL serveru Poskytovatel pracuje s databázemi SQL serveru. Je reprezentován třídou SqlMembershipProvider. Samotné uložení dat do databáze probíhá přes connectionstring definovaný u konkrétního poskytovatele v souboru Web.config. Členství potřebuje pro práci určité tabulky. Ty je možné do SQL databáze importovat pomocí spouštěcího souboru aspnet_regsql.exe umístěného v adresáři: [disk]:\windows\microsoft.net\framework\[verze] Poskytovatel Active Directory poskytovatel pracuje s Active Directory. Reprezentován třídou ActiveDirectoryMembershipProvider. Úložiště členství Reprezentuje konkrétní úložiště, kam se budou jednotlivé položky API členství ukládat a odkud jsou načítány. (MACDONALD, FREEMAN, SZPUSZTA, 2010, s. 64-65) 33
Obrázek 13: Architektura API členství Zdroj: MacDonald, Freeman, Szpuszta (2010), vlastní úprava 34
9. ZABEZPEČENÍ KOMUNIKACE V aplikaci jsou citlivá data přenášena přes různé body. Přenos těchto dat po různých kanálech musíme zabezpečit, aby nebyly prozrazeny, popřípadě pozměněny. V této kapitole si vysvětlíme pojmy utajení a integrita. Následně si uvedeme, čím tyto pojmy zajistit v prostředí ASP.NET aplikace. 9.1 9.1.1 Zajištění zabezpečené komunikace Utajení a integrita Pro zabezpečenou komunikaci jsou velmi důležité dvě vlastnosti. První z nich je Utajení, které má na starost, aby nikdo neměl přístup k citlivým datům, která zpracovává určitý uživatel. Jako řešení se využívá šifrování. Pomocí tohoto přistupu docílíme utajení a důvěryhodnosti dat. Šifrováním se zabývá celá kapitola 10. Na rozdíl od utajení druhá vlastnost nesoucí název integrita zabraňuje pozměnění dat v průběhu přenosu neautorizovanými subjekty po určitém kanále. Integrita je narušena v případě poškození těchto dat, jelikož již nenesou původní informaci. Pro udržení integrity se využívají Message Authentication Codes (MAC) představující krátkou informaci pro ověření zprávy a také lze využít otisků (viz kapitola 10.3). (MICROSOFT CORPORATION, 2004, s. 33) 9.1.2 Certifikáty Jedná se o veřejný klíč podepsaný certifikační autoritou (CA) 10. Jsou potřeba pro fungování SSL (viz kapitola 10.1.4) na serveru. Certifikát tedy získáme od určité certifikační autority. Po jeho získání je ho možné nainstalovat na webový server, v našem případě na server IIS. Certifikát přidáme na server pomocí Správce IIS po vybrání položky Certifikáty serveru z menu. Na webovém serveru může být nainstalováno více certifikátů sloužících pro více webových stránek. Dříve tu však tato možnost nebyla. Standardem certifikátů je certifikát X.509. 10 Subjekt vydávající certifikáty. Zaručuje správnost informací v nich obsažených. 35
Obrázek 14: Struktura certifikátu X.509 verze 3 Zdroj: http://cs.wikipedia.org/wiki/x.509, vlastní úprava 9.1.2.1 Možnosti certifikátů Self-signed certifikát si vydáváte a podepisujete sami. Certifikát nelze použít pro ověření identity. Používají se v uzavřeném prostření (firma, škola). Vlastní certifikační autorita server provozuje vlastní certifikační autoritu. Důležitým krokem u této možnosti je chránit privátní klíč, kterým CA certifikáty podepisuje. V případě úniku klíče můžete všechny své certifikáty vyhodit. Stejně tak jako u Self-signed je tato metoda spíše pro intranetovou oblast. Těžko neznámého uživatele donutíme k tomu, aby si vaši CA nastavil jako důvěryhodnou kořenovou autoritu. Komerční certifikační autorita certifikáty jsou vydávány komerční certifikační autoritou, která má jasně stanovenou certifikační politiku. Tato možnost je placená a cena se pohybuje okolo 339-1696 Kč. Nejznámější komerční certifikační autority jsou: VeriSign, Comodo, GoDaddy. (technet.microsoft.com/cs-cz/edge/zadost-o-ssl-certifikat-cz) 36
9.1.3 SSL (Secure Sockets Layer) Protokol zajišťující bezpečnou a spolehlivou komunikaci aplikací. Díky této technologii budou citlivá data aplikace splňovat utajení (viz kapitola 10.1.1) a integritu (viz kapitola 10.1.2). Protokol SSL se využívá i při ověřování uživatele, kdy jsou přihlašovací údaje šifrovány právě tímto protokolem. Nevýhodou použití SSL je snížená výkonnost serveru a s tím spojené prodloužení doby odezvy. Tuto nevýhodu můžeme snížit například tím, že SSL aplikujeme pouze na klíčové akce v naší aplikaci, jako je přihlášení, platba kartou atd. Obrázek 15: Pozice protokolu SSL v TCP/IP modelu Zdroj: http://www.svetsiti.cz/view.asp? rubrika=tutorialy&temaid=171&clanekid=187 SSL šifruje HTTP komunikaci, ale nemění způsob zacházení s těmito HTTP dotazy. Důvodem je práce SSL na nižší vrstvě. V případě ASP.NET zajišťuje šifrování a dešifrování IIS. HTTP komunikace, která je šifrována protokolem SSL, začíná prefixem https://. Klient přistupující na stránku se zabezpečenou komunikací nejdříve stáhne veřejný klíč serveru. U tohoto klíče následně zkontroluje, zda pochází opravdu od serveru na který přistupuje. Ověření pravosti klíče řeší právě certifikační autorita. Internetový prohlížeč, nebo úložiště certifikačních autorit ve Windows uchovává určitý seznam takzvaných důvěřyhodných CA. Pokud CA není v tomto seznamu, internetový prohlížeč zobrazí varování uživateli, že certifikát není bezpečný. (http://www.brainweb.cz/ssl-certifikaty) Obrázek 16: Informace o zabezpečené komunikaci Zdroj: Autorem vytvořeno v internetovém prohlížeči Google Chrome 37
10. KRYPTOGRAFIE Kryptografie neboli šifrování je nauka o metodách utajování smyslu zpráv převodem do podoby, která je čitelná jen se speciální znalostí. (cs.wikipedia.org/wiki/kryptografie) Slouží k zajištění utajení (viz kapitola 10.1.1) a integrity (viz kapitola 10.1.2) dat. Lze ji také použít k ověřování, kde zkoumá, zda data pocházejí od příslušného uživatele. V.NET je reprezentována jmenným prostorem System.Security.Cryptography. Naleznete zde šifrovací algoritmy, pomocné třídy, třídy pro práci s certifikáty X.509, třídy pro šifrování a podepisování XML dokumentů. Kryptografie v.net je založena na proudech. K fungování této proudové architektury nám slouží dvě třídy. První z nich je třída ICryptoTransform, která definuje kryptografickou transformaci po blocích. Druhá třída CryptoStream obaluje obyčejný proud a za scénou používá ICryptoTransform. Na třídě CryptoStream můžeme volat metodu jak pro čtění, tak pro zápis. (MACDONALD, FREEMAN, SZPUSZTA, 2010, s. 216).NET framework dokáže pracovat s šifrováním symetrickým, asymetrickým a jednosměrným (heše). V následujících několika podkapitolách si tyto typy šifrování blíže představíme a ukážeme si důležité třídy pro implementaci. V ASP.NET aplikacích se kryptografie používá například k šifrování: Hesla Sekce konfiguračních souborů(viz 8.3.3) ViewState Ověřovací Cookies Citlivé informace aplikace(důležité firemní dokumenty, informace o platební kartě atd.) 38
10.1 Symetrická kryptografie Obrázek 17: Proces šifrování a dešifrování symetrické kryptografie Zdroj: Vlastní ilustrace Algoritmy pracující na principu jednoho klíče. K vykonávání šifrování i dešifrování je použit stejný klíč. Výhodou tohoto přístupu je nízka výpočetní náročnost. Symetrické šifrování je tedy většinou několikanásobně rychlejší než šifrování asymetrické. (cs.wikipedia.org/wiki/symetrick%c3%a1_kryptografie) Tabulka 2: Symetrické algoritmy, které podporuje.net Abstraktní algoritmus Výchozí implementace Platná délka Maximální délka klíče klíče DES DESCryptoServiceProvider 64 64 TripleDES TripleDESCryptoServiceProvider 128,19 192 RC2 RC2CryptServiceProvider 40 až 128 128 Rijndael RijndaelManaged 128,192,256 256 Zdroj: MacDonald, Freeman, Szpuszta (2010) 39
10.1.1 Implementace symetrických šifer v ASP.NET Symetrické šifry v ASP.NET reprezentuje bázová třída 11 SymmetricAlgorithm, která obsahuje všechny abstraktní symetrické algoritmy, jež lze v ASP.NET implementovat. Tabulka 3: Nejdůležitější metody třídy SymmetricAlgorithm Název metody Popis Create() Vytvoří instanci třídy algoritmu, který udáme v závorce. GenerateKey() Vygeneruje náhodný klíč, který slouží jako klíč pro určitý algoritmus. GenerateIV() Vygeneruje inicializační vektor, který přidává náhodná data do zašifrovaného proudu. CreateEncryptor() Zašifruje objekt s patřičným inicializačním vektorem. klíčem a CreateDecryptor() Dešifruje objekt s patřičným inicializačním vektorem. klíčem a Zdroj: msdn.microsoft.com/en-us/library/system.security.cryptography.symmetricalgorithm.aspx 10.1.1.1 Obecný postup šifrování dat 1. Data určená pro šifrování musíme převést do bajtového pole, které bude sloužit jako vstupní parametr. 2. Vytvoříme algoritmus pomocí třídy SymmetricAlgorithm a metody Create(). 3. Vygenerujeme klíč a inicializační vektor voláním metod GenerateKey(), GenerateIV() na vytvořené instanci třídy SymmetricAlgorithm. 4. Zašifrujeme data pomocí třídy CryptoStream a metody CreateEncryptor() na vytvořené instanci třídy SymmetricAlgorithm. 10.1.1.2 Obecný postup dešifrování dat 1. Vytvoříme algoritmus pomocí třídy SymmetricAlgorithm a metody Create(). 2. Načteme si klíč a inicializační vektor z procesu šifrování. Tyto hodnoty uložíme do vlastnosti Key a IV třídy vytvořené instance v kroku 1. 11 Nazýváno také jako rodič, base class, parent 40
3. Dešifrujeme data pomocí třídy CryptoStream a metody CreateDecryptor() na vytvořené instanci třídy SymmetricAlgorithm. 4. Získané bajty převedeme na text. 10.2 Asymetrická kryptografie Obrázek 18: Proces šifrování a dešifrování asymetrické kryptografie Zdroj: Vlastní ilustrace Na rozdíl od symetrických šifrovacích algoritmů, asymetrické používají k šifrování a dešifrování odlišné klíče, ale jsou mnohem pomalejší. První klíč se označuje jako veřejný, ten lze poskytnout každému. Soukromý klíč slouží k dešifrování informací. Tedy v případě, že vlastníte soukromý klíč, můžete informace dešifrovat. V případě obrázku 7 tedy nemusíme Alici posílat klíč, který umí tato data dešifrovat. Asymetrické šifry se používají také pro elektronický podpis 12. (projektysipvz.gytool.cz/projektysipvz/default.aspx?uid=555) 12 Údaje v elektronické podobě, které jsou připojené k datové zprávě nebo jsou s ní logicky spojené a které slouží jako metoda k jednoznačnému ověření identity podepsané osoby ve vztahu k datové zprávě. (http://business.center.cz/business/pravo/zakony/epodpis/cast1.aspx) 41
Tabulka 4: Asymetrické algoritmy, které podporuje Abstraktní algoritmus Výchozí implementace Platná délka klíče Maximální délka klíče RSA RSACryptoServiceProvider 384-16384(8 bitové přírůstky) 1024 DSA DSACryptoServiceProvider 512-1024(64 bitové přírůstky) 1024 Zdroj: MacDonald, Freeman, Szpuszta (2010) 10.2.1 Implementace asymetrických šifer v ASP.NET Implementace je velice podobná symetrickým šifrám. Rozdíl spočívá ve správě klíčů. Asymetrické šifrování je v ASP.NET reprezentováno bázovou třídou AsymmetricAlgorithm. V tabulce 3 jsou uvedeny dva algoritmy využívané pro asymetrické šifrování v ASP.NET, ale pouze RSA se pro tento účel využívá. Algoritmus DSA je určen pro digitální podpisy. Tabulka 5: Nejdůležitější metody třídy RSACryptoServiceProvider Název metody Popis ToXmlString() Vrací řetezec s XML strukturou, obsahující hodnoty pro výpočet privátního nebo veřejného klíče. V případě vstupní hodnoty true se exprotuje jak veřejný tak i soukromý klíč, pakliže je hodnota false exportuje se jen klíč veřejný. FromXmlString() Převede Encrypt() Zašifruje data Decrypt() Dešifruje data formát ToXmlString(). klíče. Opak metody Zdroj: msdn.microsoft.com/enus/library/system.security.cryptography.rsacryptoserviceprovider_methods(v=vs.71).aspx 10.2.1.1 Obecný postup vytváření soukromého a veřejného klíče 1. Vytvoříme instanci třídy RSACryptoServiceProvider. 2. Zavoláme metodu ToXmlString() s parametrem true. Tím získáme privátní klíč, který je nutno uložit na bezpečné místo(viz kapitola 10.4). 3. Zavoláme metodu ToXmlString() s parametrem false. Máme tedy k dispozici veřejný klíč, který můžeme poskytnout osobě, která nám chce posílat šifrovaná data. 42
10.2.1.2 Obecný postup šifrování dat 1. Data určená pro šifrování musíme převést do bajtového pole, které bude sloužit jako vstupní parametr. 2. Vytvoříme instanci třídy RSACryptoServiceProvider. 3. Načteme veřejný klíč volání metody FromXmlString(). 4. Zašifrujeme data voláním metody Encrypt() na vytvořené instanci třídy RSACryptoServiceProvider. 10.2.1.3 Obecný postup dešifrování dat 1. Vytvoříme instanci třídy RSACryptoServiceProvider. 2. Načteme klíče voláním metody FromXmlString(). 3. Dešifrujeme data metodou Decrypt() na instanci třídy RSACryptoServiceProvider. 4. Získané bajty převedeme na text. 10.3 Jednosměrná kryptografie (heš, otisk) Algoritmům se říká jednosměrné, protože prostý text dokáží pouze zašifrovat. Prostý text je šifrován, ale ani ten, kdo ho šifruje, neví pomocí jakého klíče. Heše se využívájí hlavně pro šifrování hesel. Díky tomu naše heslo nemůže přečíst ani správce webu, správce databáze a zbytek vývojového týmu daného serveru. Samozřejmě tím ztížíme práci i potencionálním útočníkům na náš server. (blok.net-vor.cz/bezpecnost-hesel-v-php) V případě, že útočník získá otisky hesel, pomocí různých metod lze získat původní hesla. Bezpečnost hesel se dá zvýšit takzvaným solením. Sůl je určitý řetězec znaků, který se přidává na vstup při hešování hesla. Jako sůl můžeme zvolit libovolný řetězec, který by měl být jiný pro každého uživatele. Metoda solení nám pomůže částečně odvrátit některé útoky, jako je například útok s předgenerovanými tabulkami (rainbow tables), ale není nám nic platná proti útoku hrubou silou. (www.phpguru.cz/clanky/soleni-hesel) 43
Tabulka 6: Hešohovací algoritmy, které podporuje.net Abstraktní algoritmus Výstupní velikost (bit) Výchozí implementace KeyedHashAlgorithm 160 HMACSHA1;MacTripleDES MD5 128 MD5CryptoServiceProvider SHA1 160 SHA1CryptoServiceProvider SHA256 256 SHA256Managed SHA384 384 SHA384Managed SHA512 512 SHA512Managed Zdroj: Microsoft Corporation (2004) 10.3.1 Implementace hešů v ASP.NET Heše jsou v ASP.NET reprezentovány bázovou třídou HashAlgorithm. Neobsahují tolik metod jako třídy pro symetrické a asymetrické šifrování, jelikož zde nejsou potřeba žádné klíče. Tabulka 7: Nejdůležitější metody třídy HashAlgorithm Název metody Popis Create() Vytvoří instanci třídy algoritmu, který uvedeme v závorce. ComputeHash() Zahešuje data Zdroj: msdn.microsoft.com/en-us/library/system.security.cryptography.hashalgorithm.aspx 10.3.1.1 Obecný postup šifrování dat 1. Data určená pro šifrování musíme převést do bajtového pole, které bude sloužit jako vstupní parametr. 2. Vytvoříme algoritmus pomocí třídy HashAlgorithm a metody Create(). 3. Zavoláme metodu ComputeHash() na instanci třídy HashAlgorithm, jejíž vstupní hodnota budou naše data, která chceme šifrovat. 44
10.4 Zabezpečení klíče Vygenerované klíče a inicializační vektory je potřeba někde uchovávat (např. Web.config). To z toho důvodu, abychom měli tyto dvě hodnoty shodné pro šifrování i dešifrování. Zvýšení bezpečnosti můžeme dosáhnout pomocí šifrování těchto klíčů. To by znamenalo, že bychom vygenerovali nový klíč a ten museli také někde uložit. K šifrování klíčů nám slouží Data Protection API(DRAPI), které šifruje data vygenerovaným klíčem stroje, případně klíčem uživatele. Systému tedy sdělujeme, ať něco zašifruje či dešifruje, tímto klíčem. Přístup ke klíči však nemáme. K tomuto účelu je v System.Security.Cryptography.ProtectedData. (MACDONALD, FREEMAN, SZPUSZTA, 2010, s. 218) 45 ASP.NET vytvořena třída
11. HROZBY Aplikaci lze napadnout nespočtem metod. V této kapitole si představíme nejznámější hrozby webové aplikace a zároveň si řekneme, čím se před nimi chránit v prostředí ASP.NET. 11.1 SQL Injection Jedná se o změnu SQL dotazu přes neošetřené formulářové nebo jiné vstupy. V případě, že naše aplikace není chráněna proti tomuto typu útoku, útočník může získat hesla z databáze či editovat a mazat data. Jeden z nejčastějších dotazů je porovnání uživatelského jména a hesla ze vstupních dat s daty databáze. Mějme tedy tento dotaz: "Select Count(*) from Users Where UserName = ' " + TextBoxName.Text + " ' And Password = ' " + TextBoxPass.Text + " ' "; Dotaz vrátí počet nalezených řádků. V případě, že nic nenajde, vrátí 0 a uživatel nebude přihlášen. V případě této implementace SQL dotazu lze velice jednoduše provést SQL Injection. Stačí pouze do textboxů napsat: 'or '1' = '1 Tento dotaz může například vrátit první řádek, který se shoduje. V případě multiuživatelské aplikace vytvořené pro tuto práci byl vytvářen jako první administrátorský účet, tudíž po tomto dotazu byste se úspěšně přihlásil jako uživatel s plnými právy. (mikesdotnetting.com/article/113/preventing-sql-injection-in-asp.net) Obrázek 19: Ukázka útoku pomocí SQL injection Zdroj: Vlastní ilustrace 46
Proti SQL Injection se lze samozřejmě bránit a to vcelku jednoduše. Mezi způsoby obrany proti SQL Injection patří: Validace dat - je jedním ze způsobů obrany, při kterém se ověřuje vstup z formulářových prvků podle určitého podkladu. V ASP.NET k tomuto účelu slouží různé validační prvky jako RegularExpressionValidator, RangeValidator, CustomValidator. Parametrizované dotazy - jsou další způsob, jak SQL Injection pokořit. Jedná se o využití parametrizovaných vstupů v SQL dotazech. Tyto vstupy jsou před vykonáním dotazu automaticky ošetřeny o nebezpečné znaky. 11.2 Cross-Site Scripting (XSS) Jedná se o útoky prováděné klientským skriptovacím jazykem (JavaScript, Jscript a jiné), případně HTML, XHTML.13. Útočníkovi je díky bezpečnostní mezeře povoleno webové aplikaci podstrčit vlastní kód. Tento kód může být až tak nebezpečný, že danou stránku znefunkční nebo díky němu získá citlivá uživatelská data. Mezi nejznámější typy útoků patří: Perzistentní útok - provádí se, pokud je obsah stránky brán z databáze. Například návštěvní kniha, diskusní fóra. V případě, že vložíme do návštěvní knihy příspěvěk obsahující skript, je následně uložen do databáze a zobrazen všem uživatelům, kteří do návštěvní knihy vstoupí. Okamžitý útok (non-persistent) - provádí se úpravou části URL adresy. Na rozdíl od perzistentního útoku se skript provede ihned po odeslání požadavku na server. Lokální útok - je proveden tak, že škodlivý kód je spuštěn z uživatelského počítače. Útočí se tedy na lokální webové aplikace. Například Internet Explorer považuje klientské skripty spouštěné v lokální zóně za bezpečné. Je jim dovoleno přistupovat k souborům na disku a zneužití těchto skriptů nese veliké riziko. (cs.wikipedia.org/wiki/cross-site_scripting) ASP.NET poskytuje vestavěnou obranu proti tomuto typu útoků. Je však stále potřeba validovat vstupní data jako hlavičky, formulářová pole, cookies a nepřiřazovat data formulářových polí přímo. Vestavěná obrana je reprezentována parametrem ValidateRequest. Je zde i další předprogramovaná obrana EnableEventValidation. Ta snižuje riziko neoprávněných postbacků a callbacků. Oba parametry jsou v základní konfiguraci nastaveny na hodnotu true. 13 Novější verze jazyka HTML. 47
Pro ASP.NET je také volně stažitelná knihovna Anti-XSS na MSDN portále obsahující potřebné nástroje pro účinnou obranu. Obrázek 20: Ilustrace perzistentního XSS útoku Zdroj: Vlastní ilustrace 11.3 Session hijacking Jedná se o útok, jehož cílem je získat uživatelskou session určité webové aplikace. Díky tomu se útočník bude moci přihlásit do webové aplikace pod uživatele, jehož session získal. Útočník může session uživatele získat několika způsoby: Útok hrubou silou při němž se útočník snaží session ID uhodnout. Například pomocí programu, který náhodně generuje session ID. Útok, který se snaží session ID spočítat, nikoliv náhodně vygenerovat. Session fixation znamená útok, při kterém útočník vygeneruje nové session ID a snaží se ho oběti podstrčit. Steal útok používá různé techniky jako Cross-Site Scripting, Man-In-The-Middle k získání session ID. (cs.wikipedia.org/wiki/session#session_hijacking) ASP.NET generuje session ID o velikosti 120-bit, takže útok hrubou silou či odhad dá útočníkovi pěkně zabrat. Dalším důležitým bezpečnostním prvkem je nastavit platnost session po určitou dobu. Webová aplikace by také měla používat protokol SSL (viz kapitola 10.1.4), který se postará o to, aby útočník s odcizenou session ID nemohl nic podniknout. Před XSS útokem na 48
cookies se bráníme pomocí příkazu HttpOnly, ten zabrání přístup skriptů k těmto cookies. HttpOnly můžeme nastavit například v souboru Web.config. <httpcookies httponlycookies="true"/> Jednotlivé Cookies pak obsahují část, ve které je vyznačeno, že se jedná o HttpOnly. Na to reaguje internetový prohlížeč (který ovšem příkaz HttpOnly podporuje) a omezí veškerý přístup klientských skriptů k hodnotám Cookies. Mezi prohlížeče podporující tuto funkčnost patří například: Internet Explorer 8, Mozzila Firefox 5.0.1, Opera 11, Safari 5, Google Chrome 13 a jiné. Obrázek 21: Ilustrace útoku session fixation Zdroj: ptgmedia.pearsoncmg.com/images/chap4_0321369440/elementlink s/04fig17.jpg, vlastní úprava 11.4 Man-In-The-Middle Útočník se snaží odposlouchávat komunikaci mezi účastníky tak, že se stane prostředníkem. Tedy veškerá komunikace půjde přes něj a oběť si toho ani nevšimne. Mějme příklad s Alicí a Bobem, kde si mezi sebou vymění veřejné klíče. Útočník zachytí klíč Alice, zamění ho za svůj a pošle Bobovi. Stejně postupuje i u Boba. Výsledkem je, že Alice a Bob šifrují zprávu veřejným klíčem útočníka a vůbec o tom nevědí. Kdykoliv tedy Alice nebo Bob něco pošlou, útočník to zachytí a dešifruje svým klíčem, znovu zašifruje a následně odešle druhé straně. (www.krypta.cz/articles.php?id=94) 49
Před tímto typem útoku se bráníme pomocí důvěryhodné třetí strany, v případě webových aplikací certifikační autoritou (viz 10.1.3). Ta klíč Alice a Boba podepíše a v situaci záměny klíčů za útočníkův druhá strana zjistí, že to není klíč, který má obdržet. Obrázek 22: Princip útoku Man-In-The-Middle Zdroj: Vlastní ilustrace 11.5 Denial of Service (DoS) Útok spočívá ve snaze znepřístupnit určité internetové stránky nebo služby. Nejedná se o průnik do systému s cílem získat nebo poškodit data. Hlavním principem DoS útoků je přehltit server požadavky, aby neměl čas na vyřízení ostatních. Při přehlcení serveru požadavky docílíme toho, že doba odezvy pro normální uživatele je zcela nesnesitelná, nebo celý server spadne. DoS útoky obsahují mnoho různých druhů, cíl útoku je ale stejný. Distribuovaný DoS (DDoS) využívá více počítačů k útoku. Počet počítačů může sahat až k tisícům. Tohoto čísla útočník docílí pomocí infikování počítačů škodlivým kódem, který pak provádí tento útok. Infikovaný počítač je označován jako Zombie. Ping of Death je útok pomocí pozměněných paketů v protokolu IP. Tato změna se týkala velikosti paketu a docházelo tak většinou k přetečení zásobníku (buffer overflow) a pádu webové aplikace. Tento typ útoku je již velmi starý a známý. Většina systémů je v dnešní době proti tomuto útoku imunní. 50
SYN Flood je jeden z nejrozšířenějších útoků. Na cílový server jsou odesílány falešné požadavky SYN, které slouží pro zahájení komunikace klienta se serverem. Při velkém množství těchto falešných požadavků dojde k zaplnění bufferů pro polootevřená spojení a server nebude schopen obsluhovat další příchozí SYN požadavky. SYN Flood se ve většině případů kombinuje s falšováním IP adres (IP spoofing) 14. V prostředí IIS a ASP.NET se proti těmto útokům můžeme účinně bránit pomocí kvalitní konfigurace síťových uzlů. Z hlediska webového serveru existuje v IIS takzvané škrcení aplikací. To má za úkol omezit počet žádostí, kterým bude vyhověno. Dále můžeme obranu implementovat přímo v kódu ASP.NET. (http://www.adminxp.cz/security/index.php?aid=193) Obrázek 23: Princip DDoS útoku Zdroj: Vlastní ilustrace 14 Útočník maskuje vlastní IP adresu, nebo se vydává za někoho jiného. 51
11.6 Automatizované zakládání účtů Princip tohoto útoku spočívá v zakládání mnoha účtů v cílené webové aplikaci. Tohoto útoku se využívá například na mailové schránky, které následně slouží jako zdroj spamu 15. Tento útok je nepříjemný z hlediska dat v databázi. V případě, že útočník začne generovat jeden registrační formulář za druhým a nebude mu v tom nic bránit, tak to pro naši aplikaci zrovna ideální zabezpečení není. Může se lehce stát, že databáze bude během chvilky plná a uživatelé se nebudou moci registrovat. Ochrana před tímto typem útoku je takzvaná CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart). Jedná se o Turingův test 16, kde má dotazující za úkol opsat kód z vygenerovaného obrázku nebo mluveného textu. Na internetu je CAPTCHA poskytována mnoha společnostmi zdarma. Mezi hojně využívanou patří Recaptcha, která obsahuje i mluvený text pro zrakově postižené. Obrázek 24: Recaptcha umístěná ve formuláři Zdroj: Autorem vytvořeno v Google Chrome CAPTCHA však není jistá obrana. Vynalézaví hackeři vytvářejí nové a nové možnosti, jak tento typ obrany obejít. To se podařilo například u nejznámějšího českého webu Seznam.cz, Yahoo! či emailového serveru Hotmail. V dnešní době existuje i software pro rozpoznávání a analýzu zvuku, takže prolomit audio ochranu lze také. 15 Nevyžádané sdělení zaplavující emailovou schránku, diskusní fóra atd. 16 Standardní podoba testu spočívá v rospoznání člověka od stroje. 52
11.7 Kritická bezpečnostní chyba I ASP.NET se nevyhne chybám v implementaci. Mezi poslední kritickou chybu v předešlém roce patří možnost dekódovat zašifrovaná data na vzdáleném serveru a získání dat z webových aplikací ASP.NET, jako je například soubor Web.config. Při využití této chyby lze získat přístup k administrátorským účtům aplikací. Na tuto zranitelnost byl vydán již hotfix. Samotný útok se prováděl tak, že hacker zahltil aplikaci šifrovaným textem a následně si zaznamenávál obsah chybových hlášení. Opakováním tohoto procesu a analýzou chybových hlášek byl pak schopen získat šifrovací klíč a vytvořit si tak cestu k zakódovanému obsahu. (http://computerworld.cz/bezpecnost/microsoft-varuje-pred-kritickou-chybou-v-asp-net-kteraohrozuje-web-7741 ) 53
12. MULTIUŽIVATELSKÁ APLIKACE Kapitola popisuje důležité kroky při tvorbě ASP.NET aplikace, ve které implementuji většinu probraných bezpečnostních prvků v této bakalářské práci. V práci se snažím využít všech výhod programování ASP.NET aplikací ve Visual Studiu. 12.1 Implementační technologie Pro vývoj aplikace BOSS travel byl použit:.net Framework verze 4.0 Programovací jazyk C# 2010 Microsoft Visual Studio 2010 Ultimate verze 10.0 Microsoft SQL Server 2008 R2 Internet Information Services (IIS) verze 7.5 Microsoft SQL Server Management Studio verze 10.50 12.2 Popis aplikace Slouží pro demonstraci bezpečnostních prvků v rámci ASP.NET. Je zde pracováno s ověřováním založeným na formulářich a autorizace je prováděna podle adresy URL. Aplikace dále pracuje na základě API členství a rolí. Logika aplikace je řešena pomocí webových služeb WCF. Pro bezpečnou komunikaci je použit SSL protokol s self-signed certifikátem. Cílem aplikace je vyhnout se nejznámějším útokům (viz kapitola 10) v prostředí webových aplikací a uchovávat tak bezpečně citlivá data uživatelů. Obrázek 25: Funkčnosti aplikace Zdroj: Vlastní ilustrace 54
12.2.1 Big picture řešení Obrázek 26: Big picture řešení Zdroj: Vlastní ilustrace 55