Jest taka strona do AI face search - https://www.facesearchai.com/dashboard/search
I widzę w networkach, że search idzie na ten sam adres, na którym jest ta podstrona tj. https://www.facesearchai.com/dashboard/search . To jest tak zrobione, że na GET zwraca html, a przy POST działa jak endpoint? W postmanie na POST zwraca mi cały html strony. To ma działać jako zabezpieczenie, czy co? To jest sposób na ukrycie endpointa?
każdy URL może obsługiwać różne metody HTML HTTP. Czasem jest jeszcze gorzej i masz tylko fasadę i wszystko leci po gRPC ;)
@roark.dev wiem, ale POST z odpowiednim body puszczony przez postmana zwraca 200 i HTML strony, więc jest inny response niż w przeglądarce. I chodzi mi o tę różnicę. To jest rodzaj zabezpieczenia? Co zrobić, żeby otrzymać respons jak w przeglądarce?
A jeśli się nie da, to jak zrobić coś takiego analogicznie? Chciałbym u siebie ukryć endpointy, bo captcha cloudflare ma gotowe solvery na githubie i kradną wyniki.
To podaj jaki według ciebie idzie request w przeglądarce, jaki w postmanie, oraz co otrzymujesz tu i tu... szklanej kuli nie mamy.... poza tym są jeszcze inne rzeczy niż body - np. headery.
Za tą usługą raczej jest konkretny program ‘servera’. W żądaniu wyszukania twarzy otrzymuje nagłówek “Next-Action”; jego odpowiednia zawartość jest wymagana, by uzyskać właściwą odpowiedź. On przypuszczalnie wiąże żądanie z tym, co użytkownik przegląda na stronie. Nie sądzę, że istotne w tym przypadku jest ukrycie adresu.
Server może dowolnie interpretować zapytanie i na tej podstawie zwracać różne wiki. Jak to działa: nie wiadomo.
Pewnie w postmanie nie masz wszystkich potrzebnych headerów i serwer obsługujący stronę wybrał inną logikę
To jest sposób na ukrycie endpointa?
Bardziej skłaniałbym się ku niedbalstwu lub działa to działa
A to nie jest coś na zasadzie reverse proxy? Widziałem coś takiego w aplikacji Angularowej
Niestety już zmienili stronę, więc nie jestem w stanie wykazać jaka jest różnica responsa w przeglądarce i postmanie XD
Pomińmy to w takim razie, skoro nie znam niewiadomych i skupmy się na tytule tematu.
Jest endpoint, który przyjmuje w body:
image: base64 string
turnstileToken: string
jest do niego strzelane z frontu. Okazało się, że captcha cloudflare jest beznadziejna i są na GH biblioteki do jej rozwiązywania poprzez headless browser, więc niepowołane osoby kradną wyniki z tego endpointa. Captcha od googla ma ceny jakieś z kosmosu. Jak byście zabezpieczyli taki endpoint?
Co to znaczy niepowołane? Chyba, jest tam jakieś logowanie i headery z tokenem? Można dać np. ograniczoną ilość requestó per user, lub nawet per token i konieczność odswieżenia tokeny, oraz mozliwość ograniczonej ilości odswieżenia tokenu. No ale to zależy jaki jest regulamin, bo może jest legalnym tylerazy się pytać api? Można wykrywać też anomalia po ruchu od danego usera i go banować lub obsługiwać tylko co nte żądanie.
@roark.dev Darmowa wersja pozwala niezalogowanym użytkownikom na wykonywanie pewnej ilości zapytań razem z ustawionym limiterem, który co jakiś czas wyświetla dodatkową captchę. Przez to, że są niezalogowani, to jest to śledzone po IP. No, ale takie coś obchodzą dzięki proxy. Z kolei wymuszenie konta może obniżyć sprzedaż, dlatego tak to wygląda obecnie. Ja bym wymusił posiadanie konta, ale to akurat nie moja decyzja.
roark.dev napisał(a):
każdy URL może obsługiwać różne metody HTML.
nie ma takiego czegoś jak "metody HTML", chyba że się zasiedziałem z tym IT i muszę odświeżyć wiedzę
Jak nie masz identyfikacji usera to nic nie pomoże poza captchą. Nawet wprowadzenie darmowego tokena nic nie da, bo token można generować co chwila, jeśli mają ciągle inne IP.
Tzn. można próbować wykrywac, że to ten sam bot, dodawac jakiś JS do komunikacji po gRPC i generowanie finerprintów z user agenta, ale też np. wersji libek itd. itd. ale to nie będzie zabezpieczenie, a bardziej utrudnienie pracy złodzejom i można liczyć jedynie, że się zniechęcą. Można też generować dynamicznie endpointy zwracane w get w endpoincie, lub po grpc/signalR - ale to wszystkie nie jest uszczelnienie na 100% a nadzieja, że haker albo nie będzie miał dostatecznej wiedzy albo się zniechęci.
Ale mam captchę od Cloudflare - https://www.cloudflare.com/pl-pl/application-services/products/turnstile/
Okazało się, że jest już dawno rozkminiona i używając tego można ją obejść nie znając secret keya - https://github.com/Theyka/Turnstile-Solver
A captcha z googla ma teraz takie ceny, że wyszłoby przy tym ruchu z 20 tysięcy dolarów miesięcznie, czyli dużą część zysku, więc to się nie kalkuluje w ogóle XD
Na zwykłych użytkowników może wystarczy, ale tu chodzi o takich, którzy próbują wykorzystać to biznesowo. Więc captchę mam i chodzi mi o to, jakie kolejne kroki podjąć.
Lepszą captche. Nie wymagać kont i wykluczyć boty to jak mieć ciastko i zjeść ciastko. Ja bym wrzucił logowanie po FB/Google/itd. wrzucił to na 10% userów co włączają stronę. Zbadał, o ile spadnie ilość zainteresowania w tych 10% - tzn. czy procent ludzi z testowego setupu, którzy kupują produkt jest dużo mniejszy niż w pozostałych 90% anonimów no i policzył co się bardziej opłaca. Może włączenie logowania będzie tańsze niż captcha, a zminimalizuje koszty chmury "marnowaną" na ludzi kradnących darmowe requesty. Szklanej kuli tu nie ma - trzeba zbadać i odpalić Excela.
Dobra, to nie chcesz nic ukrywać, tylko zabezpieczyć przed botami?
Bo z treści wynika jakbyś nie wiedział co się dzieje w tej aplikacji i próbował sam z niej skorzystać w sposób zautomatyzowany.
Jeśli nie masz żadnego mechanizmu logowania itp, a nie chcesz płacić za captcha od innych to stwórz nawet prostą ale swoją, nawet w formie 200 pytań i odpowiedzi zahardkodowanych.
Pytanie jaki biznesowo procent botów/użytkowników chcesz wyciąć.
@1programmer myślałeś o normalnym cloudflare tj. takie co przepuszcza cały ruch? Jakieś pół roku temu rozkminiałem temat (punktem startowym było GCP i reCaptcha z Googla) i generalnie konkurencja nie wygląda znacząco lepiej xd
Tak czy owak wymóg rejestracji będzie pomocny zarówno bez captchy jak z nią
@slsy no to ogólnie jest zarządzane wszystko przez cloudflare.
@jurek1980 w której aplikacji? To co dałem linka na początku, to złodzieje i tam faktycznie nie wiem, co się dzieje.
1programmer napisał(a):
I widzę w networkach, że search idzie na ten sam adres, na którym jest ta podstrona tj.
https://www.facesearchai.com/dashboard/search. To jest tak zrobione, że na GET zwraca html, a przy POST działa jak endpoint? W postmanie na POST zwraca mi cały html strony. To ma działać jako zabezpieczenie, czy co? To jest sposób na ukrycie endpointa?
Na pewno to nie jest "ukrycie endpointa" - co by to miało niby dać? Po prostu nazwali tak sobie endpoint i tyle.
Na 99% obecnie oponenci używają jakiegoś playwrighta albo selenium i scrapują response. Są jakieś metody na taki konkretny case?
Nie możemy wprowadzić obowiązkowego logowania, bo nie mamy jeszcze mocno ugruntowanej pozycji i boimy się spadku ruchu, a co za tym idzie konwersji. W przyszłości tak, teraz nie,
Generujcie ramdomowy response i generujcie też js który ten response prasuje. Bez ręcznego zmieniania skryptu się nie obędą a jak będzie to inne przy każdym requescie to nie ogarną.
1programmer napisał(a):
Na 99% obecnie oponenci używają jakiegoś playwrighta albo selenium i scrapują response. Są jakieś metody na taki konkretny case?
Nie możemy wprowadzić obowiązkowego logowania, bo nie mamy jeszcze mocno ugruntowanej pozycji i boimy się spadku ruchu, a co za tym idzie konwersji. W przyszłości tak, teraz nie,
A co Wam przeszkadza że ktoś robi scrape? Podaj konkretny use-case w Twoim przypadku, bo rozwiązanie będzie zależało od tego co Ci przeszkadza w tym ze ludzie parsują response.
@Riddle Nie ludzie, tylko złodzieje z pakistanu, którzy tworzą bliźniaczą usługę poprzez ukradzione wyniki. Czyli zrobili sobie front i sprzedają na subskrypcji wyniki, które kradną, więc to chyba nie jest ok? XD
Złodzieje mieli wcześniej inne projekty i przez to dobrą pozycję w google. No to jeśli strona, która kradnie jest wyżej w wyszukiwarce od oryginalnej strony, to jest lipa.
Dostęp do API jest dodatkowo płatny.
Problemem nie są klienci indywidualni, tylko złodzieje, którzy próbują na tym zrobić biznes przy zerowych kosztach.
SEO niestety potrzebuje czasu. Chociaż na tym to się nie znam.
co Ci przeszkadza w tym ze ludzie parsują response
Kilka opcji:
Uhuhu faktycznie słabo, bo wasz regulamin w którym napisaliście że nie wolno kraść i skrapować pakoli pewnie g... obchodzi? Ale chamówa.
Mi się wydaje że jak już was wycelowali to albo będziecie mieć lepsze seo i reklamy albo lepszych prawników albo kaplica.
Przecież nawet najwięksi tego kraju nie dali rady skraperom, patrz allegro i tradewatch, przykładów pewnie można dawać w opór.
1programmer napisał(a):
@Riddle Nie ludzie, tylko złodzieje z pakistanu, którzy tworzą bliźniaczą usługę poprzez ukradzione wyniki. Czyli zrobili sobie front i sprzedają na subskrypcji wyniki, które kradną, więc to chyba nie jest ok? XD
Złodzieje mieli wcześniej inne projekty i przez to dobrą pozycję w google. No to jeśli strona, która kradnie jest wyżej wyszukiwarce od oryginalnej strony, to jest lipa.
https://brightdata.com/blog/web-data/anti-scraping-techniques
https://www.zenrows.com/blog/anti-scraping
https://medium.com/@datajournal/popular-anti-scraping-techniques-765473ea0451
https://docs.apify.com/academy/anti-scraping/techniques
roark.dev napisał(a):
Generujcie ramdomowy response i generujcie też js który ten response prasuje. Bez ręcznego zmieniania skryptu się nie obędą a jak będzie to inne przy każdym requescie to nie ogarną.
Wyjaśnisz bardziej, jak to ma działać i jaki da efekt, bo nie czaję?
Pomyślałem, żeby zwracać wynik (zdjęcia) i z jakimś przesunięciem bitowym, żeby przychodziły scorruptowane z endpointa i odwracać to na froncie za pomocą algorytmu zaciemnionego obfuscatorem. Niby można to odwrócić, ale zrobiłem tak z tokenem turnstile tj. captchy cloudflare i jedną metodę im zblokowałem. Tylko jeśli renderują całą stronę to lipa, a robią to teraz prawie na pewno, bo czeka się dużo dłużej na wyniki.
Albo może da się użyć steganografi do takiego czegoś? Kiedyś widziałem, że jest taka pseudo emulowana konsola ala gameboy i gry tam były zakodowane w kanale alfa obrazków PNG. No i zastanawiam się, czy by może nie dało się kodować prawdziwych wyników w jakichś fake wynikach XD
Co myślicie, odklejka i strata czasu? Może lepiej skupić się na SEO i po prostu wyświetlać się wyżej w wyszukiwarce?
odwracać to na froncie za pomocą algorytmu zaciemnionego obfuscatorem
No ale skoro będzie to na froncie, to znaczy, że potencjalny złodziej ma do tego dostęp. OK, możesz zaciemnić kod - w czasach, gdy ludzie się tym zajmowali to było to mocne utrudnienie. Tylko teraz taki kod wrzucisz do AI/ML i jemu nie robi różnicy, czy masz function setCośTam (int Xcoords, bool showBlaBla) czy X(d:e){x4xazs;}, więc algorytm odszyfrowujący z frontu po chwili będzie jawny i działający na potrzeby Hindusów/Pakistańczyków (czy jak to się tam odmienia).
Czyli apka z pierwszego postu używa Twojego Endpointu "za darmo"?
IMHO żadne obfuskacje nie mają sensu.
Chcesz blokuj im IP.
Dla osób korzystających za darmo z Twojego rozwiązania dodaj do obrazka jawny IP z jakiego był request u Ciebie i info typu utworzono za pomocą strony: Twoja strona www.
Raz na dwa dni sprawdzisz z jakiego IP robią reqesty sam korzystając z ich strony, a każdy użytkownik ich rozwiązania ma na tacy podany właściwy adres Twojej strony.
Tylko to oczywiście też kwestia biznesowa.
@cerrato akurat zrobiłem tak 2 dni temu z tym tokenem captchy, testowałem na wszystkich najlepszych modelach pod programowanie i nie udało im się, więc to też nie tak 100%. Jak AI nie da rady i trzeba by nad tym siedzieć, to można by żonglować tym i w końcu pływakom z Gangesu może się odechce XD
No i tych złodziei to nie jest jeden, tylko było z 5 - 6, ale innym właśnie się odechciało w końcu albo rozkminiają to, co wcześniej zmieniłem. Nie byliśmy świadomi skali, a także niektórych dziur, nie tylko na froncie.
pentesterzy za friko, ni tylko dziekkowac im, mozesz np darmowa subskrypcje im dac