Mecanismo de defensa central en aplicaciones web

Dividimos las defensas centrales en las aplicaciones web en tres áreas: Manejo del acceso del usuario, Manejo de la entrada del usuario y Manejo de los atacantes. Estos se explican a continuación a continuación.

1. Manejo del acceso del usuario:
la primera tarea es manejar el acceso según el usuario (usuario administrador, usuario anónimo, usuario normal). La mayoría de las aplicaciones web manejan el acceso mediante un trío (lo denominé ASA) de mecanismos de seguridad interrelacionados: la autenticación, la administración de sesiones y el control de acceso se explican a continuación.

1. Autenticación:
   el mecanismo de nombre de usuario y contraseña para verificar la validez del usuario o usuario anónimo es el básico. Hoy en día, también se implementan mecanismos aún más avanzados como la verificación en dos pasos. Por lo tanto, los piratas informáticos siempre verifican estos mecanismos en busca de defectos. La fuerza bruta es la más común. Se deben aplicar limitaciones y validaciones de entrada a estas entradas para proteger la funcionalidad básica de la aplicación.
2. Gestión de sesiones:
   después de que el usuario haya superado el primer paso de autenticación, es posible que tenga que gestionar y proporcionar gestión de acceso, que se realiza principalmente mediante un mecanismo de token. Las principales áreas de vulnerabilidad surgen de defectos en la forma en que se generan los tokens, lo que permite a un atacante adivinar los tokens emitidos a otros usuarios, y defectos en la forma en que se manejan los tokens, lo que permite a un atacante capturar los tokens de otros usuarios. Por lo tanto, el programador puede implementar la verificación del tiempo de validez del token y tokens cifrados difíciles que un atacante no puede adivinar fácilmente.
3. Control de acceso:
   sobre la base de las credenciales recibidas, la aplicación decide el nivel de acceso y, debido a su naturaleza compleja, estos mecanismos suelen ser defectuosos. Los desarrolladores a menudo hacen? Asombran las suposiciones sobre cómo los usuarios interactuarán con la aplicación y, con frecuencia, cometen descuidos al omitir las comprobaciones de control de acceso de algunas funciones de la aplicación. Por lo tanto, proporcione el mecanismo adecuado.

2. Manejo de la entrada del usuario: la
mayoría de las fallas se encuentran en el manejo de la entrada de una aplicación. Cualquier entrada no deseada puede incluso conducir a una violación de datos por inyección de SQL o token perdido por XSS almacenado y muchos más ataques pueden estar en juego y dañar su aplicación. Por lo tanto, se vuelve muy necesario fortalecer estos mecanismos. La entrada del usuario puede ser nombre de usuario, comentarios, búsqueda, formularios, a veces también se utilizan cookies.

Enfoques para manejar la entrada del usuario:
no podemos adivinar la mente o la metodología del usuario mientras ingresa. Por lo tanto, debemos usar el método «RKB» que es «Rechazar mal conocido».

• Rechazar mal conocido:
  este método consiste en una lista negra según los caracteres que se bloquean. En general, este se considera el enfoque menos efectivo para validar la entrada del usuario, por dos razones principales. En primer lugar, una vulnerabilidad en una aplicación web puede explotarse utilizando una amplia variedad de entradas y, en segundo lugar, las técnicas de explotación cambian constantemente.

  Los filtros de lista negra se pueden omitir como:

  1. If SELECT is blocked, try SeLeCt
  2. If or 1=1-- is blocked, try or 2=2--
  3. If alert(‘xss’) is blocked, try prompt(‘xss’) 

  Los filtros diseñados para bloquear palabras clave específicas se pueden omitir mediante el uso de caracteres no estándar entre expresiones para interrumpir la tokenización realizada por la aplicación.

  Por ejemplo:

  SELECT/*foo*/username, password/*foo*/FROM/*foo*/users 

  Ejemplo de omisión de byte NULL.
  Por ejemplo:

  %00alert(1)

• Acepta bueno conocido (AKG):
  este enfoque es recíproco del enfoque «RKB» en el que no podemos rechazar las malas entradas. En su lugar, podemos crear una lista blanca. Por lo tanto, la aplicación solo puede aceptar entradas enumeradas y todas las demás entradas son rechazadas por las aplicaciones. Este enfoque es más seguro que el esquema de rechazo mal conocido.
• Desinfección:
  en este enfoque, los datos recibidos deben ser desinfectados. Los caracteres maliciosos pueden eliminarse de los datos, solo quedan los caracteres seguros, o pueden codificarse adecuadamente o «escaparse» antes de que se realice un procesamiento adicional. Por ejemplo, la defensa habitual contra los ataques de secuencias de comandos entre sitios es codificar en HTML los caracteres peligrosos antes de que se incrusten en las páginas de la aplicación. Pero se puede omitir si el atacante comprende el mecanismo de limpieza.
• Manejo seguro de datos:
  la mayoría de las vulnerabilidades de las aplicaciones web surgen porque los datos proporcionados por el usuario se procesan de manera insegura. A menudo, las vulnerabilidades se pueden ignorar no validando la entrada en sí, sino asegurándose de que el procesamiento que se realiza en ella sea seguro. En algunas condiciones, se encuentran disponibles métodos de programación seguros que evitan problemas comunes. Por ejemplo, los ataques de inyección SQL se pueden prevenir mediante el uso correcto de consultas parametrizadas para el acceso a la base de datos.
• Comprobaciones semánticas:
  sin embargo, con algunas vulnerabilidades, la entrada proporcionada por el atacante es similar a la entrada que puede enviar un usuario ordinario no malicioso. Lo que lo hace malicioso son las distintas circunstancias en que se presenta. Por ejemplo, un atacante podría tratar de obtener acceso a la cuenta bancaria de otro usuario cambiando un número de cuenta transmitido en un campo de formulario oculto. Ninguna cantidad de validación sintáctica distinguirá entre los datos del usuario y los del atacante. Para evitar el acceso no autorizado, la aplicación debe validar que el número de cuenta enviado pertenece al usuario que lo envió.
• Verificación de varios pasos:
  todos usamos muchos servicios seguros en estos días, como Gmail, etc., que nos proporciona dos pasos o podemos decir verificación de varios pasos. Pero toda esta verificación es para la identificación del usuario en lugar de la verificación de datos.

3. Manejo de atacantes:
debemos tener en cuenta estos puntos al manejar errores: el manejo de errores, el mantenimiento de registros de auditoría, las alertas a los administradores y la reacción a los ataques se explican a continuación.

1. Error de manejo:
   a corto plazo, los atacantes primero intentan recopilar información sobre la aplicación. Por lo tanto, todos los mecanismos de error en la aplicación no deben proporcionar ninguna descripción, es decir, no deben filtrar ninguna información sobre bases de datos, arquitectura del sistema o detalles de rutas, etc.
2. Mantenimiento de la auditoría:
   los registros de auditoría son importantes mientras se investigan eventos como incidentes, los registros de auditoría efectivos deberían permitir a los propietarios de la aplicación comprender exactamente qué sucedió, qué vulnerabilidades se explotaron, si el atacante obtuvo acceso no deseado a los datos o realizó acciones no autorizadas, y , en la medida de lo posible, proporcionar pruebas de la identidad del intruso.

   Todos los eventos relacionados con la funcionalidad de autenticación, Transacciones clave, Cualquier solicitud que contenga strings de ataque conocidas que indiquen intenciones abiertamente maliciosas.

3. Administración de alertas:
   puede haber algún mecanismo que pueda alertar al administrador de las aplicaciones sobre cualquier actividad inusual en la aplicación, como una solicitud de ping alto desde una IP en particular.
4. Reacción al ataque:
   muchas aplicaciones críticas para la seguridad contienen mecanismos integrados para reaccionar defensivamente ante los usuarios identificados como potencialmente malintencionados. Debido a que la mayoría de las aplicaciones son diferentes y el atacante debe realizar diferentes pruebas para encontrar vulnerabilidades, identificaremos muchas de estas requests como potencialmente maliciosas y las bloquearemos. Por esta razón, algunas aplicaciones web toman medidas reactivas automáticas para frustrar al atacante que está actuando de esta forma. Por ejemplo, pueden responder cada vez más lentamente a las requests del atacante o finalizar la sesión del atacante, lo que requiere que inicie sesión o realice otros pasos antes de continuar con el ataque.