streamalism.org

1. Áttekintés

Ez az oktatóanyag megmutatja hogyan lehet a HTTPS-t használni az alkalmazás bejelentkezési oldalának védelme érdekében a Spring's Channel Security funkció használatával.

A HTTPS használata hitelesítéshez elengedhetetlen az érzékeny adatok integritásának védelme érdekében szállítás közben.

A cikk a tavaszi biztonsági bejelentkezés oktatóprogram tetejére épül egy további biztonsági réteg hozzáadásával. Kiemeljük a hitelesítési adatok biztonságához szükséges lépéseket azáltal, hogy a bejelentkezési oldalt a kódolt HTTPS csatornán keresztül szolgáltatjuk ki.

2. Kezdeti beállítás csatorna biztonság nélkül

Kezdjük a fent említett cikkben ismertetett biztonsági konfigurációval.

A webalkalmazás lehetővé teszi a felhasználók számára az alábbiak elérését:

1. /anonymous.html hitelesítés nélkül,
2. /login.html, és
3. egyéb oldalak (/homepage.html) sikeres bejelentkezés után.

A hozzáférést a következő konfiguráció vezérli:

A @Orride protected void configure (HttpSecurity http) dobja a Kivételt {http.authorizeRequests () .antMatchers ("/ anonymous *") .anonymous (); http.authorizeRequests () .antMatchers ("/ login *") .permitAll (); http.authorizeRequests () .anyRequest () .authenticated (); 

Vagy XML-en keresztül:

Ezen a ponton a bejelentkezési oldal elérhető:

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

A felhasználók képesek hitelesíteni magukat HTTP-n keresztül, azonban ez nem biztonságos, mivel a jelszavakat egyszerű szövegben küldik el.

3. HTTPS kiszolgáló konfigurálása

Csak a bejelentkezési oldal HTTPS-en keresztül történő kézbesítéséhez – webszerverének képesnek kell lennie a HTTPS-oldalak kiszolgálására. Ehhez engedélyezni kell az SSL / TLS támogatást.

Ne feledje, hogy használhat érvényes tanúsítványt, vagy tesztelési célból létrehozhatja saját.

Tegyük fel, hogy Tomcat-ot használunk, és saját tanúsítványunkat forgatjuk. Először létre kell hoznunk a kulcstár saját aláírású tanúsítvánnyal.

A kulcstároló létrehozása a következő parancs kiadásával történhet a terminálon:

keytool -genkey -alias tomcat -keyalg RSA -storepass changeit -keypass changeit -név 'CN = tomcat'

Ez létrehoz egy privát kulcsot és egy önaláírt tanúsítványt a felhasználói profil alapértelmezett kulcstárában, az otthoni mappában.

A következő lépés a szerkesztés conf / server.xml hogy így nézzen ki:

A második SSL / TLS A címkét általában a konfigurációs fájlban kommentelik, így csak a megjegyzésmentéshez és a kulcstár információ hozzáadásához van szükség. További információ a Tomcat kapcsolódó dokumentációjában található.

A HTTPS konfigurációval a bejelentkezési oldal mostantól a következő URL alatt is kiszolgálható:

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

A Tomcat-tól eltérő webszerverekhez más, de valószínűleg hasonló konfigurációra lenne szükség.

4. A csatorna biztonságának konfigurálása

Ezen a ponton tudjuk a bejelentkezési oldalt kiszolgálni HTTP és HTTPS alatt is. Ez a szakasz elmagyarázza, hogyan lehet megbízni a HTTPS használatát.

Ha HTTPS-t igényel a bejelentkezési oldalhoz módosítsa a biztonsági konfigurációt a következők hozzáadásával:

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

Vagy adja hozzá a needs-channel = "https" attribútum az XML konfigurációhoz:

Ezt követően a felhasználók csak HTTPS-en keresztül tudtak bejelentkezni. Minden relatív link pl. egy előre /homepage.html örökölni fogja az eredeti kérés protokollját, és HTTPS alatt fogják kiszolgálni.

Amikor a HTTP és a HTTPS kérelmet egyetlen webalkalmazásban keveri, további szempontokat kell figyelembe venni, amelyek további konfigurálást igényelnek.

5. A HTTP és a HTTPS keverése

Biztonsági szempontból a HTTPS-en keresztül történő minden szolgáltatás jó gyakorlat és szilárd cél.

Ha azonban kizárólag a HTTPS használata nem lehetséges, akkor konfigurálhatjuk a Spring-et a HTTP használatára az alábbiak csatolásával a konfigurációhoz:

http.requiresChannel () .anyRequest (). requiredInsecure ();

Vagy add hozzá needs-channel = "http" attribútumok az XML-hez:

Ez arra utasítja Springet, hogy használja a HTTP-t minden olyan kéréshez, amely nincs kifejezetten konfigurálva a HTTPS használatára, ugyanakkor megszakítja az eredeti bejelentkezési mechanizmust. A következő szakaszok elmagyarázzák az okot.

5.1. Egyéni bejelentkezési URL feldolgozása HTTPS-en keresztül

Az eredeti oktatóanyag biztonsági konfigurációja a következőket tartalmazza:

Erőltetés nélkül / perform_login a HTTPS használata esetén az átirányítás megtörténne a HTTP változatával, elveszítve a bejelentkezési információkat az eredeti kéréssel együtt küldték el.

Ennek leküzdéséhez be kell állítanunk Springet, hogy a HTTPS-t használja az URL feldolgozásához:

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

Figyelje meg az extra érvet / perform_login átadta a antMatchers módszer.

Az XML konfiguráció megfelelőjéhez meg kell adni egy újat <intercept-url> elem a confighoz:

Ha a saját alkalmazásod használja az alapértelmezettet login-processing-url (ami /Belépés) nem kell ezt kifejezetten a /Belépés* minta már ezt fedi.

A konfigurációval a felhasználók bejelentkezhetnek, de nem férhetnek hozzá hitelesített oldalakhoz pl. /homepage.html a HTTP protokoll alatt, a Spring munkamenet rögzítésének védelme miatt.

5.2. Letiltás session-fixation-protection

A munkamenet rögzítése olyan probléma, amelyet nem lehet elkerülni a HTTP és a HTTPS közötti váltáskor.

Alapértelmezés szerint a Spring létrehoz egy újat munkamenet azonosító sikeres bejelentkezés után. Amikor a felhasználó betölti a HTTPS bejelentkezési oldalt, a felhasználóé munkamenet azonosító a cookie jelölése: biztonságos. Bejelentkezés után a kontextus HTTP-re vált, és a süti elveszik, mivel a HTTP nem biztonságos.

Ennek elkerülése érdekében setting session-fixation-protection nak nek egyik sem megkövetelt.

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

Vagy XML-en keresztül:

A munkamenet-rögzítés elleni védelem kikapcsolása biztonsági következményekkel járhat, ezért mérlegelnie kell az előnyöket és hátrányokat, ha aggódsz a munkamenet rögzítésen alapuló támadások miatt.

6. Teszt

Ezen konfigurációs változások alkalmazása után a hozzáférés /anonymous.html bejelentkezés nélkül (bármelyik használatával) // vagy //) HTTP-n keresztül továbbítja az oldalra.

Más oldalak megnyitása, mint például /homepage.html HTTPS-en keresztül továbbítja a bejelentkezési oldalra, és a bejelentkezés után visszairányítja /homepage.html HTTP használatával.

7. Következtetés

Ebben az oktatóanyagban megvizsgáltuk, hogyan kell konfigurálni a Spring webalkalmazást, amely a bejelentkezési mechanizmus kivételével HTTP-n keresztül kommunikál. azonban az új, modern webalkalmazásoknak szinte mindig kizárólag HTTPS-t kell használniuk mint kommunikációs protokolljuk. A biztonsági szint csökkentése vagy a biztonsági funkciók (például session-fixation-protection) soha nem jó ötlet.

Ez az oktatóanyag a GitHubon elérhető kódalapon alapul. A csatorna biztonsági konfigurációja felsorolással engedélyezhető https aktív tavaszi profilként.