BINAR10 Capacitacion Programacion Segura NET V2.0

Reunin de Inicio del Proyecto y Desarrollo Conjunto de Expectativas
Capacitacin en Desarrollo y Evaluacin de Seguridad para Aplicaciones Web, basado en .Net Framework
Referencia: ADS 0020-2011-CG
2012 Copyright BINAR10 S.A.C. Preparado para uso confidencial y exclusivo por parte de La Contralora General de la Repblica
Indice
Tema
OWASP
C.T. Autenticacin C.T. Autorizacin C.T. Manejo de Sesiones C.T. Manejo de Errores
Diapositiva
04
05 09 10 12
C.T. Despliegue Seguro de Aplicaciones

C.T. Criptografa C.T. Desbordamiento de Buffers C.T. Inyeccin de Comandos del Sistema Operativo C.T. Inyeccin SQL
15
16 19 20 22
C.T. Validacin de Datos

C.T. Cross-site scripting
23
24
Indice
Tema
C.T. Cross-Site Request Forgery
C.T. Logging C.T. Integridad de Sesin C.T. Condiciones de Carrera (Race Conditions) C.T. Configuracin errnea de seguridad
Diapositiva
26
27 29 30 31
OWASP
OWASP (Open Web Application Security Project): http://owasp.org

Es una organizacin sin fines de lucro, enfocada en la mejora de seguridad de aplicaciones. OWASP es una entidad independiente, no asociada a fabricantes.
Proyectos de OWASP:
Code Review Guide V1.1 Development Guide 2010 in English (Currently under development!) Testing Guide v3 OWASP Top 10 for 2010 Herramientas / Bibliotecas: Zed Attack Proxy WebScarab OWASP Enterprise Security API WebGoat
Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1
AUTENTICACIN
Resumen Las funciones de la aplicacin relacionadas con la autenticacin son a menudo implementadas incorrectamente, esto permite a los atacantes comprometer contraseas, tokens de sesin, o explotar otras fallas de implementacin para asumir la identidad de otros usuarios. Anlisis de Cdigo Fuente Utilizacin de los mecanismos de autenticacin ya incluidos dentro de ASP.NET Credenciales transportadas a travs de una canal seguro Almacenamiento encriptado de las contraseas No guardar datos de la autenticacin dentro del navegador Contraseas Fuertes
Utilizacin de los mecanismos de autenticacin ya incluidos dentro de ASP.NET

ASP.NET 2.0 y las versiones posteriores ya proveen mltiples funcionalidades para la gestin efectiva de los procesos de autenticacin, autorizacin y manejo de la informacin personal de los usuarios. No es recomendable implementar un mecanismo personalizado de autenticacin debido a que ASP.NET realiza un trabajo aceptable en esta rea, incluyendo aspectos de encriptacin y vencimiento de sesin.
Creacin del Ticket de Autenticacin Configuracin de la Autenticacin en el archivo web.config

Utilizacin de los mecanismos de autenticacin ya incluidos dentro de ASP.NET
Configuracin de la Autenticacin en el archivo web.config
Creacin del Ticket de Autenticacin

Credenciales transportadas a travs de una canal seguro

Los datos provenientes del formulario de inicio de sesin deben ser transportados a travs de un protocolo seguro que los proteja de un atacante.
10
11
12
13
14
15
Credenciales transportadas a travs de una canal seguro

Los datos provenientes del formulario de inicio de sesin deben ser transportados a travs de un protocolo seguro que los proteja de un atacante.
Web.config
16
17
Almacenamiento encriptado de las contraseas

Las contraseas deben ser almacenadas utilizando un algoritmo de un solo sentido tambin conocido como funciones hash. Una vez que la contrasea ha sido almacenado utilizando un hash, no puede ser revertido, esto hace ms difcil que un atacante pueda recuperar el texto en plano.
Utilizar un algoritmo de Hash y no un algoritmo simtrico de encriptacin. Utilizar un "salt" junto con el algoritmo de Hash. Nunca enviar las contraseas por Email
18
No guardar datos de la autenticacin dentro del navegador

Los datos de la autenticacin pueden ser almacenados dentro del navegador, esto permite que el usuario ya no tenga que volver a logearse cuando ingrese nuevamente a la pgina. El riesgo es que estos datos almacenados pueden ser robados directamente desde la mquina de los usuarios.
No guardar la sesin de autenticacin dentro del navegador
Desactivar el autocompletado para el formulario de Login
19
Contraseas Fuertes
Las contraseas dbiles son ms vulnerables a ataques de fuerza bruta o a simple adivinacin. Las contraseas fuertes deben combinar una variedad de caracteres (letras, nmeros, smbolos, etc), el criterio mnimo de composicin es un balance entre seguridad y usabilidad.
Al menos 1 letra en mayscula (A-Z) Al menos 1 letra en minscula (a-z) Al menos 1 digito (0-9) Al menos 1 letra especial (!"$%&...) Una longitud mxima y mnima.
20
AUTORIZACIN
Resumen La correcta implementacin de un modelo de autorizacin permite que nicamente usuarios autorizados tengan acceso a funciones particulares dentro de la aplicacin, algn error en su implementacin ocasionar que atacantes accedan a recursos no permitidos, con lo cual se comprometera informacin sensible y se aumenta el riesgo de otros ataques.
21
22
23
24
Verificacin de la autorizacin en cada solicitud HTTP. Descripcin El error ms comn es basar el modelo de autorizacin en ocultar o mostrar determinados controles a travs de la pantalla ya que eso no restringe el acceso, cualquier atacante puede realizar una solicitud HTTP sin necesidad de una interfaz grfica y lograr acceder a la funcionalidad restringida.
Mostrar y ocultar elementos en la pantalla nunca es suficiente. Se debe validar la autorizacin a nivel de servidor y en cada request. Utilizar una validacin manual o mediante los ASP.NET Memberships. No olvidar a los Web Services.
25
MANEJO DE SESIONES
Resumen El manejo de las sesiones desde la perspectiva de la revisin de cdigo debe estar enfocado en la creacin, renovacin y destruccin de la sesin de un usuario a travs de la aplicacin.
Todas las versiones de ASP.NET ya proporcionan una gestin interna de las sesiones de los usuarios, estoy incluye: asignacin de una sesin nica a usuarios autenticados, expiracin de la sesin y encriptacin. A pesar de esto existen determinadas taras de que se encuentran en manos de los desarrolladores. Anlisis de Cdigo Fuente
Expiracin automtica de la sesin. Expiracin manual de la sesin
26
Expiracin automtica de la sesin

Las cookies deben tener un tiempo de expiracin corto ya que mientras ms pronto expire la cookie, la ventana de tiempo en el cul se puede producir un ataque tambin ser menor.
Establecer de manera explcita el tiempo de expiracin en el archivo Web.config
El tiempo de expiracin de la sesin debe ser por lo menos 5 minutos mayor al tiempo de expiracin de la autenticacin.
27
Expiracin manual de la sesin

Se debe brindar al usuario la capacidad de expirar su sesin manualmente a travs de un Logging Out, esto permitir reducir el riesgo de sufrir un ataque.
Utilizar estas lneas de cdigo cada vez que se quiera procesar un "Log Out"
No olvidar realizar la misma lgica en otras circunstancias donde se redireccione a la pantalla "Log In"
28
INTEGRIDAD EN LA SESIN
Resumen Las cookies son usadas para mantener el estado de una sesin y permiten identificar a un usuario mientras est usando una aplicacin. Las cookies tambin pueden ser almacenadas en el disco y ser vlidas hasta una fecha de expiracin definida. Un atacante puede alterar los datos almacenados en estas cookies o robar informacin sensible para ejecutar otros ataques.
29

Utilizando Cookies
Cookieless
30
Utilizacin siempre Cookies Identificar el valor de la propiedad cookieless del elemento <sessionState> en el archivo Web.config, el valor de esta propiedad debe estar establecido en false. Considerar que no es obligatorio establecer esta propiedad dentro del archivo y su valor por defecto es false
Archivo Web.config
31
Utilizacin Cookies HttpOnly Las cookies que son creadas automticamente por ASP.NET ya se establecen como HttpOnly pero esto no sucede con las cookies manuales, por este motivo se identificar todas las cookies creadas manualmente y se verificar que estas tengan la propiedad HttpOnly establecida en true.
Cookie creada manualmente
32
MANEJO DE ERRORES
Resumen Un manejo eficiente de los errores evitar que se filtre informacin sensible del sistema a un atacante o que la aplicacin entre en un estado inseguro luego de producido algn error.
Anlisis de Cdigo Fuente No usar bloques Catch vacos. No mostrar al usuario mensajes de error descriptivos Liberar recursos si se ha producido un error
33
No mostrar al usuario mensajes de error descriptivos

Un buen manejo de errores nunca brinda informacin que un atacante pueda utilizar, por lo tanto el mensaje nunca debe contener el stack trace, el nmero de lnea donde ocurri el error, rutas de archivo ni tampoco informacin personal. El mensaje de error que se mostrar a un usuario debe ser un mensaje genrico del tipo Error vuelva a intentarlo.
34
No usar bloques Catch vacos.

Los bloques de cdigo try-catch permiten capturar un error producido dentro del cdigo y gestionarlo apropiadamente. Al tener un bloque catch vaco se captura el error pero no se hace nada al respecto, esto significa que la ejecucin del programa continua como si nada hubiera pasado y el error es escondido.
35
Liberar recursos si se ha producido un error

Si se produce un error, se deben liberar todos los recursos que estn siendo utilizados por el bloque de cdigo que ha producido el error. Esto permite que las conexiones y la memoria disponible no se agote.
En caso de error, eliminar los recursos utilizando un try-catch o la instruccin "using"
36
37
38
DESPLIEGUE SEGURO DE APLICACIONES

Resumen Es inefectivo tener un cdigo bien escrito si este va a ser desplegado en carpetas desprotegidas. Un atacante puede tener acceso a este cdigo y encontrar otras vulnerabilidades.
39

Bloquear el acceso directo a los archivos que han sido desplegados No solo basta con tener un cdigo seguro; sino tambin el ambiente donde se encuentra desplegado este cdigo debe ser seguro. Por este motivo, el acceso directo a recursos de cdigo o configuracin debe ser bloqueado.
40
41
Web. config *Solo IIS 7 o superior y ASP.NET 4 o superior
42
DESBORDAMIENTO DE BUFFERS
Resumen Los programas usan un espacio de memoria de tamao definido para almacenar datos ingresados por los usuarios, cuando el dato ingresado por el usuario supera el tamao de este espacio se produce un desbordamiento. Los atacantes pueden aprovechar este desbordamiento para ejecutar comandos maliciosos.
43
Organizacin de un programa dentro de la memoria
44
45

No usar cdigo no manejado. Los lenguajes dentro de la plataforma .NET no son susceptibles a esto siempre que se utilice cdigo manejado (cdigo que es ejecutado siempre a travs de la mquina virtual), esto debido a que la mquina virtual se encarga del manejo de la memoria.
Identificar la utilizacin de cdigo no manejado utilizando la palabra reservada unsafe, solo C# soporta utilizar cdigo no manejado y no VB.NET. Identificar llamadas a cdigo no manejado desde cdigo manejado: Llamadas utilizando WIN32 API o P/Invoke: utilizacin del atributo DllInvoke. Utilizacin de COM Interop: Buscar la palabra clave Interop para identificar las referencias y clases usadas.
46
CONDICIONES DE CARRERA (RACE CONDITIONS)

Resumen Las condiciones de carrera se producen cuando mltiples procesos en ejecucin intentar manipular el mismo recurso almacenado o rea de memoria lo que produce errores en la integridad.
47
48
Multiprocesos Desde la primera versin de la plataforma .NET se proporciona las herramientas y APIs necesarias para implementar funcionalidades multiproceso. El desarrollador es responsable de la correcta aplicacin de estas herramientas para evitar errores comnmente producidos en ambientes multiproceso.
Buscar las siguientes referencias: Thread, System.Threading ThreadPool Evaluar que se est utilizando un semforo o un mutex en caso de acceder a un recurso compartido.
49
50
CROSS-SITE SCRIPTING (XSS)

Resumen Los ataques de XSS se producen cuando un atacante usa una aplicacin web para enviar cdigo malicioso, generalmente en forma de scripts a nivel del navegador, a un usuario diferente.
51

Validar todas las entradas de informacin
Se deben validar todas las entradas de informacin (form data, cookies, HTTP headers, query strings) que recibe la aplicacin ya que a travs de estas se puede enviar cdigo malicioso por un atacante. Request Validation, es una caracterstica desde ASP.NET 1.1, que previene al lado del servidor de aceptar cualquier contenido que contenga HTML no codificado o malicioso. El Request Validation no debe ser desactivado al menos que se tenga una muy buena razn para ello.
De manera global en el Web.config
Individualmente en cada pgina
52
53

Codificar todas las salidas HTML
Toda la informacin mostrada en la pantalla debe ser codificada para que el navegador no interprete y ejecute un comando malicioso que pueda encontrarse dentro de dicha informacin.
Formas susceptibles a contener scripts que pueden ser ejecutados en el navegador. Propiedad Text de los controles ASP.NET. Propiedad Value del control Hidden. Propiedad Request de las pginas y controles ASP.NET. Etiquetas <%= %> <%# %> dentro de las pginas y controles ASP.NET. Mtodo Eval() dentro de las pginas y controles ASP.NET.
54

Codificar toda informacin saliente utilizando alguno de los siguientes mtodos: Etiquetas <%: %> dentro de las pginas y controles ASP.NET 4 o superior. Mtodos Server.HtmlEncode, Server.UrlEncode. (No codifica muy bien Javascript) Web Protection Library: Anti-XSS y Security Runtime Engine (Forma ms fcil de adaptar una aplicacin ya existente)
55
56
57
VALIDACIN DE DATOS
Resumen Una de los aspectos ms importantes de la seguridad es la validacin de los datos ingresados por los usuarios. Muchos de los problemas ocasionados por ataques derivan de una validacin de datos dbil por parte de la aplicacin. Una validacin dbil otorga al atacante una oportunidad de hacer que la aplicacin acte de una manera incorrecta.
58

Validar a nivel de servidor todos los datos ingresados por los usuarios. La validacin de datos puede reforzase a diferentes niveles de la aplicacin, pero esta se debe realizar de manera obligatoria a nivel de servidor y en cuanto se reciben los datos ingresados por el usuario.
Aplicar las siguientes validaciones a los campos dentro de los formularios: Validacin de Dato Obligatorio Validacin de Longitud Validacin de Tipo de Dato Validacin de Rango Realizar las validaciones a nivel de servidor apenas se reciban los datos; de forma manual o utilizando los controles de validacin ASP.NET (RequiredValidator, RangeValidator, etc).
59
CROSS-SITE REQUEST FORGERY (CSRF)

Resumen CSRF es un ataque en el cul un usuario autenticado es forzado a realizar una accin sensible y nunca se verifica que el usuario en si mismo haya sido quien ha invocado esa accin. Un atacante puede aprovechar las credenciales de autenticacin de otro usuario para robar informacin o ejecutar acciones maliciosas.
60

Utilizar un Token de Sincronizacin Cada vez que un usuario ingresa al sitio web, se debe generar y almacenar un token en su sesin. Enviar el token en cada formulario cada vez que el usuario realice una accin. Cuando la accin llega al servidor, se debe validar que el token enviado en el formulario es el mismo al que se encuentra en la sesin. Si los tokens son diferentes es porque el usuario no ha sido quien ha ejecutado la accin. Implementar el algoritmo manualmente si se utiliza WebForms. ASP.NET MVC ya tiene una implementacin de caja. Otras opciones que carecen de usabilidad: CAPTCHA, Re - Autenticar
61
CRIPTOGRAFA
Resumen Un uso eficiente de la criptografa provee integridad, confidencialidad y no repudio de los datos que estn siendo almacenados y procesados. Por estos motivos la utilizacin de funciones criptogrficas dentro del cdigo debe ser conforme con el uso de los algoritmos estndares y el uso de llaves fuertes.
62
63
Las 25 contraseas ms comnmente usadas.
64
65

ATAQUE POR RAINBOW TABLES
1.- Generar la tabla de hashes (Rainbow Table)
66

2.- Cargar la tabla en una herramienta que se encargue de la bsqueda y comparacin.
67

3.- Cargar las contraseas de la BD y realizar la comparacin.
68

4.- Observar las contraseas en plano.
69
No usar algoritmos propios

La encriptacin es un proceso complejo que consume muchos y es muy difcil de implementar de forma efectiva y eficiente. Por estos motivos se debe usar siempre los algoritmos ya conocidos y que se encuentran ya implementados dentro de la plataforma .NET desde las primeras versiones. Implementar y utilizar un algoritmo propio incrementa la probabilidad de error y vulnerabilidad frente a un ataque.
70
Usar una Llave de al menos 128-bit

Los algoritmos simtricos necesitan de una llave para poder encriptar y desencriptar la informacin. Mientras ms grande sea esta llave es menos probable que el dato encriptado pueda ser descifrado si se sufre un ataque.
Algoritmos Simtricos de encriptacin: DES: Soporta una llave pequea de 56-bit que puede ser fcilmente susceptible a un ataque de fuerza bruta. 3DES: Soporta una llave de 128-bit, aplica el algoritmo DES 3 veces. AES: Soporta una llave de 256-bit, utiliza el algoritmo de Rijndael.
71
Usar un Salt en todos los Hash

El Salt es una cadena aleatoria de datos que agrega variabilidad al resultado del proceso de hash, esto dificulta que un atacante pueda descubrir el texto en plano de la informacin que ha sido encriptada.
Utilizar un SALT diferente por cada hash. Los algoritmos de MD5 y SHA-1 no son recomendados por ser muy dbiles, se recomienda la utilizacin de SHA-256.
72
73
LOGGING
Resumen Logging es la recopilacin y almacenamiento de informacin que contiene detalles de quien y cuando se ha producido una determinada accin, tambin contiene mensajes que reflejan problemas o estados invlidos dentro de la aplicacin. El Logging nos proporciona un mtodo a travs del cul podemos investigar si los otros mecanismos de seguridad estn funcionando correctamente.
74

Generacin de logs
La aplicacin debe tener la habilidad de detectar y registrar cualquier posible uso malicioso. Lo logs deben brindarnos la informacin requerida para llevar a cabo una auditoria sobre las acciones del usuario.
Registrar por lo menos los siguientes eventos: Autenticacin: Intentos exitosos y fallidos. Manipulacin de Informacin: Acciones CRUD realizada en la aplicacin. Duracin de la sesin: Eventos de Logout. Errores Inesperados: Mensaje de error y Stack Trace.
La informacin registrada debe contener por lo menos los siguientes datos: Fecha/Hora del evento. Nombre/Identificador del Usuario.
75

Algunos mtodos de Logging disponibles dentro de la plataforma .NET: Tablas y Columnas personalizadas en la BD. ASP.NET Tracing/Monitoring. Logging Framework: Log4Net, Common Logging.
76
Proteccin en los logs

Debido a que los logs contienen informacin de los usuarios y datos sensibles, esta informacin debe ser protegida para evitar violaciones en la confidencialidad.
No se debe registrar informacin sensible en los logs (contraseas, tarjetas de crdito, etc) o esta se debe encontrar encriptada.
77
INYECCIN SQL
Resumen Una inyeccin SQL consiste en la insercin de una cadena SQL maliciosa a travs de las entradas que tiene la aplicacin. Una inyeccin SQL exitosa puede leer datos sensibles, modificar informacin o ejecutar comandos administrativos en la base de datos o inclusivo a nivel del sistema operativo.
78
79
EL ATACANTE HA LOGRADO ACCEDER NICAMENTE A ESTA PANTALLA DE LA APLICACIN Y SU OBJETIVO ES ROBAR LOS DATOS DE LOS CLIENTES DE TODA LA EMPRESA.
80

ESTABLECER SI ES POSIBLE REALIZAR UN ATAQUE POR INYECCIN
81

INVESTIGAR LA ESTRUCTURA DE LA BASE DE DATOS
1.- Verificar la existencia de ciertas columnas
82

INVESTIGAR LA ESTRUCTURA DE LA BASE DE DATOS
2.- Verificar la existencia de ciertas tablas
83

DETERMINAR SI EXISTEN PERMISOS DE ESCRITURA
84

REALIZAR EL ATAQUE
1.- Poblar la tabla de productos con los datos de los clientes.
85

REALIZAR EL ATAQUE
2.- Consultar los datos de los clientes en la pantalla
86

INFORMACIN INTERNA DE LOS CLIENTES HA SIDO EXPUESTA
87
Usar parmetros SQL nombrados. No se deben construir sentencias SQL a travs de la concatenacin o manipulacin de cadenas. Dentro de la plataforma .NET, para la ejecucin de sentencias SQL que necesiten parmetros, se debe utilizar los Named Parameters ya que evitan que se pueda ingresar sentencias maliciosas a travs de los parmetros de un query.
88
INCORRECTO
CORRECTO
89
No concatenar los parmetros dentro de los Store Procedures Los Store Procedures no deben realizar ningna concatenacin de cadenas, en caso se necesite un query dinmico, este tambin deber hacer uso de parmetros.
90
STORE PROCEDURE SIMPLE
STORE PROCEDURE DINMICO (INCORRECTO)
STORE PROCEDURE DINMICO (CORRECTO)

91

Considerar que no siempre se puede evitar la concatenacin, por ejemplo el uso del operador LIKE.
La concatenacin utilizando este operador no es susceptible a inyeccin SQL ya que el parmetro ingresado es tratado como variable y no como comando.
92
INYECCIN DE COMANDOS DEL SISTEMA OPERATIVO

Resumen La inyeccin de comandos hacia el sistema operativo se produce cuando una aplicacin acepta entradas inseguras que luego son pasadas a aplicaciones externas a travs de argumentos. Al no validar las entradas inseguras, un atacante puede ejecutar comandos maliciosos directamente en el sistema operativo.
93
ENTRADAS DEL USUARIO userId = JOE123 userId = JOE123 & netstat a (ATAQUE)
94
Validar los parmetros al realizar llamadas a las funciones del sistema operativo
.NET desde su primera versin nos permite realizar llamadas a las funciones y programas del sistema operativo desde la misma aplicacin. Las llamadas a estas funciones se realizan de manera similar a una lnea de comandos por lo que se permite agregar parmetros. Se debe validar siempre el contenido de estos parmetros ya que pueden ser manipulados para afectar de manera maliciosa el comportamiento de estas funciones.
95

No utilizar la lnea de comandos a travs de la aplicacin.
La lnea de comandos del sistema operativo permite la ejecucin de cualquier comando y parmetro, por lo tanto si la aplicacin la utiliza directamente se incrementa el riesgo de que un atacante pueda ejecutar comandos maliciosos.
INCORRECTO
CORRECTO
96
CONFIGURACIN ERRNEA DE SEGURIDAD

Resumen Las aplicaciones actuales requieren de mltiples datos, que deben ser configurados, para funcionar correctamente. Generalmente estas configuraciones se encuentra en manos de los administradores de servidores, pero an existe una gran cantidad de estas que se encuentra en manos de los desarrolladores. Aqu es donde los problemas aparecen, ya que un error en la configuracin puede tener un impacto fundamental en la seguridad.
97
Actualizar los frameworks.

Los frameworks de aplicaciones pueden ser una gran ventaja cuando se tenga que construir cierta funcionalidad rpidamente, pero estas frameworks tambin pueden tener problemas o vulnerabilidades. De la misma manera como los administradores se encargan de instalar actualizaciones y parches en el servidor, los desarrolladores deben encargarse de actualizar las frameworks que estn siendo usadas dentro de una aplicacin.
98
Desactivar el modo Debugging

Existe una configuracin que permite que un cdigo se pueda depurar al momento de compilar, asimismo tiene efectos adicionales como incremento de memoria o lentitud en la ejecucin del cdigo. El problema a nivel de seguridad es que este modo se puede detectar remotamente a travs de una solicitud HTTP. Un atacante al saber que este modo est activado tambin intuir que la memoria del servidor es mayor y podr iniciar un ataque de negacin del servicio.
Archivo Web.config
99
Encriptar datos sensibles

Nunca se debe poner cadenas de conexin desencriptadas o datos sensibles dentro del archivo Web.config. Un atacante podra apoderarse de este archivo por algn ataque e informacin muy importante se encontrara comprometida.
Utilizar la lnea de comandos directamente en el servidor:
Se puede ejecutar la encriptacin directamente en el servidor(IIS y Sitio Web) o directamente en el Visual Studio.
100

Programando las encriptacin utilizando las APIs de .NET:
Utilizar solo si no sea posible ejecutar la lnea de comandos en el servidor. Ejm: Un Hosting Compartido.
101

<configuration> <connectionStrings> <add name="Northwind" connectionString="Data Source=localhost;Integrated Security=true;Initial Catalog=Northwind;" /> </connectionStrings> </configuration> ORIGINAL
<configuration> <connectionStrings configProtectionProvider="RsaProtectedConfigurationProvider"> <EncryptedData> </CipherData> <CipherValue>OpWQgQbq2wBZEGYAeV8WF82yz6q5WNFIj3rcuQ8gT0MP97aO9SHIZWwNg gSEi2Ywi4oMaHX9p0NaJXG76aoMR9L/WasAxEwzQz3fexFgFSrGPful/5t </CipherValue> </CipherData> </EncryptedData> </connectionStrings> </configuration>
ENCRIPTADO
102
No se requiere NINGUNA MODIFICACIN EN EL CDIGO para acceder a los datos encriptados, todo se realiza de manera TRANSPARENTE PARA EL DESARROLLADOR.
Se pueden usar LLAVES PERSONALIZADAS para encriptar los datos. Por defecto utiliza llaves que se encuentran dentro del servidor. (Machine Keys)
103

ENLACES
Tutoriales
Log4Net: http://www.beefycode.com/post/Log4Net-Tutorial-pt-1-Getting-Started.aspx WCF: http://geeks.ms/blogs/jnunez/archive/2007/08/10/tutorial-wcf-5-de-5.aspx Encriptar Web.config: http://weblogs.asp.net/scottgu/archive/2006/01/09/434893.aspx
Videos
Buffer Overflow: http://www.youtube.com/watch?v=t9JkUlFUQP8 XSS y CSRF: http://channel9.msdn.com/Events/MIX/MIX10/FT05 Anti XSS: http://channel9.msdn.com/Blogs/Jossie/Anti-XSS-Library-v31-Find-Fix-and-VerifyErrors SQL Injection: http://www.asp.net/web-forms/videos/authentication/sql-injection-defense
Otros
Web Services OWASP: https://www.owasp.org/index.php/Testing_for_Web_Services
104

BINAR10 Capacitacion Programacion Segura NET V2.0

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

BINAR10 Capacitacion Programacion Segura NET V2.0

Încărcat de

Drepturi de autor:

Formate disponibile

Reunin de Inicio del Proyecto y Desarrollo Conjunto de Expectativas

Referencia: ADS 0020-2011-CG

C.T. Despliegue Seguro de Aplicaciones

C.T. Validacin de Datos

OWASP (Open Web Application Security Project): http://owasp.org

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Utilizacin de los mecanismos de autenticacin ya incluidos dentro de ASP.NET

Creacin del Ticket de Autenticacin Configuracin de la Autenticacin en el archivo web.config

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Configuracin de la Autenticacin en el archivo web.config

Creacin del Ticket de Autenticacin

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Credenciales transportadas a travs de una canal seguro

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Credenciales transportadas a travs de una canal seguro

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Almacenamiento encriptado de las contraseas

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

No guardar datos de la autenticacin dentro del navegador

No guardar la sesin de autenticacin dentro del navegador

Desactivar el autocompletado para el formulario de Login

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Expiracin automtica de la sesin. Expiracin manual de la sesin

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Expiracin automtica de la sesin

Establecer de manera explcita el tiempo de expiracin en el archivo Web.config

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Expiracin manual de la sesin

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Cookie creada manualmente

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

No mostrar al usuario mensajes de error descriptivos

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

No usar bloques Catch vacos.

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Liberar recursos si se ha producido un error

En caso de error, eliminar los recursos utilizando un try-catch o la instruccin "using"

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

DESPLIEGUE SEGURO DE APLICACIONES

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Control Tcnico (C.T.) de OWASP Code Review Guide 2008 V1.1

Web. config *Solo IIS 7 o superior y ASP.NET 4 o superior