Design pro zabezpečené přihlášení do OpenCms s ověřením proti Kerberos ZČU:

Jednoduché řešení (nasazení 4/2009)

Z důvodu použití Apache + Tomcat na beta.kiv.zcu.cz, kde:

• probíhá překlad adres - není vidět /opencms/
• Tomcat nepozná, jestli je připojení HTTPS nebo HTTP - nefunguje request.isSecure()
• všechny cookie se odesílají jako non-secure
• zabezpečení stránek se nastavuje v Apache - jestli bude vynuceno HTTPS,

nelze použít řešení s validací.

Nasazeno bylo pouze:

• Kerberos - celé řešení
• pomocí Apache byla zabezpečena přihlašovací stránka do workplace
• upravené příhlašovací JSP z modulu welcome pro frontend - url login_element_secure.jsp bylo zabezpečeno Apachem.

Instalace na ManualModulLogin - Jednoduché řešení.

Kompletní řešení

Cíl: Zabezpečení přihlášení a lepší kontrolu uživatele než přes kontrolu IP (OpenCms interně).

Požadavky

1. zabezpečená přihlašovací stránka do worklace (HTTPS)
2. zabezpečená práce ve workplace
3. zabezpečená přihlašovací stránka na frontendu (odhlášení nebude zabezpečené)
4. login form pro frontend
5. ověření pravosti přihlášeného uživatele pracujícího přes HTTP (rozpoznání zloděje session)

Viz též původní náčrty: Attach:kiv-secure-auth-proces.jpg obrázek - červeně jsou označeny stránky-cookies které jsou secure čili na HTTPS. Attach:opencms-zabezpeceni-frontend.jpg - jak má fungovat zabezpečení při přístupu k frontend obsahu, včetně periodického ověřování autenticity uživatele

K celému se přidá Kerberos autentizace.

Termíny:

• zloděj, útočník = ten který nějak ukradl session ID (ale nemá secure token)
• validace = ověření, zda má přihlášený uživatel secure token

Analýza a řešení

ad 1. + 2.

Pro zabezpečení práce ve workplace včetně přihlášení je třeba nastavit v %OPENCMS%/WEB-INF/web.xml:

<security-constraint>

   <web-resource-collection>
      <web-resource-name>SecureWorkplace</web-resource-name>
      <url-pattern>/opencms/system/*</url-pattern>
   </web-resource-collection>
   <user-data-constraint>
      <transport-guarantee>CONFIDENTIAL</transport-guarantee>
   </user-data-constraint>

</security-constraint> 

Dojde k vynucení HTTPS u stránek ležících v /opencms/system/* a podadresářích. Zabezpečí se tedy přihlašovací formulář do workplace (/opencms/system/login) a samotné stránky workplace (/opencms/system/wrkplace).

ad 3. + 4.

Pro účely zabezpečeného přihlášení byl upraven modul org.opencms.welcome z OpenCms 6.2.3. Obsahuje v adresáři /elements soubory login_element.jsp a login_element_secure.jsp.

• login_element.jsp se umístí do template (na HTTP)
• umožňuje:
  • přihlášení (odkaz na zebezpečený formulář, nutno nastavit odkaz manuálně)
  • odhlášení
  • zpracovává cookie s výsledekem validace - zobrazuje zprávy pomocí javascriptu - ukradená session
• login_element_secure.jsp - přihlašovací formulář na HTTPS - přesměrování zařídí sám, nebo je možno nastavit ve web.xml stejně jako zabezpečení workplace
  • na něm se bude také provádět ověření přihlášeného uživatele
  • umožňuje odhlášení

Pokud potřebuji zabezpečit nějakou operaci (formulář atd.) musí se přejít na HTTPS.

Body 3. a 4. potřebují pro správnou funkčnost sdílení session mezi HTTPS a HTTP.

Problém je následující:

• pokud se přihlásíme na stránce s HTTPS, je session cookie odeslána jako secure, což působí problémy při přechodu na HTTP (session cookie není poslána a my figurujeme jako nepřihlášeni)
• pokud bychom se přihlásili na HTTP (což nebudeme dělat, ale uvedu jej pro úplnost), je session cookie vyslána jako nezabezpečená, tím je umožněn bezproblémový přechod na HTTPS, aniž bychom ztratili session. Problém je ovšem v tom, že máme vyzrazený identifikátor session.

Po analýze problému se nabízí řešení, které pomáhá i k řešení bodu 5.

Sdílení session HTTPS + HTTP

Po přihlášení na zebezpečené stránce by byla session cookie poslána jako secure. Tento stav je nežádoucí kvůlí sdílení session s HTTP. Nutný je tedy zásah do CmsJspLoginBean OpenCms, která je zodpovědná za přihlašování.

Provedeme několik úprav:

• znemožníme přihlášení nezabezpečeným způsobem (HTTP)
• po přihlášení cookie pošleme cookie se session id jako nezbezpečenou (přemažeme původní zabezpečenou)
• vyrobíme secure token cookie, která bude obsahovat hashMD5(session id + sůl)
  • pošleme jako zabezpečenou cookie - máme označeného uživatele, který se skutečně přihlásil; nikdo jiný tuto cookie nebude mít
  • uložíme ho také do session (pro validaci)
• do session uložíme čas přihlášení pro časovou kontrolu uživatele

Takto je zaručeno sdílení session po přihlášení na HTTPS a případném přechodu na HTTP. Máme taktéž označeného pravého uživatele

ad 5.

Ověření pravosti uživatele se bude dít přes servlet filtr ValidateAuthFilter. Filtr se nastaví, viz ManualModulLogin tak, aby kontroloval veškerou komunikaci.
Parametry filtru jsou:

• url na zabezpečenou validační stránku
• timeout pro validaci (po uplynutí tohoto času se provede validační smyčka, pouze pro HTTP)

Filtr se chová několika způsoby:

A. Jsme-li nepřihlášeni, propouští komunikaci dále.

B. Pokud jsme na nezabezpečeném HTTP, počítá při každém požadavku čas od přihlášení. Uplyne-li doba delší než delta t a je-li náš požadavek GET, začne validační smyčka:

1. uloží se url požadavku
2. do session se uloží příznak, že validujeme (nutné pro přechod zpět na HTTP)
3. dojde k přešměrování na HTTPS zabezpečenou stránku (url kde je umístěn login_element_secure.jsp)
4. ověří se přitomnost secure token a jeho správnost, několik možností:
   • nastane-li chyba při validaci, je uložen příznak do session pro informování skutečného uživatele; útočníkovi je posláno 403 Forbidden a cookie s výsledkem validace - zpracuje login_element.jsp, pokud by se znovu snažil přistoupit s ukradenou session cookie - vyběhne ihned hlášení
   • validace úspěšná, ale zjištěn útok (příznak v session); poslána cookie s příznakem útoku - zpracuje login_element.jsp - hlášení o ukradené session; uložení času validace; přechod zpět na HTTP
   • validace úspěšná; uložení času validace; přechod zpět na HTTP

C. Pokud sami přejdeme na HTTPS, je validován každý náš požadavek (GET, POST). Zůstáváme na HTTPS. Neukládá se čas validace pro případ krádeže session cookie a přístup útočníka na HTTP (bude zachycen filtrem - vyprší čas, na HTTPS by byl zachycen okamžitě). Při neúspěšné validaci se posílá 403 Forbidden.

Instalace na ManualModulLogin - Kompletní řešení.

Zpět na RedSys