streamalism.org

1. Oversikt

Denne opplæringen viser hvordan du bruker HTTPS for å beskytte applikasjonens påloggingsside ved hjelp av Spring's Channel Security-funksjon.

Å bruke HTTPS for autentisering er avgjørende for å beskytte integriteten til sensitive data under transport.

Artikkelen bygger på Spring Security Login-opplæringen ved å legge til et ekstra sikkerhetslag. Vi fremhever trinnene som trengs for å sikre autentiseringsdataene ved å betjene påloggingssiden gjennom den kodede HTTPS-kanalen.

2. Første oppsett uten kanalsikkerhet

La oss starte med sikkerhetskonfigurasjonen forklart i nevnte artikkel.

Nettappen lar brukerne få tilgang til:

1. /anonym.html uten autentisering,
2. /login.html, og
3. andre sider (/hjemmeside.html) etter en vellykket pålogging.

Tilgangen styres av følgende konfigurasjon:

@ Override beskyttet ugyldig konfigurering (HttpSecurity http) kaster Unntak {http.authorizeRequests () .antMatchers ("/ anonym *"). Anonym (); http.authorizeRequests () .antMatchers ("/ login *") .permitAll (); http.authorizeRequests () .anyRequest () .authenticated (); 

Eller via XML:

På dette tidspunktet er påloggingssiden tilgjengelig på:

//localhost:8080/spring-security-login/login.html

Brukere er i stand til å autentisere seg selv via HTTP, men dette er usikkert da passord blir sendt i ren tekst.

3. HTTPS-serverkonfigurasjon

Å bare levere påloggingssiden over HTTPS – webserveren din må kunne levere HTTPS-sider. Dette krever at SSL / TLS-støtte er aktivert.

Merk at du enten kan bruke et gyldig sertifikat eller, for testformål, kan du generere ditt eget.

La oss si at vi bruker Tomcat og ruller vårt eget sertifikat. Vi må først lage en keystore med et selvsignert sertifikat.

Generering av keystore kan gjøres ved å utstede følgende kommando i terminalen:

keytool -genkey -alias tomcat -keyalg RSA -storepass changeit -keypass changeit -dname 'CN = tomcat'

Dette vil opprette en privat a-nøkkel og et selvsignert sertifikat i standard nøkkellager for brukerprofilen din, i hjemmemappen din.

Neste trinn er å redigere conf / server.xml for å få det til å se slik ut:

Den andre SSL / TLS tag blir vanligvis kommentert i konfigurasjonsfilen, så det er ikke nødvendig å kommentere og legge til keystore-informasjon. Mer informasjon er tilgjengelig i Tomcats relaterte dokumentasjon.

Med HTTPS-konfigurasjonen på plass kan påloggingssiden nå også serveres under følgende URL:

//localhost:8443/spring-security-login/login.html

Andre webservere enn Tomcat vil kreve en annen, men sannsynligvis lignende konfigurasjon.

4. Konfigurere kanalsikkerhet

På dette tidspunktet er vi i stand til å betjene påloggingssiden både under HTTP og HTTPS. Denne delen forklarer hvordan du kan mandatere bruken av HTTPS.

Å kreve HTTPS for påloggingssiden endre sikkerhetskonfigurasjonen ved å legge til følgende:

http.requiresChannel () .antMatchers ("/ login *"). requiresSecure ();

Eller legg til krever-kanal = ”https” attributt til XML-konfigurasjonen din:

Etter dette punktet kunne brukerne bare logge inn via HTTPS. Alle relative lenker f.eks. en frem til /hjemmeside.html vil arve protokollen til den opprinnelige forespørselen og vil bli servert under HTTPS.

Når du blander HTTP og HTTPS-forespørsel i en enkelt webapp, er det flere aspekter å være oppmerksom på, og som krever ytterligere konfigurering.

5. Blanding av HTTP og HTTPS

Fra sikkerhetsperspektivet er det god praksis å servere alt over HTTPS og et solid mål å ha.

Imidlertid, hvis bruk av HTTPS utelukkende ikke er et alternativ, kan vi konfigurere våren til å bruke HTTP ved å legge til følgende i konfigurasjonen:

http.requiresChannel () .anyRequest (). requiresInsecure ();

Eller legg til krever-kanal = ”http” attributter til XML:

Dette instruerer våren om å bruke HTTP for alle forespørsler som ikke er eksplisitt konfigurert til å bruke HTTPS, men samtidig bryter den den opprinnelige påloggingsmekanismen. De følgende avsnittene forklarer den underliggende årsaken.

5.1. En URL for behandling av egendefinert pålogging over HTTPS

Sikkerhetskonfigurasjonen i den opprinnelige sikkerhetsopplæringen inneholder følgende:

Uten å tvinge / perform_login å bruke HTTPS, vil en omdirigering skje med HTTP-varianten av den, og miste påloggingsinformasjonen sendt med den opprinnelige forespørselen.

For å overvinne dette må vi konfigurere våren til å bruke HTTPS for behandlings-URL:

http.requiresChannel () .antMatchers ("/ login *", "/ perform_login");

Legg merke til det ekstra argumentet / perform_login overført til antMatchers metode.

Tilsvarende i XML-konfigurasjonen krever å legge til en ny <intercept-url> element til konfigurasjonen:

Hvis din egen applikasjon bruker standard login-processing-url (som er /Logg Inn) du trenger ikke å konfigurere dette eksplisitt som /Logg Inn* mønster dekker allerede det.

Med konfigurasjonen på plass, kan brukerne logge inn, men ikke få tilgang til autentiserte sider, f.eks. /hjemmeside.html under HTTP-protokollen, på grunn av vårens beskyttelsesfunksjon for øktfiksering.

5.2. Deaktivering økt-fiksering-beskyttelse

Sesjonsfiksering er et problem som ikke kan unngås når du bytter mellom HTTP og HTTPS.

Som standard oppretter Spring en ny øktnummer etter en vellykket pålogging. Når en bruker laster inn HTTPS-påloggingssiden brukerens øktnummer informasjonskapsel vil bli merket som sikre. Etter innlogging bytter konteksten til HTTP, og informasjonskapselen går tapt ettersom HTTP er usikker.

For å unngå dette setting økt-fiksering-beskyttelse til ingen kreves.

http.sessionManagement () .sessionFixation () .none ();

Eller via XML:

Deaktivering av øktfiksering kan ha sikkerhetsmessige konsekvenserDerfor må du veie fordeler og ulemper hvis du er bekymret for angrep basert på øktfiksering.

6. Test

Etter å ha brukt alle disse konfigurasjonsendringene, får du tilgang til /anonym.html uten å logge på (bruker enten // eller //) videresender deg til siden via HTTP.

Åpne andre sider direkte som /hjemmeside.html skal få deg videre til påloggingssiden via HTTPS, og etter pålogging blir du videresendt tilbake til /hjemmeside.html bruker HTTP.

7. Konklusjon

I denne opplæringen har vi sett på hvordan du konfigurerer et Spring-webapplikasjon som kommuniserer via HTTP bortsett fra påloggingsmekanismen. derimot nye moderne webapplikasjoner bør nesten alltid bruke HTTPS utelukkende som kommunikasjonsprotokoll. Senke sikkerhetsnivåer eller slå av sikkerhetsfunksjoner (som f.eks økt-fiksering-beskyttelse) er aldri en god idé.

Denne opplæringen er basert på kodebasen som er tilgjengelig på GitHub. Kanalsikkerhetskonfigurasjonen kan aktiveres ved oppføring https som en aktiv vårprofil.