streamalism.org

1. Pregled

Ovaj tutorial pokazuje kako koristiti HTTPS za zaštitu stranice za prijavu vašeg programa pomoću značajke Spring Security Channel.

Korištenje HTTPS-a za provjeru autentičnosti presudno je za zaštitu integriteta osjetljivih podataka tijekom transporta.

Članak se nadovezuje na tutorial Spring Security Login dodavanjem dodatnog sloja sigurnosti. Ističemo korake potrebne za zaštitu podataka za provjeru autentičnosti posluživanjem stranice za prijavu putem kodiranog HTTPS kanala.

2. Početno postavljanje bez zaštite kanala

Krenimo od sigurnosne konfiguracije objašnjene u gore spomenutom članku.

Web-aplikacija omogućuje korisnicima pristup:

1. /anonymous.html bez autentifikacije,
2. /login.html, i
3. ostale stranice (/homepage.html) nakon uspješne prijave.

Pristup kontrolira sljedeća konfiguracija:

@Override zaštićena void konfiguracija (HttpSecurity http) baca Exception {http.authorizeRequests () .antMatchers ("/ anonimni *") .anonymous (); http.authorizeRequests () .antMatchers ("/ login *") .permitAll (); http.authorizeRequests () .anyRequest () .authenticated (); 

Ili putem XML-a:

Trenutno je stranica za prijavu dostupna na:

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

Korisnici se mogu autentificirati putem HTTP-a, međutim to nije sigurno jer će se lozinke slati u običnom tekstu.

3. Konfiguracija HTTPS poslužitelja

Da biste stranicu za prijavu isporučili samo putem HTTPS-a – vaš web-poslužitelj mora moći posluživati ​​HTTPS stranice. To zahtijeva da je omogućena podrška za SSL / TLS.

Imajte na umu da možete koristiti valjani certifikat ili, u svrhu testiranja, možete generirati vlastiti.

Recimo da koristimo Tomcat i valjamo vlastiti certifikat. Prvo ćemo morati stvoriti pohrana ključeva sa samopotpisanom potvrdom.

Generiranje pohrane ključeva može se izvršiti izdavanjem sljedeće naredbe u terminalu:

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

To će stvoriti privatni ključ i samopotpisani certifikat u zadanoj pohrani ključeva za vaš korisnički profil, u vašoj matičnoj mapi.

Sljedeći je korak uređivanje conf / server.xml kako bi izgledalo ovako:

Drugi SSL / TLS oznaka obično se komentira u konfiguracijskoj datoteci, tako da je potrebno samo komentiranje i dodavanje podataka o pohrani ključeva. Dodatne informacije dostupne su u Tomcat-ovoj dokumentaciji.

S postavljenom HTTPS konfiguracijom, stranica za prijavu sada se može posluživati ​​i pod sljedećim URL-om:

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

Web-poslužitelji koji nisu Tomcat zahtijevali bi drugačiju, ali vjerojatno sličnu konfiguraciju.

4. Konfiguriranje sigurnosti kanala

U ovom smo trenutku u mogućnosti poslužiti stranicu za prijavu i pod HTTP i HTTPS. Ovaj odjeljak objašnjava kako odrediti upotrebu HTTPS-a.

Da biste zahtijevali HTTPS za stranicu za prijavu izmijenite svoju sigurnosnu konfiguraciju dodavanjem sljedećeg:

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

Ili dodajte zahtijeva-channel = ”https” atribut vašoj XML konfiguraciji:

Nakon ovog trenutka korisnici su se mogli prijaviti samo putem HTTPS-a. Sve relativne poveznice npr. naprijed prema /homepage.html naslijedit će protokol izvornog zahtjeva i služit će se pod HTTPS-om.

Kada miješate HTTP i HTTPS zahtjev unutar jedne web aplikacije, postoje dodatni aspekti kojih morate biti svjesni i koji zahtijevaju daljnju konfiguraciju.

5. Miješanje HTTP-a i HTTPS-a

Iz sigurnosne perspektive, posluživanje svega putem HTTPS-a dobra je praksa i solidan cilj.

Međutim, ako korištenje HTTPS-a isključivo nije opcija, Spring možemo konfigurirati da koristi HTTP dodavanjem sljedećeg u config:

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

Ili dodajte zahtijeva-channel = ”http” atributi za XML:

Ovo upućuje Spring da koristi HTTP za sve zahtjeve koji nisu eksplicitno konfigurirani za upotrebu HTTPS-a, ali istodobno prekida izvorni mehanizam prijave. Sljedeći odjeljci objašnjavaju osnovni uzrok.

5.1. Prilagođeni URL za obradu prijave preko HTTPS-a

Sigurnosna konfiguracija u izvornom vodiču o sigurnosti sadrži sljedeće:

Bez forsiranja / izvesti_login da se koristi HTTPS, preusmjeravanje bi se dogodilo na njegovu HTTP varijantu, gubeći podatke za prijavu poslana s izvornim zahtjevom.

Da bismo to prevladali, moramo konfigurirati Spring da koristi HTTPS za URL obrade:

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

Primijetite dodatni argument / izvesti_login prešao u Mravi Mravi metoda.

Ekvivalent u XML konfiguraciji zahtijeva dodavanje novog <presresti-url> element u konfiguraciji:

Ako vaša vlastita aplikacija koristi zadanu postavku prijava-obrada-url (koji je /prijaviti se) ovo ne trebate eksplicitno konfigurirati kao /prijaviti se* uzorak to već pokriva.

S postavljenom konfiguracijom, korisnici se mogu prijaviti, ali ne i pristupiti autentificiranim stranicama, na pr. /homepage.html pod HTTP protokolom, zbog značajke zaštite fiksiranja sesije Springa.

5.2. Onemogućivanje sesija-fiksacija-zaštita

Fiksiranje sesije problem je koji se ne može izbjeći prilikom prebacivanja između HTTP-a i HTTPS-a.

Prema zadanim postavkama Spring stvara novi id sesije nakon uspješne prijave. Kada korisnik učita HTTPS stranicu za prijavu korisnika id sesije kolačić će biti označen kao siguran. Nakon prijave kontekst će se prebaciti na HTTP i kolačić će se izgubiti jer HTTP nije siguran.

Da bi se to izbjeglo setting sesija-fiksacija-zaštita do nijedna je potrebno.

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

Ili putem XML-a:

Onemogućavanje zaštite fiksacije sesije može imati sigurnosne implikacije, stoga morate izvagati prednosti i nedostatke ako ste zabrinuti zbog napada na temelju fiksiranja sesija.

6. Test

Nakon primjene svih ovih promjena konfiguracije pristupa /anonymous.html bez prijave (koristeći bilo koji // ili //) proslijedit će vas na stranicu putem HTTP-a.

Otvaranje drugih stranica izravno poput /homepage.html bi vas trebao proslijediti na stranicu za prijavu putem HTTPS-a, a nakon prijave bit ćete preusmjereni na /homepage.html pomoću HTTP-a.

7. Zaključak

U ovom smo uputstvu pogledali kako konfigurirati web-aplikaciju Spring koja komunicira putem HTTP-a, osim mehanizma za prijavu. Međutim nove moderne web-aplikacije gotovo bi uvijek trebale koristiti isključivo HTTPS kao njihov komunikacijski protokol. Snižavanje razine sigurnosti ili isključivanje sigurnosnih značajki (poput sesija-fiksacija-zaštita) nikad nije dobra ideja.

Ovaj se vodič temelji na kodnoj bazi dostupnoj na GitHubu. Konfiguracija sigurnosti kanala može se omogućiti popisom https kao aktivni proljetni profil.