Пролетна защита на HTTP / HTTPS канал

1. Общ преглед

Този урок показва как да използвате HTTPS, за да защитите страницата за вход на приложението си чрез функцията Spring Channel Channel.

Използването на HTTPS за удостоверяване е от решаващо значение за защита на целостта на чувствителните данни, когато сте в транспорт.

Статията се основава на урока Spring Login Login, като добавя допълнителен слой сигурност. Ние подчертаваме стъпките, необходими за осигуряване на данните за удостоверяване, като обслужваме страницата за вход чрез кодирания HTTPS канал.

2. Първоначална настройка без защита на канала

Нека започнем с конфигурацията на защитата, обяснена в гореспоменатата статия.

Уеб приложението позволява на потребителите достъп до:

  1. /anonymous.html без удостоверяване,
  2. /login.html и
  3. други страници ( /homepage.html ) след успешно влизане.

Достъпът се контролира от следната конфигурация:

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

Или чрез XML:

На този етап страницата за вход е достъпна на адрес:

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

Потребителите могат да се удостоверяват чрез HTTP, но това е несигурно, тъй като паролите ще бъдат изпращани в обикновен текст.

3. Конфигурация на HTTPS сървър

За да доставите само страницата за вход през HTTPS - вашият уеб сървър трябва да може да обслужва HTTPS страници . Това изисква поддръжката на SSL / TLS да е активирана.

Имайте предвид, че можете да използвате валиден сертификат или, за целите на тестването, можете да генерирате свой собствен.

Да предположим, че използваме Tomcat и пускаме собствения си сертификат. Първо ще трябва да създадем хранилище на ключове със самоподписан сертификат.

Генерирането на хранилището на ключове може да се извърши чрез издаване на следната команда в терминала:

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

Това ще създаде частен ключ и самоподписан сертификат в хранилището на ключове по подразбиране за вашия потребителски профил във вашата домашна папка.

Следващата стъпка е да редактирате conf / server.xml, за да изглежда така:

Вторият SSL / TLS таг обикновено се коментира в конфигурационния файл, така че е необходимо само да се коментира и добави информация за хранилището на ключове. Допълнителна информация можете да намерите в свързаната с Tomcat документация.

С наличната HTTPS конфигурация страницата за вход вече може да се обслужва и под следния URL:

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

Уеб сървъри, различни от Tomcat, ще изискват различна, но вероятно подобна конфигурация.

4. Конфигуриране на защитата на канала

На този етап можем да обслужваме страницата за вход както под HTTP, така и HTTPS. Този раздел обяснява как да разрешите използването на HTTPS.

За да изисквате HTTPS за страницата за вход, променете конфигурацията на вашата защита, като добавите следното:

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

Или добавете атрибута require-channel = ”https” към вашата XML конфигурация:

След тази точка потребителите могат да влизат само чрез HTTPS. Всички относителни връзки, напр. Препращане към /homepage.html, ще наследят протокола на първоначалната заявка и ще се обслужват под HTTPS.

Когато смесвате HTTP и HTTPS заявка в едно уеб приложение, има допълнителни аспекти, които трябва да знаете и които изискват допълнителна конфигурация.

5. Смесване на HTTP и HTTPS

От гледна точка на сигурността, обслужването на всичко чрез HTTPS е добра практика и стабилна цел.

Ако обаче използването само на HTTPS не е опция, можем да конфигурираме Spring да използва HTTP, като добавим следното към config:

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

Или добавете атрибутите require-channel = ”http” към XML:

Това инструктира Spring да използва HTTP за всички заявки, които не са изрично конфигурирани да използват HTTPS, но в същото време нарушава оригиналния механизъм за вход. Следващите раздели обясняват основната причина.

5.1. URL адрес за обработка на персонализиран вход през HTTPS

Конфигурацията на защитата в оригиналния урок за защита съдържа следното:

Без да се принуждава / perfor_login да използва HTTPS, ще се случи пренасочване към неговия HTTP вариант, губейки данните за вход, изпратени с оригиналната заявка.

За да преодолеем това, трябва да конфигурираме Spring да използва HTTPS за URL за обработка:

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

Notice the extra argument /perform_login passed to the antMatchers method.

The equivalent in the XML configuration requires adding a new <intercept-url> element to the config:

If your own application is using the default login-processing-url (which is /login) you don't need to configure this explicitly as the /login* pattern already covers that.

With the configuration in place, users are able to login, but not to access authenticated pages e.g. /homepage.html under the HTTP protocol, because of Spring's session fixation protection feature.

5.2. Disabling session-fixation-protection

Session fixation is a problem which can't be avoided when switching between HTTP and HTTPS.

By default Spring creates a new session-id after a successful login. When a user loads the HTTPS login page the user's session-id cookie will be marked as secure. After logging in, the context will switch to HTTP and the cookie will be lost as HTTP is insecure.

To avoid this setting session-fixation-protection to none is required.

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

Or via XML:

Disabling session fixation protection might have security implications, therefore you need to weigh the pros and cons if you're concerned about session fixation based attacks.

6. Test

After applying all these configuration changes accessing /anonymous.html without logging in (using either // or //) will forward you to the page through HTTP.

Opening other pages directly like /homepage.html should get you forwarded to the login page via HTTPS and after login you will be forwarded back to /homepage.html using HTTP.

7. Conclusion

В този урок разгледахме как да конфигурираме Spring web-приложение, което комуникира чрез HTTP, с изключение на механизма за вход. Въпреки това новите съвременни уеб-приложения трябва почти винаги използват HTTPS изключително за своя комуникационен протокол. Намаляването на нивата на защита или изключването на защитни функции (като защита от фиксиране на сесии ) никога не е добра идея.

Този урок се основава на кодовата база, достъпна в GitHub. Конфигурацията за защита на канала може да бъде активирана чрез изброяване на https като активен профил на Spring.