2017-10-12 73 views
12

Mam aplikację internetową Spring MVC chronioną przez Spring Security. Życie wydaje się takie spokojne, dopóki nie zostałem zmuszony do zrobienia Static Application Security Testing (SAST), a narzędzie wyrzuciło kilka problemów z bezpieczeństwem. Wystarczy popatrzeć na tutaj:W jaki sposób jar może rozprzestrzenić lukę w aplikacji internetowej, w której jest używana?

enter image description here

I już przez wszystkich CVEs i ma chropowatą obraz o lukach. Mam kilka pytań:

  1. Jak aplikacja internetowa jest podatny na taką eksploatację, gdy ramy bezpieczeństwa jak (sprężyna bezpieczeństwa) jest zintegrowany z nim?

  2. Czy mogę zignorować wszystkie te luki, ponieważ Spring Security może mieć jakieś obejście dla wszystkich tych luk?

+0

Dlaczego myślisz? Ponieważ większość słoików jest używana na całym świecie, więc to będzie dzikie domysły. Odwróciłem się, ponieważ chcę zwrócić uwagę na technologię, której używałem. –

+2

Nie ma nic w [dokumentacji] (https://docs.spring.io/spring-security/site/docs/current/reference/html/index.html), która obsługuje twoje dzikie domysły. Odpowiedź AFAIK na pierwsze pytanie brzmi: nie, więc twoje drugie pytanie nie ma sensu, ponieważ Spring Security nie radzi sobie z takimi atakami. – dur

+0

Z ciekawości, z jakiego narzędzia korzystałeś? – holmis83

Odpowiedz

7

Z Spring Security manual:

Wiosna Security to potężny i wysoce konfigurowalny uwierzytelniania i kontroli dostępu ramy. Jest to de facto standard zabezpieczania aplikacji sprężynowych.

Pomyśl o bezpieczeństwie wiosennym jako strukturze uwierzytelniania, która obejmuje jeden element układanki bezpieczeństwa.

Jako przykład niech spojrzeć na # 1 ryzyk OWASP Top 10 Application Security: A1 - Wtrysk
Zakładamy użyć słoik dostępu do bazy danych SQL (np hibernacji) i ma podatność na wstrzyknięcie, a następnie aplikacja może być również podatna na atak. Jednak nawet jeśli hibernacja nie ma żadnych błędów bezpieczeństwa, jeśli programista łączy zapytanie SQL razem bez prawidłowego wychodzenia z danych wprowadzonych przez użytkownika, aplikacja jest podatna na atak wtrysku.
Bezpieczeństwo wiosenne nie chroni aplikacji przed żadnym z tych ataków polegających na wstrzyknięciu.

Jeśli słoik jest narażony na atak, a użytkownik wywołuje podatne na zagrożenia metody/funkcje, może to również powodować występowanie tej luki w zabezpieczeniach aplikacji, która zależy w dużej mierze od luki i sposobu jej wykonania oraz od tego, jak skonfigurowana jest aplikacja do korzystania z tej luki. słoik.

Na szybki patrzeć na innych OWASP Top 10 Application Security Risks:
A1-wtryskowa - Brak ochrony od wiosny Bezpieczeństwa
A2 złamane uwierzytelniania i zarządzania sesją - Wiosna Security może pomóc zarządzać niektóre z nich, jednak miss skonfigurowane zabezpieczenie sprężyny spowoduje ich odsłonięcie.
A3-Cross-Site Scripting (XSS) - Brak ochrony przed wiosennym Bezpieczeństwa
A4 Niepewne bezpośrednie Object Referencje - Nie dodatkową ochronę od wiosny Bezpieczeństwa (wiosna zabezpieczeń daje narzędzia do zarządzania tym)
A5-Security błędną - Brak ochrony przed wiosennym Bezpieczeństwa
A6-Sensitive Data ekspozycji - Wiosna Security może pomóc z tym jednak, że również zależy wiele od sposobu przechowywania i zarządzania danymi (logi EG)
A7 -Usunięcie poziomu dostępu do funkcji s Kontrola - Jeśli kontrola dostępu została pominięta, Spring Security nie może ci pomóc, jednak bezpieczeństwo wiosenne ułatwia dodawanie tych antywirusowych żądań (CSRF) do stron WWW (CSRF)- Spring Security (w zależności od tego, jak Twoja aplikacja jest skonfigurowana) pomoże ci, a nawet zarządzać tym ryzykiem.
A9 Korzystanie składniki ze znanymi lukami - to CVE użytkownika zostały wymienione w pytaniu - Brak ochrony od wiosny zabezpieczeń
A10-niezweryfikowane przekierowań i Napastnicy - Wiosna bezpieczeństwa mogą być wykorzystane do zarządzania tego jednak nie robi „t chronić swoją aplikację z tego z pudełka

listę CVEs znalezionych podczas STAT swojej aplikacji jest przykładem A9 wykorzystaniem elementów ze znanymi lukami spojrzeć na OWASP wiki for more information.

Przykład ataku Scenariusze

składowe luki może spowodować niemal każdy rodzaj ryzyka sobie wyobrazić, począwszy od trywialnych do wyrafinowanego złośliwego oprogramowania zaprojektowanego kierować konkretną organizację. Komponenty prawie zawsze uruchamiane z pełny przywilej stosowania, więc błędy w każdym składniku może być poważny, następujące dwa elementy narażone zostały pobrane razy 22m w 2011.

  • Apache CXF Authentication Bypass - nie dostarczyć token tożsamości, napastnik może wywołać dowolną usługę internetową z pełnym uprawnieniem. (Apache CXF jest strukturą usługową, której nie należy mylić z serwerem aplikacji Apache.)
  • Wdrażanie kodu źródłowego - nadużywanie wyrażeń Implementacja języka na wiosnę pozwoliła atakującym na wykonanie niepożądanego kodu, skutecznie przejmując serwer.

Każda aplikacja za pomocą jednej z tych bibliotek jest narażonych podatny na atak jak oba te składniki są dostępne bezpośrednio przez użytkowników aplikacji. Inne podatne na zagrożenia biblioteki, używane głębiej w aplikacji, mogą być trudniejsze do wykorzystania.

Uwaga z ostatniego akapitu powyżej, tym głębiej składnik (słój) jest trudniejszy do wykorzystania, jednak nie oznacza to, że określony byt nie może ich wykorzystać.

Podsumowując, Spring Security to świetne narzędzie do zarządzania uwierzytelnianiem i kontrolą dostępu w aplikacji, ale nie jest to magiczna kula, która rozwiązuje wszystkie problemy związane z bezpieczeństwem.