Tome medidas en el desarrollo para endurecer y mantener seguro su backend web.

Las pequeñas empresas, los bancos y muchas industrias dependen de las aplicaciones web. Desde el momento en que se construye una aplicación web, es crucial asegurarse de contar con protocolos para comprobar las vulnerabilidades a medida que evoluciona el desarrollo para evitar brechas de seguridad, fugas de datos y problemas financieros.

Los ataques web más peligrosos son los que se producen en el lado del servidor, donde se almacenan y analizan los datos.

¿Qué es el backend?

Una aplicación web se divide en dos partes: Frontend y Backend.

  • El frontend es del lado del cliente, es la parte con la que interactúa el usuario. Normalmente, se construye con HTML, CSS y Javascript.
  • El backend es del lado del servidor. Es básicamente cómo funciona la aplicación, aplica la lógica de negocio, los cambios y las actualizaciones. Algunas de las pilas tecnológicas populares del lado del servidor incluyen PHP, NodeJS, Java, Ruby, C, Python, base de datos, seguridad (autenticación, control de acceso, etc.), estructura y gestión de contenidos.

Un pequeño recordatorio antes de empezar – autenticación, control de acceso y gestión de sesiones

Es habitual que confundamos los términos. Así que vamos a aclararlo rápidamente:

  • La autenticación se refiere a probar la identidad del usuario (por ejemplo, contraseña, nombre de usuario, preguntas de seguridad, huellas dactilares)
  • El control de acceso se refiere a lo que el usuario puede acceder a la aplicación. Hace cumplir la política de que los usuarios no pueden actuar fuera de sus permisos previstos.
  • La gestión de la sesión se refiere a las respuestas y las transacciones de solicitud asociadas al mismo usuario. Es un mecanismo de intercambio que se utiliza entre el usuario y la aplicación después de que se haya autenticado correctamente.

Exploremos lo siguiente para mejorar la seguridad web back-end.

Defectos de inyección

Desde 2010, el OSWAP clasifica la inyección como el riesgo número 1 de las aplicaciones web.

Los fallos de inyección permiten a un usuario proporcionar datos que contienen palabras clave que modificarán el comportamiento de las consultas realizadas en la base de datos. Por ejemplo, supongamos que tenemos un script SQL que comprueba si existe una entrada coincidente en la base de datos.

uname = request.POST['nombredeusuario']
passwd = request.POST['contraseña']
sql = "SELECT id FROM users WHERE username='" uname "' AND password='" passwd "'" 
database.execute(sql)
Un atacante puede ahora manipular el campo de contraseña utilizando

inyección SQL, por ejemplo introduciendo la contraseña ‘OR 1 =’ 1, lo que conduce a la siguiente consulta SQL:

sql = "SELECT id FROM users WHERE username='' AND password='contraseña' OR 1='1'

Haciendo esto, el atacante puede acceder a todas las tablas de usuarios de la base de datos, siendo la contraseña siempre válida (1 = ‘1’). Si se conecta como administrador, podrá realizar los cambios que desee.

¿Cómo evitarlo?

Es muy FÁCIL evitar los fallos de inyección.

La mejor y más sencilla forma de verificar si no existen fallos de inyección es una revisión manual exhaustiva del código fuente para comprobar si las consultas en la base de datos se realizan mediante sentencias preparadas. También puede utilizar herramientas para comprobar si existen vulnerabilidades.

Y también debería hacer lo siguiente.

  • Utilice ORM (herramientas de mapeo relacional de objetos).
  • Escape todas las entradas. Un campo de fecha nunca debe tener almacenado nada más que fechas.
  • Aísle sus datos de forma que sólo se mantenga en un lugar determinado aquello a lo que se deba acceder.
  • Escriba códigos de error de buen manejo. No haga su base de datos o su backend demasiado verboso.

Troy Hunt tiene un curso brillante sobre inyección SQL. Si le interesa, puede explorarlo.

Autenticación rota

Como ya se ha mencionado, la autenticación se ocupa de proporcionar las credenciales. Es la primera línea de defensa contra el acceso sin restricciones. Sin embargo, una mala implementación y el incumplimiento de la política de seguridad pueden dar lugar a una autenticación defectuosa.

La autenticación rota ocurre principalmente por tres patrones :

  • Relleno de cre denciales: donde el atacante dispone de una lista de nombres de usuario y contraseñas válidos y puede automatizar el ataque para averiguar si las credenciales son válidas.
  • Ataque de fuerza bruta: donde la aplicación permite contraseñas débiles para usuarios o administradores.
  • Secuestro de sesión: donde la aplicación expone el ID de sesión, la URL o no rota tras el inicio de sesión.

En todos los casos, el atacante puede obtener acceso a una cuenta importante y dependiente de la empresa que puede provocar blanqueo de dinero, robo de identidad o revelar información legalmente protegida y muy sensible.

¿Cómo prevenirlo?

Antes de implantar el sistema de autenticación, pregúntese: ¿qué podría conseguir un atacante si el sistema de autenticación se ve comprometido?

Y según la respuesta, puede hacer lo siguiente.

  • Implemente la autenticación multifactor para evitar ataques automatizados.
  • Anime (u obligue) al usuario a adoptar una buena política de contraseñas.
  • Limite los inicios de sesión fallidos.
  • Utilice algoritmos hash eficientes. Al elegir un algoritmo, tenga en cuenta la longitud máxima de la contraseña.
  • Pruebe el sistema de tiempo de espera de sesión y asegúrese de que el testigo de sesión se invalida tras el cierre de sesión.

Control de acceso roto

El control de acceso existe para garantizar lo que el usuario autenticado está autorizado a hacer. La autenticación y la gestión de sesiones son la base o las reglas de control de acceso. Pero cuando esas reglas no están bien establecidas, pueden surgir problemas importantes.

Los fallos más comunes en el control de acceso incluyen:

  • Mala configuración de CORS que permite el acceso no autorizado a la API.
  • Manipulación de metadatos para dirigir el acceso a métodos.
  • Navegación forzada: El atacante probará una URL, modificará las rutas (por ejemplo, de http://website.domain/user/ a http://website.domain/admin), e incluso puede descubrir archivos importantes.

¿Cómo evitarlo?

En la mayoría de los casos, los fallos de acceso se producen por desconocimiento de los requisitos esenciales de una gestión eficaz del acceso.

  • Deniegue por defecto excepto los recursos públicos.
  • Desactive el listado de directorios del servidor y asegúrese de que no haya archivos de copia de seguridad.
  • Limite el acceso a la API para reducir el impacto de los ataques automatizados.
  • Invalide los tokens JWT después de cerrar la sesión en el lado backend.

Exposición de datos

También conocida como violación de datos, la exposición de datos es una ciberamenaza que amenaza a las empresas y a sus clientes.

Se produce cuando la aplicación no protege adecuadamente información como credenciales o datos sensibles como tarjetas de crédito o historiales médicos. Cada minuto se produce una violación de más de 4000 registros.

El impacto en las empresas es grande desde el punto de vista financiero: Una violación media puede costar 3,92 millones de dólares, según IBM.

¿Cómo prevenirlo?

Como desarrollador de backend, debe preguntarse cuál es la información que necesita protección.

Y luego prevenir tales fallos:

  • Cifre los datos sensibles: Para los datos en REST, cifre todo. Para los datos en tránsito, asegúrese de utilizar pasarelas seguras( SSL )
  • Identifique los datos que requieren protección adicional y limite la accesibilidad sólo a un grupo de usuarios legítimos aplicando un cifrado basado en claves.
  • Evite los algoritmos de encriptación débiles: utilice algoritmos actualizados y fuertes.
  • Tenga un plan de copias de seguridad seguro.

Deserialización insegura

La serialización y la deserialización son conceptos utilizados cuando los datos se convierten en formato de objeto para ser almacenados o enviados a otra aplicación. La serialización consiste en convertir datos en formato de objeto como XML o JSON para hacerlos utilizables. La deserialización no es más que el proceso inverso.

Los ataques contra los deserializadores pueden dar lugar a ataques de denegación de servicio, control de acceso y ejecución remota de código (RCE) si existen clases que puedan modificarse para cambiar su comportamiento.

El segundo ejemplo del documento OWASP top 10 proporciona una buena ilustración del serializador de objetos PHP :

a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

Se trata de una supercookie que contiene información como el ID de usuario, el nivel del usuario y la contraseña con hash.

Un atacante puede cambiar el objeto serializado para obtener acceso a privilegios de administrador:

a:4:{i:0;i:1;i:1;s:5: "Alice";i:2;s:5: "admin";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

¿Cómo evitarlo?

Es crucial no aceptar objetos serializados de fuentes que no sean de confianza.

También debería hacerlo:

  • No confiar nunca en las entradas del usuario.
  • Validar los datos: Si su aplicación exceptúa una cadena, asegúrese de que es una cadena antes de utilizarla
  • Utilice una comprobación para asegurarse de que los datos no han sido modificados. Es útil si está enviando datos entre dos fuentes de confianza (por ejemplo, almacenando datos del lado del cliente).

Servidor XSS

ServerXSS (Cross-site scripting) es un tipo de inyección cuando un atacante utiliza una aplicación web para enviar código malicioso a diferentes usuarios. Se produce cuando el atacante envía algunos datos manipulados que contienen código malicioso que la aplicación almacena. Esta vulnerabilidad es del lado del servidor; el navegador simplemente renderiza la respuesta.

Por ejemplo, en un foro, los mensajes de los usuarios se guardan en una base de datos, a menudo sin verificar. Los atacantes aprovechan esta oportunidad para añadir posts con scripts maliciosos. Posteriormente, otros usuarios reciben este enlace por correo electrónico o ven el post en cuestión y hacen clic en él.

¿Cómo evitarlo?

Tras la identificación primaria de todas las operaciones que presentan un riesgo potencial de XSS y que deben protegerse, debe tener en cuenta lo siguiente.

  • Validar la entrada: compruebe la longitud de la entrada, utilice la concordancia regex y sólo permita un determinado conjunto de caracteres.
  • Valide la salida: Si la aplicación copia en sus respuestas algún dato que proceda de algún usuario o de un tercero, estos datos deben codificarse en HTML para desinfectar los caracteres potencialmente maliciosos.
  • Permita limitar el HTML: por ejemplo, si tiene un sistema de blog de comentarios, sólo permita el uso de determinadas etiquetas. Si puede, utilice un marco adecuado al marcado HTML suministrado por el usuario para intentar asegurarse de que no contiene ningún medio de ejecución de JavaScript.

Conclusión

La fase de desarrollo es crucial para la seguridad de las aplicaciones web. Y debería considerar la posibilidad de incluir un escáner de vulnerabilidades de seguridad en el ciclo de vida del desarrollo, para que los problemas identificados se solucionen antes de la producción.