2. 2
Agenda
• Bezpečnost?
• Základní pojmy
• Autentizační mechanismy
• Nejčastější chyby v zabezpečení
• Logy
• Pravidla pro vytváření bezpečného kódu
• Internet, doporučená literatura
• Závěr
3. 3
O čem přednáška nebude!
• O obecných bezpečnostních metodikách
• O fyzickém přístupu osob k počítačům, serverům, úložištím dat apod.
• O pravidlech, kde se mají uskladňovat zálohovaná data
• O tom, co je např. redundantní zdroj, geo-
cluster, rootkit, backdoor, nebudeme řešit problematiku firewallů, antiviry
apod.
• O hodnocení rizik, jak se taková analýza provádí
• O síle bezpečnostních mechanismů, klíčů, hesel atd.
• O zátěžovém testování aplikací (MS TFS, HP LoadRunner, JMeter a spol.)
• O stupních zabezpečení OS (Common Criteria)
• O právní a ekonomické stránce bezpečnosti
• O sociálním inženýrství (přečtěte si Kevina Mitnicka )
• Problematika bezpečnosti je velice komplexní oblast, proto se budeme na
přednášce věnovat jen její malé části
4. 4
O čem přednáška bude!
• Na co si dát z bezpečnostního hlediska pozor při
návrhu, programování, testování, konfiguraci a provozu aplikace
• Řada bezpečnostních „incidentů“ je způsobena chybou v aplikaci, její
špatnou konfigurací nebo nastavením provozního prostředí
• Toto všechno lze relativně jednoduše ovlivnit!
5. 5
Co byste měli vědět o bezpečnosti?
• Bezpečnost je nikdy nekončící proces!
• 100% spolehlivé zabezpečení IS neexistuje, je nutné počítat se selháním!
• Je obtížné připravit aplikaci na každý potencionální útok
• Nejslabším článkem každého IS je obvykle jeho uživatel
• Zabezpečení musí být integrální součástí základního návrhu systému!
• Úroveň (míra) zabezpečení vždy ovlivňuje výslednou cenu aplikace
• Analýza bezpečnostních rizik (např. dle ISO) se proto provádí ve spolupráci
se zadavatelem (zákazníkem)
• Nejcennější částí IS jsou obvykle uložená data!
• I chybná implementace bezpečnostních pravidel je lepší než žádná!
• Dejte si pozor na „vnitřního“ nepřítele! Je jednodušší přesvědčit někoho
s vnitřním oprávněním, než to všechno dělat sám zvenku…
6. 6
Programátorský pud sebezáchovy – základní pravidla
• Nikdy nevěřte datům od klientů!
• Udělujte pouze nejnutnější přístupová práva, více úrovní = více hesel
• Vždy používejte nejjednodušší řešení (minimalismus)
• Nikdy nezakládejte bezpečnost na utajení!
• Chraňte citlivé údaje (např. šifrováním), neveřejné informace umístěte
mimo veřejnou oblast
• Instalujte jen nejnutnější SW
• Hlídejte si bezpečnostní díry v používaném SW
• Přesuňte weby na nesystémový disk
• Sledujte logy a statistiky
7. 7
Agenda
Bezpečnost?
• Základní pojmy
• Autentizační mechanismy
• Nejčastější chyby v zabezpečení
• Logy
• Pravidla pro vytváření bezpečného kódu
• Internet, doporučená literatura
• Závěr
8. 8
Základní pojmy
• Identifikace – Kdo jsi?
• Autentizace – Proces ověření identity (jméno a heslo, certifikát apod.)…
• Autorizace – Oprávnění k použití konkrétní služby…
• SSO (Single Sign-On) – uživatel se jednou přihlásí (prokáže identitu)
a v rámci jedné relace získá přístup k různým aplikacím (běžné u tzv.
portálových služeb)
▫ Řešení obvykle využívá https, tzv. adresářové služby (např. LDAP, OIM)
a centrální Federační server, který autentizaci uživatele zajišťuje a vydává
jednotlivým aplikacím tzv. SAML token s příslušnými údaji o uživateli
▫ Vlastní autorizaci si obvykle pro každého autentizovaného uživatele zajišťuje
každá aplikace sama!
9. 9
Základní pojmy II.
• Symetrická komunikace – společný klíč pro obě strany
▫ HMAC – kontrolní součet (hash) přenášených informací se „solí“ (náhodné znaky)
▫ Není nepopiratelná (klíč je znám oběma komunikujícím stranám)
▫ Nesmí dojít ke kompromitaci klíče, pozor na „vnitřního“ nepřítele!
▫ Nezávisí na síle použitého hash algoritmu (funguje i „slabší“ MD5), jde použít GET
• Asymetrická komunikace – použití dvojice RSA klíčů (private, public)
▫ Je nepopiratelná (výjimkou je zapření doručení zprávy, nedostanu odpověď)
▫ Mnohem bezpečnější způsob komunikace, ale přenáší se více dat (certifikáty)
▫ Je nutné dobře zabezpečit úložiště privátních klíčů, nelze použít metodu GET
• Digitální certifikát – datová struktura identifikující jejího držitele při el.
komunikaci. Bývá uložen buďto v souboru nebo na HW zařízení. Je určen
k podepisování a šifrování dat. Podobu certifikátů stanovuje norma X.509
• PKI (Public Key Infrastructure) – prostředí, které umožňuje ochranu
informačních systémů, elektronických transakcí a komunikace
▫ Zahrnuje veškerý software, technologie a služby, které využívají šifrování
s veřejným a privátním klíčem (podpis ve formátu PKCS7)
10. 10
Agenda
Bezpečnost?
Základní pojmy
• Autentizační mechanismy
• Nejčastější chyby v zabezpečení
• Logy
• Pravidla pro vytváření bezpečného kódu
• Internet, doporučená literatura
• Závěr
11. 11
Autentizační mechanismy
• Cílem je zajistit všem oprávněným uživatelům bezpečný přístup k poskytovaným
službám a informacím
• V prostředí webových aplikací (IS) jsou používány nejrůznější autentizační
mechanismy >> využívají se v nich jména + hesla, adresářové
služby, certifikáty, PINy, biometriky apod.
• „Bezpečný přístup“ zahrnuje např.:
▫ Ověření identity uživatele žádajícího o přístup
▫ Autorizaci (oprávnění) tohoto uživatele
▫ Bezpečný (šifrovaný, SSL) přenos komunikace mezi uživatelem a serverem
▫ Integritu předávaných informací mezi komunikujícími stranami
• Velmi populární a účinné jsou v současné době autentizační mechanismy založené
na PKI, kdy každý uživatel (a služba) mají vydán vlastní certifikát veřejného klíče
podepsaný důvěryhodnou certifikační autoritou
• http://www.ics.muni.cz/zpravodaj/articles/522.html
12. 12
Autentizační mechanismy v .NET
Basic Digest NTLM Kerb Certs Forms Passport
Není nutno vytvářet účet v AD Ne Ne Ne Ne A/N Ano Ano
Možnost předat dál (delegovat) Ano Ne Ne Ano A/N Ano Ano
Nezávislé na OS/prohlížeči klienta Ano Ne Ne Ne Ano Ano Ano
Heslo se přenáší šifrovaně Ne Ano Ano Ano Ano Ne Ano
Vhodné pro Internet Ano Ne Ne Ne Ano Ano Ano
Vhodné pro intranet Ano Ano Ano Ano Ano Ne Ne
Michal A. Valášek – přednáška „ASP.NET Security“, http://www.aspnet.cz
13. 13
Agenda
Bezpečnost?
Základní pojmy
Autentizační mechanismy
• Nejčastější chyby v zabezpečení
• Logy
• Pravidla pro vytváření bezpečného kódu
• Internet, doporučená literatura
• Závěr
14. 14
Potencionálně slabá místa v aplikaci
• Klient
▫ Webový prohlížeč (bugy, podsouvání kódu)
• Komunikace
▫ Použité protokoly,
▫ Odposlech komunikace,
▫ Přesměrování komunikace,
▫ Slabé šifrování
• Webový server
▫ Bugy, konfigurace, logy
• Aplikace a data
▫ Autentizace, oprávnění, řízení přístupu, validace vstupů a výstupů, manipulace s databází
• http://www.slideshare.net/DCIT/bezpenos-webovch-aplikci
15. 15
Nejčastější chyby v zabezpečení webových aplikací
• „The top 10 reasons Web sites get hacked“ – Jon Brodkin (InfoWorld.com)
http://www.infoworld.com/article/07/10/05/Top-10-reasons-Web-sites-get-hacked_1.html
http://www.owasp.org/index.php/Top_10_2007
https://www.owasp.org/index.php/Top_10_2010-Main
1. Cross Site Scripting (XSS) *
2. Chyby umožňující útoky typu SQL/Script injection *
3. Provedení škodlivého souboru (typu exe)
4. Nechráněný přímý odkaz na objekt
5. Vnucený požadavek (Cross-Site Request Forgery, CSRF) *
6. Únik informací a nesprávné ošetření chyb *
7. Narušená správa autentizace a chráněných komunikací
8. Nezabezpečené uložení kryptografických dat
9. Nechráněná komunikace
10.Nepodařený zákaz přístupu na URL
16. 16
Nejčastější chyby v zabezpečení webových aplikací II.
• Nekontrolovaný vstup dat od uživatelů *
• Nedostatečná vnitřní kontrola (uživatelé, Broken access control, integrace…)
• Přetečení vyrovnávací paměti (Buffer Overflow)
• Nezabezpečené úložiště dat, přístup do databáze
• Denial of Service (DoS) *
• Clickjacking (útok překrýváním vizuálních vrstev aplikace)
• Nezabezpečená konfigurační správa *
• Nevyužívání logů *
• Poznámka: Velmi častý je kombinovaný útok na slabě zabezpečená místa aplikace!
• http://zdrojak.root.cz/clanky/prehled-utoku-na-webove-aplikace/
• http://www.sectheory.com/clickjacking.htm
17. 17
Nekontrolovaný vstup dat od uživatelů
• Nikdy nevěřte vstupním datům od uživatelů!
• Kdokoli může poslat jakákoliv data
• Chyba (aplikace, uživatele), neznalost, zlý úmysl
Obrana
• Před vlastním zpracováním vstupních dat provádět jejich důslednou validaci, např.:
▫ Přišlo to, co očekávám?
▫ Odpovídají typy proměnných?
▫ Co délka řetězců?
▫ Jsou zaslané hodnoty přípustné (číselníky)?
▫ Nebyl zaslán nějaký nebezpečný obsah (kolizní znaky, SQL příkazy)?
• Validaci (kontrolu) vstupních dat lze provádět na straně klienta (tady můžu)
a na straně serveru (a tady musím!)
18. 18
Vkládání neautorizovaného kódu (Script/SQL Injection)
• Webová aplikace používá zasílané parametry k přístupu na externí systémy
nebo k operačnímu systému.
• Pokud útočník dokáže tyto parametry pozměnit (např. SQL dotaz) a připojit
vlastní kód, externí systém tyto příkazy spustí s oprávněními serveru.
Obrana
• Striktní typovost dat, validátory, regulární výrazy ve filtrech, HTML
encoding, kontrola vstupu i výstupu, používání parametrů pro vkládání do SQL
příkazů
• „Závadný obsah“ se do aplikace může dostat nejen ze strany uživatele
(formulář), ale i prostřednictvím integrovaných aplikací třetích stran, počítejte
s tím!
http://cs.wikipedia.org/wiki/SQL_injection
http://www.pooh.cz/a.asp?a=2012768
http://digiweb.ihned.cz/c4-10122900-19732020-i00000_d-sql-injection-princip-a-ochrana
http://php.vrana.cz/obrana-proti-sql-injection.php
http://videoarchiv.altairis.cz/Entry/11-sql-injection.aspx
http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/
19. 19
XSS (Cross Site Scripting)
• Webová aplikace může být použita jako mechanismus pro přenesení útoku přímo
do internetového prohlížeče uživatele >> pošle mu „závadný“ kód, který se
v prohlížeči interpretuje.
• Úspěšný útok může odhalit přihlašovací údaje uživatele, umožnit útok
na uživatelův počítač nebo podvrhnout obsah stránky k oklamání uživatele.
• Vložený skript (může být i externí) má přístup ke cookies a přes DOM i k obsahu
stránky, v jejímž kontextu běží!
Obrana
• Validace vstupních dat, HTML encoding, kontrola výstupů na stránku apod.
http://cs.wikipedia.org/wiki/XSS
http://stoyan.cz/hacking-xss/
http://ha.ckers.org/xss.html
20. 20
Vnucený požadavek (Cross-Site Request Forgery, CSRF)
• Webový trojský kůň, provádí se skrytě na pozadí
• Zfalšování HTTP požadavku, např. vložením skriptu do tagu pro obrázek apod.
• Nepozorovaně provádí pod identitou uživatele, který na odkaz kliknul, nějakou skrytou
a většinou nepříjemnou činnost
• Moc se o tomto druhu útoku neví… povědomost už se poslední době zlepšila
Obrana
• Důsledná kontrola veškerých vstupů a výstupů, kontrola hlavičky HTTP REFERRER
(odkud požadavek přišel >> není 100% = spoofing), všechny formulářové údaje předávat
metodou POST.
http://en.wikipedia.org/wiki/CSRF
http://zdrojak.root.cz/clanky/co-je-cross-site-request-forgery-a-jak-se-branit/
http://php.vrana.cz/cross-site-request-forgery.php
http://www.soom.cz/index.php?name=articles/show&aid=382
http://www.owasp.org/index.php/Top_10_2007-A5
http://zdrojak.root.cz/clanky/html5-nova-bezpecnostni-rizika/
21. 21
Únik informací, nesprávné ošetřování chyb
• Útočník se úmyslně pokouší vyvolávat chyby, které aplikace neošetřuje korektně
• Díky informacím o chybě se může dostat k detailním informacím o celém
systému, které lze následně zneužít >> získat „citlivé“ informace, zakázat celou
službu, obejít bezpečnostní mechanismus nebo způsobit pád serveru
Obrana
• Validace vstupních dat
• Důsledně ošetřovat a testovat chybové stavy >> používat výjimky!
• Nevypisovat chybová hlášení tzv. „z výroby“, ale upravit je tak, aby z nich nebylo
možné získat informace kompromitující aplikaci
• Dokumentovat nastalé chyby do logu a průběžně provádět jejich kontrolu!
http://www.owasp.org/index.php/Top_10_2007-A6
22. 22
DoS útok (Denial of Service)
• Útočník může přetížit systém samostatně legálními požadavky >> další oprávnění
uživatelé nemohou službu nadále používat nebo k ní přistupovat
• Pro distribuované DoS útoky (DDoS) se používají sítě tzv. botů >> atak probíhá
z několika stovek nebo tisíců počítačů najednou
Obrana
• Jsou-li příčinou chyby v aplikaci, lze je odstranit
• Při útoku z jednoho místa lze použít blokování IP adresy
• Jinak 100% spolehlivá ochrana neexistuje, zvláště u distribuovaných DDoS útoků
je obrana velmi obtížná
http://cs.wikipedia.org/wiki/DDoS
http://www.lupa.cz/serialy/utoky-typu-dos/
http://www.zive.sk/default.aspx?section=44&server=1&article=250832
http://www.root.cz/zpravicky/internet-byl-napaden-silou-40-gbps
http://www.viruslist.com/en/analysis?pubid=204792068
23. 23
Nezabezpečená konfigurační správa
• Velké konfigurační nároky na server (OS + instalovaný SW) mohou mít špatný vliv
na zabezpečení webové aplikace
• Mnoho konfiguračních možností ovlivňuje i bezpečnost aplikace v případě
špatného nastavení
Více možností >> více chyb >> více bezpečnostních děr!
Obrana
• Pečlivá (přehledná a zdokumentovaná) konfigurace prostředí
• Důsledná eliminace výchozích oprávnění, účtů a hesel
• Instalujte jen nutný SW!
• Přístup ke konfiguraci mají mít pouze povolané osoby s vlastními účty (vnitřní
nepřítel)
• Sledování změn v konfiguračních souborech, např. systémem pro řízení konfigurace
(správu zdrojového kódu, verzování)
• http://www.aspnet.cz/articles/305-sifrovani-konfiguracnich-sekci-v-asp-net
24. 24
Agenda
Bezpečnost?
Základní pojmy
Autentizační mechanismy
Nejčastější chyby v zabezpečení
• Logy
• Pravidla pro vytváření bezpečného kódu
• Internet, doporučená literatura
• Závěr
25. 25
Logy
• Práce s logy je nesmírně důležitá!
• Logovat lze v IS téměř cokoliv a kdykoliv (vývoj, testování, provoz)
• Při vhodném nastavení pravidel jsou logy výborným pomocníkem při monitorování
aktuálních nebo možných budoucích nedostatků v zabezpečení aplikace
• Je vhodné zamezit neautorizované manipulaci s logy (např. elektronickým podpisem)
Časté chyby při správě logů
• Logy nejsou používány
• Logy jsou používány, ale nejsou prohlíženy
• Logy jsou ukládány na příliš krátkou dobu
• Jsou upřednostněny jen některé logy
• Jsou ignorovány logy aplikací
• Jsou prohlíženy jen ty logů, kde víme, že jsou problémy
http://www.infosecwriters.com/text_resources/pdf/Six_Mistakes_of_Log_Management_AChuvakin.pdf
26. 26
Agenda
Bezpečnost?
Základní pojmy
Autentizační mechanismy
Nejčastější chyby v zabezpečení
Logy
• Pravidla pro vytváření bezpečného kódu
• Internet, doporučená literatura
• Závěr
27. 27
Pravidla pro vytváření bezpečného kódu – I.
Huseby, Sverre H. – Zranitelný kód, Computer Press 2006
1. Nikdy nepodceňujte sílu protivníka!
2. Pokud mají akce vedlejší efekty, používejte pro odeslání požadavků metodu POST
3. Z hlediska serveru neexistuje bezpečný klient!
4. Nikdy nepoužívejte pro ověřování uživatele nebo pro kontrolu přístupových práv
hlavičku REFERER
5. Při přihlášení uživatele zajistěte vždy vygenerování nového identifikátoru relace!
6. Nikdy neposílejte klientům podrobná chybová hlášení!
7. Nezapomeňte identifikovat každý metaznak předávaný do subsystému
8. Metaznaky je nutno ošetřit vždy, když posíláte data do dalšího subsystému
9. Vždy, když je to možné, posílejte data odděleně od řídících informací
10. Dávejte pozor na interpretaci znaků na více úrovních
28. 28
Pravidla pro vytváření bezpečného kódu – II.
11. Snažte se ze všech sil uplatňovat mechanismus Defense in depth (současné
zabezpečení několika mechanismy)
12. Nikdy slepě nedůvěřujte dokumentaci API (např. vstupní data)
13. Zjistěte všechny zdroje, odkud data do aplikace vstupují
14. Pozor na neviditelnou bezpečnostní bariéru; nezapomeňte vždy kontrolovat
všechny vstupy
15. Při filtrování dávejte přednost whitelistingu před blacklistingem
16. Nikdy neupravujte neplatný vstup, abyste z něj udělali platný
17. Vytvářejte záznamy i na úrovni aplikací
18. Nikdy nepoužívejte pro testování zabezpečení skripty běžící na straně klienta
19. Používejte pro vstup vytvořený serverem nepřímý přístup k datům vždy, když je
to možné
20. Předávejte klientovi o vnitřním stavu co nejméně informací
29. 29
Pravidla pro vytváření bezpečného kódu – III.
21. Nepředpokládejte, že jednotlivé požadavky přicházejí v určitém pořadí
22. Provádějte filtrování všech dat, a to bez ohledu na jejich původ, předtím, než se
data zobrazí na webové stránce
23. Nevytvářejte vlastní kryptografické algoritmy, používejte existující
24. Nikdy neukládejte hesla v nešifrované podobě
25. Nikdy nepoužívejte metodu GET v souvislosti s tajnými informacemi nebo
v souvislosti s identifikátorem relace
26. Předpokládejte, že se zdrojový kód na straně serveru může ocitnout v rukou
útočníků
27. Bezpečnost není produkt, ale proces (nikdy nekončící!)
30. 30
Agenda
Bezpečnost?
Základní pojmy
Autentizační mechanismy
Nejčastější chyby v zabezpečení
Logy
Pravidla pro vytváření bezpečného kódu
• Internet, doporučená literatura
• Závěr
31. 31
Odkazy na Internetu I.
• http://crypto-world.info/
• http://www.owasp.org/ – OWASP (The Open Web Application Security Project)
• http://kryl.info/clanek/561-bezpecnostni-audit-pres-obed
• http://www.interval.cz – celá řada článků a seriálů věnovaných problematice bezpečnosti
• http://secunia.com/
• http://www.securityfocus.com/
• http://www.cert.org/
• http://kryl.info/clanek/429-top-15-bezpecnostnich-a-hackovacich-nastroju
• http://www.xssed.com/archive/special=1/
• http://www.sweb.cz/jobabroad/teorie.htm – teorie spoofingu
• http://www.zive.cz/Clanky/Eugen-Kaspersky-a-rok-2018-Pohoda-ci-beznadej/sc-3-a-
144454/default.aspx
• http://www.dbsvet.cz/view.php?cisloclanku=2008100101
• http://blog.softeu.cz/europen-bezpecnost-na-webu-2008/
32. 32
Odkazy na Internetu II.
• http://code.google.com/p/browsersec/wiki/Main – bezpečnostní omezení a problémy prohlížečů
• http://blog.synopsi.com/2009-07-23/test-ssl-certifikaty-slovenskych-a-ceskych-bank
• http://blog.synopsi.com/2009-08-11/dread-analyza-rizik-podle-microsoftu
• http://blog.synopsi.com/2009-09-25/hes-hes-zly-hacker
• http://www.slideshare.net/MedvidekPU/trendy-v-internetov-bezpenosti
• http://www.slideshare.net/synopsi/socialne-siete-navod-pre-deti
• http://www.slideshare.net/synopsi/socilne-siete-a-bezpenos – sociální sítě
• http://www.slideshare.net/synopsi/synopsi-barcamp – trendy
• http://vimeo.com/8869477 – platební karty
• http://www.lupa.cz/clanky/jak-vas-budou-na-webu-spehovat-v-novem-desetileti/
• http://zdrojak.root.cz/clanky/html5-nova-bezpecnostni-rizika/
• http://blog.synopsi.com/2010-06-15/facebook-a-clickjacking – nezabezpečený Facebook
• http://www.diit.cz/clanek/firefox-3-6-9-konecne-podporuje-zakaz-behu-stranky-v-i-frame/36935/
33. 33
Doporučená literatura
• Microsoft – Vytváříme zabezpečené aplikace v Microsoft ASP.NET,
CP Books (Computer Press) 2004
• Taylor, Art; Buege Brian; Layman Randy – Hacking bez tajemství: Java a J2EE, Computer Press
2003
• Huseby, Sverre H. – Zranitelný kód, Computer Press 2006
• Aulds, Charles – Linux – administrace serveru Apache, Grada 2003
• Pošmura, Vlastimil – Apache – Příručka správce WWW serveru,
Computer Press 2002
• Dostálek, Libor, a kol. – Velký průvodce protokoly TCP/IP – Bezpečnost, Computer Press 2003
• Mitnick, Kevin – Umění klamu, Helion 2003
• Singh, Simon – Kniha kódů a šifer, Argo, Dokořán, 2003
34. 34
Agenda
Bezpečnost?
Základní pojmy
Autentizační mechanismy
Nejčastější chyby v zabezpečení
Logy
Pravidla pro vytváření bezpečného kódu
Internet, doporučená literatura
• Závěr
35. 35
Závěr
• Je velmi důležité si uvědomit, že každá webová aplikace je potencionálním cílem pro
útočníky a může být napadena!
• Znovu: Bezpečnost je nikdy nekončící proces!
• Nic se nemá přehánět, úroveň zabezpečení by měla odpovídat charakteru aplikace
a vynaloženým nákladům. Nemá smysl utrácet více, než získáte.
• „Dobrý admin nemusí být paranoidní. Ale hodně to pomáhá.“ – Michal A. Valášek
36. 36
Souhrn
Bezpečnost?
Základní pojmy
Autentizační mechanismy
Nejčastější chyby v zabezpečení
Logy
Pravidla pro vytváření bezpečného kódu
Internet, doporučená literatura
Závěr
