streamalism.org

1. Oversigt

Denne tutorial viser hvordan man bruger HTTPS til at beskytte din applikations login-side ved hjælp af Spring's Channel Security-funktion.

Brug af HTTPS til godkendelse er afgørende for at beskytte integriteten af ​​følsomme data under transport.

Artiklen bygger på toppen af ​​Spring Security Login-tutorial ved at tilføje et ekstra sikkerhedslag. Vi fremhæver de nødvendige trin for at sikre godkendelsesdataene ved at betjene login-siden gennem den kodede HTTPS-kanal.

2. Første opsætning uden kanalsikkerhed

Lad os starte med sikkerhedskonfigurationen forklaret i den førnævnte artikel.

Webappen giver brugerne adgang til:

1. /anonym.html uden godkendelse,
2. /login.htmlog
3. andre sider (/hjemmeside.html) efter et vellykket login.

Adgangen styres af følgende konfiguration:

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

Eller via XML:

På dette tidspunkt er login-siden tilgængelig på:

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

Brugere er i stand til at godkende sig selv via HTTP, men dette er usikkert, da adgangskoder sendes i almindelig tekst.

3. HTTPS-serverkonfiguration

At kun levere login-siden via HTTPS – din webserver skal kunne tjene HTTPS-sider. Dette kræver, at SSL / TLS-understøttelse er aktiveret.

Bemærk, at du enten kan bruge et gyldigt certifikat eller til testformål kan du generere dit eget.

Lad os sige, at vi bruger Tomcat og kører vores eget certifikat. Vi bliver først nødt til at oprette en keystore med et selvsigneret certifikat.

Generering af keystore kan udføres med følgende kommando i terminalen:

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

Dette opretter en privat nøgle og et selvsigneret certifikat i standardnøglelageret til din brugerprofil i din hjemmemappe.

Det næste trin er at redigere conf / server.xml for at få det til at se sådan ud:

Den anden SSL / TLS tag kommenteres normalt i konfigurationsfilen, så det er alt, hvad der er behov for at kommentere og tilføje keystore-oplysninger. Yderligere information findes i Tomcats relaterede dokumentation.

Med HTTPS-konfigurationen på plads kan login-siden nu også serveres under følgende URL:

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

Andre webservere end Tomcat ville kræve en anden, men sandsynligvis lignende konfiguration.

4. Konfiguration af kanalsikkerhed

På dette tidspunkt er vi i stand til at betjene login siden både under HTTP og HTTPS. Dette afsnit forklarer, hvordan man kan anvende HTTPS.

At kræve HTTPS til login-siden rediger din sikkerhedskonfiguration ved at tilføje følgende:

http.requiresChannel () .antMatchers ("/ login *"). kræverSecure ();

Eller tilføj kræver-kanal = ”https” attribut til din XML-konfiguration:

Efter dette punkt kunne brugerne kun logge ind via HTTPS. Alle relative links f.eks. en frem til /hjemmeside.html vil arve protokollen for den oprindelige anmodning og vil blive forkyndt under HTTPS.

Når du blander HTTP og HTTPS-anmodning i en enkelt webapp, er der yderligere aspekter, du skal være opmærksom på, og som kræver yderligere konfiguration.

5. Blanding af HTTP og HTTPS

Fra sikkerhedsperspektivet er det god praksis og et solidt mål at have alt over HTTPS.

Men hvis udelukkende anvendelse af HTTPS ikke er en mulighed, kan vi konfigurere Spring til at bruge HTTP ved at tilføje følgende til konfigurationen:

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

Eller tilføj kræver-kanal = ”http” attributter til XML:

Dette instruerer Spring til at bruge HTTP til alle anmodninger, der ikke er udtrykkeligt konfigureret til at bruge HTTPS, men samtidig bryder den den oprindelige login-mekanisme. De følgende afsnit forklarer den bagvedliggende årsag.

5.1. En brugerdefineret login-behandlings-URL via HTTPS

Sikkerhedskonfigurationen i den originale sikkerhedsvejledning indeholder følgende:

Uden at tvinge / udfør_login at bruge HTTPS vil en omdirigering ske med HTTP-varianten af ​​det og miste loginoplysningerne sendt med den oprindelige anmodning.

For at løse dette er vi nødt til at konfigurere Spring til at bruge HTTPS til behandlings-URL:

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

Bemærk det ekstra argument / udfør_login videregivet til antMatchers metode.

Det tilsvarende i XML-konfigurationen kræver tilføjelse af en ny <intercept-url> element til konfigurationen:

Hvis din egen applikation bruger standard login-behandling-url (som er /Log på) behøver du ikke at konfigurere dette eksplicit som /Log på* mønster dækker det allerede.

Med konfigurationen på plads er brugerne i stand til at logge ind, men ikke få adgang til godkendte sider, f.eks. /hjemmeside.html under HTTP-protokollen på grund af Springs beskyttelsesfunktion til sessionsfiksering.

5.2. Deaktiverer session-fiksering-beskyttelse

Sessionsfiksering er et problem, som ikke kan undgås, når du skifter mellem HTTP og HTTPS.

Som standard opretter Spring et nyt Sessions ID efter et vellykket login. Når en bruger indlæser HTTPS login-siden brugerens Sessions ID cookie markeres som sikker. Efter at have logget ind, skifter konteksten til HTTP, og cookien går tabt, da HTTP er usikker.

For at undgå dette sening session-fiksering-beskyttelse til ingen er påkrævet.

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

Eller via XML:

Deaktivering af beskyttelse af sessionfiksering kan have sikkerhedsmæssige konsekvenserDerfor er du nødt til at afveje fordele og ulemper, hvis du er bekymret for sessionfikseringsbaserede angreb.

6. Test

Efter at have anvendt alle disse konfigurationsændringer adgang /anonym.html uden at logge ind (ved hjælp af en // eller //) videresender dig til siden via HTTP.

Åbning af andre sider direkte som /hjemmeside.html skulle få dig videresendt til login siden via HTTPS, og efter login vil du blive videresendt tilbage til /hjemmeside.html ved hjælp af HTTP.

7. Konklusion

I denne vejledning har vi taget et kig på, hvordan man konfigurerer en Spring-webapplikation, der kommunikerer via HTTP undtagen login-mekanismen. Imidlertid nye moderne webapplikationer skal næsten altid udelukkende bruge HTTPS som deres kommunikationsprotokol. Sænkning af sikkerhedsniveauer eller deaktivering af sikkerhedsfunktioner (som f.eks session-fixering-beskyttelse) er aldrig en god idé.

Denne vejledning er baseret på den codebase, der er tilgængelig på GitHub. Kanalsikkerhedskonfigurationen kan aktiveres ved en liste https som en aktiv forårsprofil.