Zabezpieczenie końcówek REST przed wyciekiem danych

Odpowiedz Nowy wątek
2020-03-12 17:37

Rejestracja: 9 lat temu

Ostatnio: 4 dni temu

0

Cześć,
Temat dość nietuzinkowy. Chciałbym poznać Wasze sposoby na radzenie sobie z problemem bezpieczeństwa danych. Aplikacja typu Client Side. Komunikacja z back-endem po restach. I teraz spójrzcie, mamy pole gdzie podajemy pesel klienta i po tym peselu przekazywanym jako input do resta, pobieramy dane personalne klienta. Oczywiście aby było wszystko jasne. Aplikacja działa w sieci wewnętrznej i nie jest absolutnie nigdzie udostępniana. Osoby które z niej korzystają mają rzecz jasna dostęp do tych danych i mogą je oglądać. Problem jest nieco głębszy. Autoryzacja odbywa się za pomocą tokena JWT. Załóżmy że mamy jakiegoś nie do końca uczciwego pracownika który kopiuje sobie token bezpieczeństwa i powiedzmy za pomocą postmana naparza w tą końcówkę peselami z generatora pobierając (oczywiście przy założeniu że trafi w pesel) dane klienta, budując sobie w ten sposób jakąś tam bazę którą może później sprzedać. Pytanie zadałem nie dla tego że nie mam pomysłu jak problem rozwiązać lecz bardziej chodzi mi o to, że może ktoś z Was podsunie jeszcze jakiś inny pomysł. To co mi przyszło do głowy i z czym się spotkałem, to był głównie monitoring. Monitorowanie ilości zapytań, jakiś system anty-fraud między serwerem http a back-endem w celu wyłapywania takich masowych zapytań. Timeouty na usługach tzn. dany user może strzelić w konkretną końcówką określoną ilość razy w jednostce czasowej. Generalnie wszystkie rozwiązania z jakimi się spotykałem to rozwiązania bardziej monitorujące ruch i wyłapywanie takich żądań. Pytanie czy są jakieś inne sposoby na radzenie sobie z takimi problemami.

Pozostało 580 znaków

2020-03-12 17:40
Moderator

Rejestracja: 16 lat temu

Ostatnio: 13 godzin temu

2
  1. Przecież ten JWT wiadomo do kogo należy.
  2. Co za problem robić statystyki requestów? Wiesz który user, wiesz kiedy, wiesz kogo sprawdzał. Nie bardzo rozumiem gdze masz problem.

Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...

Pozostało 580 znaków

2020-03-12 17:43

Rejestracja: 9 lat temu

Ostatnio: 4 dni temu

0

Oczywiście że tak. i takie coś jest robione. Każdy request jest logowany i logi trzymane są przez miesiąc czasu natomiast chodzi mi bardziej o jakieś programistyczne zabezpieczenie przed takimi rzeczami bo łapanie tego poprzez monitoring już mam i jest to robione :)

Pozostało 580 znaków

2020-03-12 17:48

Rejestracja: 1 rok temu

Ostatnio: 1 godzina temu

2

Możesz go odcinać. Jak np koleś z jednym tokenem odpytuje kilka razy na sekundę, to samo api, jeszcze z błędnym PESELem to go blokujesz na jakiś czas. Nie jesteś sie wstanie przed tym zabezpieczyć na 100 %.

Pozostało 580 znaków

2020-03-12 18:49

Rejestracja: 4 lata temu

Ostatnio: 13 godzin temu

5

Znaczy, chcesz się zabezpieczyć przed tym, że uprawniony ziomek zobaczy dane, do których jest uprawniony? ;-)

IMO powinieneś mieć wypracowane odpowiednie podejście biznesowe. Zastanówmy się, dlaczego ktoś miałby odpytywać po dowolnym PESEL?

Dostęp do określonych danych/osoby (via PESEL) nie wynika z zachcianki, tylko ma jakąś motywację biznesową. Jaka to motywacja/przyczyna/sprawa (kontekst)? Dodając taki kontekst do API, mógłbyś odpytać po PESELU tylko w konkretnym przypadku, a nie za każdym razem i dla każdego PESEL. Np. dostęp do konkretnych danych potrzebny jest do obsługi wniosku X. Jeśli wniosek X został przetworzony (proces "obsługa wniosku" zmienił status z "nowy" do "zakończony"), to odpytywanie o taki PESEL mogłoby zwyczajnie przestać działać .

Oczywiście można marudzić na takie podejście, że przecież to skomplikuje interfejs itd. No chyba, że interfejs "by design" ma udostępniać wszystkie dane ;-)

edytowany 1x, ostatnio: yarel, 2020-03-12 18:50

Pozostało 580 znaków

cmd
2020-03-12 19:33
cmd

Rejestracja: 5 lat temu

Ostatnio: 8 godzin temu

Lokalizacja: Warszawa

2

Może wystarczy skrócić czas ważności tokenu? No chyba że macie wieczne tokeny to faktycznie torchę przypał ;]

Pozostało 580 znaków

2020-03-12 19:33

Rejestracja: 6 lat temu

Ostatnio: 8 godzin temu

1

Można to ograć rolami czyli np. tylko dla pracownika A dane klienta o peselu X zostaną zwrócone, użytkownik B dostanie 403.

Pozostało 580 znaków

Odpowiedz

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