Al navegar por la web, a veces nos saludamos con una ventana emergente después de visitar un sitio web. También hay una ventana emergente en nuestro sitio web por primera vez. Suponiendo que nuestro sistema pueda ser atacado por estas ventanas emergentes, es posible que ingresen cargas útiles maliciosas en nuestro sistema o que roben nuestros datos confidenciales.
Hoy en este artículo cubriremos el Secuencias de comandos entre sitios y también aprendemos cómo un atacante ejecuta código JavaScript malicioso en el campo de entrada y genera Pop-US para desfigurar la aplicación web o secuestrar la sesión del usuario.
JavaScript es uno de los lenguajes de programación más populares en la web, con más del 93% de los sitios web que utilizan JavaScript. Es muy flexible y fácil de mezclar con los códigos HTML.
Una página web HTML incrustada con JavaScript la mostrará mágicamente después de que la página web se haya cargado en el navegador. JavaScript usa algunas funciones para cargar un objeto en una página web. Funciones como onload, onmouseover, onclick, etc. Luego, la advertencia se muestra tal como está codificada. Por esta razón, las cargas útiles XSS siempre usan código JavaScript.
El cross-site scripting, también conocido como XSS, es un ataque de inyección de código del lado del cliente que permite a los atacantes ejecutar scripts maliciosos en sitios web confiables. Todos los sitios web no son susceptibles a XSS, solo se verán afectados aquellos sitios web o aplicaciones web para los que los parámetros de entrada no se hayan validado correctamente. Desde allí, los atacantes pueden enviar código JavaScript malicioso y el usuario de la aplicación web no tiene forma de saber que está cargando scripts del atacante. Por eso XSS es demasiado peligroso.
¿Confundido con lo que estamos hablando? ¿No te gusta demasiada teoría? Vayamos a ejemplos prácticos. Antes de hacer esto, debemos saber que existen principalmente tres tipos de XSS, y son los siguientes:
- XSS guardado
- XSS reflejado
- XSS basado en DOM
El «XSS almacenado» también se conoce como «XSS de persistencia» o «Tipo I», como podemos deducir por el nombre que se almacena, es decir, los códigos JavaScript maliciosos del atacante se «almacenan» en la base de datos de las aplicaciones web y el servidor lo borra aún más cuando el cliente visita el sitio web en particular.
Dado que esto se hace de una manera muy legítima, como cuando el cliente / usuario hace clic o se desplaza sobre una determinada sección infectada, el navegador ejecutará el código JavaScript malicioso que se inyecta, ya que ya se ha almacenado en la base de datos de la aplicación web. . Debido a esto, este ataque no requiere una técnica de phishing para atrapar al usuario.
El ejemplo más común de «XSS almacenado» es la sección de comentarios de los sitios web, que permite a cualquier usuario publicar su comentario como en el formulario de comentarios. Ahora veamos un ejemplo:
Una aplicación web pide a los usuarios que proporcionen sus comentarios. En la siguiente captura de pantalla podemos ver los dos campos, uno para el nombre y otro para el comentario.
Si ahora llenamos el formulario y hacemos clic en «Entrar en el libro de visitas«para dejar nuestros comentarios, nuestra entrada se guarda en la base de datos. Podemos ver el área de la base de datos resaltada en la siguiente captura de pantalla:
En este caso, el desarrollador confía en nosotros y no ingresó un validador en los campos, o se olvidó de agregar validadores. Entonces, si un atacante encuentra esta laguna, el atacante puede explotarla. Sin publicar el comentario en el área de mensajes, el atacante podría ejecutar un script malicioso. El siguiente script se utiliza como ejemplo:
Si pegamos el código JavaScript en la sección "Mensaje", podemos ver que la aplicación web muestra un aviso de advertencia.
In the database section we can see that the database has been updated with name, but the message section is empty.
Esta es una clara indicación de que nuestro script / atacante se inyectó con éxito.
Ahora, verifiquemos si realmente se envió a la base de datos o no. Abrimos otro navegador (Chrome) e intentamos dar comentarios reales.
Aquí cuando nosotrosEntrar en el libro de visitasBotón, este navegador ejecuta el script inyectado, como podemos ver en la siguiente captura de pantalla:
Podemos ver que esto también refleja nuestro script insertado, ya que ha almacenado nuestra entrada en la base de datos. Este es el XSS almacenado.
El XSS reflejado también se conoce como "XSS de no persistencia" o "Tipo II". Si la aplicación web responde inmediatamente a la entrada del cliente sin verificar lo que el cliente escribió, podría permitir que un atacante inserte código ejecutable del navegador malicioso en la respuesta HTML individual. Esto también se conoce como "no persistencia" porque el script malicioso no se almacena en la base de datos de la aplicación web. Por esta razón, el atacante tiene que hacer phishing del enlace malicioso para interceptar al cliente.
XSS reflejado es el más común y se puede encontrar fácilmente en el "Campos de búsqueda de sitios web"donde el atacante puso un código JavaScript malicioso en el cuadro de texto / búsqueda y, si el sitio web es vulnerable, el sitio web devuelve el evento descrito en el script.
Existen principalmente dos tipos de XSS reflejados:
- XSS reflejado GET
- POST XSS reflejado
Repasemos el concepto de XSS reflejado. Necesitamos verificar el siguiente escenario:
Aquí tenemos un sitio web donde podemos ingresar y enviar nuestro nombre. Entonces, cuando ingresamos nuestro nombre y lo enviamos. Aparecerá un mensaje en la pantalla que nos saluda.
Si miramos la URL, vemos que "Apellido"El parámetro en la URL indica que los datos se solicitaron mediante el método GET.
Ahora vamos a intentar generar algunas ventanas emergentes poniendo código JavaScript en esta.Apellido"Parámetro como:
Necesitamos pegar este script en la URL donde estaba nuestro nombre.
Now we can see that our JavaScript code is executed as an alert in the following screenshot:
De hecho, el desarrollador no configuró ninguna validación de entrada para la función, y nuestras entradas simplemente obtienen "eco".
Este es un ejemplo de XSS reflejado utilizando el método GET. Para el método XSS-POST reflejado, no podemos ver la solicitud en la URL. En este caso tenemos que usar Suite para eructar o WebScarab como herramientas para modificar la solicitud e insertar nuestros códigos JavaScript.
XSS basado en DOM es el punto débil que aparece en un modelo de objetos de documento y no en las páginas HTML. Pero antes de eso, necesitamos saber qué es Document Object Model.
DOM o Document Object Model describe los diversos segmentos del sitio web, tales como: títulos, encabezados, formularios, tablas, etc. e incluso la estructura jerárquica de una página HTML. Esto se debe a que esta API aumenta la capacidad de los desarrolladores para crear y modificar documentos HTML y XML como objetos de programación.
Cuando un documento HTML se carga en un navegador web, se convierte en un "objeto de documento".
Las vulnerabilidades XSS basadas en DOM generalmente ocurren cuando JavaScript toma datos de una fuente controlable por el atacante, como la URL, y los pasa a un receptor (una función peligrosa de JavaScript o un objeto DOM como eval ()) que ejecuta dinámicamente los soportes de código.
Este ataque se diferencia de los ataques XSS almacenados y reflejados en que los desarrolladores no pueden encontrar el script peligroso en este ataque ni en el código fuente HTML ni en la respuesta HTML, pero solo se puede observar durante la ejecución. No entendido bien, veamos un ejemplo de XSS basado en DOM.
La siguiente aplicación nos permite elegir un idioma que se muestra en la siguiente captura de pantalla:
Si elegimos nuestro idioma lo podemos ver en la url. Al igual que con el anterior (Reflected XSS GET) podemos manipular la URL para obtener la advertencia.
Entonces, si intentamos cambiar el idioma, podemos ver:
After the language we put a '#', this is the major diffrence between DOM-BAsed XSS and Reflected or Stored XSS is that it can't be stopped by server-side filters because anything written after the '#' (hash) will never forward to the server.
Haha 😂, what the hell if we get an alert by doing these kind of stuffs, just this? nothing else? We click on the OK button and the pop-up alert is vanishing.
Wait, the pop-up speaks about a lot words. Let's go back to the the first place, "We've come a long way from where we began". Back to the Stored XSS section.
Here, in the stored XSS section, we know that our input is stored on the database of the web-application. In our previous example we created just an alert but we can do much more then it. For an example if we put any name in the name field and put the following JavaScript code on the message field.
Y capturamos la cookie como podemos ver en la siguiente captura de pantalla:
Si ahora salimos de esta página en un navegador diferente y luego regresamos a la página XSS guardada, nuestro código debería ejecutarse nuevamente y mostrar una ventana emergente con la cookie para la sesión actual. Esto se puede ampliar mucho y, con un poco más de conocimiento de JavaScript, un atacante puede hacer mucho daño.
Para obtener más información sobre la explotación XSS, podemos repasar este documentación oficial de PortSwigger, eso está bien escrito.
Como expertos en ciberseguridad, intentamos encontrar errores en varios servicios, no solo que sea nuestro trabajo corregirlos o dar una idea para solucionarlos. Evitar las secuencias de comandos entre sitios, o XSS, a veces es trivial, pero puede ser mucho más difícil debido a la complejidad de la aplicación y la forma en que procesa la información que es controlable por el cliente.
Por lo general, podemos detener XSS usando la siguiente guía:
- Verifique la entrada del usuario. En el punto donde se recibe la entrada del usuario, filtre lo más estrictamente posible según la entrada esperada o válida.
- Codifique los datos a medida que salen del servidor. Si se devuelven datos controlables por el usuario en respuestas HTTP, debemos codificar la salida para evitar que se interprete como contenido activo. Dependiendo del contexto de salida, es posible que sea necesario utilizar combinaciones de codificación HTML, URL, JavaScript y CSS.
- Utilice encabezados de respuesta adecuados. Para detener XSS en respuestas HTTP que no deben contener HTML o JavaScript, podemos usar el Tipo de contenido y Opciones de tipo de contenido X Encabezados para asegurarse de que los navegadores interpreten las respuestas como pretendíamos.
- Política de seguridad de contenido. Como última línea de defensa, podemos utilizar la Política de seguridad de contenido (CSP) para reducir la gravedad de las vulnerabilidades XSS que aún puedan surgir.
Hay innumerables otros artículos sobre esto que podemos obtener de Internet. Encontramos un artículo muy detallado sobre Prevención de XSS Ataques.
¿Te encantan nuestros artículos? Asegúrate de eso Síguenos en Gorjeo y GitHub, publicamos actualizaciones de artículos allí. A unirse a nosotros KaliLinuxIn Familia ven a nosotros Grupo de telegramas. Estamos tratando de construir una comunidad para Linux y ciberseguridad. Siempre estamos felices de ayudar a todos en el como sección. Como sabemos, nuestra sección de comentarios siempre está abierta a todos. Leemos cada comentario y siempre respondemos.
