GoldenLine
Zaloguj się
Marcin D.

Marcin D. frontend & backend
developer

Temat: Zabezpieczanie danych

Generuje XML, przetwarzam i wyswietlam dane na stronie.
Jakie metody mozna stosowac do zabezpieczenia przed "pobieraniem automatami" wygenerowanych danych?
1. blokowanie IP,
2. sesje,
3. $PHP_SELF.

Sa jakies skuteczne metody?
Link do wypowiedziLink
Tomek Łos

Tomek Łos Tom Eł

Temat: Zabezpieczanie danych

Hej!

Na jakiej podstawie generujesz XMLa? Na podstawie hasła (podanego np. w urlu?), co chcesz zabezpieczyć i dlaczego?

1. blokowanie IP - a jak automat jest ustawiony na tym komputerze z tym IP?
2. sesje - małe piwo dla automatów - wystarczy odpowiedni nagłówek z ciachem
3. nie mam pojęcia co masz na myśli....

Napisz mi proszę co chcesz blokować i dlaczego :)
Link do wypowiedziLink
Marcin D.

Marcin D. frontend & backend
developer

Temat: Zabezpieczanie danych

Zakładając, że dane źródłowe są bezużyteczne, a odpowiednio przetworzone nabierają wartości przez co mogą stać się łupem np. konkurencji, której jeszcze nie ma.
Dzięki "ajax-owi" skrypt odczytuje dane z plików XML i wyświetla je więc nie zostaje generowana po stronie serwera. Pozostaje tylko zabezpieczenie generowanych plików XML i stąd moje pytanie.
1. tak naprawdę pierwsze rozwiązanie (blokada IP) omijam z daleka,
2. jeśli automat nie zna nazwy sesji to raczej nie powinien dostać się do danych. Założenie: przeglądamy stronę z $_SESSION['blokada']=1, a gdy odwołujemy się do skryptu generującego XML na poczatku jest warunek if($_SESSION['blokada']==1),
3. if(!$_SERVER['PHP_SELF']) - czy "automat" to obejdzie?
Link do wypowiedziLink
Tomek Łos

Tomek Łos Tom Eł

Temat: Zabezpieczanie danych

2. jeśli automat nie zna nazwy sesji to raczej nie powinien dostać się do danych. Założenie: przeglądamy stronę z $_SESSION['blokada']=1, a gdy odwołujemy się do skryptu generującego XML na poczatku jest warunek if($_SESSION['blokada']==1),

Jeśli użytkownik się loguje (login+hasełko) i jest zapamiętywane coś w sesji to ok. Ale przecież jeśli automat zna login i hasełko, to będzie działał dokładnie jak użytkownik. Czyli wpierw wejdzie na stronę z $_SESSION['blokada']=1 a później do XMLa.
Link do wypowiedziLink
Marcin D.

Marcin D. frontend & backend
developer

Temat: Zabezpieczanie danych

Miałem na myśli prosty automat czytający bezpośrednio po URL /plikxml.php?id={1-50000} - przy uruchomieniu z cron'a sesja nie przetrwa. Czasami wystarczy delikatnie utrudnić życie, a jeśli ktoś faktycznie będzie chciał pozyskać te dane to zrobi to nawet ręcznie.
Link do wypowiedziLink
Tomek Łos

Tomek Łos Tom Eł

Temat: Zabezpieczanie danych

Ja jak robie automaty to nie tylko lecące po URL ale korzystające z sesji. Jednakże aby to zrobić musi się znać poprawne hasło i login - bez tego ani rusz.

Podsumowując:
Wg. mnie jeśli stronę XML zabezpieczysz odpowiednio sesją to niepowołane automaty nie mają większych szans bez loginu i hasła
Link do wypowiedziLink
Sebastian Marek Gruchacz

Sebastian Marek Gruchacz Senior .Net
Developer at Grupa
Pracuj

Temat: Zabezpieczanie danych

Zawsze jeszcze można dodać sprawdzanie HTTP_REFERAL (czy jakoś tak)... oczywiście jest to zabezpieczenie, które łatwo ominąć... jak sie wie, że jest :P Plus kilka innych sprawdzeń z dziedziny sesji, informacji o przeglądarce, generowanych automatycznie numerów itp., które piszący bota zazwyczaj nie od razu umieści w nagłówkach.
A tymczasem można zwracać jakieś pseudo-bzdurne dane, albo wręcz mylące. Gdy jedno lub kilka takich sprawdzeń sie nie powiedzie należy od razu banować taki IP (albo lepiej konto, email itp) - mamy znak, że ktoś tam pisze bota :)
Link do wypowiedziLink
Paweł Knapik

Paweł Knapik Front-End Developer

Temat: Zabezpieczanie danych

Sebastian Gruchacz:
Plus kilka innych sprawdzeń z dziedziny sesji, informacji o przeglądarce, generowanych automatycznie numerów itp., które piszący bota zazwyczaj nie od razu umieści w nagłówkach.

Można wymyślać masę zabezpieczeń, a i tak będą one dość łatwe do obejścia. Botem może być plugin do Firefoksa, który nie da się odróżnić od prawdziwego użytkownika - chyba, że technikami typu CAPTCHA, ale to już byłby absurd, bo przecież mówimy tu o wyświetlaniu asynchronicznie pobieranych danych, czyli rozwiązaniu, które ma usprawniać interakcję.
Sensowne są jakieś proste, podstawowe mechanizmy, typu wspomniane już zmienne sesyjne, albo np. ustawienie dodatkowego nagłówka w zapytaniu XMLHttpRequest - zniechęcą tych, którzy chcieliby łatwo i szybko się "podpiąć". Ci, którym na danych będzie naprawdę zależało, poświęcą nie mniej wysiłku na ich zdobycie, niż my na ich zabezpieczanie :)
Link do wypowiedziLink
Sebastian Marek Gruchacz

Sebastian Marek Gruchacz Senior .Net
Developer at Grupa
Pracuj

Temat: Zabezpieczanie danych

To prawda... Osób wystarczająco zdeterminowanych nie zniechęcą nawet zabezpieczenia hardwarowe... Ale sporo osób może się uda zniechęcić wcześniej :)
Link do wypowiedziLink
Maciej Kuś

Maciej Kuś właściciel, ibex.pl

Temat: Zabezpieczanie danych

Marcin D.:
Miałem na myśli prosty automat czytający bezpośrednio po URL /plikxml.php?id={1-50000} - przy uruchomieniu z cron'a sesja nie przetrwa. Czasami wystarczy delikatnie utrudnić życie, a jeśli ktoś faktycznie będzie chciał pozyskać te dane to zrobi to nawet ręcznie.

A może zamiast podejścia plikxml.php?id=1...100000
stosować GUID'y?

plikxml.php?id=483874-A8743847-3874-ABN6574

No i zgadnij jaki jest następny identyfikator pliku xml w twojej bazie.

Myślę, że trochę utrudni to życie bota.
Link do wypowiedziLink
Marcin D.

Marcin D. frontend & backend
developer

Temat: Zabezpieczanie danych

Maciej Kuś:
Marcin D.:
Miałem na myśli prosty automat czytający bezpośrednio po URL /plikxml.php?id={1-50000} - przy uruchomieniu z cron'a sesja nie przetrwa. Czasami wystarczy delikatnie utrudnić życie, a jeśli ktoś faktycznie będzie chciał pozyskać te dane to zrobi to nawet ręcznie.

A może zamiast podejścia plikxml.php?id=1...100000
stosować GUID'y?

plikxml.php?id=483874-A8743847-3874-ABN6574

No i zgadnij jaki jest następny identyfikator pliku xml w twojej bazie.

Myślę, że trochę utrudni to życie bota.

Strona dostępna publicznie, więc można ją "przelecieć" i zdobyć wszystkie stałe id= jakkolwiek byłyby zakodowane.
W moim przypadku faktycznie proste szyfrowanie (rc4crypt::encrypt/rc4crypt::decrypt) ze zmiennym kluczem będzie dobrym dodatkowym zabezpieczeniem.
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

Pobranie danych z innej strony




Wyślij zaproszenie do
Anuluj