Ya sé que es un poco tarde, pero hoy he visto El Hobbit. Y sí, la película me ha resultado entretenida, he visto la recreación de un libro divertido en la pequeña pantalla que alguien se ha encargado de transformar en un guión de tres horas para la primera parte de una trilogía. Perdónenme los fanáticos de Tolkien, pero yo jamás pude imaginar que un libro como El Hobbit diese para una trilogía de tres horas cada película.

Y esa misma sensación es la que muchas veces me he encontrado en mi experiencia profesional cuando he tenido que abordar proyectos de seguridad que únicamente tienen en cuenta la fase de la auditoría lógica.

[Read more…]

(N.d.E. Después de una semana menos activa de lo habitual, volvemos a la carga al menos hasta que el turrón haga acto de presencia de forma oficial)

En los últimos años las redes sociales se han extendido de forma masiva y ya resulta extraño encontrar personas que no hagan uso de estos servicios de forma habitual, eso sí, debo reconocer que yo soy uno de ellos y que únicamente tengo mi cuenta para mi comunidad de vecinos, por lo que seguro que cualquiera de ustedes sabe más de las redes sociales que yo mismo.

Sin embargo, lo que sí tengo claro es que mucha de nuestra información se encuentra disponible en estas redes y en muchos casos a la vista de mirones no deseados, aspecto que ya se ha tratado numerosas veces en entradas anteriores y en las que no voy a entrar en esta entrada. Lo que sí me gustaría hacer es aprovechar este post para felicitar a Facebook, la red social más conocida y utilizada, por su iniciativa de organizar la primera hacker cup, una competición dotada con 5000$ en un único premio, que intentará reunir a personas interesadas en la seguridad de todo el mundo. La competición se encuentra dividida en 4 fases, las 3 primeras online y la última en las oficinas de Facebook ubicadas en Palo Alto (California, EEUU) donde se encontraran los 25 mejores clasificados; esperemos que se encarguen ellos de pagar el viaje.

La primera prueba consistirá en una ronda de clasificación de 72 horas, que da comienzo el Viernes 07 de enero de 2011 a las 16:00h, horario de España, en la que se presentarán tres problemas, de los cuales al menos habrá que conseguir resolver uno para poder clasificarse para la siguiente ronda. Poco más se sabe de la competición, así que sólo queda esperar al próximo 20 de Diciembre para que se abra la inscripción y ver cómo se desarrolla.

A mí ya me han convencido para dedicarle algún tiempo a este tipo de redes, ¿nos vemos en California?

Llegamos con esta entrada al ecuador de la lista de OWASP, tras el repaso a las cuatro primeras vistas en entradas anteriores (I, II, III, IV). En esta ocasión, el artículo del top 10 del catálogo de vulnerabilidades de OWASP del año 2010 se basa en el riesgo conocido como Cross Site Request Forgery, CSRF, que en castellano tiene la difícil traducción que podemos leer en el título de esta entrada. Este riesgo no aparecía recogido en la lista del año 2004, sin embargo en 2007 apareció en quinto lugar, posición que mantiene en esta nueva clasificación de riesgos del año 2010.

Las vulnerabilidades relacionadas con la falsificación de petición en sitios cruzados permiten a un atacante la posibilidad de enviar una petición a una aplicación Web vulnerable ejecutando una acción a través de la víctima. Veamos el siguiente ejemplo como demostración del tipo de situaciones en las que podemos encontrar un ataque de este tipo. Sea una aplicación que dispone de un frontal web, en el que un usuario autenticado dispone de un conjunto de puntos bonificables que puede transferir a otros usuarios de la propia aplicación a través de un formulario que ejecuta una acción del siguiente tipo:

Una vez recibida en el servidor, se le muestra la cantidad a transferir, el identificador del usuario y realiza el traspaso de puntos.
[Read more…]

Si recuerdan el post sobre XSS de la serie que explica las vulnerabilidades TOP 10 en aplicaciones web de OWASP de este año, en éste les comentábamos los potenciales problemas de seguridad que podían enmascararse con el uso de los extendidos servicios de reducción de tamaño en las URL. Si todavía hoy alguien no los conoce, estos servicios se encargan de reducir el tamaño de una URL determinada a una nueva URL con una longitud predeterminada e inferior, en la que se mapea el enlace de forma que pueda ser utilizado en servicios como twitter que tienen un número limitado de caracteres; el incremento de popularidad de esta “nueva” red social ha hecho que este tipo de servicios se multipliquen como las setas. De esta manera, se facilita el incorporar enlaces largos en entradas de este tipo de servicios.

A modo de ejemplo, una url del tipo:

Se traduce con uno de estos servicios en:

[Read more…]

En esta ocasión, el cuarto artículo del top 10 del catálogo de vulnerabilidades de OWASP del año 2010 se basa en la vulnerabilidad conocida como referencia directa a objetos insegura. Anteriormente ya vimos los ataques relacionados con las vulnerabilidades XSS, de Inyección y de Robo de sesiones web.

La vulnerabilidad que les presentamos hoy no aparecía recogida en la lista del año 2004 puesto que se encontraba agrupada dentro de la categoría “Error de Controles de Acceso”, sin embargo en 2007 se tomó la decisión de separar dicha categoría por la importancia detectada en este tipo de vulnerabilidades, pasando a ocupar el cuarto lugar en la clasificación. En la nueva clasificación que estamos presentando continua siendo una de las vulnerabilidades más encontradas permaneciendo en la misma posición que en 2007, es decir, en cuarta posición.

Las vulnerabilidades relacionadas con la referencia directa a objetos permiten a un atacante la posibilidad de obtener manipular referencias internas de la aplicación para acceder a objetos sin autorización. Es decir, la aplicación desarrollada que es vulnerable a este tipo de ataques permite el acceso a ficheros, directorios o registros de la base de datos a partir, entre otros, de un enlace a una URL o a un parámetro en un formulario.

Veamos el siguiente ejemplo como demostración del tipo de situaciones en las que podemos encontrar un ataque de este tipo. Sea una aplicación que dispone de un frontal web en el que un usuario autenticado puede consultar una serie de artículos de una determinada categoría. Desde la página de cada artículo puede acceder a un documento en el que se encuentra un enlace para descargar las especificaciones de éste con una URL del tipo:

Una vez recibida en el servidor, obtiene el documento componiendo la ruta al fichero a partir de los parámetros enviados y se lo devuelve el fichero para que el usuario lo pueda descargar a su ordenador.
Un atacante de nuestra plataforma podría modificar la petición esperada que provocase que retornase cualquier fichero de configuración de la aplicación o del sistema operativo, por ejemplo, el fichero de conexión con la base de datos o el fichero de usuarios y contraseñas de la máquina que aloja este servicio (por utilizar un ejemplo clásico):

Para que esta vulnerabilidad sea efectiva, es necesario que la composición de la ruta al fichero se realice en el servidor sin realizar ningún tipo de comprobación respecto al nombre del documento que se desea descargar o la ruta a la cual se está accediendo.

Existe una variante de este tipo de vulnerabilidad que puede comprometer los mecanismos de seguridad de acceso a los datos de nuestra aplicación. Supongamos que nuestra aplicación de catálogo tiene definidos diferentes fabricantes que sólo permiten el acceso a sus especificaciones a los usuarios autenticados de su propia empresa. Estas especificaciones se muestran en modo de lista y se puede descargar cada una de ellas pulsando sobre su nombre obteniendo el fichero a partir de una URL semejante a la siguiente:

Un atacante de nuestra plataforma podría averiguar esta petición y obtener el fichero en cuestión independientemente de sus permisos puesto que este fichero se está publicando directamente en el servidor de aplicaciones, y únicamente la lógica de negocio es la que protege la disponibilidad de acceso a la información. Del mismo modo, supongamos que nuestra aplicación permite acceder a una pantalla en la que se visualizan los datos personales del usuario y desde ahí es posible la realización de modificaciones de esta información a través de una URL del tipo:

Una vez recibida en el servidor, obtiene la información del usuario y la presenta para su consulta y modificación en caso de ser necesario. Un atacante de nuestra plataforma podría modificar la petición esperada que provocase que retornase la información de cualquier otro usuario de la aplicación, vulnerando de esta manera la privacidad de la información y las reglas de negocio de la aplicación.

Con el fin de evitar que nuestras aplicaciones sean vulnerables a este tipo de ataque se debe evitar, en la medida de lo posible, la presentación al usuario de referencias directas a estos objetos. En caso de que no sea posible realizar esta modificación se deberán incorporar los mecanismos de seguridad necesarios para garantizar que dicho usuario dispone de permisos para acceder al recurso solicitado.
De esta forma, si se desea ofrecer acceso a un fichero, será más seguro realizarlo a través de una clave intermedia que permita garantizar que el usuario que intenta acceder al recurso dispone de los permisos suficientes, así como evitar la publicación directa de recursos a través del acceso directo mediante una URL que pueda ser predicha.

Y hasta aquí todo lo referente a las vulnerabilidades de referencia directa a objetos insegura, de momento. Como les hemos insistido en entradas anteriores, si quieren extenderse en la materia, más allá de los innumerables recursos de la red, pueden acudir a la web de OWASP, donde encontrarán mucha información de utilidad. Si desean que demos más detalles sobre alguna de las vulnerabilidades mostradas, no les ha quedado clara la explicación, o les gustaría que entrásemos más en profundidad, no tienen más que indicarlo en los comentarios y estaremos encantados de ampliar la información.

Tras los dos artículos previos sobre el TOP 10 de OWASP, en esta ocasión el artículo del top 10 del catálogo de vulnerabilidades de OWASP del año 2010 se basa en la vulnerabilidad conocida como pérdida de autenticación y gestión de sesiones. Esta vulnerabilidad, desde mi punto de vista, demuestra lo poco que suele preocupar la seguridad a los usuarios. Aunque en la primera clasificación del año 2004 estaba situada como la tercera más encontrada, en la clasificación el año 2007 destacaba por haber descendido hasta el séptimo puesto. Sin embargo, tres años después, en esta nueva clasificación, se vuelve a observar un repunte en la localización de este tipo de vulnerabilidades que la vuelve a colocar en la tercera posición dejando como anécdota la anterior mejora.

Las vulnerabilidades relacionadas con la pérdida de autenticación y gestión de sesiones son críticas en la seguridad de las aplicaciones y en especial de las aplicaciones WEB, ya que permiten a un atacante suplantar la información de un determinado usuario, pudiendo llegar a obtener una cuenta de administración que le permita sabotear los controles de autorización y registro de la aplicación. Esta situación podría ocasionar un acceso no autorizado a cualquier tipo de información que se encuentre almacenada en el servidor o los servicios que han sido comprometidos.

Existen multitud de situaciones en las que nos podemos encontrar ante una aplicación vulnerable a este tipo de ataque, pero la mayor parte de las veces se encuentran en la gestión de las contraseñas, la expiración de sesiones o el proceso de cierre de sesión. Además, debe prestarse especial atención a las procesos que permiten la recuperación de los valores del usuario de forma automática como pueden ser los servicios de pregunta secreta, de actualización de cuenta o de “Recordar contraseña”.

De nuevo, igual que ocurría en la vulnerabilidad explicada en el primer post de la serie de inyecciones, hay multitud de ejemplos que podrían demostrar el uso de esta vulnerabilidad, por lo que vamos a introducir únicamente un grupo reducido de ejemplos que permitan ilustrar la situación, y en caso de que sea necesaria alguna aclaración sobre cualquiera de los aspectos no considerados esperamos que nos lo hagan saber a través de los comentarios.

Veamos el siguiente ejemplo como demostración del tipo de situaciones en las que podemos encontrar un ataque de este tipo: sea una aplicación que dispone de un frontal web en el que un usuario autenticado puede consultar una serie de artículos de una determinada categoría. Navegando por cada uno de los artículos accede a uno que le interesa y que quiere compartir con sus amigos, por lo que accede a la url que tiene en su navegador del tipo:

A continuación cierra su navegador y postea en una red social este enlace para que todos puedan acceder a este curioso artículo. Como el servidor en el que se encuentra el artículo no cierra la sesión del usuario salvo que sea por petición de éste, cualquiera de sus “amigos” que acceda a dicho enlace aparecerá registrado en la aplicación como el usuario autenticado con el consecuente acceso a sus datos.

Del mismo modo, es posible encontrar un ejemplo de autenticación realizada a través de medios no confiables. Pensemos que esta misma aplicación utiliza un servicio de autenticación seguro a través de https. De esta forma, la comunicación viaja cifrada y no es posible interceptar el tráfico para capturar la contraseña del usuario. Como sucede en muchas páginas, el proceso de autenticación proporciona la posibilidad de “recordar” al usuario al marcar un check, de forma que se almacena en local una cookie de la página con el nombre de usuario y contraseña introducidos en el formulario de autenticación.

Aunque durante el proceso de autenticación manual el servicio utiliza una configuración segura a través de https, el proceso de autenticación automático utiliza una configuración a través de http.

En este momento, cualquier atacante de la aplicación que se encuentre controlando el tráfico que intenta acceder la aplicación de catálogo dispondrá del nombre de usuario y su contraseña por no haber utilizado un sistema de comunicación seguro.

Existen diferentes formas de proteger la aplicación desarrollada de este tipo de vulnerabilidades, pero requieren decisiones a nivel de diseño. En primer lugar, la gestión de contraseñas nunca puede almacenarse en texto plano, aspecto que aunque a ustedes les parezca obvio, es más común de lo que piensan. Esto provocaría que un atacante que tuviese acceso a la tabla o al fichero en el que se almacena la información de los usuarios tendría automáticamente acceso a cualquier recurso de la aplicación que desease, independientemente de las medidas de control que pudiésemos plantear. Además, deben utilizarse los servicios que utilicen información sensible a través de canales seguros, como puede ser una conexión sobre SSL, de forma que se evite la posibilidad de que un atacante se interponga en la comunicación de esta información entre nuestro cliente y el servidor de la aplicación de datos.

Por último, una serie de indicaciones generales sobre la forma de gestionar las sesiones:

• Añadir la comunicación cifrada en en el proceso de acceso a la aplicación.
• Eliminar, en la medida de lo posible, la utilización de mecanismos de autenticación del tipo “Recordar Contraseña” puesto que, generalmente, esta contraseña se almacena para poder ser utilizada y la sustracción de ésta valor podría ocasionar la suplantación de usuarios. Por supuesto, en este punto entramos en el equilibrio entre seguridad y funcionalidad.
• Ofrecer un enlace en todas las páginas de la aplicación para que el usuario pueda cerrar la sesión.
• Gestionar de forma adecuada la caducidad de las sesiones ante un período de inactividad.
• Gestionar de forma adecuada el tratamiento de la información cuando se introduzca un identificador de sesión caducado o no válido.

Y hasta aquí todo lo referente a las vulnerabilidades de pérdida de autenticación y gestión de Sesiones, de momento. Como saben, si quieren extenderse en la materia, más allá de los innumerables recursos de la red, pueden acudir a la web de OWASP, donde encontrarán mucha información de utilidad. Como siempre, si tienen interés en que demos más detalles sobre alguna de las vulnerabilidades mostradas, o no les ha quedado clara la explicación, no tienen más que indicarlo en los comentarios y estaremos encantados de ampliar la información.

En esta ocasión, el artículo sobre el TOP 10 del catálogo de vulnerabilidades de OWASP del año 2010 se basa en la vulnerabilidad conocida como XSS, cuyas siglas en inglés se traducen como Cross Site Scripting. Por si alguien se lo está preguntando, la X es realmente una cruz y de ahí lo de Cross, ya que tuvieron que buscarle unas siglas que no pudieran confundir con CSS, Cascade Style Sheet. La nomenclatura es la misma que en Xing, la red social de profesionales, por lo que si alguna vez hay que pronunciarlo: será mejor hacerlo como crossing.

Pero dejemos las siglas para otro post y centrémonos en el XSS. Esta vulnerabilidad ha estado presente en las tres clasificaciones de OWASP. En el 2004 se consideró la cuarta vulnerabilidad más encontrada, en 2007 se posicionó en la primera posición de esta clasificación y en esta nueva versión del 2010 continúa en la parte alta ocupando la segunda posición, únicamente superada por la Inyección, que ya vimos en el anterior post de la serie.

Las vulnerabilidades de XSS son explotadas cuando una aplicación obtiene datos de cualquier fuente y los envía al navegador del usuario sin realizar una validación previa de los datos. Este tipo de vulnerabilidades permiten a un atacante ejecutar código arbitrario en el navegador del usuario permitiendo el robo de sesiones, defacement de páginas web (¿se acuerdan de Mr. Bean en la página de la presidencia de turno del Gobierno?), o incluir código malicioso de páginas no confiables por el usuario en otras que sí lo son.

Existen tres situaciones en las que nos podemos encontrar ante una aplicación vulnerable a ataques XSS:

• Utilizando los parámetros que se envían a través de una URL,
• utilizando información almacenada en el back end de datos del servidor y
• utilizando el propio objeto DOM que representa la página web que se está visualizando.

Veamos el siguiente ejemplo como demostración del tipo de situaciones en las que podemos encontrar un ataque de XSS a través de una URL. Sea una aplicación que dispone de un frontal web en el que se muestra un formulario. Al seleccionar el usuario una determinada categoría, pulsa el botón de buscar y le aparece el conjunto de artículos que contiene dicha categoría. Al pulsar sobre “Seleccionar”, se envía una petición al servidor del tipo:

Una vez recibida en el servidor, obtiene el listado de artículos y devuelve la información, así como el identificador de la categoría que quedará almacenado en un input oculto para su posterior utilización de la forma:

<input type='hidden' name='category' id='category' value='<%=request.getParameter(“id”)'/>

Un atacante de nuestra plataforma podría modificar la petición esperada que provocase que no se retornará ningún artículo de la categoría pero le permitiese, por ejemplo, recuperar la cookie de sesión del usuario y realizar cualquier acción que considere oportuna:

Para que esta vulnerabilidad sea efectiva y el usuario pueda ser atacado es necesario engañarlo, por ejemplo a través de un correo en el que se solicita que pulse un determinado enlace que visualmente apunta a una página “segura” en la que se ofuscan los parámetros que pueden ocasionar la vulnerabilidad. Si no conocían esta vulnerabilidad, es posible que a partir de hoy le tengan tanto respeto como yo a los acortadores de URL tipo http://bit.ly/9Uc1S4 o http://tinyurl.com/382hyoz, pero esto ya lo trataremos en otro post.

Del mismo modo, es posible mostrar un ejemplo de vulnerabilidad de XSS basada en el árbol DOM que representa la página web que está visualizando el usuario. Sea una aplicación que permite la selección de lenguaje a través de un parámetro con el siguiente aspecto:

Seleccione su idioma:

<select>
   <script>
	document.write(“<option value=1></option>”);
	document.write(“<option value=2>”+
		document.location.href.substring(document.location.href.indexOf(“lang=”)+8
		+”</option>”);
	document.write(“<option value=3>English</option>”);
   </script>
</select>

Al seleccionar se envía una petición al servidor del tipo:

Un atacante de nuestra plataforma podría modificar la petición esperada que provocase que no se realizase un cambio en el lenguaje de la interfaz pero le permitiese, de nuevo, recuperar la cookie de sesión del usuario y realizar cualquier acción que considere oportuna:

Sin aprovechar ningún problema de validación en el servidor que recibe la petición ésta se transforma en un alert con la cookie del usuario en pantalla.

Por último, es posible aprovechar vulnerabilidades XSS permanentes procedentes del back end de datos del servidor de la aplicación, siendo esto posible si un mal diseño ha permitido a un usuario incorporar estos valores a través de la propia aplicación o mediante la explotación de alguna vulnerabilidad, por ejemplo las de inyección explicadas en el post anterior de la serie. De nuevo utilizamos el mismo ejemplo que desea obtener el listado de artículos de una categoría y las representa en una tabla con id, nombre y precio con una petición del tipo:

Supongamos que la tabla la compone directamente el back end del servidor en Java de la forma:

List<article> articles = proxyCategory.getArticles(id);
StringBuffer sbItem = new StringBuffer(“<table>”);
for (Article article : articles) {
	sbItem.append(“<tr><td>”).
	.append(article.getId())
	.append(“</td><td>”).
	.append(article.getDescription())
	.append(“</td><td>”)
	.append(article.getPrice())
	.append(“</td></tr>”);
} 
sbItem.append(“</table>”)

Si la información almacenada en el back end ha sido comprometida, será posible que en el campo descripción, suponiendo que éste sea el único campo de tipo alfanumérico, se puedan incorporar datos maliciosos que puedan ocasionar una pérdida de información en la interfaz del cliente, de la misma forma explicada en los anteriores ejemplos. Para que esta vulnerabilidad sea efectiva y el usuario pueda ser atacado ya no es necesario engañarlo sino que la propia infraestructura del servidor al que se conecta es la que ha sido comprometida.

Al igual que en la entrada anterior, hemos realizado la muestra de vulnerabilidades a través de peticiones GET, siendo extensible a las peticiones POST sin que los ejemplos se vean alterados. Del mismo modo, estas vulnerabilidades son independientes del lenguaje utilizado en el servidor.

Aunque la primera manera de protegerse pueda considerarse eliminar por completo el uso de javascript en la página con plugins del tipo NoScript, siempre existirán páginas en las que confiaremos y para las que habilitaremos el uso de esta tecnología. Es por tanto necesario, desde el punto de vista del programador, incorporar los controles necesarios en la programación del servidor para mitigar y eliminar este tipo de vulnerabilidades. El resto de aspectos son similares a los que comentamos la última vez: es fundamental sanear las entradas: si el valor esperado es un número, que sólo pueda ser tratado un número, si es una cadena de texto, se deben validar que los caracteres incluidos sólo puedan contener caracteres válidos. En caso de que la aplicación desarrollada deba permitir el uso de caracteres especiales, se deberá tratar con especial atención esta información y garantizar que la información que se está tratando es adecuada antes de aceptar los datos.

Y hasta aquí todo lo referente a ataques de XSS, de momento. Como saben, si quieren extenderse en la materia, más allá de los innumerables recursos de la red, pueden acudir a la web de OWASP, donde encontrarán mucha información de utilidad. Si desean que demos más detalles sobre alguna de las vulnerabilidades mostradas, o no les ha quedado clara la explicación, no tienen más que indicarlo en los comentarios y estaremos encantados de ampliar la información.

Si recuerdan el post que publicamos hace poco más de una semana titulado OWASP Top 10 2010. Release Candidate, éste iniciaba una serie de entradas a través de las que pretendemos mostrar en qué consiste cada una de las vulnerabilidades que forman el TOP 10 de OWASP, así como ofrecer algunas indicaciones y recomendaciones sobre la mejor forma de evitar que nuestras aplicaciones sufran estas conocidas vulnerabilidades. Con algo de retraso sobre la fecha prevista, he aquí el primero.

La vulnerabilidad más comúnmente explotada desde el año 2004 que OWASP lleva realizando esta clasificación es la inyección. Aunque la más común sea probablemente la Inyección de SQL, existen otros tipos de inyecciones que es posible que no nos resulten tan familiares: LDAP, XPath, XSLT, XML, OS injection, etc., y que al igual que la Inyección SQL se aprovechan de la sintaxis del interprete que se va a encargar de ejecutar una determinada acción. Las vulnerabilidad de inyección pueden permiten a un atacante obtener cualquier tipo de información disponible en la aplicación, pudiendo llegar a comprometer totalmente la aplicación, así como los sistemas relacionados con ésta. Y ya saben que de ahí al infinito y más allá.

Veamos el siguiente ejemplo como demostración del tipo de situaciones en los que podemos encontrar una inyección SQL. Sea una aplicación que dispone de un frontal web en el que se muestra un formulario. Al seleccionar el usuario una determinada categoría, pulsa el botón de buscar y le aparece el conjunto de artículos que contiene dicha categoría. Al pulsar sobre “Seleccionar”, se envía una petición al servidor del tipo:

Una vez recibida en el servidor, dicha petición se transforma en el siguiente código para obtener el listado de artículos de una determinada categoría:

Un atacante de nuestra plataforma podría modificar la petición esperada y solicitar información no controlada, por ejemplo:

De esta forma, el atacante podría obtener el listado de todos los artículos de la base de datos con una simple modificación que puede ser realizada directamente desde el navegador con, por ejemplo, el plugin Hack Bar de Firefox. Aunque esto parezca trivial y quizá en algún caso pueda interesar que un usuario se pase toda la tarde viendo mi página web para comprar un cabecero para su dormitorio, la cosa cambia sustancialmente cuando la información que se pretende mostrar son los ingresos de un trabajador o el grado de minusvalía de una determinada persona. Si a esto le añadimos la posibilidad de algunos sistemas gestores de base de datos de concatenar sentencias en una misma ejecución, el resultado podría ser la modificación de una tabla o incluso el borrado de la propia base de datos.

Pasando a otra tipología, veamos ahora una inyección de sistema operativo. Supongamos que en la interfaz de administración de la aplicación de catálogo comentada anteriormente existe una interfaz de administración que permite ejecutar unas tareas administrativas sobre el servidor, cuyo resultado es mejorar la indexación de las distintas bases de datos que componen la aplicación. Una vez seleccionada la base de datos, el usuario pulsa el botón de optimizar y se envía una petición al servidor del tipo:

Una vez recibida en el servidor, dicha petición se transforma en el siguiente código para optimizar la base de datos solicitada:

Cuando el proceso termina se envía un mensaje al espacio privado del usuario con el resultado de la ejecución. Un atacante de nuestra plataforma podría modificar la petición esperada y solicitar información no controlada, por ejemplo de la siguiente manera:

De esta forma, podría obtener el listado de todos los usuarios y sus contraseñas en su espacio de usuario, únicamente esperando a que el proceso termine su ejecución (seguro que en lugar de /etc/passwd pueden pensar alternativas mejores).

Aunque los ejemplos de vulnerabilidades se han mostrado siempre con peticiones GET, las aplicaciones son igualmente vulnerables a peticiones POST. Del mismo modo, estas vulnerabilidades son independientes del lenguaje utilizado en el servidor, aunque el uso de determinados frameworks puede mitigar la existencia de estas vulnerabilidades. Los dos ejemplos mostrados son sólo un par de situaciones en las que es posible encontrar vulnerabilidades de inyección, pero la filosofía es extensible al resto de tipos de inyecciones.

La primera manera de protegerse, independientemente del tipo de inyección que podamos sufrir, es asegurar que los datos que se utilizan para componer la visualización dinámica de la aplicación —aquella que depende de la petición del usuario— se encuentran correctamente validados antes de su interpretación. Es decir, si “estamos esperando” un número, se debe validar que el parámetro utilizado será un número, y si por el contrario esperamos una dirección de correo electrónico, utilizaremos ese dato únicamente si éste es conforme al formato establecido. En segundo lugar, es importante prestar especial atención a la existencia de determinadas secuencias de caracteres y cuando se presenten, “escaparlas” mediante las funciones apropiadas. Por último, la mayoría de lenguajes disponen de APIs con funciones diseñadas para proteger la aplicación, y que ofrecen la posibilidad de ejecutar consultas especialmente preparadas para evitar este tipo de problemas de seguridad.

Y hasta aquí todo lo referente a ataques de inyección, de momento. Como saben, si quieren extenderse en la materia, más allá de los innumerables recursos de la red, pueden acudir a la web de OWASP, donde encontrarán mucha información de utilidad. Si desean que demos más detalles sobre alguna de las vulnerabilidades mostradas, no tienen más que indicarlo en los comentarios.

A continuación os presentamos un reto criptográfico que ha sido publicado por OWASP con el objetivo de promover unas conferencias en Estocolmo los días 21 al 24 de Junio organizadas por los capítulos de Suecia, Noruega y Dinamarca.

¿Qué se gana con este reto? Pues el primero en resolver el reto se lleva una entrada gratuita para estas conferencias valorada en unos 300€. Según anuncian en su página web, estos retos se realizan todos los días 21 hasta la celebración de las conferencias. En este caso, el objetivo de este reto en concreto es sencillo: obtener 8 contraseñas, compuestas por 5 caracteres codificadas en alfabeto tradicional, es decir [a-zA-z].

El esquema del reto es iterativo, como se puede comprobar en la siguiente ilustración. Es decir, obtenemos la primera contraseña, que se debe utilizar en el segundo paso para averiguar la segunda contraseña, ésta se usa para obtener la tercera y así sucesivamente.

Y cómo sabemos que la contraseña encontrada es la correcta? Pues con la información que se detalla a continuación:

• LM(pwd1) 0C04DACA901299DBAAD3B435B51404EE
• MD2(pwd2 + pwd1) 16189F5462BF906E9D88CF6F152DE86F
• MD4(pwd3 + pwd2) FA8F46A6D347087D6980C3FA77DD4DE9
• MD5(pwd4 + pwd3) 425B33D6F60394C897B8413B5C185845
• RIPEMD160(pwd5 + pwd4) 35F34671D30472D403937820DCABC1C78C837071
• SHA1(pwd6 + pwd5) AE81A30510B2931921934218636B26A803330EB1
• SHA256(pwd7 + pwd6) B2FF0269E927C6559804A37590A0688C45DF143F85CEE0E3F239F846B65C9644
• GOST3411(pwd8 + pwd7) 16CC9F1FF65688E040F5ADA82A41A258FF948769CDA4C4A17D85228A6F358971

El reto está desarrollado en Java y el código fuente que genera las hash se encuentra disponible (.ZIP), a excepción del algoritmo LM para el que se ha utilizado Bouncy Castle 1.4.5. Aunque el reto ya está resuelto en los foros, y no, no conocemos a quien lo ha resuelto —de hecho yo me he enterado cuando ya estaba resuelto—, eso no quita para intentar obtener las claves en menos tiempo que el ganador: 15 horas después de su publicación.

Siempre les quedará la victoria moral, que no es poca.

Aunque en alguna ocasión hemos hablado de OWASP (algunos de nosotros estuvimos en el pasado meeting del pasado mayo que tuvo lugar en Barcelona), lo cierto es que hasta la fecha, no hemos profundizado demasiado sobre este proyecto. Sirva esta entrada para solventar esta (relativamente) grave carencia.

Por si alguien no lo conoce, OWASP (acrónimo de Open Web Application Security Project, es decir Proyecto de seguridad de aplicaciones web abiertas), es un proyecto de código abierto dedicado a determinar y combatir las causas que hacen que el software sea inseguro, aunque su objetivo y foco de atención principal son las aplicaciones web. La comunidad OWASP, formada por empresas, organizaciones y particulares de todo el mundo, trabaja para crear artículos, metodologías, documentación, herramientas y tecnologías que se liberan y pueden ser usadas gratuitamente por cualquiera.

Organizativamente, OWASP se encuentra dividido en capítulos distribuidos geográficamente. Mención especial debe realizarse al capítulo ibérico, formado por los capítulos de España y Portugal, que organizó el pasado mes de Diciembre la primera conferencia de este capítulo en territorio español con el objetivo de difundir y discutir los problemas y soluciones relacionados con la seguridad de las aplicaciones, destacando la presencia del conocido Bruce Schneier, entre otros.

Una de las partes más conocidas de la documentación que genera esta comunidad, y que va a ser el objeto de las siguientes entradas de esta serie, son las revisiones de las 10 vulnerabilidades web más conocidas y explotadas dentro del sector. Muchos desarrolladores y técnicos han conocido la existencia de las inyecciones de SQL, el cross site scripting o la importancia del manejo de sesiones, entre otras, gracias a la documentación generada por esta comunidad en las versiones publicadas en el año 2004 y 2007. Está previsto que durante el año 2010 se publique una nueva versión de este documento que ya está disponible en la página web del proyecto para su validación y consulta (PDF). Entre los aspectos más destacados de esta nueva revisión podemos indicar que el top 5 no cambia, lo que a todas luces muestra que la mayor parte de la industria del desarrollo web (así como desarrollo en general) continúa considerando la seguridad como una parte prescindible y auxiliar de las aplicaciones, ignorando aspectos de seguridad críticos y en muchos casos fácilmente solventables.

Así pues, esta nueva serie de post sobre el TOP 10 de OWASP, que publicaremos semanalmente si el tiempo lo permite, mostrará en qué consiste cada una de las vulnerabilidades descritas y ofrecerá indicaciones y recomendaciones sobre la forma de evitar estas situaciones. Esperemos que les parezca interesante y nos hagan llegar sus impresiones al respecto.

Pasen, como siempre y a pesar del mal tiempo, un buen fin de semana.