INSTITUTO POLITECNICO NACIONAL
ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y ELÉCTRICA
UNIDAD CULHUACÁN
Sección de Estudios de Posgrado e Investigación
“Esquema de Seguridad para el desarrollo de Aplicaciones Web para
CFE”
T E S I N A
QUE PARA OBTENER EL GRADO DE ESPECIALISTA EN SEGURIDAD INFORMÁTICA Y TECNOLOGÍAS DE LA INFORMACIÓN.
P R E S E N T A:
ING. MANUEL ALEJANDRO CARREÓN MENDOZA
ASESOR:
DR. RUBÉN VÁZQUEZ MEDINA
Instituto Politécnico Nacional ESIME Culhuacán
2 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE
Instituto Politécnico Nacional ESIME Culhuacán
Esquema de seguridad para el desarrollo de aplicaciones Web para CFE
Instituto Politécnico Nacional ESIME Culhuacán
Esquema de seguridad para el desarrollo de aplicaciones Web para CFE
Instituto Politécnico Nacional ESIME Culhuacán
3 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE
Instituto Politécnico Nacional ESIME Culhuacán
4 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE
ESQUEMA DE SEGURIDAD PARA EL DESARROLLO DE APLICACIONES WEB PARA CFE
Instituto Politécnico Nacional ESIME
Culhuacán
Sección de Estudios de Posgrado e Investigación
Tesina para obtener el grado de especialista en Seguridad Informática y Tecnologías de la Información
Presenta Ing. Manuel Alejandro Carreón Mendoza
Asesor Dr. Rubén Vázquez Medina
Instituto Politécnico Nacional ESIME Culhuacán
5 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE
Tabla de Contenido
RESUMEN 7
ABSTRACT 8
CAPÍTULO 1: MARCO DE REFERENCIA 9
1.1 DEFINICIÓN DEL PROBLEMA 9
1.2 JUSTIFICACIÓN 9
1.3 OBJETIVO 10
1.4 HIPÓTESIS 10
CAPÍTULO 2: ESTADO DEL ARTE 11
2.1 HISTORIA DE LA WORLD WIDE WEB 11
2.2 EVOLUCIÓN DE LA WEB 11
2.3 APLICACIONES WEB 12
2.4 TECNOLOGÍAS DE SERVIDOR PARA EL DESARROLLO DE APLICACIONES WEB 13
2.4.1 Php 14
2.4.2 Asp.Net 16
CAPÍTULO 3: DESARROLLO DE APLICACIONES SEGURAS 18
3.1 RESUMEN 18
3.2 CONSIDERACIONES INICIALES PARA EL DESARROLLO 18
3.2.1 Minimizando el área de la superficie de ataque 19
3.2.2 Seguridad por defecto 20
3.2.3 Mínimo privilegio 20
3.3 PRINCIPIOS DE SEGURIDAD EN EL DESARROLLO 20
3.3.1 Defensa profunda 20
3.3.2 Fallar de manera segura 20
3.3.3 Segregación de funciones 21
3.4 CONSIDERACIONES ADICIONALES 21
3.4.1 Inseguridad de los sistemas externos 21
3.4.2 No confiar en la seguridad a través de la oscuridad 21
3.4.3 Simplicidad en el desarrollo 22
3.4.4 Corregir errores de seguridad correctamente 22
Instituto Politécnico Nacional ESIME Culhuacán
6 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE
CAPÍTULO 4: MODELADO DE AMENAZAS EN EL DESARROLLO 23
4.1 RESUMEN 23
4.2 ANTECEDENTES 23
4.3 PASO 1: IDENTIFICAR OBJETIVOS DE SEGURIDAD 25
4.4 PASO 2: CREAR UNA DESCRIPCIÓN GENERAL DE LA APLICACIÓN 25
4.5 PASO 3: DESCOMPONER LA APLICACIÓN 26
4.6 PASO 4: IDENTIFICACIÓN DE AMENAZAS 26
4.6.1 Identificar amenazas y ataques comunes 27
4.6.2 Metodología STRIDE 29
4.6.3 Identificar amenazas a través de casos de uso 29
4.6.4 Identificar amenazas a través del flujo de datos 29
4.7 PASO 5. IDENTIFICACIÓN DE VULNERABILIDADES 30
4.7.1 Autenticación 30
4.7.2 Autorización 32
4.7.3 Validación de datos 33
4.7.4 Administración de la Configuración 33
4.7.5 Datos sensibles 34
4.7.6 Administración de sesiones 34
4.7.7 Cifrado 35
4.7.8 Manipulación de parámetros 36
4.7.9 Manejo de excepciones 36
4.7.10 Auditoria y bitácoras 37
4.8 DESCRIPCIÓN DE UN EJEMPLO TÍPICO 37
Paso1: Definición de objetivos 38
Paso2: Descripción general de la aplicación. 38
Paso 3: Descomponiendo la Aplicación 40
Paso 4: Identificando Amenazas 41
Paso 5: Identificación de Vulnerabilidades. 43
Siguientes Pasos 44
CONCLUSIONES 45
RECOMENDACIONES 46
TRABAJO A FUTURO 47
BIBLIOGRAFÍA 48
Instituto Politécnico Nacional ESIME Culhuacán
7 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE
Resumen
Con la cada vez más común integración de las tecnologías de redes a las empresas, se han generado cambios en la manera de trabajar de estas y se han venido implementando nuevas tecnologías que les permiten aprovechar mejor los recursos tecnológicos. Muchas de las aplicaciones que anteriormente se trabajan en ambientes de escritorio se han migrado a tecnologías Web, esto en gran parte motivado por la facilidad de acceder a las aplicaciones desde cualquier computadora conectada a la intranet o desde Internet y por las necesidades de disponibilidad de información de las organizaciones.
La complejidad de los sistemas web ha venido en aumento, cada vez ofrecen mayor funcionalidad, llegando en algunos casos a lucir como las aplicaciones de escritorio y ofreciendo la misma o mayor facilidad de uso.
La implementación de estos sistemas en los procesos más importantes viene de la mano con estrictos requisitos de accesibilidad, respuesta y seguridad en las aplicaciones. Para cumplir con los requerimientos es necesario reflexionar sobre la mejor arquitectura y las técnicas de diseño más adecuadas para satisfacerlos.
Anteriormente la presencia de aplicaciones web se limitaba al uso de portales que mostraban información estática o general de las empresas; hoy en día esos portales se han convertido en el centro de trabajo de gran parte de los procesos productivos y administrativos de las empresas.
La Comisión Federal de Electricidad (CFE) es una empresa que cuenta con una gran infraestructura de red y consciente de las oportunidades y beneficios que los sistemas web le pueden ofrecer, se han desarrollado muchas aplicaciones para satisfacer distintas necesidades de sus procesos productivos, pero a su vez, no se cuenta con un esquema unificado para el desarrollo de sistemas basados en Web. En cada centro de trabajo, los distintos equipos de desarrollo han decidido que tecnologías utilizar para el desarrollo de los sistemas; en muchas ocasiones el tema de la seguridad de los sistemas no se ha considerado al momento de desarrollarlos.
Con este trabajo de Tesina, se busca proponer un esquema de seguridad para el desarrollo de Aplicaciones Web que garantice la protección de los datos sensibles de los procesos productivos y administrativos de la CFE.
Instituto Politécnico Nacional ESIME Culhuacán
8 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE
Abstract
Each time, integration of network technologies is more common between enterprises. Changes have been generated in the way these firms work actually and implementation of new technologies has been made too. Many desktop applications (Windows applications) have been migrated to Web Application, this motivated by the advantages that Web Technology offers like access from any computer connected to the company’s network or from internet.
Complexity of Web Systems has growth, each time they offer more functionability performing sometimes as Desktop Applications, and offering the same or more usability.
The implementation of these systems in the more important process comes with strict requirements of accessibility, response and security in applications. To satisfy the requirements is necessary to reflex about the best architecture and the more adequate and best practices of Software Design.
The presence of Web Applications before was limited for using of simple Portals that showed only static information or general information about enterprises; by now theses portals have become the main works center of most part of the productive and administrative process of the companies.
The Comisión Federal de Electricidad (CFE) is an enterprise that counts with a great network infrastructure. Being conscious of big opportunities and benefits that Systems can offer, Applications have been development in the company to satisfy different needs of his productive processes, but at the same time it does not count with an unified scheme of Software Development based on Web platform. In each work center, the development teams have decided which kind of Technologies to use for Software Development; often Systems Security has not been considerate in the development.
This work proposes a scheme of security for the development of Web Applications that grant the protection of sensible data of the productive and administrative processes of CFE.
Instituto Politécnico Nacional ESIME Culhuacán
9 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE
Capítulo 1: Marco de Referencia
1.1 DEFINICIÓN DEL PROBLEMA
Actualmente muchas organizaciones no cuentan con un esquema de seguridad definido que garantice la protección de la información procesada y almacenada en los distintos Sistemas Web que se encuentran operando en su Intranet corporativa; esta misma situación se vive en la Comisión Federal de Electricidad. Muchas aplicaciones se han desarrollado sin contemplar algún mecanismo de seguridad o análisis de posibles riesgos de la información que contienen y los efectos que produciría en la organización un ataque sobre ellos.
1.2 JUSTIFICACIÓN
En la actualidad, la información, es uno de los activos más importantes de cualquier organización y los sistemas informáticos ayudan en gran medida a la administración, almacenamiento y procesamiento de ésta. Tomando en cuenta la facilidad que los Sistemas Web ofrecen para acceder a la información desde cualquier equipo conectado a la intranet y tomando como premisa que la información contenida se utiliza para la toma decisiones en varios procesos, resulta imprescindible establecer mecanismos de seguridad que garanticen la integridad de la información, su disponibilidad y que sólo sea accesible para el personal autorizado.
Instituto Politécnico Nacional ESIME Culhuacán
10 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE 1.3 OBJETIVO
Proponer una estrategia para el desarrollo seguro de Aplicaciones Web que sirva de herramienta para la planeación de la seguridad en el desarrollo de sistemas basados en Web dentro de la Comisión Federal de Electricidad. La estrategia propuesta definirá los mecanismos y principios que se deben considerar para lograr los niveles de seguridad esperados, según el nivel de importancia de los sistemas en la organización y el valor de la información que contienen.
1.4 HIPÓTESIS
La estrategia de seguridad que se propone, podrá ser implementada en los nuevos proyectos que se realicen, así mismo, los sistemas que no cuenten con seguridad implementada podrán utilizar esta estrategia para aumentar el nivel de seguridad de la información.
Instituto Politécnico Nacional ESIME Culhuacán
11 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE
Capítulo 2: Estado del Arte
2.1 HISTORIA DE LA WORLD WIDE WEB
La World Wide Web, conocida también como la Web, es una red mundial de documentos entrelazados se les denomina así porque tienen enlaces a otros documentos. A estos enlaces entre documentos se les define con el término de hipertexto. La Web fue creada alrededor de 1989 por el inglés Tim Berners-Lee y el belga Robert Cailliau mientras trabajaban en el CERN (European Organization for Nuclear Research) en Ginebra, Suiza, y fue publicada en 1992.
Se diseñó para trabajar sobre la Internet1, en un inicio era muy complicado crear los documentos, fue así que se diseñó el Lenguaje de Formato de Documentos para Hipertexto ó HTML y a su vez se diseñó el Protocolo de transferencia de Hipertexto ó HTTP para transportar los documentos a través de la red. Mediante el uso de HTML, que relativamente es sencillo, muchos usuarios sin conocimientos computacionales avanzados pudieron desarrollar lo que se conoce como Páginas Web, que se transferían de una computadora a otra mediante el protocolo HTTP.
2.2 EVOLUCIÓN DE LA WEB
La Web es una tecnología que ha evolucionado considerablemente, primero lo hizo pensando en la comodidad del usuario para visualizar de manera sencilla la información, que inicialmente sólo se presentaba mediante texto, posteriormente se añadieron las imágenes y después el sonido, ofreciendo al usuario una experiencia multimedia que enriquecía los contenidos compartidos.
La mayor evolución se generó alrededor del año 1999, cuando muchas personas y empresas vieron el potencial económico de la Web, fue así que los sitios web empezaron a transformarse de sitios Web estáticos en Aplicaciones Web dinámicas. La necesidad de ofrecer mejores contenidos y mayor dinamismo a los sitios motivó la aparición de muchas tecnologías que prometían ofrecer las soluciones buscadas, muchas desaparecieron, otras tantas se mantienen y continúan en desarrollo.
1Internet es un conjunto descentralizado de redes de comunicación interconectadas, que utilizan la familia de protocolos TCP/IP, garantizando que las redes físicas heterogéneas que la componen funcionen como una red lógica única, de alcance mundial.
Instituto Politécnico Nacional ESIME Culhuacán
12 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE 2.3 APLICACIONES WEB
Con la necesidad de generar interacción de los usuarios con los sitios Web, los fabricantes de Servidores Web2 permitieron que se ejecutaran programas externos mediante la implementación de aplicaciones CGI (Common Gateway Interface). Esto le permitió a las aplicaciones recibir información de los usuarios y procesarla en programas externos que generaban un resultado que era devuelto al usuario.
Las aplicaciones CGI podían crearse con cualquier lenguaje que entendiera el Servidor Web y que generara archivos ejecutables, normalmente se utilizaba el lenguaje C por su popularidad entre los desarrolladores. Básicamente el funcionamiento era el siguiente:
El cliente solicitaba al servidor un URL3 que contenía un CGI
El servidor prepara el entorno de ejecución y manda los parámetros necesarios a la aplicación
Se ejecuta la aplicación realizando todas sus operaciones y se captura su salida estándar.
El resultado es generado con el tipo MIME4 necesario para ser interpretado por el cliente.
Finalmente se envía el resultado de la solicitud al cliente.
Si bien esta tecnología era muy rápida, también presentaba sus inconvenientes:
La memoria de los servidores se podía saturar si se solicitaban simultáneamente muchas aplicaciones CGI, ya que al ser archivos ejecutables necesitaban espacio reservado de memoria.
La seguridad de los servidores se veía comprometida, ya que los ejecutables tenían acceso a los recursos del servidor al poder trabajar a niveles de memoria.
2 Un Servidor Web es un programa que implementa el protocolo HTTP y está diseñado para transferir lo que llamamos hipertextos, páginas web o páginas HTML.
3 URL significa Uniform Resource Locator, es decir, localizador uniforme de recurso. Es una secuencia de caracteres, de
acuerdo a un formato estándar, que se usa para nombrar recursos, como documentos e imágenes en Internet, por su localización.
4 MIME (Multipurpose Internet Mail Extensions), (Extensiones de Correo de Internet Multipropósito), son una serie de convenciones o especificaciones dirigidas a que se puedan intercambiar a través de Internet todo tipo de archivos (texto, audio, vídeo, etc.) de forma transparente para el usuario.
Instituto Politécnico Nacional ESIME Culhuacán
13 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE
CGI es raramente utilizado ahora, pero la idea de un proceso ejecutando información suministrada por el usuario o una base
Aplicaciones Web de las cuales se hablará
2.4 TECNOLOGÍAS DE SERVIDOR PARA EL DESARROLLO DE APLICACIONES WEB
Existen varias tecnologías para el desarrollo de P
populares son PHP, JSP, ASP y más recientemente ASP.NET. Cada una tiene sus diferencias y es soportada por diferentes empresas o grupos de desarrolladores.
a los detalles, todas ofrecen herramientas s aplicación ya sea comercial, empresarial o personal lenguaje de programación, el tipo de licencia que manejan
PHP y JSP; Microsoft IIS es normalmente utilizado para soportar las tecnologías propias como lo son ASP y ASP.NET.
Gráfica 1 Distribución de Servidores (Wss, 2009)
Instituto Politécnico Nacional ESIME Culhuacán
Esquema de seguridad para el desarrollo de aplicaciones Web para CFE
CGI es raramente utilizado ahora, pero la idea de un proceso ejecutando información suministrada por el usuario o una base de datos y generando un resultado, es ahora el
eb de las cuales se hablará más adelante.
TECNOLOGÍAS DE SERVIDOR PARA EL DESARROLLO DE APLICACIONES
nologías para el desarrollo de Páginas Web dinámicas o de s
populares son PHP, JSP, ASP y más recientemente ASP.NET. Cada una tiene sus diferencias y es soportada por diferentes empresas o grupos de desarrolladores. Hablando a grandes rasgos y sin llegar a los detalles, todas ofrecen herramientas suficientes para el desarrollo de casi cualquier tipo de ya sea comercial, empresarial o personal. Sus diferencias más significativas radican en el
el tipo de licencia que manejan y los costos de uso.
Según las estadísticas servidores Web más utilizados en la industria son Apache y Microsoft IIS. Ambos pueden ser configurados para ejecutar cualquiera de las tecnologías antes mencionadas
utilizados con mayor frecuencia para una tecnología en específico. Apache
es normalmente utilizado para tecnologías gratuitas como lo son PHP y JSP; Microsoft IIS es normalmente utilizado para soportar las tecnologías propias como lo son
Distribución de Servidores (Wss, 2009)
Instituto Politécnico Nacional ESIME Culhuacán
Esquema de seguridad para el desarrollo de aplicaciones Web para CFE
CGI es raramente utilizado ahora, pero la idea de un proceso ejecutando información dinámica es ahora el pilar de las
TECNOLOGÍAS DE SERVIDOR PARA EL DESARROLLO DE APLICACIONES
o de servidor, las más populares son PHP, JSP, ASP y más recientemente ASP.NET. Cada una tiene sus diferencias y es Hablando a grandes rasgos y sin llegar uficientes para el desarrollo de casi cualquier tipo de . Sus diferencias más significativas radican en el
Según las estadísticas, los servidores Web más utilizados en la industria son Apache y Microsoft IIS. Ambos pueden ser configurados para ejecutar cualquiera de las tecnologías antes mencionadas, aunque son utilizados con mayor frecuencia para una tecnología en específico. Apache Web Server mente utilizado para gratuitas como lo son PHP y JSP; Microsoft IIS es normalmente utilizado para soportar las tecnologías propias como lo son
Instituto Politécnico Nacional ESIME Culhuacán
14 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE
Gráfica 2 Top Servidores Web en el Mercado 1995
2.4.1 Php
Inicialmente conocido como “Personal Home Page Tools”
1995 como un simple conjunto de S
funcionalidad y estructura iniciales eran básicas. En 1997 apareció la segunda versión, reescrita en C, la cual fue aceptada por un gran número de usuarios, alred
utilizaban esta nueva tecnología.
En noviembre de 1997 Rasmus
Zeev Zuraski decidieron darle seguimiento al proyecto. Se dieron cuenta que el proyecto inicial presentaba muchas limitantes para el desarrollo de aplicaciones comerci
una nueva versión a la cual llamaron PHP3;
pasaron el acrónimo a “Hypertext Preprocessor”. Esta nueva versión y sus características de extensibilidad llamaron la atención de doc
añadiendo nuevos módulos que fueron agregando funcionalidad al lenguaje
5Un Script es un guión o conjunto de instrucciones. Permiten la automatización de ejecutados por un intérprete de línea de órdenes y usualmente son archivos de texto.
Instituto Politécnico Nacional ESIME Culhuacán
Esquema de seguridad para el desarrollo de aplicaciones Web para CFE
1995-2009 (Wss, 2009)
Inicialmente conocido como “Personal Home Page Tools”, fue creado por Rasmus Lerdorf en como un simple conjunto de Scripts5 de Perl para controlar los accesos a su trabajo en línea
ciales eran básicas. En 1997 apareció la segunda versión, reescrita en C, la e aceptada por un gran número de usuarios, alrededor del 1% de los dominios de I
Rasmus decidió abrirlo al público, fue entonces que
Zeev Zuraski decidieron darle seguimiento al proyecto. Se dieron cuenta que el proyecto inicial presentaba muchas limitantes para el desarrollo de aplicaciones comerciales y decidieron
una nueva versión a la cual llamaron PHP3; eliminaron la implicación de herramienta personal y el acrónimo a “Hypertext Preprocessor”. Esta nueva versión y sus características de extensibilidad llamaron la atención de docenas de desarrolladores que se unieron al proyecto
que fueron agregando funcionalidad al lenguaje.
es un guión o conjunto de instrucciones. Permiten la automatización de tareas creando pequeñas utilidades. Son ejecutados por un intérprete de línea de órdenes y usualmente son archivos de texto.
Instituto Politécnico Nacional ESIME Culhuacán
Esquema de seguridad para el desarrollo de aplicaciones Web para CFE
, fue creado por Rasmus Lerdorf en de Perl para controlar los accesos a su trabajo en línea, la ciales eran básicas. En 1997 apareció la segunda versión, reescrita en C, la edor del 1% de los dominios de Internet
decidió abrirlo al público, fue entonces que Andi Gutmans y Zeev Zuraski decidieron darle seguimiento al proyecto. Se dieron cuenta que el proyecto inicial decidieron desarrollar la implicación de herramienta personal y el acrónimo a “Hypertext Preprocessor”. Esta nueva versión y sus características de enas de desarrolladores que se unieron al proyecto
tareas creando pequeñas utilidades. Son
Instituto Politécnico Nacional ESIME Culhuacán
15 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE
En el invierno de 1998, poco después de la liberación de PHP3, los nuevos líderes del proyecto decidieron reescribir el núcleo de PHP, los objetivos eran mejorar la ejecución de aplicaciones complejas y mejorar la adaptación de módulos. El nuevo núcleo fue llamado “Motor Zend” el cual logró los objetivos de su implementación y formó parte de la nueva versión liberada de PHP4.
Gran parte de la aceptación que ha tenido PHP radica en que la curva de aprendizaje es menor a la de otros lenguajes como Java y se pueden desarrollar cualquier tipo de aplicaciones; además cuenta con un gran número de desarrolladores que liberan al público su trabajo, permitiéndole a otros aprovechar de un sinnúmero de aplicaciones avanzadas que en la mayoría de los casos no tienen ningún costo y pueden ser modificadas y adaptadas según se requiera.
Ventajas
Es un lenguaje multiplataforma, ya que puede ejecutarse en los principales sistemas operativos (Linux, Windows, MacOS)
Conexión con los más populares manejadores de bases de datos libres y comerciales (MySQL, Oracle, MS SQL).
Capacidad de integración de módulos para mayor funcionalidad.
Extensa documentación
Soporte extenso en foros.
Es orientado a objetos
Una gran biblioteca nativa de funciones.
Fácil de aprender.
Desventajas
PHP no establece una metodología determinada de desarrollo; por lo tanto, el desarrollador puede seguir cualquier metodología que le permita escribir código ordenado, estructurado y manejable; en proyectos pequeños esto no resulta un problema, pero en los de mayor tamaño se dificulta un poco su mantenimiento y depuración. Existe un proyecto en PHP para implementar el patrón de diseño, Modelo Vista Controlador (o MVC), que permiten separar el tratamiento y acceso a los datos, la lógica de control y la interfaz de usuario en tres componentes independientes.
Instituto Politécnico Nacional ESIME Culhuacán
16 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE 2.4.2 Asp.Net
Microsoft introdujo la tecnología ASP (Active Server Pages) en diciembre de 1996 como una alternativa más en el mercado para el desarrollo de scripts que funcionaran en conjunto con el tradicional HTML para generar páginas dinámicas. La definición contextual de Microsoft es que "Las Active Server Pages son un ambiente de aplicación abierto y gratuito en el que se puede combinar código HTML, scripts y componentes ActiveX del servidor para crear soluciones dinámicas y poderosas para el Web".
En 1997 Microsoft comenzó a investigar un nuevo modelo de desarrollo para ASP, para resolver el problema de la separación de la presentación y el contenido y generar código limpio que fuera más fácil de mantener. Los encargados de esta tarea fueron Mark Anders y Scott Guthrie, quienes a finales de 1997 ya habían desarrollado el primer prototipo al cual llamaron XSP.
El desarrollo inicial de XSP fue hecho usando Java, pero pronto se decidió construir una nueva plataforma sobre el Common Language Runtime(CLR), pues ofrecía un ambiente orientado a objetos, recolección de basura y otras características que fueron vistas como características deseables. Esta integración con el CLR se consideró de alto riesgo ya que el éxito del nuevo lenguaje estaría de la mano del éxito del CLR.
Con el cambio al Common Language Runtime, XSP fue implementado en C# (conocido internamente como "Project Cool") y fue renombrado a ASP+, para este punto la nueva plataforma fue vista como el sucesor de Active Server Pages, y la intención fue proporcionar un medio fácil de migración para los desarrolladores ASP.
La primera demostración pública y la liberación de la primera beta de ASP+ y el resto del .NET Framework se realizó en el Microsoft's Professional Developers Conference el 11 de julio de 2000 en Orlando, Florida. Durante la presentación se demostró la compatibilidad de ASP+ usado en conjunción con COBOL y el soporte para una variedad de otros lenguajes fue anunciada, incluyendo los nuevos lenguajes de Microsoft, Visual Basic .NET y C#, así como también el soporte por medio de herramientas de interoperabilidad para Python y Perl creadas por la empresa canadiense ActiveState.
Instituto Politécnico Nacional ESIME Culhuacán
17 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE
Después de cuatro años de desarrollo, y una serie de versiones de evaluación en los años 2000 y 2001, ASP.NET 1.0 fue liberado el 5 de enero de 2002 como parte de la versión 1.0 del .NET Framework. Incluso antes de su liberación, docenas de libros habían sido escritos sobre ASP.NET y Microsoft lo promocionó fuertemente como parte de su plataforma para servicios web.
Ventajas
Las páginas de ASP.NET son mejor conocidas como Web Forms y son archivos con extensión ASPX en los cuales se colocan típicamente etiquetas HTML y XHTML6 estáticas para definir controles Web y controles de usuario que se ejecutan del lado del servidor. En estos archivos también se puede colocar código dinámico dentro de un bloque <% %> que se ejecuta en el servidor, similar a lo que se hace en PHP, JSP y ASP, aunque no se recomienda en absoluto. En su lugar Microsoft recomienda utilizar una de las principales características de ASP.NET, el modelo “Code-Behind” que coloca el código en un archivo por separado.
El archivo de código es nombrado igual que el archivo ASPX pero se le agrega la extensión VB o CS, u otra dependiendo del lenguaje de programación utilizado. Cuando se usa este estilo de programación, el desarrollador escribe el código correspondiente a diferentes eventos, como la carga de la página, o el clic en un control, en vez de un recorrido lineal a través del documento.
Desventajas
Una de las principales desventajas del ASP.Net, es la necesidad de contar con toda la infraestructura de Microsoft (lo cual implica un alto costo financiero que no todas las empresas pueden costear) para su funcionamiento como es Windows, IIS y el Visual Studio; si bien este último no es obligatorio, ya que existe la posibilidad de escribir con un editor de texto los archivos, resulta indispensable si queremos que el desarrollo sea ágil.
Cabe mencionar que existe una iniciativa llamada Mono Project para ejecutar aplicaciones de ASP.Net en ambientes Linux.
6 XHTML, acrónimo en inglés de eXtensible Hypertext Markup Language (lenguaje extensible de marcado de hipertexto), es
el lenguaje de marcado pensado para sustituir a HTML como estándar para las páginas web. En su versión 1.0, XHTML es solamente la versión XML de HTML, por lo que tiene, básicamente, las mismas funcionalidades, pero cumple las especificaciones, más estrictas, de XML.
Instituto Politécnico Nacional ESIME Culhuacán
18 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE
Capítulo 3: Desarrollo de Aplicaciones Seguras
3.1 RESUMEN
Los principios de seguridad permiten detectar los principales errores que se cometen durante el desarrollo de proyectos informáticos. Estas recomendaciones le permiten a los desarrolladores enfocarse en los puntos claves que son principalmente aprovechados por los atacantes.
Las aplicaciones sin una arquitectura de seguridad son como puentes sin estudios de diseño, a primera vista parecerán puentes, pero caerán con el primer ataque del medio. Las aplicaciones funcionan de la misma manera, así como se deben diseñar todas las funcionalidades para cumplir el propósito de su desarrollo, se deben planear los mecanismos con los que se defenderá la aplicación de ataques internos o externos.
3.2 CONSIDERACIONES INICIALES PARA EL DESARROLLO
La planeación de la seguridad debe ser una parte fundamental en el desarrollo de proyectos informáticos; esto se debe, en gran medida, a la importancia que han tomado los sistemas informáticos en las organizaciones y las tareas críticas que estos desempeñan. Sin bien no se puede hablar de una seguridad absoluta, lo que se busca es minimizar el riesgo y el impacto de los ataques en los procesos productivos.
En todas las organizaciones existen sistemas con mayor grado de importancia y otros tantos que más bien son de apoyo o informativos; se deben clasificar los sistemas para determinar el nivel de seguridad que se tiene que manejar según el valor de la información. No es lo mismo proteger un sistema con información sensible, como podría ser uno de apoyo al proceso operativo, que proteger un sistema que es informativo como un portal del área. Los posibles atacantes de cada sistema varían según su importancia o el valor de la información que contienen.
Instituto Politécnico Nacional ESIME Culhuacán
19 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE
Algunos tipos de atacantes pueden ser:
Personal descontento de la organización.
Virus, troyanos.
Atacantes motivados por algún objetivo.
Atacantes sin motivo de ataque, simplemente por ganar reputación.
Todos los principios de seguridad buscan el cumplimiento de los tres pilares básicos de la seguridad de la información:
Confidencialidad. Los datos deben ser accedidos únicamente por los usuarios que tienen permiso de hacerlo.
Integridad. Los datos no deben ser alterados o modificados por usuarios que no tengan autorización. Esta alteración puede darse al momento de trasmitir la información y desde su origen.
Disponibilidad. La información y por ende los sistemas, deben estar disponibles para los usuarios autorizados en el momento que la requieran.
Cuando estamos desarrollando controles de seguridad debemos considerar cada uno de estos pilares para obtener controles robustos de seguridad.
3.2.1 Minimizando el área de la superficie de ataque
Con cada característica que se agrega a una aplicación se añade cierto riesgo a la aplicación en total. El objetivo del desarrollo seguro es reducir el riesgo que se agrega con cada característica. Por ejemplo, cuando se agrega la funcionalidad para el usuario de generar filtros de datos, se expone a la aplicación a ataques de inyección SQL. Si se limita la característica de filtros a usuarios autorizados se disminuye el área de ataque; otra manera sería con validaciones de los datos que el usuario ingrese o diseñar la interfaz para que el usuario no introduzca los datos manualmente.
Lo que se busca es que las características no añadan más opciones para que los atacantes logren obtener beneficio de la información resguardada.
Instituto Politécnico Nacional ESIME Culhuacán
20 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE 3.2.2 Seguridad por defecto
Se debe establecer un nivel de seguridad por defecto, por ejemplo, que el usuario deba cambiar cada cierto tiempo su contraseña o que la contraseña deba contener cierta cantidad y tipos de caracteres. Estas opciones de seguridad deben estar presentes en la configuración inicial de la aplicación y permitirle al usuario deshabilitarlas para simplificar el uso de la aplicación y aumentar su riesgo. Un ejemplo de esto, es la opción de recordar usuario y contraseña, lo cual elimina el paso de introducir los datos para el usuario, pero aumenta su riesgo, ya que si alguien más tiene acceso al equipo podrá acceder a la información.
3.2.3 Mínimo privilegio
Lo que se busca es asignar sólo los privilegios necesarios a las cuentas de usuarios. Por ejemplo, si se necesita un usuario para sólo leer información desde una base de datos, se debe considerar un usuario que sólo tenga como único privilegio, la lectura de los datos necesarios sin poder acceder o escribir datos no autorizados. Este control de privilegios abarca los derechos de usuarios, permisos de CPU, memoria, red y archivos.
3.3 PRINCIPIOS DE SEGURIDAD EN EL DESARROLLO 3.3.1 Defensa profunda
En este principio lo que se busca es la creación de varias barreras de protección en lugar de tener sólo una barrera altamente protegida. La protección por niveles o capas, limitan el acceso al atacante sólo al siguiente nivel, provocando que invierta tiempo en detectar como penetrar la siguiente capa, lo que permite a los administradores del sistema su detección. Esto permite que no todo el sistema se vea comprometido por un ataque, lo que minimiza el impacto. Un ejemplo sería la colocación de varios firewalls en diferentes niveles, que impidieran el acceso a las secciones de red más críticas.
3.3.2 Fallar de manera segura
En todos los sistemas informáticos existen errores, muchas veces son estos errores los que permiten el acceso sin autorización a los atacantes. La manera en que se manejan los errores no debe generar huecos de seguridad. Si la aplicación tiene posibilidades de fallar, el manejo del error debe contemplar no generar puntos de acceso a atacantes. Esto pude suceder, por ejemplo, en un bloque Try-Catch en donde una sección del código falla y ya no se ejecuta el código restante que contiene mecanismos de seguridad, como se muestra en el ejemplo siguiente:
Instituto Politécnico Nacional ESIME Culhuacán
21 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE
isAdmin = True Try
CodigoQuePuedeFallar()
isAdmin = isAdministrator(User) Catch ex As Exception
MessageBox.Show("Error") End Try
3.3.3 Segregación de funciones
Este principio indica que se deben separar las funciones de los usuarios para que no se traslapen y generen conflicto. Por ejemplo un usuario que es vendedor en un sitio de ventas por Internet puede también ser comprador, pero no debe poder comprarse así mismo. Otro caso sería el de Administrador y Usuario, el administrador debe poder acceder al sistema para configurarlo, pero no debe tener la capacidad de acceder como un súper usuario privilegiado y poder realizar actividades tomando la identidad de otro usuario.
3.4 CONSIDERACIONES ADICIONALES 3.4.1 Inseguridad de los sistemas externos
Consiste en asumir que todos los datos o invocaciones que se reciben de sistemas externos sobre los que no se tiene control, son posibles fuentes de ataque ya que seguramente el proveedor tiene sus propios controles de seguridad que no necesariamente se alinean con los de CFE. Ellos podrán darle mayor o menor importancia a ciertos controles que pueden pasar a afectar a la organización. Toda la información que se recibe de estas entidades debe de ser validada para asegurar que no ponga en riesgo los sistemas de CFE.
3.4.2 No confiar en la seguridad a través de la oscuridad
La seguridad por medio de la oscuridad es un control débil; no se debe confiar en que ocultando la funcionalidad o estructura de la aplicación a los posibles atacantes se estará seguro. Se ha demostrado que mantener en secreto la funcionalidad de las aplicaciones no es garantía de seguridad, un ejemplo de ello es el sistema operativo Microsoft Windows, que aunque su código no es libre, muchos programadores han sabido encontrar sus vulnerabilidades. Un ejemplo de un sistema de código libre y seguro sería Linux.
Instituto Politécnico Nacional ESIME Culhuacán
22 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE 3.4.3 Simplicidad en el desarrollo
Este principio va de la mano con el de minimizar la superficie de ataque. Se debe optar por programar las aplicaciones de manera sencilla y evitar codificaciones complejas que dificulten el entendimiento y mantenimiento de los sistemas. Una codificación compleja puede ser más propensa a errores o que estos sean más difícil de detectar.
Un ejemplo sería el uso de procedimientos recursivos, que si bien reducen la cantidad de código utilizado, también aumentan su complejidad.
3.4.4 Corregir errores de seguridad correctamente
Cuando se corrigen errores que se han detectado, se debe hacer un análisis profundo del error para detectar si se encuentra presente en diferentes partes del sistema o en otros sistemas desarrollados, utilizando los mismos principios de codificación o reutilización de código.
Instituto Politécnico Nacional ESIME Culhuacán
23 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE
Capítulo 4: Modelado de Amenazas en el Desarrollo
4.1 RESUMEN
El Modelado de Amenazas es una técnica de ingeniería que se puede utilizar para ayudar a identificar amenazas, ataques y vulnerabilidades que podrían afectar a las aplicaciones. Se puede utilizar para dar forma al diseño de la aplicación, alcanzar los objetivos de seguridad de la empresa y reducir los riesgos. El Modelado de Amenazas también permitirá la justificación de la implementación de las características de seguridad dentro de los sistemas o las prácticas de seguridad para utilizarlo, para la protección de los activos de la empresa. En este capítulo se describe una metodología para el modelado de amenazas que se adapta a las necesidades de CFE, la metodología permite la detección oportuna de las amenazas más comunes a las que están expuestas las aplicaciones Web.
4.2 ANTECEDENTES
La identificación de las posibles amenazas le permitirá elegir los mecanismos o controles de seguridad que mejor se adaptan a la aplicación; por ejemplo, no tendría sentido invertir en un control que costara $100,000.00 pesos si los niveles de fraude son mínimos y no se justifica invertir todo ese capital. Existen en el mercado varias metodologías para el modelado de amenazas, se enlistan algunas a continuación:
Trike. Es un framework7 y una metodología conceptual, acompañada por una herramienta que intenta facilitar el proceso de modelado. La metodología, está diseñada con el propósito de permitir al analista describir de forma completa y precisa las características de seguridad de un sistema, desde los detalles de alto nivel de la arquitectura, hasta la implementación.
AS/NZS 4360:2004 Risk Management. Es el estándar de Australia y Nueva Zelanda, se liberó en 1999 y fue revisado en 2004. Fue el primer estándar formal para la documentación y administración del riesgo.
CVSS. Sistema de Marcación de Vulnerabilidades Comunes. Es establecida por el grupo de trabajo de revelación de Vulnerabilidades NIAC, que incorpora las aportaciones de Cisco, Symantec, ISS, Qualys, Microsoft, CERT/CC y eBay.
7 Framework es una estructura de soporte definida, mediante la cual otro proyecto de software puede ser organizado y desarrollado. Típicamente, puede incluir soporte de programas, bibliotecas y un lenguaje interpretado entre otros software para ayudar a desarrollar y unir los diferentes componentes de un proyecto.
Instituto Politécnico Nacional ESIME Culhuacán
24 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE
Octave. Pertenece al Instituto de Ingeniería de Software del CMU en colaboración con el CERT, está dirigido a riesgo organizacional más que a riesgo técnico.
Modelado de Amenazas de Microsoft. Es el modelo propuesto por Microsoft que puede ser aplicado a cualquier desarrollo informático ya que se enfoca en técnicas que permiten la identificación de amenazas y vulnerabilidades, por medio de una serie de pasos en los que va descomponiendo la aplicación.
¿Para qué sirve?
Dar forma al diseño de la aplicación para cumplir los objetivos de seguridad.
Ayudar a que los pros y los contras se vean con más facilidad al tomar decisiones de ingeniería claves.
Reducir el riesgo de problemas de seguridad que surjan durante el desarrollo y las operaciones.
Ayuda a comprender mejor el funcionamiento de la aplicación.
Ayuda a encontrar errores complejos de diseño difíciles de encontrar.
La estrategia propuesta en este trabajo es congruente con el modelo de amenazas de Microsoft, ya que el modelo ha sido bien recibido en la comunidad de desarrolladores, cuenta con herramientas de apoyo, extensa documentación adicional y se alinea con las políticas de CFE de utilizar preferentemente el Software licenciado de Microsoft. El modelo, como se mencionó anteriormente, es aplicable a cualquier tecnología de desarrollo.
Pasos a seguir
1. Identificar objetivos de seguridad. Aclarar los objetivos le ayudará a centrarse en la actividad de modelado de amenazas y a determinar cuánto esfuerzo dedicará a los siguientes pasos.
2. Crear una descripción general de la aplicación. Personalizar los actores y las características importantes de la aplicación ayudará a identificar las amenazas más importantes durante el paso 4.
3. Descomponer la aplicación. Una comprensión detallada de la mecánica de la aplicación facilita el descubrimiento de amenazas más relevantes y detalladas.
4. Identificar amenazas. Utilizando la información que se detalla en los pasos 2 y 3 se identificarán las amenazas más importantes para el contexto y el escenario de la aplicación.
5. Identificar vulnerabilidades. Revisando las capas de la aplicación se identificarán los puntos débiles relacionados con las amenazas. Se utilizarán las categorías de vulnerabilidades para identificar con mayor facilidad las áreas en las que tienen lugar los errores más frecuentes.
Instituto Politécnico Nacional ESIME Culhuacán
25 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE 4.3 PASO 1: IDENTIFICAR OBJETIVOS DE SEGURIDAD
Los líderes de la organización junto con el equipo de desarrollo deben identificar cuáles serán los objetivos de seguridad:
Identidad. Concentrarse en los controles que garanticen la identidad de los usuarios (ejem.
aplicación bancaria).
Reputación. La pérdida de reputación de la empresa derivado de un ataque.
Financiero. Las pérdidas financieras generadas por un ataque a las que está expuesta la empresa.
Privacidad y Regulaciones. En qué medida la aplicación debe proteger la información del usuario.
Disponibilidad. Cuáles son los niveles de disponibilidad con los que debe cumplir la aplicación. Existen aplicaciones que son críticas para los procesos de las empresas, por lo que el tiempo de disponibilidad debe ser del 99.99%.
4.4 PASO 2: CREAR UNA DESCRIPCIÓN GENERAL DE LA APLICACIÓN
Después de definir los objetivos de seguridad de la aplicación, se debe analizar para determinar los componentes, flujos de datos y límites de confianza. Para lograr esto se puede utilizar la documentación de arquitectura y diseño de la aplicación, diagramas UML, diagrama de componentes de alto nivel, especificaciones funcionales, diagramas de casos de uso, identificación de las tecnologías utilizadas, identificación de los mecanismos de seguridad utilizados, entre otros.
Navegador
Presentación
Negocio
Acceso a Datos
DB Server
(MS SQLServer)
HTTP TCP/IP
Identificación de la aplicación Web
Autentificación Windows
DMZ
Figura 1 Ejemplo de la arquitectura de la aplicación.
Instituto Politécnico Nacional ESIME Culhuacán
26 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE 4.5 PASO 3: DESCOMPONER LA APLICACIÓN
Se debe descomponer la aplicación para identificar:
Límites de confianza. Identificar los límites de confianza permitirá enfocarse en los puntos críticos. Se pueden definir los límites identificando los puntos donde la integridad y la confidencialidad de los datos se ven comprometidos. Un cambio de límite de confianza podría ser cuando se envía información a través de Internet.
Flujo de datos. Se deben trazar los flujos de datos de la aplicación, esto permitirá saber hacia donde fluye la información y de qué manera interactúa la aplicación con sistemas externos, con clientes y entre los componentes internos. Se debe poner especial atención en el flujo de los datos sensitivos como los de autentificación.
Puntos de acceso. Todos los puntos de acceso a la aplicación son potenciales puntos de ataque. Un punto de acceso podría ser el servidor Web que está escuchando solicitudes Web.
Puntos de salida. Identificar los puntos donde la aplicación envía datos a sistema externos, poniendo principal atención en los datos sensitivos como datos de usuarios.
4.6 PASO 4: IDENTIFICACIÓN DE AMENAZAS
En este punto es donde se utilizan todos los documentos e información obtenidos en los pasos anteriores. Se deben identificar las amenazas y ataques que podrían afectar a la aplicación y comprometer los objetivos de seguridad. Las amenazas encontradas en este punto, no necesariamente indican la presencia de una vulnerabilidad, si bien la amenaza puede estar presente, podemos contar con los mecanismos necesarios para mitigarla al momento que se presenta.
Para dicho propósito se deben realizar las siguientes actividades:
Identificar amenazas y ataques comunes.
Metodología STRIDE para identificación de amenazas.
Identificar amenazas a través de casos de uso.
Identificar amenazas a través del flujo de datos
Instituto Politécnico Nacional ESIME Culhuacán
27 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE 4.6.1 Identificar amenazas y ataques comunes
Existe una lista de vulnerabilidades comunes que se han encontrado en la mayoría de las aplicaciones Web existentes y que han sido clasificadas y analizadas por expertos en la seguridad Web.
Se utilizará esta lista para identificar las amenazas a las que podría estar expuesta la aplicación.
Autentificación
¿Cómo podría un atacante tomar la identidad de otro usuario?
¿Cómo podría un atacante acceder a las credenciales8 de los usuarios almacenadas?
¿Cómo podría un atacante montar un ataque de diccionario? ¿Cuáles son las políticas de endurecimiento de contraseñas?
¿Cómo podría un atacante modificar, interceptar o evadir los mecanismo de reinicio de credenciales?
Autorización
¿Cómo podría un atacante elevarse los privilegios?
¿Cómo podría un atacante evadir los controles de verificación de autorización para lograr acceder a operaciones privilegiadas?
Validación de datos
¿Cómo podría un atacante inyectar comandos de SQL?
¿Cómo podría un atacante evadir la validación de datos de entrada?
¿Puede un atacante efectuar un ataque XSS(Cross-Site Scripting Attack)9?
¿Puede un atacante enviar datos inválidos para evadir la lógica de seguridad del servidor?
¿Cómo podría un atacante mandar datos malformados para colapsar la aplicación?
Administración de la configuración
¿Cómo podría un atacante obtener acceso a las funcionalidades del administrador?
¿Cómo podría un atacante acceder a los datos de configuración de la aplicación?
8 Nombre de usuario y contraseña.
9 Cross-Site Scripting Attack es un tipo de vulnerabilidad de seguridad típicamente encontrada en aplicaciones web que permiten la inserción de código por usuarios maliciosos.
Instituto Politécnico Nacional ESIME Culhuacán
28 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE
Datos sensibles
¿Dónde y cómo se almacenan los datos sensitivos de la aplicación?
¿En qué momento y cómo viajan los datos a través de la red?
¿Cómo podría un atacante ver los datos sensibles?
¿Cómo podría un atacante manipular los datos sensibles?
Administración de sesiones
¿Cómo podría un atacante capturar una sesión?
¿Cómo podría un atacante ver o manipular la sesión de otro usuario?
Cifrado
¿Se utiliza un algoritmo de cifrado personalizado? ¿Se confía en él?
¿Qué necesitaría un atacante para de romper el cifrado?
¿Cómo podría un atacante obtener acceso a las llaves de cifrado?
¿Qué estándares de cifrado se están utilizando? ¿Qué pasa si los atacantes los conocen?
¿Cómo afecta la tecnología de desarrollo al método de cifrado elegido?
Manipulación de parámetros
¿Cómo podría un atacante manipular los parámetros para afectar los mecanismos de seguridad del servidor?
¿Cómo podría un atacante modificar parámetros sensibles?
Manejo de excepciones
¿Cómo podría un atacante colapsar la aplicación?
¿Cómo podría un atacante obtener información valiosa de los detalles de las excepciones?
Auditoria y bitácoras
¿Cómo podría un atacante ocultar sus acciones?
¿Cómo podemos demostrar las acciones realizadas por un atacante o usuario?
Instituto Politécnico Nacional ESIME Culhuacán
29 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE 4.6.2 Metodología STRIDE
Una forma de garantizar que las aplicaciones desarrolladas cumplan con las propiedades de seguridad consiste en emplear el modelado de amenazas con STRIDE, el acrónimo de "Spoofing, Data Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege", es decir, suplantación de identidad, manipulación de datos, repudio (los usuarios pueden negar que realizaron una acción), revelación de información, denegación de servicio y elevación de privilegios.
Amenaza Propiedad de seguridad
Suplantación Autenticación
Manipulación Integridad
Repudio No repudio
Revelación de información Confidencialidad
Denegación de servicio Disponibilidad
Elevación de privilegios Autorización
Tabla 1 Amenazas y propiedades de la seguridad
4.6.3 Identificar amenazas a través de casos de uso
Se tiene que examinar cada uno de los casos de uso clave de la aplicación e identificar maneras en las que un usuario podría, intencionalmente o por error, forzar la aplicación a realizar una operación no válida. Para lograr lo anterior, se debe pensar como los atacantes y hacerse preguntas de cómo podría lograr que la aplicación fallara. Algunos ejemplos podrían ser los siguientes:
¿Cómo podría un cliente insertar datos maliciosos en este caso de uso?
¿Los datos que mandados por los usuarios están siendo validados o no?
¿Cómo puede un atacante manipular una sesión?
¿Cómo puede un atacante evadir los controles de autorización?
4.6.4 Identificar amenazas a través del flujo de datos
Utilizando los casos de uso y los escenarios se tiene que analizar el flujo de datos entre los componentes individuales de la arquitectura de la aplicación. Los flujos de datos a través de los límites de confianza son particularmente importantes ya que no se pueden controlar esos datos. Se debe asumir que todos los datos que provienen fuera de los límites de confianza son maliciosos.
Instituto Politécnico Nacional ESIME Culhuacán
30 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE
Se pueden hacer algunas preguntas:
¿Cómo fluyen los datos de inicio a fin en la aplicación?
¿Qué componentes llaman a otros componentes?
¿Qué hace que los datos sean válidos?
¿Dónde se realizan las validaciones?
¿Cómo se protegen los datos mientras se envían por la red?
4.7 PASO 5. IDENTIFICACIÓN DE VULNERABILIDADES
Utilizando la misma lista de amenazas del paso 4 a las que comúnmente se enfrentan las aplicaciones Web, se tratará de localizar sus vulnerabilidades mediante la realización de una serie de preguntas.
4.7.1 Autenticación
El objetivo de la autentificación es proveer acceso a las aplicaciones a los usuarios autorizados mediante el uso de controles que permitan corroboran que un usuario es quién dice ser y denegar el acceso a los atacantes que utilizan métodos para romper la autenticación. Algunas preguntas que se pueden hacer para identificar vulnerabilidades serían las siguientes:
Autenticación positiva. Cuando el bloque de autenticación falla, ¿El usuario logra autentificarse?
Inyección SQL. ¿Se están validando los datos que se reciben del usuario? Una manera de proteger las aplicaciones es limitar la longitud del campo que se recibe y verificar que cumpla con una serie de caracteres.
¿Se envían el nombre de usuario y contraseña en texto en claro sobre un canal desprotegido?
¿Se utiliza algún mecanismo de cifrado para datos sensibles?
¿Se almacenan las credenciales? ¿En dónde y cómo se protegen si se almacenan?
¿Utilizamos contraseñas endurecidas? ¿Cuáles son las políticas de contraseñas?
¿Las credenciales son verificadas?
¿Cómo se autentica el identificador de usuario después del acceso (login)?
Instituto Politécnico Nacional ESIME Culhuacán
31 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE
¿El navegador almacena los datos ingresados por el usuario? Se debe definir en la aplicación qué campos o formas no serán guardados por el navegador.
o Ejemplo <form … autocomplete=”off”>
¿Se utilizan cuentas predeterminadas?
¿Los nombres de usuario son predecibles?
¿Es posible la realización de ataques de fuerza bruta? Se deben limitar el número de intentos fallidos permitidos para evitar estos ataques.
¿Las cuentas de usuarios inactivos expiran?
Las mejores prácticas
Se deben mantener políticas que permitan recolectar evidencia de las actividades de los usuarios para el no repudio.
Utilizar el control de autenticación adecuado para el valor del activo protegido.
Re-autenticar a los usuarios cuando realicen transacciones de alto nivel.
Autenticar la transacción, no al usuario, principalmente para evitar el phishing10.
Utilizar contraseñas y políticas adecuadas al valor del sistema.
Técnicas de autenticación comunes
Autenticación por contraseña. Se presenta una ventana al usuario donde introduce su nombre de usuario y contraseña. El envío se realiza en texto claro por lo que su nivel de seguridad es bajo.
Autenticación basada en formas. Es muy utilizada en las aplicaciones web, ya que permite bastante personalización, aunque también existen muchos mecanismos para ser atacados. Se recomienda utilizar los controles estandarizados disponibles en lugar de utilizar controles personalizados. Un ejemplo, ASP.NET provee de controles de servidor que permiten llevar a cabo todas las tareas de manejo de usuarios.
Autenticación integrada. Comúnmente utilizada en servidores con Microsoft IIS y aplicaciones ASP.NET en ambientes de Intranet; utiliza un certificado de autenticación del lado de cliente.
10 Phishing es un término informático que denomina un tipo de delito encuadrado dentro del ámbito de las estafas, y que se comete mediante el uso de un tipo de ingeniería social caracterizado por intentar adquirir información confidencial de forma fraudulenta (como puede ser una contraseña o información detallada sobre tarjetas de crédito u otra información bancaria).
Instituto Politécnico Nacional ESIME Culhuacán
32 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE
Autenticación basada en certificados. La aplicación Web expide certificados, los certificados públicos son almacenados y comparados con las sesiones entrantes del navegador, si coinciden entonces el usuario es autenticado. La calidad del certificado depende de la calidad de la infraestructura de la llave pública.
Autenticación fuerte. La utilización de mecanismos de usuario y contraseñas (algo que se sabe) no provee un mecanismo fuerte de autenticación, pero con la combinación de la utilización de Tokens11 o llaves USB o certificados (algo que tenemos) se logra un control fuerte de autenticación.
4.7.2 Autorización
El objetivo es que los usuarios sólo puedan realizar las operaciones correspondientes a su nivel de privilegios y prevenir que usuarios malintencionados logren elevar su nivel de privilegios. Algunas preguntas que se pueden hacer para identificar vulnerabilidades serían las siguientes:
¿Se cumple con el principio del menor privilegio? Los usuarios sólo deben tener los privilegios necesarios para la realización de sus operaciones.
¿Se manejan listas de control de acceso? Las listan proveen un mecanismo adicional para controlar el acceso a los recursos.
¿Se utilizan controles de autorización personalizados? Preferentemente se deben utilizar los controles bien desarrollados como los que proveen los lenguajes de JAVA y ASP.Net
¿Las rutinas de autorización están centralizadas? Si se identifica los mecanismos de autorización se logrará acceder a todos los recursos.
¿Se controla el acceso a los recursos? No sólo se deben controlar las acciones, el acceso a recursos también debe ser controlado.
¿Qué controles de acceso se utilizan en los puntos de entrada de la aplicación?
¿La aplicación utiliza roles? ¿Están lo suficientemente separados las funciones para auditorias?
En caso de un error ¿El usuario logra obtener acceso?
¿El acceso a la base de datos es restringido?
11 Token es un dispositivo electrónico que se le da a un usuario autorizado de un servicio computarizado para facilitar el proceso de autenticación.
Instituto Politécnico Nacional ESIME Culhuacán
33 Esquema de seguridad para el desarrollo de aplicaciones Web para CFE 4.7.3 Validación de datos
El objetivo es garantizar que la aplicación este protegida contra ataques en la recepción de los datos enviados por los usuarios, los componentes externos o las bases de datos. Algunas preguntas que se pueden hacer para identificar vulnerabilidades serían las siguientes:
¿Se realizan revisiones de integridad de los datos en los límites de confianza? No se debe confiar en los datos que se envían por un medio no seguro.
¿Los datos recibidos son validados?
¿Se validan tipos, longitud, rango, formato?
¿Es confiable la validación del lado del cliente?
¿Se pueden realizar ataques por inyección de comandos?
¿Se validan los datos antes de ejecutar una consulta SQL para prevenir ataques por inyección SQL?
¿Podemos confiar en los datos recibidos de la base de datos?
¿Se envían datos por método GET? No se aconseja, sólo si es información para la navegación y debidamente cifrados.
¿Se limita los caracteres que se pueden enviar? Se debe poner especial atención en los caracteres especiales que pueden activar acciones en las aplicaciones.
4.7.4 Administración de la Configuración
El objetivo es garantizar que los datos sensibles de configuración estén protegidos. Algunas preguntas que se pueden hacer para identificar vulnerabilidades serían las siguientes:
¿Cómo se administran las interfaces de administración remotas?
¿Las cadenas de conexión están cifradas?
¿Los datos de configuración o sensibles se envían cifrados por la red?
¿Los privilegios del administrador están separados?
¿El acceso a los datos de configuración se realiza con los permisos adecuados? ¿Pueden los usuarios comunes escribir, leer o modificar estos datos?
