streamalism.org

1. Oversikt

I denne artikkelen skal vi illustrere hvordan Spring Security lar oss kontrollere HTTP-øktene.

Denne kontrollen spenner fra en tidsavbrudd for økt til aktivering av samtidige økter og andre avanserte sikkerhetskonfigurasjoner.

2. Når blir økten opprettet?

Vi kan kontrollere nøyaktig når økten vår blir opprettet, og hvordan Spring Security vil samhandle med den:

• alltid- en økt vil alltid bli opprettet hvis en ikke allerede eksisterer
• om nødvendig- en økt vil bare bli opprettet om nødvendig (misligholde)
• aldri- rammeverket vil aldri opprette en økt selv, men den vil bruke en hvis den allerede eksisterer
• statsløs- ingen økt vil bli opprettet eller brukt av Spring Security

...

Java-konfigurasjon:

@ Override beskyttet ugyldig konfigurasjon (HttpSecurity http) kaster unntak {http.sessionManagement () .sessionCreationPolicy (SessionCreationPolicy.IF_REQUIRED)}

Det er veldig viktig å forstå det denne konfigurasjonen styrer bare hva Spring Security gjør - ikke hele søknaden. Spring Security kan ikke opprette økten hvis vi instruerer den ikke, men appen vår kan!

Som standard, Spring Security oppretter en økt når den trenger en - dette er "om nødvendig“.

Til en mer statsløs applikasjon, “aldri”Alternativet vil sikre at Spring Security ikke vil opprette noen økt; Imidlertid, hvis applikasjonen oppretter en, vil Spring Security bruke den.

Endelig er det strengeste alternativet for øktopprettelse - “statsløs" - er en garanterer at applikasjonen ikke vil opprette noen økt i det hele tatt.

Dette ble introdusert våren 3.1 og vil effektivt hoppe over deler av Spring Security-filterkjeden - hovedsakelig sesjonsrelaterte deler som HttpSessionSecurityContextRepository, SessionManagementFilter, RequestCacheFilter.

Disse strengere kontrollmekanismene har den direkte implikasjonen at informasjonskapsler brukes ikke og så hver forespørsel må godkjennes på nytt. Denne statsløse arkitekturen spiller bra med REST APIer og deres begrensninger for statsløshet. De fungerer også bra med autentiseringsmekanismer som Basic og Digest Authentication.

3. Under hetten

Før autentiseringsprosessen kjøres, kjører Spring Security et filter som er ansvarlig for å lagre sikkerhetskonteksten mellom forespørslene - SecurityContextPersistenceFilter. Konteksten lagres i henhold til en strategi - HttpSessionSecurityContextRepository som standard - som bruker HTTP-økt som lagring.

For de strenge create-session = ”stateless” attributt, vil denne strategien erstattes med en annen - NullSecurityContextRepository - og ingen økt vil bli opprettet eller brukt for å beholde konteksten.

4. Samtidig øktkontroll

Når en bruker som allerede er godkjent prøver å godkjenne igjen, kan applikasjonen håndtere denne hendelsen på en av få måter. Det kan enten ugyldiggjøre den aktive økten til brukeren og autentisere brukeren igjen med en ny økt, eller la begge øktene eksistere samtidig.

Det første trinnet i å aktivere samtidig økt-kontroll støtte er å legge til følgende lytter i web.xml:

  org.springframework.security.web.session.HttpSessionEventPublisher 

Eller definer det som en bønne - som følger:

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

Dette er viktig for å være sikker på at Spring Security-sesjonsregistret er varslet når økten er ødelagt.

For å aktivere scenariet som tillater flere samtidige økter for den samme brukeren elementet skal brukes i XML-konfigurasjonen:

Eller via Java-konfigurasjon:

@ Override beskyttet ugyldig konfigurasjon (HttpSecurity http) kaster unntak {http.sessionManagement (). MaximumSessions (2)}

5. Tidsavbrudd for økt

5.1. Håndtere øktperioden

Etter at økten er tidsavbrutt, hvis brukeren sender en forespørsel med en utløpt økt-ID, blir de omdirigert til en URL som kan konfigureres via navneområdet:

Tilsvarende hvis brukeren sender en forespørsel med en økt-ID som ikke er utløpt, men helt ugyldig, blir de også omdirigert til en konfigurerbar URL:

 ... 

Tilsvarende Java-konfigurasjon:

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

5.2. Konfigurer sesjonstidsavbrudd med Spring Boot

Vi kan enkelt konfigurere Session timeout-verdien til den innebygde serveren ved hjelp av egenskaper:

server.servlet.session.timeout = 15m

Hvis vi ikke spesifiserer varighetsenheten, vil Spring anta at det er sekunder.

I et nøtteskall, med denne konfigurasjonen, utløper økten etter 15 minutter med inaktivitet. Økten etter denne perioden anses som ugyldig.

Hvis vi konfigurerte prosjektet vårt til å bruke Tomcat, må vi huske at det bare støtter liten presisjon for tidsavbrudd for økten, med minst ett minutt. Dette betyr at hvis vi spesifiserer en timeout-verdi på 170-tallet for eksempel vil det resultere i en tidsavbrudd på to minutter.

Til slutt er det viktig å nevne at selv om Spring Session støtter en lignende eiendom for dette formålet (vår.session.timeout), hvis ikke dette er spesifisert, vil autokonfigurasjonen gå tilbake til verdien på eiendommen vi først nevnte.

6. Forhindre bruk av URL-parametere for øktsporing

Å eksponere øktinformasjon i URL-en er en økende sikkerhetsrisiko (fra sted 7 i 2007 til plass 2 i 2013 på OWASPs topp 10-liste).

Fra og med Spring 3.0, URL-omskrivningslogikken som vil legge til jsessionid til URL kan nå deaktiveres ved å sette disable-url-rewriting = ”true” i navneområdet.

Alternativt, fra og med Servlet 3.0, kan sesjonssporingsmekanismen også konfigureres i web.xml:

 KJEKS 

Og programmatisk:

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

Dette velger hvor du skal lagre JSESSIONID - i informasjonskapselen eller i en URL-parameter.

7. Beskyttelse mot øktfiksering med vårsikkerhet

Rammeverket gir beskyttelse mot typiske Session Fixation-angrep ved å konfigurere hva som skjer med en eksisterende økt når brukeren prøver å autentisere igjen:

 ...

Tilsvarende Java-konfigurasjon:

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

Som standard har Spring Security denne beskyttelsen aktivert (“migrateSession“) - ved autentisering opprettes en ny HTTP-økt, den gamle ugyldiggjøres og attributtene fra den gamle økten kopieres.

Hvis dette ikke er ønsket oppførsel, er to andre alternativer tilgjengelige:

• når "ingen”Er angitt, vil den originale økten ikke bli ugyldiggjort
• når "newSession”Er angitt, vil en ren økt opprettes uten at noen av attributtene fra den gamle økten kopieres

8. Secure Session Cookie

Deretter vil vi diskutere hvordan vi kan sikre øktkaken vår.

Vi kan bruke httpBare og sikre flagg for å sikre øktkaken vår:

• httpBare: hvis det er sant, vil ikke nettleserskriptet ha tilgang til informasjonskapselen
• sikre: hvis det er sant, sendes informasjonskapselen bare via HTTPS-tilkobling

Vi kan sette flaggene for øktkaken vår i web.xml:

 1 sant sant 

Dette konfigurasjonsalternativet er tilgjengelig siden Java-servlet 3. Som standard http-bare er sant og sikre er falsk.

La oss også ta en titt på den tilsvarende Java-konfigurasjonen:

public class MainWebAppInitializer implementerer WebApplicationInitializer {@Override public void onStartup (ServletContext sc) kaster ServletException {// ... sc.getSessionCookieConfig (). setHttpOnly (true); sc.getSessionCookieConfig (). setSecure (true); }}

Hvis vi bruker Spring Boot, kan vi sette disse flaggene i vår application.properties:

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

Til slutt kan vi også oppnå dette manuelt ved å bruke a Filter:

offentlig klasse SessionFilter implementerer Filter {@Override public void doFilter (ServletRequest request, ServletResponse response, FilterChain chain) kaster IOException, ServletException {HttpServletRequest req = (HttpServletRequest) forespørsel; HttpServletResponse res = (HttpServletResponse) respons; Cookie [] allCookies = req.getCookies (); hvis (allCookies! = null) {Cookie-økt = Arrays.stream (allCookies) .filter (x -> x.getName (). tilsvarer ("JSESSIONID")) .findFirst (). eller Else (null); hvis (økt! = null) {session.setHttpOnly (true); session.setSecure (true); res.addCookie (økt); }} chain.doFilter (req, res); }}

9. Arbeide med økten

9.1. Session Scoped Beans

En bønne kan defineres med økt omfang ganske enkelt ved å bruke @Scope-merknaden på bønner deklarert i web-Context:

@Component @Scope ("session") offentlig klasse Foo {..}

Eller med XML:

Deretter kan bønnen bare injiseres i en annen bønne:

@Autowired privat Foo theFoo;

Og våren vil binde den nye bønnen til livssyklusen til HTTP-sesjonen.

9.2. Injisere Raw Session i en kontroller

Den rå HTTP-økten kan også injiseres direkte i en Kontroller metode:

@RequestMapping (..) offentlig ugyldighet fooMethod (HttpSession-økt) {session.setAttribute (Constants.FOO, ny Foo ()); // ... Foo foo = (Foo) session.getAttribute (Constants.FOO); }

9.3. Få Raw Session

Gjeldende HTTP-økt kan også oppnås programmatisk via rå Servlet API:

ServletRequestAttributes attr = (ServletRequestAttributes) RequestContextHolder.currentRequestAttributes (); HttpSession-økt = attr.getRequest (). GetSession (true); // true == tillat oppretting

10. Konklusjon

I denne artikkelen diskuterte vi administrering av økter med vårsikkerhet. Vårreferansen inneholder også en veldig god FAQ om øktledelse.

Som alltid er koden presentert i denne artikkelen tilgjengelig på Github. Dette er et Maven-basert prosjekt, så det skal være enkelt å importere og kjøre som det er.