2017-10-11 97 views
8

Powódź Atak: Krótko mówiąc, haker może nadal uderzać serwer (bez plików cookie), aby wymusić na kontenerze Java tworzenie nowej sesji.Jak zapobiec atakowi powodzi sesji HTTP

Używam Spring Security do zarządzania sesją. Zdaję sobie sprawę, że jsessionid jest tworzony przed zalogowaniem się, to nie jest to, czego chcę.

Więc zrobiłem:

1) na wiosnę konfiguracji zabezpieczeń:

sessionManagement().sessionCreationPolicy(SessionCreationPolicy.NEVER) 

2) wyłączenia tworzenia sesji w JSP. Ponieważ używam kafelka apache, ponieważ używa on dynamicznego włączania, więc muszę wyłączyć tworzenie sesji we wszystkich fragmentach jsp. To bardzo żmudne.

<%@page session="false"%> 

Na pierwszy rzut oka wszystko jest w porządku, ale jest scenariusz, w którym wciąż mam sesję.

Powiedzmy przed zalogowaniem się, odwiedzam adres URL, który można odwiedzać tylko po uwierzytelnieniu, Spring przekieruje mnie na stronę logowania.

Zanim zostanie przekierowany, odpowiedź już zawiera instrukcje, aby ustawić nowy plik cookie, już utworzoną sesję.

Moje pytanie:

1) Czy atak powodziowy w sesji jest poważnym problemem? Czy naprawdę powinienem się tym zająć?

2) Czy istnieje lepszy sposób rozwiązania tego problemu? Jakieś najlepsze praktyki?

3) Co stanie się z moim kodem? Powinien działać właściwie, podejrzewam, że ciasteczko zostało utworzone przez Spring, chociaż już ustawiłem to na SessionCreationPolicy.NEVER. Nie mogę ustawić go na Stateless, nadal potrzebuję sesji po zalogowaniu.

Jestem bardziej zaniepokojony atakiem sesyjnym niż DDOS, ustawiłem też na wiosnę .maximumSessions(1), aby zapobiec wielokrotnemu logowaniu. Ale powyższy problem występuje przed zalogowaniem. Proszę pomóż. Dzięki.

+1

Pierwszy myśleć mogę zasugerować jest kontrola jak ten: jeśli kilka wniosków przybyć z tego samego adresu IP w krótkim czasie (10 wniosek w ciągu 10 sekund, na przykład) blokować żądania –

+1

Zgadzam się z @AngeloImmediata. Jeśli Twoim celem jest zapobieganie atakowi powodziowym, który jest "rodzajem" ataku DDoS, podejmuj działania na niższym poziomie, aby zapobiec takim sytuacjom, a nie kłopotliwemu z tym serwerowi aplikacji. Na niższym poziomie mam na myśli użycie Zapory sieciowej. Oto, jak możesz to zrobić za pomocą 'iptables': https://unix.stackexchange.com/questions/139285/limit-max-connections-per-ip-address-and-new-connections-per-second--- iptable –

Odpowiedz

2

Twój punkt wygląda na prawidłowy, prawdopodobnie nie będzie poważnym problemem, jeśli nie będzie obsługiwany. Odkryłem, że istnieje już otwarty problem na ten temat. Istnieje jednak możliwość obejścia tego problemu.

public class ApiSecurityConfig extends WebSecurityConfigurerAdapter { 
     public HttpSessionRequestCache getHttpSessionRequestCache() { 
      HttpSessionRequestCache httpSessionRequestCache = new HttpSessionRequestCache(); 
      httpSessionRequestCache.setCreateSessionAllowed(false); 
      return httpSessionRequestCache; 
     } 

     @Override 
     protected void configure(final HttpSecurity http) throws Exception { 
      http.requestCache().requestCache(getHttpSessionRequestCache()); 
} 

Zobacz następujące linki, aby uzyskać więcej informacji.

https://github.com/spring-projects/spring-security/issues/4242

How to stop Spring Security from creating a new session?