Kodowanie po stronie klienta: jak zapobiec złośliwemu użyciu?

W ostatnich latach trend aplikacji po stronie klienta (przeglądarki) naprawdę się rozwinął.

W moim najnowszym projekcie postanowiłem iść z duchem czasu i napisać aplikację po stronie klienta.

Część tej aplikacji obejmuje wysyłanie wiadomości e-mail dotyczących transakcji do użytkowników (na przykład sprawdzanie poprawności rejestracji, wiadomości e-mail dotyczące resetowania hasła itp.). Korzystam z interfejsu API innej firmy do wysyłania wiadomości e-mail.

Zwykle moja aplikacja działałaby na serwerze. Dzwonię do interfejsu API innej firmy z kodu na moim serwerze.

Uruchomienie aplikacji po stronie klienta oznacza, że ​​teraz musi to nastąpić w przeglądarce użytkownika. Interfejs API innej firmy zapewnia niezbędne pliki JavaScript do osiągnięcia tego celu.

Pierwszym rażącym problemem, jaki widzę, jest konieczność użycia klucza API. Zwykle byłoby to bezpiecznie przechowywane na moim serwerze, ale teraz prawdopodobnie będę musiał dostarczyć ten klucz do przeglądarki klienta.

Zakładając, że mogę obejść ten problem, następnym problemem jest to, co powstrzymuje doświadczonego technicznie użytkownika ładującego narzędzie programistyczne JavaScript w przeglądarce i używającego interfejsu API poczty e-mail, tak czy inaczej, zamiast mówić o przestrzeganiu reguł, które ustawiłem w aplikacji .

Wydaje mi się, że moim ogólnym pytaniem jest - w jaki sposób możemy zapobiec złośliwemu użyciu aplikacji po stronie klienta?

Nie możesz, a im więcej ludzie to rozumieją, i im głębiej rozumieją, tym lepiej dla świata.

Kod działający na urządzeniu kontrolowanym przez użytkownika nie może być kontrolowany. Smartfony mogą mieć jailbreak. Dekodery mogą być popękane. Zwykłe przeglądarki nawet nie próbują uniemożliwiać dostępu do kodu JavaScript. Jeśli masz coś, co warto ukraść lub nadużyć, zdeterminowany atakujący będzie mógł to zrobić, chyba że zweryfikujesz wszystko, co cenisz po stronie serwera.

Zaciemnianie jest bardzo mało pomocne; rodzaj przeciwnika, którego przyciągniesz, gdy tylko zdalnie zajmie się to finansowo, czyta język asemblera, jak ogłoszenia drobne. Szyfrowanie nie może ci pomóc, ponieważ urządzenie, które będzie pilnowało klucza, jest tym samym urządzeniem, co do którego musisz założyć, że jest pęknięte. Istnieje wiele innych, pozornie oczywistych środków zaradczych, które nie działają z podobnych powodów.

Niestety jest to bardzo niewygodna prawda. Świat jest pełen małych i dużych operatorów, którzy myślą, że mogą w jakiś sposób obejść fundamentalne zerwanie zdalnego zaufania, po prostu dlatego, że byłoby tak miło , gdybyśmy mogli założyć, że nasz kod będzie działał tak, jak zakładaliśmy. I tak, wszystko to byłoby o wiele łatwiejsze, że nawet nie jest śmieszne. Ale pragnienie tego nie czyni, a nadzieja wbrew nadziei, że jesteś jedynym inteligentnym ciasteczkiem, który może uniknąć nieprzyjemności, spali tylko ciebie i twoich klientów. Dlatego wejdź do sposobu myślenia, że ​​Internet jest terytorium wroga, uwzględnij ten dodatkowy koszt w swoich szacunkach, a wszystko będzie dobrze.

To powiedziawszy, oczywiście istnieje coś takiego jak głęboka obrona. Ukrywanie kodu JavaScript nie zniechęca zdecydowanego napastnika, ale może zniechęcić niektórych mniej zdeterminowanych atakujących. Jeśli twoje aktywa są wystarczające do ochrony, ale nie za wszelką cenę, którykolwiek z tych środków może zwiększyć wartość biznesową twojego systemu; to po prostu nie może być idealne. Tak długo, jak masz pełną świadomość kompromisów, może to być rozsądna strategia.

Zasada jest następująca:

Rób wszystko, co po stronie klienta, co nie wpływa na nikogo innego, jeśli użytkownik manipuluje nim. W szczególności oznacza to efekty graficzne.

Zrób wszystko, co wymaga bezpieczeństwa po stronie serwera, i po prostu wyślij zdarzenia interfejsu użytkownika od klienta (np. Wtedy klient mówi „użytkownik nacisnął przycisk Kup”, podczas gdy serwer faktycznie przeprowadza transakcję). W szczególności oznacza to transakcje finansowe.

Dokładnie tak jest, gdy uczynienie go całkowicie aplikacją po stronie klienta nie jest właściwe.

Możesz dokonać logiki i podstawowej weryfikacji formularzy po stronie klienta (nadal musisz dokonać ponownej walidacji na serwerze, ponieważ ktoś może próbować sfałszować żądanie), aby poprawić czas reakcji, możesz wykonywać żądania HTTP z JavaScript przekazujące dane tam iz powrotem w JSON do unikaj ponownego wysyłania ozdób stron i tym podobnych, ale jeśli sama transakcja wymaga uwierzytelnienia i autoryzacji, powinna ona nadal odbywać się na serwerze.

Twój środkowy akapit jest sednem problemu:

Uruchomienie aplikacji po stronie klienta oznacza, że ​​teraz musi to nastąpić w przeglądarce użytkownika. Interfejs API innej firmy zapewnia niezbędne pliki js, aby to osiągnąć.

Dlaczego aplikacja po stronie klienta oznacza, że ​​nie możesz pracować po stronie serwera? Nacisk na programowanie po stronie klienta nie polega na eliminowaniu serwerów, ale na wykorzystaniu nowszych technologii, które wreszcie obsługują przeglądarki, aby ulepszyć interfejsy użytkownika.

Co do otrzymanego .jspliku, czy jesteś pewien, że jest on przeznaczony do przeglądarki? Czy może to być biblioteka node.js?

Cofnijmy się od tego i spójrzmy na wyższy poziom ... czy my ... Czy Eudora lub program Outlook (aplikacja po stronie klienta, nawet niepotrzebująca przeglądarki) kiedykolwiek spowodował stratę finansową dla jakiejkolwiek firmy? Nie. Każdy może pisać do API POP / SMTP i być klientem. Ale bez strat na serwerze. Serwer nie ograniczył działań klienta, obliczeń, pamięci, temperatury, rozmiaru dysku, rozmiaru RAM, DPI monitora, GPU, FPU yada yada klienta, ale dokładnie określił, na co odpowie i nic więcej. Czy słyszałeś kiedyś o szybkim użyciu lub o użyciu MS-Money do włamania do banku?

Twoja przeglądarka (tj. Po stronie klienta) może korzystać z tej samej architektury.

1. Budujesz swój serwer za pomocą interfejsu API (który BTW zawsze sprowadza się do pochodnych GET POST HEAD itp.).
2. Na serwerze upewnij się, że interfejs API komunikuje się tylko z klientem uwierzytelnionym i zweryfikowanym pod względem tożsamości dla każdego połączenia.
3. Więc nie obchodzi cię, kim jest klient.
4. A potem nie obchodzi cię, czy to przeglądarka, zepsute urządzenie, szkło Google, DOS 3.1, czy zupełnie nowy Nexus w rękach pra-pra-pra-pra-pra-dziadka, który podróżował do 2014 roku i przegapił wszystko technologia, która zalała nasze życie w ciągu ostatnich 15 dekad.
5. Teraz możesz rozpocząć odciążanie wszystkiego po stronie klienta.

SoapBoxBegin

@KilianFoth podnosi ważny punkt świadomości dla naiwnych i lekkomyślnych, głównie tych, którzy cały czas czytają nagłówki, ale nigdy nie myślą, że stanie się to z ich aplikacją, kodem, pracodawcą, klientem, własnym kontem bankowym. Jeszcze bardziej lekkomyślni są ich pracodawcy (zwłaszcza CTO), którzy pozwolą wyjść z aplikacji, które narażą każdy system na niezarządzane / niekontrolowane narażenie. Jednak zawsze zastanawiam się, jak to się wydaje, że „nigdy się nie uczymy”.

SoapBoxEnd

Podsumowując. Stwórz solidny i zwarty API po stronie serwera. Przeładuj wszystko inne na klienta w oparciu o wszystko, co klient może obsłużyć.

Twierdziłbym, że naprawdę nie możesz. Jeśli chcesz wysłać dane do klienta, musisz spodziewać się, że zostaną one wykorzystane - jednak w miarę możliwości. Twój przykład dotyczący klucza API ilustruje tę kwestię, a ja nie uwzględniałbym tego po stronie klienta JS - zostanie skradziony i wykorzystany.

Na pewno będziesz potrzebować pewnej ilości kodu serwera, aby zachować bezpieczeństwo. Nawet coś tak prostego, jak wyszukiwanie tylko danych związanych z zalogowanym użytkownikiem. To uwierzytelnienie nie może być wykonane po stronie klienta, w przeciwnym razie zostaniesz wykorzystany, a Twoje dane nie będą bezpieczne.

Zawsze postrzegałbym środowisko klienta JS jako dodatek do kodu serwera. Sprawdzanie poprawności na kliencie zapewnia przyjemną obsługę, ale jeśli nie zweryfikujesz również danych POST na serwerze odbierającym, narażasz się na atak. Wszystko od klienta należy uznać za podejrzane.

To naprawdę proste. Załóżmy, że komputer kliencki i całe działające na nim oprogramowanie jest pod pełną kontrolą sprytnego złośliwego hakera.

Oznacza to, że wszelkie informacje wysyłane z serwera do klienta będą znane złośliwemu hakerowi, dlatego musisz upewnić się, że nie wysłałeś do klienta żadnych informacji, które mogłyby zostać użyte do zaatakowania twojego serwera lub firmy.

Oznacza to również, że wszystko wysyłane z klienta na serwer zostało wyprodukowane przez złośliwego hakera, więc kod serwera musi mieć pewność, że nic, co klient może wysłać, nie będzie w stanie skutecznie zaatakować twojego serwera.

Wprawdzie wdrożenie jest problemem, ale ważne jest podejście mentalne, założenie, że „klient”, z którym myślisz, że twój serwer rozmawia, nie jest klientem, ale aktywnym atakującym.

(Musisz również założyć, że użytkownik jest sprytnym oszustem, który spróbuje zaatakować twoje metody biznesowe, ale nie ma to nic wspólnego z programowaniem po stronie klienta).

Moim zdaniem aplikacja po stronie klienta dotyczy głównie interfejsu użytkownika. Na przykład cały system interfejsu użytkownika zostanie wysłany raz do klienta, a następnie klient zrobi z nim, co chce.

Zwykle moja aplikacja działałaby na serwerze. Dzwonię do interfejsu API innej firmy z kodu na moim serwerze.

Uruchomienie aplikacji po stronie klienta oznacza, że ​​teraz musi to nastąpić w przeglądarce użytkownika. Interfejs API innej firmy zapewnia niezbędne pliki JavaScript do osiągnięcia tego celu.

Jeśli masz klucz API, to nie jest przeznaczony do pracy po stronie klienta. Jeśli podasz klucz API po stronie klienta, każdy ma do niego dostęp, a następnie może go użyć do własnych celów. Zapisz go i użyj po stronie serwera, gdy klient tego potrzebuje, a następnie wyślij wynik za pomocą Ajax / WebSockets.

To tak, jakby twój bank mówił: „Cóż, umieszczę hasło głównej strony bazy danych klienta, aby klient mógł sam o to poprosić, a on nie będzie już niepokoił naszych serwerów”.