[sha128]

Jak wysyłać podpisane requesty do API z frontendu? #php #js #programowanie #webdev #api

Mam prosty panel admina/użytkownika (w zasadzie taki CRUD w php) i wszystkie dane użytkownika są ładowane i wypluwane po zalogowaniu, ale dodałem taką funkcjonalność że JS na frontendzie co 5s odpytuje API o te dane użytkownika żeby je odświeżyć na stronie bez konieczności jej przeładowywania (takie złudzenie dla usera że dane się na żywo zmieniają).

Ale teraz rozkminiam jak to zrobić żeby user po przejrzeniu zakładki network w devtoolsach nie mógł z ręki wejść na URL danego API i samemu pociągać danych z niego. Wyczytałem że do tego stosuje się JWT albo bearer token i obejrzałem parę poradników implementacji ale dalej mi coś nie gra.

W teorii JWT do każdego zapytania do API powinien dorzucać mi unikalny token tak aby nie dało się dwa razy wysłać requestu z tym samym tokenem, i o ile rozumiem po stronie PHP jak to ogarnąć no bo kod jest tajny, to z kolei na frontejdzie w JS skąd idą zapytania to kod jest jawny więc będzie można sprawdzić metodę generowania tych tokenów i koniec końców będzie można samodzielnie wykonać taki request z przęglądarki/postmana pomijając mój panel.

Dochodzi też druga sprawa, to co ja teraz opisałem to metoda GET która tylko pobiera dane usera, ale chciałbym też wysyłać POSTy z danymi które wpisze user, no i chciałbym aby to też w jakiś sposób było podpisywane żeby gościu nie otworzył postmana i nie wsadził tam jakiś danych i wysłał mi milion requestów

I cały mój problem się tu rozchodzi czy w ogóle da się to w 100% zabezpieczyć, a jak nie da to jakie jest do tego najlepsze podejście? bo chyba jakieś jest bo większość internetu teraz działa na frontedzie w js, autentykacja odbywa się przez API

[E.....o]

@sha128: token generujesz na backendzie i wysylasz na front, potem do kazdego requestu go dodajesz

[sha128]

wysylasz na front

@ElTalento: no ale wtedy user będzie mógł sobie podejrzeć ten token np. DUPA, i do każdego requestu doda sobie DUPA i już może robić co chce

[LaylaTichy]

więc będzie można sprawdzić metodę generowania tych tokenów

@sha128: jwt generujesz na backendzie i zwracasz z zapytaniem

czy w ogóle da się to w 100% zabezpieczyć

@sha128: nie da sie, jedynie tokeny i corsy na backendzie, bo i w sumie po co? nawet jakbys juz zrobil w 100% ze tylko z twojej strony moze pytac api, nic nie stoi na przeszkodzie, zeby ktos odpalil puppetera itd

no ale wtedy user

[E.....o]

@sha128: no bedzie mogl podejrzec payload tylko

[tos-1_buratino]

@sha128:
Nie wiem dlaczego chciałbyś maskować swoje API skoro po logowaniu dajesz userowi token za pomocą którego może korzystać z niego. Ale jak już musisz to możesz np. robić skrót kryptograficzny danego tokena i na podstawie tego skrótu generować unikalne adresy URL w API.
Poza tym unikalny token dla każdego zapytania jest bez sensu bo requesty z javascriptu działają asynchronicznie i za chwilę staniesz przed problem unieważniania tokenów w nieprawidłowej kolejności.

[nowiutki]

no ale wtedy user będzie mógł sobie podejrzeć ten token np. DUPA, i do każdego requestu doda sobie DUPA i już może robić co chce

@sha128: no ale przecież to właśnie robi za niego Twój frontend więc o co chodzi? Czemu chcesz zabronić użytkownikowi posługującemu się tokenem odpytać API np. Postmanem ale już przez frontend nie?

[sha128]

@nowiutki: @tos-1_buratino: @ElTalento: @LaylaTichy:

chodzi mi o to, jak się zabezpieczyć przed tym aby user po wysłaniu formularza POSTem do mojego api, nie wszedł w devtoolsy, nie kliknął na ten wysłany request POST i nie wysłał go jeszcze 100 razy ręcznie

[LaylaTichy]

@sha128: mozesz robic jakies rate limity no ale dalej po co?

co za roznica czy wysle ci ten formularz 100x z postmana, czy 100x sz twojej strony jadac puppeterem czy nawet jakims tampermonkeyem?

[nowiutki]

@sha128: ale z tego co rozumiem przez Twój frontend jak będzie uparty to również może kliknąć 100 razy przycisk "Wyślij", tak?

[sha128]

ale z tego co rozumiem przez Twój frontend jak będzie uparty to również może kliknąć 100 razy przycisk "Wyślij", tak?

@nowiutki: tak, jak od nowa wypełni wszystkie pola, kliknie kapcze to może tak wysłać nawet i milion requestów

[E.....o]

@sha128: to kaz mu podać jakieś gui w requescie i po problemie

[E.....o]

GUID*

[nowiutki]

tak, jak od nowa wypełni wszystkie pola, kliknie kapcze to może tak wysłać nawet i milion requestów

@sha128: no to przecież to jest dokładnie to samo ;)

Jaką różnicę dla backendu robi czy ten request był wysłany przez HTMLowy formularz czy np. Postmanem? Dla backendu ważne jest, że user jest zautentykowany, request jest zautoryzowany, a dane zwalidowane.

[KombinatorAstralny]

@sha128: Chodzi o jakieś zabezpieczenia przed CSRF czy inne #!$%@? muje ?

[sha128]

@nowiutki: @LaylaTichy: no dobra jak to przemyślałem to nie ma znaczenia skąd mi wyśle te requesty, zrobię tylko te JWT żeby było i starczy

[Cimcirimcipiririri]

nie wysłał go jeszcze 100 razy ręcznie

@sha128: a) rate limiter na podstawie ip i/lub ilości zapytań i/lub useragenta i/lub JWT w jakimś okienku czasowym,
b) być może wysyłany formularz ma jakieś pole które jest swoistym kluczem unikalnym, jakiś unikalny serial number czy pesel czy coś takiego, i możesz zwalidować ze formularz o takim kluczu unikalnym został już zsubmitowany i wywalić mu errora
c) wyciągaj hash z formularza i zapisuj go

[NieBendePrasowac]

@sha128: czyli innymi słowy, chodziło Ci o zabezpieczenie API przed atakiem DoS? @Cimcirimcipiririri dobrze opisal metody, o tej trzeciej nie pomyślałem.