El documento habla sobre la importancia de incorporar la seguridad de la información en el desarrollo de aplicaciones. Explica que la seguridad debe ser parte de los requerimientos, el diseño y las pruebas de las aplicaciones para prevenir defectos. También recomienda realizar capacitación al personal de desarrollo, seguir guías de desarrollo seguro, y utilizar técnicas como revisiones de código y pruebas automatizadas para mejorar la seguridad.

1. 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

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

3. 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

4. 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

5. Concientización y
Entrenamiento del Personal
55

6. 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

7. 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

8. Requerimientos de Seguridad
88

9. Requerimientos de Seguridad
• 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

10. Requerimientos de Seguridad
• 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

11. Identificación de Amenazas
1111

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

13. 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

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

15. 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

16. Guías para el Diseño Seguro
1616

17. 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

18. Pruebas de Seguridad for
1818

19. 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

20. 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

21. 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

22. 1. Cross Site Scripting (XSS)
2222

23. 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”

24. 2. Injection Flaws
2424

25. 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

26. 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

27. 3. Inclusión insegura de
archivos remotos
2727

28. 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

29. 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

30. 4. Insecure Direct Object
Reference
3030

31. 4. Insecure Direct Object
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

32. 4. Insecure Direct Object
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

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

34. 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

35. 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

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

37. 6. Fuga de Información y Manejo
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

38. 6. Fuga de Información y Manejo
Inadecuado de Errores
• Vulnerabilidades
– comentarios en el código fuente
– mensajes de error
3838

39. 6. Fuga de Información y Manejo
Inadecuado de Errores
• 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

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

41. 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

42. 7. Débil Protección de Elementos
de Sesión y Autenticación
• 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

43. 7. Débil Protección de Elementos
de Sesión y Autenticación
• 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

44. 8. Almacenamiento inseguro
de funciones criptográficas
4444

45. 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

46. 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

47. 9. Comunicaciones Inseguras
4747

48. 9. Comunicaciones Inseguras
• 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

49. 9. Comunicaciones Inseguras
• 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

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

51. 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

52. 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

53. 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

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