¿Cómo escribir un código seguro?

¡Protégete contra la autenticación y la gestión de sesiones rotas!

¿Necesitas un código seguro?

He estado trabajando en prácticas de codificación seguras y tratando de aprender tantos puntos esenciales como sea posible. En los últimos años de estar en info-sec, me he dado cuenta de la cantidad de daño que una pequeña vulnerabilidad puede tener en la vida de un hombre común. Los ataques cibernéticos como el ransomware WannaCry y Petya son bastante recientes en la mente de varias personas que sufrieron por ello.

Sin embargo, cada día que pasa los investigadores pueden encontrar errores muy graves uno tras otro en las aplicaciones web y otros dominios. Esta tendencia no disminuirá a menos que los programadores se den cuenta del código que escriben. El código no solo debe ser capaz de llevar a cabo el trabajo previsto, sino que también debe ser capaz de defenderse de cualquier carga maliciosa y escenarios de ataque. La mejor manera de hacerlo es hacer una sinergia entre la comunidad de codificación y seguridad y ayudarse mutuamente.

¡Vamos a profundizar en!

Por lo tanto, este artículo en particular de "¿Cómo escribir código seguro?" Se centra en el problema de autenticación rota y el problema de administración de sesión.

Las funciones de la aplicación relacionadas con la autenticación y la administración de sesiones a menudo no se implementan correctamente, lo que permite a los atacantes comprometer contraseñas, claves, tokens de sesión o explotar otros defectos de implementación para asumir la identidad de otro usuario.

En este artículo, analizaré algunos tipos diferentes de ataques y métodos que puede usar para prevenirlos:

1. Credenciales de inicio de sesión de codificación rígida

Las credenciales de inicio de sesión de Hard Coding son uno de los errores más novatos que un programador puede cometer, ya que es tan bueno como entregar credenciales a los piratas informáticos en bandeja de plata. Los datos confidenciales nunca deben estar codificados.

Código inseguro - Créditos codificados

El código en el lateral es uno de esos ejemplos en los que las credenciales de inicio de sesión están codificadas en el código escrito por el programador.

Mientras que el código presente a continuación es un ejemplo donde las credenciales no están codificadas en el programa, lo que lo hace exponencialmente más seguro que aquellas en las que los créditos están codificados.

Código seguro: los créditos no están codificados

Estas pequeñas diferencias pueden tener un gran impacto en la seguridad de la aplicación.

2. Manipulación de cookies

La manipulación de cookies está aumentando como uno de los ataques más peligrosos que se llevan a cabo en estos días a medida que se lleva a cabo más y más proceso de autenticación al verificar los detalles de las cookies que presenta el usuario.

Los atacantes están encontrando formas de romper y descubrir cómo las aplicaciones web asignan cookies para poder manipularlas y hacerse pasar por otro usuario que realiza la toma de control de la cuenta.

Permítanme demostrar que un atacante podría aprovechar las cookies débiles que se están asignando al usuario o si las cookies se mantienen igual.

Esta imagen en el lateral es un portal de inicio de sesión donde llevaremos a cabo el ataque y mostraremos los problemas con la implementación de cookies débiles.

Una vez que iniciamos sesión en la aplicación, interceptamos el tráfico en Burp-Suite para echarle un vistazo y las cookies que se pasan para autenticarnos como usuario.

Detalles de cookies

La imagen de arriba muestra los cuatro parámetros "Set-Cookie" que se asignan cuando intentamos iniciar sesión. Estas cuatro cookies diferentes de inicio de sesión, PHPSESSID, muestran sugerencias, nombre de usuario y el uid. Sospechamos que el uid es único para cada usuario. Así que seguimos y manipulamos el uid para verificar si podemos acceder a la cuenta de otra persona.

Modificando cookie

Para capturar el valor de la cookie, utilizamos la extensión Cookie Manager presente en el navegador y luego pasamos la solicitud. Cambiamos nuestro "uid" de 24 a 12, como se muestra a continuación.

Cookie modificada

Tan pronto como modifiquemos el valor de la cookie, podemos ver que hemos llevado a cabo un ataque de adquisición de cuenta a medida que tenemos acceso a la cuenta del otro usuario.

La razón por la que se produjo este ataque fue que el PHPSESSID no se modificó en absoluto antes y después de que el usuario iniciara sesión, lo que convierte al "uid" en el único factor decisivo para identificar qué usuario acaba de iniciar sesión en su cuenta. Como podemos ver arriba, se manipula fácilmente permitiendo la toma de control de la cuenta.

Para evitar que suceda algo así, debemos reasignar la cookie después del intento de inicio de sesión y debemos tener en cuenta que la cookie también debe ser única. Aquí hay una idea de cómo podría hacer lo siguiente.

// El problema es que se está utilizando el mismo objeto de sesión, así que obtenga la sesión actual
HttpSession before_login = request.getSession ();
// Invalidar esa sesión
before_login.invalidate ();
// Genera una nueva sesión, un nuevo JSESSIONID
HttpSession after_login = request .getSession (verdadero);

El código anterior se usa para cambiar la cookie SESSIONID antes y después de iniciar sesión.

3. Enumeración de usuarios a través del servicio web

El problema de la enumeración es bastante grave, ya que permite al atacante averiguar los nombres de usuario / identificadores de correo electrónico de los usuarios que están presentes en la aplicación y los siguientes detalles se pueden utilizar más adelante para los ataques de fuerza bruta.

Llevamos este ataque a Burp-Suite usando la extensión Widsler y utilizando la funcionalidad "getuser" de la misma. Entonces, tratamos de recopilar la respuesta del sistema cuando ingresamos el nombre de usuario válido y luego ingresamos una cadena aleatoria que no es un nombre de usuario y luego verificamos la respuesta. Podemos ver la respuesta respectiva en las imágenes a continuación.

el usuario no existe

La imagen de arriba es una solicitud y respuesta que recibimos cuando el usuario con cierto nombre de usuario no existe. Enviamos la consulta de solicitud en el repetidor para verificar la respuesta.

El usuario existe

La imagen de arriba es una solicitud y respuesta que recibimos para la condición en la que el usuario existía. Enviamos la consulta de solicitud en el repetidor para verificar la respuesta y obtuvimos una respuesta diferente esta vez. Esto nos dio la idea de que podemos enumerar a los usuarios en función de la respuesta que recibimos.

Por lo tanto, pasamos la solicitud en la pestaña de intrusos y luego llevamos a cabo una fuerza bruta para verificar si hay varios usuarios que utilizan la aplicación.

Nombres de usuario enumerados

El principal problema aquí es que los desarrolladores están poniendo demasiados detalles en la consulta de respuesta. Como en este ataque, podemos ver claramente que debido a demasiada información en la respuesta, podríamos descubrir cuál de los usuarios con los nombres de usuario correspondientes existía y cuál de ellos no. Necesitamos hacer un mensaje estandarizado para que el atacante no pueda resolverlo usando una técnica simple de enumeración.

4. Ataque de fuerza bruta

Esta es la siguiente etapa de ataque que se lleva a cabo una vez que el atacante ha enumerado a los usuarios y sus nombres de usuario a través del método anterior.

La imagen al lado muestra la página de inicio de sesión donde ya hemos enumerado a los usuarios y necesitamos llevar a cabo el ataque de fuerza bruta para conocer las credenciales de inicio de sesión de esos usuarios.

Entonces, cuando intentamos iniciar sesión, interceptamos el tráfico en Burp-Suite y capturamos el paquete de solicitud y lo enviamos al intruso.

Solicitar consulta

Ahora que tenemos los nombres de usuario ya enumerados, llevamos a cabo el ataque de fuerza bruta. Obtenemos un grupo de contraseñas comunes de Internet y ejecutamos nuestro ataque para descubrir las contraseñas correspondientes.

Ataque de fuerza bruta a través de Burp-Suite

El tipo de ataque de fuerza bruta nunca debe permitirse bajo ninguna circunstancia. La funcionalidad de bloqueo de cuenta siempre debe estar presente, ya que evita que la aplicación sea forzada por la fuerza bruta y expulse las credenciales del usuario. La fuerza bruta también se puede contrarrestar permitiendo a los usuarios no usar palabras del diccionario, usar contraseñas de ciertas longitudes para pedirles que usen frases de contraseña. Las contraseñas de los usuarios siempre deben ser hash antes de ser almacenadas, el uso de sal con el hash también es increíblemente importante.

Moral

Podemos tomar las siguientes precauciones y mantener estas notas mentales mientras tratamos de combatir los problemas de Gestión de sesión y autenticación interrumpida.

Autenticación rota

  • Revelando mensajes de error / éxito
  • Nunca credenciales de código duro
  • Aplicación de la política de contraseñas (envejecimiento, resistencia, hashes con sales)

Manejo de sesiones

  • Imprevisibilidad en tokens (es decir, aleatoriedad segura)
  • Políticas de caducidad, reinicios de inicio / cierre de sesión
  • Uso de cifrado fuerte
  • Seguridad compleja de cookies

Lea mi otro artículo sobre "Prácticas de codificación segura"

~ Ataques de inyección - https://bit.ly/2OqkRv5
~ Cross Site Scripting - https://bit.ly/2TcpU2Y

Si lo disfrutaste, aplaude y colaboremos. ¡Consigue, establece, piratea!

Sitio web: aditya12anand.com | Done: paypal.me/aditya12anand

Telegrama: https://t.me/aditya12anand

Twitter: twitter.com/aditya12anand

LinkedIn: linkedin.com/in/aditya12anand/

Correo electrónico: aditya12anand@protonmail.com

Siga los informes de Infosec para obtener más comentarios increíbles.