Share
Datorită HTML5, din ce în ce mai mult o logică a aplicațiilor este transferată de la partea de server la cea a clientului. Acest lucru presupune ca dezvoltatorii din front-end să se concentreze mai mult pe securitate. În acest articol vă voi arăta cum să faceți aplicațiile mai sigure. Mă voi concentra asupra unor tehnici pe care probabil că nu le-ați auzit, în loc să vă spun doar că trebuie să scăpați de datele HTML introduse de utilizatori.
Bineînțeles că nu vreau să vă difuzați conținutul cu FTP sau TCP simplu. Ceea ce vreau să spun este că dacă doriți ca utilizatorii dvs. să fie în siguranță atunci când folosesc site-ul dvs., trebuie să utilizați SSL (HTTPS). Și nu numai pentru site-uri de conectare, sau informații valoroase. Pentru tot conținutul. Altfel, atunci când cineva vă accesează aplicația dintr-o rețea publică, ceea ce văd poate fi malformat de un anumit hacker din cadrul acestei rețele. Aceasta se numește atac principal în mijloc:
Când utilizați SSL, toate datele sunt criptate înainte de a fi trimise, astfel încât, chiar dacă atacatorul îl primește, nu va fi capabil să-l modifice sau să-l captureze. Acesta este de departe cel mai important pas în securizarea aplicației dvs..
Acest antet HTTP poate fi util dacă doriți să difuzați conținutul utilizând numai SSL. Când este emis de server (sau a tag, dar care va permite ca cel puțin o cerere să fie HTTP), nu va apărea un trafic nesigur din browser către serverul dvs. Se folosește astfel:
Strict-Transport-Securitate: max-vârsta = 3600; includeSubDomains
includeSubDomains parte este opțională, vă permite să declarați că doriți, de asemenea, ca toate subdomeniile să fie accesate utilizând HTTPS. max-age opțiunea stabilește cât timp (în secunde) paginile trebuie să fie difuzate utilizând SSL. Din păcate, numai Firefox, Chrome și Opera suportă Strict Transport Security.
Un alt mod de îmbunătățire a securității atât pe HTTP cât și pe HTTPS sunt cele două atribute cookie: Sigur și HttpOnly. Primul permite ca un modul cookie să fie trimis numai pe conexiunea SLL. Cel de-al doilea poate suna ca exact opusul, dar nu este. Spune browser-ului că cookie-ul poate fi accesat numai folosind protocolul HTTP (S), deci nu poate fi furat utilizând, de exemplu, JavaScript document.cookie.
Politica de securitate a conținutului vă permite să definiți originea tuturor scripturilor, imaginilor etc. pe site-ul dvs..
Dacă credeți că filtrul dvs. XSS va opri toate atacurile XSS posibile, verificați câte moduri există pentru a efectua aceste atacuri și a vă gândi din nou. Desigur, securizarea aplicației pentru a opri toate acestea poate fi o problemă și o poate încetini, dar există o soluție.
Se numește Politica de securitate a conținutului. Acesta vă permite să definiți originea tuturor script-urilor, imaginilor etc. pe site-ul dvs. De asemenea, blochează toate scripturile și stilurile inline, deci chiar dacă cineva poate injecta un tag script într-un comentariu sau post, codul nu va fi executat. CSP este un antet HTTP (care poate fi de asemenea setat folosind HTML tag), care arată astfel:
Conținut-Politica de securitate: politică
Unde politică este un set de directive CSP. Iată opțiunile posibile:
Dacă nu este setată o directivă, browserul presupune că toate originile sunt permise. Acest lucru poate fi modificat prin setarea default-src opțiune. Ceea ce ați stabilit acolo va fi aplicat tuturor directivelor dezactivate. Este deasemenea o Sandbox opțiune, care face încărcarea paginii web ca o iframe cu Sandbox atribut. O exemplu de utilizare a antetului CSP ar arata astfel:
Conținut-Politica de securitate: implicit-src: "de sine"; script-src: https://apis.google.com;
Permite ca toate bunurile să fie încărcate numai de la originea aplicației ( 'de sine' atribut) și, de asemenea, vă permite să încărcați scripturi de pe serverul API Google. Există o mulțime de flexibilitate atunci când se definește CSP, iar atunci când este folosit în mod corespunzător, aceasta va îmbunătăți considerabil securitatea paginii dvs. Web.
Lucrul pe care trebuie să-l rețineți atunci când utilizați CSP este că, în mod implicit, tot JavaScript-ul inline nu va fi executat. Aceasta include, de asemenea:
Accentsconagua
JavaScript URL-uri: cum ar fi Acest lucru se datorează faptului că browserul nu poate distinge codul dvs. inline de codul inline al hacker-ului. Va trebui să le înlocuiți prin adăugarea de ascultători de evenimente addEventListener sau echivalentul unui cadru. Acesta nu este un lucru rău în cele din urmă, deoarece te obligă să separi logica aplicației de reprezentarea grafică pe care ar trebui să o faci oricum. De asemenea, CSP (în mod implicit) blochează toate eval ()-cod ish, inclusiv șiruri de caractere în setInterval/setTimeout și codul de genul Funcție nouă ("return false").
CSP este disponibil în majoritatea browserelor moderne. Firefox, Chrome și Opera (de asemenea, mobile) utilizează standardul Conținutul-politicii de securitate, antet. Safari (iOS) și Chrome pentru Android utilizează X-WebKit-CSP antet. IE10 (cu sprijin limitat doar la Sandbox directivă) X-Content-Securitate-Politica. Prin urmare, datorită aplicației Internet Explorer, nu puteți utiliza doar CSP (cu excepția cazului în care veți folosi ceva similar cu Google Chrome Frame), însă puteți să-l utilizați în continuare pentru a îmbunătăți securitatea browserelor reale și pentru a vă pregăti aplicația pentru viitor.
JSONP este în prezent cea mai utilizată tehnică pentru a obține resurse de la alte servere, în pofida politicii de același tip. De obicei, creați funcția de retur în codul dvs. și trimiteți numele acelei funcții la adresa URL de la care doriți să obțineți datele, cum ar fi:
funcția parseData (date) ...
Dar făcând acest lucru, creați un mare risc de securitate. Dacă serverul de la care obțineți date este compromis, un hacker poate adăuga codul său rău intenționat și, de exemplu, poate fura datele private ale utilizatorului, deoarece, de fapt, primiți JavaScript folosind această solicitare - și browserul va rula tot codul ca în cazul unui fișier de script normal.
Soluția de aici este Cross Source Resource Sharing. Acesta permite furnizorului dvs. de date să adauge un antet special în răspunsuri, astfel încât să puteți utiliza XHR pentru a prelua aceste date, apoi să le analizați și să le verificați. Acest lucru elimină riscul de a fi executat cod rău intenționat pe site-ul dvs..
Implementarea cere furnizorului să adauge doar următoarele antete speciale în răspunsuri:
Access-Control-Allow-Origine: origini admise
Acestea pot fi doar câteva originale permise separate cu spații sau cu un caracter cu machetă: * pentru a permite fiecărei origini să solicite datele.
Toate versiunile actuale ale browserelor moderne suportă CORS, cu excepția programului Opera Mini.
Desigur, problema mai mare aici este că furnizorii de servicii ar trebui să adauge sprijinul CORS, deci nu este complet dependent de dezvoltator.
Un iframe cu
Sandboxatributul nu va putea să navigheze în fereastră, să execute scripturi, să blocheze pointerul, să afișeze ferestre pop-up sau să trimită formulare.
Dacă utilizați iframe pentru a încărca conținut de pe site-uri externe, poate doriți să le securiziți. Acest lucru se poate face folosind Sandbox iframe atribut. O iframe cu un astfel de atribut gol (dar prezent) nu va avea permisiunea de a naviga în fereastră, de a executa scripturi, de a bloca pointerul, de a afișa ferestrele pop-up sau de a trimite formulare. Cadrul va avea, de asemenea, o origine unică, deci nu se poate folosi localStorage sau orice altceva legat de politica de același tip. Puteți, desigur, să permiteți câtorva dintre ei, dacă doriți, adăugând una sau mai multe dintre aceste valori în atributul:
Sandbox atributul iframe este acceptat în toate browserele moderne, cu excepția programului Opera Mini.
Deci asta este. Sper că ați învățat câteva tehnici noi pe care le puteți utiliza în proiectele viitoare pentru a vă proteja aplicațiile. Mulțumită HTML5, acum putem face lucruri uimitoare cu site-urile noastre, dar trebuie să ne gândim la securitate de la prima linie de cod dacă vrem să fie rezistenți împotriva atacurilor.
