Browserele pornite de Selenium pot diferi prin porturile de depanare, proprietățile pe care pagina le poate citi și modul de pornire. Unele setări pot fi configurate în mod rezonabil, în timp ce încercarea de a ascunde automatizarea însăși este fragilă, inutilă și adesea ineficientă.
Când rulezi automatizări cu Selenium, se poate întâmpla ca logica scriptului să fie corectă și totuși să nu obții rezultatul dorit. Prima reacție este adesea să modifici unul sau doi parametri, dar ceea ce face mediul vizibil ca fiind diferit nu este, de regulă, un singur comutator. Mai des este vorba despre o combinație de diferențe pe mai multe niveluri. Separarea acestor niveluri ajută la înțelegerea lucrurilor care merită configurate și a celor care probabil nu vor ajuta.
Porturi de depanare și artefacte de runtime
Modul în care Selenium controlează browserul lasă două tipuri de urme. În primul rând, browserul poate deschide la pornire un port de depanare prin care software extern poate prelua controlul paginii. În al doilea rând, în mediul de runtime pot apărea elemente suplimentare, precum variabile globale cu prefixul cdc_ injectate de driver, obiecte suplimentare ale driverului în window și părți modificate ale unor prototipuri de obiecte.
Aceste elemente nu provin din pagina web, ci din driverul însuși. Dacă browserul este pornit în modul standard, ele sunt prezente indiferent cât de bine este scris scriptul.
Proprietăți pe care pagina le poate citi
O altă categorie de urme nu se află în driver, ci în mediul JavaScript pe care pagina îl poate citi. Cel mai des menționat exemplu este navigator.webdriver.
Această proprietate poate avea trei valori. true înseamnă că browserul este controlat de un instrument de automatizare, false înseamnă că nu este controlat, iar undefined înseamnă că informația nu este disponibilă, de obicei pentru că browserul nu expune proprietatea sau aceasta a fost modificată. În navigarea umană normală, valoarea este false sau undefined, în timp ce Selenium pornește implicit cu true.
În jurul ei există un set mai larg de parametri: User-Agent, sistemul de operare și versiunea browserului, rezoluția ecranului, fusul orar, limba, Canvas, WebGL, AudioContext, lista de fonturi, modelul GPU și numărul de nuclee CPU. Împreună formează ceea ce se numește în mod obișnuit amprenta browserului. Utilizatorii reali au în mod natural amprente diverse deoarece sistemele, software-ul și obiceiurile lor diferă. În schimb, browserele rulate cu configurații implicite de automatizare pot produce combinații foarte asemănătoare, ceea ce le face mai ușor de încadrat în tipare cunoscute.
Diferențe provocate de modul de pornire și timpul de randare
A treia categorie nu ține de o singură proprietate, ci de diferențele generale produse de modul în care browserul este pornit și randat.
Pornirea cu indicatori de automatizare, rularea în modul headless, nepotrivirea dintre dimensiunea ferestrei și parametrii ecranului, combinațiile nefirești dintre randarea fonturilor și driverul grafic sau distribuția prea uniformă a timpului dintre încărcare și interactivitate nu reprezintă dovezi luate separat. Împreună însă pot crea un mediu care seamănă puțin cu unul folosit de o persoană reală.
Headless este un exemplu tipic. Modul headless din versiunile noi de Chrome este mult mai apropiat de un browser obișnuit decât în urmă cu câțiva ani, dar poate totuși să expună mai ușor caracteristici de automatizare decât modul normal, mai ales pe site-uri cu controale stricte de risc.
Ce poate fi configurat în mod rezonabil
Fusul orar, limba, rezoluția ecranului și lista de fonturi nu sunt specifice automatizării. Dispozitivele reale diferă în mod natural. Ceea ce contează este coerența internă: fusul orar trebuie să corespundă regiunii ieșirii de rețea, limba regiunii de utilizare obișnuite, iar rezoluția nu trebuie să contrazică profilul hardware.
Cu alte cuvinte, scopul nu este ca mediul să pară special, ci să fie logic în interior. Dacă un dispozitiv pare să acceseze din Germania, dar browserul raportează fusul orar de pe coasta de vest a SUA, sistemul folosește numai engleza, iar rezoluția arată ca una tipică pentru un ecran virtual, această combinație este deja suficient de neobișnuită.
De aceea, setările mediului sunt mai bine păstrate într-un suport persistent. Modificarea fusului orar astăzi și uitarea limbii mâine poate crea inconsistențe mai mari decât dacă nu ai schimba nimic.
Ce încearcă să ascundă automatizarea și de ce nu merită
O altă clasă de tehnici vizează direct urmele: eliminarea navigator.webdriver, ștergerea variabilelor injectate de driver, ascunderea obiectelor driverului sau împiedicarea în alte moduri a citirii stării de automatizare.
Problema este că aceste tehnici modifică suprafața, nu comportamentul de bază. Detectarea a depășit de mult verificarea unei singure proprietăți; citirea atributelor este doar stratul cel mai superficial. O actualizare a driverului, o schimbare a ordinii de execuție a scriptului de detectare sau un detector care ocolește JavaScript și analizează direct rezultatele de randare de nivel jos și combinațiile de caracteristici ale dispozitivului poate face inutile modificările anterioare. Costul de întreținere rămâne semnificativ, iar beneficiul continuă să scadă.
Mai practic, astfel de acțiuni se încadrează adesea exact în zona pe care termenii de utilizare ai platformelor o descriu drept ocolirea măsurilor tehnice de protecție. Un script scris curat nu schimbă natura acțiunii doar pentru că au fost modificate câteva proprietăți.
Stratul de rețea nu poate fi rezolvat din script
Chiar dacă mediul browserului pare coerent, stratul de rețea poate identifica în continuare sesiunea. Poate lua în calcul dacă IP-ul aparține unui centru de date, unui server cloud sau unei rețele proxy; reputația istorică și ASN-ul intervalului IP; geolocalizarea; densitatea cererilor de la același IP; și dacă acel IP accesează mai multe conturi sau pagini într-un interval scurt. Cookies, Sessions și starea de autentificare din cereri pot fi, de asemenea, corelate.
Aceste probleme nu pot fi rezolvate în script. Ele trebuie gestionate la nivelul mediului: ieșire separată pentru fiecare sarcină, potrivirea dintre regiunea ieșirii și regiunea mediului și un ritm controlabil al cererilor. Pentru izolarea mai multor sarcini, capabilități precum PurpleMark funcționează de obicei la acest nivel, oferind fiecărei sarcini un mediu de browser și o ieșire de rețea independente, cu parametri geografici consecvenți.
Ordinea practică de diagnostic când accesul este blocat
O ordine rezonabilă este: mai întâi verifici stratul de rețea pentru tipul IP, stabilitate și coerență geografică; apoi verifici dacă mediul este coerent intern în privința fusului orar, limbii, rezoluției și fonturilor; după aceea analizezi ritmul comportamentului, de exemplu dacă așteptările au mereu valori fixe sau introducerea datelor se termină instantaneu; iar la final verifici proprietățile de automatizare la nivelul driverului.
Motivul este simplu: artefactele driverului nu mai sunt principalul punct de interes al detectării. Plasarea lor la începutul diagnosticului înseamnă de obicei timp pierdut.
Limite
Măsurile tehnice pot reduce probabilitatea de identificare, dar există limite care nu trebuie depășite: respectă regulile robots și termenii de utilizare ai site-ului țintă, nu colecta informații personale, nu ocoli măsurile tehnice de protecție, controlează frecvența cererilor și nu afecta funcționarea normală a serviciului.
