Zabezpieczanie danych przed kradzieżą, Jak obronić się przed curl, imacros, itp Opcje

[lmdl]

Witam,

Szukam odpowiedzi na pytanie jak skutecznie zabezpieczyć własne dane na stronie, przed kradzieżą przez niepowołane osoby. Załóżmy że prowadzę sklep internetowy w którym jest wiele produktów z cenami. Sklep musi być dostępny dla każdego odwiedzającego. Jednak nie chciałbym aby konkurencja mogła napisać sobie skrypt który będzie "chodził" po moim sklepie i sprawdzał jakie mam ceny - żeby sobie ustawić niższą.

Macie jakieś sprawdzone na to metody ? Większość skryptów tego typu opiera się o sztywną strukturę strony i wyrażenia regularne - więc być może wystarczy wprowadzić jakąś losowość w strukturze strony.
Jakieś inne ciekawe pomysły ?

[Pawel_W]

jeżeli wprowadzisz jakąś losowość to i tak będzie się ona opierała o określony wzorzec i z pewnością będzie do obejścia przez wyrażenia regularne wg mnie nie ma takiego sposobu, który pozwoliłby zabezpieczyć taki serwis, możesz próbować, ale radzę się zastanowić, co jest dla Ciebie ważniejsze - potencjalny klient, którego takie zabezpieczenia mogą odstraszyć czy konkurencja, która, jeżeli byłaby wystarczająco uparta, może przecież dodawać ceny ręcznie

[lmdl]

Wydaje mi się że zmuszenie konkurencji do ręcznego wprowadzania danych przy odpowiedniej ilości danych mogło by pozytywnie wpłynąć na ich zniechęcenie. Przy wprowadzaniu losowości można w zasadzie zaprojektować nieskończoną ilość różnych szablonów przedstawiających od strony użytkownika dokładnie to samo. Problem w tym że jest to pracochłonne.

[ulow]

generować ceny jako obrazki przez GD? taki pomysł mi wpadł

[Pawel_W]

generować ceny jako obrazki przez GD? taki pomysł mi wpadł

i co, myślisz, że tego nie da się odczytać? te ceny musiałyby wyglądać jak captcha...

[Pilsener]

1. Używać autorskich aplikacji (których nie obsługują boty), napisanie dedykowanego bota pod jeden serwis opłaca się tylko wtedy, jeśli to naprawdę duży serwis a i tak jeśli coś zmienią to całą robotę trafia szlag
2. Używać filtrów anty-botowych, anty-spamerskich, czarnych list, rozwiązań typu limit żądań i danych dla jednego IP, jest tego cała masa, wystarczy poszukać, wybrać odpowiednie rozwiązania i zaimplementować.

[lmdl]

Dlaczego autorskich aplikacji nie obsługują boty ? Czym one się różnią od zwykłych stron ?

[ulow]

i co, myślisz, że tego nie da się odczytać? te ceny musiałyby wyglądać jak captcha...

a Ty myślisz, że ktoś specjalnie będzie zamawiać bota który odczytuje ceny z obrazków, bo chce ustawić o złotówkę niższą?

[erix]

że ktoś specjalnie będzie zamawiać bota który odczytuje ceny z obrazków

Człowieku, przecież wykorzystanie pierwszego lepszego OCR-a do takich rzeczy, to kwestia pięciu minut.

Próby blokowania takich botów, to jak walka z wiatrakami - kwestia czasu, aż ktoś to złamie.

[ulow]

więc ja pytam, po co w ogóle ten temat? przecież to tylko walka z wiatrakami, najlepiej nic nie rób.

[thek]

Zacznij od prostych, niepozornie wyglądających rzeczy, które dopiero w źródle strony zauważysz. Ja tak ostatnio zrobiłem prosty antybot. Jako że nie robiłem klikalnego maila, to cały adres mail w PHP napisałem "od tyłu" a na stronie zrobiłem proste jego odwrócenie przy użyciu CSS. Wygląda więc dla usera normalnie, ale próba Ctrl+C, Ctrl+V i tego typu widzi ten pisany od tyłu. Zamiast więc adres@domena.pl masz lp.anemod@serda. Sztuczka prosta, ale bot skopiuje adres bo widzi małpę. Adres jest niepoprawny i w bazie bota będzie puszczał dane w kosmos. A ktoś sobie zrobi adres ti.amo@domena.pl i co? lp.anemod@oma.it co spełnia warunki poprawności adresu mail i nawet człowiek sprawdzający maile pod kątem prawidłowych, nie wykryje przekrętu dopóki nie zajrzy w źródło strony. Z ceną można zrobić podobnie. User i tak nie zauważy odwrócenia a bot spisujący stronę nie zinterpretuje pewnie css prawidłowo tylko skopiuje wartość.

[nuntium]

Zacznij od prostych, niepozornie wyglądających rzeczy, które dopiero w źródle strony zauważysz. Ja tak ostatnio zrobiłem prosty antybot. Jako że nie robiłem klikalnego maila, to cały adres mail w PHP napisałem "od tyłu" a na stronie zrobiłem proste jego odwrócenie przy użyciu CSS. Wygląda więc dla usera normalnie, ale próba Ctrl+C, Ctrl+V i tego typu widzi ten pisany od tyłu. Zamiast więc adres@domena.pl masz lp.anemod@serda. Sztuczka prosta, ale bot skopiuje adres bo widzi małpę. Adres jest niepoprawny i w bazie bota będzie puszczał dane w kosmos. A ktoś sobie zrobi adres ti.amo@domena.pl i co? lp.anemod@oma.it co spełnia warunki poprawności adresu mail i nawet człowiek sprawdzający maile pod kątem prawidłowych, nie wykryje przekrętu dopóki nie zajrzy w źródło strony. Z ceną można zrobić podobnie. User i tak nie zauważy odwrócenia a bot spisujący stronę nie zinterpretuje pewnie css prawidłowo tylko skopiuje wartość.

Przecież odwrócenie stringu to kwestia jednej funkcji. W przypadku maili ma to sens - bo boty przeszukują setki stron. Ktoś kto pisze automat pod konkretny serwis z łatwością to zauważy i obejdzie.

Nie da się przed czymś takim zabezpieczyć.

[Fifi209]

Przyłączę się do erixa, nie ma sensu zabezpieczać się przed botami, możesz najwyżej utrudnić im zadanie, sprawdzając np. przesłane nagłówki.

Odwracanie stringu - jak napisał kolega @up kwestia kilku chwil, aby to obrócić.

Co do generowania cen jako obrazków w GD - 20 minut i gotowe, nie zrobisz z ceny captcha przecież...wszystko musi ładnie wyglądać.

Utrudnić się da - zablokować nie.
Ty się namęczysz, przyjdzie ktoś na giełdę, da potrzebującemu (np. mnie ) 50zł i gotowe. Serwisy typu nasza-klasa, lockerz... wszystkie ich zabezpieczenia idzie złamać w kilka chwil z developerskimi wtyczkami typu live http headers.

Ten post edytował fifi209 14.07.2010, 00:28:24

[darko]

Zacznij od prostych, niepozornie wyglądających rzeczy, które dopiero w źródle strony zauważysz. Ja tak ostatnio zrobiłem prosty antybot. Jako że nie robiłem klikalnego maila, to cały adres mail w PHP napisałem "od tyłu" a na stronie zrobiłem proste jego odwrócenie przy użyciu CSS. Wygląda więc dla usera normalnie, ale próba Ctrl+C, Ctrl+V i tego typu widzi ten pisany od tyłu. Zamiast więc adres@domena.pl masz lp.anemod@serda. Sztuczka prosta, ale bot skopiuje adres bo widzi małpę. Adres jest niepoprawny i w bazie bota będzie puszczał dane w kosmos. A ktoś sobie zrobi adres ti.amo@domena.pl i co? lp.anemod@oma.it co spełnia warunki poprawności adresu mail i nawet człowiek sprawdzający maile pod kątem prawidłowych, nie wykryje przekrętu dopóki nie zajrzy w źródło strony. Z ceną można zrobić podobnie. User i tak nie zauważy odwrócenia a bot spisujący stronę nie zinterpretuje pewnie css prawidłowo tylko skopiuje wartość.

Thek to jest genialne w swojej prostocie, ale skuteczne do momentu opublikowania tego postu Piszący różnego rodzaju boty i inny shit mogą sprawdzać poprawność adresu e-mail odwracając ciąg zawierający znak @ i Twoja koncepcja upada.

// edit
oO już ktoś zwrócił wcześniej na to uwagę, nie zauważyłem. Teraz przyszło mi jeszcze do głowy, ale w bardzo słaby pomysł: można zastosować wstawki flashowe z jakąś prawie niezauważalną animacją. Co o tym sądzicie? Wiem, że nie każdy ma zainstalowanego flasha, a także wydajnościowo byłoby kiepsko, ale może jest to jakieś skuteczne rozwiązanie?

Ten post edytował darko 14.07.2010, 02:13:51

[nuntium]

@darko
Dość ciekawy pomysł. Obsługa flasha byłaby wielkim utrudnieniem dla botów (zwłaszcza takich, które zawierają w sobie pare linijek curla). Do pewnego momentu byłby też skueczny js, ajax i wszystko co jest parsowane po stronie przeglądarki.

[erix]

Dość ciekawy pomysł. Obsługa flasha byłaby wielkim utrudnieniem dla botów

Dla użytkowników też. Sporo po prostu tę wtyczkę wyłącza; zależy jeszcze od targetu.

dla botów (zwłaszcza takich, które zawierają w sobie pare linijek curla)

Napisanie bota działającego na engine przeglądarki internetowej, to kwestia 5 minut roboty - w przypadku Windows - WSH + instancja Internet Explorera i niestety, Twoje "zabezpieczenia" można sobie rozbić o kant dolnej części pleców. I nie będziesz w stanie wykryć, czy to prawdziwy użytkownik, czy przeglądarka sterowana przez skrypt. Tylko sobie roboty narobisz, a użytkowników powkurzasz (zwłaszcza tym uzależnieniem od flasha; wiele osób stosuje white-listy, że np. tylko YouTube może odpalać flasha, reszta stron już nie).

Do pewnego momentu byłby też skueczny js, ajax i wszystko co jest parsowane po stronie przeglądarki.

Jw, to bez sensu - uzależniać wszystko od technologii client-side, bo i tak da się to ominąć.

[zordon]

wiadomo, że na dobrą sprawę nic nie jest bezpieczne. Ale tu raczej nie chodzi o to, żeby eliminowało 100% zagrożenia, a raczej jego większość.
Niedawno klient chciał "zabezpieczyć" pobieranie obrazków ze strony. Zrobiłem mu znaki wodne ale gość miał pretensje że mimo wszystko obrazek można pobrać a znak wodny wyciąć w photoshopie. Szczęśliwy był dopiero, gdy ... zablokowałem mu prawy przycisk myszy i nie miał dostępu do menu kontekstowego Okazało się, że jego konkurencja to żadni hakerzy - po prostu wchodzą na stronę i pobierają grafikę. Ten prosty sposób odciął mu od strony 90% "złodzei". Pozostałe 10% jak zechce i tak może wyciąć znak wodny - tylko czy będzie im się chciało?

Analogicznie do tej sytuacji: małym nakładem sił, stosując niektóre z podanych tu metod można stworzyć stronę, która nie będzie w 100% bezpieczna, ale pozbędzie się 90% zagrożeń, a pozostałych może zniechęcić. Napisanie prostego skryptu, który będzie buszował po stronie to nic trudnego, ale taki, który odczyta obrazki z cenami, obejdzie losowość strony, zczyta odwrotnie wpisany adres email itp itd już nie każdy napisze, a Ci którzy go napiszą, odpowiednio sobie zań policzą. I tutaj potencjalny napastnik zada sobie pytanie - czy mu się to opłaca - wszak podobnych sklepów które się nie zabezpieczają jest mnóstwo, a w naszym musi się dodatkowo liczyć z tym , że jego drogi, dedykowany pod nasz sklep bot w przypadku wprowadzania kolejnych zabezpieczeń będzie wymagał kolejnych rozwinięć, nakładów finansowych, czasowych.

Moja opinia to odpowiednio dobrać współczynnik potrzeb do ceny/czasu i zaimplementować wystarczające zabezpieczenia do naszych potrzeb, najmniejszym możliwym nakładem

Ten post edytował zordon 14.07.2010, 12:39:41

[Fifi209]

Okazało się, że jego konkurencja to żadni hakerzy - po prostu wchodzą na stronę i pobierają grafikę. Ten prosty sposób odciął mu od strony 90% "złodzei". Pozostałe 10% jak zechce i tak może wyciąć znak wodny - tylko czy będzie im się chciało?

Ta bajka nie może być prawdą, po pierwsze jak sprawdzić czy ktoś nie pobiera obrazków skoro robił to ręcznie? Wystarczy wyłączyć javascript lub "zapisz stronę jako" i pobierze z obrazkami, nawet wygodniejszy sposób bo wszystkie ściągamy od razu.

[darko]

Dla użytkowników też. Sporo po prostu tę wtyczkę wyłącza; zależy jeszcze od targetu.

Można sprawdzić czy użytkownik ma zainstalowanego flasha, ale - niestety - nie można sprawdzić czy ma włączoną jego obsługę i tutaj moja koncepcja upada.

[zordon]

Ta bajka nie może być prawdą, po pierwsze jak sprawdzić czy ktoś nie pobiera obrazków skoro robił to ręcznie? Wystarczy wyłączyć javascript lub "zapisz stronę jako" i pobierze z obrazkami, nawet wygodniejszy sposób bo wszystkie ściągamy od razu.

nie zrozumiałeś. Ja nie mówię, że to było bezpieczne. Chodzi o to, że większość "konkurencji" mojego klienta nie miała pojęcia, że można wyłączyć javascript, czyli innymi słowy "obejść" to wielce skomplikowane zabezpieczenie
W tym wypadku taka mała, błyskawiczna korekta skryptu dała mi poziom zabezpieczenia, którego on oczekiwał i dla niego było skuteczniejsze niż znak wodny!
W przypadku sklepu zabezpieczenia są na innym poziomie ale jak się dokładnie przeczyta mój post (i go zrozumie) to można zauważyć ANALOGIĘ, o której wspominałem