Web technology, security

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