TNPW2-2011-07

1,380 views
1,334 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,380
On SlideShare
0
From Embeds
0
Number of Embeds
63
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

TNPW2-2011-07

  1. 1. TNPW2<br />2009/2010<br />07 – Bezpečnost webových aplikací<br />Mgr. Lukáš Vacek<br />lukas.vacek@uhk.cz<br />
  2. 2. Agenda7<br /><ul><li>Bezpečnost?
  3. 3. Základní pojmy
  4. 4. Autentizační mechanismy
  5. 5. Nejčastější chyby v zabezpečení
  6. 6. Logy
  7. 7. Pravidla pro vytváření bezpečného kódu
  8. 8. Internet, doporučená literatura
  9. 9. Závěr</li></ul>2<br />
  10. 10. O obecných bezpečnostních metodikách.<br />O fyzickém přístupu osob k počítačům, serverům, úložištím dat apod.<br />O pravidlech, kde se mají uskladňovat zálohovaná data.<br />O tom, co je např. redundantní zdroj, geo-cluster, rootkit, backdoor, nebudeme řešit problematiku firewallů, antiviry apod.<br />O hodnocení rizik, jak se taková analýza provádí.<br />O síle bezpečnostních mechanismů, klíčů, hesel atd.<br />O zátěžovém testování aplikací (JMeter a spol).<br />O stupních zabezpečení OS (Common Criteria).<br />O právní a ekonomické stránce bezpečnosti.<br />O sociálním inženýrství (přečtěte si KevinaMitnicka)<br />Problematika bezpečnosti je velice komplexní oblast, proto se budeme na přednášce věnovat jen její malé části.<br />3<br />O čem přednáška nebude!<br />
  11. 11. Na co si dát z bezpečnostního hlediska pozor při návrhu, programování, testování, konfiguraci a provozu aplikace.<br />Řada bezpečnostních „incidentů“ je způsobena chybou v aplikaci, její špatnou konfigurací nebo nastavením provozního prostředí .<br />Toto všechno lze relativně jednoduše ovlivnit!<br />4<br />O čem přednáška bude!<br />
  12. 12. Bezpečnost je nikdy nekončící proces!<br />100% spolehlivé zabezpečení IS neexistuje, je nutné počítat se selháním!<br />Je obtížné připravit aplikaci na každý potencionální útok.<br />Nejslabším článkem každého IS je obvykle jeho uživatel <br />Zabezpečení musí být integrální součástí základního návrhu systému!<br />Ú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).<br />Nejcennější částí IS jsou obvykle uložená data!<br />I chybná implementace bezpečnostních pravidel je lepší než žádná!<br />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…<br />5<br />Co byste měli vědět o bezpečnosti?<br />
  13. 13. Nikdy nevěřte datům od klientů!<br />Udělujte pouze nejnutnější přístupová práva, více úrovní = více hesel.<br />Vždy používejte nejjednodušší řešení (minimalismus).<br />Nikdy nezakládejte bezpečnost na utajení!<br />Chraňte citlivé údaje (např. šifrováním), neveřejné informace umístěte mimo veřejnou oblast.<br />Instalujte jen nejnutnější SW.<br />Hlídejte si bezpečnostní díry v používaném SW.<br />Přesuňte weby na nesystémový disk.<br />Sledujte logy a statistiky.<br />6<br />Programátorský pud sebezáchovy – základní pravidla<br />
  14. 14. Agenda7<br /><ul><li>Bezpečnost?
  15. 15. Základní pojmy
  16. 16. Autentizační mechanismy
  17. 17. Nejčastější chyby v zabezpečení
  18. 18. Logy
  19. 19. Pravidla pro vytváření bezpečného kódu
  20. 20. Internet, doporučená literatura
  21. 21. Závěr</li></ul>7<br />
  22. 22. Identifikace – Kdo jsi? <br />Autentizace – Proces ověření identity (jméno a heslo, certifikát apod.)…<br />Autorizace – Oprávnění k použití konkrétní služby…<br />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). <br />Ř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.<br />Vlastní autorizaci si obvykle pro každého autentizovaného uživatele zajišťuje už každá aplikace sama!<br />8<br />Základní pojmy<br />
  23. 23. PKI (Public Key Infrastructure) – prostředí, které umožňuje ochranu informačních systémů, elektronických transakcí a komunikace. <br />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.<br />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.<br />9<br />Základní pojmy II.<br />
  24. 24. Agenda7<br /><ul><li>Bezpečnost?
  25. 25. Základní pojmy
  26. 26. Autentizační mechanismy
  27. 27. Nejčastější chyby v zabezpečení
  28. 28. Logy
  29. 29. Pravidla pro vytváření bezpečného kódu
  30. 30. Internet, doporučená literatura
  31. 31. Závěr</li></ul>10<br />
  32. 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.<br />V prostředí webových aplikací (IS) jsou používány nejrůznější autentizační mechanismy –&gt; využívají se v nich jména + hesla, adresářové služby, certifikáty, PINy, biometriky apod.<br />„Bezpečný přístup“ zahrnuje např.:<br />Ověření identity uživatele žádajícího o přístup,<br />Autorizaci (oprávnění) tohoto uživatele,<br />Bezpečný (šifrovaný, SSL) přenos komunikace mezi uživatelem a serverem,<br />Integritu předávaných informací mezi komunikujícími stranami.<br />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. <br />http://www.ics.muni.cz/zpravodaj/articles/522.html<br />11<br />Autentizační mechanismy <br />
  33. 33. Michal A. Valášek – přednáška „ASP.NET Security“, http://www.aspnet.cz<br />12<br />Autentizační mechanismy v .NET<br />
  34. 34. Agenda7<br /><ul><li>Bezpečnost?
  35. 35. Základní pojmy
  36. 36. Autentizační mechanismy
  37. 37. Nejčastější chyby v zabezpečení
  38. 38. Logy
  39. 39. Pravidla pro vytváření bezpečného kódu
  40. 40. Internet, doporučená literatura
  41. 41. Závěr</li></ul>13<br />
  42. 42. „The top 10 reasons Web sites get hacked“ – JonBrodkin (InfoWorld.com)<br />http://www.infoworld.com/article/07/10/05/Top-10-reasons-Web-sites-get-hacked_1.html<br />http://www.owasp.org/index.php/Top_10_2007<br />CrossSiteScripting (XSS) *<br />Chyby umožňující útoky typu SQL/Scriptinjection *<br />Provedení škodlivého souboru (typu exe)<br />Nechráněný přímý odkaz na objekt<br />Vnucený požadavek (Cross-SiteRequestForgery, CSRF) *<br />Únik informací a nesprávné ošetření chyb *<br />Narušená správa autentizace a chráněných komunikací<br />Nezabezpečené uložení kryptografických dat<br />Nechráněná komunikace<br />Nepodařený zákaz přístupu na URL<br />14<br />Nejčastější chyby v zabezpečení webových aplikací<br />
  43. 43. Nekontrolovaný vstup dat od uživatelů *<br />Nedostatečná vnitřní kontrola<br />Přetečení vyrovnávací paměti (Buffer Overflow)<br />Nezabezpečené úložiště dat, přístup do databáze<br />Denial of Service (DoS) *<br />Nezabezpečená konfigurační správa *<br />Nevyužívání logů *<br />Poznámka: Velmi častý je kombinovaný útok na slabě zabezpečená místa aplikace!<br />http://zdrojak.root.cz/clanky/prehled-utoku-na-webove-aplikace/<br />15<br />Nejčastější chyby v zabezpečení webových aplikací II.<br />
  44. 44. Nikdy nevěřte vstupním datům od uživatelů!<br />Kdokoli může poslat jakákoliv data.<br />Chyba (aplikace, uživatele), neznalost, zlý úmysl.<br />Obrana<br />Před vlastním zpracováním vstupních dat provádět jejich důslednou validaci, např.:<br />Přišlo to, co očekávám?<br />Odpovídají typy proměnných?<br />Co délka řetězců?<br />Jsou zaslané hodnoty přípustné (číselníky)?<br />Nebyl zaslán nějaký nebezpečný obsah (kolizní znaky, SQL příkazy)?<br />Validaci (kontrolu) vstupních dat lze provádět na straně klienta (tady můžu) a na straně serveru (a tady musím!).<br />16<br />Nekontrolovaný vstup dat od uživatelů<br />
  45. 45. Webová aplikace používá zasílané parametry k přístupu na externí systémy nebo k operačnímu systému. <br />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.<br />Obrana<br />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ů.<br />http://cs.wikipedia.org/wiki/SQL_injection <br />http://www.pooh.cz/a.asp?a=2012768 <br />http://digiweb.ihned.cz/c4-10122900-19732020-i00000_d-sql-injection-princip-a-ochrana <br />http://php.vrana.cz/obrana-proti-sql-injection.php<br />http://videoarchiv.altairis.cz/Entry/11-sql-injection.aspx<br />http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/<br />17<br />Vkládání neautorizovaného kódu (Script/SQL Injection)<br />
  46. 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 –&gt; pošle mu „závadný“ kód, který se v prohlížeči interpretuje.<br />Ú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.<br />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ěží!<br />Obrana<br />Validace vstupních dat, HTML encoding, kontrola výstupů na stránku apod.<br />http://cs.wikipedia.org/wiki/XSS<br />http://stoyan.cz/hacking-xss/<br />http://ha.ckers.org/xss.html<br />18<br />XSS (Cross Site Scripting)<br />
  47. 47. Webový trojský kůň, provádí se skrytě na pozadí.<br />Zfalšování HTTP požadavku, např. vložením skriptu do tagu pro obrázek apod.<br />Nepozorovaně provádí pod identitou uživatele, který na odkaz kliknul, nějakou skrytou a většinou nepříjemnou činnost.<br />Moc se o tomto druhu útoku neví…<br />Obrana<br />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.<br />http://en.wikipedia.org/wiki/CSRF <br />http://zdrojak.root.cz/clanky/co-je-cross-site-request-forgery-a-jak-se-branit/<br />http://php.vrana.cz/cross-site-request-forgery.php<br />http://www.soom.cz/index.php?name=articles/show&aid=382<br />http://www.owasp.org/index.php/Top_10_2007-A5<br />19<br />Vnucený požadavek (Cross-Site Request Forgery, CSRF)<br />
  48. 48. Útočník se úmyslně pokouší vyvolávat chyby, které aplikace neošetřuje korektně.<br />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 –&gt; získat „citlivé“ informace, zakázat celou službu, obejít bezpečnostní mechanismus nebo způsobit pád serveru.<br />Obrana<br />Validace vstupních dat.<br />Důsledně ošetřovat a testovat chybové stavy –&gt; používat výjimky!<br />Nevypisovat chybová hlášení tzv. „z výroby“, ale upravit je tak, aby z nich nebylo možné získat informace kompromitující aplikaci. <br />Dokumentovat nastalé chyby do logu a průběžně provádět jejich kontrolu!<br />http://www.owasp.org/index.php/Top_10_2007-A6<br />20<br />Únik informací, nesprávné ošetřování chyb<br />
  49. 49. Útočník může přetížit systém samostatně legálními požadavky –&gt; další oprávnění uživatelé nemohou službu nadále používat nebo k ní přistupovat. <br />Pro distribuované DoS útoky (DDoS) se používají sítě tzv. botů –&gt; atak probíhá z několika stovek nebo tisíců počítačů najednou.<br />Obrana<br />Jsou-li příčinou chyby v aplikaci, lze je odstranit.<br />Při útoku z jednoho místa lze použít blokování IP adresy.<br />Jinak 100% spolehlivá ochrana neexistuje, zvláště u distribuovaných DDoS útoků je obrana velmi obtížná.<br />http://cs.wikipedia.org/wiki/DDoS <br />http://www.lupa.cz/serialy/utoky-typu-dos/<br />http://www.zive.sk/default.aspx?section=44&server=1&article=250832<br />http://www.root.cz/zpravicky/internet-byl-napaden-silou-40-gbps<br />http://www.viruslist.com/en/analysis?pubid=204792068<br />21<br />DoS útok (Denial of Service)<br />
  50. 50. Velké konfigurační nároky na server (OS + instalovaný SW) mohou mít špatný vliv na zabezpečení webové aplikace. <br />Mnoho konfiguračních možností ovlivňuje i bezpečnost aplikace v případě špatného nastavení.Více možností –&gt; více chyb –&gt; více bezpečnostních děr!<br />Obrana<br />Pečlivá (přehledná a zdokumentovaná) konfigurace prostředí. <br />Důsledná eliminace výchozích oprávnění, účtů a hesel.<br />Instalujte jen nutný SW! <br />Přístup ke konfiguraci mají mít pouze povolané osoby s vlastními účty (vnitřní nepřítel).<br />Sledování změn v konfiguračních souborech, např. systémem pro řízení konfigurace (správu zdrojového kódu, verzování).<br />22<br />Nezabezpečená konfigurační správa<br />
  51. 51. Agenda7<br /><ul><li>Bezpečnost?
  52. 52. Základní pojmy
  53. 53. Autentizační mechanismy
  54. 54. Nejčastější chyby v zabezpečení
  55. 55. Logy
  56. 56. Pravidla pro vytváření bezpečného kódu
  57. 57. Internet, doporučená literatura
  58. 58. Závěr</li></ul>23<br />
  59. 59. Práce s logy je nesmírně důležitá!<br />Logovat lze v IS téměř cokoliv a kdykoliv (vývoj, testování, provoz) <br />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.<br />Je vhodné zamezit neautorizované manipulaci s logy (např. elektronickým podpisem).<br />Časté chyby při správě logů<br />Logy nejsou používány<br />Logy jsou používány, ale nejsou prohlíženy<br />Logy jsou ukládány na příliš krátkou dobu<br />Jsou upřednostněny jen některé logy<br />Jsou ignorovány logy aplikací<br />Jsou prohlíženy jen ty logů, kde víme, že jsou problémy<br />http://www.infosecwriters.com/text_resources/pdf/Six_Mistakes_of_Log_Management_AChuvakin.pdf<br />24<br />Logy<br />
  60. 60. Agenda7<br /><ul><li>Bezpečnost?
  61. 61. Základní pojmy
  62. 62. Autentizační mechanismy
  63. 63. Nejčastější chyby v zabezpečení
  64. 64. Logy
  65. 65. Pravidla pro vytváření bezpečného kódu
  66. 66. Internet, doporučená literatura
  67. 67. Závěr</li></ul>25<br />
  68. 68. Huseby, Sverre H. – Zranitelný kód, Computer Press 2006<br />Nikdy nepodceňujte sílu protivníka!<br />Pokud mají akce vedlejší efekty, používejte pro odeslání požadavků metodu POST<br />Z hlediska serveru neexistuje bezpečný klient!<br />Nikdy nepoužívejte pro ověřování uživatele nebo pro kontrolu přístupových práv hlavičku REFERER<br />Při přihlášení uživatele zajistěte vždy vygenerování nového identifikátoru relace!<br />Nikdy neposílejte klientům podrobná chybová hlášení!<br />Nezapomeňte identifikovat každý metaznak předávaný do subsystému<br />Metaznaky je nutno ošetřit vždy, když posíláte data do dalšího subsystému<br />Vždy, když je to možné, posílejte data odděleně od řídících informací<br />Dávejte pozor na interpretaci znaků na více úrovních<br />26<br />Pravidla pro vytváření bezpečného kódu – I.<br />
  69. 69. Snažte se ze všech sil uplatňovat mechanismus Defense in depth (současné zabezpečení několika mechanismy)<br />Nikdy slepě nedůvěřujte dokumentaci API (např. vstupní data)<br />Zjistěte všechny zdroje, odkud data do aplikace vstupují<br />Pozor na neviditelnou bezpečnostní bariéru; nezapomeňte vždy kontrolovat všechny vstupy<br />Při filtrování dávejte přednost whitelistingu před blacklistingem<br />Nikdy neupravujte neplatný vstup, abyste z něj udělali platný<br />Vytvářejte záznamy i na úrovni aplikací <br />Nikdy nepoužívejte pro testování zabezpečení skripty běžící na straně klienta<br />Používejte pro vstup vytvořený serverem nepřímý přístup k datům vždy, když je to možné<br />Předávejte klientovi o vnitřním stavu co nejméně informací<br />27<br />Pravidla pro vytváření bezpečného kódu – II.<br />
  70. 70. Nepředpokládejte, že jednotlivé požadavky přicházejí v určitém pořadí<br />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<br />Nevytvářejte vlastní kryptografické algoritmy, používejte existující<br />Nikdy neukládejte hesla v nešifrované podobě<br />Nikdy nepoužívejte metodu GET v souvislosti s tajnými informacemi nebo v souvislosti s identifikátorem relace<br />Předpokládejte, že se zdrojový kód na straně serveru může ocitnout v rukou útočníků<br />Bezpečnost není produkt, ale proces (nikdy nekončící!)<br />28<br />Pravidla pro vytváření bezpečného kódu – III.<br />
  71. 71. Agenda7<br /><ul><li>Bezpečnost?
  72. 72. Základní pojmy
  73. 73. Autentizační mechanismy
  74. 74. Nejčastější chyby v zabezpečení
  75. 75. Logy
  76. 76. Pravidla pro vytváření bezpečného kódu
  77. 77. Internet, doporučená literatura
  78. 78. Závěr</li></ul>29<br />
  79. 79. http://crypto-world.info/<br />http://www.owasp.org/ – OWASP (The Open Web ApplicationSecurity Project)<br />http://kryl.info/clanek/561-bezpecnostni-audit-pres-obed<br />http://www.interval.cz– celá řada článků a seriálů věnovaných problematice bezpečnosti<br />http://secunia.com/<br />http://www.securityfocus.com/<br />http://www.cert.org/<br />http://kryl.info/clanek/429-top-15-bezpecnostnich-a-hackovacich-nastroju<br />http://www.xssed.com/archive/special=1/<br />http://www.sweb.cz/jobabroad/teorie.htm – teorie spoofingu<br />http://www.zive.cz/Clanky/Eugen-Kaspersky-a-rok-2018-Pohoda-ci-beznadej/sc-3-a-144454/default.aspx<br />http://www.dbsvet.cz/view.php?cisloclanku=2008100101<br />http://blog.softeu.cz/europen-bezpecnost-na-webu-2008/<br />http://code.google.com/p/browsersec/wiki/Main - bezpečnostní omezení a problémy prohlížečů<br />http://blog.synopsi.com/2009-07-23/test-ssl-certifikaty-slovenskych-a-ceskych-bank<br />http://blog.synopsi.com/2009-08-11/dread-analyza-rizik-podle-microsoftu<br />http://blog.synopsi.com/2009-09-25/hes-hes-zly-hacker<br />http://www.slideshare.net/MedvidekPU/trendy-v-internetov-bezpenosti<br />30<br />Odkazy na Internetu<br />
  80. 80. Microsoft – Vytváříme zabezpečené aplikace v Microsoft ASP.NET, CP Books (Computer Press) 2004<br />Taylor, Art; BuegeBrian; Layman Randy – Hacking bez tajemství: Java a J2EE, Computer Press 2003<br />Huseby, Sverre H. – Zranitelný kód, Computer Press 2006<br />Aulds, Charles – Linux – administrace serveru Apache, Grada 2003<br />Pošmura, Vlastimil – Apache – Příručka správce WWW serveru, Computer Press 2002<br />Dostálek, Libor, a kol. – Velký průvodce protokoly TCP/IP – Bezpečnost, Computer Press 2003<br />Mitnick, Kevin – Umění klamu, Helion 2003<br /> Singh, Simon – Kniha kódů a šifer, Argo, Dokořán, 2003<br />31<br />Doporučená literatura<br />
  81. 81. Agenda7<br /><ul><li>Bezpečnost?
  82. 82. Základní pojmy
  83. 83. Autentizační mechanismy
  84. 84. Nejčastější chyby v zabezpečení
  85. 85. Logy
  86. 86. Pravidla pro vytváření bezpečného kódu
  87. 87. Internet, doporučená literatura
  88. 88. Závěr</li></ul>32<br />
  89. 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!<br />Znovu: Bezpečnost je nikdy nekončící proces!<br />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.<br />„Dobrý admin nemusí být paranoidní. Ale hodně to pomáhá.“ – Michal A. Valášek <br />33<br />Závěr<br />
  90. 90. Souhrn7<br /><ul><li>Bezpečnost?
  91. 91. Základní pojmy
  92. 92. Autentizační mechanismy
  93. 93. Nejčastější chyby v zabezpečení
  94. 94. Logy
  95. 95. Pravidla pro vytváření bezpečného kódu
  96. 96. Internet, doporučená literatura
  97. 97. Závěr</li></ul>34<br />

×