Your SlideShare is downloading. ×
TNPW2-2014-04
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

TNPW2-2014-04

347
views

Published on

Web technology, security

Web technology, security

Published in: Education

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
347
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. TNPW2 2013/2014 Mgr. Lukáš Vacek lukas.vacek@uhk.cz Bezpečnost
  • 2. „Dobrý admin nemusí být paranoidní. Ale hodně to pomáhá.“ – Michal A. Valášek 2
  • 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 3
  • 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, když o tom víte… 4
  • 5. Agenda • Bezpečnost? • Základní pojmy • Autentizační mechanismy • Nejčastější chyby v zabezpečení • HTTP hlavičky • Pravidla pro vytváření bezpečného kódu • Internet, doporučená literatura • Závěr 5
  • 6. 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
  • 7. Základní pravidla (programátorský pud sebezáchovy) • • • • • • • • • 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
  • 8. Základní pojmy
  • 9. Základní pojmy • Identifikace – Kdo jsi? • Autentizace – Proces ověření identity (jméno a heslo, certifikát apod.)… • Klient něco ví (heslo, PIN) • Klient něco má (kalkulátor, privátní klíč) • Klient něčím je, nebo se nějak chová (biometriky) • 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 identitě uživatele • Vlastní autorizaci si následně u každého autentizovaného uživatele zajišťuje každá aplikace sama! 9
  • 10. Základní pojmy II. • Symetrická komunikace – společný klíč pro obě strany • HMAC – kontrolní součet (hash) přenášených informací se „solí“ (sůl = 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 10
  • 11. Základní pojmy III. • 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 • Vydává ho certifikační autorita, může odvolat jeho platnost přes CRL • PKI (Public Key Infrastructure) • Prostředí pro 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) • Pozor na kompromitaci privátních klíčů >> PROBLÉM 11
  • 12. Kryptografické operace ve webových aplikacích? • V současné době nelze přímo provádět ve webových aplikacích žádné kryptografické operace (šifrování, podepisování) v JavaScriptu na straně klienta • JavaScript má problém s dostatečně bezpečným • generátorem náhodných čísel • úložištěm klíčů • a důvěryhodným doručením kryptografického zdrojového kódu • Prohlížeče podporují pouze zabezpečené spojení mezi klientem a serverem (SSL, TLS) • Občas je nutné zašifrovat data (zprávu, soubor) tak, aby je samotný server nemohl rozšifrovat… bez nějaké podpůrné aplikace to dnes nejde • Možné řešení… draft Web Cryptography API (W3C) • http://tech.ihned.cz/geekosfera/c1-60754800-webcrytoapi-sifrovani-webove-aplikace 12
  • 13. 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 • Webové aplikace používají jednoduché i více-faktorové autentizační mechanismy • Využívají se 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 (pravost) informací předávaných mezi komunikujícími stranami • Velmi populární a účinné jsou autentizační mechanismy založené na PKI, kdy každý účastník (uživatel a služba) má 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 • http://si.vse.cz/archive/proceedings/2001/autentizacni-mechanismy.pdf 13
  • 14. Výběr autentizačního mechanismu • Výběr vhodného autentizačního mechanismu závisí na celé řadě kritérií • Kdo je uživatelem? – Zaměstnanec vs. Zákazník (klient) • O jakou operaci jde? – Pasivní (čtení informace) vs. Aktivní (změna dat) • Kdo má kontrolu nad prostředím? – Provozovatel vs. uživatel vs. třetí strana • Náklady, požadavky na HW a SW • http://si.vse.cz/archive/proceedings/2001/autentizacni-mechanismy.pdf 14
  • 15. Nejčastější chyby v zabezpečení
  • 16. Potencionálně slabá místa v zabezpečení • 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 • Sítě tvoří hardware, software a velmi dlouhé dráty  • V podstatě libovolná část může selhat nebo být napadena, počítejte s tím! 16
  • 17. Nejčastější chyby v zabezpečení webových aplikací I. • The top 10 reasons Web sites get hacked – Jon Brodkin (InfoWorld.com) • The Open Web Application Security Project (OWASP) • Neziskovka zaměřená na bezpečnost • Výborný zdroj informací! • Vydává žebříčky nejčastějších chyb… Top 10 za rok 2013 • • • • • • • • Cross Site Scripting (XSS) * Chyby umožňující útoky typu SQL/Script injection * Vnucený požadavek (Cross-Site Request Forgery, CSRF) * Únik informací a nesprávné ošetření chyb * Narušená správa autentizace a session management Nezabezpečené uložení kryptografických dat Nezabezpečené úložiště dat, přístup do databáze Nechráněná komunikace 17
  • 18. 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) Nepodařený zákaz přímého přístupu k objektu Nevalidní redirect a forwarding na webovém serveru Používání komponent se známou zranitelností 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 18
  • 19. 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!) 19
  • 20. Vkládání neautorizovaného kódu (SQL/Script 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! • https://www.owasp.org/index.php/Top_10_2013-A1-Injection • http://php.vrana.cz/obrana-proti-sql-injection.php • http://videoarchiv.altairis.cz/Entry/11-sql-injection.aspx 20
  • 21. 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 načte a 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. • XSS (OWASP) • XSS Filter Evasion Cheat Sheet 21
  • 22. Vnucený požadavek (Cross-Site Request Forgery, CSRF) • • • • Webový trojský kůň, provádí se skrytě na pozadí Útok probíhá ze stránky, kterou kontroluje útočník (sociální ing.) 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 Obrana • Důsledná kontrola vstupů a výstupů, autentizační token pro formulář, kontrola hlavičky HTTP REFERRER (odkud je požadavek >> není 100% = spoofing), formulářové údaje předávat metodou POST, HTTP X-Frame-Options DENY • • • • CSRF (OWASP) 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://zdrojak.root.cz/clanky/html5-nova-bezpecnostni-rizika/ 22
  • 23. Ú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! • Information Leakage and Improper Error Handling (OWASP) 23
  • 24. 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 (není to časté), 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á • Útoky typu DoS (seriál Lupa) • http://www.root.cz/zpravicky/internet-byl-napaden-silou-40-gbps • DDoS (wiki) 24
  • 25. 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í) 25
  • 26. 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 • Pozor na Log Injection, může k němu dojít  • Six Mistakes of Log Management – Anton Chuvakin (PDF) 26
  • 27. HTTP hlavičky
  • 28. HTTP hlavičky • Do HTTP hlavičky můžu napsat skoro cokoliv! • GET url/file HTTP/1.0 HOST: nějaký kód v JavaScriptu • Kód v JS se provede na URL adrese stránky… a je malér! • Doporučení: Obalit i HTTP hlavičky serveru před výpisem na stránku přes HTMLSpecialChar funkce • • Přímému přístupu na citlivé URL adresy (/admin) lze zamezit přes tzv. port knocking. Správná sekvence klepání na porty resp. URL otevře /admin… něco se uloží do Session, a potom to jde. Jinak zobrazí kód chyby HTTP 404 • Michal Špaček o HTTP hlavičkách na DevFestu 2013 28
  • 29. HTTP hlavičky: XSS-Protection • X-XSS-Protection: 1; mode=block • Defaultně v prohlížečích vypnuto 0, • Zapnutí se pokusí XSS filtrem opravit kód stránky (jen odkazem, ne pro stored skripty!)… pozor, riziko, že tam stejně proběhne útok • Proto použijte mode=block, stránka se vůbec nezobrazí • Podpora IE 8+, Chrome, Safari 4+ 29
  • 30. HTTP hlavičky: HTTP-Only Cookie • Nemá k nim přístup JavaScript, posílají se jen mezi serverem a prohlížečem • Zapnutí v PHP session.cookie_httponly: true; • Posílání cookies jen přes zabezpečené HTTPS spojení… session.cookie_secure: true; • Podpora od IE 6 SP1+ 30
  • 31. HTTP hlavičky: Content-Security-Policy • Něco jako white list adres serverů, odkud se skripty a další objekty mohou do stránky stahovat • default-src 'none' všechno zakáže, a postupně to povolím • script-src 'unsafe-inline' url umožní inline skripty z url adresy • Podpora IE 10+, Firefox 4+ (X-Content-Security-Policy), Firefox 25+, Chrome 23+, Opera 15+ (Content-Security-Policy), lze poslal obě hlavičky. 31
  • 32. HTTP hlavičky: X-Frame-Options a X-Content-Type-Options X-Frame-Options DENY • Obrana proti CSRF útokům • Zabraňuje používání iframe pro Clickjacking útoky (průhledný frame, na který user kliká) • Podpora IE 8+, Firefox 3.6.9+, Chrome 4.1+, Safari 4+ • Video pro ASP.NET (Altaris) X-Content-Type-Options nosniff • Zakáže některým prohlížečům odhadovat typ obsahu stránky • Podpora IE 8+, Chrome 32
  • 33. HTTP hlavičky: HTTP Strict-transport-security • HTTP Strict-transport-security max-age=(parametr čas) • Přechod HTTP -> (?) HTTPS při přesměrování je rizikový • Man-in-the-middle útok (sslstrip) prohlížeč neupdatuje jako https, user si toho nevšimne • Hlavička zajistí upgrade na HTTPS ještě před 1. požadavkem • S neplatným certifikátem nepovolí pokračovat! • Je to relativně nová hlavička! • Podpora Chrome 4+, Firefox 4+, Opera 12+ 33
  • 34. Pravidla pro vytváření bezpečného kódu
  • 35. Pravidla pro vytváření bezpečného kódu – I. • Huseby, Sverre H. – Zranitelný kód, Computer Press 2006 • • • • • • • • • • Nikdy nepodceňujte sílu protivníka! Pokud mají akce vedlejší efekty, používejte pro odeslání požadavků metodu POST Z hlediska serveru neexistuje bezpečný klient! Nikdy nepoužívejte pro ověřování uživatele nebo pro kontrolu přístupových práv hlavičku REFERER Při přihlášení uživatele zajistěte vždy vygenerování nového identifikátoru relace! Nikdy neposílejte klientům podrobná chybová hlášení! Nezapomeňte identifikovat každý metaznak předávaný do subsystému Metaznaky je nutno ošetřit vždy, když posíláte data do dalšího subsystému Vždy, když je to možné, posílejte data odděleně od řídících informací Dávejte pozor na interpretaci znaků na více úrovních 35
  • 36. Pravidla pro vytváření bezpečného kódu – II. • Snažte se ze všech sil uplatňovat mechanismus Defense in depth (současné zabezpečení několika mechanismy) • Nikdy slepě nedůvěřujte dokumentaci API (např. vstupní data) • Zjistěte všechny zdroje, odkud data do aplikace vstupují • Pozor na neviditelnou bezpečnostní bariéru; nezapomeňte vždy kontrolovat všechny vstupy • Při filtrování dávejte přednost whitelistingu před blacklistingem • Nikdy neupravujte neplatný vstup, abyste z něj udělali platný • Vytvářejte záznamy i na úrovni aplikací • Nikdy nepoužívejte pro testování zabezpečení skripty běžící na straně klienta • Používejte pro vstup vytvořený serverem nepřímý přístup k datům vždy, když je to možné • Předávejte klientovi o vnitřním stavu co nejméně informací 36
  • 37. Pravidla pro vytváření bezpečného kódu – III. • Nepředpokládejte, že jednotlivé požadavky přicházejí v určitém pořadí • 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 • Nevytvářejte vlastní kryptografické algoritmy, používejte existující • Nikdy neukládejte hesla v nešifrované podobě • Nikdy nepoužívejte metodu GET v souvislosti s tajnými informacemi nebo v souvislosti s identifikátorem relace • Předpokládejte, že se zdrojový kód na serveru se může ocitnout v rukou útočníků • Bezpečnost není produkt, ale proces (nikdy nekončící!) 37
  • 38. Internetové odkazy, literatura
  • 39. 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.dbsvet.cz/view.php?cisloclanku=2008100101 http://blog.softeu.cz/europen-bezpecnost-na-webu-2008/ 39
  • 40. 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-iframe/36935/ • http://html5sec.org/ HTML5 Security Cheatsheet • http://www.lupa.cz/clanky/myty-o-bezpecnosti-mobilniho-bankovnictvi-jsou-nutna-dlouhahesla-a-sms/ 40
  • 41. 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 41
  • 42. 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. • Aby byl Internet bezpečný, musí se odpovídajícím způsobem chovat všichni… vývojáři, provozovatelé i uživatelé aplikací! • „Veřejnost začíná vnímat Internet jako rizikový prostor, což je v pořádku; její značná část však bude očekávat, že ji má ochránit nějaká státní autorita — a to v pořádku není.“ – Petr Koubský 42
  • 43. Závěr, dotazy