1 / 48

VÝVOJ PODNIKOVÝCH APLIKACÍ NA PLATFORMĚ JAVA - PŘEDNÁŠKA

VÝVOJ PODNIKOVÝCH APLIKACÍ NA PLATFORMĚ JAVA - PŘEDNÁŠKA. Zbyněk Šlajchrt http://java.vse.cz/4it447/HomePage. Část 11. Hrozby v enterprise aplikacích. Podnikové aplikace musí čelit různým bezpečnostním hrozbám Předstírání identity uživatele Prozrazení důvěrných informací

shakti
Download Presentation

VÝVOJ PODNIKOVÝCH APLIKACÍ NA PLATFORMĚ JAVA - PŘEDNÁŠKA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. VÝVOJ PODNIKOVÝCH APLIKACÍ NA PLATFORMĚ JAVA - PŘEDNÁŠKA Zbyněk Šlajchrt http://java.vse.cz/4it447/HomePage Část 11.

  2. Hrozby v enterprise aplikacích • Podnikové aplikace musí čelit různým bezpečnostním hrozbám • Předstírání identity uživatele • Prozrazení důvěrných informací • Vyzrazení lékařských informací o pacientovi • Zlovolná úprava dat • Virus na serveru "upraví" zůstatek na bankovním účtu • Zneužití služeb aplikace • Uživateli se podaří vytvořit vyhrávající los • Výpadky v důsledku napadení • Hackerské útoky (DoS), viry

  3. Bezpečnostní mechanismy • Ověření pravosti (authentication) • Proces ověření identity uživatele, který se pokouší přistupovat k prostředkům aplikace • Autorizace (authorization) • Následuje po ověření pravosti uživatele • Ověřuje se, zda uživatel smí přistupovat k danému prostředku • Ochrana důvěrných dat a jejich integrity • Přenášená data je třeba ochránit před neoprávněným "odposlechem" – důvěrnost - či neoprávněnými úpravami - integrita

  4. Autentizace ve webovém kontejneru • Při přístupu k chráněným prostředkům (statické a dynamické stránky, obrázky, soubory) je třeba zjistit identitu uživatele • Po zjištění identity se ověří, zda daný uživatel má právo k požadované operaci s prostředkem • Webový kontejner podporuje tyto mechanismy • HTTP Basic • HTTP Digest • HTTPS Mutual • FORM Based

  5. HTTP Basic 1. GET /album 401 Unauthorized WWW-Authenticate: Basic realm="album" 2.

  6. HTTP Basic jméno a heslo zakódované BASE64 GET /album Authorization: Basic c87fba22... 3. User: pepa PSW:**** <html> ... </html> 4.

  7. HTTP Basic • Klient odešle požadavek na stránku /album • Server odvětí chybovým kódem 401 Unauthorized a nabídne BASIC autentizaci • Prohlížeč otevře dialogové okno, kam uživatel zadá své jméno a heslo. Tyto informace se spojí a zakódují v BASE64. Kód se odešle na server. • Pokud je uživatelské jméno a heslo platné, webový kontejner vrátí obsah požadované stránky

  8. Nevýhody HTTP Basic • Jelikož HTTP protokol je bez-stavový, autentizační údaje se musí odesílat s každým dotazem • Velmi zranitelný mechanismus. Autentizační údaje putují na server zakódované v BASE64. Dekódovaní je velmi snadné. • Nedoporučuje se bez dodatečného zabezpečení • Obvykle v kombinaci s HTTPS (SSL) • ISIS

  9. HTTP Digest • Řeší "viditelnost" přihlašovacích údajů HTTP Basic • Na server se místo hesla odesílá hash z řetězce sestaveného z dat v dotazu (heslo, URL, nonce atd.) • Server v první odpovědi posílá dodatečné parametry, které se použijí pro sestavení hashe • hodnota parametru nonce(number used once) je jedinečná a je použita při výpočtu hash kódu • to učiní hash kód neopakovatelným, tudíž případný jeho odposlech je nepoužitelný • Tato metoda není specifikací vyžadována

  10. HTTPS Mutual (CLIENT-CERT) • Klient a server si vymění cerifikáty (X.509) • Certifikáty obsahují veřejný klíč a slouží jako osvědčení pravosti identity certifikační autoritou (CA) • Přenos dat probíhá po zabezpečeném kanálu a významně redukuje riziko odposlechu a neoprávněné zásahu do přenášených dat. • Nevýhoda: klient musí mít certifikát

  11. Symetrické šifrování • Strany účastnící se komunikace se domluví na šifrovacím klíči • Tento klíč se použije pro zašifrování předávaných zpráv • AES, Blowfish, DES, RC4, FISH ... • Výhoda: nízká výpočetní náročnost, RC4 a FISH dokáží šifrovat proudy (ostatní po blocích) • Nevýhoda: náchylné k prolomení

  12. Asymetrické šifrování • Každá strana v komunikaci vlastní pár klíčů • veřejný a soukromý • Data zakódovaná jedním klíčem lze dekódovat druhým • Diskrétní doručení • Odesílatel zašifruje zprávu veřejným klíčem příjemce. Ten ji pak dešifruje použitím svého soukromého klíče. • Elektronický podpis (pečeť) • Odesílatel podepíše hash zprávy svým soukromým klíčem a pošle jej se zprávou. Příjemce si ověří autenticitu dešifrováním hashe pomocí veřejného klíče odesílatele a porovnáním s aktuálním hashem doručené zprávy

  13. Vlastnosti asymetrické šifry • Výhody • Nevyžaduje počáteční výměnu klíče • Oproti symetrickým šifrám bezpečnější • Nevýhody • Výpočetně náročné (až 100.000x než symetrické) • Prolomitelné brutální silou • Šifrování po malých blocích (max. cca 120 bytů pro 1024 bitovou šifru) • Zástupci: RSA, Diffie-Hellman ...

  14. Digitální certifikáty • Řeší problém: Jakou cestou příjemce získá veřejný klíč odesílatele? • Pokud osobně, není problém. • Pokud jinak, hrozí, že je klíč podvržený • Řešení: veřejný klíč si jeho vlastník drží v "obálce" zvané bezpečnostní certifikát. • Tato "obálka" je podepsána soukromým klíčem nějaké důvěryhodné instituce – cert. autority (CA) • Pravost veřejného klíče odesílatele se ověří přes veřejný klíč certifikační autority • obvykle je součástí webových prohlížečů

  15. Secure Socket Layer • Bezpečnostní protokol zaručující důvěrnost a integritu přenosů po Internetu (Netscape) • Obě strany se dohodnou na klíči pro symetrické šifrování přenášených dat – handshake • K dohodě se použije veřejný klíč serveru, kterým klient zašifruje náhodně vygenerované číslo, které odešle na server • Dva mody výměny certifikátů • server – ověřuje se pouze identita serveru • mutual – ověrují se identity server i klienta

  16. SSL – Handshake (server-only mod) Předá seznam podporovaných symetrických šifer 1. 5. Zašifrované náhodné číslo 2. Výběr šifry 6. Generování klíče pro komunikaci z náhodného čísla 4. • ověření přes CA • gen. náhod. čísla (základ prospolečný klíč vybrané sym. šifry) • zašifrování čísla veřejným • klíčem serveru 3. Zvolená šifra a certifikát serveru

  17. Činnosti webového kontejneru • Vyhledání poptávaného prostředku • kontejner musí zjistit, zda se nejedná o chráněný prostředek • Ověření identity žadatele (autentizace) • pokud se jedná o chráněný prostředek, musí zajistit autentizaci žadatele • Autorizace • Podařilo-li se ověřit identitu, musí kontejner zjistit, může-li klient přistupovat k požadovanému prostředku

  18. Deklarativní řízení bezpečnosti • Usnadňuje vývoj tím, že se vývojář nemusí zabývat bezpečnostními hledisky aplikace • Konfigurace je možná bez zásahu do zdrojového kódu • Podporuje komponentové programování – znovu-použitelnost • Jeden servlet lze použít v různých bezpečnostních scénářích

  19. Aktivace autentizace • Ve WEB-INF/web.xml • auth-method může nabývat těchto hodnot • BASIC • DIGEST • FORM • CLIENT-CERT • specifický kód výrobce kontejneru <login-config> <auth-method>BASIC</auth-method> </login-config>

  20. Security Realm • Termínem realm se označuje místo (registr), kde jsou uloženy informace o uživatelích (jména, hesla, skupiny atd.) • Při autentizaci webový kontejner spolupracuje s realm • Na serveru lze definovat více realm, aplikace však pracuje právě s jedním • Lze určit prvkem <realm-name> v <login-config> • Glassfish nabízí např. tyto typy realm • File – jednoduché, vhodné pro vývoj • LDAP – napojení na LDAP • JDBC – informace jsou uloženy v databázi

  21. File realm na Glassfish

  22. Správa uživatelů ve File realm

  23. Definice rolí • V chráněné aplikaci vystupují uživatelé v tzv. rolích • Aplikace udržuje jejich seznam ve web.xml • V případě Glassfish se musí role namapovat v sun-web.xml na skupiny v realm <security-role> <description>Administrátor bankovní aplikace</description> <role-name>bankAdmin</role-name> </security-role> <security-role-mapping> <role-name>bankAdmin</role-name> <group-name>bankAdmin</group-name> </security-role-mapping>

  24. Určení chráněných prostředků • Při konfiguraci autorizace se neuvažují pouze URL prostředků, ale i HTTP metody, pomocí kterých klient k prostředkům přistupuje (dotazuje se) • Omezují se HTTP dotazy, nikoliv prostředky samotné POST /addAccount GET /index.jsp GET /accounts/*

  25. Příklad určení chráněných URL Povinný údaj pro potřeby deployment nástrojů Seznam URL chráněných prostředků. Může obsahovat vzor (*) Seznam HTTP metod, na které se vztahuje omezení přístupu k uvedeným zdrojům Seznam rolí, které mohou přistupovat k prostředkům pomocí uvedených HTTP metod Viz http://java.dzone.com/articles/understanding-web-security

  26. <web-resource-collection> • Sdružuje prostředky a metody přístupu k nim. K této kolekci se pak přiřazují role. • <url-pattern> - používá stejná pravidla jako servlet-mapping pro mapování servletů • musí být specifikován aspoň jeden vzor • <http-method> - pokud není uvedena žádná HTTP metoda, je to jakoby byly uvedeny všechny • Pozor: pokud jsou uvedeny nějaké HTTP metody, tak zbývající jsou povoleny! • Lze uvést více <web-resource-collection> v rámci jednoho <security-constraint>

  27. <auth-constraint> • Specifikuje role, kterým je povoleno dotazovat se na prostředky • Pokud NENÍ<auth-constraint> uvedeno, přístup je POVOLEN VŠEM rolím • Pokud JE<auth-constraint> uvedeno, ale je prázdné, přístup je ZAKÁZÁN VŠEM rolím • <role-name> uvnitř <auth-constraint>POVOLUJE přístup uvedené roli • <role-name> může obsahovat *. Pak je přístup POVOLEN VŠEM rolím. Stejné jako 2.

  28. Překryv <security-constraint> • Jak kontejner řeší situaci, kdy dva <security-constraint> bloky obsahují stejné URL vzory a metody? <auth-constraint> <role-name>Role1</role-name> </auth-constraint> <auth-constraint> <role-name>Role2</role-name> </auth-constraint> Role1, Role2 <auth-constraint> <role-name>Role1</role-name> </auth-constraint> <auth-constraint> <role-name>*</role-name> </auth-constraint> Všechny role <auth-constraint> <role-name>Role2</role-name> </auth-constraint> Žádná role <auth-constraint/> <auth-constraint> <role-name>Role2</role-name> </auth-constraint> NEUVEDENO Všechny role

  29. Příklad překrývání omezení přístupu Vzor /* identifikuje všechny prostředky, tedy i ty, podchycené v horním bloku. V průniku dochází ke kupení rolí.

  30. Autentizace pomocí formuláře • Umožňuje připravit si vlastní formulář pro přihlašování do aplikace včetně stránky, která se zobrazí po neśpěšném přihlášení. <login-config> <auth-method>FORM</auth-method> <form-login-config> <form-login-page>/loginPage.jsp</form-login-page> <form-error-page>/loginError.jsp</form-error-page> </form-login-config> </login-config>

  31. Formulář pro přihlášení <form action="j_security_check" method="POST"> <input type="text" name="j_username"/> <input type="text" name="j_password"/> <input type="submit" value="Enter"/> </form> • akce formuláře musí být j_security_check • uživatelské jméno je přenášeno v parametru j_username • heslo je přenášeno v parametru j_password Přihlašovací údaje putují na server nechráněná! Podobně jako v případě BASIC. Řešení: přenos údajů musí probíhat po chráněné transportní vrstvě, např. HTTPS, neboli HTTP nad SSL. Pozn.:Při použití FORM autentizace musí být aktivní sledování session (např. cookies, SSL)!

  32. Chráněná transportní vrstva • Deklarace chráněných prostředků může také obsahovat příkaz, aby kontejner zajistil komunikaci po chráněném kanálu při přenosu dotazu na prostředek serveru i při předávání odpovědi (vlastní data prostředku) zpět na klienta. • Specifikace nevnucuje konkrétní technologii, ale prakticky vždy se jedná o HTTPS (HTTP nad SSL).

  33. Aktivace chráněného přenosu • Provádí se v <security-constraint> vepsáním tagu <user-data-constraint> • Má tento obsah • Při přístupu k prostředku „vnutí“ kontejner klientovi HTTPS protokol. • Možné hodnoty: • CONFIDENTIAL – zamezí odposlechu dat • INTEGRAL – zajistí integritu dat, tj. zamezí změně dat cestou • NONE – bez chráněného protokolu <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint>

  34. Příklad konfigurace HTTPS

  35. Poznámky k chráněnému přenosu • Protokol SSL řeší integritu i důvěrnost • Volba INTEGRAL i CONFIDENTIAL vede prakticky vždy k použití protokolu HTTPS, efekt obou je stejný

  36. Automatické přepnutí protokolů 1. GET /addAccount HTTP 4. GET /addAccount HTTPS 7. GET /addAccount HTTPS Authorization: g67va ... 2. Zjistí, že v <security-constraint> se nachází <user-data-constraint> s <transport-guarantee>CONFIDENTIAL 301 Redirect Location: https://... 3. 8. 401 Unauthorized WWW-Authenticate: Basic: realm=“bank-app“ 5. 6. <html> ... </html> Zjistí, že GET /addAccount je chráněné. Vyžádá si proto autentizaci.

  37. Poznámky k důvěrné autentizaci • Klient se nikdy nedotazuje na přihlašovací okno • Zobrazení přihlašovacího okna je až důsledek dotázání se na chráněný prostředek • V případě, že přihlašovací údaje mají na server putovat po zabezpečeném spojení, je třeba každý chráněný prostředek opatřit <transport-guarantee>CONFIDENTIAL</transport-guarantee>

  38. Odhlašování • Informace o přihlášení je uložena v session • Voláním HttpSession::invalidate() má za následek odhlášení uživatele • Od verze Servlet API 3.0 metoda HttpRequest::logout() • resetování security kontextu (principal a jeho role) • metody getUserPrincipal, getRemoteUser, getAuthType vrací null

  39. Programové zabezpečení • V případech, kdy si nevystačíme s deklarativním zabezpečení aplikace, můžeme použít programové zabezpečení. • Metody v HttpServletRequest • login(user, password) – ověří uživatele, vyhazuje výjimku • authenticate(response) – vynutí si autentizaci na kontejneru • logout() – vymaže údaje o uživateli z dotazu • getRemoteUser() – jméno přihlášeného uživatele • isUserInRole(role) – vrací true, pokud má uživatel danou roli • getUserPrincipal() – vrací java.security.Principal objekt odpovídající vzdálenému uživateli

  40. JAAS • Java Authentication and Authorization Service • Implementace: LDAP, MS Active Directory, ... • Používáno kontejnerem pro autentizaci a autorizaci Přenos ověřeného uživatele WebContainer/ ACC EJB Container Autentizace Autorizace Autorizace JAAS Authentication System

  41. Podpora bezpečnosti v EJB • Cílem je řídit přístup k business logice • Autentizace je řízena webovým kontejnerem nebo ACC (application client container, stand-alone app) • Předpokládá se, že do EJB kontejneru přistupuje již ověřený uživatel • Provádí se pouze autorizace • Deklarativní • Programová

  42. Deklarativní bezpečnost v EJB • Jako obvykle: anotace nebo ejb-jar.xml • Zahrnuje: • Deklarace rolí • Přiřazení povolenek metodám nebo celým beanům • Dočasná změna identity

  43. Bezpečnostní anotace

  44. Bezpečnostní anotace - příklad 1 2 3 4 K beanu ATMServiceBean mohou přistupovat role admin a banker Při zavolání metody se dočasně změní role volajícího na admin Metoda withdraw povoluje navíc přístup roli client Metoda log na beanu Logger je volána v převlečení za roli admin (viz 2.)

  45. Kombinování anotací • @PermitAll, @DenyAll, and @RolesAllowed nesmí být použity současně na metodě či třídě • V případě kombinování anotací mají přednost anotace na metodě před anotacemi na třídě • @PermitAll na třídě, @RolesAllowed nebo @DenyAll na metodě • @DenyAll na třídě, @PermitAll nebo @RolesAllowed na metodě • @RolesAllowed na třídě, @PermitAll nebo @DenyAll na metodě

  46. Programová bezpečnost • Používá se v případech, kdy nepostačuje deklarativní zabezpečení • Rozhraní SessionContext • isCallerInRole(String role) • vrací true, pokud volající je v uvedené roli • Principal getCallerPrincipal() • vrací objekt java.security.Principal, který reprezentuje volajícího

  47. Programová bezpečnost - příklad

  48. Zdroje • Allen, Paul R. – Bambara, Joseph L.; SCEA Study Guide; McGraw Hill • Head First Servlets/JSP • Burke, Bill – Monson-Haefel, Richard; Enterprise Java Beans 3.0; O'Reilly • Goncalves, Antonio; Beginning Java EE 6 Platform With GlassFish 3; APRESS • http://www.javaworld.com/javaworld/jw-09-2004/jw-0927-logout.html • http://sqltech.cl/doc/oas10gR31/web.1013/b28221/servsecr004.htm

More Related