[husky83]

Mam pytanie z zakresu #php #programowanie #webdev.
Muszę udostępnić pewno API dla aplikacji napisanej w JS. Jaki jest najskuteczniejszy sposób na zabezpieczenie takiego API przed strzałami z CURL'a i podobnych?
Domyślam się, że niestety przed skryptami doklejonymi do przeglądarki i strzelającymi do API się raczej nie obronię...

[D.....a]

@husky83: Chodzi o zmniejszenie liczby zapytań czy odrzucenie tych, które nie pochodzą z dopuszczonego źródła?

[husky83]

@Dzyszla: najlepiej obydwa, ale póki co odrzucenie tych nie wywołanych przez moją apkę (stronę) w JS.

[D.....a]

@husky83: Musisz jakiś mechanizm uwierzytelnienia (autoryzacji) stworzyć. Można posłużyć się którąś ze stosowanych metod. Możesz też opracować własną, np. wysyłając w żądaniu dane logowania, w przypadku poprawnym odpowiedzieć kluczem, który będzie musiał być dołączany do kolejnych żądań i będzie identyfikował uwierzytelnioną aplikację, a wszystkie zapytania z kluczami, które nie pasują do bazy uwierzytelnionych, będą odrzucane.

Druga opcja to np. jeśli znasz strukturę sieciową, skąd będą przychodzić żądania - to wówczas łatwo

[Andy77Kl]

Dorzuc do zapytania dodatkowy parameter z jakimś hashem który wygenerujesz i porównasz po obu stronach

[croppz]

ale póki co odrzucenie tych nie wywołanych przez moją apkę (stronę) w JS.

@husky83: ale tak właściwie to po co? Ktoś będzie chciał dane to użyje selenium zamiast curla, żadna przeszkoda. Jak nie chcesz żeby ludzie scrapowali stronę to dodaj po prostu rate limitera jakiegoś i po przekroczeniu rzucaj 429.

[nowiutki]

odrzucenie tych nie wywołanych przez moją apkę (stronę) w JS.

@husky83: nie da się tak, skoro apka jest w JSie po stronie klienta to kod jest publicznie jawny. Żadne uwierzytelnianie, ani hashe nic tu nie dadzą. Jak ktoś będzie chciał to i tak się dokopie do tych "zabezpieczeń". Referer/origin można sobie również zmienić.

Jedynie rate limiter i banowie spamerskich IP.

[D.....a]

@nowiutki: Jeśli uwierzytelnianie byłoby częścią wprowadzanych przez użytkownika danych, to da :) Oczywiście, nie na stałe w kodzie, bo to sensu nie ma, jak piszesz.

[nowiutki]

Jeśli uwierzytelnianie byłoby częścią wprowadzanych przez użytkownika danych, to da

@Dzyszla: oczywiście, ale z tego co zrozumiałem to OP chce mieć publicznie dostępną aplikację nawet dla gości, ale chciałby, żeby requesty pochodziły tylko z "legitnie" odpalonego ajaxa z jego stronki.

[D.....a]

@nowiutki: Racja. Przydało by się więcej informacji - @husky83 - może się do tego odniesiesz i powiesz, jak to wygląda?

[D.....a]

Niemniej, mam jeszcze pomysł - skrypt, który jest dynamicznie tworzony i możliwy do wykonania tylko przez określony czas. Jeśli to Twoja strona udostępnia skrypt, to może mogłaby ona przekazać zaszyfrowany czas (algorytmem tylko sobie znanym) i zapisze go w wygenerowanym skrypcie. Wówczas taki skrypt przesyła tą informację, a w API dekodujesz i sprawdzasz, czy jest to skrypt np. sprzed 5 minut.
Więc nawet jeśli ktoś ukradnie skrypt, to będzie on użyteczny tylko

[rhqq]

@husky83: w nginxie zrób sobie pierwszą linię walki, tylko urle pasujące do wszystkich handle w api przyjmuj, resztę od razu 403, te, które przepuszczasz daj rate limitting rozsądny. a później juz jak ktoś wspomniał, jakiś api-key zrób, starczy md5(zapytanie + klucz uzgodniony z klientem), i bedziesz w stanie szybko uwierzytelnić zapytanie. jeśli chcesz sie zabezpieczyć jeszcze przed tzw replay attacks, to musisz dorzucić do tego unixtimestamp i liczyć +/- 10s czyli

[husky83]

@croppz: 429 jest najrozsądniejsze, ale nie blokuje kogoś, kto strzela z wielu curl'i. Niestety nie mogę dać limitu na IP, bo zdarzają się całe sieci osiedlowe na jednym IP.

oczywiście, ale z tego co zrozumiałem to OP chce mieć publicznie dostępną aplikację nawet dla gości, ale chciałby, żeby requesty pochodziły tylko z "legitnie" odpalonego ajaxa z jego stronki.

@nowiutki: Dokładnie tak.
@Dzyszla: Ogólnie sprawa wygląda tak. Jest sobie pewna

[D.....a]

@husky83: A ktoś ładuje stronę wcześniej, żeby pobrać informację? Naprawdę można by zrobić limit wtedy 2 żądań i obowiązek przeładowania strony. A tu sobie łatwiej poradzisz. Po prostu przypiszesz token, który sobie zachowasz podczas generowania strony i będziesz liczył, ile na tym tokenie poszło zapytań.

[rhqq]

@husky83: i nie zapominaj, ze wielu klientów uzywa curl/libcurl jako ich narzędzia do interfejsowania sie z api, wiec blokowanie curla to strzał w stope ;-)

[husky83]

@rhqq: To ma być tylko i wyłącznie dostępne z aplikacji, nikt "legalnie" z curla nie ma do tego strzelać :-)

[rhqq]

@husky83: to ci zaspoofuję curlem chroma czy inne dowolne narzędzie. patrzysz na to ze złej strony. token czasowy + klucz api i nginx do akceptowania tylko tego co jest zgodne z regexpem z lista uchwytów api i tyle

[LuckyLuke_2776]

Jaki jest najskuteczniejszy sposób na zabezpieczenie takiego API przed strzałami z CURL'a i podobnych?

@husky83: https://jwt.io

[croppz]

@husky83: chcesz zablokować scrapowanie to opcje są właściwie dwie, rate limiter albo captcha co kilka requestów. Wszystko inne co wymyślisz to będą tylko upierdliwe szczegóły.

Oczywiście rate limitera możesz obejść korzystając z odpowiednio dużej puli proxy, captchę możesz obejść wynajmując Hindusa. Ale to już powiedzmy poważniejsze przeszkody, niż konieczność wykonania dodatkowego requesta, ustawienia kilku headerów albo puszczenia całości przez selenium. Jakby dane faktycznie były warte kradzieży, to zawsze można też wziąć

[husky83]

@croppz za tą fotkę powinienem Ci 5 plusów dać. Przekaże ja szefowi, może zrozumie problem ( ͡º ͜ʖ͡º)