Cześć, jak zabezpieczacie swoje publiczne endpointy w NEXT JS?
Da sie zrobić tak, aby możliwe było uderzenie do nich jedynie z tego samego frontu? Czyli żeby nikt z żadnych postmanów nie mógł spamować?
Używacie dodatkowo jakiejś ReCAPTCHy albo czegoś podobnego? Podobno są problemy z rodo z nią.
A jak niby miałbyś to rozróżnić?
To jest po prostu request http, przeglądarka wysyła taki sam jak postman. Nawet gdyby przeglądarka wysyłała jakieś specjalne znaczniki, to nadal bot lub inny client mógłby wysłać takie same. Żeby to zrobić, przeglądarki musiałyby mieć specjalne klucze prywatne, i się autentykować że są jednymi z dopuszczalnych klientów, ale to nadal by nie rozwiązało Twojego problemu, bo z takiej przeglądarki nadal możesz strzelić tysiącem niechcianych żądań.
Także w taki sposób się tego nie da osiągnąć.
Jedyne co chyba realnie możesz wprowadzić to jakieś limity requestów z danego IP. Jeśli ktoś będzie chciał spamersko walić z jakiegoś serwera to po kilku/nastu/dziesięciu próbach blokujesz. Albo captcha - to dość ciężko (jeszcze póki co) obejść botami.
cerrato napisał(a):
Jedyne co chyba realnie możesz wprowadzić to jakieś limity requestów z danego IP. Jeśli ktoś będzie chciał spamersko walić z jakiegoś serwera to po kilku/nastu/dziesięciu próbach blokujesz. Albo captcha - to dość ciężko (jeszcze póki co) obejść botami.
W tym przypadku to pewnie nie ma wiekszego znaczenia, ale co do zasady lepiej throttlowac uzytkownikow a nie IP bo mozesz w ten sposob np. cala uczelnie albo biurowiec wyciac :)
stivens napisał(a):
W tym przypadku to pewnie nie ma wiekszego znaczenia, ale co do zasady lepiej throttlowac uzytkownikow a nie IP bo mozesz w ten sposob np. cala uczelnie albo biurowiec wyciac :)
Userów - owszem, ma to sens, ale zauważ, co napisał parę postów wcześniej autor wątku - Większość endpointów zabezpieczam JWT ale /register z wiadomych powodów nie. Skoro masz problem/obawę że będzie spamowanie/atak botów na endpoint od rejestracji, to nie da się przecież blokować usera, bo on jeszcze nie istnieje/dopiero powstaje na tym etapie.
Pytanie do @Bambo - czy masz realne podstawy, żeby się tego obawiać, coś się dzieje/działo albo z innego powodu jesteś przekonany, że coś będzie się działo, czy to takie dmuchanie na zimne i zabezpieczanie przed czymś, co może się nigdy nie przytrafić?
@cerrato: dmuchanie na zimne :)
Podpiąłem captche 3, ale rodo w związku z tym trochę pokomplikowane. Mam mechanizm do zarządzania cookiesami, ale nie czaję co mam zrobić jak user nie wyrazi zgoody na cookiesy, które instaluje captcha 3. Wyłączyć wszystkie formularze ? ;P
nie wszystkie cookisy podlegają pod rodo, jedną z grup są "niezbedne do działania systemu" i ich nie można wyłączyć przez odnowę zgody na cookisy.
Co do cookies, RODO oraz captcha:
rozmowa jest rejestrowana, jak nie wyrażasz zgody to zakończ rozmowę@cerrato: dla precyzji "identyfikacjia usera" też musi być specyficzna np na potrzeby remarketingu, reklam i tak dalej. Jeśli jest to identyfikacji w postaci cookisa sesji która jest niezbędna do działania systemu to nie ma potrzeby prosić o zgodę o użycie takiego cookisa.
https://wideangle.co/blog/is-recaptcha-illegal-under-gdpr
@ehhhhh: @cerrato
Z tego co tu czytam to nie jest tak łatwo i kolorowo jak opisujecie :)
https://www.akamai.com/products/app-and-api-protector
Co prawda rozwiazanie enterpirse, ale dla przykładu duże firmy w ten sposób to rozwiązują.
Bambo