VÝVOJ PODNIKOVÝCH APLIKACÍ NA PLATFORMĚ JAVA - PŘEDNÁŠKAZbyně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í
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 Basic5
GET /album
401 UnauthorizedWWW-Authenticate: Basic realm="album"
1.1.
2.2.
HTTP Basic6
GET /albumAuthorization: Basic c87fba22...
<html> ...</html>
3.3.
4.4.
User: pepaPSW:****
User: pepaPSW:****
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ž 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
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
1.1.
3.3.
5.5. 2
.2. Výběr šifry
4.4.a. ověření přes CAb. gen. náhod. čísla (základ pro
společný klíč vybrané sym. šifry)c. zašifrování čísla veřejnýmklíčem serveru
Zašifrované náhodné číslo
6.6.
Generování klíčepro komunikaci zná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
<login-config> <auth-method>BASIC</auth-method></login-config>
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
20
File realm na Glassfish21
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
<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>
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řebydeployment nástrojůPovinný údaj pro potřebydeployment nástrojů
Seznam URL chráněnýchprostředků. Může obsahovat vzor (*)
Seznam URL chráněnýchprostř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é sevztahuje omezení přístupu k uvedeným zdrojům
Seznam rolí, které mohou přistupovatk prostředkům pomocí uvedených HTTP metodSeznam rolí, které mohou přistupovatk prostředkům pomocí uvedených HTTP metod
Viz http://java.dzone.com/articles/understanding-web-security
<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>
26
<auth-constraint>
1. Specifikuje role, kterým je povoleno dotazovat se na prostředky
2. Pokud NENÍ <auth-constraint> uvedeno, přístup je POVOLEN VŠEM rolím
3. Pokud JE <auth-constraint> uvedeno, ale je prázdné, přístup je ZAKÁZÁN VŠEM rolím
4. <role-name> uvnitř <auth-constraint> POVOLUJE přístup uvedené roli
5. <role-name> může obsahovat *. Pak je přístup POVOLEN VŠEM rolím. Stejné jako 2.
27
Překryv <security-constraint> Jak kontejner řeší situaci, kdy dva <security-constraint> bloky obsahují stejné URL vzory a metody?
28
<auth-constraint> <role-name>Role1</role-name></auth-constraint>
<auth-constraint> <role-name>Role2</role-name></auth-constraint>
<auth-constraint> <role-name>Role1</role-name></auth-constraint>
<auth-constraint> <role-name>*</role-name></auth-constraint>
<auth-constraint/><auth-constraint> <role-name>Role2</role-name></auth-constraint>
NEUVEDENO
<auth-constraint> <role-name>Role2</role-name></auth-constraint>
Role1, Role2
Všechny role
Žádná role
Všechny role
Příklad překrývání omezení přístupu
29
Vzor /* identifikuje všechnyprostředky, tedy i ty, podchycenév horním bloku. V průniku docházíke kupení rolí.
Vzor /* identifikuje všechnyprostř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
<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>
Formulář pro přihlášení31
<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)!
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 <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
33
<user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee></user-data-constraint>
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ů
36
1.1.
2.2.
GET /addAccount HTTP
Zjistí, že v <security-constraint> senachází <user-data-constraint> s<transport-guarantee> CONFIDENTIAL
3.3.
301 RedirectLocation: https://...
4.4.
GET /addAccount HTTPS
5.5.Zjistí, že GET /addAccount je
chráněné. Vyžádá si proto autentizaci.
6.6.
401 UnauthorizedWWW-Authenticate:Basic: realm=“bank-app“
7.7.
GET /addAccount HTTPSAuthorization: g67va ...
8.8.
<html>...</html>
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>
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 Containe
r/ACC
Web Containe
r/ACC
EJB Containe
r
EJB Containe
r
JAASJAAS
AuthenticationSystem
AuthenticationSystem
Přenosověřenéhouživatele
AutentizaceAutorizace
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í anotace43
Anotace Bean Metoda
Popis
@PermitAll X X K metodě nebo beanu může přistupovat kterákoliv role.
@DenyAll X X K metodě nebo beanu nemůže přistupovat žádná role.
@RolesAllowed
X X K metodě nebo beanu mohou přistupovat pouze vyjmenované role.
@DeclareRoles
X Deklaruje role pro celou aplikaci.
@RunAs X Dočasně přiřadí specifikovanou roli volajícímu.
Bezpečnostní anotace - příklad
44
1122
33
44
1. K beanu ATMServiceBean mohou přistupovat role admin a banker2. Při zavolání metody se dočasně změní role volajícího na admin3. Metoda withdraw povoluje navíc přístup roli client4. Metoda log na beanu Logger je volána v převlečení za roli admin (viz 2.)
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
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
http://www.javaworld.com/javaworld/jw-09-2004/jw-0927-logout.html
http://sqltech.cl/doc/oas10gR31/web.1013/b28221/servsecr004.htm
48
Top Related