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 ?

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

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.

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...

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ć.

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

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ą?

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.

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

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ć.

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.

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?

@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.

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


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).


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

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

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.

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.

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

Jeśli rozmawiamy o skrypcie pisanym na zlecenie, to praktycznie nie ma szans na zabezpieczenie tego - praktycznie każdy sposób, który wymyślimy będzie można obejść w kilka chwil. W miarę skuteczne sposoby spowodują tylko utrudnienia dla użytkowników.

Reasumując - daj sobie z tym spokój - nie da się skutecznie zabezpieczyć treści, która jednocześnie ma być dostępna dla użytkowników.

Co może zrobić przeglądarka może zrobić też bot, tyle powiem.

- tym, że spamboty wykrywają określone skrypty (np. katalog stron oparty o WP czy Mini) i potrafią obsługiwać ich captche oraz formularze, raportować akcje itp. Standardowy bot w starciu z autorskim skryptem jest bezradny, najczęściej wypełnia formularz przypadkowymi znakami i nie przechodzi on walidacji, bot się sam nie nauczy (przynajmniej na razie), ktoś musi go nauczyć a dla jednego serwisu nikt się nie będzie w to bawił. Boty reklamuje się pod kątem aplikacji lub serwisów, które potrafią spamować. Jeśli stawiasz katalog stron na gotowym i popularnym silniku to inwazje botów masz jak w banku, jeśli to autorski skrypt - to masz problem tylko z dodającymi wpisy ręcznie (oczywiście skrypt musi być w miarę normalnie napisany).

Hmm, chyba było coś takiego, jak sieci neuronowe, nie?

Poza tym, pewne elementy interfejsu są pewnym niepisanym standardem, więc np. odwrócenie adresu mailowego jest pikusiem (wystarczy sprawdzić, czy jest kropka na właściwym miejscu, jeśli nie -> transformacje wg listy); myślisz, że te boty napiszą raz i nie rozwijają...? Dla mnie wydaje się śmieszne np. obfuskowanie maili przez JS/encje, bo spamerzy też czytają serwisy poświęcone "zabezpieczeniom"...

Musiałbyś sprawdzać np. domenę, a dlaczego?

comgmailjacek@gmail.com

ten adres można zapisać jako

com.gmail.jacek@gmail.com

http://www.google.com/search?client=opera&...-8&oe=utf-8 - 3 sekundy szukania...

Dla polskich wcale nie trudniej:
http://www.google.com/search?hl=pl&cli...q=&gs_rfai=

Naprawdę, szkoda czasu na implementację takich "zabezpieczeń"...