Com utilitzar de manera segura un framework de frontend per al teu lloc web

Què és un Framework de Frontend?

Un framework és un conjunt d'eines—un punt de partida per desenvolupar el teu lloc web. Estandarditza la manera com estructures el teu programari, el codi, i s'encarrega de moltes coses que tot lloc web necessita, com l'emmagatzematge de dades o la construcció de pàgines. Aquest últim és un exemple principal del que un framework ofereix per a la "part frontal" del lloc web, d'aquí el nom de framework de frontend. Basant-nos en les nostres experiències amb vulnerabilitats en la pràctica, aquí tens els tres consells més importants per utilitzar frameworks de frontend de manera segura.

1. No confiïs en el teu Frontend

El frontend es diu frontend perquè és la part del codi del lloc web que s'executa a l'ordinador, portàtil o dispositiu mòbil del visitant. Això significa que no has de confiar en el frontend. Algú amb intencions malicioses pot veure o modificar fàcilment el codi font del frontend. Per tant, és crucial que el backend, la part del servidor del lloc web, no depengui del frontend per realitzar comprovacions de seguretat; ha de fer-les de manera independent. Això inclou verificar l'autenticació de l'usuari i si un usuari autenticat té accés a dades sensibles. A més, el codi font del frontend és públic, així que no és el lloc per a informació sensible o secrets com contrasenyes o claus API.

2. Coneix les Limitacions del teu Framework

Un framework de frontend és increïblement útil, especialment per prevenir una vulnerabilitat particular que afecta un terç dels llocs web: l'execució de codi maliciós entre llocs (XSS). Si un lloc web és vulnerable a XSS, una persona malintencionada pot utilitzar un fragment de codi perjudicial per atacar altres visitants del lloc. Normalment, l'atacant no pot dirigir-se a tothom al lloc sense passos addicionals, com fer que la víctima faci clic en un enllaç maliciós específic.
Els frameworks de frontend són eines efectives per prevenir vulnerabilitats XSS ja que molts apliquen automàticament la codificació correcta, assegurant que l'entrada es mostri com a dades i no com a codi. Tot i això, els frameworks de frontend no són solucions màgiques, i com a desenvolupador has de tenir en compte moltes excepcions. Aviat entrarem en detalls específics. Si no ets desenvolupador, pots saltar directament al punt 3 sobre actualitzacions.

2.1 Teoria dels Frameworks

L'execució de codi maliciós entre llocs (XSS) apareix quan l'entrada de l'usuari arriba a llocs del frontend on no s'interpreta com a text sinó com a HTML o JavaScript. Per exemple, si construïm una funció de cerca que mostra quants resultats ha donat un terme de cerca, podríem oblidar codificar en HTML el terme de cerca. Aquesta errada permet crear enllaços amb JavaScript maliciós que, en fer clic, executa aquest codi. Amb JavaScript, els atacants obtenen accés a dades sensibles de la víctima.

Bàsicament hi ha tres variants bàsiques de XSS, classificades segons on acaba la entrada de l'usuari. En l'exemple anterior, acaba entre etiquetes d'element, a 'innerHTML', però l'XSS també pot ocórrer amb l'entrada col·locada en un atribut HTML.

Finalment, hi ha una variant única que implica prefixos d'URL especials com 'javascript:'

2.2 XSS i Frameworks Frontend

Alguns frameworks protegeixen rigorosament contra les tres variants bàsiques d'XSS, mentre que altres només protegeixen contra la primera. Examinem tres frameworks.

2.2.1 Angular

• Si utilitzeu consistentment la interpolació a Angular ({{ }}), esteu protegits. Angular és prou intel·ligent per reconèixer els contextos esmentats anteriorment. No obstant això:

• Eviteu la interacció directa amb elements DOM fora d'Angular. Per exemple, manipular el DOM utilitzant ElementRef. Fer-ho utilitza les API integrades del navegador on l'entrada de l'usuari podria no ser gestionada de manera segura.

• No sobreescriviu les funcions de seguretat d'Angular. Podeu marcar cert contingut com a segur utilitzant funcions com bypassSecurityTrustHTML, però això evita la funció d'escapament d'Angular i suposa un risc de vulnerabilitats XSS.

• Eviteu generar plantilles dinàmicament, com ara afegir cadenes a plantilles o utilitzar un altre llenguatge de plantilles. L'escapament només es produeix durant el renderitzat de la plantilla, així que la plantilla en si ha de ser de confiança. Qualsevol entrada d'usuari incorporada a la plantilla suposa riscos d'XSS.

2.2.2 Vue.js

Vue.js també ofereix un suport fort. Quan s'utilitza la interpolació de text ({{ }}), l'entrada de l'usuari s'escapa en HTML, fent-la segura per a la inclusió entre etiquetes HTML. No obstant això, tingueu en compte:

• En la majoria dels casos, l'entrada d'usuari en enllaços d'atributs dinàmics és segura, però cal precaució amb atributs com 'src' i 'href', ja que Vue.js només codifica les cometes dobles ("). Per tant, un prefix 'javascript:' podria persistir.

• Vue.js permet controladors d'esdeveniments amb directives v-on o directament en atributs d'esdeveniments 'natius', però compte: l'entrada d'usuari en aquests atributs es tracta i s'executa com a JavaScript. L'escapament HTML a través de la interpolació de text fa poc, ja que l'entrada no està en un context HTML sinó en un de JavaScript.

• De manera similar a Angular, la manipulació directa del DOM a Vue.js, com l'ús de v-html, funcions de renderitzat o JSX, interpreta l'entrada com a HTML, suposant riscos quan es combina amb entrada d'usuari (potencial).

• Com Angular, generar plantilles dinàmicament a Vue.js és arriscat. L'escapament es produeix en el moment del renderitzat, així que les plantilles no fiables a causa de l'entrada d'usuari afegida suposen un risc d'XSS.

2.2.3 React

• React segueix una línia similar. JSX serveix per definir elements HTML, avaluant el contingut JSX com a expressions JavaScript, que després s'escapen en HTML, assegurant una contenció segura entre etiquetes HTML. No obstant això, tingueu en compte:

• React també només escapa les cometes dobles (") en atributs. Per tant, cal tenir precaució amb els atributs 'src' i 'href' on els prefixos 'javascript:' podrien romandre.

• A React, la manipulació directa del DOM mitjançant dangerouslySetInnerHTML o la interacció amb el DOM amb findDOMNode/createRef omet l'escapament estàndard de React, deixant vulnerabilitats XSS.

• És comú a React instanciar components utilitzant l'operador spread (per exemple, <div { ...properties }>). No obstant això, un usuari que modifiqui l'objecte de propietats pot injectar script a través de 'dangerouslySetInnerHTML', resultant en exposició a XSS.

###3. Mantingueu el programari actualitzat

Les actualitzacions de programari i la gestió de dependències són sempre un repte de seguretat, especialment per als frameworks frontend. És crucial comprovar periòdicament noves vulnerabilitats ja que sovint apareixen i poden afectar la vostra situació. Les eines poden ajudar; molts gestors de paquets poden comprovar automàticament vulnerabilitats conegudes (com npm audit), mentre que els escàners de dependències poden crear automàticament sol·licituds de pull per actualitzacions (com Dependabot).

Finalment, sigueu crítics amb el programari del qual depeneu. Cada biblioteca addicional augmenta la vostra superfície d'atac, possiblement amb vulnerabilitats desconegudes, necessitant actualitzacions oportunes i potencialment compromeses. Per tant, limiteu les dependències de programari i utilitzeu només fonts de confiança.

Conclusió

Voleu utilitzar un framework frontend de manera segura? Aquí teniu com:

1. No confieu en el vostre frontend. Utilitzeu el backend per a secrets i comprovacions de seguretat vitals.
2. Sigueu conscients de les limitacions del vostre framework. Un framework només és més segur si s'utilitza correctament.
3. Controleu les actualitzacions de programari i assegureu-vos de rebre pegats de seguretat a temps.

Teniu curiositat si el vostre frontend és segur? Deixeu-nos revisar el vostre codi font. Farem una investigació en profunditat per identificar vulnerabilitats i proporcionar comentaris sobre eleccions arquitectòniques i de disseny, ajudant-vos a abordar debilitats.
Contacteu-nos a: [email protected].