În această secțiune, vom descrie câteva principii generale pentru prevenirea vulnerabilităților de scriptare între site-uri și modalități de utilizare a diferitelor tehnologii comune pentru protejarea împotriva atacurilor XSS.

preveniți

Prevenirea scripturilor între site-uri poate fi realizată în general prin două straturi de apărare:

Puteți utiliza Burp Scanner pentru a vă scana site-urile web pentru a găsi numeroase vulnerabilități de securitate, inclusiv XSS. Logica de scanare de ultimă oră a lui Burp reproduce acțiunile unui atacator calificat și este capabilă să obțină o acoperire corespunzătoare ridicată a vulnerabilităților XSS. Puteți utiliza Burp Scanner pentru a vă asigura că apărarea împotriva atacurilor XSS funcționează eficient.

Codificați datele la ieșire

Codificarea ar trebui aplicată direct înainte ca datele controlabile de utilizator să fie scrise într-o pagină, deoarece contextul în care scrieți determină ce fel de codificare trebuie să utilizați. De exemplu, valorile dintr-un șir JavaScript necesită un tip diferit de evadare a celor dintr-un context HTML.

În context HTML, ar trebui să convertiți valorile care nu figurează pe lista albă în entități HTML:

  • convertește în:
  • > convertește în:>

Într-un context de șir JavaScript, valorile non-alfanumerice ar trebui să fie evadate Unicode:

  • convertește în: \ u003c
  • > convertește în: \ u003e

Uneori va trebui să aplicați mai multe straturi de codificare, în ordinea corectă. De exemplu, pentru a încorpora în siguranță intrările utilizatorului într-un handler de evenimente, trebuie să vă ocupați atât de contextul JavaScript, cât și de contextul HTML. Deci, trebuie mai întâi să scape de Unicode de intrare și apoi să-l codezi HTML:

Validați datele introduse la sosire

Codificarea este probabil cea mai importantă linie de apărare XSS, dar nu este suficientă pentru a preveni vulnerabilitățile XSS în fiecare context. De asemenea, ar trebui să validați intrarea cât mai strict posibil în momentul în care este primită de la un utilizator.

Exemple de validare a intrărilor includ:

  • Dacă un utilizator trimite o adresă URL care va fi returnată în răspunsuri, confirmând că începe cu un protocol sigur, cum ar fi HTTP și HTTPS. În caz contrar, cineva ar putea exploata site-ul dvs. cu un protocol dăunător, cum ar fi javascript sau date .
  • Dacă un utilizator furnizează o valoare care este de așteptat să fie numerică, validând că valoarea conține de fapt un număr întreg.
  • Validarea acelei intrări conține doar un set de caractere așteptat.

Validarea intrărilor ar trebui să funcționeze în mod ideal blocând intrarea nevalidă. O abordare alternativă, a încercării de a curăța intrările nevalide pentru ao face valabilă, este mai predispusă la erori și ar trebui evitată ori de câte ori este posibil.

Listă albă vs listă neagră

Validarea intrărilor ar trebui să utilizeze, în general, liste albe mai degrabă decât liste negre. De exemplu, în loc să încercați să faceți o listă cu toate protocoalele dăunătoare (javascript, date etc.), pur și simplu faceți o listă de protocoale sigure (HTTP, HTTPS) și interziceți orice nu este pe listă. Acest lucru vă va asigura că apărarea dvs. nu se va sparge atunci când apar noi protocoale dăunătoare și o va face mai puțin susceptibilă la atacuri care încearcă să ofere valori nevalide pentru a se sustrage unei liste negre.

Permite HTML „sigur”

Permiterea utilizatorilor să posteze marcaje HTML ar trebui evitată ori de câte ori este posibil, dar uneori este o cerință de afaceri. De exemplu, un site de blog ar putea permite să fie postate comentarii care conțin unele limitări HTML.

Abordarea clasică este de a încerca să filtrați etichetele potențial dăunătoare și JavaScript. Puteți încerca să implementați acest lucru folosind o listă albă de etichete și atribute sigure, dar datorită discrepanțelor în motoarele de analiză a browserului și a ciudățenilor precum mutația XSS, această abordare este extrem de dificilă de implementat în siguranță.

Cea mai puțin proastă opțiune este utilizarea unei biblioteci JavaScript care efectuează filtrarea și codificarea în browserul utilizatorului, cum ar fi DOMPurify. Alte biblioteci permit utilizatorilor să furnizeze conținut în format de reducere și să convertească reducerea în HTML. Din păcate, toate aceste biblioteci au din când în când vulnerabilități XSS, deci aceasta nu este o soluție perfectă. Dacă utilizați una, ar trebui să monitorizați cu atenție actualizările de securitate.

În plus față de JavaScript, alte conținuturi precum CSS și chiar HTML obișnuit pot fi dăunătoare în anumite situații.

Cum să preveniți XSS folosind un motor de șabloane

Multe site-uri web moderne folosesc motoare de șabloane pe partea de server, cum ar fi Twig și Freemarker, pentru a încorpora conținut dinamic în HTML. Acestea definesc de obicei propriul sistem de evadare. De exemplu, în Twig, puteți utiliza filtrul e (), cu un argument care definește contextul:

Unele alte motoare de șabloane, cum ar fi Jinja și React, scapă în mod implicit de conținutul dinamic, ceea ce previne efectiv majoritatea aparițiilor XSS.

Vă recomandăm să examinați îndeaproape caracteristicile de evacuare atunci când evaluați dacă utilizați un anumit motor de șablon sau cadru.

Dacă concatenați direct introducerea utilizatorului în șiruri de șabloane, veți fi vulnerabil la injecția șablonului de pe server, care este adesea mai gravă decât XSS.

Cum se previne XSS în PHP

În PHP există o funcție încorporată pentru a codifica entități numite htmlentities. Ar trebui să apelați această funcție pentru a scăpa de intrare atunci când vă aflați într-un context HTML. Funcția trebuie apelată cu trei argumente:

  • Șirul dvs. de intrare.
  • ENT_QUOTES, care este un steag care specifică toate ghilimelele ar trebui codat.
  • Setul de caractere, care în majoritatea cazurilor ar trebui să fie UTF-8.

Când vă aflați într-un șir JavaScript, trebuie să introduceți Unicode-escape, așa cum s-a descris deja. Din păcate, PHP nu oferă un API pentru Unicode-evadarea unui șir. Iată câteva coduri pentru a face acest lucru în PHP:

funcția jsEscape ($ str) $ output = ";
$ str = str_split ($ str);
pentru ($ i = 0; $ i ":
$ output. = sprintf ("\\ u% 04x", $ chrNum);
pauză;
Mod implicit:
$ output. = $ str [$ i];
pauză;
>
>
returnează $ ieșire;
>
?>

Iată cum să utilizați funcția jsEscape în PHP:

Alternativ, puteți utiliza un motor de șabloane.

Cum să preveniți partea de client XSS în JavaScript

Pentru a scăpa de introducerea utilizatorului într-un context HTML în JavaScript, aveți nevoie de propriul codificator HTML, deoarece JavaScript nu oferă un API pentru codificarea HTML. Iată câteva exemple de cod JavaScript care convertește un șir în entități HTML:

Apoi, veți utiliza această funcție după cum urmează:

Dacă intrarea dvs. se află într-un șir JavaScript, aveți nevoie de un codificator care să efectueze scăderea Unicode. Iată un exemplu de codificator Unicode:

function jsEscape (str) return String (str) .replace// [^ \ w.]/gi, function (c) return '\\ u' + ('0000' + c.charCodeAt (0) .toString (16) ) felie (-4);
>);

Apoi, veți utiliza această funcție după cum urmează:

Cum să preveniți XSS în jQuery

Cea mai obișnuită formă de XSS în jQuery este atunci când trimiți intrarea utilizatorului către un selector jQuery. Dezvoltatorii web ar folosi adesea location.hash și l-ar transmite selectorului, ceea ce ar cauza XSS, deoarece jQuery ar reda codul HTML. jQuery a recunoscut această problemă și a corelat logica selectorului pentru a verifica dacă intrarea începe cu un hash. Acum jQuery va reda HTML numai dacă primul caracter este un. Dacă treceți date de încredere selectorului jQuery, asigurați-vă că scăpați corect de valoarea utilizând funcția jsEscape de mai sus.

Atenuarea XSS utilizând politica de securitate a conținutului (CSP)

Politica de securitate a conținutului (CSP) este ultima linie de apărare împotriva scripturilor între site-uri. Dacă prevenirea XSS eșuează, puteți utiliza CSP pentru a atenua XSS restricționând ceea ce poate face un atacator.

CSP vă permite să controlați diverse lucruri, cum ar fi dacă scripturile externe pot fi încărcate și dacă scripturile inline vor fi executate. Pentru a implementa CSP, trebuie să includeți un antet de răspuns HTTP numit Content-Security-Policy, cu o valoare care să conțină politica dvs.

Un exemplu de CSP este următorul:

default-src 'auto'; script-src „sine”; object-src 'none'; frame-src 'none'; base-uri 'none';

Această politică specifică faptul că resursele precum imagini și scripturi pot fi încărcate numai din aceeași origine ca și pagina principală. Deci, chiar dacă un atacator poate injecta cu succes o sarcină utilă XSS, poate încărca resurse numai din originea curentă. Acest lucru reduce foarte mult șansa ca un atacator să exploateze vulnerabilitatea XSS.

Dacă aveți nevoie de încărcarea resurselor externe, asigurați-vă că permiteți scripturilor care nu ajută un atacator să vă exploateze site-ul. De exemplu, dacă lista albă a anumitor domenii, atunci un atacator poate încărca orice script din acele domenii. Unde este posibil, încercați să găzduiți resurse pe propriul domeniu.

Dacă acest lucru nu este posibil, puteți utiliza o politică bazată pe hash sau noncece pentru a permite scripturi pe diferite domenii. Un nonce este un șir aleatoriu care este adăugat ca un atribut al unui script sau resursă, care va fi executat numai dacă șirul aleatoriu se potrivește cu cel generat de server. Un atacator nu poate ghici șirul aleatoriu și, prin urmare, nu poate invoca un script sau o resursă cu un nonce valid și astfel resursa nu va fi executată.

Citeste mai mult

Doriți să vă urmăriți progresul și să aveți o experiență de învățare mai personalizată? (Este gratis!)