Web API a weryfikacja klientów mobilnych

0

Mam system składający się z mikroserwisów które są niedostępne z zewnątrz. Dostęp do systemu odbywa się za pomocą "backend for frontend", czyli Web API mający dostęp do wewnętrznych mikroserwisów, hostujący aplikację webową (SPA napisane w React) oraz dostarczający odpowiednich endpointów w celu weryfikacji i pchania requestów do wewnętrznych systemów. Ten serwis ma zabezpieczenia takie jak polityka CORS, anti-forgery tokens itp. Prawdopodobnie do tego systemu dojdą klienci w postaci aplikacji mobilnych (natywne). Będzie więc trzeba jakoś zapewnić dostęp do wewnętrznego systemu (mikroserwisów), ale ze względów bezpieczeństwa jak i separacji odpowiedzialności bezpośredni dostęp nie jest opcją. Siłą rzeczy rozwiązaniem będzie jakieś API gateway/kolejny serwis "backend for frontend".

Moje pytanie jest takie- czy są jakieś sprawdzone albo rekomendowane sposoby na zabezpieczenie API tak aby można było dopuścić komunikację tylko ze strony tych aplikacji mobilnych? Dodam że aplikacje nie będą wymagać zalogowania, więc uwierzytelnianie użytkownika nie wchodzi w grę. Czy w ogóle Waszym zdaniem próba zabezpieczenia tego i ograniczania dostępu tylko klientom mobilnym ma tutaj sens? Jedno co mi przychodzi do głowy to jakiś API key załączony z aplikacją na telefonie. Tylko że na nic się to zda jeśli ktoś naprawdę będzie chciał wysyłać requesty bezpośrednio, bo zrobi reverse engineering i sprawdzi co jest wysyłane w requestach.

0

napisz albo znajdz detekcje, czy meta ma w sobie mobile

0

@FullSnack: problem w tym że to jest połowiczne rozwiązanie. Nie chodzi o to żeby ograniczyć przyjmowanie requestow do urządzeń mobilnych (jakichkolwiek), tylko do konkretnych aplikacji mobilnych.

0

To może klucze API? Każda aplikacja miałaby zaszyty klucz który byłby przesyłany w nagłówkach żądania i walidowany po stronie proxy/backendu

5

Jeżeli ma to być rozwiązanie z perspektywy security, to wydaje mi się że z uwagi na to jak działa HTTP, to nie da się tego w 100% zrobić aby wymusić mobile device only / dana appka.

Waszym zdaniem próba zabezpieczenia tego i ograniczania dostępu tylko klientom mobilnym ma tutaj sens?

pytanie tylko czy to problem, że ktoś skorzysta z serwisu przeznaczonego dla mobilek z innego urządzenia / curlem / postmanem itd?

0

Jedyną opcją jaką widzę to mTLS z kluczem klienta trzymanym w jakiejś enklawie, z której nie da się wyciągnąć klucza prywatnego. Pozostaje jedynie kwestia tego jak uwierzytelnić klucz publiczny.

2

Jeżeli celem jest "nie może dać się połączyć z backendem z poziomu innych aplikacji" to w skrócie - nie da się.
Jak wystawiasz API po HTTP, to nie da się zablokować żądań wykonanych np. Postmanem. Żeby identyfikować klienta, potrzebujesz przechowywać jakiś sekret po jego stronie, czyli poza twoją kontrolą. Teoretycznie urządzenia mobilne mają wbudowane key vaulty, do których nic poza koszerną aplikacją nie ma dostępu, tylko jakoś trzeba ten sekret tam załadować. Czyli masz ten sam problem co wcześniej, tylko w trochę innym miejscu.

Ostatecznie wszystko sprowadza się do standardowego podejścia w budowaniu API - uwierzytelnianie użytkownika / usługi, które się łączą z twoim API. Polecam skorzystanie do tego celu z jakiegoś zewnętrznego serwisu typu FireBase, czy inne Auth0. W przypadku tego pierwszego masz o ile pamiętam jakieś delikatne zabezpieczenia na właściwy podpis łączącej się aplikacji, przynajmniej w przypadku Androida. Generalnie użycie tych usług ma sens również w przypadku aplikacji webowych, szczególnie biorąc pod uwagę jak kiepsko potrafią być zaimplementowane uwierzytelnianie i autoryzacja (na przykładzie wyciekających co chwila zbiorów danych z tego, czy innego sklepu).

0

@Aventus: wtedy ta sama detekcja ale konkretnej aplikacji ( mozna zrobic i czy jest mobile i czy jest od danej aplikacji mobile)
w zasadzie wiedzac, czy dany request jest mobile , mozna zalozyc , ze dana apka requestujaca ,tez jest mobile

2

ale jak ktoś spreparuje request to jak chcesz to wykryć? Chodzi o to, że jeśli API będzie filtrowało po czymś co jest jawne (np. nie będzie w requeście przychodził jakiś zaszyfrowany / podpisany secret czegoś co API wysłało wcześniej tylko jakiś stały text, np. i'm from ebedded) to odpowiednio uparty człowiek taki request spreparuje. A jeśli coś będziesz szyfrował/podpisywał/whatever to gdzieś te klucze musisz mieć i do nich też się będzie odpowiednio uparty człowiek mógł dostać. Generalnie z każdej strony dupa.
Jeszcze nikt nie wymyślił zabezpieczenia nie do złamania - jest tylko kalkulacja kosztów do zysków.

1

Nie wiem czy chodzi o zabezpieczenia ale zostało to tu chyba idealnie podane na tacy : Web API a weryfikacja klientów mobilnych

Ja pisze o wykrywaniu czy jest mobile czy nie , bo chyba takie bylo pytanie .. Jesli chodzi o zabezpieczenie to dlaczego nie dac w headers jakiegos tokena , uwierzytelniająco-informacyjnego

0

Czy nie robi się tego przez wystawianie certyfikatów na komputer klienta ?
Tak samo można zainstalować certyfikat na Androidzie - przy założeniu że aplikacja jest dla konkretnej, wąskiej grupy odbiorców.

1

@FullSnack: Bo przechwycenie tokena w nagłówku http jest trywialne, jak go masz, to możesz użyć gdzie chcesz podobnie z pomysłem @gosc_z_pytaniem - ten certyfikat jest na urządzeniu do którego użytkownik ma pełne prawa.

0

Ok, masz intranet mikroserwisow i chcesz dodac nowych klientow mobilinych, ktorzy beda bez uwierzytelniania.

Siłą rzeczy rozwiązaniem będzie jakieś API gateway

ciężko inaczej - jakieś proxy , ktore odwołuje się do jakiegoś endpoint, który gada z mikroserwisami

API key załączony z aplikacją na telefonie

jesli bez uwierzytelniania to srednio ma to sens (chyba , że taki bogus, zmylenie tropu ) jednak to :

wysyłać requesty bezpośrednio, bo zrobi reverse engineering i sprawdzi co jest wysyłane w requestach

możesz użyć np. Websockets (tak, że tylko serwer może wysyłać do klienta) i robić pseudo-uwierzytelnianie (a raczej generowanie hasha (czy czegos)) do tego proxy - w oparciu o to co możesz wydobyć, na temat sprzętu/telefonu/tableta którego używa i generować unikalną sygnature dla kazdego podłączonego klient- w ten sposob możesz też wyciąć szybko ddos, oraz próby ataku np. z cli

0

Wybaczcie, nie kliknąłem obserwacji wątku i nie wiedziałem że jest tyle odpowiedzi...

@WeiXiao

pytanie tylko czy to problem, że ktoś skorzysta z serwisu przeznaczonego dla mobilek z innego urządzenia / curlem / postmanem itd?

Na pierwszy rzut oka nie ale bardzo ważne są miarodajne statystki dla działu marketingu. Gdyby z jakiegoś powodu ktoś zaczął się bawić requestami wychodzącymi spoza naszych aplikacji mobilnych, i uderzał do API przeznaczonego właśnie dla tych aplikacji mobilnych to statystyki zostałyby zakłamane.

@hauleth możesz to rozwinąć lub podesłać link(i)?

@piotrpo uwierzytelnianie użytkownika odpada, bo aplikacja ma głownie cel marketingowy i ma zapewnić jak najmniejsze przeszkody dla użytkownika. Anonimowe używanie tychże aplikacji to jedno z fundamentalnych wymagań biznesowych i nie podlega dyskusji- czy mi się to podoba czy nie.

@FullSnack możesz to rozwinąć? Czym w takim przypadku jest ta "meta" i dla czego ktoś nie mógłby tego nadpisać np. w Postmanie?
Oraz co do tego:

Ja pisze o wykrywaniu czy jest mobile czy nie , bo chyba takie bylo pytanie

Nie, chodzi o konkretne aplikacje mobilne (te stworzone przeze mnie).

@abrakadaber

ale jak ktoś spreparuje request to jak chcesz to wykryć?(...) Generalnie z każdej strony dupa.

No właśnie o to się rozchodzi :)

@gosc_z_pytaniem

Tak samo można zainstalować certyfikat na Androidzie - przy założeniu że aplikacja jest dla konkretnej, wąskiej grupy odbiorców.

Docelową grupową odbiorców są anonimowe osoby mogące zainstalować aplikację z Google Play/Apple App Store.


Ogólnie chodzi o to że jest system ubezpieczeniowy dostarczający informacje o polisach- celem jest ograniczenie tego aby każdy mógł sobie dowolnie z tego systemu korzystać podszywając się pod klienta mobilnego (tego którego my stworzyliśmy). O ile to w ogóle możliwe- stąd też ten wątek. Do tego dochodzi kwestia statystyk którą opisałem w odpowiedzi do WeiXiao.

1

A ja powiem - nigdy nie byłem religijny zwolennikiem REST zawsze i za każdą cenę - że apkę mobilną można połączyć na wielu różnych protokołach, a nie tylko HTTP+REST
(zwłaszcza że połowa wdrożeń REST , to jest REST zgwałcony)

Np bardzo dobrze - co sprawdziłem własnymi paluchami - apke mobilną z centralnym serwerem się łączy Apache Thrift.
Wydajnie, z małym obciążeniem RAM, sieci i procesorów, i cokolwiek bardziej dyskretne.

Dobre RPC nie jest złe, pozwala np nie kłamać, że mamy bezstanowy REST. A dziś to wiedza zaginiona, z "dinozaurami", a młodym się RPC przekazuje w strasznych bajkach, jak o czarnym wilku.itd..

Chory w stosunku do wymagań początkowy wybór (tu: wysoce otwarty meta-protokoł REST, gdy chcemy zamknięty) - to potem wychodzi szydło z worka.

1

@Aventus:

Na pierwszy rzut oka nie ale bardzo ważne są miarodajne statystki dla działu marketingu.

A może to nie problem komputerowy, a data scajensowy?

Czy statystyka oferuje jakieś narzędzia aby odstrzelić takich gagatków?

dodać do tego jakiś monitoring/alert wykrywający podejrzane zachowanie np. 100 requestów w 30sec, jakaś powtarzalność - strzelam sobie

aby ich pomijać

1

Jeśli to tylko dla Twoich aplikacji, to dlaczego nie jakies uwierzytelnianie w oparciu o email albo sygnature sprzetowa...

Meta, jesli to sa requesty https, to masz tez tzw. headers (nagłówki) , tam możesz dodac co chcesz, np. kazdorazowo jakis wygenerowany token z twojej apki, który jest unikalny dla każdego klienta

Screenshot from 2021-08-29 15-03-19.png

Masz tu rozne naglowki, mozna dodac swoj p. X-SUPER-SECRET-TOKEN : jakis.token.dla.proxy(gateway)

1 użytkowników online, w tym zalogowanych: 0, gości: 1