VÝVOJ PODNIKOVÝCH APLIKACÍ NA PLATFORMĚ JAVA - PŘEDNÁŠKA Zbyněk Šlajchrt Čá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í 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

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

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

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

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

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

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

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

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

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

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

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ž x 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

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

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

SSL – Handshake (server-only mod) 16 Předá seznam podporovaných symetrických šifer Zvolená šifra a certifikát serveru Výběr šifry 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 Generování klíče pro komunikaci z náhodného čísla

Č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

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

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

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

File realm na Glassfish 21

Správa uživatelů ve File realm 22

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

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/*

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

 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

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

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

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

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

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)!

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

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

Příklad konfigurace HTTPS 34

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

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

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

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

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

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

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

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

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

Bezpečnostní anotace - příklad 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.)

Kombinování 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ě na na metodě na na metodě na na metodě 45

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

Programová bezpečnost - příklad 47

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  /jw-0927-logout.html /jw-0927-logout.html  21/servsecr004.htm 21/servsecr004.htm 48