¿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
Comentarios
Publicar un comentario
Dejanos tus dudas y comentarios