Desarrollo Seguro de Aplicaciones en 'NET - PowerPoint PPT Presentation

1 / 57
About This Presentation
Title:

Desarrollo Seguro de Aplicaciones en 'NET

Description:

Seguridad, es un termino relativo y no absoluto Que es lo que esta seguro? ... http://yonkis.ya.com : la web m s visitada por los universitarios espa oles ... – PowerPoint PPT presentation

Number of Views:172
Avg rating:3.0/5.0
Slides: 58
Provided by: downloadM
Category:

less

Transcript and Presenter's Notes

Title: Desarrollo Seguro de Aplicaciones en 'NET


1
Desarrollo Seguro de Aplicaciones en .NET
Chema AlonsoMVP Windows Server Security
Informática 64 Ricardo VarelaMVP C José
Parada GimenoIT Pro EvangelistMicrosoft
2
Principios de Seguridad
3
Seguridad
  • 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)

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

5
Porque 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

6
Motivos
  • La tecnología tiene fallos.
  • Es muy fácil hacerlo.
  • No hay conciencia clara del delito

Porque MOLA!!
7
Quié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

8
Impacto 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)
9
Incidentes Reportados al CERT
Data Source CERT ( http//www.cert.org)
10
Vulnerabilidades por Años
Data Source CERT ( http//www.cert.org)
11
Problema de la Industria ITVulnerabilidades en
Sistemas Operativos - 2002
12
Problema de la Industria ITVulnerabilidades en
Sistemas Operativos - 2003
Windows 2003
OpenBSD
Windows XP
Windows 2000
SuSE
SUN
Mandrake
RedHat
Debian
13
Fuentes
  • 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/

14
Vulnerabilidades
http//www.securityfocus.com/bid
15
Problema de la Industria ITVulnerabilidades en
Sistemas Operativos - Agosto 2004
16
Código segurorecomendaciones para el desarrollo
17
Contenidos
  • Seguridad en la arquitectura
  • Pausa intermedia los principios básicos
  • Seguridad en la programación
  • Seguridad en las pruebas

18
Seguridad en la arquitectura
  • Seguridad en el modelo de desarrollo
  • Estrategia SD3
  • Seguridad en el diseño por capas
  • Holística de la seguridad

19
Seguridad 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
20
El 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
21
Seguridad 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
22
Holí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
23
Los principios básicos
  • Antes de que entremos en mayor materia

24
Los 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

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

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

27
Qué 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

28
Posibles resultados de los desbordamientos de
búfer
29
Ejemplo de desbordamiento de búfer basado en pila
Parte superior de la pila
char4
int
Dirección de retorno
30
Desbordamiento 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
31
Defensa 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

32
Defensa 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

33
Errores 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

34
Defensa 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)

35
Qué 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
36
Ataques basados en Form (1 de 2)
Response.Write(Bienvenido Request.QueryString
(UserName))
37
Dos 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)

38
Ataques 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
39
Defensa 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

40
Qué 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

41
Ejemplos 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') --

42
Demostración 3Inyección de SQLInvestigación de
problemas por inyección de SQLUso de consultas
parametrizadas para defenderse contra la
inyección de SQL
43
Defensa 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

44
Problemas 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

45
Problemas de canonizaciónEjemplo 1 nombres de
archivo
  • MiArchivoLargo.txt
  • MiArchivoLargo.txt.
  • MiArch1.txt
  • MiArchivoLargo.txtDATA

46
Problemas 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
47
Defensa 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

48
Debilidades 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
49
Defensa 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

50
Problemas 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

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

52
Ataques de denegación de servicio
  • Insuficiencia de CPU
  • Insuficiencia de memoria
  • Insuficiencia de recursos
  • Insuficiencia de red

53
Defensa 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 /

54
Seguridad en las pruebas
  • Testing por capas
  • Herramientas
  • Hackproofing

55
Seguridad 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,

56
Seguridad en las pruebas
  • Hackproofing

cliente
servidor
hub
intruso
57
Referencias
  • 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
Write a Comment
User Comments (0)
About PowerShow.com