Bezpieczne zabezpieczenie modułów Lazy-Loaded (Angular 2)

Question

Pracuję nad aplikacją, dla której mam obszar użytkownika i obszar administracyjny. Rozdzieliłem je na osobne moduły Angular 2. Z powodzeniem zaimplementowałem leniwy-ładowanie, aby moduł administracyjny mógł być ładowany tylko wtedy, gdy użytkownik/admin jest żądany przez użytkownika.

Z Kątowymi dokumentacji 2, widzę, że mogę określić "canLoad" straż tak:

{ 
    path: 'admin', 
    loadChildren: 'app/admin/admin.module#AdminModule', 
    canLoad: [AdminGuard] 
    } 

i zaimplementować funkcję canLoad wewnątrz klasy AdminGuard tak:

canLoad(route: Route): boolean { 
    return this.authService.isAdmin(); 
} 

(gdzie isAdmin() może wywołać API zaplecza, który zwróciłby rolę bieżącego użytkownika lub coś podobnego)

Ale czy to faktycznie uniemożliwia jakiekolwiek admin z ładowania modułu AdminModule? O ile się nie mylę, cały ten kod znajduje się na kliencie, więc czy istnieje coś, co uniemożliwiłoby klientowi modyfikację metody "canLoad", aby zawsze zwracała wartość true? Podobnie jak:

canLoad(route: Route): boolean { 
    return true; 
} 

Tym samym umożliwiając klientowi załadowanie dowolnego modułu, który chce.

Oczywiście wszystkie połączenia z interfejsem API zaplecza, które wymagają statusu administratora, będą chronione, ale wygląda na to, że każdy użytkownik będzie mógł zobaczyć interfejs administratora, co wydaje mi się trochę dziwne. Czy ktoś może mi to wyjaśnić?

Answer 1

To jest świetne pytanie i byłem ciekawy, czy ktoś ma szczegółową odpowiedź na to. Więc znalazłem ten link, który miał całkiem niezłą rozmowę.

Angular 2 Reddit Article

Jeden komentarz, że naprawdę wyciągnął do mnie był to jeden.

Mówiąc w SPA, ogólnie szablony html i pliki js będą dostępne dla wszystkich, których opieka wystarczy. Twoje SPA będzie mówić tylko na serwerze w danych (czytaj: json), szablony będą wtedy wypełnione tymi danymi po stronie klienta. więc podstawową troską jest ochrona tego interfejsu API przed . Sesje, pliki cookie, tokeny, wszystko to oznacza, że ​​nadal obowiązuje tutaj. Ja sam używam tokenów do uwierzytelniania i autoryzacji. Żądanie interfejsu API zawierałoby token podpisany przez serwer, który następnie jest sprawdzany pod numerem , z którego wyodrębniane są role i poświadczenia, a następnie użyty do ustalenia, czy użytkownik jest uprawniony do żądania. Failed check zwróci 401-nieautoryzowane do klienta. Po stronie kanciastej, zapiszemy token, który otrzymaliśmy po udanym logowaniu, a następnie użyjemy go do kolejnych żądań . Odszyfrowuję także poświadczenia i role, a dzięki wyświetla informacje o użytkowniku i autoryzuje trasy. Drogi chronione w kanciastości to osiągnięte dzięki interfejsowi CanActivate, który można połączyć z wieloma numerami : {Path: 'protected', CanActivate: [LoggedInGuard]}, {Path: 'supersecret', CanActivate: [LoggedInGuard, AdminGuard]}. ..etc Ale Osłony po stronie klienta (czytaj: kątowe) jest ostatecznie problemem UX, a nie środkiem bezpieczeństwa . Doświadczony haker może po prostu zepsuć zmienne z konsolą dev lub obejść je w całości za pomocą prostego wywołania api .Wystarczy pokazać użytkownikom, jaki błąd się wydarzył, i nawigować po gdzie indziej itd.