Tavaszi HTTP / HTTPS csatorna biztonság
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:
- /anonymous.html hitelesítés nélkül,
- /login.html, és
- 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.