OWASP dziesięć pierwszych ataków i ochrona wiosenna

Question

Oceniam zabezpieczenia dla mojej aplikacji internetowej. Ponieważ używam Springa w mojej aplikacji internetowej, chciałbym wykorzystać framework Spring Security. Szukałem więcej informacji o bezpieczeństwie w sieci i natknąłem się na społeczność OWASP oraz listę 10 najczęstszych ataków. Moje pytanie brzmi; Czy wystarczy skonfigurować Spring Security, aby zabezpieczyć moją aplikację? Jakie zagrożenia bezpieczeństwa z OWASP top 10 (2013) obsługiwane są przez Spring Security Framework?

Answer 1

Budowanie bezpiecznych aplikacji to trudne zadanie i nie ma produktu "srebrnej kuli", który sprawiłby, że aplikacja będzie automatycznie zabezpieczana. Dlatego proste użycie Spring Security z pewnością nie oznacza automatycznie, że twoja aplikacja jest bezpieczna! Spring Security to świetne narzędzie, które pomaga w wielu aspektach budowania bezpiecznych aplikacji, ale jak przy każdym narzędziu, które musisz wiedzieć, jak prawidłowo go używać.

Wiosna Security może pomóc rozwiązać przynajmniej następujące kwestie OWASP TOP10:

• A2-łamany Uwierzytelnianie i Session Management - poprzez zapewnienie mechanizmów skutecznego i bezpiecznego uwierzytelniania i zarządzania sesją
• A4 -Insecure Direct Object Referencje - przez zapewnienie mechanizmów autoryzacji w ramach aplikacji
• Ekspozycja danych wrażliwych na działanie A6 - Moduł kryptograficzny wiosna Security zapewnia niezbędne funkcje kryptograficzne
• A7-missing Poziom Funkcja Access Control - poprzez przekazanie środków do autoryzacji w interfejsie użytkownika i po stronie serwera
• A8-cross-site request forgery (CSRF) - poprzez zapewnienie wsparcia do generowania i sprawdzania tokenów łagodzących ataki CSRF

Answer 2

Możesz spróbować HDIV, który obsługuje wiele frameworków.

Answer 3

Zaleca się stosowanie warstwowej architektury zabezpieczeń. Chodzi o to, że można stworzyć bezpieczną aplikację ręcznie, ale jest to niezwykle trudne do zrealizowania. Niektóre funkcje zabezpieczeń, takie jak uwierzytelnianie i podstawowa kontrola dostępu (poziom adresu URL lub komponent GUI), są względnie łatwe do wdrożenia, ale wymagania takie jak bezpieczeństwo na poziomie instancji (specjalnie działające w starszych wersjach baz danych), Sql Injection i XSS są trudniejsze.

Polecam używać Spring Security i wdrażać jak najwięcej niestandardowych walidacji. Oprócz tego zalecam użycie HDIV w celu dodania dodatkowej warstwy zabezpieczeń, która mogłaby pomóc w uniknięciu ryzyka nieobjętego niestandardowymi walidacjami. W szczególności funkcje oferowane przez HDIV są:

• A1- wtryskowa: dotyczące wartości i parametrach określonych adresów URL http HDIV zmniejszyć ryzyko wystąpienia tej usterki tylko do danych, które pochodzą z pól tekstowych w obrębie form, stosując walidacji integralności (zapewnia, że ​​otrzymana wartość jest taka sama, jak wygenerowana po stronie serwera) dla pozostałych danych pochodzących od strony klienta. W przypadku pól tekstowych zawartych w formularzach, HDIV oferuje ogólne zatwierdzenia (biała lista i czarna lista) w celu uniknięcia ataków wtrysku.

• A2-łamany Uwierzytelnianie i Session Management: HDIV nie oferuje funkcjonalności dla tego ryzyka internetowej.

• A3-XSS: taki sam jak A1, ale w tym przypadku, aby uniknąć ryzyka XSS.

• A4 niebezpiecznym dopełnienia Referencje: HDIV kontroluje wszystkie dane generowane po stronie serwera zapewnienia integralności danych i uniknięcia tej luki.

• A5-Security błąd konfiguracji: HDIV nie obejmuje specyficzne funkcje dla tego, ale nie pozwala na dostęp do zasobów nie wysyłanych przez serwer wcześniej, unikając wykorzystywania nieoczekiwanych zachowań lub dostępu do zasobów prywatnych.

• A6-Sensitive Data ekspozycji: HDIV oferuje funkcję poufności ukryć wartości parametrów HTTP.

• A7-missing Poziom Funkcja Access Control: dzięki walidacji integralności realizowane przez HDIV, unika wykorzystywania tej luki i ograniczyć użytkownikowi na wykonanie czynności prawnych i utrzymanie pierwotnego zamówienia (GUI lub API) Wystawiono przez aplikację
  .

• A8-cross-site request forgery (CSRF): HDIV dodaje losowe znaki do uniknąć tej luce

• A9-Użycie komponentów ze znanymi lukami: HDIV nie obejmuje szczególne funkcje w tym przypadku, ale dzięki interakcji ograniczenia nałożone na użytkownika w wielu przypadkach nie jest możliwe, aby wykorzystać tę lukę.

• A10-niezweryfikowane przekierowania i do przodu: Luka ta głównie związane z manipulacją non edycji danych lub danych wytworzonych uprzednio na stronie serwera. HDIV kontroluje wszystkie dane wysłane przez serwer i nie zezwala na przekierowanie do złośliwych witryn internetowych.

Oprócz tych funkcji do ochrony przed OWASP dziesięciu największych zagrożeń internetowych, HDIV generuje także dzienniki związane z szkodliwej aktywności lub ataków na swojej stronie internetowej, w tym wszelkich informacji na temat ataku i nazwy użytkownika w uwierzytelnionych stron internetowych .

Pozdrawiam,

Roberto Velasco (zespół HDIV)