Title: Desarrollo Seguro de Aplicaciones en 'NET
1Desarrollo Seguro de Aplicaciones en .NET
Chema AlonsoMVP Windows Server Security
Informática 64 Ricardo VarelaMVP C José
Parada GimenoIT Pro EvangelistMicrosoft
2Principios de Seguridad
3Seguridad
- La seguridad depende de 3 factores
- Procesos
- Procedimientos y operaciones en nuestros entornos
- Personas
- Poca formación
- Tecnología
- Estándares (TCP/IP)
- Desarrollos personales
- Productos de los fabricantes (IIS,Apache)
4Que es Seguridad?
- Seguridad, es un termino relativo y no absoluto
- Que es lo que esta seguro?
- Contra quien se esta seguro?
- Contra que se esta seguro?
- Hasta cuando se esta seguro?
- Que intensidad de ataque se puede resistir?
- Por lo tanto sin un contexto el termino Seguridad
no tiene sentido
5Porque Atacan?
- Hacer Daño
- Alterar, dañar or borrar información
- Deneger servicio
- Dañar la imagen pública
- Motivos Personales
- Desquitarse
- Fundamentos políticos o terrorismo
- Gastar una broma
- Lucirse y presumir
- Motivos Financieros
- Robar información
- Chantaje
- Fraudes Financieros
6Motivos
- La tecnología tiene fallos.
- Es muy fácil hacerlo.
- No hay conciencia clara del delito
Porque MOLA!!
7Quién Ataca?
- El estereotipo es
- Varones jóvenes entre 15 y 25 años
- Mucho tiempo libre y poco dinero
- Un pequeño circulo de verdaderos crackers que
desarrollan herramientas y guías - Muchos hackers sin excesivos conocimientos que
utilizan las herramientas y guías de terceros - Ganan prestigio con acciones de renombre
- Motivación mas personal que financiera
8Impacto de los Ataques
Pérdida de Beneficios
Daños en la reputación
Deterioro de la confianza de los inversores
Datos comprometidos
Interrupción de los procesos de Negocio
Daños en la confianza de los clientes
Consecuencias legales (LOPD/LSSI)
9Incidentes Reportados al CERT
Data Source CERT ( http//www.cert.org)
10Vulnerabilidades por Años
Data Source CERT ( http//www.cert.org)
11Problema de la Industria ITVulnerabilidades en
Sistemas Operativos - 2002
12Problema de la Industria ITVulnerabilidades en
Sistemas Operativos - 2003
Windows 2003
OpenBSD
Windows XP
Windows 2000
SuSE
SUN
Mandrake
RedHat
Debian
13Fuentes
- Debian http//www.nl.debian.org/security
- Mandrake http//www.mandrakesoft.com/security/adv
isories - Microsoft http//www.microsoft.com/technet/securi
ty/current.aspx - Open BSD http//www.openbsd.org/errata35.html
- Sun http//sunsolve.sun.com/pub-cgi/show.pl?targe
tsecurity/sec - Suse http//www.novell.com/linux/security/advisor
ies.html - RedHat http//www.redhat.com/security/updates/
14Vulnerabilidades
http//www.securityfocus.com/bid
15Problema de la Industria ITVulnerabilidades en
Sistemas Operativos - Agosto 2004
16Código segurorecomendaciones para el desarrollo
17Contenidos
- Seguridad en la arquitectura
- Pausa intermedia los principios básicos
- Seguridad en la programación
- Seguridad en las pruebas
18Seguridad en la arquitectura
- Seguridad en el modelo de desarrollo
- Estrategia SD3
- Seguridad en el diseño por capas
- Holística de la seguridad
19Seguridad en el modelo de desarrollo
Aprender y refinar
Analizar amenazas
Revisión externa
Determinar los criterios de validación de la
seguridad
Security push
Preguntas durantelas entrevistas
Concepto
Entrega
Después de la entrega
Planes de pruebascompletados
Diseños completados
Código completado
Revisar defectos anteriores, comprobar registros
directrices de programación segura, usar
herramientas
Entrenar a los miembros del equipo
Revisión del equipo de seguridad
Pruebas de mutación de datos y mínimos privilegios
continuo
20El marco de seguridad SD3
SD3
- Arquitectura y código seguros
- Análisis de amenazas
- Reducción de vulnerabilidades
Secure by Design
Secure by Default
- Reducir el área de ataques
- Características no utilizadas desactivadas de
forma predeterminada - Uso de privilegios mínimos
- Protección detección, defensa, recuperación,
administración - Proceso guías de procedimientos, guías de
arquitecturas - Equipo formación
Secure in Deployment
21Seguridad en el diseño por capas
Users
SECURITY
Operational management
Communication
UI Components
UI Process Components
Service Interfaces
Business Workflows
Business Components
Business Entities
Data access logic components
Service Agents
Data Sources
Services
22Holística de la seguridad
Securing the application
Input validation Authentication Authorization Conf
iguration Management Sensitive Data
Session Management Cryptography Parameter
Manipulation Exception Management Auditing and
Logging
Securing the network
Router Firewall Switch Logging IDS
Securing the host
Patches and Updates Services Protocols
Accounts Files and Directories Shares
Ports Registry Auditing and Logging
23Los principios básicos
- Antes de que entremos en mayor materia
24Los principios básicos
- Principio 1 Todo el mundo es malo
- Es decir no te fíes de nada ni de nadie
- Principio 2 Nunca menosprecies el poder del
aburrimiento humano - http//yonkis.ya.com la web más visitada por
los universitarios españoles
25Seguridad en la programación
- Antes de empezar
- Problemas de memoria
- Errores aritméticos
- XSS (cross-site scripting)
- SQL injection
- Problemas de canonización
- Debilidades en la criptografía
- Problemas de Unicode
- Denegación de servicio
26Antes de empezar
- El computador es una máquina inútil, sólo sabe
dar respuestas Pablo Picasso - El factor humano es el que determina lo que
puedes hacer en tu proyecto - Asegúrate que tu equipo conoce las bases de la
seguridad - Fija con ellos unos tests mínimos
- Fijad unas convenciones de código y diseño
- Formación continua
27Qué es un desbordamiento de búfer
- Ocurre cuando los datos superan el tamaño
esperado y sobrescriben otros valores - Puede darse en código C/C no administrado
- (y llamadas a componentes no administrados)
- Incluye cuatro tipos
- Desbordamientos de búfer basados en pilas
- Desbordamiento de memoria dinámica
- Sobrescrituras de punteros de función y de
V-table - Sobrescrituras de manejadores de excepciones
- Smashing the stack for fun and profitAleph One
28Posibles resultados de los desbordamientos de
búfer
29Ejemplo de desbordamiento de búfer basado en pila
Parte superior de la pila
char4
int
Dirección de retorno
30Desbordamiento de memoria dinámica
- Sobrescriben datos almacenados en la memoria
dinámica (HEAP) - Son más difíciles de explotar que un
desbordamiento de búfer
strcpy
xxxxxxxxxxxxxx
31Defensa contra los desbordamientos de búfer (1 de
2)
- Tenga mucho cuidado cuando utilice
- strcpy
- strncpy
- CopyMemory
- MultiByteToWideChar
- Use la opción de compilación /GS de Visual C
para detectar desbordamientos de búfer - Utilice strsafe.h para lograr un tratamiento más
seguro de los búferes
32Defensa contra los desbordamientos de búfer (2 de
2)
- Compruebe todos los índices de matrices
- Utilice clases de empaquetadores existentes para
lograr un tratamiento seguro de las matrices - Compruebe las longitudes de rutas de acceso a
archivos mediante _MAX_PATH - Utilice métodos reconocidos de procesamiento de
rutas de acceso a archivos, como splitpath - Utilice código administrado, pero preste atención
a PInvoke y COM Interop
33Errores aritméticos
- Se producen cuando se superan las limitaciones de
una variable - Generan errores graves en tiempo de ejecución
- Suelen pasarse por alto y subestimarse
- Incluyen
- Desbordamiento valor demasiado grande para
un tipo de datos - Subdesbordamiento valor demasiado pequeño para
un tipo de datos
34Defensa contra errores aritméticos
- Sea consciente de las limitaciones de los tipos
de datos elegidos - Escriba código de defensa que compruebe si hay
desbordamientos - Considere la posibilidad de escribir funciones
seguras reutilizables - Considere la posibilidad de utilizar una clase
plantilla segura (si está programando en C)
35Qué es XSS
- Una técnica que permite
- Ejecutar una secuencia de comandos
malintencionada en el explorador Web
de un cliente - Insertar etiquetas ltscriptgt, ltobjectgt, ltappletgt,
ltformgt y ltembedgt - Robar información de la sesión Web y cookies
de autenticación - Tener acceso al equipo cliente
Cualquier página Web que produzca código HTML
que contenga datos proporcionados por el usuario
es vulnerable
36Ataques basados en Form (1 de 2)
Response.Write(Bienvenido Request.QueryString
(UserName))
37Dos explotaciones frecuentes de las secuencias de
comandos entre sitios
- Ataques a plataformas de correo electrónico y
paneles de discusión basados en Web - Uso de etiquetas ltformgt de HTML para redirigir
información privada (robo de cookies)
38Ataques basados en Form (2 de 2)
lta hrefhttp//www.contoso.msft/welcome.asp?name
ltFORM actionhttp//www. nwtraders.msft/data.asp
methodpost ididFormgt ltINPUT
namecookie typehiddengt lt/FORMgt
ltSCRIPTgt idForm.cookie.valuedocument.cookie
idForm.submit() lt/SCRIPTgt gt here lt/agt
39Defensa contra secuencias de comandos entre sitios
- No
- Confíe en los datos proporcionados por los
usuarios - Repita datos especificados por los usuarios
basados en Web a menos que los haya validado - Almacene información secreta en cookies
- Sí The Regulator
- Utilice la opción de cookie HttpOnly
- Utilice el atributo de seguridad ltframegt
- Aproveche las características de ASP.NET
40Qué es la inyección de SQL
- La inyección de SQL es
- El proceso de agregar instrucciones SQL con
los datos especificados por el usuario - Los hackers la utilizan para
- Examinar bases de datos
- Eludir la autorización
- Ejecutar varias instrucciones SQL
- Llamar a procedimientos almacenados integrados
41Ejemplos de inyección de SQL
sqlString "SELECT HasShipped FROM" "
OrderDetail WHERE OrderID '" ID "'"
- Si la variable ID se lee directamente de
un cuadro de texto de un formulario Web
o de Windows, el usuario podría introducir
cualquiera de los siguientes valores - ALFKI1001
- ALFKI1001' or 11 --
- ALFKI1001' DROP TABLE OrderDetail --
- ALFKI1001' exec xp_cmdshell('fdisk.exe') --
42Demostración 3Inyección de SQLInvestigación de
problemas por inyección de SQLUso de consultas
parametrizadas para defenderse contra la
inyección de SQL
43Defensa contra inyecciones de SQL
- Limpie todos los datos especificados por los
usuarios - Considere que todos los datos de entrada son
peligrosos mientras no se demuestre lo contrario - Busque los datos válidos y rechace todos los
demás - Considere la posibilidad de utilizar expresiones
regulares para quitar los caracteres no deseados - Ejecute el código con el menor privilegio posible
- Nunca ejecute código como sa
- Restrinja el acceso a los procedimientos
almacenados integrados - Utilice procedimientos almacenados o consultas de
SQL parametrizadas para tener acceso a los datos - No muestre los errores de ODBC
44Problemas de canonización
- Suele haber más de una forma de denominar algo
- Existen representaciones alternativas para
- Nombres de archivo
- Direcciones URL
- Dispositivos (como impresoras)
- Los hackers pueden explotar código que toma
decisiones basándose en nombres de archivo o
direcciones URL
45Problemas de canonizaciónEjemplo 1 nombres de
archivo
- MiArchivoLargo.txt
- MiArchivoLargo.txt.
- MiArch1.txt
- MiArchivoLargo.txtDATA
46Problemas de canonizaciónEjemplo 2
representación de caracteres
- Hay muchas formas de representar caracteres en
Internet
http//www.microsoft.com/technet/security
Es igual que
http//www2emicrosoft2ecom2ftechnet2fsecurity
http//www.microsoft.comc0aftechnetc0afsecurit
y http//www253265microsoft.com/technet/securit
y http//172.43.122.12 http//2888530444
47Defensa contra problemas de canonización
- Utilice la seguridad del sistema de archivos para
restringir el acceso a datos privados - No tome nunca una decisión basándose en un nombre
- Deshabilite la opción de rutas de acceso
primarias de IIS
48Debilidades en la criptografía
- Uso inapropiado de algoritmos
- Creación de los suyos propios
- Uso de algoritmos débiles
- Aplicación incorrecta
- No mantener las claves seguras
- Almacenamiento inseguro
- Uso prolongado
- El factor humano
Clave
Texto sin cifrar
Texto cifrado
Algoritmo
Necesito tres elementos de los anteriores para
descifrar sus datos
49Defensa contra debilidades en la criptografía
- Recicle las claves periódicamente
- Utilice ACL para restringir el acceso a las
claves - Almacene las claves en un dispositivo externo
- Utilice SACL para supervisar las actividades
- Utilice claves largas para ofrecer
mayor seguridad - Utilice DPAPI para simplificar la administración
de claves, si es posible - No implemente sus propias rutinas criptográficas
50Problemas de Unicode
- Errores frecuentes
- Tratamiento de un carácter Unicode como un
único byte - Cálculo incorrecto del tamaño de búfer necesario
- Uso incorrecto de MultiByteToWideChar
- Validación de los datos antes de la conversión,
pero no después - Resultados
- Desbordamientos de búfer
- Algunas secuencias de caracteres posiblemente
peligrosas pueden entrar en sus rutinas de
validación
51Defensa contra problemas de Unicode
- Calcular tamaños de búfer mediante sizeof (WCHAR)
- Conocer los estándares GB18030 (4 bytes
por carácter) - Convertir de Unicode a ASCII y después validar
- Utilizar IsNLSDefinedString durante la validación
- Utilizar MultiByteToWideChar correctamente para
proporcionar un búfer suficiente
52Ataques de denegación de servicio
- Insuficiencia de CPU
- Insuficiencia de memoria
- Insuficiencia de recursos
- Insuficiencia de red
53Defensa contra los ataques de denegación de
servicio
- Considere la seguridad como una característica de
diseño - No confíe en los datos proporcionados
por los usuarios - Aplique inteligencia en caso de error
- Pruebe la seguridad y la carga
- QoS
- Y si ya es tarde paciencia /
54Seguridad en las pruebas
- Testing por capas
- Herramientas
- Hackproofing
55Seguridad en las pruebas
- Testing de capas por separado
- Unit-testing en código
- Tests carga
- Uso de herramientas automatizadas
- FxCop
- MS Baseline Security Analizer
- Nessus, SATAN,
56Seguridad en las pruebas
cliente
servidor
hub
intruso
57Referencias
- http//www.microsoft.com/security
- http//msdn.microsoft.com/security Sitio de
seguridad de MSDN para desarrolladores - http//www.microsoft.com/resources/practices/guide
s.mspx Guías Patterns Practices - Writing Secure Code, 2nd edition Howard,
Leblanc. MS Press, 2003