VÝVOJ PODNIKOVÝCH APLIKACÍ NA PLATFORMĚ JAVA - PŘEDNÁŠKA Zbyněk Šlajchrt Část 11.

Prezentace na téma: "VÝVOJ PODNIKOVÝCH APLIKACÍ NA PLATFORMĚ JAVA - PŘEDNÁŠKA Zbyněk Šlajchrt Část 11."— Transkript prezentace:

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 2

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 3

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 4

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

6 HTTP Basic 6 GET /album Authorization: Basic c87fba22...... 3.3. 3.3. 4.4. 4.4. User: pepa PSW:**** User: pepa PSW:**** jméno a heslo zakódované BASE64 jméno a heslo zakódované BASE64

7 HTTP Basic 1. Klient odešle požadavek na stránku /album 2. Server odvětí chybovým kódem 401 Unauthorized a nabídne BASIC autentizaci 3. 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. 4. Pokud je uživatelské jméno a heslo platné, webový kontejner vrátí obsah požadované stránky 7

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 8

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 9

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 10

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í 11

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 12

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... 13

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čů 14

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 15

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

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 17

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 18

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 19 BASIC

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 v  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 20

21 File realm na Glassfish 21

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

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 23 Administrátor bankovní aplikace bankAdmin bankAdmin

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é 24 POST /addAccount GET /index.jsp GET /accounts/*

25 Příklad určení chráněných URL 25 Povinný údaj pro potřeby deployment nástrojů Povinný údaj pro potřeby deployment nástrojů Seznam URL chráněných prostředků. Může obsahovat vzor (*) 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 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 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  Sdružuje prostředky a metody přístupu k nim. K této kolekci se pak přiřazují role.  - používá stejná pravidla jako servlet-mapping pro mapování servletů  musí být specifikován aspoň jeden vzor  - 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 v rámci jednoho 26

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

28 Překryv  Jak kontejner řeší situaci, kdy dva bloky obsahují stejné URL vzory a metody? 28 Role1 Role2 Role1 * Role2 NEUVEDENO Role2 Role1, Role2 Všechny role Žádná role Všechny role

29 Příklad překrývání omezení přístupu 29 Vzor /* identifikuje všechny prostředky, tedy i ty, podchycené v horním bloku. V průniku dochází ke kupení rolí. 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í. 30 FORM /loginPage.jsp /loginError.jsp

31 Formulář pro přihlášení 31 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). 32

33 Aktivace chráněného přenosu  Provádí se v vepsáním tagu  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 33 CONFIDENTIAL

34 Příklad konfigurace HTTPS 34

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ý 35

36 Automatické přepnutí protokolů 36 1.1. 1.1. 2.2. 2.2. GET /addAccount HTTP Zjistí, že v se nachází s CONFIDENTIAL 3.3. 3.3. 301 Redirect Location: https://... 4.4. 4.4. GET /addAccount HTTPS 5.5. 5.5. Zjistí, že GET /addAccount je chráněné. Vyžádá si proto autentizaci. 6.6. 6.6. 401 Unauthorized WWW-Authenticate: Basic: realm=“bank-app“ 7.7. 7.7. GET /addAccount HTTPS Authorization: g67va... 8.8. 8.8....

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 CONFIDENTIAL 37

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 38

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 39

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

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á 41

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 42

43 Bezpečnostní anotace 43 AnotaceBeanMetodaPopis @PermitAllXXK metodě nebo beanu může přistupovat kterákoliv role. @DenyAllXXK metodě nebo beanu nemůže přistupovat žádná role. @RolesAllowedXXK metodě nebo beanu mohou přistupovat pouze vyjmenované role. @DeclareRolesXDeklaruje role pro celou aplikaci. @RunAsXDočasně přiřadí specifikovanou roli volajícímu.

44 Bezpečnostní anotace - příklad 44 1 1 2 2 3 3 4 4 1.K beanu ATMServiceBean mohou přistupovat role admin a banker 2.Při zavolání metody se dočasně změní role volajícího na admin 3.Metoda withdraw povoluje navíc přístup roli client 4.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ě 45

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 46

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

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://www.javaworld.com/javaworld/jw-09- 2004/jw-0927-logout.html  http://sqltech.cl/doc/oas10gR31/web.1013/b282 21/servsecr004.htm http://sqltech.cl/doc/oas10gR31/web.1013/b282 21/servsecr004.htm 48