Per què necessites una política de seguretat de contingut forta

La Importància dels Encabezats de Seguretat

Quan es van dissenyar els navegadors per primera vegada, ningú no podia preveure quins tipus d'atacs serien possibles eventualment. Alguns dels atacs que coneixem avui podrien potencialment ser eliminats, o almenys limitats, canviant com funcionen els navegadors. No obstant això, alterar el funcionament dels navegadors impactaria significativament els serveis d'internet existents, fent-ho una opció inviable. L'alternativa? Oferim als usuaris amb necessitats de seguretat més altes la capacitat d'afegir capes addicionals de protecció, conegudes com a encabezats de seguretat. Quan es visita un lloc, el servidor respon amb un encabezat de resposta HTTP. Aquesta és una instrucció addicional per al teu navegador, fent que la teva part d'internet—el teu lloc web o aplicació web—sigui més segura.

Què és un CSP?

La Política de Seguretat de Contingut, o CSP per abreujar, és un exemple d'aquest tipus d'encabezat de seguretat [1,2]. La idea és simple: un CSP restringeix què pot fer un navegador amb el contingut i d'on pot provenir aquest contingut. En la configuració per defecte, hi ha poques restriccions, cosa que significa que un lloc web pot carregar contingut de gairebé qualsevol font a internet. Això inclou coses aparentment inofensives com imatges, però també codi JavaScript que s'executa directament al navegador. Amb un CSP, tu com a propietari del lloc web determines exactament d'on pot venir el contingut i sota quines condicions.

Pensa en el CSP com la teva segona línia de defensa. Si un atacant aconsegueix trobar una vulnerabilitat, el CSP fa que sigui molt més difícil per a ell explotar-la. Considerem un exemple concret.

El Perill del Cross-Site Scripting

Les vulnerabilitats d'injecció de contingut i codi al frontend han estat un problema conegut durant molt de temps. Aquesta és una classe de vulnerabilitats on les dades, com el text enviat per un usuari, no són processades correctament per l'aplicació. Això permet a un atacant eludir la seguretat i afegir el seu propi marcat (HTML), estil (CSS) o codi client (JavaScript) a l'aplicació web. Això és especialment perillós amb JavaScript, ja que permet a un atacant executar codi client al navegador de la víctima. Això es coneix com a cross-site scripting (XSS) i dóna a l'atacant control total sobre l'aplicació com si estigués autenticat com la víctima.

Potser penses, "Però si la meva aplicació no és vulnerable a XSS, un CSP no aporta cap valor?" Estàs realment segur que no ets vulnerable? L'XSS pot ser un dels 'clàssics' en mètodes d'atac, però continua sent un problema que afecta moltes organitzacions. Més del 30% de les aplicacions provades per Computest Security l'any passat eren vulnerables a alguna forma d'XSS [3]. Tingues en compte que el client mitjà de Computest Security ja és molt conscient de la seguretat, realitzant proves de seguretat regularment a les seves aplicacions. Per tant, el nombre real d'aplicacions vulnerables a XSS probablement és encara més alt. No és un luxe establir un CSP fort. Pot proporcionar aquell extra de seguretat que necessites per mitigar riscos desconeguts.

Com Funciona el CSP?

Com amb tota pregunta interessant, la resposta és: depèn. En aquest cas, depèn de la teva aplicació i de com està estructurada. Vegem alguns exemples de possibles CSPs retornats com a encabezats de resposta HTTP.

Centrant-se en la directiva script-src, que gestiona totes les fonts de JavaScript com ara fitxers *.js o codi en línia entre etiquetes , aquesta directiva et protegeix contra vulnerabilitats amb el major impacte.
Si la teva aplicació (https://example.com) està configurada de manera que tot el JavaScript utilitzat prové d'un domini dedicat (https://js.example.com), llavors un CSP que et protegeixi contra molts tipus d'atacs XSS podria ser així:

Cap script carregat des d'una altra font s'executarà. El mateix s'aplica a qualsevol JavaScript en línia. Si també cal incloure scripts des del mateix domini que allotja l'aplicació, podria ser així:

Permetre JavaScript en línia ho fa una mica més complex ja que un navegador no pot distingir entre contingut legítim i contingut injectat maliciós. Tot i això, és possible utilitzant nonces o hashes. Un nonce, un valor prou aleatori, es pot incloure a la capçalera CSP així:

Aquest valor ha de coincidir amb el valor especificat en una etiqueta a la mateixa resposta.

Si no s'inclou el nonce adequat, el codi no s'executa. El valor del nonce canvia amb cada sol·licitud, evitant que un atacant el pugui predir per avançat, fent que qualsevol vulnerabilitat XSS potencial no sigui explotable. Un mètode alternatiu és utilitzar un valor hash, calculat sobre el contingut complet de l'etiqueta , assegurant que hashes no coincidents signifiquin cap execució. Això impedeix que un atacant injecti el seu codi maliciós.

Si no vas desenvolupar la teva aplicació tenint en compte una CSP, tria una solució que s'adapti a la teva arquitectura. Afortunadament, existeixen biblioteques per a diversos frameworks d'aplicacions web que ajuden a la implementació.

Els exemples proporcionats aquí no mostren totes les possibilitats d'una CSP. Permet configuracions detallades per a tots els recursos potencials en una pàgina HTML. Interessat? Els enllaços al final d'aquest blog ofereixen material de lectura addicional.

Errors d'implementació amb una CSP

Sigues cautelós, les coses poden sortir malament quan s'implementa una CSP. Particularment quan s'utilitza l'enfocament de llista blanca de fonts, hi ha trampes. A Computest Security, sovint hem vist que una CSP mal configurada esdevé inútil o fàcilment evadida per un atacant. Exemples d'aquests errors inclouen:

• Si inclous 'unsafe-inline' a la directiva script-src, això permet tot el JavaScript en línia. Com indica el nom, això presenta un alt risc, anul·lant la majoria dels beneficis d'una CSP.
• Quan es poden pujar i descarregar fitxers des del domini de l'aplicació, hi ha un alt risc que això es pugui explotar per evadir una CSP que permet ‘self’ a la directiva script-src, fent la teva aplicació vulnerable.
• Si permets un CDN o un host públic com AWS S3 (per exemple, https://s3.eu-central-1.amazonaws.com), un atacant pot utilitzar aquests serveis per allotjar els seus exploits maliciosos. Qualsevol pot crear un compte AWS per allotjar recursos a S3, per tant, això suposa riscos potencials.
• Si utilitzes nonces, han de ser prou aleatoris i utilitzats només una vegada. Altrament, un atacant pot reutilitzar el nonce per als seus atacs.
• Si permets JavaScript en línia amb un valor nonce, la CSP no protegeix contra la injecció de JavaScript directament dins l'script. Una etiqueta aprovada amb un valor nonce sempre s'executarà independentment del seu contingut.
• Els hosts permesos amb punts finals JSONP poden ser explotats per atacants per evadir parcialment una CSP mitjançant l'ús indegut de la funcionalitat de callback, permetent potencialment l'execució arbitrària de JavaScript.

A causa d'aquestes configuracions errònies comunes, una CSP basada en nonce o hash combinada amb 'strict-dynamic' es considera generalment l'enfocament més segur [4]. Això permet especificar exactament quins scripts es poden executar sense necessitat d'incloure tota la llista blanca d'hosts. Un exemple de com podria aparèixer:

A continuació es pot incloure contingut addicional dins de l'HTML:

Una Política de Seguretat de Contingut ben pensada i estricta determina amb precisió què pot passar al navegador quan la teva aplicació es carrega. Tot i que una CSP forta no garanteix que la teva aplicació estigui completament protegida contra tots els atacs externs, et posa en el camí correcte cap a un entorn en línia més segur.

T'interessa saber si la teva organització es beneficiaria d'una CSP? Som aquí per ajudar-te! Contacta'ns a través de [email protected] o truca al +31 (0)88 733 13 37 i et respondrem ràpidament.

Per a més lectura sobre CSP:

1
2
3
4
5