Nástroje pro kontrolu bezpečnosti webových aplikací

Nástroje pro kontrolu bezpečnosti webových aplikací Alexander Galba Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky nám. W. Churchilla 4 130 67 Praha 3 Česká republika e-mail: [email protected] Abstrakt: Webové aplikace jsou dnes pro mnoho podniků a organizací hlavním komunikačním nástrojem s jejich okolím. Velká část (ne-li většina) webových aplikací je dostupná přes Internet komukoliv. Technologie, které webové aplikace používají, poskytují případným útočníkům možnost získat neautorizovaný přístup do informačních systémů organizací a podnikatelských subjektů, se kterými jsou dnes webové aplikace často úzce spojeny. Kontrola bezpečnosti webových aplikací je proto nezbytnou součástí snižování potenciálního bezpečnostního rizika provozování celého informačního systému. Klíčová slova: Webová aplikace, bezpečnost, bezpečnostní riziko, kontrola bezpečnostních rizik, nástroje kontroly Abstract: Web applications are today for many businesses and organizations the main communication tool with their surroundings. A large part (if not most) of web applications is available via the Internet to anyone. Technologies that use web applications, provide potential attackers to obtain unauthorized access to information systems with which web applications are today closely linked. Web application security is a necessary part of reducing potential security risks of the whole information system. Keywords: Web application, security, security risk, security risk control, control tools

1. Úvod Webové aplikace se staly nezbytnou součástí informačních systémů mnoha organizací a podnikatelských subjektů. Dnešní webové aplikace již nejsou statickými "html stránkami" jako v minulosti, ale komplexními aplikacemi, které jsou integrální součástí informačních systémů. Vzhledem k technologiím, které webové aplikace používají, jsou velmi často vytvářeny a dodávány na klíč zákazníkům, subjekty menší a střední velikosti, které nejsou příliš erudované v používání bezpečnostních principů tvorby aplikací. Výsledná aplikace pak nemusí splňovat standardy bezpečnosti zákazníka. Webová aplikace je ze své podstaty síťovou aplikací, dostupnou v rámci intranetu široké škále uživatelů anebo v rámci internetu dostupná komukoliv ve světě. Proto není dobře možné zajistit bezpečnost použití aplikace vnějšími opatřeními, jak je tomu u stand-alone aplikací anebo aplikací používanými pouze uvnitř organizace, jako například instalace pouze na dedikovaná zařízení, přístup k aplikaci pouze určeným jedincům anebo řízení přístupu k aplikaci v rámci domény apod. Náklady spojené s eventuální ztrátou dat anebo neautorizovaným přístupem do informačního systému (dále jen IS) přes webovou aplikací již nejsou zanedbatelné. Dle Ponemon Institute dosáhly v roce 2010 sumy 7.2M USD (Ponemon, L.,2011). V další zprávě z roku 2011 100

SYSTÉMOVÁ INTEGRACE 4/2012

Nástroje pro kontrolu bezpečnosti webových aplikací

uvádí Ponemon Institute, že u 64% respondentů jejich výzkumu došlo za posledních 24 měsíců k 1 až 10 úspěšným útokům hackerů na jejich webové aplikace.(Ponemon Institute, 2011) Kontrola bezpečnosti webových aplikací je proto nezbytnou součástí snižování potenciálního rizika provozování celého informačního systému.

2. Nástroje pro kontrolu bezpečnosti. Webové aplikace tvoří dnes komplexní systém využívající technologií a služeb většiny komponent IS. Typicky je kód webové aplikace provozován současně na webových, databázových a aplikačních serverech. Zároveň je část kódu a informací dopravována prostřednictvím internetu na stranu uživatele do prostředí které buď není možné ovlivnit vůbec a nebo ho lze ovlivnit jen zčásti. Taková komplexnost obsahuje mnoho bezpečnostních hrozeb, které použitím tradičních postupů pro ochranu sítí a aplikací nelze dostatečně ošetřit. Identifikace potencionálních hrozeb v tak variabilním prostředí není triviální záležitostí. Identifikací bezpečnostních rizik webových aplikací se zabývá mimo jiné i organizace OWASP (www.owasp.org). Tato organizace zveřejňuje seznam bezpečnostních rizik včetně pořadí jejich důležitosti, které webové aplikace obsahují. Pro ověření bezpečnosti webové aplikace lze použít více postupů. V současnosti lze tyto postupy rozdělit do následujících kategorií: 1. postupy doporučené tvůrci a dodavateli webových technologií 2. postupy vycházející z metod auditu IS 3. kontrolní seznamy 4. automatizované nástroje První dvě kategorie obsahují komplexnější nástroje pro zajištění bezpečnosti webových aplikací, včetně ověřených návodů a postupů týkající se celého životního cyklu webové aplikace a technologických doporučení pro infrastrukturu. Kategorie 3. a 4. obsahují postupy jednodušeji aplikovatelné a můžou sloužit k prověření bezpečnosti webové aplikace před rozhodnutím zda použít komplexnější prověření z kategorie 1. nebo 2. Všechny nástroje minimálně pokrývají rizika uvedené v předchozí kapitole. Postupy doporučené tvůrci a dodavateli webových technologií. Postupy kontroly webové aplikace řazené do této kategorie jsou vytvářeny technologickými společnostmi mající většinou bohaté zkušenosti s tvorbou aplikací. Postupy zahrnují i infrastrukturní okolí webové aplikace a proto jejich doporučení jsou zárukou zajištění vysokého stupně bezpečnosti. Pro lepší porozumění procesů odehrávajících se při provozu webové aplikace většinou tyto postupy nahlížejí na webovou aplikaci pomocí předem definovaných pohledů (obrázek 1 a 2). V případě, že lze ovlivnit celý životní cyklus webové aplikace jsou tyto pohledy definované pro jednotlivé fáze životního cyklu. Příkladem této kategorie nástrojů je postup společnosti Microsoft (Microsoft, 2004) a IBM (IBM, 2007). Oba tyto postupy jsou reprezentanty komplexního systémů pravidel a doporučení pro zajištění bezpečného provozu webové aplikace.


101

Alexander Galba

. Obrázek 1 Příklad náhledů společnosti Microsoft (Microsoft,2004)

Obrázek 2 Příklad náhledu společnosti IBM (IBM, 2007) Celý proces zabezpečení se dělí na jednotlivé kroky aplikované na jednotlivé úrovně pohledu. Výsledkem takového postupu je seznam kontrolních kroků a doporučení v rámci jednotlivých pohledů nebo vrstev. Následující seznam uvádí seznam kontrolních bodů dle vrstev znázorněných v obr. č. 2 Globální hledisko o Obecná doporučení Transakční hledisko o zásady kódování o ochrana hodnot parametrů o ochrana komunikace 102



o o o

kontrola dynamických stránek ochrana HTTP hlaviček aplikace standardů

Relační hledisko o ochrana ověřovacího procesu o použití dostatečných kryptografických klíčů o automatické ukončování relací o zabezpečení a ochrana toku dat Aplikační hledisko o rozdělení veřejného a privátního prostoru o ochrana vstupních bodů o použití šifrování o ochrana mezipaměti Hledisko celkového prostředí aplikace o ochrana produkčních serverů o nastavení DMZ Hledisko nástrojů třetích stran o bezpečné nastavení parametrů o nastavení procesů aplikace oprav Konkrétní doporučení jsou pak obsahem jednotlivých bodů. Podrobnější informace včetně konkrétních doporučení lze najít v dokumentu (IBM, 2007). Výhodou nástrojů doporučených výrobci a dodavateli webových technologií je jejich detailní znalost dané technologie a prostředí v kterém se technologie využívá. Nevýhodou může být cena provedení takové kontroly popřípadě problematika použití pro technologie jiných výrobců a dodavatelů. Postupy vycházející z metod auditu IS. Audit IS v sobě zahrnuje i metody auditu aplikací provozovaných v IS, webové aplikace nevyjímaje. U webových aplikací je nutno zohlednit při auditu určité odlišnosti jako například dostupnost aplikace přes internet a procesy auditu tomu přizpůsobit. Vhodným příkladem je systém CobiT (Control objectives for information and related technology). CobiT je souhrn metod, doporučení a postupů vytvořený organizací ISACA (Information Systems Audit and Control Association) s cílem nabídnout společnostem využívajícím informační a komunikační technologie (dále jen ICT) ucelený koncept pro efektivní harmonizaci jimi stanovených cílů s funkcionalitou používaných IS. CobiT Security Baseline (dále jen CSBL) je obecný rámec zaměřený na proces kontroly bezpečnosti IS anebo jejich částí. Definuje 44 základních kontrolních bodů v rámci všech domén navázaných na 20 bezpečnostních procesů, na jejíž ověření by se měla organizace soustředit při auditu bezpečnosti IS nebo jeho části. CSBL nahlíží na bezpečnost IS z perspektivy definovaných uživatelských rolí. CSBL lze aplikovat na životní cyklus software tvořený na míru, což je případ většiny webových aplikací. CSBL pokrývá všechny fáze životního cyklu tvorby a provozu webové aplikace (dále jen SDLC - software development life cycle) od záměru, definice požadavků, vytvoření návrhu, specifikace funkcionality, vývoje, testování, implementace, provozu až po zánik. Obrázek č. 3 znázorňuje rozdělení jednotlivých kontrolních kroků CSBL v rámci domén CobiT na SDLC. Podrobnější aplikaci SYSTÉMOVÁ INTEGRACE 4/2012

103

Alexander Galba

jednotlivých procesů znázorněných na webové aplikace je možné nalézt například v článku Colina Watsona (Watson, C., 2009). Kontrola bezpečnosti webových aplikaci prostřednictvím procesů a metod auditu IS pokrývá i širší kontext aplikace a proto je vhodným nástrojem pro vyloučení bezpečnostních rizik. Výhodou kontroly použitím metod auditu IS je začlenění do standardizovaných procesů souvisejících s auditem IS a tím i posuzování bezpečnostních rizik z celkového kontextu použití IS. Nevýhodu může být cena takového auditu.

Obrázek 3 Kroky CSBL dle domén a fází SDLC (Watson, C., 2009). Kontrolní seznamy. Webové aplikace jsou často provozované mimo infrastrukturu vlastní organizace a použití některých metod výše uvedených není v praxi možné. Kontrolní seznamy jako nástroj kontroly bezpečnostních rizik webové aplikace lze v takových situacích využít. Jejich použití lze vyžadovat již jako součást dokumentace při tvorbě webové aplikace na zakázku a nebo jako součást dokumentace při koupi již hotových webových aplikací. Kontrolní seznamy se především zaměřují na potencionální rizika samotné webové aplikace a méně nebo vůbec nezohledňují bezpečnostní rizika dalších souvisejících komponent. Příkladem je následující seznam:

104



Certified Secure Basic Web Application Audit Checklist (Certified, 2010) 1.0

Multi-system Services

1.1

If proxy functionality is used, each request must be rewritten or validated

2.0

Design

2.1

Only the user interface must be directly accessible by users

3.0

Information Disclosure

3.1

Error messages must be generalized efore being presented to the user

3.2 3.3

Debug functionality must not be available to normal users The robots.txt must not provide any sensitive information about the system

3.4

The document root must not contain extraneous files

4.0

Privacy and Confidentiality

4.1

Sensitive information must be transmitted encrypted

4.2

Sensitive information must not be stored in cookies

4.3

Sensitive information must be protected using anti-caching headers

5.0

Integrity

5.1

Session related information must be stored at the server-side

6.0

Authentication and Authorization

6.1

Authentication must be performed at the server side

6.2

Authentication must be performed for each privileged request

6.3

Authentication and authorization must not be based on obscurity

6.4

Authentication must not be based on the knowledge of a secret URL

6.5

Authorization must not be based of the knowledge of a identifier

6.6

The old password must be provided when choosing a new password

6.7

Authentication failures must always result in the same log message

6.8

No default, test or temporary user accounts must exist

6.9

Password brute forcing must be prevented

6.10 6.11

Username enumeration must be prevented A denial of service using automatically locked accounts must be prevented

7.0

User Input

7.1

User input must never be decoded more than once

7.2

User input must be encoded before it is used in path/filenames

7.3

User input must be encoded before it is used in SQL commands


105

Alexander Galba

7.4

User input must be encoded before it is used in XML documents

7.5

User input must be encoded before it is used in XPath queries

7.6

User input must be encoded before it is used in HTML output

7.7

User input must be encoded before it is used in LDAP commands

7.8

User input must be encoded before it is used in HTTP headers

7.9

User input must be encoded before it is used in XSL(T) input/output

7.10

User input must be encoded before it is used in system commands

7.11

User input must be encoded before it is used in resource identifiers

7.12

User input must be encoded before it is used in “eval” functions

7.13

User input must be encoded before it is used in regular expressions

8.0

XML

8.1

Untrusted XML External Entities must not be parsed or evaluated

8.2

Untrusted XML External DTDs must not be parsed or evaluated

9.0

File Upload

9.1

Uploaded files must never be “executed” or “evaluated”

9.2

A conservative size limit must be enforced on uploaded files

10.0

E-mail

10.1

E-mail functionality must be protected against automated spamming

11.0

Secure Sessions

11.1

Session-ids must be generated with sufficient entropy

11.2

User generated session-ids must be rejected

11.3

Session-cookies must be transmitted via HTTPS

11.4

The secure flag must be set on the session cookies

11.5

The httponly flag must be set on the session cookies

11.6

Sessions must be revoked if the session-id is not received via HTTPS

11.7

Data mutation must be performed using POST requests

11.8

A session-bound token must be validated for each POST request

12.0

Cryptography

12.1

Only widely accepted cryptographic methods must be used

13.0

Miscellaneous

13.1

Application or setup specific probléme

Jednotlivé body kontrolního seznamu pak můžou být rozpracovány do podrobnějších doporučení a pravidel směřujících k odstranění nebo minimalizaci příslušného rizika.

106



Výhodou kontrolních seznamů je jejich jednodušší a pravděpodobně levnější použití. Nevýhodou je užší zaměření, nezohledňující celé prostředí webové aplikace. Automatizované nástroje Poslední kategorii představují automatizované nástroje pro kontrolu bezpečnosti webových aplikací. Jedná se o software zaměřený na kontrolu webových aplikací. Výhodou těchto nástrojů je možnost použití i méně erudovanými uživateli a možnost použití na aplikace dostupné jen přes internet. Většina automatizovaných nástrojů kontroluje rizika nejen samotné aplikace ale i webového prostředí (webového serveru), popřípadě doplňkových služeb s webovou aplikací souvisejících. Automatizované nástroje lze získat ve formě placené licence ,volně šířené licence anebo formou SaaS. Jeden se seznamů takových nástrojů lze nalézt na stránkách Web Application Security Consortium (http://projects.webappsec.org). Uživatelské rozhraní těchto nástrojů může korespondovat například s rozhraním produktu společnosti Acunetix (www.acunetix.com) (obrázek č. 4)

Obrázek 4 úvodní dialog aplikace Acunetix Web Vulnerability Scanner (autor) Automatizované nástroje obsahují parametry jejíž nastavení ovlivňuje schopnost odhalit bezpečnostní rizika webové aplikace. Autor tohoto textu nenalezl nějaké hodnocení automatizovaných nástrojů ale ze zkušenosti lze doporučit placené nástroje, které většinou v licenci zahrnují i technickou podporu. Důležitým momentem použití automatizovaných nástrojů je zhodnocení výsledku. Nakolik tyto nástroje jako jediné umožňují kontrolu rizik bez spolupráce s odborníky mohou zjištěné výsledky být nevypovídající a nebo zavádějící. V obrázku č.5 je znázorněn výsledek kontroly konkrétní webové aplikace. Upozornění na 63 problematických míst v této aplikaci se 1 po podrobnějším náhledu na aplikaci ukazují jako nerizikové

1

uvedená rizika se týkají vyhledávání podle klíčových slov , kde variabilita a možná změna ze strany uživatele je žádoucí SYSTÉMOVÁ INTEGRACE 4/2012

107

Alexander Galba

Výhodou automatizovaných nástrojů je jednoduchost jejich použití a možnost kontroly v podstatě čehokoliv co je dosažitelné přes Internet. Nevýhodou může být nedostatečné nastavení parametrů kontroly a schopnost interpretace získaných výsledků.

Obrázek 5 Zobrazení výsledků kontroly Acunetix Web Vulnerability Scanner-u webové aplikace www.mojerezervace.cz (autor) 108



3. Závěr Webové technologie, včetně jejich okolí, procházejí neustálým dynamickým vývojem. Při tvorbě webových aplikací je využíváno velké množství nestandardizovaných technologií (Flash, Silverlight, XUL a další). Tato situace zvyšuje bezpečnostní riziko neautorizovaného použití webové aplikace a přístupu do IS organizací. Každý nástroj pro kontrolu bezpečnosti webové aplikaci uvedený v jednotlivých kategoriích má svoje výhody a nevýhody. Tak jak se vyvíjejí webové technologie lze očekávat i vývoj nástrojů pro kontrolu jejich bezpečnosti. Bude zajímavé sledovat jak se budou ve světě Internetu slaďovat proudy podporující bohatost poskytovaných služeb a bezpečnostní standardy, které většinou působí omezujícím vlivem.

Seznam použitých zdrojů Certified Secure (2010). Certified Secure Basic Web Application Audit Checklist [online] [náhled 2012-03-26]. Dostupné z https://www.certifiedsecure.com/download/inline/26234 IBM, (2007)A layered approach to delivering security-rich Web applications. [online]. [náhled 2012-04-21]. Dostupné z: ftp://ftp.software.ibm.com/software/rational/web/whitepapers/r_wp_securityrichwebapp s.pdf ISACA (2007) COBIT Security Baseline: An Information Security Survival Kit, 2nd Edition. 2007 [online].[náhled 2012-03-26]. Dostupné z: http://www.isaca.org/KnowledgeCenter/Research/ResearchDeliverables/Pages/COBIT-Security-Baseline-AnInformation-Security-Survival-Kit-2nd-Edition1.aspx Microsoft, (2004), Improving Web Application Security: Threats and Countermeasures. [online]. s. 833 [náhled 2012-04-21]. Dostupné z: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=1330 Microsoft (2005),Security Checklist: ASP.NET 2.0 2005 [online]. [náhled 2012-03-26]. Dostupné z: http://msdn.microsoft.com/en-us/library/ff648269.aspx Ponemon, Larry;(2011) Cost of Data Breach Climbs Higher, Ponemon Institute, USA [online].náhled [2012-03-26]. Dostupné z: www.ponemon.org/blog/post/cost-of-a-databreach-climbs-higher Ponemon, Institute, (2011) State of Web Application Security. [online]. [2012-03-26]. Dostupné z: http://www.barracudanetworks.com/ns/downloads/White_Papers/Barracuda_Web_Ap p_Firewall_WP_Cenzic_Exec_Summary.pdf Watson, Colin (2009) CobiT Security Baseline Applied to Business Web Application 2009 [online]. s. 5 [2012-03-26]. Dostupné z: http://www.isaca.org/Journal/PastIssues/2009/Volume-4/Pages/COBIT-Security-Baseline-Applied-to-Business-WebApplications.aspx JEL: L86, M15


109

Nástroje pro kontrolu bezpečnosti webových aplikací

Recommend Documents