BAKALÁŘSKÁ PRÁCE. Bezpečnost ASP.NET aplikací. ASP.NET Web Application Security. Marek Pavelek

BAKALÁŘSKÁ PRÁCE Bezpečnost ASP.NET aplikací ASP.NET Web Application Security 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

Bakalářská práce Bezpečnost ASP.NET aplikací ASP.NET Web Application Security

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 Bezpečnost ASP.NET aplikací 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:

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

●

Zosobnění uživatele pro všechny požadavky aplikace

▪ 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


▪ 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


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


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

v souboru Web.config, jelikož je tento atribut při vytvoření nového projektu implicitně nastavena na Forms. Značka v sekci představuje důležité volby ověřování. Tyto volby jsou shrnuty v následující tabulce. Tabulka 1: Atributy pro element 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


▪ 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

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


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ě:

<system.web> <deny users="?" /> 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 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.

<system.web> ….....

▪ 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 s atributem enabled="true".

<system.web> <providers> …... Poskytovatelé rolí se konfigurují v podelementu <provider>

elementu
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

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

<system.web> <Membership> <providers> …... 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í


▪ 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


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


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


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


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)


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


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


▪ 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


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


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


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


▪ 54 ▪


12.2.1

Big picture řešení

Obrázek 26: Big picture řešení


▪ 55 ▪


12.2.2

Use-case diagram

Obrázek 27: Use-case diagram aplikace BOSS travel


▪ 56 ▪


12.2.3

Přehled aktérů

Název

Popis

Cíle

Host

Uživatel bez přihlášení do aplikace.

Registrovat se.

Uživatel standardUser

Jedná se o uživatele přihlášeného do Nakupovat zájezdy. systému s právy standardUser.

Uživatel premiumUser

Uživatel přihlášený do aplikace s / právy premiumUser.

Administrator

Uživatel přihlášený do aplikace s Spravovat aplikaci. právy na správu aplikace.

12.2.4

Přehled use-case

ID

Název

Popis

UC01

Registrace

Vyplnění registračního odeslání aplikaci.

UC02

Přihlášení

Vyplnění přihlašovacího formuláře a jeho následného odeslání aplikaci.

UC03

Prohlížení úvodní stránky

Zobrazení úvodní stránky default.aspx

UC04

Odhlášení ze systému

Uživatel bude odhlášen z aplikace.

UC05

Změna hesla

Možnost měnit uživatelské heslo.

UC06

Zobrazit informace o platební Uživatel má možnost prohlédnout si informace o jeho kartě platební kartě, kterou do aplikace zavedl.

UC07

Vklad platebních dat

Uživatel bude moci vytvořit objekt platební karty, pomocí které bude uhrazovat objednávky.

UC08

Odhlášení ze systému

Uživatel bude odhlášen z aplikace.

UC09

Hodnotit zájezdy

Možnost hodnotit již proběhlé zájezdy podle spokojenosti klienta.

UC10

Zobrazit počet registrovaných Zobrazení celkového počtu registrovaných uživatelů v uživatelů aplikaci.

▪ 57 ▪

formuláře

a

jeho

následné


12.3

Základní struktura Jako první krok je potřeba vytvořit strukturu stránek. BOSS travel jsem rozdělil do dvou

základních adresářů „Anonym“ a „Prihlasen“. Složka „Anonym“ obsahuje stránku pro přihlášení, registraci uživatele a soubor Web.config. Do konfiguračního souboru jsem přidal autorizační nastavení:

Adresář „Příhlášen“ obsahuje stránky, ke kterým může uživatel přistoupit jen v případě jeho úspěšného ověření (například stránka „spravaUctu.aspx). Adresář obsahuje také konfigurační soubor, v jehož nastavení zamezíme přístupu neověřeným uživatelům:

<deny users="?"/> Projekt je také nutno situovat podle toho, co vykonává. V případě BOSS travel jsem rozdělil Solution do dvou projektů. První slouží pro vizualizaci dat a webové komponenty. Druhý projekt pak k vykonávání business logiku pomocí webových služeb. Metody ve službách nevykonávají potřebný kód. Volají pouze statické třídy ve složce Workers, které potřebný kód vykonají. Nastane-li v aplikaci chyba, z hlediska bezpečnosti ji není vhodné zobrazovat uživateli, tak jak ji zobrazuje ASP.NET. Při výskytu chyby aplikace uživatele přesměruje na stránku

Error.aspx, jejíž obsahem je prostý text.

<customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="~/Error.aspx" />

Kód 1: Nastavení chybové stránky v souboru Web.config

12.4

Nastavení formulářové autentizace Autentizace využívá klouzavé doby vypršení autentizačního lístku, který je podepsán a

šifrován algoritmem Triple-DES. K přenášení lístku se používají soubory cookies. Samotné vypršení lístku je nastaveno na 10 minut a je přenášen pouze po zabezpečeném kanále.

Kód 2: Nastavení formulářové autentizace v souboru Web.config

▪ 58 ▪


12.5

Přistup k databázi

Kód 3: Konfigurace připojovacího řetězce v souboru Web.config

Šifroval jsem všechny sekce konfiguračních souborů, které obsahují informace o připojení do databáze (connectionStrings). Pro šifrování byl použit klíč DRAPI. Pomocí příkazové řádky stačí soubor spustit a nastavit tyto parametry:

aspnet_regiis.exe -pef "connectionStrings" "cestaKprojektu" -prov "DataProtectionConfigurationProvider"

12.6

Zabezpečení WCF Přenášená data pomocí webových služeb je nutno zabezpečit. K tomuto účelu jsem zvolil

možnost zabezpečení transport security mode17 .

<security mode="Transport">

Kód 4: Konfigurace zabezpečení WCF v souboru Web.config

12.7

Dostupnost pouze pro členy Pro práci s členstvím má ASP.NET již předpřipravené tabulky. Ty je možné importovat do

exisující databáze. Nástroj pro import tabulek se jmenuje aspnet_regsql.exe a je umístěn v adresáři [disk]:\Windows\Microsoft.NET\Framework\[verze] . 17 Bezpečnost je řešena na úrovni přenosového protokolu tzn. HTTPS

▪ 59 ▪

Soubor lze spustit


pomocí příkazové řádky a nebo pomocí grafického průvodce. Při použití průvodce jsou importovány i tabulky obsluhující role a profily. Jelikož profily aplikace nepoužívá, tabulky pro ně jsou smazány. Jako druhý krok je nutné nastavit členství v kořenovém Web.config souboru. Je zde povoleno měnit uživatelská hesla pomocí komponenty ChangePassword a hesla všeobecně musí být minimálně 6 znaků dlouhá. Na druhou stranu není povoleno na jeden e-mail registrovat více účtů. Nakonfigurována je i obrana proti opakovanému zadávání neplatných hesel. Ta je nastavena na 8 pokusů a dále je účet zablokován na 20 minut.

<membership defaultProvider="BOSSSqlMembershipProvider" userIsOnlineTimeWindow="10"> <providers>

Kód 5: Konfigurace členství v souboru Web.config

12.8

Konfigurace rolí Role se konfigurují ve stejné sekci jako členství, tedy v system.web v souboru

Web.config. Ke konfiguraci lze použít i nástroj WAT. Zprostředkovatel rolí je nakonfigurován tak, aby používal mnou znovelné úložiště. Role se ukládají do cookie a doba jejich platnosti je nastavena na 10 minut. Platnost cookies se prodlužuje s každým požadavkem. Cookies jsou použity v rámci relace a jsou šifrovány a podepsány. Přenášení Cookies je uskutečněno pouze přez https protokol.

<providers>

Kód 6: Nastavení rolí v souboru Web.config

▪ 60 ▪


12.9

Klíčové stránky aplikace

12.9.1

Přihlašovací stránka (~/Anonym/Login.aspx)

Tato stránka je určena pro ověření uživatele a obsahuje pole pro zadání uživatelského jména a hesla. Při tvorbě přihlašovací stránky je vhodné využít komponentu Login sloužící pro automatické ověřování uživatelů. V případě použití členství, což je případ BOSS travel aplikace, nemusíte psát kód pro autentizaci. Ten je již napsán a pro samotné ověření uživatele je volána metoda Membership.ValidateUser(). V případě použití vlastní autentizační logiky je potřebné kód upravit. Komponenta obsahuje pouze validaci v podobě nutnosti vyplnit vstupní pole a je tedy vhodné ji doplnit ještě o validaci pomocí regulárních výrazů. Aplikace používá regulár:

^[a-zA-Z0-9_-]{6,15}$ Obrázek 28: Komponenta Login v BOSS travel aplikaci

Zdroj: Autorem vytvořeno v MS Visual Studio

12.9.2

Registrační stránka (~/Anonym/Register.aspx)

Slouží k vytváření uživatelských účtů. Pro proces registrace ve Visual Studiu byla použita komponenta CreateUserWizard, která je použitelná při práci s členstvím v ASP.NET. Na první pohled se nejeví nijak zvláštně, ale když známe její funkčnost, víme, že je to mocný nástroj. CreateUserWizard po validaci dat zapisuje parametrizovaně přihlašovací údaje do tabulky

aspnet_Membership a do tabulky aspnet_Users. V tabulce aspnet_Users nalezneme uživateslké jméno a k němu vygenerované UserId. Ostatní informace se uloží do tabulky

aspnet_Membership. Heslo je osoleno a hešováno algoritmem SHA-1. Náhodně generovaná sůl je uložena také v tabulce aspnet_Membership. Hešování hesla se konfiguruje v souboru

▪ 61 ▪


Web.config u elementu <membership> a atributu hashAlgorithmType ="..". SHA1 je výchozí hodnota, tudíž nemusíme tento atribut nastavovat. Komponenta při registraci požaduje i osobní údaje. Ty jsou ukládány parametrizovaně do speciální tabulky UserInfo přes webovou službu UserService.

public class UserService : IUserService { public void AddUserInfo(object UserInfo, string name, string surname, string phoneN) { UserWorker.AddUserInfo(UserInfo, name, surname, phoneN); } }

Kód 7: Webová služba UserService volající statickou třídu UserWorker

Na registrační stránce hrozí automatizovaného zakládání účtů (viz kapitola 11.6) a je ji třeba ochránít pomocí CAPTCHA. Pro tuto práci jsem zvolil již hotové řešení zvané reCAPTCHA. První

krok

pro

použití

této

komponenty

spočívá

v

registraci

na

stránkách

http://www.google.com/recaptcha. Po registraci jsou vygenerovány klíče, které je potřeba uložit do elementu umístěného v souboru Web.config aplikace. Posledním krokem je přidat referenci na knihovnu Recaptcha.dll a umístit komponentu do stránky:

12.9.3

Práce s kartou (~/Prihlasen/AktivacePlatebniKarty.aspx)

Tato stránka přijme informace o platební kartě pomocí formuláře. Data od klienta jsou dále webovou službou CreditCardWebService zpracována. Při kliknutí na tlačítko pro odeslání formuláře je vytvořena instance pro tuto webovou službu a následně je na ní volána metoda AddNewCreditCard(). Po úspěšném uložení dat vrátí metoda hodnotu true, v opačném případě false.

CreditCardReference.CreditCardServiceClient CreditCardServiceProvider = new CreditCardReference.CreditCardServiceClient(); object userId = Membership.GetUser().ProviderUserKey; bool CCcreated = CreditCardProvider.AddNewCreditCard(userId, DropDownList_karta.SelectedValue, TBCVV.Text, TBCreditCardNumber.Text, TBExpDay.Text);

Kód 8: Volání metody AddNewCreditCard webové služby CreditCardService

▪ 62 ▪


12.9.3.1

Šifrování platebních dat

Nemusím zde ani uvádět, že platební data patří mezi velmi citlivá. Je tedy na místě je šifrovat. Aplikace tak koná algoritmem Triple-DES. Konkrétně se jedná o statickou třidu s názvem

SymSifrovaciTrida poskytující metody pro celý průběh šifrování. Prvním krokem je ověřit, zda existuje již vygenerovaný klíč v souboru Klic.config. Tuto funkčnost vykonává metoda ExistenceKlice(). Implementace metody je velice jednoduchá a jjde tedy pouze o jednoduchou podmínku. Pokud soubor Klic.config neexistuje, je volána metoda VygenerujKlic(), která vytvoří/přepíše konfigurační soubor a do něj klíč vygeneruje. Neukládá však do souboru samotný šifrovací klíč. Ten je pro zvýšení bezpečnosti šifrován klíčem stroje. TripleDES Algoritmus = TripleDESCryptoServiceProvider.Create(); Algoritmus.GenerateKey(); byte[] Klic = ProtectedData.Protect(Algoritmus.Key,null, DataProtectionScope.LocalMachine); using (FileStream klicConfig = new FileStream(CestaKlic, FileMode.Create)) { klicConfig.Write(Klic, 0, Klic.Length); }

Kód 9: Generování Triple-DES klíče metodou VygenerujKlic() Z souboru Klic.config se samozřejmě klíč i načíta. Funkci načtení klíče uskutečňuje metoda NactiKlic(). Po získání klíče ze souboru je ho nutno dešifrovat klíčem stroje.

byte[] Klic; using (FileStream KlicConfig = new FileStream(CestaKlic, FileMode.Open)) { Klic = new byte[KlicConfig.Length]; int BajtuKeCteni = (int)KlicConfig.Length; KlicConfig.Read(Klic, 0, BajtuKeCteni); } byte [] KlicBezDRAPI = ProtectedData.Unprotect(Klic, null, DataProtectionScope.LocalMachine); DES.Key = KlicBezDRAPI;

Kód 10: Načtení klíče ze souboru metodou NactiKlic()

▪ 63 ▪


Druhým krokem je samotné šifrování. Vykonává ho metoda Zasifruj() se vstupní hodnotou čistého textu. Metoda vrací pole bajtů nesoucí zašifrovná data. Nutno podotknout, že právě v Zasifruj() je volána metoda NactiKlic().

byte[] poleData = System.Text.Encoding.UTF8.GetBytes(data); TripleDES DESalgo = new TripleDESCryptoServiceProvider(); DESalgo.GenerateIV(); NactiKlic(DESalgo); MemoryStream PametProud = new MemoryStream(); PametProud.Write(DESalgo.IV, 0, DESalgo.IV.Length); CryptoStream CryptoProud = new CryptoStream(PametProud, DESalgo.CreateEncryptor(), CryptoStreamMode.Write); CyptoProud.Write(poleData, 0, poleData.Length); CryptoProud.FlushFinalBlock(); return PametProud.ToArray();

Kód 11: Metoda Zašifruj() implementující šifrování dat

12.9.4

Informace o kartě (~/Prihlasen/PlatebniKartaInfo.aspx)

Stránka má za úkol zobrazit uložené informace o kartě. Tyto informace jsou však v databázi šifrovány. Při přístupu na stránku se zjišťuje, zda je uživatel ověřen. Tento postup slouží jako částečná prevence proti session hijacking (viz kapizola 10.3). Druhým krokem je volání metody CheckCard() webové služby CreditCardWebService. Metoda přijme uživatelské id a podívá se do databáze, zda vůbec uživatel kartu vlastní. Podle výsledku vrátí bool hodnotu18.

if (HttpContext.Current.Request.IsAuthenticated) {

CreditCardReference.CreditCardServiceClient CreditCardServiceProvider = new CreditCardReference.CreditCardServiceClient(); object userId = Membership.GetUser().ProviderUserKey; bool CardOK = CreditCardServiceProvider.CheckCard(userId); ... ..... string[] ListKarta = CreditCardServiceProvider.GetCreditCard(userId);

Kód 12: Kód v logické části stránky obstarávající informace o kartě

18 Datový typ obsahuje hodnotu true a nebo false.

▪ 64 ▪


Posledním krokem je načtení dat kreditní karty do pole stringu a jeho zobrazení uživateli. Tuto funkčnost plní metoda GetCreditCard().

List<string> ListInformace = new List<string>(); var zakaznik = context.UserInfo.First(c => c.UserId == (Guid)UserId); var karta = context.UserCard.First(c => c.ID == zakaznik.CreditCard); string CCislo = SymSifrovaciTrida.Desifruj((byte[])karta.Number); string CCV = SymSifrovaciTrida.Desifruj((byte[])karta.SecureCode); string ExpDate = SymSifrovaciTrida.Desifruj((byte[])karta.ExpiresEnd); ListInformace.Add(CCislo); ListInformace.Add(CCV); ListInformace.Add(ExpDate); return ListInformace;

Kód 13: Metoda GetCreditCard() třídy CreditCardWorker

Načtené informace z databáze jsou šifrované a je nutno je dešifrovat. K dešifrování slouží metoda Desifruj() statické třídy SymSifrovaciTrida. Metoda nejprve vytvoří instanci algoritmu Triple-DES a načte klíč ze souboru Klic.config. Následně získá inicializační vektor a data dešifruje.

TripleDES DESalgo = new TripleDESCryptoServiceProvider(); NactiKlic(DESalgo); MemoryStream PametProud = new MemoryStream(); byte[] inicializacniV = new byte[DESalgo.IV.Length]; Array.Copy(data, inicializacniV, inicializacniV.Length); DESalgo.IV = inicializacniV; int prom = 0; prom += DESalgo.IV.Length; CryptoStream CryptoProud = new CryptoStream(PametProud, DESalgo.CreateDecryptor(), CryptoStreamMode.Write); CryptoProud.Write(data, prom, data.Length - prom); CryptoProud.FlushFinalBlock(); string DekodovanyText = System.Text.Encoding.UTF8.GetString(PametProud.ToArray()); return DekodovanyText;

Kód 14: Dešifrování informací metodou Desifruj() třídy CreditCardWorker

12.9.5

Hodnocení zájezdů (~/Prihlasen/rozcestnik.aspx)

Tato stránka vykresluje jednotlivé uskutečněné zájezdy uložené v databázi. Konkrétně se jedná o tabulku Zajezdy obsahující kromě základních informací jako název, popis, typ ubytování i hodnocení.

▪ 65 ▪


Hodnocení

a

načítání

zájezdů

je

implementováno

pomocí

webové

služby

ZajezdyService. Načtení zájezdů je uskutečněno metodou GetZajezdy(), která vrací pole zájezdů. Daleko zajímavější je ovšem možnost tyto zájezdy hodnotit. K tomu slouží metoda

Ohodnot() vracející bool hodnotu. Implementace samotného hodnocení je umístěna ve statické třídě ZajezdyWorker. Zde probíhá kromě přičtení či odečtení hodnoty ještě kontrola, zda uživatel náhodou již pro tento zájezd nehlasoval. Toho je docíleno pomocí tabulek Banlist a List. Každý zájezd obsahuje ID pro něj vytvořeného banlistu. Do tabulky List se pak ukládá ID banlistu a ID uživatele. Kód je spuštěn jen v případě, že aktuálně přihlášený uživatel je v roli premiumUser.

if (Roles.IsUserInRole(usrName, "premiumUser")) { Zajezd zaj = context.Zajezd.First(c => c.ID == IDzajezd); int IDbanlist = zaj.BanlistID; var vsechny = from c in context.List select c; List vsechnyList = vsechny.ToList(); bool nehlasoval = true; foreach (List gda in vsechnyList) { if ((gda.UzivatelId == (Guid)userId) && (gda.BanlistId == IDbanlist)) { nehlasoval = false; } }

if (nehlasoval) { if (hodnoceni == "p") { zaj.Hodnoceni += 1; } else { zaj.Hodnoceni -= 1; } List list = new List { UzivatelId = (Guid)userId, BanlistId = zaj.BanlistID }; context.List.AddObject(list); context.SaveChanges(); } }

return true; } return false;

Kód 15: Implementace metody Ohodnot() ve statické třídě ZajezdyWorker

▪ 66 ▪


13.

ZÁVĚR ASP.NET patří a po dlouhou dobu bude patřit mezi nejpoužívanější technologie pro vývoj

dynamických stránek, webových aplikací a webových služeb běžících na straně serveru. Technologie dosahuje i pokroků, co se týče vývoje. V roce 2009 uvedl Microsoft nový framework s názvem ASP.NET MVC Framework 1.0, který umožňuje vyvíjet webové aplikace podle architektury Model-View-Controller. Práce měla za cíl analyzovat bezpečnostní prvky obsažené v technologii ASP.NET, identifikovat nejčastější zranitelná místa webových aplikací a s tím spojené řešení, jak toto zranitelné místo v ASP.NET odstranit. Koncept bezpečnostních prvků je reprezentován vytvořenou multiuživatelskou aplikací BOSS Travel. První část práce popisuje bezpečnostní architekturu ASP.NET, jak identifikovat uživatele přistupujícího k naší aplikaci a pomocí čeho zajistit, aby měl přístup jen tam, kam chceme. Zejména je rozebrána identifikace uživatele na základě formulářů. Další důležitou částí je správa uživatelů a rolí pomocí API technologie ASP.NET. Jako poslední je zde vysvětlena ochrana konfiguračních souborů webové aplikace. Ve druhé části je popsán způsob, jak zajistit, aby útočník nemohl získat přenášená data nebo je měnit v průběhu přenosu. Dále je zde uvedeno, v jaké formě uchovávat citlivá data v databázi a v případě jejich získání zabránit čtení těchto dat. Třetí část je věnována nejčastěji zranitelným místům webových aplikací a s tím spojenými hrozbami. Je zde také uvedeno, jak tato zranitelná místa ošetřit v prostředí ASP.NET. Poslední část je věnována multiuživatelské aplikaci spravující a uchovávající citlivá data za využití technologie ASP.NET. Aplikace slouží jako ukázková implementace probraných bezpečnostních prvků v této práci. Tato část nejdříve aplikaci popisuje a dále jsou ukázány a popsány kroky při implementaci jednotlivých bezpečnostních prvků. Práce je umístěna na přiloženém CD.

▪ 67 ▪


14.

CONCLUSION ASP.NET is and will be for a long time one of the most popular technologies used in the

development of dynamic pages, web applications and web services running on the server side. Recently, this technology has also seen some progress in its development. In 2009, Microsoft unveiled ASP.NET MVC Framework 1.0, a new framework which allows for the development of web applications based on the Model-View-Controller architecture. The objective of the thesis was to analyze the security elements contained in the ASP.NET technology, to identify the most vulnerable spots in web applications and the corresponding methods of removing these vulnerable spots in ASP.NET. The concept of security elements is represented by the proprietary multi-user application BOSS Travel. The first part of the thesis describes the security architecture of ASP.NET, how to identify users who access our application and how to ensure that users are granted access only to areas we choose. A special attention is devoted to the analysis of user identification based on user ID forms. Another important section focuses on the administration of users and roles by using the ASP.NET configuration API. The last section explains the protection of configuration files of web applications. In the second part we describe how to ensure that hackers may not capture the data being transmitted or to alter the data during transmission. We also explain how to store sensitive data in database and how to prevent the data from being read in case of capture. The third part is devoted to the most vulnerable spots in web applications and the related threats. It also explains how to deal with these vulnerabilities in the ASP.NET environment. The last part presents a multi-user application that administers and stores sensitive data by using the ASP.NET technology. The application demonstrates implementation of the security elements covered by this thesis. First, we describe the application and then go on to show and describe the steps to be taken during implementation of individual security elements. The thesis is available on the attached CD.

▪ 68 ▪


15.

SEZNAM POUŽITÉ LITERATURY

1. MACDONALD, Matthew; FREEMAN, Adam; SZPUSZTA, Mario. ASP.NET 4 a C# 2010 : tvorba

dynamických stránek profesionálně, kniha 2. 2010. [s.l.] : Zoner Press, 2011. 700 s. ISBN 978-80-7413-145-5.

2. Microsoft Corporation. Vytváříme zabezpečené aplikace v Microsoft ASP.NET . 2003. [s.l.] : Computer Press, 2004. 542 s. ISBN 80-251-0466-4.

3. NAGEL, Christian; EVJEN, Bill; GLYNN, Jay; SKINNER, Morgan; WATSON, Karli. Wrox Professional C# 2008. 2008. [s.l.] : Wiley Publishing, 2008. 1847s. ISBN 978-0-470-191378. 4. MRNKA, Ladislav. Herakles.zcu.cz - /education/net/lectures/ [online]. 2005 [cit. 2011-0719].

Bezpečnost

v

ASP.NET.

Dostupné

.

▪ 69 ▪

z

WWW:


16.

SEZNAM POUŽITÝCH INTERNETOVÝCH ZDROJŮ

1. Microsoft. Technet [online]. 2011 [cit. 2011-06-01]. Zosobnění v technologii ASP.NET. Dostupné z WWW: . 2. BEDNÁŘ, Vojtěch . Microsoft Passport v koncích. Nebo na začátku?. Lupa.cz [online]. 2005, 1, [cit. 2011-06-07]. Dostupný z WWW: . 3. MALÝ, Martin. Implementace přihlašování pomocí Live ID. Zdrojak.cz [online]. 2009, 1, [cit. 2011-06-07]. Dostupný z WWW: . 4. VALÁŠEK,

Martin.

Jak

tickety. Aspnet.cz [online].

funguje

2008,

1,

forms [cit.

authentication

2011-08-17].

a

Dostupný

autentizační z

WWW:

. 5. ODVÁRKA, Petr. SSL protokol (1) - princip a přínosy. Svět sítí [online]. 2002, 1, [cit. 201106-15].

Dostupný

z

WWW:

rubrika=Tutorialy&temaID=171&clanekID=187>. 6. STEBERL, Jan. Technet [online]. 2010 [cit. 2011-07-01]. Žádost o SSL certifikát. Dostupné z WWW: . 7. Symetrická kryptografie.

Wikipedia : the free encyclopedia [online]. St. Petersburg

(Florida) : Wikipedia Foundation, 06. 06. 2006, last modified on 11.05.2011 [cit. 2011-0817]. Dostupné z WWW: . 8. KOVÁŘ, Dušan. Asymetrické šifrování. Projekty SIPVZ [online]. 2006, 1, [cit. 2011-07-12]. Dostupný z WWW: . 9. NET-VORův blok [online]. 2010 [cit. 2011-07-07]. Bezpečnost hesel v PHP. Dostupné z WWW: . 10. Microsoft. Msdn [online]. 2011 [cit. 2011-08-17]. SymmetricAlgorithm Class. Dostupné z WWW:

us/library/system.security.cryptography.symmetricalgorithm.aspx>. 11. Microsoft. Msdn [online]. Dostupné

z

2011

[cit.

2011-07-07]. WWW:

RSACryptoServiceProvider

Methods.

us/library/system.security.cryptography.rsacryptoserviceprovider_methods(v=VS.71).aspx>.

▪ 70 ▪


12. Preventing SQL Injection in ASP.NET. Mikesdotnetting [online]. 2009, 1, [cit. 2011-07-14]. Dostupný z WWW: . 13. Cross-site scripting. Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 27. 12. 2006, last modified on 08.07. 2011 [cit. 2011-08-17]. Dostupné z WWW: . 14. TICHÝ, Jan. PHP Guru [online]. 2007 [cit. 2011-07-03]. Solení hesel aneb Sůl nad zlato. Dostupné z WWW: . 15. TILL, Michal. Man in the middle attack. KRYPTA [online]. 2001, 1, [cit. 2011-07-18]. Dostupný z WWW: . 16. Microsoft. Technet [online]. 2011 [cit. 2011-06-01]. Architektura technologie ASP.NET. Dostupné z WWW: . 17. Session hijacking. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 27.01.2007, last modified on 13.12.2010 [cit. 2011-08-17]. Dostupné z WWW: .

18. AdminXP [online].

2010

[cit.

2011-07-20].

Zabezpečení.

Dostupné

z

WWW:

.

19. Business center [online]. 2011 [cit. 2011-07-28]. Zákon o elektronickém podpisu. Dostupné z WWW: .

20. Brain Internet Group. Brain Internet Group [online]. 2009 [cit. 2011-07-25]. SSL certifikáty a zabezpečené připojení. Dostupné z WWW: .

21. Implementing .NET Passport Authentication in Web Applications . Extreme experts [online]. 2003,

1,

[cit.

2011-08-01].

Dostupný

z

WWW:

.

22. The Definitive Guide To MOSS Pluggable Authentication Providers. ARB SECURITY

SOLUTIONS [online].

2011,

1,

[cit.

2011-08-05].

Dostupný

z

WWW:

.

▪ 71 ▪


17.

SEZNAM POUŽITÝCH SYMBOLŮ A ZKRATEK

Zkratka

Popisek

CLR

Common Language Runtime

IIS

Internet Information Services

API

Application Programming Interface

CV

Curriculum Vitae

SDK

Software development kit

NTLM

NT LAN Manager

ACL

Access Control List

CAS

Code Access Security

AD

Active Directory

MAC

Message Authentication Codes

CA

Certifikační autorita

SSL

Secure Socker Layer

TCP/IP

Transmission Control Protocol / Internet Protocol

Http

Hypertext Transfer Protocol

Https

Hypertext Transfer Protocol Secure

MD

Message-Digest

SHA

Secure Hash Algorithm

DRAPI

Data Protection Application Programming Interface

SQL

Structured Query Language

XSS

Cross-Site Scripting

DoS

Denial of Service

DdoS

Distributed Denial of Service

CAPTCHA

Completely Automated Public Turing test to tell Computers and Humans Aparts

WCF

Windows Communication Foundation

PC

Personal Computer

▪ 72 ▪


18.

SEZNAM OBRÁZKŮ

Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek

1: Bezpečnostní architektura technologie ASP.NET...............................................11 2: Implementační třídy rozhraní IPrincipal a IIdentity .............................................12 3: Identita protéka přes síťové hopy ........................................................................15 4: Ověřování systému Windows.................................................................................16 5: Přihlašovací okno základního ověřování s varováním .......................................17 6: Proces základního ověřování.................................................................................18 7: Proces ověřování algoritmem Digest....................................................................18 8: Proces ověřování službou Passport......................................................................20 9: Proces formulářové autentizace bez existence autentizační Cookie ...............21 10: Proces autorizace podle souboru........................................................................24 11: Proces autorizace podle URL..............................................................................25 12: Architektura API rolí.............................................................................................. 29 13: Architektura API členství......................................................................................34 14: Struktura certifikátu X.509 verze 3......................................................................36 15: Pozice protokolu SSL v TCP/IP modelu.............................................................37

Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek

16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31:

Informace o zabezpečené komunikaci................................................................37 Proces šifrování a dešifrování symetrické kryptografie ...................................39 Proces šifrování a dešifrování asymetrické kryptografie .................................41 Ukázka útoku pomocí SQL injection...................................................................46 Ilustrace perzistentního XSS útoku.....................................................................48 Ilustrace útoku session fixation...........................................................................49 Princip útoku Man-In-The-Middle........................................................................50 Princip DDoS útoku............................................................................................... 51 Recaptcha umístěná ve formuláři........................................................................52 Funkčnosti aplikace............................................................................................... 54 Big picture řešení................................................................................................... 55 Use-case diagram aplikace BOSS travel...........................................................56 Komponenta Login v BOSS travel aplikaci........................................................61 Důležité třídy API rolí............................................................................................ 77 Důležité třídy API členství....................................................................................78 Představený projekt v akci...................................................................................80

▪ 73 ▪


19.

SEZNAM TABULEK

Tabulka Tabulka Tabulka Tabulka Tabulka Tabulka Tabulka

1: 2: 3: 4: 5: 6: 7:

Atributy pro element .................................................................................22 Symetrické algoritmy, které podporuje .NET........................................................39 Nejdůležitější metody třídy SymmetricAlgorithm.................................................40 Asymetrické algoritmy, které podporuje................................................................42 Nejdůležitější metody třídy RSACryptoServiceProvider.....................................42 Hešohovací algoritmy, které podporuje .NET.......................................................44 Nejdůležitější metody třídy HashAlgorithm...........................................................44

▪ 74 ▪


20. Kód Kód Kód Kód Kód Kód Kód Kód Kód Kód Kód Kód Kód Kód Kód

SEZNAM ZDROJOVÝCH KÓDŮ 1: Nastavení chybové stránky v souboru Web.config.....................................................58 2: Nastavení formulářové autentizace v souboru Web.config.......................................58 3: Konfigurace připojovacího řetězce v souboru Web.config .......................................59 4: Konfigurace zabezpečení WCF v souboru Web.config..............................................59 5: Konfigurace členství v souboru Web.config.................................................................60 6: Nastavení rolí v souboru Web.config............................................................................60 7: Webová služba UserService volající statickou třídu UserWorker............................62 8: Volání metody AddNewCreditCard webové služby CreditCardService ...................62 9: Generování Triple-DES klíče metodou VygenerujKlic().............................................63 10: Načtení klíče ze souboru metodou NactiKlic()..........................................................63 11: Metoda Zašifruj() implementující šifrování dat..........................................................64 12: Kód v logické části stránky obstarávající informace o kartě ...................................64 13: Metoda GetCreditCard() třídy CreditCardWorker.....................................................65 14: Dešifrování informací metodou Desifruj() třídy CreditCardWorker........................65 15: Implementace metody Ohodnot() ve statické třídě ZajezdyWorker .......................66

▪ 75 ▪


21.

SEZNAM PŘÍLOH

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

▪ 76 ▪


PŘÍLOHA 1 – VLASTNOSTI A METODY DŮLEŽITÝCH TŘÍD API ROLÍ Obrázek 29: Důležité třídy API rolí

Zdroj: Autorem vytvořeno v MS Visual Studio 2010

▪ 77 ▪


PŘÍLOHA 2 – VLASTNOSTI A METODY DŮLEŽITÝCH TŘÍD API ČLENSTVÍ Obrázek 30: Důležité třídy API členství

Zdroj: Autorem vytvořeno v MS Visual Studio 2010

▪ 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 CD je přiloženo k vázané bakalářské práci a má následující strukturu: ●

Projekt představené aplikace 

●

●

BOSStravel

Projekt představené aplikace pro otestování s přiloženým manuálem 

BOSStravel



Manual.pdf

Databaze 

Inserty 



bakalarka_insert_Zajezd.sql

Tabulky 

Users_Card_Query.sql



Zajezdy_Banlist_Query.sql

Projekt ve složce „Projekt představené aplikace pro otestování s přiloženým manuálem“ neobsahuje určitou bezpečnostní konfiguraci, kterou jsem použil při

tvorbě

popsané aplikace v práci. Jedná se konkrétně o tyto nastavení: ●

Element ConnectionStrings není šifrován - Důvod je ten, že v případě testování aplikace bude nutno informace v connectionStrings změnit. Bylo by tedy nelogické informace šifrovat.

●

Atribut requireSSL = “true“ - Aplikace musí běžet na šifrovaném spojení, které poskytuje server IIS. Tato práce se nezabývá konfigurací serveru IIS a tedy tyto atributy jsou nastaveny na hodnotu false. Atributy jsou odebrány z : ●

Nastavení formulářového ověřování v souboru Web.config (projekt BOSS Travel)

▪ 79 ▪


●

Atribut cookieRequireSSL = “true“ ●

Nastavení

API

rolí

v

souboru

Web.config

(projekt

BOSS

Travel,

BOSStravelService) Tato práce se nezabývá konfigurací IIS serveru. V případě, že chcete použít zabezpečenou komunikaci pomocí SSL protokolu je nutno IIS server nastavit a uvedenou bezpečnostní konfiguraci zpětně do projektu doplnit. Projekt ve složce „Projekt představené aplikace“ reprezentuje popsaný projekt v této práci. Konfigurace je tedy přímo určena PC, na kterém se implementoval. Obrázek 31: Představený projekt v akci

Zdroj: Autorem vytvořeno v internetovém prohlížeči Google Chrome

▪ 80 ▪

BAKALÁŘSKÁ PRÁCE. Bezpečnost ASP.NET aplikací. ASP.NET Web Application Security. Marek Pavelek

Recommend Documents