Qué es el scripting entre sitios

En este enlace: http://www.acunetix.com/websitesecurity/cross-site-scripting/ bajo The Theory of XSS , dice: the hacker infects a legitimate web page with his malicious client-side script . 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 hacker tener acceso al código fuente de la página web? ¿O puede inyectar el script malicioso sin acceder al jsp de origen?

Con scripts de sitios cruzados, es posible infectar el documento HTML generado sin causar la infección del servidor web . Un ataque XSS usa el servidor como un vector para presentar contenido malicioso de nuevo a un cliente, ya sea instantáneamente desde la solicitud (un ataque reflejado) o retrasado a través del almacenamiento y la 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 aparezcan 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 rompen con el contenido de texto común e introducen 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 plantillas creado para producir una página HTML (como PHP, ASP, CGI o una secuencia de comandos Velocity o Freemarker). Toma la siguiente página y sustituye “< ? = $ Name?>” Con el valor no guardado del parámetro de consulta “nombre”.

  Example Hi, < ?=$name?>  

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 

Llamar a la misma página con algo más malicioso puede usarse para alterar sustancialmente la página o la experiencia del usuario.

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

En lugar de simplemente decir “Hola, Rumplestiltskin”, esta URL también provocaría que la página muestre un mensaje de alerta que diga “¡Abucheo!”. Es decir, por supuesto, un ejemplo simplista. Uno podría proporcionar una secuencia de comandos sofisticada que captura las pulsaciones de teclas o solicita que se verifique un nombre y una contraseña, o borra la pantalla y reescribe completamente la página con contenido de descarga. Todavía MIRARÍA como si viniera de example.com, porque la página en sí sí lo hizo, pero el CONTENIDO se proporciona en algún lugar de la solicitud y se refleja como parte de la página.

Por lo tanto, si la página simplemente está escupiendo contenido proporcionado por la persona que lo solicita y usted está solicitando esa página, ¿cómo infecta un hacker su solicitud? Por lo general, esto se logra al proporcionar un enlace, ya sea en una página web o enviado por correo electrónico, o en una solicitud abreviada de URL, por lo que es difícil ver el desorden en la URL.

  Click Me!  

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

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. Puede cambiar el parámetro de URL para que contenga tags de script.

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

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

Es mejor pensar que el guión está siendo inyectado en el medio de la conversación entre la página web mal codificada y el navegador web del cliente. En realidad no está inyectado en el código de la página web; sino más bien en la stream de datos que va al navegador web del cliente.

Hay dos tipos de ataques XSS:

  1. No persistente: esta sería una URL especialmente diseñada que integra un script como uno de los parámetros de 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 él. La página de destino maneja incorrectamente el parámetro y, involuntariamente, envía código a la máquina del cliente que se transfirió originalmente a través de la cadena URL.
  2. Persistente: este ataque usa 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 el apellido) que se ejecuta en el navegador web del cliente sin saberlo. Normalmente, el desagradable script se almacena en la base de datos y se vuelve a ejecutar en cada visita del cliente a la página infectada.

Consulte lo siguiente para obtener un ejemplo trivial: ¿Qué es el Cross-Site Scripting (XSS)?