BINAR10 Capacitacion Programacion Segura NET V2.0

2012 © Copyright BINAR10 S.A.C. Preparado para uso confidencial y exclusivo por parte de La Contraloría General de la República

Capacitación en Desarrollo y Evaluación de Seguridad para Aplicaciones Web, basado en .Net Framework

Referencia: ADS 0020-2011-CG

Reunión de Inicio del Proyecto y Desarrollo Conjunto de Expectativas


Indice

Tema Diapositiva

OWASP 04

C.T. Autenticación 05

C.T. Autorización 09

C.T. Manejo de Sesiones 10

C.T. Manejo de Errores 12

C.T. Despliegue Seguro de Aplicaciones 15

C.T. Criptografía 16

C.T. Desbordamiento de Buffers 19

C.T. Inyección de Comandos del Sistema Operativo 20

C.T. Inyección SQL 22

C.T. Validación de Datos 23

C.T. Cross-site scripting 24

2


Indice

3

Tema Diapositiva

C.T. Cross-Site Request Forgery 26

C.T. Logging 27

C.T. Integridad de Sesión 29

C.T. Condiciones de Carrera (Race Conditions) 30

C.T. Configuración errónea de seguridad 31


OWASP

4

• OWASP (Open Web Application Security Project): http://owasp.org – Es una organización 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

http://owasp.org/

2012 © Copyright BINAR10 S.A.C. Preparado para uso confidencial y exclusivo por parte de La Contraloría General de la República 5 5

• AUTENTICACIÓN Resumen

Las funciones de la aplicación relacionadas con la autenticación son a menudo implementadas incorrectamente, esto permite a los atacantes comprometer contraseñas, tokens de sesión, o explotar otras fallas de implementación para asumir la identidad de otros usuarios.

Análisis de Código Fuente

Utilización de los mecanismos de autenticación ya incluidos dentro de ASP.NET

Credenciales transportadas a través de una canal seguro

Almacenamiento encriptado de las contraseñas

No guardar datos de la autenticación dentro del navegador

Contraseñas Fuertes

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

2012 © Copyright BINAR10 S.A.C. Preparado para uso confidencial y exclusivo por parte de La Contraloría General de la República 6



ASP.NET 2.0 y las versiones posteriores ya proveen múltiples funcionalidades para la gestión efectiva de los procesos de autenticación, autorización y manejo de la información personal de los usuarios. No es recomendable implementar un mecanismo personalizado de autenticación debido a que ASP.NET realiza un trabajo aceptable en esta área, incluyendo aspectos de encriptación y vencimiento de sesión.

Creación del Ticket de Autenticación

Configuración de la Autenticación en el archivo web.config




Creación del Ticket de Autenticación

Configuración de la Autenticación en el archivo web.config



Credenciales transportadas a través de una canal seguro Los datos provenientes del formulario de inicio de sesión deben ser transportados a través de un protocolo seguro que los proteja de un atacante.



Credenciales transportadas a través de una canal seguro Los datos provenientes del formulario de inicio de sesión deben ser transportados a través de un protocolo seguro que los proteja de un atacante.

Web.config



Almacenamiento encriptado de las contraseñas Las contraseñas deben ser almacenadas utilizando un algoritmo de un solo sentido también conocido como funciones hash. Una vez que la contraseña ha sido almacenado utilizando un hash, no puede ser revertido, esto hace más difícil que un atacante pueda recuperar el texto en plano.

Utilizar un algoritmo de Hash y no un algoritmo simétrico de encriptación. Utilizar un "salt" junto con el algoritmo de Hash.

Nunca enviar las contraseñas por Email



No guardar datos de la autenticación dentro del navegador Los datos de la autenticación pueden ser almacenados dentro del navegador, esto permite que el usuario ya no tenga que volver a logearse cuando ingrese nuevamente a la página. El riesgo es que estos datos almacenados pueden ser robados directamente desde la máquina de los usuarios.

No guardar la sesión de autenticación dentro del navegador

Desactivar el autocompletado para el formulario de Login



Contraseñas Fuertes Las contraseñas débiles son más vulnerables a ataques de fuerza bruta o a simple adivinación. Las contraseñas fuertes deben combinar una variedad de caracteres (letras, números, símbolos, etc), el criterio mínimo de composición es un balance entre seguridad y usabilidad.

• Al menos 1 letra en mayúscula (A-Z)

• Al menos 1 letra en minúscula (a-z)

• Al menos 1 digito (0-9)

• Al menos 1 letra especial (!"£$%&...)

• Una longitud máxima y mínima.



• AUTORIZACIÓN Resumen

La correcta implementación de un modelo de autorización permite que únicamente usuarios autorizados tengan acceso a funciones particulares dentro de la aplicación, algún error en su implementación ocasionará que atacantes accedan a recursos no permitidos, con lo cual se comprometería información sensible y se aumenta el riesgo de otros ataques.



Verificación de la autorización en cada solicitud HTTP.

Descripción

El error más común es basar el modelo de autorización en ocultar o mostrar determinados controles a través de la pantalla ya que eso no restringe el acceso, cualquier atacante puede realizar una solicitud HTTP sin necesidad de una interfaz gráfica y lograr acceder a la funcionalidad restringida.

Mostrar y ocultar elementos en la pantalla nunca es suficiente. Se

debe validar la autorización a nivel de servidor y en cada request.

Utilizar una validación manual o mediante los ASP.NET Memberships.

No olvidar a los Web Services.



• MANEJO DE SESIONES

Resumen

El manejo de las sesiones desde la perspectiva de la revisión de código debe estar enfocado en la creación, renovación y destrucción de la sesión de un usuario a través de la aplicación.

Todas las versiones de ASP.NET ya proporcionan una gestión interna de las sesiones de los usuarios, estoy incluye: asignación de una sesión única a usuarios autenticados, expiración de la sesión y encriptación. A pesar de esto existen determinadas taras de que se encuentran en manos de los desarrolladores.


Expiración automática de la sesión.

Expiración manual de la sesión



Expiración automática de la sesión Las cookies deben tener un tiempo de expiración corto ya que mientras más pronto expire la cookie, la ventana de tiempo en el cuál se puede producir un ataque también será menor.

Establecer de manera explícita el tiempo de expiración en el

archivo Web.config

El tiempo de expiración de la sesión debe ser por lo menos 5

minutos mayor al tiempo de expiración de la autenticación.



Expiración manual de la sesión Se debe brindar al usuario la capacidad de expirar su sesión manualmente a través de un “Logging Out”, esto permitirá reducir el riesgo de sufrir un ataque.

Utilizar estas líneas de código cada vez que se quiera procesar un

"Log Out"

No olvidar realizar la misma lógica en otras circunstancias donde

se redireccione a la pantalla "Log In"



• INTEGRIDAD EN LA SESIÓN Resumen

Las cookies son usadas para mantener el estado de una sesión y permiten identificar a un usuario mientras está usando una aplicación. Las cookies también pueden ser almacenadas en el disco y ser válidas hasta una fecha de expiración definida.

Un atacante puede alterar los datos almacenados en estas cookies o robar información sensible para ejecutar otros ataques.



Utilizando Cookies

Cookieless



Utilización 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



Utilización Cookies HttpOnly

Las cookies que son creadas automáticamente 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



• MANEJO DE ERRORES Resumen

Un manejo eficiente de los errores evitará que se filtre información sensible del sistema a un atacante o que la aplicación entre en un estado inseguro luego de producido algún error.


No usar bloques Catch vacíos.

No mostrar al usuario mensajes de error descriptivos

Liberar recursos si se ha producido un error



No mostrar al usuario mensajes de error descriptivos Un buen manejo de errores nunca brinda información que un atacante pueda utilizar, por lo tanto el mensaje nunca debe contener el stack trace, el número de línea donde ocurrió el error, rutas de archivo ni tampoco información personal.

El mensaje de error que se mostrará a un usuario debe ser un mensaje genérico del tipo “Error – vuelva a intentarlo”.



No usar bloques Catch vacíos. Los bloques de código try-catch permiten capturar un error producido dentro del código y gestionarlo apropiadamente.

Al tener un bloque catch vacío se captura el error pero no se hace nada al respecto, esto significa que la ejecución del programa continua como si nada hubiera pasado y el error es escondido.



Liberar recursos si se ha producido un error Si se produce un error, se deben liberar todos los recursos que están siendo utilizados por el bloque de código 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 instrucción "using"



• DESPLIEGUE SEGURO DE APLICACIONES Resumen

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



Bloquear el acceso directo a los archivos que han sido desplegados

No solo basta con tener un código seguro; sino también el ambiente donde se encuentra desplegado este código debe ser seguro. Por este motivo, el acceso directo a recursos de código o configuración debe ser bloqueado.



Web. config

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



• DESBORDAMIENTO DE BUFFERS Resumen

Los programas usan un espacio de memoria de tamaño definido para almacenar datos ingresados por los usuarios, cuando el dato ingresado por el usuario supera el tamaño de este espacio se produce un desbordamiento. Los atacantes pueden aprovechar este desbordamiento para ejecutar comandos maliciosos.



Organización de un programa dentro de la memoria



No usar código no manejado.

Los lenguajes dentro de la plataforma .NET no son susceptibles a esto siempre que se utilice código manejado (código que es ejecutado siempre a través de la máquina virtual), esto debido a que la máquina virtual se encarga del manejo de la memoria.

• Identificar la utilización de código no manejado utilizando la palabra reservada “unsafe”, solo C# soporta utilizar código no manejado y no VB.NET.

• Identificar llamadas a código no manejado desde código manejado:

– Llamadas utilizando WIN32 API o P/Invoke: utilización del atributo DllInvoke.

– Utilización de COM Interop: Buscar la palabra clave “Interop” para identificar las referencias y clases usadas.



• CONDICIONES DE CARRERA (RACE CONDITIONS) Resumen

Las condiciones de carrera se producen cuando múltiples procesos en ejecución intentar manipular el mismo recurso almacenado o área de memoria lo que produce errores en la integridad.



Multiprocesos

Desde la primera versión de la plataforma .NET se proporciona las herramientas y APIs necesarias para implementar funcionalidades multiproceso.

El desarrollador es responsable de la correcta aplicación de estas herramientas para evitar errores comúnmente producidos en ambientes multiproceso.

• Buscar las siguientes referencias:

– Thread,

– System.Threading

– ThreadPool

• Evaluar que se esté utilizando un semáforo o un mutex en caso de acceder a un recurso compartido.



• CROSS-SITE SCRIPTING (XSS) Resumen

Los ataques de XSS se producen cuando un atacante usa una aplicación web para enviar código malicioso, generalmente en forma de scripts a nivel del navegador, a un usuario diferente.



Validar todas las entradas de información Se deben validar todas las entradas de información (form data, cookies, HTTP headers, query strings) que recibe la aplicación ya que a través de estas se puede enviar código malicioso por un atacante.

Request Validation, es una característica 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 razón para ello.

De manera global en el Web.config

Individualmente en cada página



Codificar todas las salidas HTML Toda la información mostrada en la pantalla debe ser codificada para que el navegador no interprete y ejecute un comando malicioso que pueda encontrarse dentro de dicha información.

• 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 páginas y controles ASP.NET.

– Etiquetas “<%= %>” “<%# %>” dentro de las páginas y controles ASP.NET.

– Método Eval() dentro de las páginas y controles ASP.NET.



• Codificar toda información saliente utilizando alguno de los siguientes métodos:

– Etiquetas <%: %> dentro de las páginas y controles ASP.NET 4 o superior.

– Métodos Server.HtmlEncode, Server.UrlEncode. (No codifica muy bien Javascript)

– Web Protection Library: Anti-XSS y Security Runtime Engine (Forma más fácil de adaptar una aplicación ya existente)



• VALIDACIÓN DE DATOS Resumen

Una de los aspectos más importantes de la seguridad es la validación de los datos ingresados por los usuarios. Muchos de los problemas ocasionados por ataques derivan de una validación de datos débil por parte de la aplicación. Una validación débil otorga al atacante una oportunidad de hacer que la aplicación actúe de una manera incorrecta.



Validar a nivel de servidor todos los datos ingresados por los usuarios.

La validación de datos puede reforzase a diferentes niveles de la aplicación, 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:

– Validación de Dato Obligatorio

– Validación de Longitud

– Validación de Tipo de Dato

– Validación de Rango

• Realizar las validaciones a nivel de servidor apenas se reciban los datos; de forma manual o utilizando los controles de validación ASP.NET (RequiredValidator, RangeValidator, etc).



• CROSS-SITE REQUEST FORGERY (CSRF) Resumen

CSRF es un ataque en el cuál un usuario autenticado es forzado a realizar una acción sensible y nunca se verifica que el usuario en si mismo haya sido quien ha invocado esa acción. Un atacante puede aprovechar las credenciales de autenticación de otro usuario para robar información o ejecutar acciones maliciosas.



Utilizar un Token de Sincronización

• Cada vez que un usuario ingresa al sitio web, se debe generar y almacenar un token en su sesión.

• Enviar el token en cada formulario cada vez que el usuario realice una acción.

• Cuando la acción llega al servidor, se debe validar que el token enviado en el formulario es el mismo al que se encuentra en la sesión.

• Si los tokens son diferentes es porque el usuario no ha sido quien ha ejecutado la acción.

Implementar el algoritmo manualmente si se utiliza WebForms.

ASP.NET MVC ya tiene una implementación de caja.

Otras opciones que carecen de usabilidad: CAPTCHA, Re - Autenticar



• CRIPTOGRAFÍA Resumen

Un uso eficiente de la criptografía provee integridad, confidencialidad y no repudio de los datos que están siendo almacenados y procesados. Por estos motivos la utilización de funciones criptográficas dentro del código debe ser conforme con el uso de los algoritmos estándares y el uso de llaves fuertes.



Las 25 contraseñas más comúnmente usadas.



ATAQUE POR RAINBOW TABLES

1.- Generar la tabla de hashes (Rainbow Table)




2.- Cargar la tabla en una herramienta que se encargue de la

búsqueda y comparación.




3.- Cargar las contraseñas de la BD y realizar la comparación.




4.- Observar las contraseñas en plano.



No usar algoritmos propios La encriptación es un proceso complejo que consume muchos y es muy difícil 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.



Usar una Llave de al menos 128-bit Los algoritmos simétricos necesitan de una llave para poder encriptar y desencriptar la información. Mientras más grande sea esta llave es menos probable que el dato encriptado pueda ser descifrado si se sufre un ataque.

Algoritmos Simétricos de encriptación:

– DES: Soporta una llave pequeña de 56-bit que puede ser fácilmente 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.



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 información que ha sido encriptada.

• Utilizar un SALT diferente por cada hash.

• Los algoritmos de MD5 y SHA-1 no son recomendados por ser muy débiles, se recomienda la utilización de SHA-256.



• LOGGING Resumen

Logging es la recopilación y almacenamiento de información que contiene detalles de quien y cuando se ha producido una determinada acción, también contiene mensajes que reflejan problemas o estados inválidos dentro de la aplicación.

El Logging nos proporciona un método a través del cuál podemos investigar si los otros mecanismos de seguridad están funcionando correctamente.



Generación de logs La aplicación debe tener la habilidad de detectar y registrar cualquier posible uso malicioso.

Lo logs deben brindarnos la información requerida para llevar a cabo una auditoria sobre las acciones del usuario.

• Registrar por lo menos los siguientes eventos:

– Autenticación: Intentos exitosos y fallidos.

– Manipulación de Información: Acciones CRUD realizada en la aplicación.

– Duración de la sesión: Eventos de Logout.

– Errores Inesperados: Mensaje de error y Stack Trace.

• La información registrada debe contener por lo menos los siguientes datos:

– Fecha/Hora del evento.

– Nombre/Identificador del Usuario.



• Algunos métodos de Logging disponibles dentro de la plataforma .NET:

– Tablas y Columnas personalizadas en la BD.

– ASP.NET Tracing/Monitoring.

– Logging Framework: Log4Net, Common Logging.



Protección en los logs Debido a que los logs contienen información de los usuarios y datos sensibles, esta información debe ser protegida para evitar violaciones en la confidencialidad.

No se debe registrar información sensible en los logs

(contraseñas, tarjetas de crédito, etc) o esta se debe encontrar

encriptada.



• INYECCIÓN SQL Resumen

Una inyección SQL consiste en la inserción de una cadena SQL maliciosa a través de las entradas que tiene la aplicación. Una inyección SQL exitosa puede leer datos sensibles, modificar información o ejecutar comandos administrativos en la base de datos o inclusivo a nivel del sistema operativo.



EL ATACANTE HA LOGRADO ACCEDER ÚNICAMENTE A

ESTA PANTALLA DE LA APLICACIÓN Y SU OBJETIVO ES

ROBAR LOS DATOS DE LOS CLIENTES DE TODA LA

EMPRESA.



ESTABLECER SI ES POSIBLE REALIZAR UN ATAQUE POR

INYECCIÓN



INVESTIGAR LA ESTRUCTURA DE LA BASE DE DATOS

1.- Verificar la existencia de ciertas columnas



INVESTIGAR LA ESTRUCTURA DE LA BASE DE DATOS

2.- Verificar la existencia de ciertas tablas



DETERMINAR SI EXISTEN PERMISOS DE ESCRITURA



REALIZAR EL ATAQUE

1.- Poblar la tabla de productos con los datos de los clientes.



REALIZAR EL ATAQUE

2.- Consultar los datos de los clientes en la pantalla



INFORMACIÓN INTERNA DE LOS CLIENTES HA SIDO EXPUESTA



Usar parámetros SQL nombrados.

No se deben construir sentencias SQL a través de la concatenación o manipulación de cadenas.

Dentro de la plataforma .NET, para la ejecución de sentencias SQL que necesiten parámetros, se debe utilizar los Named Parameters ya que evitan que se pueda ingresar sentencias maliciosas a través de los parámetros de un query.



INCORRECTO

CORRECTO



No concatenar los parámetros dentro de los Store Procedures

Los Store Procedures no deben realizar ningúna concatenación de cadenas, en caso se necesite un query dinámico, este también deberá hacer uso de parámetros.



STORE PROCEDURE SIMPLE

STORE PROCEDURE DINÁMICO (INCORRECTO)

STORE PROCEDURE DINÁMICO (CORRECTO)



• Considerar que no siempre se puede evitar la concatenación, por ejemplo el uso del operador LIKE.

La concatenación utilizando este operador no es susceptible a inyección SQL ya que el parámetro ingresado es tratado como variable y no como comando.



• INYECCIÓN DE COMANDOS DEL SISTEMA OPERATIVO Resumen

La inyección de comandos hacia el sistema operativo se produce cuando una aplicación acepta entradas inseguras que luego son pasadas a aplicaciones externas a través de argumentos. Al no validar las entradas inseguras, un atacante puede ejecutar comandos maliciosos directamente en el sistema operativo.



ENTRADAS DEL USUARIO

• userId = JOE123

• userId = JOE123 & netstat –a (ATAQUE)



Validar los parámetros al realizar llamadas a las funciones del sistema operativo

.NET desde su primera versión nos permite realizar llamadas a las funciones y programas del sistema operativo desde la misma aplicación. Las llamadas a estas funciones se realizan de manera similar a una línea de comandos por lo que se permite agregar parámetros.

Se debe validar siempre el contenido de estos parámetros ya que pueden ser manipulados para afectar de manera maliciosa el comportamiento de estas funciones.



No utilizar la línea de comandos a través de la aplicación. La línea de comandos del sistema operativo permite la ejecución de cualquier comando y parámetro, por lo tanto si la aplicación la utiliza directamente se incrementa el riesgo de que un atacante pueda ejecutar comandos maliciosos.

INCORRECTO

CORRECTO



• CONFIGURACIÓN ERRÓNEA DE SEGURIDAD Resumen

Las aplicaciones actuales requieren de múltiples datos, que deben ser configurados, para funcionar correctamente. Generalmente estas configuraciones se encuentra en manos de los administradores de servidores, pero aún 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 configuración puede tener un impacto fundamental en la seguridad.



Actualizar los frameworks. Los frameworks de aplicaciones pueden ser una gran ventaja cuando se tenga que construir cierta funcionalidad rápidamente, pero estas frameworks también 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 están siendo usadas dentro de una aplicación.



Desactivar el modo Debugging Existe una configuración que permite que un código se pueda depurar al momento de compilar, asimismo tiene efectos adicionales como incremento de memoria o lentitud en la ejecución del código.

El problema a nivel de seguridad es que este modo se puede detectar remotamente a través de una solicitud HTTP. Un atacante al saber que este modo está activado también intuirá que la memoria del servidor es mayor y podrá iniciar un ataque de negación del servicio.

Archivo Web.config



Encriptar datos sensibles Nunca se debe poner cadenas de conexión desencriptadas o datos sensibles dentro del archivo “Web.config”. Un atacante podría apoderarse de este archivo por algún ataque e información muy importante se encontraría comprometida.

• Utilizar la línea de comandos directamente en el servidor:

Se puede ejecutar la encriptación directamente en el servidor(IIS y Sitio Web) o directamente en el Visual Studio.



• Programando las encriptación utilizando las APIs de .NET:

Utilizar solo si no sea posible ejecutar la línea de comandos en el servidor. Ejm: Un Hosting Compartido.



<configuration>

<connectionStrings configProtectionProvider="RsaProtectedConfigurationProvider">

<EncryptedData>

</CipherData>

<CipherValue>OpWQgQbq2wBZEGYAeV8WF82yz6q5WNFIj3rcuQ8gT0MP97aO9SHIZWwNg

gSEi2Ywi4oMaHX9p0NaJXG76aoMR9L/WasAxEwzQz3fexFgFSrGPful/5t

</CipherValue>

</CipherData>

</EncryptedData>

</connectionStrings>

</configuration>

<configuration>

<connectionStrings>

<add name="Northwind" connectionString="Data Source=localhost;Integrated

Security=true;Initial Catalog=Northwind;" />

</connectionStrings>

</configuration>

ORIGINAL

ENCRIPTADO



No se requiere NINGUNA MODIFICACIÓN EN EL CÓDIGO 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)



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-Verify-Errors

• 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

http://www.beefycode.com/post/Log4Net-Tutorial-pt-1-Getting-Started.aspx












http://geeks.ms/blogs/jnunez/archive/2007/08/10/tutorial-wcf-5-de-5.aspx










http://weblogs.asp.net/scottgu/archive/2006/01/09/434893.aspx

http://www.youtube.com/watch?v=t9JkUlFUQP8

http://channel9.msdn.com/Events/MIX/MIX10/FT05

http://channel9.msdn.com/Blogs/Jossie/Anti-XSS-Library-v31-Find-Fix-and-Verify-Errors

















http://www.asp.net/web-forms/videos/authentication/sql-injection-defense







https://www.owasp.org/index.php/Testing_for_Web_Services



BINAR10 Capacitacion Programacion Segura NET V2.0

Documents

Transcript of BINAR10 Capacitacion Programacion Segura NET V2.0