Dlaczego potrzebujemy bezpieczeństwa na poziomie metody?

Dlaczego w świecie rzeczywistym musimy wdrażać zabezpieczenia na poziomie metod?

Mamy aplikację internetową lub komputerową, w której użytkownik uzyskuje dostęp do interfejsu użytkownika (a zatem bezpośrednio nie może uzyskać dostępu do metody).

Gdzie zatem pojawia się bezpośredni dostęp do metod?

edytuj: Zadaję to pytanie, ponieważ eksperymentuję z zabezpieczeniami wiosennymi i widzę autoryzację użytkowników na dostęp do metod.

coś jak :

 @ROLE_ADMIN
public void update() {
      //update
}

W odpowiednio zaprojektowanej aplikacji backend i frontend są rozłączone. System bezpieczeństwa zaplecza nie może zakładać, że jakikolwiek konkretny interfejs będzie poprawnie obsługiwał zabezpieczenia, więc musi sobie z tym poradzić.

Zakładam, że mówisz o dostępie opartym na rolach do działań w kontrolerze. Tj. W architekturze MVC każda metoda w Controllerklasie jest osobną akcją. Większość frameworków MVC, z których korzystałem, pozwala mi przypisywać uprawnienia zarówno na poziomie metody, jak i klasy. Oznaczałoby to, że mogę zastosować atrybut / adnotację na poziomie klasy, a odpowiednia rola byłaby wymagana dla każdej akcji w tym kontrolerze.

Jeśli chodzi o bardziej szczegółową kontrolę dostępu opartego na rolach, rozważ to:

• Wygodnie jest grupować wszystkie działania wokół zasobu. Tj. Twórz / czytaj / aktualizuj / usuwaj (CRUD) akcje dla artykułów, kont itp. To sprawia, że ​​interfejsy API w stylu REST są łatwiejsze do pisania i zarządzania.
• Wiele systemów ma inne poświadczenia / role wymagane dla akcji Utwórz / Aktualizuj / Usuń niż dla akcji Odczytaj.
• Jeśli wszystkie działania na kontach użytkowników są w jednym kontrolerze, chcesz zezwolić każdemu na zalogowanie się, ale tylko niektórym osobom można tworzyć nowe konta lub przypisywać role.

Czy to się podoba, czy nie, kiedy Ruby on Rails uderzył w fale radiowe kilka lat temu, prawie każda platforma MVC skopiowała swoje podstawowe podejście projektowe. Kiedyś akcje były oddzielnymi klasami, ale logika akcji bywa niewielka i skoncentrowana, więc narzut całej klasy jest nadmierny. Mapowanie metody na kontrolerze do akcji dla strony rzeczywiście miało sens. Po prostu wiedz, że wiele osób potrzebuje drobiazgowej kontroli nad tym, które role mogą pełnić jakie funkcje.

Bezpieczeństwo na poziomie metody jest przydatne z dwóch głównych powodów:

• jako kolejna warstwa bezpieczeństwa (oprócz innych warstw)

• w przypadkach, gdy wygodniejsze lub logiczne jest posiadanie uprawnień na poziomie metody, rozważ przypadek, w którym różni użytkownicy mogą wykonywać te same „bezpośrednie” działania (więc bezpieczeństwo klienta nie jest istotne). ale w niektórych przypadkach ich działanie może spowodować zachowanie, które chcesz ograniczyć - w tym przypadku bezpieczeństwo na poziomie metody może być odpowiednim rozwiązaniem.

Mike Wiesner przypomniał w prezentacji SpringSource, Wprowadzenie do Spring Security 3 / 3.1 , podając przykład, że Tomcat i wiele innych kontenerów serwletów zawierało błąd, który nie rozpoznał poprawnie „../” po zakodowaniu w Unicode, w sposób, który prosty test równości nie powiedzie się w Javie, ale przełoży się na wyższy katalog w systemie plików.

Bezpieczeństwo jest trudne, wiele poziomów bezpieczeństwa, zwiększy szanse na zablokowanie prób obejścia środków. Ponieważ zabezpieczenia na poziomie metody są kodowane bezpośrednio wewnątrz klasy, po rozszerzeniu AOP podczas wywoływania metody zawsze wywołujesz kontrolę bezpieczeństwa wcześniej.

Zakładam, że mówisz tutaj o metodach publicznych, prywatnych i chronionych?

Jeśli tak, to nie istnieją dla celów bezpieczeństwa. Istnieją one w celu ułatwienia zagwarantowania, że ​​oprogramowanie jest odpowiednio zmodularyzowane. (To, czy im się uda, to debata, którą zostawię innym. Taka jest jednak wizja tego, po co są.)

Załóżmy, że dostarczam bibliotekę, a następnie mogę swobodnie dostarczyć inną wersję biblioteki i zmieniać rzeczy oznaczone jako prywatne tak bardzo, jak chcę. Natomiast gdybym nie oznaczył tych rzeczy jako prywatnych, nie byłbym w stanie zmienić żadnych wewnętrznych elementów mojego oprogramowania, ponieważ ktoś gdzieś prawdopodobnie ma do niego bezpośredni dostęp. Oczywiście, teoretycznie jest to ich wina, że ​​nie używają udokumentowanego API. Ale klient postrzega to jako moją winę, że moja aktualizacja oprogramowania spowodowała uszkodzenie oprogramowania. Nie chcą wymówek, chcą to naprawić. Ale jeśli nie pozwolę im mieć dostępu od samego początku, to mój interfejs API jest dokładnie publicznymi metodami, które zamierzałem być moim interfejsem API i problem zostanie uniknięty.

Drugą najbardziej prawdopodobną rzeczą, o której możesz mówić, jest model bezpieczeństwa Java. Jeśli mówisz o tym, przyczyną jest to, że pierwotna wizja Javy dotyczyła osób wysyłających potencjalnie niezaufane aplety do interaktywnej pracy w programach innych firm (np. Przeglądarkach). Dlatego model bezpieczeństwa miał zapewnić użytkownikom pewną ochronę przed złośliwymi apletami. Dlatego zagrożeniem bezpieczeństwa, przed którym należy się martwić i chronić przed nim, są niezaufane aplety próbujące wchodzić w interakcje z innym oprogramowaniem, które może zostać załadowane.