17 may 2021

Consejos de ciberseguridad en el desarrollo de software

Buenas a todos! Hoy os traigo una serie de consejos a seguir sobre seguridad aplicada al desarrollo de software.




1. Mantener el software y las dependencias actualizadas

Una gran parte de las páginas web son vulnerables a través de exploits, publicados (o no) a través de CVE (Common Vulnerabilities and Exposures).


Ilustración: Y mira que npm nos avisa..

Podéis consultar si vuestro software y versión tienen algún tipo de CVE publicado a través de este enlace.

Existen multitud de páginas web donde consultar exploits de todo tipo de software y las cuales, son realmente útiles para posibles atacantes.

Breve inciso: Utilizad las menores dependencias posibles.

2. Forzar el acceso al website a través de HTTPS

Como muchos sabréis, HTTPS realiza un cifrado en dos direcciones para las comunicaciones entre el servidor y los clientes enviando los datos a través de SSL/TLS.


Pero.. ¿Esto qué significa?

Básicamente, que es más seguro, puesto que los datos que viajan hacia y desde la web van cifrados. Tenemos varias publicaciones creadas por @mikiminoru sobre las suites de TLS/SSL donde explica de forma extensa la importancia de una configuración correcta, como comprobar las vulnerabilidades y las recomendaciones para cada caso.



Pero.. ¿Esto quiere decir que un sitio web al que accedemos a través de HTTPS es seguro?

Para nada, es un error bastante común pensar que una web que utiliza HTTPS es segura y NO ES ASÍ puesto que la comunicación está cifrada, pero no sabemos si la web en sí está realizando un uso fraudulento de tus datos.
Además, en caso de ser una web fiable, pueden estar cometiendo errores de configuración.


Vale, entonces, si es seguro.. ¿No tendría que hacer nada más?

Por supuesto que sí, es solo una capa de protección adicional, para tener una página web segura debes seguir todos los puntos de este post y muchos más que seguiremos explicando en futuras publicaciones.


3. Injection

En este punto, trataremos de explicar en general las posibles vulnerabilidades a través de injection, en este caso hablaremos de las siguientes: SQL, NoSQL, XML, ORM queries.

Consejos principales:

  • Validación de inputs.

  • Escapar y "limpiar" todas las variables recibidas del usuario. (Escape, Sanetize)

  • Uso de procesos almacenados cuando sea posible.

  • Uso de consultas parametrizadas.

  • Hacer cumplir el Principio de mínimo privilegio.

  • WAF

SQL Injection  'or' '1' = '1

sqlQuery='SELECT * FROM custTable WHERE User='' OR 1=1-- ' AND PASS=' + password

Los ataques de inyección SQL pueden realizarse en consultas SQL poco seguras.
Podéis ver información ampliada sobre esto en el siguiente enlace: SQL Injection Prevention Cheat Sheet

NoSQL

Así es, las consultas NoSQL a pesar de ser "más seguras", no se libran de ser atacadas.
Podéis consultar diferentes formas de inyección NoSQL en este enlace, además de diferentes formas de evitarlos.

XML Parsers

Existen diferentes formas de explotar la inyección sobre XML, varias de ellas son mencionadas aquí.

ORM Queries

Efectivamente, las consultas a través de ORM  (Object-relational mapping) tampoco son completamente seguras. Sobre todo, si se hace un mal uso de ellas 😉
Podéis ver varios ejemplos genéricos en el siguiente enlace Testing for ORM Injection.


4. XSS o Cross Site Scripting

Este tipo de ataques son similares a los ataques de inyección, pero en este caso, el objetivo del atacante no es la base de datos, sino los usuarios que se conectan a la página.

A veces, con fin de conseguir información de usuario y otras, para realizar redirecciones a páginas fraudulentas.

Ejemplo: En un input escribir <script type =’text / javascript’> alert (‘Test XSS’); </ script>

Aquí está el enlace con ejemplo de su uso y como protegernos.

5. Autenticación

Según OWASP la política de contraseñas seguras debe ser la siguiente:

  • Mínimo 8 caracteres.

  • NO establecer un máximo de caracteres para las contraseñas.

  • NO partir contraseñas. (Cifrar en SHA256 y a continuación en Bcrypt)

  • Permitir el uso de todo tipo de caracteres incluidos unicode y espacios en blanco.

  • Asegurar la rotación de contraseñas cuando sean filtradas o en el momento en que se encuentre una vulnerabilidad.

  • Mostrar un "Strength-meter" o "Medidor de fuerza" para que el usuario sepa en todo momento la seguridad de su contraseña.

Además, existen errores a nivel de implementación de software que pueden ser subsanados para asegurar a los usuarios y la plataforma:

  • Implementar un mecanismo seguro de recuperación de contraseñas.


  • Comparar los hashes con funciones seguras. (EJ: password_verify() en PHP)

  • Trasmitir las contraseñas a través de un protocolo seguro. (TLS u otros)

  • Solicitar de nuevo el acceso para acciones más críticas.

  • Solicitar 2FA para acciones más críticas. Podéis ver un ejemplo aquí de fraude por la no utilización de 2FA publicado por mi compañero Daniel González.

  • Transacciones autorizadas. Hay varios métodos de implementar esto, por lo que os dejo el siguiente enlace para que veáis algunos ejemplos.

  • Control de los errores de autenticación.
    Este punto, básicamente, se trata de proporcionar errores genéricos, donde no aparezcan datos sensibles de ser explotados o utilizados para extraer datos.

    Algunos ejemplos de errores demasiado descriptivos y que deberían ser generalizados:

    • The user ID or password was incorrect.
    • The account does not exist.
    • The account is locked or disabled.
    • The account exists but password doesn’t match.
           Ejemplo de errores genéricos:
    • Invalid user or password.
    • If that email address is in our database, we will send you an email to reset your password.
    • A link to activate your account has been emailed to the address provided.

  • Protección ante ataques automatizados. (Brute force, Credentials Stuffing, Password Spraying)

    Vamos a nombrar diferentes formas de protegernos contra estos ataques:

  • Uso de protocolos de autenticación no basados en contraseñas

  • Promover el uso de software de gestión de contraseñas. EJ: KeePass

  • Monitorización

    Como sabréis, una parte muy importante de la seguridad es la monitorización, por ello, es más que indispensable la revisión de los posibles ataques, cuentas bloqueadas etc y la aplicación de políticas de seguridad basadas en los resultados.

6. Auditoria

Todos estos conceptos son aplicables por un equipo técnico cualificado y especializado en ciberseguridad y desarrollo.

A pesar de existir todos estos métodos, la única forma de tener una plataforma y entorno seguro, es realizando una auditoria completa a toda la infraestructura y aplicando los correspondientes métodos de "aseguramiento" en cada uno de los nodos afectados.

Esperamos que toda esta información os sea de gran ayuda en vuestros proyectos y tengamos, en un futuro, sitios más seguros. Y recordad, si precisáis de una compañía externa que revise la seguridad de vuestras aplicaciones, no dejéis de contactarnos en nuestro correo info@zerolynx.com. Mis compañeros del laboratorio cyber estarán encantados de atenderos.

Saludos!


en
Etiquetas:

No hay comentarios:

Publicar un comentario

Suscribirse a: Enviar comentarios (Atom)