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

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

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

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

HTTP Basic5

GET /album

401 UnauthorizedWWW-Authenticate: Basic realm="album"

HTTP Basic6

GET /albumAuthorization: Basic c87fba22...

User: pepaPSW:****

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

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)

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

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

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í

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

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

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

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

SSL – Handshake (server-only mod)

Předá seznam podporovaných symetrických šifer

Zvolená šifra a certifikát serveru

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

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

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

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>

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

File realm na Glassfish21

Správa uživatelů ve File realm

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>

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

Příklad určení chráněných URL

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>

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

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>*</role-name></auth-constraint>

<auth-constraint/><auth-constraint> <role-name>Role2</role-name></auth-constraint>

NEUVEDENO

Role1, Role2

Všechny role

Žádná role

Všechny role

Příklad překrývání omezení přístupu

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

<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

•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).

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>

Příklad konfigurace HTTPS

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ý

Automatické přepnutí protokolů

GET /addAccount HTTP

Zjistí, že v <security-constraint> senachází <user-data-constraint> s<transport-guarantee> CONFIDENTIAL

301 RedirectLocation: https://...

GET /addAccount HTTPS

5.5.Zjistí, že GET /addAccount je

chráněné. Vyžádá si proto autentizaci.

401 UnauthorizedWWW-Authenticate:Basic: realm=“bank-app“

GET /addAccount HTTPSAuthorization: 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 <transport-guarantee>CONFIDENTIAL</transport-guarantee>

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

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

Java Authentication and Authorization Service Implementace: LDAP, MS Active Directory, ...

Používáno kontejnerem pro autentizaci a autorizaci

Web Containe

EJB Containe

JAASJAAS

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á

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

Bezpečnostní anotace43

Anotace Bean Metoda

@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

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ě

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

Programová bezpečnost - příklad

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

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

Documents

Poskytování aplikací z cloudu

Řízení rizik v platformě ICZ Risk*Guide

Úvod do podnikových financí

SEKTOR SDÍLENÝCH PODNIKOVÝCH SLUŽEB V ČESKÉ …outsourcing služeb řešení IT (např. údržbu systémů, aplikací nebo infrastruktury či technickou podporu) a/nebo vývoj

Stránka 1, © Vema, a. s.z podniků a organizací úplně zmizí servery s instalacemi podnikových aplikací a databází provozování se zcela přesune k dodavatelům cloudových

Integrace aplikací Profinit ESB –úvod

Cloudové řešení podnikových aplikací

Charakteristika podniku a podnikových faktorov

Optimalizace webových aplikací

VÝVOJ PODNIKOVÝCH APLIKACÍ NA PLATFORMĚ JAVA EE

Vývoj aplikací pro iOS

KONCEPCIA PODPORY CENTIER PODNIKOVÝCH SLUŽIEB

SYSTÉMOVÁ INTEGRACE A INTEGRACE APLIKACÍ

Komplexní návrh podnikových sítí za použití spolehlivých ... file1 Komplexní návrh podnikových sítí za použití spolehlivých aktivních prvků Petr Dorociak obchodní

Hra vytvořená v platformě Unity 3D - cvut.cz

Deployment PHP aplikací | WebExpo 2011

Pokročilé programování na platformě Java, letní semestr 2019

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

Ladění aplikací v Caché

Vývoj aplikací v jazyce Ruby