streamalism.org

1. Overzicht

Deze tutorial laat zien hoe u HTTPS gebruikt om de aanmeldingspagina van uw toepassing te beschermen met behulp van Spring's Channel Security-functie.

Het gebruik van HTTPS voor authenticatie is cruciaal om de integriteit van gevoelige gegevens tijdens transport te beschermen.

Het artikel bouwt voort op de Spring Security Login-zelfstudie door een extra beveiligingslaag toe te voegen. We benadrukken de stappen die nodig zijn om de authenticatiegegevens te beveiligen door de inlogpagina te bedienen via het gecodeerde HTTPS-kanaal.

2. Eerste installatie zonder kanaalbeveiliging

Laten we beginnen met de beveiligingsconfiguratie die in het bovengenoemde artikel wordt uitgelegd.

De web-app geeft gebruikers toegang tot:

1. /anonymous.html zonder authenticatie,
2. /login.html, en
3. andere pagina's (/homepage.html) na een succesvolle login.

De toegang wordt gecontroleerd door de volgende configuratie:

@Override protected void configure (HttpSecurity http) genereert uitzondering {http.authorizeRequests () .antMatchers ("/ anonymous *") .anonymous (); http.authorizeRequests () .antMatchers ("/ login *") .permitAll (); http.authorizeRequests () .anyRequest () .authenticated (); 

Of via XML:

Op dit moment is de inlogpagina beschikbaar op:

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

Gebruikers kunnen zichzelf verifiëren via HTTP, maar dit is onveilig omdat wachtwoorden in platte tekst worden verzonden.

3. HTTPS-serverconfiguratie

Om de inlogpagina alleen via HTTPS te bezorgen – uw webserver moet HTTPS-pagina's kunnen bedienen. Dit vereist dat SSL / TLS-ondersteuning is ingeschakeld.

Merk op dat u een geldig certificaat kunt gebruiken of, voor testdoeleinden, uw eigen certificaat kunt genereren.

Laten we zeggen dat we Tomcat gebruiken en ons eigen certificaat rollen. We zullen eerst een keystore met een zelfondertekend certificaat.

Het genereren van de keystore kan worden gedaan door het volgende commando in de terminal te geven:

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

Dit zal een persoonlijke a-sleutel en een zelfondertekend certificaat creëren in de standaard keystore voor uw gebruikersprofiel, in uw thuismap.

De volgende stap is om te bewerken conf / server.xml om het er zo uit te laten zien:

De tweede SSL / TLS tag wordt meestal uitgecommentarieerd in het configuratiebestand, dus het verwijderen van commentaar en het toevoegen van keystore-informatie is alles wat nodig is. Meer informatie is beschikbaar in de gerelateerde documentatie van Tomcat.

Met de HTTPS-configuratie kan de inlogpagina nu ook onder de volgende URL worden bediend:

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

Andere webservers dan Tomcat zouden een andere, maar waarschijnlijk vergelijkbare configuratie vereisen.

4. Kanaalbeveiliging configureren

Op dit punt kunnen we de inlogpagina zowel onder HTTP als HTTPS bedienen. In dit gedeelte wordt uitgelegd hoe u het gebruik van HTTPS verplicht stelt.

HTTPS vereisen voor de inlogpagina wijzig uw beveiligingsconfiguratie door het volgende toe te voegen:

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

Of voeg het vereist-channel = "https" attribuut aan uw XML-configuratie:

Na dit punt konden gebruikers alleen inloggen via HTTPS. Alle relatieve links, bijv. een vooruit naar /homepage.html zal het protocol van het oorspronkelijke verzoek overnemen en zal worden aangeboden onder HTTPS.

Bij het combineren van HTTP- en HTTPS-verzoeken in een enkele web-app, zijn er extra aspecten waar u op moet letten en die verdere configuratie vereisen.

5. Mixen van HTTP en HTTPS

Vanuit beveiligingsperspectief is alles bedienen via HTTPS een goede gewoonte en een solide doel om te hebben.

Als het echter niet mogelijk is om uitsluitend HTTPS te gebruiken, kunnen we Spring configureren om HTTP te gebruiken door het volgende aan de configuratie toe te voegen:

http.requiresChannel () .anyRequest (). vereistInsecure ();

Of voeg toe vereist-channel = "http" attributen aan de XML:

Dit instrueert Spring om HTTP te gebruiken voor alle verzoeken die niet expliciet zijn geconfigureerd om HTTPS te gebruiken, maar tegelijkertijd breekt het het oorspronkelijke inlogmechanisme. In de volgende secties wordt de onderliggende oorzaak uitgelegd.

5.1. Een aangepaste login-verwerkings-URL via HTTPS

De beveiligingsconfiguratie in de originele beveiligingshandleiding bevat het volgende:

Zonder te forceren / perform_login om HTTPS te gebruiken, zou er een omleiding gebeuren met de HTTP-variant ervan, waardoor de inloggegevens verloren gaan verzonden met het oorspronkelijke verzoek.

Om dit te verhelpen, moeten we Spring configureren om HTTPS te gebruiken voor de verwerkings-URL:

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

Let op het extra argument / perform_login doorgegeven aan de antMatchers methode.

Het equivalent in de XML-configuratie vereist het toevoegen van een nieuw <intercept-url> element naar de configuratie:

Als uw eigen applicatie de default login-verwerking-url (dat is /Log in) hoeft u dit niet expliciet te configureren als de /Log in* patroon dekt dat al.

Met de configuratie op zijn plaats kunnen gebruikers inloggen, maar hebben ze geen toegang tot geauthenticeerde pagina's, bijv. /homepage.html onder het HTTP-protocol, vanwege de beveiligingsfunctie voor sessiefixatie van Spring.

5.2. Uitschakelen sessie-fixatie-bescherming

Sessiefixatie is een probleem dat niet kan worden vermeden bij het schakelen tussen HTTP en HTTPS.

Spring maakt standaard een nieuw sessie-id na een succesvolle login. Wanneer een gebruiker de HTTPS-inlogpagina laadt van de gebruiker sessie-id cookie wordt gemarkeerd als veilig. Na het inloggen schakelt de context naar HTTP en gaat de cookie verloren omdat HTTP onveilig is.

Om dit te vermijden setting sessie-fixatie-bescherming naar geen Is benodigd.

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

Of via XML:

Het uitschakelen van Session Fixation-bescherming kan gevolgen hebben voor de veiligheidDaarom moet u de voor- en nadelen afwegen als u zich zorgen maakt over op sessiefixatie gebaseerde aanvallen.

6. Test

Na het toepassen van al deze configuratiewijzigingen, opent u /anonymous.html zonder in te loggen (met een van beide // of //) stuurt u door naar de pagina via HTTP.

Andere pagina's direct openen zoals /homepage.html moet u doorgestuurd krijgen naar de inlogpagina via HTTPS en na het inloggen wordt u teruggestuurd naar /homepage.html met behulp van HTTP.

7. Conclusie

In deze tutorial hebben we bekeken hoe je een Spring-webtoepassing configureert die communiceert via HTTP, met uitzondering van het inlogmechanisme. Echter nieuwe moderne webapplicaties zouden bijna altijd uitsluitend HTTPS moeten gebruiken als hun communicatieprotocol. Beveiligingsniveaus verlagen of beveiligingsfuncties uitschakelen (zoals sessie-fixatie-bescherming) is nooit een goed idee.

Deze tutorial is gebaseerd op de codebase die beschikbaar is op GitHub. De kanaalbeveiligingsconfiguratie kan worden ingeschakeld door een opsomming te geven https als een actief Spring-profiel.