Etiqueta: chrome

Chrome dice que mi sitio no es seguro ¿Qué hago?

Hoy es el día elegido (no os quejéis, podrían haber escogido un viernes) para que el navegador Google Chrome comience a marcar los sitios que no posean un certificado como “No seguro”. De momento es un mensaje adosado al nombre del dominio visitado, en gris. No salta a la vista, es algo discreto y con las prisas con las que vivimos hoy día no parece que a muchos les vaya a molestar…hasta que en octubre de este mismo año, ese mismo mensaje, se cabree y se torne de color rojo chillón…Ya lo contaba nuestro compañero Carlos ‘Maestro‘ Ledesma en otra UAD.

Casi es seguro, el resto de navegadores menos uno seguirá la estela marcada por Chrome. Con el tiempo añadirán el mismo mensaje o similar. Así que toca extender un certificado y configurar adecuadamente el cifrado del servidor para que ese mensaje desaparezca cuando nuestros visitantes entren en nuestros dominios. Pero no queremos que esa sea la motivación principal. Existe otra (y muchas más) importantes por las que ya deberías estar ofreciendo cifrado incondicional en todos y cada uno de tus sitios. Además vamos a derribar unos cuantos mitos acerca de los costes y complejidades inherentes a su despliegue.

1.- Respeta la privacidad de tus clientes o visitantes

Las conexiones cifradas no son un adorno ni están ahí para que “salga el candadito”. Están para que otros no capturen y lean el tráfico que se produce entre cliente y servidor. Es posible que creas que ese tráfico “no es importante”, pero en muchos contextos sí que lo es e importa mucho. Incluso si tu sitio es presencial y no existen formularios o campos de búsqueda, la propia traza de visitas de URLs del sitio ya permite crearse un perfil de la persona afectada por no cifrar las comunicaciones.

2.- Da autenticidad a tu dominio

Sin un certificado debidamente extendido un visitante no sabría diferenciarlo de un sitio falsificado. Visitar un dominio no implica que sea el sitio correcto, tanto con un ataque de envenenamiento de la caché DNS como con un ataque sobre rutas BGP nos permite falsificar un sitio si este no posee un certificado adecuado.

3.- Es gratis

Muchas personas y organizaciones piensan que extender un certificado es caro y un gasto innecesario (o simplemente, no dan importancia a los motivos del punto 1). No solo no es caro, es gratis. Iniciativas como Let’s Encrypts nos permiten poseer un certificado libre de costes directos. No hay excusas si habías mirado la inversión en certificados como un gasto inútil. Es gratis. 0 euros. Nada.

4.- Es sencillo

No tengo/No voy a dedicar personal/tiempo para una tarea así. A veces no es cuestión de dineros sino de tiempo o no tener el personal adecuado para extender e instalar un certificado. En realidad es una tarea sencilla, no es compleja. Elige el certificado adecuado (recuerda, Let’s Encrypts…es gratis!), lo obtienes, sigues los pasos indicados por el emisor (todos tienen una guía, por ejemplo), reinicias el servidor y a funcionar.

5.- Mejora tu imagen

A ver. ¿Cómo va a ser lo mismo una conexión plana, ahí, sin candado ni verde y con un mensaje de “No seguro” que una conexión cifrada con un buen candadazo TLS 1.3? Eso dice mucho. Da fuerza, vigor y sienta principios: “Esto es seguro, bueno (toc, toc) y de confianza”. Aunque no lo hagas por la privacidad, te salga gratis y te lo instale un amigo con conocimientos informáticos al que invitarás a una paella a cambio, al menos piensa que va a reforzar tu imagen.

Desbloquea un logro más:

6.- HSTS o mata tus conexiones inseguras

No es suficiente con el certificado y las conexiones bien configuradas, que eso es otro menester. Mientras no configuremos nuestros servidores para que les diga al navegador de nuestros clientes que no usen conexiones inseguras cuando nos visiten, todo esto podría no servir de mucho.

Aunque dispongamos de lo anterior, los ataques de hombre en el medio suelen usar herramientas del tipo ssltrip, donde se puentea la conexión segura hacia una insegura. Sin embargo, si el navegador visitó antes de ese ataque nuestro sitio y recibió la cabecera HSTS entonces optará por no establecer una conexión plana (no cifrada) y cortará las comunicaciones que se dirijan a nuestro dominio. ¿Sencillo verdad?.

HSTS (https strict transport security) no es para nada difícil de implementar. Hay miles de guías para ello. Una sola cabecera http puede proteger a tus clientes y visitantes de ataques de hombre en el medio de forma bastante sencilla y eficaz.

Vulnerabilidad CRÍTICA en Chrome

La vulnerabilidad descubierta por Michal Bentkowski fue reportada a finales de Mayo.

Sin dar a conocer ningun detalle técnico, el equipo de seguridad de Chrome ha descrito el problema como un manejo incorrecto del encabezado CSP (CVE-2018-6148) en su blog.

Para quien no lo conozca, el encabezado de la Política de Seguridad de Contenido (CSP) permite a los administradores de sitios web añadir una capa adicional de seguridad al permitirles controlar los recursos que el navegador puede cargar. 

El manejo incorrecto de estos encabezados por el navegador web podría volver a habilitar vulnerabilidades de tipo XSS, Clickjacking o de inyección de código en varias webs que securizaran su sitio con este encabezado.

Para los que no conozcan estos ataques, aquí tenéis algunas UAD escritas sobre ellos:
– XSS: https://unaaldia.hispasec.com/search?q=xss
– Clickjackinghttps://unaaldia.hispasec.com/search?q=clickjacking
 Inyección de código: https://unaaldia.hispasec.com/search?q=inyeccion

El parche para esta vulnerabilidad ya ha sido lanzado, por lo que todos los usuarios deben de asegurarse que su sistema está ejecutando la última version actualizada del navegador Chrome.

Más información:

Perfil de Twitter de Michal Bentkowski:
https://twitter.com/securitymb

Vulnerabilidad en el blog de Google:

Google Chrome corrige una vulnerabilidad crítica en su sandbox

Google Chrome ha actualizado su reciente versión 66 para corregir cuatro importantes vulnerabilidades, entre ellas una crítica que permitía tomar el control total del navegador saltándose las restricciones de la sandbox.
La actualización 66.0.3359.170, que ya está disponible para todos los sistemas operativos, corregiría las siguientes 4 vulnerabilidades:
  • Crítica: Vulnerabilidad por evasión de la sandbox, que permitiría ejecución remota de código.
  • Alta: Escalada de privilegios a través de las extensiones (CVE-2018-6121)
  • Alta: Denegación de servicio a través del motor V8 (CVE-2018-6122)
  • Alta: Denegación de servicio a través a través de PDFium (CVE-2018-6120)
Como siempre, y hasta que la mayoría de usuarios no hayan actualizado a esta versión, no se publicarán más datos sobre las vulnerabilidades.

Esta actualización está disponible a través de Chrome Update automáticamente en los equipos así configurados, o a través de “Información sobre Google Chrome” (chrome://chrome/).