streamalism.org

1. Áttekintés

Ebben a cikkben bemutatjuk, hogyan A Spring Security lehetővé teszi számunkra a HTTP munkamenetek ellenőrzését.

Ez a vezérlés a munkamenet időkorlátjától az egyidejű munkamenetek és egyéb speciális biztonsági konfigurációk engedélyezéséig terjed.

2. Mikor jön létre a munkamenet?

Pontosan szabályozhatjuk, hogy mikor készüljön el a munkamenetünk, és hogyan lépjen kapcsolatba vele a Spring Security:

• mindig- egy munkamenet mindig létrejön, ha még nem létezik ilyen
• ha szükséges- munkamenet csak szükség esetén jön létre (alapértelmezett)
• soha- a keretrendszer soha nem hoz maga létre munkamenetet, de használni fogja, ha már létezik
• hontalan- a Spring Security nem hoz létre és nem használ munkamenetet

...

Java konfiguráció:

A @Orride védett void konfiguráció (HttpSecurity http) a {http.sessionManagement () .sessionCreationPolicy (SessionCreationPolicy.IF_REQUIRED)} kivételt dobja

Nagyon fontos ezt megérteni ez a konfiguráció csak azt ellenőrzi, hogy mit csinál a Spring Security - nem a teljes alkalmazás. Lehet, hogy a Spring Security nem hozza létre a munkamenetet, ha arra utasítjuk, de az alkalmazásunk igen!

Alapértelmezés szerint, A Spring Security akkor hoz létre munkamenetet, amikor szüksége van rá - ez "ha szükséges“.

Mert hontalanabb alkalmazás, a "soha”Opció biztosítja, hogy maga a Spring Security ne hozzon létre munkamenetet; ha azonban az alkalmazás létrehoz egyet, akkor a Spring Security élni fog vele.

Végül a legszigorúbb munkamenet-létrehozási lehetőség - „hontalan" - egy garantálja, hogy az alkalmazás egyáltalán nem hoz létre munkamenetet.

Ezt a 3.1 tavasszal vezették be, és hatékonyan kihagyja a Spring Security szűrőlánc egyes részeit - elsősorban a munkamenethez kapcsolódó részeket, mint pl HttpSessionSecurityContextRepository, SessionManagementFilter, RequestCacheFilter.

Ezeknek a szigorúbb ellenőrzési mechanizmusoknak közvetlen következménye van arra cookie-kat nem használunk és aztán minden egyes kérést újra hitelesíteni kell. Ez a hontalan architektúra jól játszik a REST API-kkal és azok hontalansági korlátjaival. Jól működnek olyan hitelesítési mechanizmusokkal is, mint az alap- és a kivonatolt hitelesítés.

3. A motorháztető alatt

A hitelesítési folyamat végrehajtása előtt a Spring Security lefuttat egy szűrőt, amely felelős a biztonsági kontextus tárolásáért a kérések között SecurityContextPersistenceFilter. A kontextust egy stratégia szerint tároljuk - HttpSessionSecurityContextRepository alapértelmezés szerint - amely a HTTP munkamenetet használja tárhelyként.

A szigorúaknak create-session = "hontalan" attribútummal, ezt a stratégiát felváltja egy másik - NullSecurityContextRepository - és nem hoz létre vagy nem használ munkamenetet hogy megtartsa a kontextust.

4. Egyidejű munkamenet-ellenőrzés

Amikor egy már hitelesített felhasználó megpróbálja hitelesítse újra, az alkalmazás néhány módon kezelheti az eseményt. Vagy érvénytelenítheti a felhasználó aktív munkamenetét, és újból hitelesítheti a felhasználót egy új munkamenettel, vagy engedélyezheti mindkét munkamenet egyidejű létezését.

Az egyidejűség engedélyezésének első lépése session-control támogatás a következő hallgató felvétele a web.xml:

  org.springframework.security.web.session.HttpSessionEventPublisher 

Vagy definiálja babként - az alábbiak szerint:

@Bean public HttpSessionEventPublisher httpSessionEventPublisher () {return new HttpSessionEventPublisher (); }

Ez elengedhetetlen annak biztosításához, hogy a tavaszi biztonsági munkamenet-nyilvántartás az értesítik, amikor a munkamenet megsemmisül.

A forgatókönyv engedélyezéséhez, amely több egyidejű munkamenetet engedélyez ugyanannak a felhasználónak elemet kell használni az XML konfigurációban:

Vagy Java konfiguráción keresztül:

A @Orride védett void konfiguráció (HttpSecurity http) dobja a Kivételt {http.sessionManagement (). MaximumSessions (2)}

5. A munkamenet időkorlátja

5.1. A munkamenet időkorlátjának kezelése

A munkamenet időtúllépése után, ha a felhasználó kérést küld egy lejárt munkamenet azonosító, átirányítják őket a névtéren keresztül konfigurálható URL-re:

Hasonlóképpen, ha a felhasználó egy olyan munkamenet-azonosítóval ellátott kérést küld, amely nem lejárt, hanem teljes egészében érvénytelen, egy konfigurálható URL-re is átirányítják őket:

 ... 

A megfelelő Java konfiguráció:

http.sessionManagement () .expiredUrl ("/ sessionExpired.html") .invalidSessionUrl ("/ érvénytelenSession.html");

5.2. Konfigurálja a munkamenet időtúllépését a tavaszi indítással

Könnyen konfigurálhatjuk a beágyazott szerver Session timeout értékét a tulajdonságok használatával:

server.servlet.session.timeout = 15m

Ha nem adjuk meg az időtartam mértékegységét, akkor Spring feltételezi, hogy ez másodperc.

Dióhéjban, ezzel a konfigurációval, 15 perc inaktivitás után a munkamenet lejár. Az ezen időtartamot követő munkamenet érvénytelennek minősül.

Ha a projektünket Tomcat használatra konfiguráltuk, akkor szem előtt kell tartanunk, hogy az csak a munkamenet időtúllépésének percig tartó pontosságát támogatja, minimum egy perccel. Ez azt jelenti, hogy ha megadunk időtúllépési értéket 170-es évek például 2 perc időkorlátot eredményez.

Végül fontos megemlíteni, hogy annak ellenére, hogy a Tavaszi ülés hasonló tulajdonságot támogat erre a célra (tavasz.szakasz.időtúllépés), ha ez nincs megadva, akkor az automatikus konfiguráció vissza fog térni az általunk először említett tulajdonság értékére.

6. Akadályozza meg az URL-paraméterek használatát a munkamenet-követéshez

A munkamenet információinak az URL-ben való feltárása növekvő biztonsági kockázatot jelent (a 2007. évi 7. helyről a 2013. évi 2. helyre az OWASP Top 10 listáján).

A 3.0 tavasztól kezdődően az URL átírási logikája, amely hozzáfűzi a jsessionid URL-re mostantól letilthatja a disable-url-rewriting = "true" ban,-ben névtér.

Alternatív megoldásként a Servlet 3.0-tól kezdve a munkamenet-követési mechanizmus a web.xml:

 APRÓSÜTEMÉNY 

És programszerűen:

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

Ez kiválasztja a tárolási helyet JSESSIONID - a cookie-ban vagy egy URL-paraméterben.

7. A munkamenet rögzítésének védelme tavaszi biztonsággal

A keretrendszer védelmet nyújt a tipikus munkamenet-rögzítési támadások ellen azáltal, hogy konfigurálja, hogy mi történik egy meglévő munkamenettel, amikor a felhasználó újra megpróbálja hitelesíteni:

 ...

A megfelelő Java konfiguráció:

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

Alapértelmezés szerint a Spring Security engedélyezi ezt a védelmet (“migrateSession“) - a hitelesítéskor egy új HTTP munkamenet jön létre, a régit érvénytelenítik, és a régi munkamenet attribútumait átmásolják.

Ha ez nem a kívánt viselkedés, két másik lehetőség áll rendelkezésre:

• mikor "egyik sem”Be van állítva, az eredeti munkamenet nem lesz érvénytelen
• mikor "newSession”Be van állítva, akkor egy tiszta munkamenet jön létre anélkül, hogy a régi munkamenet egyik attribútuma átkerülne

8. Biztonságos munkamenet Cookie

Ezután megvitatjuk a munkamenet-cookie biztonságossá tételét.

Használhatjuk a Csak http és biztonságos zászlók a munkamenet süti biztosításához:

• Csak http: ha igaz, akkor a böngésző szkriptje nem fogja tudni elérni a cookie-t
• biztonságos: ha igaz, akkor a sütit csak HTTPS kapcsolaton keresztül küldjük el

Beállíthatjuk ezeket a zászlókat a munkamenet süti számára a web.xml:

 1 igaz igaz 

Ez a konfigurációs opció a Java 3 servlet óta elérhető. Alapértelmezés szerint csak http igaz és biztonságos hamis.

Vizsgáljuk meg a megfelelő Java konfigurációt is:

public class MainWebAppInitializer végrehajtja a WebApplicationInitializer {@Override public void onStartup (ServletContext sc) dobja a ServletException {// ... sc.getSessionCookieConfig (). setHttpOnly (true); sc.getSessionCookieConfig (). setSecure (true); }}

Ha a Spring Boot-ot használjuk, beállíthatjuk ezeket a zászlókat alkalmazás.tulajdonságok:

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

Végül ezt manuálisan is elérhetjük az a használatával Szűrő:

public class SessionFilter végrehajtja a {@Override public void doFilter (ServletRequest kérés, ServletResponse válasz, FilterChain lánc) IOException, ServletException {HttpServletRequest req = (HttpServletRequest) kérést; HttpServletResponse res = (HttpServletResponse) válasz; Cookie [] allCookies = req.getCookies (); if (allCookies! = null) {Cookie session = Arrays.stream (allCookies) .filter (x -> x.getName (). egyenlő ("JSESSIONID")) .findFirst (). vagyElse (null); if (session! = null) {session.setHttpOnly (true); session.setSecure (true); res.addCookie (munkamenet); }} chain.doFilter (req, res); }}

9. A munkamenet működése

9.1. Session hatókörű bab

A bab meghatározható a ülés hatókör egyszerűen a webes környezetben deklarált babok @Scope kommentárjának használatával:

@Component @Scope ("session") nyilvános osztály Foo {..}

Vagy XML-lel:

Ezután a bab egyszerűen beadható egy másik babba:

@Autowired privát Foo theFoo;

És tavasz az új babot a HTTP munkamenet életciklusához köti.

9.2. A nyers munkamenet injektálása egy vezérlőbe

A nyers HTTP munkamenet közvetlenül az a-ba is injektálható Vezérlő módszer:

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

9.3. A nyers munkamenet megszerzése

Az aktuális HTTP munkamenet programszerűen is megszerezhető a nyers Servlet API:

ServletRequestAttributes attr = (ServletRequestAttributes) RequestContextHolder.currentRequestAttributes (); HttpSession session = attr.getRequest (). GetSession (true); // true == a létrehozás engedélyezése

10. Következtetés

Ebben a cikkben megvitattuk a munkamenetek kezelését a Spring Security céggel. Ezenkívül a tavaszi referencia nagyon jó GYIK-et tartalmaz a munkamenet-kezelésről.

Mint mindig, az ebben a cikkben bemutatott kód elérhető a Github oldalon. Ez egy Maven-alapú projekt, ezért könnyen importálhatónak és futtathatónak kell lennie.