TNPW2-2011-07
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

TNPW2-2011-07

  • 1,766 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,766
On Slideshare
1,704
From Embeds
62
Number of Embeds
5

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 62

http://tnpw2.blogspot.com 33
http://tnpw2.webnode.cz 22
http://www.slideshare.net 3
http://tnpw2.blogspot.cz 3
http://cms.tnpw2.webnode.cz 1

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
    2009/2010
    07 – Bezpečnost webových aplikací
    Mgr. Lukáš Vacek
    lukas.vacek@uhk.cz
  • 2. Agenda7
    • Bezpečnost?
    • 3. Základní pojmy
    • 4. Autentizační mechanismy
    • 5. Nejčastější chyby v zabezpečení
    • 6. Logy
    • 7. Pravidla pro vytváření bezpečného kódu
    • 8. Internet, doporučená literatura
    • 9. Závěr
    2
  • 10. 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í (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 KevinaMitnicka)
    Problematika bezpečnosti je velice komplexní oblast, proto se budeme na přednášce věnovat jen její malé části.
    3
    O čem přednáška nebude!
  • 11. 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!
    4
    O čem přednáška bude!
  • 12. 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…
    5
    Co byste měli vědět o bezpečnosti?
  • 13. 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.
    6
    Programátorský pud sebezáchovy – základní pravidla
  • 14. Agenda7
    • Bezpečnost?
    • 15. Základní pojmy
    • 16. Autentizační mechanismy
    • 17. Nejčastější chyby v zabezpečení
    • 18. Logy
    • 19. Pravidla pro vytváření bezpečného kódu
    • 20. Internet, doporučená literatura
    • 21. Závěr
    7
  • 22. 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 už každá aplikace sama!
    8
    Základní pojmy
  • 23. 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é umožňují využití šifrování s veřejným a privátním klíčem.
    Digitální certifikát – datová struktura identifikující jejího držitele při elektronické 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.
    9
    Základní pojmy II.
  • 24. Agenda7
    • Bezpečnost?
    • 25. Základní pojmy
    • 26. Autentizační mechanismy
    • 27. Nejčastější chyby v zabezpečení
    • 28. Logy
    • 29. Pravidla pro vytváření bezpečného kódu
    • 30. Internet, doporučená literatura
    • 31. Závěr
    10
  • 32. 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
    11
    Autentizační mechanismy
  • 33. Michal A. Valášek – přednáška „ASP.NET Security“, http://www.aspnet.cz
    12
    Autentizační mechanismy v .NET
  • 34. Agenda7
    • Bezpečnost?
    • 35. Základní pojmy
    • 36. Autentizační mechanismy
    • 37. Nejčastější chyby v zabezpečení
    • 38. Logy
    • 39. Pravidla pro vytváření bezpečného kódu
    • 40. Internet, doporučená literatura
    • 41. Závěr
    13
  • 42. „The top 10 reasons Web sites get hacked“ – JonBrodkin (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
    CrossSiteScripting (XSS) *
    Chyby umožňující útoky typu SQL/Scriptinjection *
    Provedení škodlivého souboru (typu exe)
    Nechráněný přímý odkaz na objekt
    Vnucený požadavek (Cross-SiteRequestForgery, CSRF) *
    Únik informací a nesprávné ošetření chyb *
    Narušená správa autentizace a chráněných komunikací
    Nezabezpečené uložení kryptografických dat
    Nechráněná komunikace
    Nepodařený zákaz přístupu na URL
    14
    Nejčastější chyby v zabezpečení webových aplikací
  • 43. Nekontrolovaný vstup dat od uživatelů *
    Nedostatečná vnitřní kontrola
    Přetečení vyrovnávací paměti (Buffer Overflow)
    Nezabezpečené úložiště dat, přístup do databáze
    Denial of Service (DoS) *
    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/
    15
    Nejčastější chyby v zabezpečení webových aplikací II.
  • 44. 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!).
    16
    Nekontrolovaný vstup dat od uživatelů
  • 45. 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, používání parametrů pro vkládání do SQL příkazů.
    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/
    17
    Vkládání neautorizovaného kódu (Script/SQL Injection)
  • 46. 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
    18
    XSS (Cross Site Scripting)
  • 47. 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í…
    Obrana
    Důsledná kontrola veškerých vstupů, kontrola hlavičky REFERER (odkud požadavek přišel), 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
    19
    Vnucený požadavek (Cross-Site Request Forgery, CSRF)
  • 48. Ú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
    20
    Únik informací, nesprávné ošetřování chyb
  • 49. Ú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
    21
    DoS útok (Denial of Service)
  • 50. 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í).
    22
    Nezabezpečená konfigurační správa
  • 51. Agenda7
    • Bezpečnost?
    • 52. Základní pojmy
    • 53. Autentizační mechanismy
    • 54. Nejčastější chyby v zabezpečení
    • 55. Logy
    • 56. Pravidla pro vytváření bezpečného kódu
    • 57. Internet, doporučená literatura
    • 58. Závěr
    23
  • 59. 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
    24
    Logy
  • 60. Agenda7
    • Bezpečnost?
    • 61. Základní pojmy
    • 62. Autentizační mechanismy
    • 63. Nejčastější chyby v zabezpečení
    • 64. Logy
    • 65. Pravidla pro vytváření bezpečného kódu
    • 66. Internet, doporučená literatura
    • 67. Závěr
    25
  • 68. 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
    26
    Pravidla pro vytváření bezpečného kódu – I.
  • 69. 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í
    27
    Pravidla pro vytváření bezpečného kódu – II.
  • 70. 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 straně serveru může ocitnout v rukou útočníků
    Bezpečnost není produkt, ale proces (nikdy nekončící!)
    28
    Pravidla pro vytváření bezpečného kódu – III.
  • 71. Agenda7
    • Bezpečnost?
    • 72. Základní pojmy
    • 73. Autentizační mechanismy
    • 74. Nejčastější chyby v zabezpečení
    • 75. Logy
    • 76. Pravidla pro vytváření bezpečného kódu
    • 77. Internet, doporučená literatura
    • 78. Závěr
    29
  • 79. http://crypto-world.info/
    http://www.owasp.org/ – OWASP (The Open Web ApplicationSecurity 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/
    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
    30
    Odkazy na Internetu
  • 80. Microsoft – Vytváříme zabezpečené aplikace v Microsoft ASP.NET, CP Books (Computer Press) 2004
    Taylor, Art; BuegeBrian; 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
    31
    Doporučená literatura
  • 81. Agenda7
    • Bezpečnost?
    • 82. Základní pojmy
    • 83. Autentizační mechanismy
    • 84. Nejčastější chyby v zabezpečení
    • 85. Logy
    • 86. Pravidla pro vytváření bezpečného kódu
    • 87. Internet, doporučená literatura
    • 88. Závěr
    32
  • 89. 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
    33
    Závěr
  • 90. Souhrn7
    • Bezpečnost?
    • 91. Základní pojmy
    • 92. Autentizační mechanismy
    • 93. Nejčastější chyby v zabezpečení
    • 94. Logy
    • 95. Pravidla pro vytváření bezpečného kódu
    • 96. Internet, doporučená literatura
    • 97. Závěr
    34