Consolidarea Securității Frontend: Content Security Policy și CORS

În peisajul digital interconectat de astăzi, securitatea frontend este primordială. Aplicațiile web sunt din ce în ce mai vizate de atacuri sofisticate, ceea ce face esențiale măsurile de securitate robuste. Două componente critice ale unei arhitecturi frontend sigure sunt Content Security Policy (CSP) și Cross-Origin Resource Sharing (CORS). Acest ghid complet oferă o privire aprofundată asupra acestor tehnologii, oferind exemple practice și informații acționabile pentru a vă ajuta să vă fortificați aplicațiile web împotriva amenințărilor moderne.

Ce este Content Security Policy (CSP)?

Content Security Policy (CSP) este un strat suplimentar de securitate care ajută la detectarea și atenuarea anumitor tipuri de atacuri, inclusiv Cross-Site Scripting (XSS) și atacurile de injectare de date. CSP este implementat prin trimiterea de către serverul web a unui antet de răspuns HTTP Content-Security-Policy către browser. Acest antet definește o listă albă de surse din care browserul are voie să încarce resurse. Prin restricționarea surselor de conținut pe care un browser le poate încărca, CSP face mult mai dificil pentru atacatori să injecteze cod malițios pe site-ul dvs.

Cum Funcționează CSP

CSP funcționează instruind browserul să încarce resurse (de exemplu, scripturi, foi de stil, imagini, fonturi) numai din surse aprobate. Aceste surse sunt specificate în antetul CSP folosind directive. Dacă un browser încearcă să încarce o resursă dintr-o sursă care nu este permisă în mod explicit, va bloca cererea și va raporta o încălcare.

Directive CSP: O Prezentare Generală

Directivele CSP controlează tipurile de resurse care pot fi încărcate din surse specifice. Iată o prezentare a unora dintre cele mai importante directive:

• default-src: Specifică sursa implicită pentru toate tipurile de conținut. Aceasta este o directivă de rezervă care se aplică atunci când alte directive mai specifice nu sunt prezente.
• script-src: Specifică sursele din care pot fi încărcate scripturile. Acest lucru este crucial pentru prevenirea atacurilor XSS.
• style-src: Specifică sursele din care pot fi încărcate foile de stil.
• img-src: Specifică sursele din care pot fi încărcate imaginile.
• font-src: Specifică sursele din care pot fi încărcate fonturile.
• media-src: Specifică sursele din care pot fi încărcate conținutul audio și video.
• object-src: Specifică sursele din care pot fi încărcate pluginurile (de exemplu, Flash). Aceasta este adesea setată la 'none' pentru a dezactiva complet pluginurile din cauza riscurilor lor de securitate inerente.
• frame-src: Specifică sursele din care pot fi încărcate cadrele (de exemplu, <iframe>).
• connect-src: Specifică URL-urile la care agentul utilizator se poate conecta folosind interfețe de script precum XMLHttpRequest, WebSocket și EventSource.
• base-uri: Specifică URL-urile care pot fi utilizate în elementul <base> al unui document.
• form-action: Specifică URL-urile către care pot fi trimise formularele.
• upgrade-insecure-requests: Instruiește agentul utilizator să actualizeze automat cererile nesecurizate (HTTP) la cereri securizate (HTTPS).
• report-uri: Specifică un URL unde browserul ar trebui să trimită rapoarte despre încălcările CSP. Această directivă este depreciată în favoarea `report-to`.
• report-to: Specifică un nume de grup de raportare definit în antetul `Report-To`, unde browserul ar trebui să trimită rapoarte despre încălcările CSP.

Cuvinte Cheie pentru Lista de Surse CSP

În cadrul directivelor CSP, puteți utiliza cuvinte cheie pentru lista de surse pentru a defini sursele permise. Iată câteva cuvinte cheie comune:

• 'self': Permite resurse de la aceeași origine (schemă și gazdă) ca și documentul.
• 'none': Interzice resursele din toate sursele.
• 'unsafe-inline': Permite utilizarea scripturilor și stilurilor inline (de exemplu, etichetele <script> și atributele de stil). Utilizați cu extremă prudență, deoarece slăbește semnificativ protecția CSP împotriva XSS.
• 'unsafe-eval': Permite utilizarea funcțiilor de evaluare a codului dinamic, cum ar fi eval() și Function(). Utilizați cu extremă prudență, deoarece introduce riscuri semnificative de securitate.
• 'unsafe-hashes': Permite anumite handlere de evenimente inline sau etichete <style> care se potrivesc cu un hash specificat. Necesită suport din partea browserului. Utilizați cu prudență.
• 'strict-dynamic': Specifică faptul că încrederea acordată în mod explicit unui script prezent în marcaj, prin însoțirea acestuia cu un nonce sau un hash, va fi propagată tuturor scripturilor încărcate de acel script rădăcină.
• data: Permite URI-uri de tip data: (de exemplu, imagini inline codificate în base64). Utilizați cu prudență.
• https:: Permite încărcarea resurselor prin HTTPS de pe orice domeniu.
• [hostname]: Permite resurse de pe un domeniu specific (de exemplu, example.com). Puteți specifica și un număr de port (de exemplu, example.com:8080).
• [scheme]://[hostname]:[port]: Un URI complet calificat, permițând resurse de la schema, gazda și portul specificate.

Exemple Practice de CSP

Să ne uităm la câteva exemple practice de antete CSP:

Exemplul 1: CSP de Bază cu 'self'

Această politică permite resurse numai de la aceeași origine:

            Content-Security-Policy: default-src 'self'
            

              
                Copy
              
            
          

Exemplul 2: Permiterea Scripturilor dintr-un Domeniu Specific

Această politică permite scripturi de pe propriul domeniu și de pe un CDN de încredere:

            Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com
            

              
                Copy
              
            
          

Exemplul 3: Dezactivarea Scripturilor și Stilurilor Inline

Această politică interzice scripturile și stilurile inline, ceea ce reprezintă o apărare puternică împotriva XSS:

            Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'
            

              
                Copy
              
            
          

Important: Dezactivarea scripturilor inline necesită refactorizarea codului HTML pentru a muta scripturile inline în fișiere externe.

Exemplul 4: Utilizarea Nonce-urilor pentru Scripturi Inline

Dacă trebuie să utilizați scripturi inline, folosiți nonce-uri (token-uri criptografice aleatorii, de unică folosință) pentru a adăuga în lista albă anumite blocuri de scripturi inline. Acest lucru este mai sigur decât 'unsafe-inline'. Serverul trebuie să genereze un nonce unic pentru fiecare cerere și să-l includă atât în antetul CSP, cât și în eticheta <script>.

            Content-Security-Policy: default-src 'self'; script-src 'nonce-r4nd0mN0nc3'; style-src 'self'
            

              
                Copy
              
            
          

            <script nonce="r4nd0mN0nc3"> console.log('Inline script'); </script>
            

              
                Copy
              
            
          

Notă: Nu uitați să generați un nou nonce pentru fiecare cerere. Nu refolosiți nonce-urile!

Exemplul 5: Utilizarea Hash-urilor pentru Stiluri Inline

Similar cu nonce-urile, hash-urile pot fi folosite pentru a adăuga în lista albă anumite blocuri inline <style>. Acest lucru se face prin generarea unui hash SHA256, SHA384 sau SHA512 al conținutului stilului.

            Content-Security-Policy: default-src 'self'; style-src 'sha256-HASHEDSTYLES'
            

              
                Copy
              
            
          

            <style sha256="HASHEDSTYLES"> body { background-color: #f0f0f0; } </style>
            

              
                Copy
              
            
          

Notă: Hash-urile sunt mai puțin flexibile decât nonce-urile, deoarece orice modificare a conținutului stilului va invalida hash-ul.

Exemplul 6: Raportarea Încălcărilor CSP

Pentru a monitoriza încălcările CSP, utilizați directiva report-uri sau report-to:

            Content-Security-Policy: default-src 'self'; report-to csp-endpoint;
            

              
                Copy
              
            
          

Va trebui, de asemenea, să configurați antetul Report-To. Antetul Report-To definește unul sau mai multe grupuri de raportare, care specifică unde și cum ar trebui trimise rapoartele.

            Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"https://example.com/csp-report"}]}
            

              
                Copy
              
            
          

Testarea și Implementarea CSP

Implementarea CSP necesită o planificare și o testare atentă. Începeți cu o politică restrictivă și relaxați-o treptat, după cum este necesar. Utilizați antetul Content-Security-Policy-Report-Only pentru a vă testa politica fără a bloca resurse. Acest antet raportează încălcările fără a impune politica, permițându-vă să identificați și să remediați problemele înainte de a implementa politica în producție.

            Content-Security-Policy-Report-Only: default-src 'self'; report-to csp-endpoint;
            

              
                Copy
              
            
          

Analizați rapoartele generate de browser pentru a identifica orice încălcare și ajustați-vă politica în consecință. Odată ce sunteți sigur că politica dvs. funcționează corect, implementați-o folosind antetul Content-Security-Policy.

Cele Mai Bune Practici pentru CSP

• Începeți cu un default-src: Definiți întotdeauna un default-src pentru a stabili o politică de bază.
• Fiți specific: Utilizați directive specifice și cuvinte cheie din lista de surse pentru a limita domeniul de aplicare al politicii dvs.
• Evitați 'unsafe-inline' și 'unsafe-eval': Aceste cuvinte cheie slăbesc semnificativ CSP și ar trebui evitate ori de câte ori este posibil.
• Utilizați nonce-uri sau hash-uri pentru scripturi și stiluri inline: Dacă trebuie să utilizați scripturi sau stiluri inline, folosiți nonce-uri sau hash-uri pentru a adăuga în lista albă anumite blocuri de cod.
• Monitorizați încălcările CSP: Utilizați directiva report-uri sau report-to pentru a monitoriza încălcările CSP și a vă ajusta politica în consecință.
• Testați temeinic: Utilizați antetul Content-Security-Policy-Report-Only pentru a vă testa politica înainte de a o implementa în producție.
• Iterați și rafinați: CSP nu este o configurație unică. Monitorizați și rafinați continuu politica pentru a vă adapta la schimbările din aplicația dvs. și din peisajul amenințărilor.

Ce este Cross-Origin Resource Sharing (CORS)?

Cross-Origin Resource Sharing (CORS) este un mecanism care permite paginilor web de la o origine (domeniu) să acceseze resurse de la o origine diferită. În mod implicit, browserele impun o Politică a Aceleiași Origini (Same-Origin Policy), care împiedică scripturile să facă cereri către o origine diferită de cea din care a provenit scriptul. CORS oferă o modalitate de a relaxa selectiv această restricție, permițând cereri legitime cross-origin, protejând în același timp împotriva atacurilor malițioase.

Înțelegerea Politicii Same-Origin (Aceeași Origine)

Politica Same-Origin este un mecanism fundamental de securitate care împiedică un script malițios de pe un site web să acceseze date sensibile de pe un alt site web. O origine este definită de schemă (protocol), gazdă (domeniu) și port. Două URL-uri au aceeași origine dacă și numai dacă au aceeași schemă, gazdă și port.

De exemplu:

• https://www.example.com/app1/index.html și https://www.example.com/app2/index.html au aceeași origine.
• https://www.example.com/index.html și http://www.example.com/index.html au origini diferite (schemă diferită).
• https://www.example.com/index.html și https://sub.example.com/index.html au origini diferite (gazdă diferită).
• https://www.example.com:8080/index.html și https://www.example.com:80/index.html au origini diferite (port diferit).

Cum Funcționează CORS

Când o pagină web face o cerere cross-origin, browserul trimite mai întâi o cerere „preflight” către server. Cererea preflight folosește metoda HTTP OPTIONS și include antete care indică metoda HTTP și antetele pe care le va folosi cererea reală. Serverul răspunde apoi cu antete care indică dacă cererea cross-origin este permisă.

Dacă serverul permite cererea, include antetul Access-Control-Allow-Origin în răspuns. Acest antet specifică originea (originile) care are permisiunea de a accesa resursa. Browserul continuă apoi cu cererea reală. Dacă serverul nu permite cererea, nu include antetul Access-Control-Allow-Origin, iar browserul blochează cererea.

Antete CORS: O Privire Detaliată

CORS se bazează pe antete HTTP pentru a comunica între browser și server. Iată principalele antete CORS:

• Access-Control-Allow-Origin: Specifică originea (originile) care are permisiunea de a accesa resursa. Acest antet poate conține o origine specifică (de exemplu, https://www.example.com), un wildcard (*) sau null. Utilizarea * permite cereri de la orice origine, ceea ce în general nu este recomandat din motive de securitate. Utilizarea `null` este potrivită doar pentru „răspunsuri opace”, cum ar fi atunci când resursa este preluată folosind protocolul `file://` sau un URI de date.
• Access-Control-Allow-Methods: Specifică metodele HTTP care sunt permise pentru cererea cross-origin (de exemplu, GET, POST, PUT, DELETE).
• Access-Control-Allow-Headers: Specifică antetele HTTP care sunt permise în cererea cross-origin. Acest lucru este important pentru gestionarea antetelor personalizate.
• Access-Control-Allow-Credentials: Indică dacă browserul ar trebui să includă credențiale (de exemplu, cookie-uri, antete de autorizare) în cererea cross-origin. Acest antet trebuie setat la true pentru a permite credențiale.
• Access-Control-Expose-Headers: Specifică ce antete pot fi expuse clientului. În mod implicit, doar un set limitat de antete sunt expuse.
• Access-Control-Max-Age: Specifică durata maximă de timp (în secunde) în care browserul poate memora în cache cererea preflight.
• Origin: Acesta este un antet de cerere trimis de browser pentru a indica originea cererii.
• Vary: Un antet HTTP general, dar important pentru CORS. Când Access-Control-Allow-Origin este generat dinamic, antetul Vary: Origin ar trebui inclus în răspuns pentru a instrui mecanismele de caching că răspunsul variază în funcție de antetul de cerere Origin.

Exemple Practice de CORS

Să ne uităm la câteva exemple practice de configurații CORS:

Exemplul 1: Permiterea Cererilor de la o Origine Specifică

Această configurație permite cereri doar de la https://www.example.com:

            Access-Control-Allow-Origin: https://www.example.com
            

              
                Copy
              
            
          

Exemplul 2: Permiterea Cererilor de la Orice Origine (Nerecomandat)

Această configurație permite cereri de la orice origine. Utilizați cu prudență, deoarece poate introduce riscuri de securitate:

            Access-Control-Allow-Origin: *
            

              
                Copy
              
            
          

Exemplul 3: Permiterea Anumitor Metode și Antete

Această configurație permite metodele GET, POST și PUT, și antetele Content-Type și Authorization:

            Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization
            

              
                Copy
              
            
          

Exemplul 4: Permiterea Credențialelor

Pentru a permite credențiale (de exemplu, cookie-uri), trebuie să setați Access-Control-Allow-Credentials la true și să specificați o origine specifică (nu puteți folosi * când permiteți credențiale):

            Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Credentials: true
            

              
                Copy
              
            
          

De asemenea, trebuie să setați credentials: 'include' în cererea dvs. JavaScript fetch/XMLHttpRequest.

            fetch('https://api.example.com/data', {
  credentials: 'include'
})
            

              
                Copy
              
            
          

Cereri Preflight CORS

Pentru anumite tipuri de cereri cross-origin (de exemplu, cereri cu antete personalizate sau metode altele decât GET, HEAD sau POST cu Content-Type de application/x-www-form-urlencoded, multipart/form-data sau text/plain), browserul trimite o cerere preflight folosind metoda OPTIONS. Serverul trebuie să răspundă la cererea preflight cu antetele CORS corespunzătoare pentru a indica dacă cererea reală este permisă.

Iată un exemplu de cerere și răspuns preflight:

Cerere Preflight (OPTIONS):

            OPTIONS /data HTTP/1.1
Origin: https://www.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type, Authorization
            

              
                Copy
              
            
          

Răspuns Preflight (200 OK):

            HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400
            

              
                Copy
              
            
          

Antetul Access-Control-Max-Age specifică cât timp poate browserul să memoreze în cache răspunsul preflight, reducând numărul de cereri preflight.

CORS și JSONP

JSON with Padding (JSONP) este o tehnică mai veche pentru a ocoli Politica Same-Origin. Cu toate acestea, JSONP are riscuri semnificative de securitate și ar trebui evitat în favoarea CORS. JSONP se bazează pe injectarea de etichete <script> în pagină, care pot executa cod arbitrar. CORS oferă o modalitate mai sigură și mai flexibilă de a gestiona cererile cross-origin.

Cele Mai Bune Practici pentru CORS

• Evitați utilizarea *: Evitați utilizarea wildcard-ului (*) în antetul Access-Control-Allow-Origin, deoarece permite cereri de la orice origine. În schimb, specificați originea (originile) specifică (specifice) care are (au) permisiunea de a accesa resursa.
• Fiți specific cu metodele și antetele: Specificați exact metodele HTTP și antetele care sunt permise în antetele Access-Control-Allow-Methods și Access-Control-Allow-Headers.
• Utilizați Access-Control-Allow-Credentials cu prudență: Activați Access-Control-Allow-Credentials doar dacă trebuie să permiteți credențiale (de exemplu, cookie-uri) în cererile cross-origin. Fiți conștienți de implicațiile de securitate ale permiterii credențialelor.
• Securizați cererile preflight: Asigurați-vă că serverul dvs. gestionează corect cererile preflight și returnează antetele CORS corecte.
• Utilizați HTTPS: Utilizați întotdeauna HTTPS atât pentru origine, cât și pentru resursele pe care le accesați cross-origin. Acest lucru ajută la protejarea împotriva atacurilor de tip man-in-the-middle.
• Vary: Origin: Dacă generați dinamic antetul `Access-Control-Allow-Origin`, includeți întotdeauna antetul `Vary: Origin` pentru a preveni problemele de caching.

CSP și CORS în Practică: O Abordare Combinată

Deși atât CSP, cât și CORS abordează probleme de securitate, ele operează la niveluri diferite și oferă o protecție complementară. CSP se concentrează pe împiedicarea browserului de a încărca conținut malițios, în timp ce CORS se concentrează pe controlul originilor care pot accesa resursele de pe serverul dvs.

Prin combinarea CSP și CORS, puteți crea o postură de securitate mai robustă pentru aplicațiile dvs. web. De exemplu, puteți utiliza CSP pentru a restricționa sursele din care pot fi încărcate scripturile și CORS pentru a controla ce origini pot accesa punctele finale ale API-ului dvs.

Exemplu: Securizarea unui API cu CSP și CORS

Să presupunem că aveți un API găzduit la https://api.example.com pe care doriți să îl faceți accesibil doar de la https://www.example.com. Puteți configura serverul să returneze următoarele antete:

Antetele Răspunsului API (https://api.example.com):

            Access-Control-Allow-Origin: https://www.example.com
Content-Type: application/json
            

              
                Copy
              
            
          

Și puteți configura site-ul dvs. web (https://www.example.com) să utilizeze următorul antet CSP:

Antetul CSP al Site-ului Web (https://www.example.com):

            Content-Security-Policy: default-src 'self'; script-src 'self'; connect-src 'self' https://api.example.com;
            

              
                Copy
              
            
          

Această politică CSP permite site-ului web să încarce scripturi și să se conecteze la API, dar îl împiedică să încarce scripturi sau să se conecteze la alte domenii.

Concluzie

Content Security Policy (CSP) și Cross-Origin Resource Sharing (CORS) sunt instrumente esențiale pentru consolidarea securității aplicațiilor dvs. frontend. Prin configurarea atentă a CSP și CORS, puteți reduce semnificativ riscul de atacuri XSS, atacuri de injectare de date și alte vulnerabilități de securitate. Nu uitați să începeți cu o politică restrictivă, să testați temeinic și să monitorizați și să rafinați continuu configurația pentru a vă adapta la schimbările din aplicația dvs. și la peisajul amenințărilor în evoluție. Prin prioritizarea securității frontend, puteți proteja utilizatorii și asigura integritatea aplicațiilor dvs. web în lumea digitală tot mai complexă de astăzi.