Content Security Policy: mayor seguridad para tus co­n­te­ni­dos web

Los co­n­te­ni­dos activos en páginas web, como por ejemplo Ja­va­S­cri­pt, CSS o ActiveX, plantean riesgos de seguridad para los usuarios de Internet y los gestores de páginas web y pueden ma­ni­pu­lar­se, por ejemplo, mediante el Cross Site Scripting. Para que las páginas de Internet puedan uti­li­zar­se sin preo­cu­pa­cio­nes, existe lo que se conoce como Content Security Policy (CSP), cuyo papel consiste en proteger a las páginas frente a ataques pe­r­ju­di­cia­les y es co­m­pa­ti­ble con la mayoría de na­ve­ga­do­res web. Por ello, este concepto de seguridad protege tanto a páginas web como a usuarios de Internet, pero ¿en qué consiste y cómo funciona CSP?

La Política de seguridad de contenido (CSP, Content Security Policy) tiene sus orígenes en el año 2004, cuando se le conocía con el nombre de “Content Re­s­tri­c­tion”. Su aparición estuvo motivada por las brechas de seguridad cada vez mayores en los scripts de Internet. El Cross Site Scripting (XSS) en concreto es un método criminal que consiste en infiltrar código malicioso en una página web, por lo que plantea un enorme riesgo para los usuarios. Si bien los usuarios visitan una página en principio fiable, en ella puede haberse insertado un script que carga los datos ma­li­cio­sos de una fuente externa. Los ci­be­r­de­li­n­cue­n­tes utilizan para ello, por ejemplo, brechas de seguridad en las funciones de co­me­n­ta­rios de la página. Así pueden obtener acceso a or­de­na­do­res pe­r­so­na­les sin que los usuarios de Internet sean co­n­s­cie­n­tes de ello y en la mayoría de los casos, ni siquiera los we­b­ma­s­te­rs suelen darse cuenta de la in­fi­l­tra­ción de código.

La Mozilla Fou­n­da­tion impulsó el de­sa­rro­llo de la CSP para so­lu­cio­nar esta pro­ble­má­ti­ca. La ventaja del estándar de seguridad es que se pueden es­ta­ble­cer reglas en el navegador con respecto a los scripts que el software tiene que cargar y los que no. Para ello, la Content Security Policy se basa en cabeceras HTTP.

Para es­ta­ble­cer la co­mu­ni­ca­ción en Internet, cliente y servidor in­te­r­ca­m­bian datos a través del Hypertext Transfer Protocol (HTTP). Los campos de las cabeceras HTTP son una parte muy im­po­r­ta­n­te de las requests (pe­ti­cio­nes) y las responses (re­s­pue­s­tas) y en ellas se tra­n­s­mi­ten pa­rá­me­tros y ar­gu­me­n­tos re­le­va­n­tes para el in­te­r­ca­m­bio de ambos pa­r­ti­ci­pa­n­tes en la co­n­ve­r­sa­ción (servidor y cliente). Dichas cabeceras se dividen en diversos campos para so­li­ci­tu­des y re­s­pue­s­tas y pueden, por ejemplo, contener in­fo­r­ma­ción sobre el conjunto de ca­ra­c­te­res, el idioma y las cookies. CSP se de­sa­rro­lla como campo de cabecera de respuesta, lo que significa que el servidor entrega los datos y el navegador los procesa.

El webmaster crea la cabecera de la Content Security Policy y la integra en cada subpágina de la página web en la que deba aplicarse el estándar de seguridad. También cabe la po­si­bi­li­dad de aplicar di­fe­re­n­tes medidas de seguridad para cada una de las páginas. Un modo sencillo de im­ple­me­n­tar este concepto de seguridad es mediante la creación de archivos .htaccessd, que se colocan en las mismas carpetas (o en un nivel más elevado je­rá­r­qui­ca­me­n­te) que las páginas web o anclando la CSP di­re­c­ta­me­n­te en la co­n­fi­gu­ra­ción del servidor.

En el marco de la Content Security Policy y para evitar el Cross Site Scripting, los we­b­ma­s­te­rs deben ex­te­r­na­li­zar todos los scripts en archivos separados en lugar de in­te­grar­los di­re­c­ta­me­n­te en el código fuente de la página web. La CSP funciona según el principio de la whitelist: en el header se mencionan las fuentes desde las que se pueden cargar scripts y datos. Si un script ajeno se introduce en el código HTML sin ser re­co­no­ci­do y este intenta cargar datos externos, el navegador del usuario lo impide. En general, una CSP bloquea todos los scripts que se en­cue­n­tran di­re­c­ta­me­n­te en el código (inline scripts). Con ello se protege tanto la página web como a los usuarios de Internet y sobre todo sus datos sensibles. 

La ma­ni­pu­la­ción mediante el Cross Site Scripting es para los ci­be­r­de­li­n­cue­n­tes algo muy sencillo de realizar. Casi todas las páginas de la World Wide Web tienen un campo de entrada de datos, como pueden ser los co­me­n­ta­rios, la barra de búsqueda o los campos de inicio de sesión. En ellos, en lugar de textos, también pueden in­se­r­tar­se scripts. Si el servidor no está protegido ade­cua­da­me­n­te, los cri­mi­na­les utilizan in­te­r­fa­ces de phishing, in­mo­vi­li­zan la página en su totalidad u obtienen el control del navegador web del usuario mediante software malicioso. La política de seguridad de contenido o, para ser más exactos, su campo en la cabecera, informa al navegador web sobre las fuentes desde las que puede cargar datos. Si se im­ple­me­n­ta esta política en el código de la página web, se responde al intento de acceder al código in­fi­l­tra­do mediante XSS con un mensaje de error.

Con la Content Security Policy los we­b­ma­s­te­rs también pueden hacer otras co­n­fi­gu­ra­cio­nes, por ejemplo, a través de las si­guie­n­tes di­re­c­ti­vas:

• base-uri: limita los URL que pueden aparecer en el elemento <base> de la página web.  
• child-src: establece las fuentes desde las que pueden aparecer datos en frames, como, por ejemplo, en los vídeos in­se­r­ta­dos por terceros.
• connect-src: limita las fuentes con las que se puede vincular una página web, p. ej., a través de enlaces.
• font-src: determina las fuentes desde las que se pueden cargar los tipos de letra.
• form-action: facilita una lista de puntos finales válidos en fo­r­mu­la­rios. 
• frame-ancestors: establece los dominios que pueden in­co­r­po­rar la página web como frames y iFrames.
• img-src: restringe las fuentes desde las que se pueden cargar imágenes.
• media-src: establece las fuentes a partir de las que se pueden cargar los formatos de audio y vídeo.
• object-src: define los controles sobre Flash y otros plugins.
• plugin-types: limita los tipos de plugins.
• report-uri: es­pe­ci­fi­ca un URL al que se pueden enviar informes si se violan las medidas de seguridad.
• script-src: define las fuentes pe­r­mi­ti­das para Ja­va­S­cri­pt.
• style-src: funciona como script-src, pero se aplica a las hojas de estilo.
• upgrade-insecure-requests: establece que las páginas inseguras deben tratarse con HTTP y HTTPS.
• sandbox: desplaza la página co­rre­s­po­n­die­n­te a un sandbox (entorno de pruebas), en el que, se prohíben, entre otros, fo­r­mu­la­rios, ventanas eme­r­ge­n­tes y scripts.

Estas di­re­c­ti­vas solo se aplican si así se establece ex­pre­sa­me­n­te. En caso contrario pe­r­ma­ne­cen abiertas y re­pre­se­n­tan una brecha de seguridad, algo que se puede cambiar con default-src, que establece el estado por defecto de todas las di­re­c­ti­vas que terminan con -src. En lugar de dejarlas abiertas, podrías regular que solo se carguen datos de la propia página web, a menos que hayas definido una única página de otra forma en la cabecera HTTP. En algunas di­re­c­ti­vas es­pe­cia­les puedes agregar otras fuentes.

En el campo header pueden in­se­r­tar­se muchas di­re­c­ti­vas. Si quieres in­co­r­po­rar varias, puedes se­pa­rar­las con puntos y comas. Además, como webmaster debes es­pe­ci­fi­car todas las fuentes dentro de una directiva, pero no se permiten entradas múltiples de las mismas di­re­c­ti­vas con fuentes adi­cio­na­les como en el ejemplo siguiente: