¿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