<\/p>\n
En las \u00faltimas semanas hemos cubierto en el blog bastantes cabeceras HTTP relacionadas con la seguridad, pero la jefa de todas ellas tiene que ser Content-Security-Policy<\/a>(CSP). El jefe, tanto por el nivel de protecci\u00f3n que proporciona como, desgraciadamente, por la dificultad de implementarlo correctamente a la primera. Como con todas las reglas de gesti\u00f3n del tr\u00e1fico flightPATH de las que hemos hablado recientemente, las utilizamos nosotros mismos para proteger el sitio web edgeNEXUS y a sus visitantes. <\/p>\n Hemos hecho el trabajo duro y hemos sentido el dolor para que t\u00fa no tengas que hacerlo, pero es innegable que hay que pensar y planificar antes de ponerlo en pr\u00e1ctica. Pero merece la pena. El concepto de esta cabecera es bastante sencillo<\/a> e igual de potente. En pocas palabras, se utiliza para especificar los or\u00edgenes permitidos del contenido que se puede cargar en tu sitio web. Esto proporciona una fuerte protecci\u00f3n contra una serie de ataques de inyecci\u00f3n de c\u00f3digo frecuentes en la cada vez m\u00e1s din\u00e1mica Internet de hoy en d\u00eda, como el Cross Site Scripting (XSS) y el Clickjacking. <\/p>\n Los tipos de contenido que se pueden controlar son: JavaScript, CSS (s\u00ed, el CSS puede ser peligroso), marcos HTML, fuentes, im\u00e1genes y objetos incrustables como los applets de Java. Es estupendo tener tantas opciones, pero aqu\u00ed es donde surge la dificultad. Los sitios web actuales (incluidos los nuestros) contienen una multitud de estos tipos de contenido de muchas fuentes, e identificarlos y tenerlos en cuenta en una pol\u00edtica puede ser todo un esfuerzo. <\/p>\n Antes de entrar en materia, echemos un vistazo a los elementos del valor de la cabecera y al aspecto de una pol\u00edtica. Como ver\u00e1s, se trata esencialmente de una larga lista de tipos de contenido (todos terminan con -src en este ejemplo) y las fuentes permitidas para cada tipo. En conjunto, se conocen como directivas de pol\u00edtica. <\/p>\n default-src \u201cself\u201d data:; script-src \u201cself\u201d \u201cunsafe-inline\u201d; connect-src \u201cself\u201d; img-src \u201cself\u201d data:; style-src \u201cself\u201d \u201cunsafe-inline\u201d data:; font-src \u201cself\u201d data:; child-src \u201cself\u201d<\/strong><\/p>\n Hay m\u00e1s tipos de contenido que podemos tener en cuenta, pero las que se muestran arriba son las directivas m\u00e1s importantes (en nuestra opini\u00f3n, basadas en el riesgo y la prevalencia). A continuaci\u00f3n se detalla a qu\u00e9 contenido se refiere cada una; <\/p>\n Estos tipos de contenido y sus valores est\u00e1n separados entre s\u00ed (delimitados) por un punto y coma. Cada tipo puede tener uno o varios de los siguientes valores; <\/p>\n Se utiliza un espacio simple para delimitar cada valor. Las comillas simples ‘ son necesarias a menos que el valor sea un nombre de dominio. Ten en cuenta que las extensiones del navegador y los plugins est\u00e1n exentos, ya que se consideran seguros porque el usuario conf\u00eda en ellos (al fin y al cabo, es quien los ha instalado). <\/p>\n Todo parece bastante t\u00e9cnico y complejo, pero si lo abordamos paso a paso es bastante r\u00e1pido llegar a una pol\u00edtica. Vamos a trabajar r\u00e1pidamente con dos ejemplos. En primer lugar, probemos con un simple sitio web interno servido a trav\u00e9s de HTTP. Esto es lo que necesitamos <\/p>\n El valor completo de la cabecera es razonablemente corto:<\/p>\n default-src \u201cself\u201d data:; script-src \u201cself\u201d \u201cunsafe-inline\u201d; connect-src \u201cself\u201d; img-src \u201cself\u201d data:; style-src \u201cself\u201d \u201cunsafe-inline\u201d data:; font-src \u201cself\u201d data:<\/strong><\/p>\n En segundo lugar, un sitio web de cara a Internet protegido por SSL\/TLS que utiliza Google Analytics (GA), CSS en l\u00ednea, fuentes e im\u00e1genes, CSS de tu sitio e im\u00e1genes de otros sitios web. Repasemos lo que necesitamos pieza por pieza (no es muy diferente); <\/p>\n Si lo sumamos todo, tenemos esta pol\u00edtica ligeramente m\u00e1s larga:<\/p>\n default-src \u201cself\u201d data: https:; script-src \u201cself\u201d \u201cunsafe-inline\u201d *.google-analytics.com https:; img-src \u201cself\u201d \u201cunsafe-inline\u201d * https:; style-src \u201cself\u201d \u201cunsafe-inline\u201d https:; font-src \u201cself\u201d \u201cunsafe-inline\u201d https:<\/strong><\/p>\n Yo dir\u00eda que es bastante f\u00e1cil. Google no era tan \u201camigable\u201d con CSP en el pasado (este valor de cabecera sol\u00eda ser al menos el doble de largo), pero afortunadamente han hecho grandes progresos recientemente. Ver\u00e1s que no hemos tenido que a\u00f1adir el dominio *.google-analytics.com al script-src como valor de tipo de contenido, ya que su c\u00f3digo se ejecuta como un script en l\u00ednea.<\/p>\n Lo ideal ser\u00eda que crearas una pol\u00edtica por p\u00e1gina de tu sitio web, ya que los recursos cargados sin duda variar\u00e1n seg\u00fan la p\u00e1gina, pero esto es bastante oneroso y es mucho m\u00e1s sencillo, aunque eficaz, crear una pol\u00edtica que cubra todas las fuentes posibles. La mayor\u00eda de los ejemplos de nuestra p\u00e1gina de GitHub adoptan este enfoque, pero tambi\u00e9n hay uno all\u00ed por si quieres proporcionar una mayor protecci\u00f3n a p\u00e1ginas concretas. <\/p>\n Para probar y solucionar problemas, te recomiendo encarecidamente que utilices las Herramientas para desarrolladores de Google Chrome. Ve al sitio en cuesti\u00f3n y pulsa F12, haz clic en Red, aseg\u00farate de que la opci\u00f3n Desactivar cach\u00e9 est\u00e1 marcada y vuelve a cargar la p\u00e1gina. Cualquier error aparecer\u00e1 claramente resaltado. Al final de este blog hay una pantalla de lo que podr\u00edas ver si tu pol\u00edtica est\u00e1 bloqueando unsafe-inline<\/strong> y utilizas Google Analytics; los mensajes de error son muy \u00fatiles. <\/p>\n Ajusta tu pol\u00edtica seg\u00fan sea necesario y aclara y repite. Lo ideal ser\u00eda que lo hicieras utilizando un Servicio Virtual de pruebas dedicado con la regla flightPATH que est\u00e1s probando aplicada, pero que por lo dem\u00e1s sirviera al mismo sitio, s\u00f3lo que a trav\u00e9s de una IP Virtual diferente para no afectar a los clientes reales mientras realizas las pruebas. <\/p>\n Como siempre ocurre, la gran ventaja de utilizar un equilibrador de carga es que s\u00f3lo tenemos que hacerlo en un lugar central para proteger todos nuestros servidores (y sitios). No necesitamos depender de desarrolladores ni de reconfiguraciones del servidor web. En el equilibrador de carga edgeNEXUS s\u00f3lo tenemos que importar una plantilla de configuraci\u00f3n autom\u00e1tica jetPACK y asignar una regla de tr\u00e1fico flightPATH al Servicio o Servicios Virtuales que deseemos proteger (tras las modificaciones oportunas). <\/p>\n La regla s\u00f3lo a\u00f1ade la cabecera si no existe, por lo que funcionar\u00e1 incluso cuando nuestros servidores web ya la inserten o quiz\u00e1s s\u00f3lo la inserten para p\u00e1ginas concretas. Esta regla deber\u00eda formar parte de tu configuraci\u00f3n est\u00e1ndar del Servicio Virtual: no tienes nada que perder sea cual sea el sitio aunque, por supuesto, siempre se recomienda hacer pruebas. Puedes descargar este jetPACK y muchos otros en el sitio Github de edgeNEXUS<\/a>. <\/p>\n flightPATH es un motor de reglas din\u00e1mico y basado en eventos desarrollado por edgeNEXUS para manipular y enrutar de forma inteligente el tr\u00e1fico IP, HTTP y HTTPS de carga equilibrada. Es altamente configurable y potente, pero muy f\u00e1cil de usar. <\/p>\n Merece la pena leer estos enlaces relacionados si quieres saber m\u00e1s;<\/p>\n http:\/\/www.html5rocks.com\/en\/tutorials\/security\/content-security-policy\/<\/a><\/p>\n https:\/\/developer.mozilla.org\/en\/docs\/Web\/Security\/CSP\/CSP_policy_directives<\/a><\/p>\n\n
\n
\n
\n