bakalářská práce - Unicorn College

Transkript

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
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:
<authentication mode="None|Windows|Passport|Forms">
Do uvozovek se uvádí pouze jeden z těchto čtyř režimů ověřování. Každý z nich je popsán
v následujících podkapitolách.
8.2.1
Ověřování systému Windows
Tento způsob ověřování se využívá hlavně ve firemním intranetu, kde mají uživatelé
vytvořený účet ve Windows, přes který se do systému přihlašují. Systém tedy využívá již existující
údaje o uživatelích a jejich členství ve skupinách. „Největším přínosem této metody je, že lze
provádět neviditelné ověřování, při němž (v závislosti na použitých nastaveních a architektuře sítě)
není nutná samostatná přihlašovací procedura.“
Ověřování není implementováno v ASP.NET, ale provádí se na úrovni Internetové
informační služby (IIS). Díky tomu odpadají starosti spojené s přihlašovací stránkou a vše, co k ní
náleží (validita dat, přístup do databáze a další věci s tím spojené). Jedna z obrovských výhod
spočívá v použití nástroje Správce služby IIS, v kterém se provádí veškerá konfigurace tohoto
režimu. (MACDONALD, FREEMAN, SZPUSZTA, 2010, s. 115-116)
Důležitým bezpečnostním prvkem v ověřování systému Windows je zosobnění, jenž nám
dává možnost dočasně měnit identitu využívanou ASP.NET k provádění určitých úloh. Zosobnění
je ve výchozím nastavení zakázáno. To znamená, že jsou úlohy prováděny pod stejným
uživatelským účtem (většinou ASPNET účet). Pro povolení zosobnění v aplikaci musíte do souboru
Web.config přidat prvek < identity > .
●
Povolení zosobnění pro aplikaci
<identity impersonate="true"/>
●
Zosobnění uživatele pro všechny požadavky aplikace
<identity impersonate="true" userName="unicorn\PavelekM"
password="pass"/>
▪ 14 ▪
Pro
dočasné
provádění
úloh
pod
zvolenou
identitou
slouží
metoda
WindowsIdentity.Impersonate(), kterou voláme přímo v kódu programu. Metoda pracuje
buď s tokeny účtů, a nebo instancí. Token obsahuje informace o ověření uživatele.
(207.46.16.252/cs-cz/library/cc787120(WS.10).aspx)
●
Pokud máme token již uložený v proměnné, zosobnění vyvoláme velice jednoduše:
WindowsIdentiy.Impersonate(token);
●
Samotná instance aktuálně přihlášeného uživatele se volá následovně:
(WindowsIdentity)HttpContext.Current.User.Identity;
Obrázek 3: Identita protéka přes síťové hopy
Zdroj: MacDonald, Freeman, Szpuszta (2010), vlastní úprava
Se zosobněním souvisí i pojem delegování. Při použití zosobnění nelze přistupovat na jiný
server v síti pod dočasnou identitou. Delegování je založeno na stejném konceptu jako zosobnění,
ale přístup na jiný server umožňuje způsobem, který převezme ticket ověřeného uživatele a pošle
ho jinému serveru v síti. Delegování lze využít v integrovaném ověřování systému Windows jen v
případě, pokud má původní server patřičná oprávnění a je zde ověřovací protokol Kerberos (více o
protokolu Kerberos v kapitole 9.1.1.3). V metodě ověřování algoritmem digest není delegování
možné, naopak v základním ověřování lze delegování uplatnit po splnění určitých podmínek.
(MACDONALD, FREEMAN, SZPUSZTA, 2010, s. 136-137)
▪ 15 ▪
Obrázek 4: Ověřování systému Windows
▪ 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í.
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
<authentication mode=""> v souboru Web.config, jelikož je tento atribut při vytvoření
nového projektu implicitně nastavena na Forms. Značka <forms> v sekci <authentication>
představuje důležité volby ověřování. Tyto volby jsou shrnuty v následující tabulce.
Tabulka 1: Atributy pro element <forms>
Atribut
Možnost
Popis
name
Určuje název HTTP cookie pro ověřování. Výchozí hodnota je
nastavena na .ASPXAUTH. V případě, že na jednom serveru
běží více jak jedna aplikace, je potřeba tuto hodnotu změnit pro
každý Web.config aplikace.
loginUrl
Určuje, kam bude uživatel přesměrován v případě, že nevlastní
ověřovací cookie. Základním nastavením je stránka
default.aspx.
protection
Určuje typ šifrování, které se pro ověřovací cookies použije.
Původní hodnota je nastavena na All.
All
Ověřovací cookie se šifruje (pomocí šifry Triple-DES) a
podepisuje.
None
Tato možnost není doporučována a znamená, že ověřovací
cookies se nešifrují ani nepodepisují.
Encryption Ověřovací cookie se šifruje použítím šifry Triple-DES nebo DES
Validation Ověřovací cookie se podepisuje
timeout
Udává počet minut do vypršení platnosti ověřovací cookie.
Původní hodnota je nastavena na 30.
path
Specifikuje cestu pro cookies zaslaných aplikací. Původni
hodnota je „ / “.
requireSSL
Určuje, zdali je SSL připojení vyžadováno pro přenost
ověřovacích cookie. Původní hodnota je nastavena na false.
true
Pokud na webovém serveru není aktivováno SSL, webový
prohlížeč nebude přenášet ověřovací cookie. To znamená, že
▪ 22 ▪
formulářová autentizace nebude funkční.
flase
SlidingExpir
ation
Na webovém serveru není vyžadováno aktivní SSL
Určuje, zda se bude doba života ověřovacího cookie
prodlužovat (vyresetováním expirační doby) na základě nově
vytvořených požadavků. Původní hodnota je nastavena na
false.
true
Klouzavá expirační doba je aktivována.
false
Klouzavá expirační doba není aktiví.
cookieless
Specifikuje, zda bude ASP.NET aplikace zasílat ověřovací
cookie klientovi.
UseCookies Bude zasílat klientovi ověřovací cookie. V případě, že klientský
prohlížeč cookie nepodporuje, ověření nebude fungovat a
uživatel se nikdy nepřihlásí.
UseUri
Ověřovací lístek se nebude zasílat v cookies, ale bude
zakódován do URL.
AutoDetect Pokud prohlížeč cookies podporuje, ověřovací lístek je
předáván pomocí cookies, v opačném případě bude kódován
do URL.
UseDeviceP Ověřovací lístek je předán volbou specifikovanou v profilu
zařízení. Tento profil je uložen na webovém serveru.
rofile
Zdroj: msdn.microsoft.com/en-us/library/1d3t3c61.aspx
8.2.4
Režim ověřování None
Nedochází k zádnému ověřování. Pokud plánujete vytvořit vlastní ověřování například
pomocí jiné služby než Passport, je tento režim na místě.
8.3
Autorizace
Proces autorizace je v zabezpečených systémech nezbytný. Nastává hned po ověření
subjektu a jeho úkolem je stanovovat práva a omezení tomuto subjektu. Pomocí autorizace tedy
docílíme dalšího stupně bezpečnosti systému v podobě omezení přistupu k zabezpečeným
prostředkům nepověřeným subjektům.
Stejně jako u ověřování si autorizaci můžeme představit v reálném životě. Pokračujme tedy
se zaměstancem Temelína, který je již ověřen. Zaměstnanec má stanovenou určitou práci, kterou
má za úkol vykonat. Tato práce je uskutečněna v některém ze segmentů této elektrárny.
Zaměstnanec tedy musí projít určitým počtem segmentů, aby se dostal k tomu svému, kde má
práci vykonat. K tomuto účelu slouží jeho karta, která ho identifikuje. Díky ní prochází segmenty,
které má od zaměstnavatele povoleny. V případě, že chce zaměstnanec projít segmentem, ve
▪ 23 ▪
kterém nic dělat nemá, zabezpečovací dvěře (popřípadě ochranka) ho do tohoto segmentu
nepustí. Nebylo by zrovna vhodné, aby zaměstnanec obsluhující stroj pro odvoz jaderného odpadu
měl přístup k panelu pro manipulaci s jadernými tyčemi.
8.3.1
Způsoby autorizace v ASP.NET
8.3.1.1
Autorizace podle souboru
Provádí se na základě práv v souborovém systému serveru. Jak jistě víte, v souborovém
systému NTFS lze nastavovat uživatelská a skupinová oprávnění k souborům. Autorizace podle
souboru je prováděna modulem FileAuthorizationModule. V případě, že chce uživatel
přistoupit k souboru, FileAuthorizationModule se podívá na oprávnění tohoto uživatele
vztahující se k tomuto souboru, a pokud tato práva nevlastní, vyhodí výjimku, při které je uživateli
zobrazena informace ohledně zamezení přístupu. Samozřejmě tento způsob autorizace lze uplatnit
pouze s ověřováním systému Windows. K souborům je možné připojit seznamy ACL (Access
Control Lists), pomocí nichž lze řídit oprávnění přístupu k těmto souborům.
(MRNKA, 2005, s. 51-52)
Obrázek 10: Proces autorizace podle souboru
▪ 24 ▪
8.3.1.2
Autorizace podle adresy URL
Prováděna modulem UrlAuthorizationModule. „Mapuje uživatele a role na části
oboru názvů URL. Modul implementuje pozitivní i negativní autorizační výroky. To znamená, že
modul lze použít k selektivnímu povolení nebo odepření přistupu k libovolným částem oboru názvů
URL pro určité skupiny, uživatele nebo role.“
(technet.microsoft.com/cs-cz/library/cc779441(WS.10).aspx)
Autorizace podle adressy URL nastavuje sekce
<authorization> v souboru
Web.config. První element uvádí o jakou autorizaci se jedná. Allow udává pozitivní a deny
negativní. Za tímto elementem následují atributy users=".." a roles="..". Pro správnou
funkčnost musí být alespoň jeden z atributů uveden. Do uvozovek za atributem users se uvadí
přihlašovací jména uživatelů a do atributu roles víčet rolí. Dalším a posledním atributem, jež lze
zde zadat je verbs="..". Atribut určuje, na jaké požadavky se autorizace vztahuje. Do atributu
verbs se vkládá hodnota GET, POST nebo HEAD7. (MRNKA, 2005, s. 53)
Obrázek 11: Proces autorizace podle URL
7
Metody požadavku protokolu HTTP
▪ 25 ▪
Do uvozovek atributů lze uvést dva zástupné znaky. První znak „ * “ zastupuje všechny
uživatele. Druhý znak „ ? “ zastupuje pouze anonymní uživatele. Těchto znaků můžete využít
například pokud máte v ASP.NET projektu vytvořenu hierarchii pomocí složek a potřebujete
zabezpečit určité stránky tak, aby na ně mohli pouze ověření uživatelé. Stačí vytvořít soubor
Web.config například pomocí klávesové zkratky CTRL+SHIFT+A v této složce a konfigurační
soubor nastavit následovně:
<configuration>
<system.web>
<authorization>
<deny users="?" />
</authorization>
</system.web>
</configuration>
Toto nastavení zamezí přistupovat neověřeným uživatelům k čemukoliv ve složce. Pokud
adresář obsahuje podadresář, ve kterém je také soubor Web.config, nastavení v něm má vyšší
váhu než nastavení práv adresáře nadřazeného.
Při práci s autorizací v souboru Web.config využijeme i element <location> s
atributem path="..". To konkrétně v případě aplikace práv pouze na jednotlivé soubory. Do
elementu se vkládá cesta ke stránce, ke které se nastavení autorizace vztahuje.
<location path="Stranka.aspx">
<system.web>
….....
</system.web></location>
▪ 26 ▪
8.3.2
Role
Zastupuje určitý počet subjektů a jsou na ni mapována práva a omezení. V příkladu se
zaměstnancem jsou také využity role. Není možné, aby společnost, která má nad 1000
zaměstnanců, určovala práva a omezení pro každého zaměstnance zvlášť. To by znamenalo, že v
případě každého nově příchozího/odchozího zaměstnance by se mu musela práva a omezení
přidělovat/odebírat zvlášť. Samozřejmě by toto řešení zabralo spoustu času a díky použití rolí
pouze nově příchozího zaměstnance do určité role obsadíme a automaticky dostane práva a
ověření vztahující se k této roli.
Ve webových systémech se s ničím jiným než s rolemi nesetkáme. Možná se najdou
unikáty aplikující práva na jednotlivé uživatele, ale dovolím si tvrdit, že je to pouze z nezkušenosti
daného programátora.
ASP.NET má pro práci s rolemi předem vytvořené API (Application Programming
Interface)8. Pomocí tohoto API můžete spravovat role velice jednoduše. Lze ho využít jak pro
ověřování založené na formulářích, tak i ověřování systému Windows. Pro aktivaci API stačí přidat
do souboru Web.config element <roleManager> s atributem enabled="true".
<configuration>
<system.web>
<roleManager enabled="true" />
<providers>
…...
</providers>
</system.web>
</configuration>
Poskytovatelé rolí se konfigurují v podelementu <provider>
elementu <roleMan-
ager>. Podrobnější konfigurace je ukázána v kapitole 12.6.
8
Rozhraní obsahující třídy, funkce a jíné. Programátor pak tohoto obsahu může využívat.
▪ 27 ▪
8.3.2.1
Architektura API rolí v ASP.NET
Skládá se ze čtyř hlavních částí:
●
Ověřovací prvky pro bezpečnost – Vestavěné bezpečnostní komponenty ASP.NET.
Například pomocí komponenty LoginView můžeme vytvářet rozdílné pohledy v závislosti
na rolích.
●
API pro role – V této části jsou umístěny třídy API rolí jmenného prostoru
System.Web.Security. Všechny metody a vlastnosti tříd jsou znázorněny v příloze 1.
Nejdůležitější třídy jsou:
●
Třída Roles – obsahuje metody a vlastnosti pro správu rolí. Jedna z hojně
využívaných metod je IsUserInRole(), která zjistí, zda je uživatel v roli umístěné ve
vstupní hodnotě metody.
●
Třída RolePrincipal – Dědí z třídy IPrincipal a úkolem této třídy je spojovat role s
autentizovaným uživatelem.
●
Třída RoleManagerModule – „Zajišťuje, že aktuálně přihlášenému uživateli budou
přiděleny role pro každý jeho požadavek.“
●
Poskytovatelé rolí – Implementují přístup k úložišti dat API rolí. Pro poskytovatele je
základní třída RoleProvider, z které ostatní poskytovatelé dědí. ASP.NET obsahuje tři
zabudované poskytovatele rolí:
●
Poskytovatel SQL Serveru – Pracuje s databázemi SQL serveru. Je reprezentován
třídou SqlRoleProvider. Samotné uložení dat do databáze probíhá přes
connectionString definovaný u konkrétního poskytovatele v souboru Web.config.
Pro práci s API rolí je nutno importovat určité tabulky představující úložnou strukturu
rolí
do
SQL
databáze
pomocí
spouštěcího
souboru
aspnet_regsql.exe
umístěného v adresáři:
[disk]:\Windows\Microsoft.NET\Framework[verze]
●
Poskytovatel Authorization Store – Mapuje role z Microsoft Authorization Manager
(AzMan)
do
rolí
v
ASP.NET.
Je
reprezentován
třídou
AuthorizationStoreRoleProvider.
●
Poskytovatel Windows Token – „Získává informace o rolích pro ověřeného uživatele
Windows založeného na asociacích skupiny Windows.“
(MACDONALD, FREEMAN, SZPUSZTA, 2010, s. 143, 158)
▪ 28 ▪
Obrázek 12: Architektura API rolí
Zdroj: http://www.sharepointsecurity.com/sharepoint/sharepoint-development/the-definitive-guideto-moss-pluggable-authentication-providers , vlastní úprava
8.3.3
Možnosti autorizace na business vrstvě
Jak již jistě víte, většina webových aplikací pracuje na třívrstvé architektuře 9. Výše zmíněné
možnosti autorizace pracují na vrstvě prezentační. ASP.NET obsahuje možnosti autorizace i na
business vrstvě. Při použití takovéto autorizace je aplikace schopna povolit, či nepovolit uživateli k
volání metod, vytváření instancí tříd atp. Jedná se konkrétně o:
9
Skládá se ze tří vrstev :
Prezentační vrstva – funkce uživatelského rozhraní.
Aplikační vrstva – logika aplikace.
Datová vrstva – funkce pro přístup k datům.
▪ 29 ▪
8.3.3.1
Role-based security
Model autorizace je založen na principálovi (viz kapitola 8.1.1), kde ke zjištění, zda je
uživatel obsažen v roli, slouží metoda IsInRole(). Pro tento model však existuje ještě jeden
způsob pro práci s autorizací.
●
Využívá se třídy PrincipalPermission. Při vytváření instance této třídy se uvádí
jako jeden ze vstupních parametrů název role. Po zavolání metody Demant() na
vytvořené instanci třídy PrincipalPermission se vyhodnotí, zda aktuálně
přihlášený uživatel do role patří. Pokud uživatel do role nepatří, je vyhozena
bezpečnostní
výjimka.
Tento
model
lze
implementovat
i
pomocí
atributu
PrincipalPermission, který se přiřazuje určité třídě nebo metodě. Kód pak může
vypadat následovně:
●
Použití třídy PrincipalPermission
PrincipalPermission kontrola = new PrincipalPermission(null,
"Administrators");
●
Použití atributu PrincipalPermission
[PrincipalPermission(SecurityAction.Demand, Role=
"Administrators")]
8.3.3.2
Code Access Security (CAS)
Veškeré Windows aplikace mají přístup k prostředkům jako registry systému Windows,
místní disky, protokoly událostí atd. Může se tedy snadno stát, že v případě spuštění škodlivého
kódu se tyto prostředky poškodí (např. smazání důležitých souborů operačního systému, editace
registrů). CAS tyto prostředky systému chrání před záludnými kódy. Tedy říká kódu, co má
povoleno dělat a co ne podle jeho stupně důvěryhodnosti. Pokud CLR věří kódu natolik, aby ho
spustil, a kód začne dělat něco, na co nemá právo, je vyhozena bezpečnostní výjimka. CAS je
založeno na těchto pojmech:
●
Oprávnění – Určuje to, co má kód povoleno dělat. Je vydáváno pro jednotlivé kódové
skupiny.
▪ 30 ▪
Sady oprávnění – Abychom skupinám nemuseli přiřazovat jednotlivá oprávnění,
●
existují právě sady oprávnění, které jednotlivá oprávnění sdružují. Mezi ně patří
například FullTrust (neomezený přístup k chráněným prostředkům), UIPermission
(oprávnění k využívání uživatelského rozhraní).
Kódové skupiny – Sady oprávnění nejsou přidělovány jednotlivým knihovnám, ale
●
skupinám, do kterých jsou knihovny přiřazeny. Řazení probíhá na základě vlastností.
Každá skupina řadí knihovny pouze podle jediné vlastnosti. Nejvyužívanější je
vlastnost zóna, která určuje, odkud knihovna pochází. Knihovna však může patřit do
několika skupin, v takovém případě je provedeno sjednocení oprávnění z těchto
skupin.
(NAGEL, EVJEN, GLYNN, SKINNER, WATSON, 2008, s. 602-603)
8.3.4
Zabezpečení konfiguračních souborů
Při práci s ASP.NET by vás mohlo zajímat, co se stane v případě, zadáte-li do prohlížeče
adresu k souboru Web.config. Budete s ním moci manipulovat? Odpověď zní - samozřejmě ne.
Webový server IIS má registrované přípony souborů, mezi ně patří i přípona .config. Server IIS
tedy zamezí stahování konfiguračních souborů ASP.NET.
Není vhodné ukládat všechny konfigurační informace do jednoho konfiguračního souboru.
Například nechcete, aby zaměstnanec firmy mohl spravovat a vidět jiný obsah než sekci <pages>.
Toho lze dosáhnout pomocí externalizace sekcí konfiguračních souborů. Jednoduše se vytvoří
nový konfigurační soubor např. Pages.config, který bude uchovávat již zmíněnou sekci
<pages>.
Do
souboru
Web.config
stačí
k
sekci
<pages>
přidat
atribut
configSource="Pages.config", ať ví, kde má hledat. Zaměstnanci pak zamezíme přístup k
souboru Web.config a přidáme potřebná oprávnění na soubor Pages.config.
Pokud chcete bezpečnost konfiguračních souborů ještě zvýšit, ASP.NET podporuje
šifrování
částí
kódu
v
konfiguračních
souborech.
Je
doporučeno
šifrovat
sekci
<connectionStrings>, protože se jedná o velice citlivé informace nesoucí uživatelské jméno a
heslo pro přístup k databázi.
Šifrování sekcí konfiguračních souborů lze provést pomocí nástroje aspnet_regiis
umístněného v [disk]:\Windows\Microsoft.NET\Framework\[verze] . Lze si zde i zvolit,
pomocí jakého algoritmu budou data šifrována.
▪ 31 ▪
8.4
Členství
Internetové aplikace pracují většinou s uživateli a jejich správou. Jak již bylo zmíněno,
bezpečnostní architektura ASP.NET obsahuje různé způsoby ověřování a autorizace uživatelů.
Nebylo však nic řečeno o jejich vytváření, odstraňování, změnách hesla apod. Tato oblast je
implementována pomocí API členství (membership API). Tohoto API se využívá spolu s
ověřováním založeném na formulářích.
Členství
zpřístupníme
a
nakonfigurujeme
v
souboru
Web.config
elementem
<membership>. V něm se například určuje, v jaké formě bude uloženo heslo uživatele, zda je
povolena změna hesla atd.
<configuration>
<system.web>
<Membership>
<providers>
…...
</providers>
</system.web>
</configuration>
Tento element obsahuje podelement <providers>, ve kterém jsou
poskytovatelé členství. Podrobnější konfiguraci tohoto elementu popisuje kapitola 12.5.
▪ 32 ▪
definováni
8.4.1
Architektura API členství
Je velice podobná architektuře API rolí. Skládá se také ze čtyř hlavních částí:
●
Ovládací prvky pro bezpečenost – Microsoft Visual Studio obsahuje vestavěné
bezpečnostní komponenty pro formulářovou autentizaci a infrastrukturu členství. Ty lze
snadno přizpůsobovat a tím dosáhnout efektivní práce v poměru s časovou náročností na
jejich implementaci. Komponenty Login, LoginStatus, LoginView, CreateUserWizard a
ostatní jsou umístěny ve skupině Login panelu ToolBox.
●
API pro členství – Obsahuje třídy pro API členství umístěné ve jmenném prostoru
System.Web.Security. Všechny metody a vlastnosti tříd jsou znázorněny v příloze 2.
Nejdůležitější jsou třídy Membership a MembershipUser.
●
Třída Membership – Obsahuje statické metody a vlastnosti pro správu uživatelů,
jejich ověřování a pro přístup k jejich rolím. Tyto metody pracují se základním
poskytovatelem aplikace pro členství.
●
Třída MembershipUser – Ztvárňuje jedniného uživatele a obsahuje metody a
vlastnosti pro práci s ním.
●
Poskytovatelé členství – Implementují přístup k úložišti dat API členství. Pro
poskytovatele je základní třída MembershipProvider, z které ostatní poskytovatelé dědí.
ASP.NET obsahuje dva zabudované poskytovatele členství:
●
Poskytovatel SQL serveru – Poskytovatel pracuje s databázemi SQL serveru. Je
reprezentován třídou SqlMembershipProvider. Samotné uložení dat do databáze
probíhá přes connectionString definovaný u konkrétního poskytovatele v souboru
Web.config. Členství potřebuje pro práci určité tabulky. Ty je možné do SQL
databáze importovat pomocí spouštěcího souboru aspnet_regsql.exe umístěného
v adresáři:
[disk]:\Windows\Microsoft.NET\Framework\[verze]
●
Poskytovatel
Active
Directory
–
poskytovatel
pracuje
s
Active
Directory.
Reprezentován třídou ActiveDirectoryMembershipProvider.
●
Úložiště členství – Reprezentuje konkrétní úložiště, kam se budou jednotlivé položky API
členství ukládat a odkud jsou načítány.
▪ 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
vstupní parametr.
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
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
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.
▪ 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.
<httpCookies httpOnlyCookies="true"/>
Jednotlivé Cookies pak obsahují část, ve které je vyznačeno, že se jedná o HttpOnly. Na
to reaguje internetový prohlížeč (který ovšem příkaz HttpOnly podporuje) a omezí veškerý
přístup klientských skriptů k hodnotám Cookies. Mezi prohlížeče podporující tuto funkčnost patří
například: Internet Explorer 8, Mozzila Firefox 5.0.1, Opera 11, Safari 5, Google Chrome 13 a jiné.
Obrázek 21: Ilustrace útoku session fixation
Zdroj:
ptgmedia.pearsoncmg.com/images/chap4_0321369440/elementLink
s/04fig17.jpg, vlastní úprava
11.4
Man-In-The-Middle
Útočník se snaží odposlouchávat komunikaci mezi účastníky tak, že se stane
prostředníkem. Tedy veškerá komunikace půjde přes něj a oběť si toho ani nevšimne.
Mějme příklad s Alicí a Bobem, kde si mezi sebou vymění veřejné klíče. Útočník zachytí
klíč Alice, zamění ho za svůj a pošle Bobovi. Stejně postupuje i u Boba. Výsledkem je, že Alice a
Bob šifrují zprávu veřejným klíčem útočníka a vůbec o tom nevědí. Kdykoliv tedy Alice nebo Bob
něco pošlou, útočník to zachytí a dešifruje svým klíčem, znovu zašifruje a následně odešle druhé
straně. (www.krypta.cz/articles.php?ID=94)
▪ 49 ▪
Před tímto typem útoku se bráníme pomocí důvěryhodné třetí strany, v případě webových
aplikací certifikační autoritou (viz 10.1.3). Ta klíč Alice a Boba podepíše a v situaci záměny klíčů za
útočníkův druhá strana zjistí, že to není klíč, který má obdržet.
Obrázek 22: Princip útoku Man-In-The-Middle
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í:
<allow users="*"/>
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.
<authentication mode="Forms">
<forms loginUrl="~/Anonym/Login.aspx"
timeout="10" slidingExpiration="true" defaultUrl="~/Default.aspx"
protection="All" requireSSL="true" cookieless="UseCookies" />
Kód 2: Nastavení formulářové autentizace v souboru Web.config
▪ 58 ▪
12.5
Přistup k databázi
<connectionStrings>
<add name="PripojeniKdbBOSS" connectionString="Data Source=MAREK-PC; Initial
Catalog=BOSStravel ;Integrated Security=True;"
providerName="System.Data.SqlClient" />
</connectionStrings>
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 .
<bindings>
<basicHttpBinding>
<binding name="SecurityByTransport">
<security mode="Transport">
<transport clientCredentialType="Windows" />
</security>
</binding>
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>
<add name="BOSSSqlMembershipProvider"
type="System.Web.Security.SqlMembershipProvider"
connectionStringName="PripojeniKdbBOSS" enablePasswordRetrieval="false"
enablePasswordReset="true" requiresQuestionAndAnswer="false"
requiresUniqueEmail="true" maxInvalidPasswordAttempts="8"
passwordAttemptWindow="20" minRequiredNonalphanumericCharacters="0"
minRequiredPasswordLength="6" />
</providers>
</membership>
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.
<roleManager
enabled="true" cookieTimeout="10" defaultProvider="MujRoleSqlProvider"
cookieProtection="All" createPersistentCookie="false" cacheRolesInCookie="true"
cookieSlidingExpiration="true" cookieRequireSSL="true">
<providers>
<add connectionStringName="PripojeniKdbBOSS" name="MujRoleSqlProvider"
type="System.Web.Security.SqlRoleProvider" />
</providers>
</roleManager>
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 <appSettings> 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:
<recaptcha:RecaptchaControl ID="recaptcha" runat="server" />
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<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é
<http://herakles.zcu.cz/education/net/lectures/ASPNET_security.pdf>.
▪ 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: <http://207.46.16.252/cs-cz/library/cc787120(WS.10).aspx>.
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: <http://www.lupa.cz/clanky/microsoftpassport-v-koncich-nebo-na-zacatku/?labelsBox-labelId=38&do=labelsBox-switch>.
3. MALÝ, Martin. Implementace přihlašování pomocí Live ID. Zdrojak.cz [online]. 2009, 1, [cit.
2011-06-07]. Dostupný z WWW: <http://zdrojak.root.cz/clanky/implementace-prihlasovanipomoci-live-id/>.
4. VALÁŠEK,
Martin.
Jak
tickety. Aspnet.cz [online].
funguje
2008,
1,
forms
[cit.
authentication
2011-08-17].
a
Dostupný
autentizační
z
WWW:
<http://www.aspnet.cz/articles/188-jak-funguje-forms-authentication-a-autentizacnitickety>.
5. ODVÁRKA, Petr. SSL protokol (1) - princip a přínosy. Svět sítí [online]. 2002, 1, [cit. 201106-15].
Dostupný
z
WWW:
<http://www.svetsiti.cz/view.asp?
rubrika=Tutorialy&temaID=171&clanekID=187>.
6. STEBERL, Jan. Technet [online]. 2010 [cit. 2011-07-01]. Žádost o SSL certifikát. Dostupné
z WWW: <http://technet.microsoft.com/cs-cz/edge/zadost-o-ssl-certifikat-cz>.
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: <http://cs.wikipedia.org/wiki/Symetrick%C3%A1_kryptografie>.
8. KOVÁŘ, Dušan. Asymetrické šifrování. Projekty SIPVZ [online]. 2006, 1, [cit. 2011-07-12].
Dostupný z WWW: <http://projektysipvz.gytool.cz/ProjektySIPVZ/Default.aspx?uid=555>.
9. NET-VORův blok [online]. 2010 [cit. 2011-07-07]. Bezpečnost hesel v PHP. Dostupné z
WWW: <http://blok.net-vor.cz/bezpecnost-hesel-v-php/>.
10. Microsoft. Msdn [online]. 2011 [cit. 2011-08-17]. SymmetricAlgorithm Class. Dostupné z
WWW:
<http://msdn.microsoft.com/en-
us/library/system.security.cryptography.symmetricalgorithm.aspx>.
11. Microsoft. Msdn [online].
Dostupné
z
2011
[cit.
2011-07-07].
WWW:
RSACryptoServiceProvider
Methods.
<http://msdn.microsoft.com/en-
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: <http://www.mikesdotnetting.com/Article/113/Preventing-SQL-Injectionin-ASP.NET>.
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: <http://cs.wikipedia.org/wiki/Cross-site_scripting>.
14. TICHÝ, Jan. PHP Guru [online]. 2007 [cit. 2011-07-03]. Solení hesel aneb Sůl nad zlato.
Dostupné z WWW: <http://www.phpguru.cz/clanky/soleni-hesel>.
15. TILL, Michal. Man in the middle attack. KRYPTA [online]. 2001, 1, [cit. 2011-07-18].
Dostupný z WWW: <http://www.krypta.cz/articles.php?ID=94>.
16. Microsoft. Technet [online]. 2011 [cit. 2011-06-01]. Architektura technologie ASP.NET.
Dostupné z WWW: <http://technet.microsoft.com/cs-cz/library/cc737863(WS.10).aspx>.
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: <http://cs.wikipedia.org/wiki/Session#Session_hijacking>.
18. AdminXP [online].
2010
[cit.
2011-07-20].
Zabezpečení.
Dostupné
z
WWW:
<http://www.adminxp.cz/security/index.php?aid=193>.
19. Business center [online]. 2011 [cit. 2011-07-28]. Zákon o elektronickém podpisu. Dostupné z
WWW: <http://business.center.cz/business/pravo/zakony/epodpis/cast1.aspx>.
20. Brain Internet Group. Brain Internet Group [online]. 2009 [cit. 2011-07-25]. SSL certifikáty a
zabezpečené připojení. Dostupné z WWW: <http://www.brainweb.cz/ssl-certifikaty>.
21. Implementing .NET Passport Authentication in Web Applications . Extreme experts [online].
2003,
1,
[cit.
2011-08-01].
Dostupný
z
WWW:
<http://www.extremeexperts.com/Net/Articles/ImplementingPassportAuth.aspx>.
22. The Definitive Guide To MOSS Pluggable Authentication Providers. ARB SECURITY
SOLUTIONS [online].
2011,
1,
[cit.
2011-08-05].
Dostupný
z
WWW:
<http://www.sharepointsecurity.com/sharepoint/sharepoint-development/the-definitiveguide-to-moss-pluggable-authentication-providers/>.
▪ 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 <forms>.................................................................................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 - Unicorn College

Transkript

Podobné dokumenty

Výroční zpráva ASP UNESCO 2007

Programátor PHP Náplň práce Požadujeme Vzdělání Datum