Incorporando la Seguridad de la Información en el Desarrollo de Aplicaciones

Click to edit Master subtitle style
Incorporando la Seguridad de la
Información en el Desarrollo de
Aplicaciones
Alfredo Aranguren T., CISSP
Especialista en Seguridad de
Información

Objetivo
22
Exponer las principales
tendencias en cuanto a
Seguridad de Información y la
importancia de la seguridad en
el desarrollo de aplicaciones.

Gente / Procesos / Tecnología
33
Concientización
Capacitación
Guías
Desarrollo Seguro
Configuraciones
Seguras
Pruebas de
Seguridad
Revisión de
Código Seguro
Pruebas
Automatizadas
Firewalls
de
Aplicación

Datos Relevantes
• Revisiones de código (peer reviews)
– IBM redujo un 82% de los defectos antes de
comenzar las pruebas.
– 80% de los defectos es probable que no sean
detectados en las pruebas
– Es 100 veces más costoso solucionar un
problema de seguridad en producción que en
el diseño (IBM Systems Sciences Institute)
44
Ref: http://ganssle.com/Inspections.pdf

Concientización y
Entrenamiento del Personal
55

Concientización y Entrenamiento
del Personal
• El soporte de la alta dirección es crucial.
• Se debe de hablar en términos de
Negocio
– Creación de Valor
– Administración de los riesgos del negocio
66

Concientización y Entrenamiento
del Personal
• Entre el 70% y el 90% de las aplicaciones
web tiene vulnerabilidades serias porque
– El desarrollador promedio no está lo
suficientemente capacitado y entrenado.
• Introducir controles de seguridad en el
desarrollo e implementación permitirá
– Mayor disponibilidad, menor TCO
– Controlar y mitigar riesgos
77

Requerimientos de Seguridad
88

• Los aspectos de seguridad deben ser
parte de los requerimientos
• El negocio debe de estar informado de los
riesgos
• Base sólida para controles de seguridad
posteriores
• Definir estándares para requerimientos de
seguridad
– Cuales controles son necesarios
– Cuando son necesarios
– Por qué son necesarios 99

• Generar un conjunto genérico de
requerimientos de seguridad
– Debe incluir todos los mecanismos de
seguridad.
– Debe considerar todas las vulnerabilidades
comunes.
– Debe considerar casos de mal uso.
– Considerar aspectos tales como
regulaciones, buenas prácticas, estándares,
etc.
1010

Identificación de Amenazas
1111

Para qué?
• Para entender el ambiente operativo en
donde se encuentra la aplicación.
• Para identificar, analizar, documentar y
mitigar riesgos.
1212

Administración de Riesgos
• Seleccionar estrategias de mitigación
basadas en las amenazas identificadas.
• Beneficios:
– Prevenir defectos en el diseño de la
seguridad
– Identificar y manejar los principales riesgos
– Mejorar el entendimiento y concientización de
los riesgos
– Permitir el concenso en el equipo de trabajo
– Lograr la justificación de costos para los
controles necesarios
1313

Evaluación y Mitigación de Riesgos
• Administrar los riesgos ocasionados por
fallas de seguridad que generan impactos:
– Financieros
– Operativos
– Legales
– Imagen
1414

Cumplimiento Legal y Regulatorio
• Cumplir con requerimientos legales y
regulatorios
• La administración de riesgos es
obligatoria para la mayoría de las
regulaciones:
– Ejemplo de marcos de referencia de control
interno: CobiT, ISO 17799
– Ejemplo de regulaciones: Basilea II,
Sarbanes-Oxley, FDA, HIPAA
1515

Guías para el Diseño Seguro
1616

Diseño Seguro
• Principios
– Asegure el eslabón más débil
– Implemente la seguridad por capas
– Fallas de manera segura
– Seguir el principio del menor privilegio
– Compartimentalización (compartmentalize)
– Mantenga las cosas simples
– Promueva la privacidad
– Recuerde que guardar secretos es dificil
– Sea reacio a confiar
– Segregación de funciones 1717

Pruebas de Seguridad
• Identificar errores de seguridad durante las
pruebas
• Desarrollar casos para pruebas de
seguridad
–Basados en los requerimientos
–Probando todos los mecanismos de seguridad
y vulnerabilidades comunes
1919

OWASP Top 10
• Se refiere a las diez vulnerabilidades de
seguridad más críticas de las aplicaciones
web
• Son un buen principio, pero no un
estándar
2020

OWASP Top 10 2007
1. Cross Site Scripting (XSS)
2. Injection Flaws
3. Inclusión insegura de archivos remotos
4. Insecure Direct Object Reference
5. Falsificación de petición en sitios cruzados (Cross Site
Request Forgery -CSRF)
6. Fuga de información y manejo inadecuado de errores
7. Débil protección de elementos de sesión y autenticación
8. Almacenamiento inseguro de funciones criptográficas
9. Comunicaciones inseguras
10. Fallas para restringir el acceso mediante URL´s
http://www.owasp.org/index.php/Top_10
2121

1. Cross Site Scripting (XSS)
2222

1. Cross Site Scripting
• Descripción
– El HTML generado por el cliente es ejecutado por
el navegador web
• reflejado: enlaces en correos, páginas web...
• almacenado: correo web, foros, blogs...
• inyección a través de DOM: manipulando document.URL,
document.location...)
• Recomendaciones
– Validar y/o codificar todos los parámetros antes de
incluirlos en páginas HTML
– Validar usando principalmente “listas blancas”

2. Injection Flaws
• Descripción
– Los datos proporcionados por el usuario son
enviados a un interpretador como parte de un
comando o de un query
– El más comun es SQL injection
– Todas las aplicaciones web que usan
interpretadores son vulnerables a este tipo de
ataques.
2525

2. Injection Flaws
• Recomendaciones
– Verificar que el usuario no puede modificar
comandos o queries enviados a cualquier
interpretador usado por la aplicación.
– Es útil hacer revisiones de código para
detectar este tipo de vulnerabilidades
– No confiar en la validación realizada por el
cliente
– Normalizar los valores de entrada
– Aplicar validación en el servidor
– Restringir los tipos de datos aceptados
2626

3. Inclusión insegura de
archivos remotos
2727

3. Inclusión Insegura de Archivos
Remotos
• Descripción
– Permite al atacante ejecutar código remoto,
comprometiendo archivos de entrada;
causado comúnmente por confiar
indebidamente de archivos de entrada
– Todas las aplicaciones que permiten que se
ejecuten archivos cargados, son vulnerables
2828

3. Inclusión Insegura de Archivos
Remotos
• Recomendaciones
– Usar referencias indirectas
– Diferenciar datos validados de los del usuario
– Validar la entrada usando “listas blancas”
– Filtrar los intentos de acceso remoto desde el
servidor web
– Usar mecanismos de aislamiento: chroot, jail,
máquinas virtuales...
– Usar mecanismos del lenguaje: tainting,
allow_url_fopen...
2929

4. Insecure Direct Object
Reference
3030

Reference
• Descripción
– La aplicación expone una referencia a un
objeto interno
• directorio
• registro de una base de datos
– Las referencias a objetos internos están
expuestas.
– Los atacantes usan manipulación de
parámetros para cambiar referencias y violar
políticas de control acceso débiles.
– Las referencias a las llaves de bases de
datos están expuestas. 3131

Reference
• Recomendaciones
– Evitar exponer las referencias
– Validar todas las referencias a objetos
– Verificar la autorización en todos los accesos
– Usar índices o mapas de referencias (
http://www.example.com/application?file=1)
– Verificar la autorización
3232

5. Falsificación de petición en
sitios cruzados (CSRF))
3333

5. Falsificación de Petición en
Sitios Cruzados (CSRF)
• Descripción
– Provocar que el navegador genere peticiones
HTTP ocultas a recursos restringidos
– Se aprovecha la autentificación implícita
• Autentificación HTTP (ej: usuario y contraseña)
• Cookies
• Autentificación SSL del cliente
• Autentificación basada en IP’s
3434

5. Falsificación de Petición en
Sitios Cruzados (CSRF)
• Recomendaciones
– Usar un token de autorización que no sea
enviado automáticamente por el navegador.
– Eliminar cualquier vulnerabilidad de XSS en la
aplicación.
– Añadir una petición a una variable de un sólo
uso al URL y formas adicional a la sesión
estándar.
– Requerir pantallas de login adicionales para
datos sensibles.
– No use GET para requerir datos sensibles
3535

6. Fuga de Información y Manejo
inadecuado de Errores
3636

Inadecuado de Errores
• Descripción
– Las aplicaciones filtran información sensible
• sobre su configuración, diseño interno...
• datos privados a los que tienen acceso
– La información puede ser usada para otros
ataques
3737

• Vulnerabilidades
– comentarios en el código fuente
– mensajes de error
3838

• Recomendaciones
– El objetivo es que la aplicación no divulge
mensajes de error detallados.
– Comprobar la aplicación con todo tipo de
datos de entrada inválidos y analizar los
mensajes generados
– Deshabilitar o limitar los detalles mostrados
sobre errores (especialmente de capas
internas: BD, SO...)
– No usar los gestores de error por defecto
– Garantizar que los caminos de ejecución
sensibles devuelven mensajes de error3939

7. Debil protección de elementos
de sesion y autenticación
4040

7. Débil Protección de Elementos
de Sesión y Autenticación
• Descripción
– Fallo al proteger credenciales y tokens de
sesión
• Causas
– Fallas en los principales mecanismos de
autenticación.
– Debilidades en la administración de
contraseñas.
– Fallas en los tiempos de desconexión de las
sesiones.
4141

• Recomendaciones
– Usar SSL exclusivamente para todo acceso
autenticado
– Encriptar todas las credenciales y tokens para
almacenarlos (A8)
– Planificación cuidadosa
• No exponer datos sensibles en URLs o registros
• Utilizar un único mecanismo de autentificación
• No usar direcciones IP, consultas al DNS o
“referrer headers” para autenticación
• Ser cuidadoso con el envío de contraseñas a
direcciones de correo
4242

• Limitar o eliminar el uso de cookies para la
autenticación o gestión de sesiones (ej: recordar al
usuario en el sitio web)
• No aceptar id. de sesión nuevos, preestablecidos
o inválidos en URLs o peticiones (evitar “session
fixation attacks”)
• Crear una nueva sesión tras la autentificación o
cambio de nivel de privilegio
• Proporcionar enlaces para desconectarse
• Utilizar mecanismos de autodesconexión
• Asegurar que la liga de logout destruye todos los
datos pertinentes.
4343

8. Almacenamiento inseguro
de funciones criptográficas
4444

8. Almacenamiento Inseguro de
Funciones Criptográficas
• Descripción
– Fallas al encriptar datos sensibles
• No encriptarlos
• Utilizar algoritmos criptográficos propios
• Usar incorrectamente algoritmos fuertes
• Continuar usando algoritmos débiles (MD5, SHA-
1, RC3, RC4...)
• Usar claves preprogramadas o almacenarlas
desprotegidas.
4545

8. Almacenamiento Inseguro de
Funciones Criptográficas
• Recomendaciones
– Sólo almacenar lo imprescindible
– Usar algoritmos probados (no crear nuevos)
• AES, RSA para criptografía asimétrica
• SHA-256 o mejores para “hashing”
• http://www.owasp.org/index.php/Guide_to_Cryptograph
– No usar algoritmos débiles (ej: MD5, SHA-1)
– Gestión cuidadosa de claves
• Generarlas fuera de línea
• Almacenar las claves privadas con extremo
cuidado
• Nunca transmitirlas por canales inseguros4646

9. Comunicaciones Inseguras
4747

• Descripción
– Las aplicaciones frecuentemente fallan en
encriptar el tráfico de la red cuando es
necesario proteger comunicaciones sensibles
– Se recomienda usar SSL para todas las
conexiones autenticadas.
4848

• Recomendaciones
– Usar SSL para conexiones autenticadas o
que transmiten información sensible
(credenciales, números de tarjeta de crédito,
datos de salud...)
– Encriptar la comunicación en la
infraestructura (con servidores de
aplicaciones, bases de datos, LDAP...)
– No permitir que se pueda pasar a un modo
inseguro (ej: cuando ocurre algún fallo en las
comunicaciones o falla algún componente)
4949

10. Falla para restringir el
acceso mediante URL’s
5050

10. Falla para Restringir el Acceso
Mediante URL’s
• Descripción
– No permitir acceso a funciones basándose en
el URL
• Es un ejemplo de seguridad mediante oscuridad
• URLs secretas, difíciles de adivinar...
• Evaluar el control de acceso en el cliente
• Permitir acceso sólo a ciertos tipos de carpetas(ej:
HTML, PDF...)
• Mantener actualizados los componentes que
manejan datos proporcionados por usuarios
(imágenes, XML, textos...)
5151

10. Falla para Restringir el Acceso
Mediante URL’s
• Recomendaciones
– Usar una matriz de control de acceso
– Restringir el acceso a URLs y funciones en
cada paso
– Realizar pruebas de penetración
– No asumir que los usuarios desconocen
ciertas URLs o APIs
5252

Fuentes
• www.owasp.org
• Programación Segura
– Carlos Pérez Conde
– Departament d'Informàtica
– Escola Técnica Superior d'Enginyeria
– Universitat de València

Click to edit Master subtitle style
Preguntas y Respuestas
Alfredo Aranguren T., CISSP
alfredo@aranguren.com.mx

Incorporando la Seguridad de la Información en el Desarrollo de Aplicaciones

Más contenido relacionado

Incorporando la Seguridad de la Información en el Desarrollo de Aplicaciones

Notas del editor