¿Cuál es la estrategia para las pruebas de seguridad de aplicaciones web para la metodología de inicio de sesión?

Buena pregunta y aspecto importante para comenzar pentest. Yo personalmente hago una especie de lista de verificación.

En los siguientes escenarios, solo señalaré las superficies de ataque y no las vulnerabilidades. De lo contrario, esta respuesta se convertirá en un blog.

  • Revise todas las características posibles de la aplicación en la fase previa al inicio de sesión, como la contraseña olvidada, el registro, la búsqueda y las páginas anónimas.
  • Vea la url para parámetros como el parámetro de búsqueda y similares.
  • Compruebe si hay inyecciones en cuadros de entrada o campos / parámetros ocultos. Este es el escenario de ataque previo al inicio de sesión más crucial y más efectivo.
  • Intenta enmarcar la aplicación.
  • Juega con las cookies y comprueba sus banderas.
  • Si la red está dentro del alcance, verifique los problemas de SSL y las configuraciones incorrectas.
  • Verifique crossdomain.xml si corresponde.
  • Compruebe si hay métodos HTTP peligrosos.
  • Vea cuál es el almacenamiento local como caché y db local (dentro de los navegadores). En la consola del navegador, escriba: localStorage
  • También verifique las políticas de bloqueo después; Todos sus casos de prueba han terminado.
  • Verifique el código fuente para obtener información confidencial como en el caso de comentarios detallados.
  • Ejecute un destructor de directorios o una araña similar para comprender los nodos / archivos ocultos de las aplicaciones.

Supongo que en general; Tener una mentalidad completa sobre la aplicación y familiarizar su lógica. Además, la mayoría de estas pruebas se pueden repetir después del inicio de sesión (si es posible) y comparar los resultados con los resultados previos al inicio de sesión.

Te doy mi conocimiento, de mi Metodología: https://www.dropbox.com/home?pre

Hace muchos años, antes de que hubiera un gran impulso para HTTPS todo el tiempo, era una práctica común para muchas aplicaciones cargar un formulario de inicio de sesión utilizando HTTP, pero luego enviar el formulario a través de HTTPS. Esto se logró estableciendo el atributo de acción del formulario en la versión HTTPS completa del sitio.

Hubo una falla en esta configuración. La falla no es ni siquiera con la presentación de sus credenciales. En cambio, el problema es cómo se carga inicialmente ese formulario de inicio de sesión. ¿Recuerdas que dijimos que la solicitud inicial era HTTP? La creencia era que debido a que la carga del formulario no transmite ningún dato confidencial, estaría bien usar HTTP. Incluso podría hacer un viaje de regreso a las guerras de rendimiento durante ese tiempo indicando que HTTP era mucho más rápido de cargar. (Aprendimos muchos años).

El problema es que si hay un usuario malicioso (atacante) en su misma red que puede redirigir su tráfico a través de ellos, podrían manipular la carga inicial de la página. ¿Imagina si el atacante interceptó su solicitud en la página de inicio de sesión (carga inicial) y cambió la acción del formulario a un sitio diferente?

Observe cómo el nuevo envío del formulario irá a un sitio diferente, ni siquiera usando HTTPS. Desde el punto de vista del usuario final, ni siquiera sabrían que el formulario enviaría sus credenciales a un sitio diferente.

A lo largo de los años, hemos visto reducir el uso de esta metodología. Muchos sitios ahora están cargando sus formularios de inicio de sesión en todo HTTPS. De hecho, muchos sitios son 100% HTTPS.

Hay otro ángulo para esto que a menudo se pasa por alto, pero funciona de manera muy similar. ¿Su sitio permite que se cargue en marcos? He visto muchos sitios que han incluido el formulario de inicio de sesión de otra aplicación utilizando conjuntos de marcos o marcos. El problema es que el sitio contenedor a menudo es un simple sitio de marketing o marca y se ejecuta a través de HTTP.

Como en el ejemplo anterior, el sitio HTTP incluye una referencia de marco a un sitio HTTPS. Nuevamente, el envío del formulario de inicio de sesión sigue siendo correcto. Sin embargo, es posible que el atacante del escenario anterior pueda interceptar la página que contiene y cambiar la referencia para el marco de inicio de sesión. En este caso, lo más probable es que el atacante cree una página que sea idéntica al formulario de inicio de sesión real y apunte el marco hacia esa. El usuario no tendría idea de que la página de autenticación era incorrecta, ya que se vería como la original. Cuando el usuario envía sus credenciales, se enviarán al usuario malintencionado en lugar del sitio real.

Se recomienda no permitir que su sitio se aloje dentro de un subtrama. Hay muchos artículos que discuten las técnicas de eliminación de fotogramas y también puede consultar el encabezado X-Frame-Options. Si su formulario no se carga en un marco, entonces se reduce su riesgo de ser incluido en un sitio no seguro. Para todos los demás escenarios, no hay muchas razones para no usar HTTPS de principio a fin. Al asegurar todas las transacciones, reduce el riesgo de que un atacante pueda manipular fácilmente ese tráfico.

Hola,

Una prueba de seguridad adecuada de la aplicación se está volviendo muy importante hoy en día a medida que se realizan más transacciones en la web a diario.

Las pruebas de seguridad hacen hincapié en mantener la confidencialidad de los datos confidenciales y el primer paso es asegurar el inicio de sesión de cualquier aplicación.

En general, las compañías de pruebas de software siguen la siguiente metodología para probar la seguridad de inicio de sesión de cualquier aplicación:

  • Descifrado de contraseñas
  • Manipulación de URL a través de métodos HTTP GET
  • Inyección SQL
  • Cross Site Scripting

Gracias,

Sumit