Identificar Puntos de Entrada en la Aplicación

  • Posted on: 23 July 2019
  • By: ReYDeS

Enumerar las aplicación y su superficie de ataque es el precursor clave antes de cualquier prueba a ser realizada, esto permite al profesional identificar áreas probables de debilidad. Esta sección ayuda a identificar y mapear áreas dentro de la aplicación, las cuales deben ser investigadas una vez se ha completado la enumeración y el mapeo.

Objetivos de la Prueba

Entender como se realizan las peticiones y respuestas típicas desde la aplicación.

Como Evaluar

Antes de iniciar cualquier prueba, el profesional debe siempre tener un buen conocimiento de la aplicación, y de como el usuario y el navegador web se comunican. Conforme se camina a través de la aplicación, se debe poner especial atención hacia todas las peticiones HTTP (Métodos GET y POST, también conocidos como Verbos), como también cada parámetro y campo de formulario pasado hacia la aplicación. Además se debe poner atención cuando se utilizan las peticiones GET y cuando se utilizan las peticiones POST, para pasar parámetros hacia la aplicación. Es muy común sea utilizada una petición GET, pero cuando se pasa información sensible frecuentemente se hace dentro del cuerpo de una petición POST.

Anotar para la visualización de los parámetros enviados en una petición POST, el profesional necesitará utilizar una herramienta como un proxy de interceptación (Por ejemplo OWASP Zed Attack Proxy) o un plugin para el navegador. Dentro de la petición POST, el profesional debe también anotar especialmente los campos ocultos del formulario conteniendo información sensible, como información de estado, cantidad de artículos, precio de artículos, lo cual el desarrollador nunca destino a ser vistos y cambiados.

Por experiencia ha sido muy útil utilizar un proxy de interceptación y una hoja de cálculo para esta etapa de las pruebas. El proxy mantiene un rastro de cada petición y respuesta entre el profesional y la aplicación conforme es recorrida. Adicionalmente en este punto, el profesional usualmente atrapa cada petición y respuesta, de tal manera pueda visualizar exactamente cada cabecera, parámetro, etc. el cual es pasado hacia la aplicación, y aquello lo cual es retornado. Esto puede ser algo tedioso algunas veces, especialmente en grandes sitios interactivos (Pensar en aplicación de banca). Sin embargo, la experiencia mostrará aquello a buscar, y esta fase puede reducirse significativamente.

Conforme el profesional recorre a través de la aplicación, debe anotar cualquier parámetro interesante en la URL, cabecera personalizada, o cuerpo de la petición o respuestas, para luego guardarlas en una hoja de cálculo. Este documento debe incluir la página solicitada (podría ser bueno también añadir el número de petición desde el proxy para futuras referencias), los parámetros interesantes, el tipo de petición (POST/GET), si el acceso es autenticado o no autenticado, si se utiliza SSL/TLS, si es parte de un proceso de varios pasos, o cualquier otra anotación relevante. Una vez se tenga cada área de la aplicación mapeada, entonces se puede recorrer la aplicación y evaluar cada una de las áreas identificadas y anotar aquello lo cual funciona o no funciona. El resto es identificar como probar cada una de estas áreas de interés, pero esto debe realizarse antes de comenzar cualquier prueba.

A continuación se presentan algunos puntos de interés para todas las peticiones y respuestas. Dentro de la sección peticiones, enfocarse en los métodos GET y POST, pues estos aparecen en la mayoría de peticiones. Anotar otros métodos, como PUT o DELETE pueden ser utilizados. Frecuentemente, estas son peticiones más raras, si están permitidas, pueden exponer vulnerabilidades. Se tiene una especial consideración para probar estos métodos HTTP.

Peticiones:

  • Identificar donde se utilizan las peticiones GET y donde se utilizan POST.
  • Identificar todos los parámetros utilizados en una petición POST (Están en el cuerpo de la petición).
  • Dentro de cada petición POST, poner especial atención en cualquier parámetro oculto. Cuando un POST es enviado, todos los campos del formulario (incluyendo los parámetros ocultos) serán enviados en el cuerpo del mensaje HTTP hacia la aplicación. Estos típicamente no son vistos a menos se utilice un Proxy o se visualice el código fuente. Además, la siguiente página mostrada, sus datos, y el nivel de acceso puede ser diferente dependiente del valor de los parámetros ocultos.
  • Identificar todos los parámetros utilizados en una petición GET (la URL), en particular la cadena de consulta (usualmente después del signo “?”).
  • Identificar todos los parámetros de la cadena de consulta. Estos usualmente están en un formato de pares, como “foo=bar”. También anotar muchos parámetros pueden estar en una cadena de consulta por separado por un “&“, “~”, “:”, o cualquier otro carácter especial o codificación.
  • Una nota especial cuando se trata de identificar múltiples parámetros en una cadena o dentro de una petición POST, es algunos o todos los parámetros podrían ser necesarios para ejecutar los ataques. El profesional necesita identificar todos los parámetros (incluso si está codificada o encriptada), e identificar cuales son procesadas por la aplicación. Posteriormente se debe identificar como evaluar estos parámetros. En este punto solo se debe estar seguro cada uno ha sido identificado.
  • También poner atención en cualquier tipo adicional de cabeceras o personalizada, la cual no es típicamente vista (como debug=false)

Respuestas:

  • Identificar donde se definen nuevas Cookies (cabecera Set-Cookie), modifican o añaden.
  • Identificar donde existe cualquier redirección (Código de estado HTTP 3xx), códigos de estado 400, en particular 403 Forbiden, y 500 Internal Server Error, durante las respuestas normales (ejemplo peticiones sin modificar)
  • También notar donde se utiliza cualquier cabecera interesante. Por ejemplo “Server: BIG-IP” indica un balance de carga en el sitio. Por lo tanto, si el sitio usa balance de carga y un servidor está incorrectamente configurado, entonces el profesional podría hacer múltiples peticiones para acceder al servidor vulnerable, dependiendo del tipo de balance de carga utilizado.

Prueba de Caja Negra

Evaluar los puntos de entrada en la aplicación:

Ejemplo 1

Este ejemplo muestra una petición GET, la cual podría comprar un artículo en una aplicación de compras en linea.

Resultado Esperado:

Aquí el profesional debería anotar todos los parámetros de la petición; como “show.product_details”, “flypage”, “product_id”, como también la Cookie (La cual podría codificar parámetros o ser utilizada para el estado de la sesión).

Ejemplo 2

En este ejemplo se muestra una petición POST, la cual añade una artículo a ser comprado.

Resultado Esperado:

En este ejemplo el profesional debe anotar todos los parámetros como se hizo anteriormente, pero notará los parámetros son pasados en el cuerpo del mensaje y no en la URL. Adicionalmente notar la existencia de alguna Cookie personalizada.

Prueba de Caja Gris

Probar los puntos de entrada a la aplicación mediante una metodología de Caja Gris podría consistir de todo lo ya identificado anteriormente, con un añadido. En casos donde existen fuentes externas desde las cuales la aplicación recibe datos y las procesa (como capturas SNMP, mensajes syslog, SMTP, o mensajes SOAP desde otros servidores), una reunión con los desarrolladores de la aplicación, podría identificar cualquier función la cual acepte o espere entrada del usuario, y como esta es formateada. Por ejemplo, un desarrollador podría ayudar a entender como formular una petición SOAP correcta, la cual la aplicación podría aceptar, y donde reside el servicio web (si el servicio web o cualquier otra función no ha sido aún identificada durante la prueba de caja negra).

Fuentes:

https://www.owasp.org/index.php/Identify_application_entry_points_(OTG-INFO-006)
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

Sobre el Autor


Alonso Eduardo Caballero Quezada - ReYDeS
Instructor y Consultor Independiente en Ciberseguridad
Correo Electrónico: ReYDeS@gmail.com
Twitter: https://twitter.com/Alonso_ReYDeS
LinkedIn: https://pe.linkedin.com/in/alonsocaballeroquezada/
Facebook: https://www.facebook.com/alonsoreydes
Youtube: https://www.youtube.com/c/AlonsoCaballero


Suscribete