Technologies for publication on the web II Department of Information Technologies University of Hradec Králové, Czech republic

1. Bezpečnost
Mgr. Lukáš Vacek
lukas.vacek@uhk.cz
TNPW2 2015/2016

2. 2
„Dobrý admin nemusí být paranoidní.
Ale hodně to pomáhá.“ – Michal A. Valášek

3. • 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
O čem přednáška nebude? 3

4. • 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…
O čem přednáška bude? 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. • 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…
Co byste měli vědět o bezpečnosti? 6

7. • 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
Základní pravidla (programátorský pud sebezáchovy) 7

8. Základní pojmy

9. • 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!
Základní pojmy 9

10. • 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
Základní pojmy II. 10

11. • 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
Základní pojmy III. 11

12. • 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
Kryptografické operace ve webových aplikacích? 12

13. • 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
Autentizační mechanismy 13

14. • 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
Výběr autentizačního mechanismu 14

15. Nejčastější chyby v zabezpečení

16. • 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!
Potencionálně slabá místa v zabezpečení 16

17. • 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
Nejčastější chyby v zabezpečení webových aplikací I. 17

18. • 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
Nejčastější chyby v zabezpečení webových aplikací II. 18

19. • 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!)
Nekontrolovaný vstup dat od uživatelů 19

20. • 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
Vkládání neautorizovaného kódu (SQL/Script injection) 20

21. • 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
• Přednáška Michala Špačka o XSS (Youtube.com)
XSS (Cross Site Scripting) 21

22. • 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/
Vnucený požadavek (Cross-Site Request Forgery, CSRF) 22

23. • Ú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)
Únik informací, nesprávné ošetřování chyb 23

24. • Ú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)
DoS útok (Denial of Service) 24

25. • 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í)
Nezabezpečená konfigurační správa 25

26. • 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)
Logy 26

27. HTTP hlavičky

28. • 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
HTTP hlavičky 28

29. • X-XSS-Protection: 1; mode=block; report=https://
• 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í!
• Na URL v parametru report se odešle JSON (request-url a request-body) >
funguje pro Webkit a Chrome!
• Podpora IE 8+, Chrome, Safari 4+
HTTP hlavičky: XSS-Protection 29

30. • Něco jako white list adres serverů, odkud se skripty a další objekty mohou
do stránky stahovat. Pozor, CSP hlavička může být docela velká!
• Content-Security-Policy:
• default-src 'self'; načte jen zdroje (skripty, obrázky) z domény, na které je stránka
• default-src 'self'; img-src 'self' url; povolí obrázky z url domény
• default-src 'none'; všechno zakáže, a postupně to povolím
• script-src 'unsafe-inline' url; umožní inline skripty z url adresy
• frame-src url; umožní načtení iframe z url
• form-action 'self'; určuje, kam se mohou odesílat formuláře (pozor na HTML5)
• report-uri url; můžete použít i službu report-uri.io (přehledný dashboard)
• Content-Security-Policy-Report-Only: neblokuje obsah, vytváří reporty
• Podpora IE 10+, Firefox 4+ (X-Content-Security-Policy), Firefox 25+, Chrome 23+,
Opera 15+ (Content-Security-Policy), lze poslal obě hlavičky.
HTTP hlavičky: Content-Security-Policy 30

31. • 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+
HTTP hlavičky: HTTP-Only Cookie 31

32. 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
HTTP hlavičky: X-Frame-Options a X-Content-Type-Options 32

33. • 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+
HTTP hlavičky: HTTP Strict-transport-security 33

34. Pravidla pro vytváření bezpečného kódu

35. • 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
Pravidla pro vytváření bezpečného kódu – I. 35

36. • 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í
Pravidla pro vytváření bezpečného kódu – II. 36

37. • 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í!)
Pravidla pro vytváření bezpečného kódu – III. 37

38. Internetové odkazy, literatura

39. Odkazy na internetu I. 39
• 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/
• https://www.secpublica.cz/

40. Odkazy na internetu II. 40
• 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/
• http://html5sec.org/ HTML5 Security Cheatsheet
• http://www.lupa.cz/clanky/myty-o-bezpecnosti-mobilniho-bankovnictvi-jsou-nutna-dlouha-
hesla-a-sms/
• BeEF (The Browser Exploitation Framework)

41. • 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
Doporučená literatura 41

42. • 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ý
Závěr 42

43. Závěr, dotazy