streamalism.org

1. Prehľad

V tomto článku si ukážeme, ako na to Jarná bezpečnosť nám umožňuje ovládať naše relácie HTTP.

Táto kontrola sa pohybuje od časového limitu relácie po povolenie súbežných relácií a ďalších pokročilých konfigurácií zabezpečenia.

2. Kedy je relácia vytvorená?

Môžeme presne určiť, kedy sa vytvorí naša relácia a ako s ňou bude Spring Security interagovať:

• vždy- relácia sa vytvorí vždy, ak ešte neexistuje
• Ak je potrebné- relácia sa vytvorí iba v prípade potreby (predvolené)
• nikdy- rámec nikdy nevytvorí reláciu sám, ale použije ju, ak už existuje
• bezstavový- Spring Security nebude vytvárať ani používať žiadnu reláciu

...

Konfigurácia Java:

@Override protected void configure (HttpSecurity http) vyvolá výnimku {http.sessionManagement () .sessionCreationPolicy (SessionCreationPolicy.IF_REQUIRED)}

Je veľmi dôležité to pochopiť táto konfigurácia riadi iba to, čo robí Spring Security - nie celá aplikácia. Aplikácia Spring Security nemusí vytvoriť reláciu, ak jej dáme pokyn, aby tak urobila, ale naša aplikácia môže!

Predvolene, Jarná bezpečnosť vytvorí reláciu, keď ju bude potrebovať - toto je "Ak je potrebné“.

Pre bez štátnej príslušnosti„nikdy”Voľba zabezpečí, že Spring Security sama nevytvorí žiadnu reláciu; ak ich však aplikácia vytvorí, Spring Security ju využije.

Nakoniec najprísnejšia možnosť vytvorenia relácie - „bezstavový”- je a zaručiť, že aplikácia nevytvorí vôbec žiadnu reláciu.

To bolo predstavené na jar 3.1 a bude efektívne preskakovať časti reťazca filtrov jarnej bezpečnosti - hlavne časti súvisiace s reláciou ako napr HttpSessionSecurityContextRepository, SessionManagementFilter, RequestCacheFilter.

Tieto prísnejšie kontrolné mechanizmy majú priamy dôsledok cookies sa nepoužívajú a tak každá žiadosť musí byť znovu autentifikovaná. Táto bezstavová architektúra hrá dobre s REST API a ich obmedzeniami bez štátnej príslušnosti. Rovnako dobre fungujú s autentifikačnými mechanizmami, ako sú napríklad Basic a Digest Authentication.

3. Pod kapotou

Pred vykonaním procesu autentifikácie spustí Spring Security filter zodpovedný za ukladanie bezpečnostného kontextu medzi požiadavkami - SecurityContextPersistenceFilter. Kontext bude uložený podľa stratégie - HttpSessionSecurityContextRepository v predvolenom nastavení - ktorý používa reláciu HTTP ako úložisko.

Za prísnych create-session = ”bez štátnej príslušnosti” atribút, bude táto stratégia nahradená inou - NullSecurityContextRepository - a nebude vytvorená ani použitá žiadna relácia zachovať kontext.

4. Súbežná kontrola relácie

Keď sa pokúša používateľ, ktorý je už autentizovaný znova overiť, aplikácia môže danú udalosť vyriešiť jedným z niekoľkých spôsobov. Môže buď zneplatniť aktívnu reláciu používateľa a znova ho autentifikovať pomocou novej relácie, alebo umožniť, aby obe relácie existovali súčasne.

Prvý krok pri povolení súbežnosti riadenie relácie podporuje pridanie nasledujúceho poslucháča do súboru web.xml:

  org.springframework.security.web.session.HttpSessionEventPublisher 

Alebo ho definujte ako fazuľu - takto:

@Bean public HttpSessionEventPublisher httpSessionEventPublisher () {vrátiť nový HttpSessionEventPublisher (); }

To je nevyhnutné na to, aby sa zabezpečilo, že register jarných relácií zabezpečenia je oznámené, keď je relácia zničená.

Povoliť scenár, ktorý umožňuje viac súbežných relácií pre toho istého používateľa, prvok by sa mal použiť v konfigurácii XML:

Alebo prostredníctvom konfigurácie Java:

Konfigurácia @Override protected void (HttpSecurity http) vyvolá výnimku {http.sessionManagement (). MaximumSessions (2)}

5. Časový limit relácie

5.1. Spracovanie časového limitu relácie

Po uplynutí časového limitu relácie, ak používateľ odošle žiadosť s ID relácie s vypršanou platnosťou, budú presmerovaní na adresu URL konfigurovateľnú prostredníctvom priestoru názvov:

Podobne, ak používateľ odošle žiadosť s ID relácie, ktorej platnosť nevypršala, ale úplne neplatný, budú tiež presmerovaní na konfigurovateľnú adresu URL:

 ... 

Zodpovedajúca konfigurácia Java:

http.sessionManagement () .expiredUrl ("/ sessionExpired.html") .invalidSessionUrl ("/ invalidSession.html");

5.2. Nakonfigurujte časový limit relácie pomocou Spring Boot

Hodnotu časového limitu relácie zabudovaného servera môžeme ľahko nakonfigurovať pomocou vlastností:

server.servlet.session.timeout = 15 metrov

Ak neurčíme jednotku trvania, Spring bude predpokladať, že sú to sekundy.

Stručne povedané, s touto konfiguráciou relácia vyprší po 15 minútach nečinnosti. Relácia po tomto časovom období sa považuje za neplatnú.

Ak sme nakonfigurovali náš projekt tak, aby používal Tomcat, musíme mať na pamäti, že podporuje iba presnosť minút pre časový limit relácie, minimálne s jednou minútou. To znamená, že ak zadáme hodnotu časového limitu 170. roky napríklad bude mať za následok časový limit 2 minúty.

Na záver je dôležité spomenúť, že aj keď Spring Session z tohto dôvodu podporuje podobnú vlastnosť (jarné zasadnutie. časový limit), ak to nie je zadané, automatická konfigurácia sa vráti k hodnote vlastnosti, ktorú sme prvýkrát spomenuli.

6. Zabráňte použitiu parametrov URL na sledovanie relácie

Vystavenie informácií o relácii v URL predstavuje rastúce bezpečnostné riziko (z miesta 7 v roku 2007 na miesto 2 v roku 2013 na zozname OWASP Top 10 List).

Počnúc jarom 3.0 je logika prepisovania adries URL, ktorá by pripojila znak jsessionid na adresu URL je teraz možné zakázať nastavením disable-url-rewriting = ”true” v menný priestor.

Alternatívne, počnúc servletom 3.0, je možné mechanizmus sledovania relácií nakonfigurovať aj v serveri web.xml:

 COOKIE 

A programovo:

servletContext.setSessionTrackingModes (EnumSet.of (SessionTrackingMode.COOKIE));

Týmto sa vyberie, kam sa má uložiť JSESSIONID - v súbore cookie alebo v parametri adresy URL.

7. Ochrana fixácie relácie pomocou pružinovej bezpečnosti

Rámec ponúka ochranu pred typickými útokmi na fixáciu relácie konfiguráciou toho, čo sa stane s existujúcou reláciou, keď sa používateľ pokúsi znova autentifikovať:

 ...

Zodpovedajúca konfigurácia Java:

http.sessionManagement () .sessionFixation (). migrateSession ()

V predvolenom nastavení má Spring Security túto ochranu povolenú („migrateSession„) - pri autentifikácii sa vytvorí nová relácia HTTP, stará sa zneplatní a atribúty zo starej relácie sa prekopírujú.

Ak to nie je požadované správanie, sú k dispozícii ďalšie dve možnosti:

• kedy "žiadny”, Pôvodná relácia nebude zneplatnená
• kedy "newSession”Nastavená, vytvorí sa čistá relácia bez toho, aby sa prekopírovali akékoľvek atribúty zo starej relácie

8. Cookie bezpečnej relácie

Ďalej prediskutujeme, ako zabezpečiť náš súbor cookie relácie.

Môžeme použiť httpLen a zabezpečiť príznaky na zabezpečenie nášho súboru cookie relácie:

• Iba http: ak je to pravda, potom skript prehliadača nebude mať prístup k súboru cookie
• zabezpečiť: ak je to pravda, potom bude súbor cookie odoslaný iba cez pripojenie HTTPS

Tieto príznaky pre náš súbor cookie relácie môžeme nastaviť v web.xml:

 1 pravda pravda 

Táto možnosť konfigurácie je k dispozícii od servletu Java 3. V predvolenom nastavení je iba http je pravda a zabezpečiť je nepravdivé.

Pozrime sa tiež na zodpovedajúcu konfiguráciu Java:

verejná trieda MainWebAppInitializer implementuje WebApplicationInitializer {@Override public void onStartup (ServletContext sc) hodí ServletException {// ... sc.getSessionCookieConfig (). setHttpOnly (true); sc.getSessionCookieConfig (). setSecure (true); }}

Ak používame Spring Boot, môžeme tieto príznaky nastaviť v našom application.properties:

server.servlet.session.cookie.http-only = true server.servlet.session.cookie.secure = true

Nakoniec to môžeme dosiahnuť aj manuálne pomocou a Filtrovať:

verejná trieda SessionFilter implementuje filter {@Override public void doFilter (požiadavka ServletRequest, odpoveď ServletResponse, reťazec FilterChain) hodí IOException, ServletException {HttpServletRequest req = (HttpServletRequest) požiadavka; HttpServletResponse res = (HttpServletResponse) odpoveď; Cookie [] allCookies = req.getCookies (); if (allCookies! = null) {cookie session = Arrays.stream (allCookies) .filter (x -> x.getName (). equals ("JSESSIONID")) .findFirst (). orElse (null); if (session! = null) {session.setHttpOnly (true); session.setSecure (true); res.addCookie (relácia); }} chain.doFilter (req, res); }}

9. Práca s reláciou

9.1. Fazuľa s rozsahom pôsobnosti

Fazuľu možno definovať pomocou zasadanie rozsah jednoducho pomocou anotácie @Scope na fazuli deklarovanej vo webovom kontexte:

@Component @Scope („relácia“) verejná trieda Foo {..}

Alebo s XML:

Potom sa fazuľa môže jednoducho vpichnúť do inej fazule:

@Autowired private Foo theFoo;

A jar naviaže novú fazuľu na životný cyklus relácie HTTP.

9.2. Vloženie surovej relácie do kontrolóra

Nespracovanú reláciu HTTP je tiež možné vložiť priamo do súboru Kontrolór metóda:

@RequestMapping (..) public void fooMethod (relácia HttpSession) {session.setAttribute (Constants.FOO, new Foo ()); // ... Foo foo = (Foo) session.getAttribute (Constants.FOO); }

9.3. Získanie surového zasadnutia

Aktuálnu reláciu HTTP je možné získať aj programovo prostredníctvom servera nespracované rozhranie Servlet API:

ServletRequestAttributes attr = (ServletRequestAttributes) RequestContextHolder.currentRequestAttributes (); HttpSession session = attr.getRequest (). GetSession (true); // true == povoliť vytvorenie

10. Záver

V tomto článku sme diskutovali o správe relácií pomocou Spring Security. Spring Reference tiež obsahuje veľmi dobré FAQ o správe relácií.

Ako vždy, kód uvedený v tomto článku je k dispozícii na stránkach Github. Toto je projekt založený na Maven, takže by malo byť ľahké ho importovať a spustiť tak, ako je.