OWASP
¿Qué es OWASP?
Sin embargo, la faceta más conocida es el documento denominado The OWASP Top 10 Web Application Security Risks.
Este documento es una recopilación de buenas prácticas aplicables a la seguridad de aplicaciones, especialmente aplicaciones web, que , en palabras de la propia fundación, representa un amplio consenso acerca de los riesgos más críticos en la seguridad de aplicaciones web.
Las recomendaciones son el tema principal que vamos a tratar.
The OWASP Top 10 Web Application Security Risks
A1:2017-Injection. (Inyección de código)
Los ataques de inyección se producen cuando un atacante consigue enviar datos no confiables a un intérprete como parte de un comando o consulta a BBDD.
Estos datos maliciosos pueden hacer que el intérprete ejecute comandos no consultas no deseadas, e incluso que pueda acceder a datos sin autorización.
Estos ataques pueden mitigarse filtrando las peticiones mediante expresiones regulares que capturen patrones concretos en todos los elementos que puedan introducir código en el servidor (cookies, cabeceras, parámetros, cuerpos de peticiones, etc).
También es recomendable el uso de APIs seguras que no utilicen el intérprete al completo, o bien provean una interfaz parametrizada que permita separar los datos de las consultas.
A2:2017-Broken Authentication. (Autenticación rota)
Algunos de los API managers más utilizados del mercado proveen funcionalidad que evita este tipo de ataques mediante servidores dedicados de autenticación, seguridad OAuth, JWT y otros mecanismos.
Sin embargo también deben cuidarse otros aspectos para evitar ataques relacionados con el robo de credenciales:
Implementar autenticación multi factor siempre que sea posible
No usar credenciales por defecto en despliegues de productos comerciales.
Establecer una política de fortaleza de contraseñas y realizar chequeos periódicos de la fortaleza de contraseñas cambiadas recientemente
Limitar o retardar incrementalmente el número de reintentos de autenticación. Registrar todos los accesos y establecer sistemas de alerta para detectar ataques de fuerza bruta, robo de credenciales, etc.
A3:2017-Sensitive Data Exposure. (Exposición de datos sensibles)
A4:2017-XML External Entities (XXE). (Entidades XML externas)
La mejor forma de mitigar estos ataques es determinar de forma precisa el contenido que admite la aplicación en el cuerpo de las peticiones, de forma que si no se usa XML no se permita enviar dicho contenido. Si, por el contrario, se permite el envío de XML es mejor deshabilitar los DTDs y evaluar el contenido de las peticiones siempre.
A5:2017-Broken Access Control. (Control de acceso roto)
Es necesario contar con un mecanismo de control de acceso que puede implementarse de distintas formas. Puede aplicarse a nivel de usuario o aplicación, tanto por endpoint como a nivel de API o aplicación completa. Puede hacerse uso de scopes OAuth o mecanismos de grano más fino como XACML.
A6:2017-Security Misconfiguration. (Configuración de seguridad errónea)
Algunos de los API managers más utilizados del mercado proveen funcionalidad que evita este tipo de ataques mediante servidores dedicados de autenticación, seguridad OAuth, JWT y otros mecanismos.
Sin embargo también deben cuidarse otros aspectos para evitar ataques relacionados con el robo de credenciales:
Implementar autenticación multi factor siempre que sea posible
No usar credenciales por defecto en despliegues de productos comerciales.
Establecer una política de fortaleza de contraseñas y realizar chequeos periódicos de la fortaleza de contraseñas cambiadas recientemente
Limitar o retardar incrementalmente el número de reintentos de autenticación. Registrar todos los accesos y establecer sistemas de alerta para detectar ataques de fuerza bruta, robo de credenciales, etc.
A7:2017-Cross-Site Scripting XSS. (Ataques de scripting entre dominios)
La mitigación de este tipo de ataques pasa por usar frameworks seguros, como React JS, en la aplicación frontal. También es posible codificar los datos de peticiones HTTP no fiables en la salida HTML. No obstante, la protección más eficaz es aplicar una política de seguridad de contenidos que impida colocar scripts en el navegador del cliente, asumiendo que no hay otras vulnerabilidades en los contenidos procedentes de fuentes externas como CDNs.
A8:2017-Insecure Deserialization (Deserialización insegura)
Estos ataques aprovechan la funcionalidad adicional ofrecida por la deserialización nativa de muchos lenguajes de programación usándola de forma maliciosa. La forma más segura de mitigarlos es no aceptar objetos serializados de fuentes no fiables o permitir sólo objetos con tipos de datos primitivos. No obstante, esto no es siempre posible. En ese caso pueden aplicarse otras técnicas, algunas de las cuales dependen del lenguaje en el que esté implementada la aplicación.
A9:2017-Using Components with Known Vulnerabilities.
Es muy importante mantener actualizados e instalar los parches de seguridad de todos los componentes implicados en el sistema: aplicación cliente, API Managers, servidores de identidad, proxies y balanceadores de carga, aplicación backend, etc.
Esto debería ser un proceso regular acorde a una metodología de trabajo que incluyese:
Retirada de dependencias y archivos obsoletos, funcionalidad innecesaria, etc.
Inventariado continuo de las versiones de los componentes a lo largo de todo el sistema. La suscripción a las alertas de seguridad de cada componente es estrictamente necesaria para llevar a cabo este proceso adecuadamente.
Obtención de componentes desde fuentes oficiales y confiables. Elegir siempre archivos firmados que puedan verificarse para minimizar el riesgo de manipulación de componentes.
Monitorizar componentes obsoletos o sin mantenimiento para buscar alternativas.
A10:2017-Insufficient Logging & Monitoring.
Las respuestas de las aplicaciones o APIs hacia el consumidor cuando se produce un error no deben ofrecer más información de la estrictamente necesaria, pero internamente se debe detallar el error lo máximo posible (logging). De esa forma, si se programan auditorías periódicas de seguridad o se dispone de un sistema de alertas (monitoring) pueden detectarse ataques de forma temprana o, al menos, periódica.
Es altamente recomendable usar plataformas de logging centralizadas y sistemas de monitorización y alerta.
Blog realizado por David Marín
¡Habla con nuestros expertos!
