Marino Posadas. Programación segura con .Net Framework (ejemplo)

5/14/2018 Marino Posadas. Programación segura con .Net Framework (ejemplo) - slidepdf.com

http://slidepdf.com/reader/full/marino-posadas-programacion-segura-con-net-framework-ejemplo 1/22



Sinopsis: Se trata de una obra introductoria a los conceptos de segu-ridad en las aplicaciones y a los conceptos de codificaciónsegura. Utilizando los principios de Microsoft SolutionsFramework como marco de trabajo y las recomendaciones

oficiales de buenas prácticas, se recorre el ciclo de vida deuna aplicación, haciendo especial hincapié en las prácticasde seguridad, los modelos de ataques, y las formas correc-tas de prevención.

LosCuadernosTécnicosdedotNetManíasonunaseriedepequeños libros enfocados a temas concretos para progra-

madores y arquitectos de software de la plataforma .NET.Cubren el hueco existente entre artículos muy específicosen una revista especializada como dotNetManía o los gran-des libros sobre temas genéricos.

Marino Posadas es Redactor Jefe de dotNet- Manía.TrabajacomoConsultoryProgramMa-nageren Alhambra-Eidos yesMicrosoftMost

Valuable Professional en Visual C#, además detitulado MCSD, MCAD, MCT y MSFP. Antesde esta obra, ha colaborado con varios compa-

ñeros de trabajo en la elaboración de otros cua-tro títulos, y esta es su tercera obra en solitario.Conferenciante en diversos eventos organizadospor Alhambra-Eidos, Microsoft y varias uni-

versidades españolas y extranjeras, se interesópor .NET Framework desde las primeras ver-siones«alfa»ymantieneunaWebdesoportede

sus actividades en el sitio www.ElAveFenix.net



Luarna

Programación segura con .NET Framework © Marino Posadas© De esta edición: 2009, Luarna Ediciones, S.L. www.luarna.com

Madrid, junio de 2009

ISBN: 978-84-92684-36-3 Versión: 1.0 (19-06-2009)«Cualquier forma de reproducción, distribución, comunica-ción pública o transformación de esta obra solo puede ser rea-lizada con la autorización de sus titulares, salvo excepción pre-

vistaporlaley.DiríjaseaCEDRO(CentroEspañoldeDerechosReprográficos, www.cedro.org) si necesita fotocopiar o escane-ar algún fragmento de esta obra».

Edición en papel

Primera edición en papel: 2006

Seguridad en .NET Framework Consideraciones de seguridad en el ciclo de vida de las aplicaciones© Marino Posadas© Netalia, S.L., 2006



Seguridad en .NET Framework Consideraciones de seguridad

en el ciclo de vida de las aplicaciones

Marino Posadas

nº 3



A Milagros, que siempre me anima en las labores de escritura, y me descarga de otras más cotidianas,

para hacer que esto sea posible.

A Paco Marín y Pilar Pérez, editores y —sin embargo— amigos. No se lo dedico por lo primero sino por esto último.

Es mucho más raro de encontrar.

A mi otro amigo, Paco Morero. Es un genio de la “otra” plataforma (J2EE), y sin embargo, me sigue considerando

tan de fiar como hace 25 años. ¡Todo un mérito!

A mis sobrinos Fernando, Sara, Ana, Paula, Pablo,

Javier, Adrián, Irene, Luis y Juan José, y a Silvia y Clara(sobrinas adoptivas), de quienes soy su primer proveedor de software. Ellos me recuerdan los aspectos más divertidos

de la informática.

A Ernesto Manrique, único familiar que —de momento— ha seguido mis pasos y va camino de superarlos con creces.

¡Que veamos muchos más!



Agradecimientos

Hay muchos a los que tengo que agradecer diversos aspec-

tos de esta obra, pero intentaré resumirlo: A Alfonso Rodríguez, Javier Izquierdo, Alberto Amescua,David Carmona y David Salgado, de Microsoft Ibérica,por su continuado apoyo y fe en mi trabajo.

A Luis Miguel Blanco, otro autor de esta serie, que consi-gue que su calidad como persona y amigo supere a la desus obras. Algo muy difícil.

A Antonio Quirós, Jorge Serrano, Pepe Hevia, Angel Rayo, Victor Arrondo y todos mis compañeros de Alhambra-Ei-dos, por su apoyo constante.

A Carlos Hevia, por sus aportaciones bibliográficas.

A mis buenos compañeros del grupo de MVP de Micro-soft, y muy especialmente, a la —ya mundialmente cono-cida— “Escuela Mediterránea de SQL Server”. Ellos sa-

ben quienes son.



Índice

1. Introducción a los conceptos de seguridad .......10La iniciativa de informática fiable

(Trustworthy Computing)..................................13El principio SD3 .......................................................15La ventaja del atacante y el dilema del defensor ......17Creación de una cultura de seguridad

en la empresa ......................................................18 Áreas de influencia ....................................................19

2. Seguridad en el ciclo de vida de un proyecto de software ....................................23

Los principios básicos de MSF .................................23

Recomendaciones generales para cada27fase del ciclo de vida .......................................27Seguridad en la fase de previsión (o análisis) ............30El modelo de riesgos bajo el prisma

de la seguridad ................................................33El control de la seguridad en las capas lógicas

de la aplicación................................................35Seguridad en la fase de implementación ..................42



Seguridad en la fase de pruebas ................................44

3. Estrategias de defensa: SD3 + C .........................47Creación del modelo de amenazas............................49

Breve explicación de las amenazas delmodelo STRIDE ............................................54Implantación de las estrategias de defensa ...............63

Autenticación ...........................................................63 Autorización .............................................................67Flujo de identidad (Identity Flow) ...........................69

Estrategias de diseño en el flujo de identidad .........74 Auditoría ...................................................................77

4. Programación de la seguridad en .NET Framework .......................................82

.NET como plataforma de ejecución segura............82

Arquitectura de un ensamblado ...............................83Seguridad en el Acceso al Código (CAS) .................85Evidencias, permisos y políticas de seguridad .........87Gestión de seguridad mediante código ...................97

Almacenamiento seguro de información crítica ....106Criptografía ............................................................119

Algunos tipos de ataques ........................................149

5. Seguridad vinculada a arquitecturas ................161Seguridad en aplicaciones Web ASP.NET.............161La seguridad y el modelo de proveedores ..............167Uso de SqlMembershipProvider ............................168Configuración de las propiedades

del proveedor de pertenencia a grupo ...............171



Ejemplos de implantación deseguridad en ASP.NET 2.0 ...............................172

Gestión de la autenticación y autorización:controles login y las API de pertenencia

a grupos ..............................................................172Seguridad en los servicios Web...............................184

6. Seguridad en las fases finales ...........................193Fase de pruebas ......................................................193Seguridad en la implantación y mantenimiento ....196

Conclusión .............................................................209



capítulo1

Introducción a los conceptosde seguridad

La seguridad es un problema de nuestros tiempos.Desde hace algunos años, todas las actividades cotidianasestán teñidas de algún concepto asociado a la seguridad.Desde los simples juguetes, hasta los automóviles. El soft-

ware no iba a ser una excepción. Las aplicaciones de hoy no son elementos aislados, y no se trata siquiera de quenuestra aplicación funcione correctamente, sino de queotras aplicaciones no interfieran con la nuestra en formano deseada. O que los usuarios no puedan realizar opera-ciones no previstas. Por otro lado, el software de hoy ne-cesita estar interconectado, integrarse, emitir y recibir in-formación fuera de los límites de su proceso de ejecución

y muchas veces, fuera del sistema operativo sobre el quese ejecuta.

Los primeros virus informáticos aparecidos en los 90causaban más curiosidad que miedo y tenían como mediode transmisión la inserción directa en un medio físico por-

tátil (disquete, casi siempre). La situación hoy es muy di-ferente debido a la aparición de Internet, que, si bien se ha



convertido en imprescindible, al tiempo, ha abierto la cajade Pandora donde todos los truenos se esconden dispues-tos a impactar contra nuestros sistemas.

¿Estamos hablando de virus? No, realmente. Hablamos

de seguridad, y eso, va más allá de la influencia de Internet.No es necesario en absoluto que exista infección vírica paraque se violen los principios de la seguridad. Cualquier per-sona que acceda a información cuya naturaleza no le com-pete o que —simplemente— no haya sido expresamente au-torizada, está violando la seguridad. Cualquier dato que salga

de los límites para los que ha sido concebido, está excedien-do su contexto de seguridad. Un empleado que se apropiade código fuente indebidamente, puede atentar contra la se-guridad una vez abandonada su empresa (o incluso mientraspermanece allí).

En general, cualquier proceso utilizado para fines para

los que no ha sido diseñado, o sometido a cargas de trabajo para las que no está preparado (como los ataques DoS ,o Denial of Service) puede convertirse en un peligro para laseguridad. En la práctica, cualquier entrada de datos pue-de ser potencialmente dañina, si el usuario conoce (o es ca-paz de inferir) el funcionamiento interno del programa: dehecho, dos de los tipos de ataque más conocidos se basanen esto: Buffer overrun y SQL-Injection.

Incluso existen factores no intencionados en absolutoque pueden provocar un mal funcionamiento de un siste-ma (o dispositivo) simplemente, por que el programadorno ha previsto que la capacidad humana de error (casi in-finita) puede provocar dicha situación.



Como vemos, la naturaleza de los ataques a la seguri-dad es muy variada, y, de hecho, también lo es la defensacontra dichos ataques. Buena parte de esa defensa, tieneque ver con la administración del propio sistema operati-

vo, pero nuestro código puede, en ocasiones, permitir loque el propio sistema impide y eso supone un planteamien-to serio de todo el modelo de amenazas.

Esta obra va a centrarse en la seguridad del códigofuente y utilizará como modelo la plataforma .NET Fra-mework 2.0, que nos servirá de laboratorio de pruebas, enmuchas ocasiones. La mayor parte de lo indicado aquí esperfectamente extrapolable a las versiones anteriores y,

cuando no sea así, lo indicaremos de forma explícita.Proponemos un recorrido por el ciclo de vida de lasaplicaciones (haciendo especial hincapié en la fase de des-arrollo), recomendando qué aspectos de seguridad debie-ran de tenerse en cuenta, cómo mitigar los efectos indese-ados y qué medidas preventivas nos parecen imprescindibles

para ofrecer el adecuado nivel de calidad en las aplicacio-nes que queremos para nuestros clientes.

Ejemplo. Pongamos un caso en extremo inocente: un pro-grama solicita en una caja de diálogo de impresión cuántascopias queremos de un documento, y, por cualquier razón, leindicamos 9999 ó 32.767 (valores máximos autorizados para

la mayoría de impresoras) en lugar de 9. O que la impresorapermite una configuración de tipo de letra, a la que asignamosun tipo vectorial de ¡500 puntos! Estaremos forzando al sis-tema más allá de los límites entre los que su funcionamientoes adecuado. No son —en sí mismos—agujeros de seguridadintencionados (por ninguna de las partes, muchas veces), peropueden provocar efectos totalmente indeseados.

n o t a



De hecho, cuanto más tarde se arreglen las cosas (encualquier aspecto, en general), peor. De ahí que este paseorápido por la seguridad recorra todo el ciclo de vida y nosolo la fase de codificación, de tal forma que el lector pue-

da tener una guía básica pero global de los problemas deseguridad y sus soluciones potenciales. Tampoco es nuestro objetivo revisar los mecanismos

de seguridad perimetral propios de los sistemas operativos.En los apartados adecuados, indicaremos qué parte de laarquitectura de software es la responsable de la seguridad,

y en algunos casos, cómo modificarla sin recurrir al admi-nistrador del sistema. Mucho y bueno hay escrito al res-pecto, y solamente asumiremos que, en lo fundamental, seconocen los mecanismos básicos o sabemos la forma de so-licitar su implantación por el encargado de la administra-ción del sistema.

La iniciativa de informática fiable(Trustworthy Computing)

Para abordar el problema de la seguridad con funda-mento, un grupo de grandes empresas, entre las que se en-

contraba desde sus inicios Microsoft, propusieron una ini-ciativa de “informática fiable” que —como puede leerse

Aviso. Debemos de tener en cuenta que es un error pen-sar que, una vez que la aplicación esté terminada, si obser-vamos un fallo de seguridad, será sencillo poner un parchepara arreglarlo. A veces, puede significar un recorrido porel ciclo completo.

n o t a



en su documento oficial1— establece que se debe perse-guir la meta de que los sistemas cumplan con estos cuatroprincipios:

• Seguros: ningún virus atentará contra nuestros sis-

temas o los volverá inutilizables.• Privados: la información personal no será expues-ta de ninguna forma, ni podrá ser utilizada en ma-nera alguna que no sea la explícitamente indicadaen el momento de su exposición.

• Fiables: cuando instalemos un programa, no ten-

dremos que preocuparnos por los posibles efectoscolaterales que pueda tener sobre otro softwareinstalado.

• Integridad de negocio: mi proveedor de serviciosresponderá rápida y efectivamente cuando informode un problema.

Uno de los frutos de esta iniciativa ha sido la colabo-ración y el acuerdo, respecto a la distribución de software,de conseguir una nueva generación de productos basándo-se en estos patrones.

Dentro de esta propuesta, hay que destacar, en lo queconcierne al ciclo de vida de desarrollo de software, el do-cumento oficial The Trustworthy Computing Security Deve-lopment Lifecycle (a partir de ahora, SDL), que pretende es-tablecer las guías a seguir en un desarrollo seguro y definirpatrones repetibles que puedan servir de medida de la se-guridad del software producido. Adicionalmente, existe unsitio Web (http://www.microsoft.com/mscorp/twc/default.mspx)

1 Disponible en http://www.microsoft.com/mscorp/twc/twc_whitepaper.mspx



que explica con detalle el conjunto de medidas tomadaspor Microsoft para cumplimentar los principios definidospor la iniciativa. El número de acciones para llevarlo a caboes bastante grande (como es de esperar de una compañía

de tal volumen), y sobrepasan con mucho el ámbito de losobjetivos de esta obra, por lo que remitimos al lector inte-resado a la Web antes citada.

Los 3 factores clave de la propuesta SDL son:• Procesos repetibles (en camino hacia un enfo-

que más científico del ciclo de vida, los procesos

en que podemos descomponer el desarrollo de unaaplicación, deberían de poderse repetir siempre,incluyendo aquellos que atañen a la seguridad dela misma).

• Educación en Ingeniería de Software, haciendoespecial énfasis en la seguridad, lo que implica la

creación de un comité de seguridad dentro de la em-presa y de unos responsables de seguridad en el equi-po de desarrollo. Naturalmente, tales compromisosimplican un conocimiento previo de la materia y una voluntad de continuidad en el esfuerzo.

• Métrica y auditoría: Conjunto de técnicas tendentesa conseguir una medida del avance del proceso en tér-minos de cantidad de proceso realizado y tiempo res-tante respecto al plazo de finalización programado.

El principio SD3

La forma en que estos principios se formalizan enmetodologías recibe el nombre de SD3: Seguro por Diseño,



Seguro por Defecto y Seguro en el Despliegue. A lo que hay que añadir un cuarto factor fundamental: Seguridad en lascomunicaciones, con lo que la fórmula final adopta la for-ma SD3 + C.

Las dos primeras, son las que mayores beneficios ofre-cen. En general, la introducción de estas ideas dentro delciclo de vida, conducen a un gráfico de proceso similar alsiguiente:

Seguro por Diseño. Al menos 3 puntos a tener en cuenta:• Arquitectura y código seguros.

• Análisis de riesgos.• Reducción de vulnerabilidades.

figura 1 Secuencia de acciones de seguridad alo largo del ciclo de vida



Seguro por Defecto. Se puede dividir en otros 3 aspectos:• Reducción del posible área de ataque.• Las características no usadas del producto deben

deshabilitarse por defecto

• Requerir privilegios mínimos.

Seguro en el Despliegue. Implica:• Proteger, detectar, defender, recuperar, adminis-

trar… todos estos verbos asociados con la gestiónde la seguridad.

• En la gestión de procesos: elaborar guías “Cómohacer…?”, y guías de arquitectura.• Formación.

¿Parece excesivo? Pues no lo es. Basta con recordar loque Howard/Leblanc llaman:

La ventaja del atacante y el dilema del defensor

Como el problema se plantea de forma global —en susentido más amplio—, requiere de una estrategia, un aná-lisis y unas acciones de la misma naturaleza. Naturaleza

que, por otra parte, es desventajosa y que —los citados au-tores— en su excelente obra2 sobre seguridad denominan“La ventaja del atacante y el dilema del defensor”, que searticula en 4 principios fundamentales:

1. El que defiende tiene que defender todos los pun-tos; el atacante puede seleccionar el más débil.

2 “Writing secure code” 2ª Edición. Ed. Microsoft Press. Michael Howard y DavidLeBlanc.



2. El defensor solo puede defenderse de ataques co-nocidos; el atacante puede probar nuevas formas deataque.

3. El defensor debe de estar en constante estado de

vigilancia; el atacante puede golpear a voluntad.4. El defensor debe jugar según las reglas; el atacan-te puede jugar sucio.

Y para acabar de empeorar las cosas, ni siquiera cono-cemos la identidad del atacante, que en el peor de los ca-

sos podrían estar dentro de nuestra propia “casa”: emple-ados descontentos, espías tecnológicos o simple dejadezpueden suponer una vía de escape a importante informa-ción corporativa.

Naturalmente, nunca estaremos totalmente a salvo,pero sí podremos poner las cosas difíciles a los atacantes y

—sobre todo— definir cuáles son los baremos de seguri-dad que consideramos suficientes en nuestras aplicaciones.

Creación de una cultura de seguridad en la empresa

Los citados autores van un paso más allá y nos su-

gieren algunas ideas para instaurar en nuestros equiposde desarrollo una “cultura sobre la seguridad”, tales como:nominar un especialista de seguridad que esté al tanto delos últimos parches y sistemas que ofrezca el mercado,seleccione un equipo de seguridad dentro de la empresa,suministre la información o la formación adecuada so-bre el tema a los que la necesitan, establezca —incluso—

recompensas al código más seguro, o al mejor parche, y finalmente compruebe las amenazas de seguridad y su



severidad para ofrecer consejos sobre la mejor forma desolucionarlas.

Sería el gestor de seguridad de la empresa, y, en grandesorganizaciones, el encargado de designar y mantener elequipo de seguridad (Security Team), propuesto por las ini-ciativas de buenas prácticas.

Áreas de influencia

En un documento publicado por Microsoft en 20033,

se establecían un conjunto de principios que regirían a todala empresa y que serían aplicables a cualquier otra que qui-siera abordar con un mínimo de seriedad los problemas deseguridad. En forma esquemática, se dividían en 4 áreas deinfluencia: la administrativa, la de usuarios y datos , la pura-mente vinculada al mundo del desarrollo de software, y la co-

rrespondiente a operaciones y mantenimiento. Describimossomeramente las competencias de cada una.• Administrativa: debería asumir un compromiso con

la gestión del riesgo y la concienciación de la segu-ridad. Sus acciones relacionadas serían la gestión del

Recomendación: Lo adecuado es que esa cultura formeparte de todos y cada uno de los integrantes de un proyectode software, y de acuerdo con ese principio, cada rol del equi-po de trabajo debería también ser responsable de su “parcela”

de seguridad: la que compete ese rol.

n o t a

3 El documento todavía estaba disponible en el momento de la escritura de este capítu-lo en la dirección: http://download.microsoft.com/download/c/3/e/c3e59c9e-9fe9-

4cca-b555-dd059e34ae28/La_seguridad_en_Microsoft.doc



riesgo en función de los objetivos empresariales,la gestión y administración de roles vinculados ala seguridad y el compromiso de trabajo en modoseguro.

• Usuarios y datos: se relaciona con 2 activos fun-damentales a nivel corporativo. Para el primero deellos, se trata de vigilar y garantizar que las perso-nas acceden a la información necesaria para la co-rrecta realización de sus funciones, preservando elresto de la información y tratando de establecer el

difícil equilibrio entre seguridad y eficacia laboral.Hay muchos factores que intervienen aquí, pero,comprobar la garantía de identidad y basar las de-cisiones en la clasificación y el uso razonable de losdatos, son dos de las más importantes a este nivel.

• Desarrollo de software: respecto al desarrollo, el

objetivo debería ser conseguir la producción desoftware seguro y de calidad, y para ello, hay queestablecer las estrategias de una defensa en pro-fundidad, reduciendo al mínimo la superficie de ata-que (recuerde el lector ni siquiera Aquiles se libróde los ataques, aunque su superficie de exposiciónera mínima)…

• Operaciones y mantenimiento: por último, inte-grar sistemas y personas, y lograr establecer los me-canismos a través de los cuales éstas puedan garan-tizar el funcionamiento de esos sistemas con unmínimo de garantías de seguridad.

Aunque son muchas las posibilidades en este cam-po, algunas de las acciones típicas podrían basarse en la



planificación del mantenimiento, el respeto a las políticasde seguridad, la supervisión y auditoria de los mismos, y,por supuesto, la respuesta adecuada a los incidentes.

En la siguiente tabla 1, aparecen estos principios ex-

puestos de forma esquemática, y detallados para cada unade las 4 áreas de influencia.

Categoría Principio de seguridad

Administrativa:Dirigido al compromiso de la

administración con la gestión delriesgo y la concienciación sobreseguridad.

Usuarios y datos:Incluye la autentificación, la

privacidad del usuario y laautorización de datos.

Desarrollo de plicaciones y sistemas:Dedicado a diseñar y desarrollar

sistemas seguros.

Operaciones y mantenimiento:Integra las personas, los procesos

y la tecnología para construir,mantener y poner en marchasistemas seguros.

• Gestionar el riesgo de acuerdo con los objetivosempresariales.

• Definir roles y responsabilidades administrativos.• Invertir en el diseño de la seguridad.• Comprometerse a trabajar de modo seguro.

• Practicar el menor número de privilegios.• Basar las decisiones en la clasificación y el uso razo-

nable de los datos.• Hacer cumplir la protección de la Privacidad y de la

Información Personal Identificable.

• Asegurar la integridad de los datos.• Controlar la garantía de identidad.• Integrar la disponibilidad.

• Integrar la seguridad en el ciclo de vida.• Diseñar una defensa en profundidad.• Reducir la superficie de ataque.• Mantener la simplicidad.

• Planificar el mantenimiento del sistema.• Hacer respetar la configuración de seguridad y su

endurecimiento.• Supervisar y auditar.• Responder ante los incidentes.• Verificar la recuperación tras un desastre.

Tabla 1. Principios de seguridad



En el citado documento, se concluye con este aparta-do denominado “las cinco garantías de confianza”:

1. Mi identidad no se ve comprometida.2. Los recursos que necesito son seguros y están dis-

ponibles, entendiendo seguro y disponible de estemodo:• Seguro. Libre de la manipulación y del acceso no

autorizado.• Disponible. Libre de vulnerabilidades de seguridad

y disponible a través de acuerdos de servicio.

3. Mis datos y comunicaciones son privados.4. Entiendo mi papel y soy responsable de mis debe-res para garantizar un entorno seguro.

5. Recibo respuestas adecuadas a los riesgos que meafectan.

Y todo esto, sin que abandonemos nunca nuestra mejor arma: el sentido común. Si una buena práctica, una reco-mendación del gurú, o cualquier otra consideración al res-pecto no encajan con el conjunto coherente de las medidasdiseñadas, es que probablemente no es aplicable en nues-tro caso. No se preocupe, no pasa nada.

Marino Posadas. Programación segura con .Net Framework (ejemplo)

Documents

Transcript of Marino Posadas. Programación segura con .Net Framework (ejemplo)