Falla 2: Control de acceso interrumpido

El proceso de control de acceso (conocido como autorización), es la manera en la que una aplicación web garantiza el acceso al contenido y la ejecución de funciones a algún usuario en particular.

Estas revisiones se hacen después de la autenticación y dictaminan qué es lo que los usuarios "autorizados" pueden hacer o no. ¿Así de entrada suena simple no lo crees? El problema es que no es tan sencillo implementar de manera correcta y eficientemente un sistema de autorización, ya que en primera, el modelo a seguir generalmente está estrechamente ligado con el contenido y las funcionalidades del sitio, y por otro lado, los usuarios pueden pertenecer a uno o varios grupos o roles cada uno con diferentes privilegios en el sistema.

Todo comienza cuando los desarrolladores desestiman la dificultad inherente en el proceso de la implementación de los mecanismos de control ya que en su mayoría los esquemas desarrollados no fueron deliberadamente designados para este propósito y fueron evolucionando junto con la aplicación web. En estos casos, se tienen varias versiones de las reglas de control de acceso regadas por todo el sitio, lo que ocaciona que a medida que el sitio crezca, la tarea de mantener toda esta colección de reglas va aumentanto hasta que se hace prácticamente insostenible y las reglas en sí dejan de tener sentido para los desarrolladores.

El problema continúa en virtud de que los controles de autorización, al estar tan íntimamente relacionados con la aplicación en sí, son difícilmente reutilizados o reimplementados en algún proyecto nuevo, lo que en su caso requerirá modificaciones.

Estos esquemas de control de acceso son fácilmente detectables y explotables por medio de llamadas a funciones o solicitudes de contenido que no debería proporcionarse. Resulta claro que las consecuencias son devastadoras puesto que además de ganar acceso a la visualización de contenido no autorizado, el atacante podría ejercer operaciones no autorizadas para cambiar o hasta eliminar los datos e incluso adueñarse de la administración del sitio.

Un ejemplo muy específico del problema del control de acceso son las interfaces que le permiten a los administradores manejar un sitio desde internet debido a que permiten controlar a los usuarios, los datos y el contenido del sitio. En algunos casos estos sitios implementan roles administrativos lo que permite una administración más fina. En virtud de todo el poder que concentran estas interfaces, se convierten comunmente en los objetivos primarios de cualquier ataque.

Virtualmente todos los sitios tienen algún mecanismo de control de acceso. Por esto es que es recomendable crear una política de control de acceso claramente documentada. Así mismo, la documentación de las etapas de diseño debería concentrarse en la implantación de dicha política.

Del mismo modo que con la política, el código que la implementa debe revisarse y después probarse mediante pruebas de penetración. Es recomendable que se diseñe para ser modular, estructurado y mayormente centralizado.

Finalmente, otra práctica importate es averiguar cómo se administran los sitios web, averigue cómo se hacen los cambios sobre las páginas, en dónde se prueban y cómo son transportados al servidor de producción. Si los administradores pueden hacer cambios de manera remota sería deseable saber cómo están protegidos esos canales.

Falla 4: Cross site scripting

Las vulnerabilidades de scripting de sitio cruzado (Cross-site scripting o simplemente XSS) ocurren cuando un atacante utiliza una aplicaciónb web para enviar código malicioso, generalmente en la forma de un script, a un usuario.

Estas fallas son bastante comunes y ocurren cuando una aplicación web utiliza (sin validar) los datos ingresados por un usuario a fin de generar la salida. En este caso, el navegador del usuario no tiene manera de saber que no se debería confiar en e script, por lo que eventualmente lo ejecutará y podrá acceder a cualquier sesión, cookies o alguna otra fuente de información sensible retenida en el navegador. Estos scripts pueden reescribir el contenido de la página HTML.

Los ataques XSS se pueden categorizar de la siguiente forma:

- Almacenados y
- Reflejados

Los araques almacenados son aquellos en los que el código inyectado reside permanentemente en los servidores que lo envían, ya sea en la base de datos, en un mensaje de un foro, en un log de un visitante, campo de comentario, etc.La víctima descarga el script malicioso del servidor cuando hace alguna solicitud de contenido.

Los ataques reflejados son aquellos donde el código inyectado es reflejado fuera del servidor, tal como en un mensaje de error, el resultado de una búsqueda o cualquier otra respuesta que incluya una parte de la entrada enviada al servidor como parte de una solicitud.

Los ataques reflejados son enviados a las víctimas por otras rutas tales como un correo electrónico u otro servidor web; en cuyo caso cuando el usuario da click sobre una liga o envía cierto tipo de forma, el código inyectado viaja al servidor web vulnerable, el que a su vez refleja el ataque al navegador del cliente, que ejecuta el código puesto que proviene de un servidor "seguro".

Las consecuencias de un ataque XSS son las mismas sin importar la variante del ataque del que se trate, la diferencia está en cómo llega al servidor el código malicioso. No hay que confiarse al pensar que un sitio de sólo lectura o "brochureware" no es vulnerable a los ataques XSS reflejados.
Los XSS pueden causar una variedad de problemas para el usuario final que van desde simples molestias en la navegación hasta compromisos completos de las cuentas en los sitios web. Los ataques más severos hacen pública la información de las cookies del usuario, permitiendo a los atacantes secuestrar la sesióny tomar el control de la misma. Otros ataques incluyen la divulgación de los archivos del usuario, la instalación de troyanos, la redirección del usuario a alguna otra página y la modificación de la presentación del contenido, como por ejemplo:

Un atacante podría modificar una comunicado de prensa que afecte la confianza de los consumidores o, en un sitio farmacéutico, podría modificar la información de dosificación de algún medicamento.

Los atacantes se ayudan de varios métodos para codificar la porción maliciosa del código, tal como el uso de Unicode, de ta forma que el request es menos sospechoso. Hay miles de variantes de estos ataques, que incluyen versiones que nisiquiera requeren de la inclusión de los símbolos <> (necesarios para definir scripts en las páginas web), por tanto es muy complicado filtrar exitosamente estos scripts. Lo que en todo caso se recomienda es la validación de la entrada contra una especificación clara de qué es lo que se espera. Los ataques XSS generalmente vienen desde scripts de JavaScript, aunque cualquier contenido activo incrustado (ActiveX,VBScript, Shockwave, Flash y muchos otros) es un peligro potencial.

Otros ataques se pueden presentar desde los mismísimos servidores de aplicaciones o de web subyacentes ya que éstos generan páginas muy simples en caso de que ocurran algunos errores como en el caso del error 404 (Page not found) o un error 500 (Internal server error). Si estas páginas reflejan información de la petición del usuario (tal como la URL de la cual se quiso acceder), podría ser vulnerable a un ataque XSS reflejado.

La probabilidad de que un sitio contenga vulnerabilidades XSS es extremadamente alta ya que hay una muy amplia variedad de formas de engañar a las aplicaciones web para que almacenen scripts maliciosos.

Los desarrolladores que traten de filtrar las partes maliciosas de estas peticiones están lejos de hacerlo efectivamente debido a las muchas codificaciones que se pueden usar.

Finalmente, no es difícil encontrar este tipo de debilidades, lo único que se necesita es un navegador y algo de tiempo, además de que hay muchas herramienta disponibles para ayudar a localizar las fallas y explotarlas a fin de inyectar ataques XSS en un sitio objetivo.