blokada anty-flood i anty-hack

0

Dzień dobry.

Mam taki problem. Chcę ustawić blokadę przeciw spamerom hackerom i innym szkodnikom. Mój skrypt generuje dane na podstawie wysłanego zakodowanego stringa z poziomu PHP do Django (Python) i z powrotem do PHP.

Chciałbym zrobić zabezpieczenie na nazwę usera i na IP. Tak sobie pomyślałam że usera zakoduję jakimś własnym kryptograficznym algorytmem, być może bazując na gotowych (np. SHA-256 z usunięciem kilku losowych znaków i dodaniu innych też w losowych pozycjach). Taki hash byłby zapisany w bazie i przypisany do usera. O ile to jeszcze w miarę ogarniam to nie wiem jak z IP. Czy można zabezpieczyć dane IP i czasowo blokować? Czy może mieć kilku userow takie samo (np. IP routera providera)? Jak to ogarnąć?

Dziękuję
Michał

3

Przeczytałem to ze 3 razy i dalej nie wiem co chcesz osiągnąć ani o co chodzi w twoim pomyśle.

Chcę ustawić blokadę przeciw spamerom hackerom i innym szkodnikom

Nie wystarczy stary dobry token?

Tak sobie pomyślałam że usera zakoduję jakimś własnym kryptograficznym algorytmem, być może bazując na gotowych (np. SHA-256 z usunięciem kilku losowych znaków i dodaniu innych też w losowych pozycjach)

  1. SHA-256 nie służy do kodowania 2. sorry ale nie wymyślisz lepszego algorytmu niż te obecnie dostępne 3. co taki (pseudo)losowy hash wniesie? Jak będziesz go weryfikował?

Taki hash byłby zapisany w bazie i przypisany do usera.

Nie rozumiem, chcesz zakodować (czy tam zahashować) usera a potem w bazie trzymać ten hash obok niezakodowanego usera?

O ile to jeszcze w miarę ogarniam to nie wiem jak z IP. Czy można zabezpieczyć dane IP i czasowo blokować?

Zabezpieczyć IP? Blokować można, ale wiele to nie da.

Czy może mieć kilku userow takie samo (np. IP routera providera)?

Tak, jeden user może mieć też milion różnych IP.

Jak to ogarnąć?

CloudFlare + jakiś auth token rozwiąże 99% twoich problemów.

0

Chodzi o zmodyfikowany hash, tak by jak ktoś zna nazwę usera nie mógł zakodować hasha ani zgadnąć, do kogo należy. Tak chce przechowywać ten hash w bazie i weryfikować na tej podstawie usera po czym ew. blokować.

Wspomniałeś o tokenie. Nie znam się na tym. Mógłbyś powiedzieć coś więcej na czym to polega? Jeżeli miałbym generować odrębny hash dla każdego autoryzowanego procesowania to jak rozpoznam usera?

0

Dzięki. A czy są biblioteki do generowania tokenów, tak żeby nie trzeba było być uzależnionym od innego hosta?

0

zescrolluj troszke nizej na tej stronie.
Masz do PHP masz do Pythona

0

Django Rest Framework ma jwt w standardzie -> https://django-rest-framework-simplejwt.readthedocs.io/en/latest/

2

2021 i dalej jest hype na JWT? Myślałem, że się skończył 3 lata temu. Nie używać JWT się nie wie po co. Zwykły authtoken wystarczy.
https://www.django-rest-framework.org/api-guide/authentication/#tokenauthentication

ledi12 napisał(a):

Django Rest Framework ma jwt w standardzie -> https://django-rest-framework-simplejwt.readthedocs.io/en/latest/

Skoro trzeba zainstalować osobną libkę to chyba tak średnio jest to w standardzie.

A skoro już mówimy o DRF, to jest też throttling który może zainteresować autora.

0

Dziękuję Panowie.

Mam pytanko, jak generuje się ten hash? Chodzi mi o to, że jak zainstaluję ten JWT, DRF or whatever, to chyba i tak będę musiał generować wysyłane dane przy pomocy JS albo innego client-side coś'a. A skoro tak, to gdzie tu bezpieczeństwo? :P

Chodzi o to, że ktoś może zajrzeć w źródło strony i je analogicznie skopiować i wykorzystać dla swoich potrzeb.

0

Nie rozumiem w ogóle problemu jaki masz. Skoro userzy są w systemie zalogowani to jaki masz problem sprawdzać czy ktos nie flooduje? Przecież widzisz w backendzie który user wysłał request. Czy te sesje usera są na bazie tokenów JWT czy czegokolwiek innego to w sumie bez żadnego znaczenia. Możesz opisać dokładnie co dokładnie masz i przed czym chcesz się bronic?

JWT działa tak ze user się "loguje" i dostaje z backendu token. Ten token ma różne informacje (np. login) plus podpis kryptograficzny (więc nie da sie tu nic zmienić). Taki token można sobie w backendzie zweryfikować.
Czyli twój JS niczego nie generuje sam, tylko wysyła login i hasło do backendu i dostaje token. Ten token dołączasz do requestów, a twoje backendy sprawdzają czy podpis się zgadza i jeśli tak, to wierzą ze przekazane w tokenie informacje są poprawne (np. login usera)

0

generujesz zawsze takie rzeczy na serwerze.
Pozniej wygenerowany token/hash/cotamchcesz wysylasz do consumera/clienta

Jaki sens jest generowanie tokena po stronie klienta?

0

@Shalom:
@fasadin:
Dzięki. Chodzi mi to to, że mój serwis będzie korzystać z PHP do obsługi strony, oraz Pythona, do którego z PHP chcę przesłać zakodowany wzór matematyczny. Python (Django) zwróci kod latex i kilka innych, ważnych rzeczy. Chcę zabezpieczyć się przed sytuacją, że ktoś podkradnie mi pomysł i zacznie używać mojej usługi w Django dla własnych, czy to prywatnych, czy komercyjnych celów.

Sory chłopaki, ale ja nigdy nie siedziałem aż tak przy projektach sieciowych, a mam już trochę lat na karku. Proszę, wytłumaczcie jak pastuch krowie na granicy, czy w sytuacji którą opisałem JWT czy DRF jest potrzebne, a jeżeli nie to co?

Może ten mój pomysł, żeby wykorzystać stały hash, generowany i zapisywany przy rejestracji w bazie, przez generację losowych znaków
(np. 64 [a-zA-Z0-9!@#$%^&*]) i sprawdzanie jak często dany login się łączy z Django?

1

Ależ robisz kombinacje alpejskie tutaj xD

  1. Twój serwis w PHP generuje payload (jakiegoś jsona czy co tam chcesz) + dodaje do niego podpis kryptograficzny
  2. Twój skrypt pythona weryfikuje podpis i jeśli się zgadza to przetwarza request
  3. Profit!

Dzięki temu tylko payloady generowane z twojego PHP będą akceptowane, a jakieś anty-floody możesz sobie zrobić w tymże PHP i tylko tam.

Swoją drogą równie dobrze mógłbyś tego pythona mieć w ogóle nie-publicznie wystawionego i przesyłać do niego requesty bezpośrednio z tego PHP server-to-server i nie trzeba by w ogóle nic kombinować. Stałby w wewnętrznej sieci widoczny tylko dla tego twojego PHP.

0

@Shalom:

Swoją drogą równie dobrze mógłbyś tego pythona mieć w ogóle nie-publicznie wystawionego i przesyłać do niego requesty bezpośrednio z tego PHP server-to-server i nie trzeba by w ogóle nic kombinować. Stałby w wewnętrznej sieci widoczny tylko dla tego twojego PHP.

Wow. Bardzo dziękuję za radę! Tego mi było trzeba. Sory za kiszenie ogórków na balkonie. Teraz już mam to, o co mi chodziło dzięki :)

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