OWASP, Consejos de Seguridad en Desarrollos de Software

Buena semana, hoy tenemos al último invitado de este año 2019, que es el Ingeniero Omar Gilbaja, tuve la oportunidad de trabajar con él hace unos 2 años, él tiene mucha experiencia en desarrollo de Software desde hace 10 años principalmente .NET , ha dado clases a nivel Universidad, conoce varios ERP's (Epicor, QAD...) , ha realizado desarrollos en la industria privada, pymes, etc.., su página WEB es https://flashiqro.com/ para que puedan contactarlo.

El tema del que nos va a platicar Omar es como desarrollar aplicaciones más seguras dándonos algunos consejos, estamos seguros que les será de utilidad, los dejo con Omar:

Si eres del área de TI por ende alguna vez te has cuestionado si los sistemas son seguros, quizás hasta te has respondido “mi seguridad es de lo mejor, mi firewall detiene todo, el login de X sistema esta mas que probado” y yo refutaría tus comentarios preguntándote ¿Qué estándares de seguridad de la información tienes? ¿Desarrollas correctamente? ¿Tienes un token? ¿Puedes haber omitido o ignorado la seguridad en algún sistema con información sensible (datos personales, nominas, transacciones monetarias, etc.)?  Se que la respuesta automática será un estado de duda debido a que no todas las organizaciones o personas conocen las vulnerabilidades que sus sistemas hechos en casa, comprados o proveídos por un tercero.

Existe una organización sin fines de lucro que se dedica a ayudar, recolectar y compartir documentación, recomendaciones y algunas herramientas sobre vulnerabilidades de seguridad que se pueden presentar en los sistemas informáticos y las organizaciones, dichas vulnerabilidades pueden ser aprovechadas por algún hacker para fines maliciosos, aunque no necesitamos irnos tan lejos también el usuario funcional puede aprovecharlas en su beneficio y así omitir pasos de un proceso en algún sistema que maneje, etc.

OWASP es la organización que ha estado documentando estas vulnerabilidades en el desarrollo o implementación de software para fines prácticos y de prevención, es importante entender que no se señala un software específico ni se divulga cuál es su vulnerabilidad, solo se documenta y detalla el error para evitarlo o corregirlo en la aplicación y futuros desarrollos. Existen diversos tipos de vulnerabilidades que tienden a ser mas comunes de los que crees.

Hasta el momento OWASP tiene documentados cerca de 63 tipos de vulnerabilidades de diversas complejidades y/o afectaciones.

¿Cuáles son los riesgos de seguridad de aplicaciones?

Los atacantes pueden utilizar diferentes rutas a través de tu aplicación para perjudicar el negocio u organización. Cada uno de estos caminos representa un riesgo que puede o no ser suficientemente grave como para merecer atención oportuna o inmediata.

Brevemente escribiré un top 5 de las principales vulnerabilidades que en mi experiencia he encontrado y resuelto sobre los proyectos de desarrollo de software en los que he trabajado y algunos consejos prácticos de como prevenirlas ya sea que desarrolles software o al menos tengas conciencia de los riesgos que pudieran suscitarse.

1.       Inyección.

Para que tengas un punto de referencia una de las mas comunes es la validación de entrada o acceso de un usuario, pero concretamente ¿a que se refiere esto? No existe un login y/o no valida correctamente las credenciales de acceso a la aplicación.

Aquí hago una pregunta muy simple, si tienes un login, ¿Cómo haces la validación? Espero que dentro del back de tu aplicación no hagas consultas directas a BD, y sobre todo que tu respuesta no sea la siguiente “SELECT dato FROM tabla WHERE usuario = campoTexto1 AND Contraseña == campoTexto2”. Si es así, con urgencia cambia a esa lógica y utiliza Store Procedures para hacer consultas a BD y evites tener vulnerabilidad de Inyección de SQL.

Recomendación:

·         Validar, filtrar y sanitizar las entradas antes de hacer las consultas.

·         Utilizar Store Procedures, no consultas directas a los manejadores o sistemas.

·         Control de acceso con privilegios.

·         Usar una capa de datos, intermediario entre la entrada de datos y el manejador.

2.       Perdida de Autenticación

Cuando no se implementa correctamente la autenticación en la aplicación puede llevar a un problema de escalación de privilegios, robo de sesión pudiendo asumir la identidad de otros usuarios de manera temporal o permanente.

El software queda vulnerable al permitir contraseñas débiles, almacenar contraseñas en texto plano, sesiones sin límite de tiempo, información de sesión visible, no utilizar protocolos de cifrado o cifrado antiguo o débil, no utilizar un token y la mas común, falta de capacitación al personal en temas de seguridad y protección de información.

Recomendaciones:

·         Política de construcción de contraseñas.

·         Gestión de sesiones.

·         Uso de certificados de seguridad.

·         Implementación de tokens.

·         Manejo y control de errores por defecto.

·         Evitar utilizar cookies y variables de sesión.

3.       Exposición de datos sensibles

Por descuido u omisión se muestran datos sensibles como información personal, financiera, confidencial, etc. y con ello algún atacante puede utilizar técnicas como escaneos pasivos para encontrar esta información expuesta y explotarla para su beneficio.

Los atacantes pueden robar o modificar estos datos protegidos inadecuadamente para llevar a cabo fraudes con tarjetas de crédito, robos de identidad u otros delitos. Los datos sensibles requieren métodos de protección adicionales, como el cifrado en almacenamiento y tránsito.

Mas de una vez escuche y vi gente que coloca información de mas “por si el usuario lo necesita”, eso es un error común que puede exponer información aun y cuando no sea mostrada directamente en la pantalla de la aplicación.

Recomendación:

·         No almacenar datos sensibles o información innecesaria a nivel de aplicación.

·         Cifrado de información.

·         Uso de protocolos de comunicación segura.

·         Delimitar conexión.

·         Deshabilitar cache.

·         Control y gestión de información que está expuesta (no mostrar información de más)

4.       Entidades Externas XML

Muchos procesadores XML antiguos o mal configurados evalúan referencias a entidades externas en documentos XML. Las entidades externas pueden utilizarse para revelar archivos internos mediante la URL o archivos internos en servidores no actualizados, escanear puertos de la LAN, ejecutar código de forma remota y realizar ataques de denegación de servicio (DoS), todo eso el poder ingresar código malicioso dentro del XML que se ejecute al ser cargado.

Recomendación:

·         Utilizar tecnologías JSON y REST APIs

·         Actualización de SOAP 1.2 o superior

·         Validación del archivo xml previo su elección.

5.       Secuencia de Comandos en Sitios Cruzados

Los XSS ocurren cuando una aplicación toma datos no confiables y los envía al navegador web sin una validación y codificación apropiada; o actualiza una página web existente con datos suministrados por el usuario utilizando una API que ejecuta JavaScript en el navegador. Permiten ejecutar comandos en el navegador de la víctima y el atacante puede secuestrar una sesión, modificar (defacement) los sitios web, o redireccionar al usuario hacia un sitio malicioso.

·         En caso de una web siempre utilizar certificados de seguridad (HTTPS)

·         Habilitar una Política de Seguridad de Contenido (CSP) es una defensa profunda para la mitigación de vulnerabilidades XSS.

Content-Security-Policy: policy

·         Aplicar codificación sensitiva al contexto, cuando se modifica el documento en el navegador del cliente, ayuda a prevenir DOM XSS

Te dejo algunas pequeñas recomendaciones que también he aplicado y espero te sirvan.

·         Siempre utiliza Store Procedures, evita el Sql Inyection.

·         Controla la apertura y cierre de conexiones y peticiones a BD.

Si desarrollas web utiliza lo siguiente:

·         HTTPS con una versión de SSL actual.

·         No guardes en cache

<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" />

<meta http-equiv="Pragma" content="no-cache" />

·         Siempre codifica en UTF-8, otras codificaciones son vulnerables a inserciones de código.

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

·         Coloca el tipo de archivo y la codificación en CSS y JS.

<link href="./sistema/css/style.css" rel="stylesheet" type="text/css" charset="utf-8" />

<script src="assets/plugins/bootstrap/js/bootstrap.min.js" type="application/javascript" charset="utf-8"></script>

·         Implementa token en lugar de variables de sesión, de esta forma cada transacción que hagas tendrá que validar el token y eso garantizara que el usuario tiene acceso y permiso a realizar dicha transacción.

En conclusión, cómo buen desarrollador debes considerar como buena práctica el conocer, prevenir y/o minimizar estas vulnerabilidades de seguridad en el software que produces, al final del día es tu creación, ese pequeño hijo del que quieres estar orgulloso y no preocupado porque sea vulnerable a algún ataque mal intencionado.

Si quieres conocer información más detallada siéntete libre de escribirme un mail a ogilbaja@flashiqro.com, con tus dudas y/o comentarios y con gusto poder orientarte en base a mi experiencia.

Pueden seguirnos también en nuestra página de Facebook