tag script language have defer async security xss

security - language - ¿Qué es el script de sitio cruzado



script tag module (4)

En este sitio ( instantánea archivada ) bajo "La teoría de XSS", dice:

el hacker infecta una página web legítima con su script malicioso del lado del cliente

Mi primera pregunta al leer esto es: si la aplicación se implementa en un servidor que es seguro (como es el caso de un banco, por ejemplo), ¿cómo puede el pirata informático acceder al código fuente de la página web? ¿O puede inyectar el script malicioso sin acceder al código fuente?

Con las secuencias de comandos entre sitios, es posible infectar el documento HTML producido sin que el propio servidor web se infecte. Un ataque XSS usa el servidor como un vector para presentar el contenido malicioso a un cliente, ya sea instantáneamente desde la solicitud (un ataque reflejado) o retrasado a través del almacenamiento y recuperación (un ataque almacenado).

Un ataque XSS explota una debilidad en la producción del servidor de una página que permite que los datos de solicitud se muestren sin formato en la respuesta. La página solo refleja lo que se envió en una solicitud ... pero el contenido de esa solicitud puede contener caracteres que se separan del contenido de texto ordinario e introduce contenido HTML o javascript que el desarrollador no pretendía.

Aquí hay un ejemplo rápido. Supongamos que tiene algún tipo de lenguaje de plantilla creado para producir una página HTML (como PHP, ASP, CGI o un script de Velocity o Freemarker). Toma la siguiente página y sustituye "<? = $ Nombre?>" Con el valor no escapado del parámetro de consulta "nombre".

<html> <head><title>Example</title></head> <body>Hi, <?=$name?></body> </html>

Alguien que llama a esa página con la siguiente URL:

http://example.com/unsafepage?name=Rumplestiltskin

Debería esperar ver este mensaje:

Hi, Rumplestiltskin

Se puede usar llamar a la misma página con algo más malicioso para alterar sustancialmente la experiencia de la página o del usuario.

http://example.com/unsafepage?name=Rumplestiltskin<script>alert(''Boo!'')</script>

En lugar de solo decir "Hola, Rumplestiltskin", esta URL también hará que la página muestre un mensaje de alerta que dice "¡Boo!". Eso es, por supuesto, un ejemplo simplista. Uno podría proporcionar un script sofisticado que capture las pulsaciones de teclas o solicite que se verifique un nombre y una contraseña, o que borre la pantalla y que vuelva a escribir la página por completo con el contenido del shock. Aún se vería como si proviniera de example.com, porque la página sí, pero el CONTENIDO se proporciona en algún lugar de la solicitud y se refleja como parte de la página.

Entonces, si la página solo está devolviendo contenido proporcionado por la persona que lo solicita, y usted está solicitando esa página, ¿cómo un pirata informático infecta SU solicitud? Por lo general, esto se logra proporcionando un enlace, ya sea en una página web o por correo electrónico, o en una solicitud acortada de URL, por lo que es difícil ver el desorden en la URL.

<a href="http://example.com?name=<script>alert(''Malicious content'')</script>"> Click Me! </a>

Un servidor con una vulnerabilidad XSS explotable no ejecuta ningún código malicioso en sí mismo, su programación permanece inalterada, pero se puede hacer que sirva contenido malicioso para los clientes.

Es mejor pensar que el script se inyecta en medio de la conversación entre la página web mal codificada y el navegador web del cliente. No está realmente inyectado en el código de la página web; sino más bien en el flujo de datos que van al navegador web del cliente.

Hay dos tipos de ataques XSS:

  1. No persistente: esta sería una URL especialmente diseñada que incrusta un script como uno de los parámetros en la página de destino. La URL desagradable se puede enviar en un correo electrónico con la intención de engañar al destinatario para que haga clic en ella. La página de destino maneja mal el parámetro y envía involuntariamente un código a la máquina del cliente que se pasó originalmente a través de la cadena de URL.
  2. Persistente: este ataque utiliza una página en un sitio que guarda los datos del formulario en la base de datos sin manejar los datos de entrada correctamente. Un usuario malintencionado puede incrustar un script desagradable como parte de un campo de datos típico (como Apellido) que se ejecuta en el navegador web del cliente sin saberlo. Normalmente, el script desagradable se almacenaría en la base de datos y se volvería a ejecutar en la visita de cada cliente a la página infectada.

Vea lo siguiente para ver un ejemplo trivial: ¿Qué es la creación de secuencias de comandos entre sitios (XSS)?

Ese atacante no necesita acceso al código fuente.

Un ejemplo simple sería un parámetro de URL que se escribe en la página. Podría cambiar el parámetro de URL para que contenga etiquetas de script.

Otro ejemplo es un sistema de comentarios. Si el sitio web no limpia correctamente la entrada / salida, un atacante podría agregar un script a un comentario, que luego se mostraría y ejecutaría en las computadoras de cualquiera que haya visto el comentario.

Estos son ejemplos simples. Hay mucho más que eso y muchos tipos diferentes de ataques XSS.