El servidor LifeRay "descuidado" de Apple

Este jueves en el evento de Eleven Paths entregué los premios del Latch Plugin Contest a los ganadores del concurso. Como tenéis publicado en la web de los ganadores, el tercer premio fue para una implementación de Latch para LifeRay, que se llevó su premio de 1.000 USD. En el evento, los ganadores subieron al escenario a contarnos sus plugins, y mientras yo escuchaba la parte del plugin de Latch para LifeRay, mi cabeza estaba haciendo memoria... ¿dónde había visto yo un servidor LifeRay no hacía mucho?

Entonces me acordé, lo había visto en un dominio de Apple.com. No esperes leyendo este post grandes bugs, sino pequeños detalles de seguridad sutiles que pueden dejar un servidor de una gran empresa menos fortificado que el resto por descuidar pequeños detalles. Solo os voy a contar mis reflexiones al respecto.

Figura 1: El servidor LifeRay descuidado de Apple

Había llegado a ese servidor tiempo atrás gracias al módulo de descubrimiento de Faast, pero para cualquiera que busque un rato no es muy difícil dar con él en Internet. Está en un dominio que cuenta con un certificado digital renovado no hace mucho, lo que parece indicar que tiene cierto mantenimiento. Lo que llama poderosamente la atención es que, cuando llegas a él, lo único que se ve es una página por defecto de una instalación recién hecha de LifeRay.

Figura 2: Aspecto del portal de LifeRay en el dominio de Apple.com

Por supuesto, es imposible no ver la versión de LifeRay que aparece en el pie de la plantilla, donde se ve que es la versión LifeRay Portal Community Edition 6.1.2 de Agosto de 2013. Casi dos años de antigüedad en un software hace más que probable que existieran algunos bugs sin parchear. Lo cierto es que existen algunos, como este CVE-2014-2963 que permite inyectar XSS en algunas partes del sistema, aunque también podrían haber aplicado el fix manualmente sin hacer un upgrade de versión.

Figura 3: Bug CVE-2014-2963

Para que se pudiera probar si es vulnerable o no a ese bug, se necesitaría tener acceso a tus propiedades de cuenta, así que habría que intentar acceder al sistema. Cuando intentas hacer login te lleva a la web de registro de cuentas Apple, pero la web cuenta con parte de registro de cuentas para el portal de LifeRay para esta instalación en concreto y sacarse una cuenta. Esto de darse de alta, muchas veces da juego en servidores WordPress que permiten esa opción y puedes sacar cosas interesantes, así que se puede probar.

Figura 4: Creación de cuentas en el servidor LifeRay

Además, como parece que está integrado con Apple.com, te puedes sacar una cuenta de AppleID y luego pedir el acceso a este portal. La autenticación se produce correctamente, pero en la fase de autorización no es posible conseguir ver los recursos, porque está protegido para algunas cuentas de algunos grupos de Active Directory. No es raro, ya hemos visto que Apple tiene mucha tecnología Microsoft internamente, desde servidores web con bugs IIS Short Name y aplicaciones en tecnologías Microsoft como hemos visto en el pasado. Recordad la famosa foto de Tim Cook en la fábrica de MacBook que usa Windows.

Figura 5: Una vez autenticado, falla la autorización para acceder a recursos

Sí que, una vez registrado, puedes jugar con las opciones de Olvidé la Contraseña para sacar información de la infraestructura de Apple que hay detrás. La idea es tan fácil como forzar que te envíe un correo electrónico con un token para cambiar la contraseña de la cuenta recién creada, tal y como se explica en este artículo de "Enviar a un amigo". Mirando el código fuente se puede ver cómo el correo se genera en localhost (el servidor web de LifeRay) y va pasando por la red de Apple.

Figura 6: Correo envidado por el servidor LifeRay con info de la red

A primera vista no he conseguido mucho más donde rascar. Corre sobre un servidor Apache 2.4.7 sin actualizar a la última versión, y tiene un servidor JSP que probablemente sea un JBossWeb, tal y como muestra este mensaje de error indexado en Archive.org. Si pruebas un foca.jsp para forzar el error JSP, da también una respuesta anómala.

Figura 7: Un error de JBossWeb cacheado en Archive.org

Como me tenía intrigado, fui a buscar más información en la red sobre ese servicio, y topé con un currículo en Linkedin que explicaba más detalles de la infraestructura que hay detrás, algo que parece corroborar lo que ya se habíamos visto de servidores LifeRay, Oracle y JBoss. Eso sí, aparecen más detalles útiles.

Figura 8: Información del proyecto en un CV de Linkedin

Lo cierto es que lo que más me sorprende sigue siendo el que esté un servidor desactualizado, configurado por defecto, en un dominio público de Apple.com sin más. No es como yo creo que deben dejarse las cosas si te preocupa la seguridad. Tal vez sea un honeypot - que parece que no por la info del perfil de Linkedin - o tal vez un descuido, a tu elección queda. Al final, la seguridad de una empresa se rompe por el punto más débil, y este no parece de los más robustos.

Saludos Malignos!

Cómo aprender de los mensajes de error en un pentesting

Este jueves pasé un rato entretenido con los compañeros jugando con unos nodos de un sitio web en Apple. Digamos que por casualidad topamos con un bug de IIS Short Name en uno de sus servidores - sí, Apple también utiliza Windows -, pero cuando íbamos a probar en detalle la vulnerabilidad los resultados eran inconsistentes... ¿cómo era esto posible?

Figura 1: Cómo aprender de los mensajes de error en un pentesting

Pues fácil, ese sitio web estaba siendo soportado por un cluster de servidores Microsoft Windows con Internet Information Services y el fallo no se encontraba en todos, lo que nos llevó a estrujarnos un poco más el cerebro y a que todo fuera aún más interesante.

Los mensajes de error en los servidores web

Muchas veces hemos hablado de la importancia de los mensajes de error en los servidores web. Hay que jugar mucho con querystring para sacar el máximo posible de información de un servidor web y los frameworks que tenga instalado. Cada código de respuesta HTTP puede estar configurado de forma distinta en cada framework, lo que hace que de cada uno de ellos se saquen datos.

Figura 2: Múltiples Frameworks que pueden procesar la petición

Un Error 404 dado por el servidor web no tiene por qué dar la misma información que un Error 404 del framework .NET, o del framework JSP, por lo que hay que conseguir hacer pruebas para obtener códigos de error HTTP en todos los motores del servidor web.

Múltiples nodos de un servicio

Para rizar un poco más el rizo, un sitio web puede estar soportado por un cluster de equipos publicado detrás de un balanceador - que además podría utilizar una CDN - por lo que hay que tener cuidado. Cuando un servicio utiliza más de un equipo para ofrecer su servicio, la labor del administrador debe ser configurar los dos de la misma forma, sin embargo esto no es siempre así. En el mundo de los servidores DNS esto es algo común y por eso en FOCA añadimos la opción de comprobar todo en todos los servidores DNS, pero también puede pasar en el mundo de los frontales web.

Figura 3: Un ejemplo de servidores DNS con diferentes configuraciones en Menéame en 2010

Localizar que un sitio web está detrás de un balanceador o que es parte de un cluster a veces se puede localizar directamente en las cookies. Sistemas como BigIP permiten localizar entornos con más de un sistema dando servicio a un servidor web.

Figura 4: Cookies de BigIP que dan información de los nodos

Otras veces simplemente hay que fijarse en todos los detalles para localizar la fuga de información necesario que nos haga descubrir la existencia de más de un nodo detrás de un servicio, como vamos a ver más adelante.

Dos nodos sirviendo distintos headers

En este caso, la característica que nos llevó a detectar múltiples nodos en un sitio web fue un header. Al revisar uno de los servidores web de Apple que tiene con tecnología Microsoft IIS, vimos que cuando pedíamos un documento ASPX que no existía, obteníamos una página de Error 404 aparentemente similar pero que no lo era. Esta es la respuesta del Nodo 1.

Figura 5: Mensaje de Error 404 del Framewok .NET en el Nodo 1

Si nos fiamos en los Response Headers de la siguiente imagen, podemos ver que el Nodo 2 tiene configurada la respuesta con el campo Server, donde se indica que es un Microsoft-IIS/6.0.

Figura 6: Mensaje de Error 404 del framework .NET en el Nodo 2

Por supuesto, de esto nos hubiéramos dado cuenta si nuestro sistema de pentesting persistente Faast no nos hubiera marcado que en este servidor se podía hacer un listado de directorios con el truco del IIS ShortName, así que, sabiendo que había dos nodos había que probar si este fallo estaba en uno o en los dos nodos.

Dos configuraciones distintas en los nodos

Probar un valor True con el bug del IIS Shortname exige poner el comienzo de un nombre de archivo que exista y un False el de uno que no exista. Esto nos permite hacer un proceso de booleanización para sacar los valores del nombre del archivo carácter a carácter. Con los servidores IIS 6.0 el resultado que se debe obtener, siguiendo la siguiente tabla de valor, es un Error 404 cuando existe un archivo que comienza por esa cadena y un Error 400 cuando no hay ningún archivo que comience por esa cadena.

Figura 7: Tabla de explotación del bug de IIS Shortname

Si miramos los resultados que se obtienen en el Nodo 1, se puede ver que cuando hay un archivo que comienza por esa cadena, en este caso la letra "a", se obtiene un Error 404 con un mensaje,

Figura 8: Archivo comenzando por letra "a" (sabemos que existe) da un Error 404 en Nodo 1

Por el contrario, cuando se solicita un archivo que comienza por la letra "X" y esta petición llega al Nodo 2, el resultado que se obtiene es un Error 404 con el mismo mensaje, lo que deja claro que NO se puede hacer un listado de directorios en formato 8:3 en este nodo del sitio web usando estas técnicas.

Figura 9: Archivo comenzando por letra "X" (sabemos que NO existe) da un Error 404 en Nodo 1

Por el contrario, si miramos los resultados que se obtienen con el Nodo 2 notamos diferencias. Cuando el archivo existe vemos un Error 404 con un mensaje de una única línea, tal y como indica la tabla de comprobación.

Figura 10: El archivo existe, así que se obtiene un Error 404 en Nodo 2

Pero cuando ponemos la cadena de un archivo que no existe, obtenemos otro Error 400 de Bad Request debido a que el archivo NO existe. Tal y como dice la tabla que se explotan estos fallos en la versión de IIS 6.0.

Figura 11: El archivo NO existe. Se obtiene un Error 400 en Nodo 2

Esto quiere decir que el Nodo 2  adolece de esta debilidad, mientras que el Nodo 1 está configurado de una forma que no permite esta manera de explotarlo.

Dos nodos con dos configuraciones distintas también en ASP

Esta configuración distinta de los tratamientos de errores se pude encontrar en muchos otros sitios, por ejemplo, en el código de Error 404 de ASP se puede ver que en el Nodo 1 sale un mensaje no controlado. 

Figura 12: Error 404 de framework ASP en el Nodo 1

Ese mensaje de arriba deja a las claras que es un IIS 6, ya que si no probablemente nos hubiéramos encontrado un mensaje de Error ASP de un servidor IIS migrado, mucho más verbose que éste. 

Figura 13: Error 404 ASP controlado en el Nodo 2

En el caso del Nodo 2, el mensaje de Error 404 de ASP está controlado y sale una página de Apple totalmente maquetada para evitar cualquier fuga de información. 

Más errores: ASP.NET, ColdFusion y JSP

Ya para terminar, volviendo al principio, no tiene porque pasar lo mismo en todos los frameworks, y si probamos con un archivo que no existe en el framework de ColdFusion, lo que obtendremos en todos los nodos es el mismo mensaje de error. Un Error 400 en este caso.

Figura 14: Error 400 con un not found en ColdFusion

Aún así, como veis, jugando con los mensajes de error de los distintos frameworks se puede sacar mucha información. Ya para terminar, me faltaba comprobar el Framework JSP, ya que si hay ColdFusion hay soporte para JSP y dependiendo de la licencia se puede obtener un Error 500 o un Error 404.

Figura 15: Errores por el framework JSP

Ya por último, igual que en el caso de Microsoft.com podemos intentar poner algún carácter o cadena de caracteres no válida para generar algún otro error del framework .NET (que sabemos que está). Simplemente, con dejar la tilde sin poner un número, se obtiene el Runtime Error de .NET.

Figura 16: Runtime Error en el framework .NET. Error 500

Al final, como se puede ver, jugando con los errores de una web, en todos sus frameworks y en todos los nodos de un sitio se puede llegar a obtener una gran cantidad de información. Hay que revisar todo que puede que, como en este caso, el administrador se deje muchos mensajes de error sin maquetar y controlar.

Saludos Malignos!

Un problema de licencia: Error 500 en Coldfusion

Después de hacer las pruebas con los mensajes de error 404 de JSP para incorporarlos a FOCA 3, se me ocurrió que un buen entorno para buscar servidores JSP serían los sitios con Coldfusion. Este servidor, primero de la empresa Allaire, luego de Macromedia y por último de Adobe, hace tiempo que está desarrollado en Java, y tiene soporte para aplicaciones JSP.


Figura 1: Sitios corriendo CFM en Google
Con esta premisa, realicé una prueba similar a la que forzar errores 404 en servidores con soporte a JSP, es decir, busqué sitios que tuvieron aplicativos desarrollados en CFM y solicité el mismo fichero pero cambiándole la extensión a JSP y el resultado me llevó a aprender una cosa curiosa que desconocía.


Figura 2: Error de licencia en un Coldfusion Standar corriendo sobre Apache


Figura 3: Error de licencia pero con poca información


Figura 4: Error de licencia de un Coldfusion Standar corriendo sobre IIS
Por lo visto, Coldfusion tiene varias licencias de venta, y no todas permiten hacer uso del motor JSP. En concreto, si el sitio sólo ha comprado una licencia Standard para desarrollo CFM puro, al invocar un programa con extensión JSP se generará una excepción 500 con un error de licencia muy curioso. Si no hay problema con la licencia, pues se obtendrá un error 404 de JSP como ya vimos.

Los mensajes de error que se obtienen son distintos, dependiendo de la versión exacta que corre de Coldfusion y el servidor web sobre el que se ejecuta. ¿Podría usar Adobe esta información para detectar software pirata de Coldfusion? Este error lo genera Coldfusion del que ya vimos que era bastante "verbose" en los fallos de SQL Injection, y en contadas excepciones he podido constatar que esté controlado, por lo que se puede sacar información del servidor allí implantado. Una curiosidad que integraremos en FOCA para extraer más info del sitio.

Saludos Malignos!

Descubrir servidores TomCat con errores JSP

Estos días, además de la compra de Motorola Mobility por parte de Google, se sigue hablando de lo de siempre, fallos de seguridad. Uno de los que estos días ha dado que hablar ha sido un bug que ya estaba resuelto, pero que ha vuelto a ser introducido en el proyecto TomCat, y que permite escribir ficheros protegidos desde el entorno de usuario. Aún cuando en la versión vulnerable exista el fallo, se tienen que dar una serie de condicionantes que en Una al día recogieron.

El caso es que, sorprendentemente, encontrar sitios con TomCat es mucho más sencillo de lo que parece, y lo es simplemente por un fallo a la hora de configurar de forma segura los mensajes de error que ofrece un servidor web. La idea es que, uno de los trucos más viejos a la hora de averiguar software que está corriendo un servidor consiste en generar un mensaje de error 404.


Figura 1: Error 404 en dominio .mil
Con este mensaje, en muchas ocasiones, se obtiene información más que suficiente como para saber la versión exacta de un servidor web e incluso algún módulo que está cargado en él. Por ello, muchos administradores, a la hora de poner en producción un servidor web el mensaje de error 404 lo controlan, mostrando un mensaje genérico.

Sin embargo, cuando se solicita un fichero que no existe, pero que está vinculado a un manejador de extensiones, es decir, un .aspx, un .jsp, o un .cfm, por poner algunos ejemplos, son estos frameworks los encargados de gestionar los mensajes de error. Y estos son los que el administrador se suele olvidar de cambiar.

Así, si por ejemplo hacemos una búsqueda por .jsp en los dominios .mil, encontramos una cantidad aproximada de 139.000 urls. Basta con abrir esas URLS y borrar una letrita del nombre del fichero, para ver qué mensaje de error se obtiene cuando se invoca un fichero JSP no existente.


Figura 2: Sitios con JSP en dominios .mil
Como se puede ver, sorprendentemente, la mayoría de los sitios contesta con la versión exacta de TomCat (o JBOSS). Yo elegí este dominio porque pensé que sería uno de los más fortificados, pero como se puede ver no es así.






Evidentemente, si pedimos el mismo fichero, pero con una extensión distinta, salvo que todas las extensiones estén asociadas al mismo framework, obtendremos mensajes 404 comunes, como en la figura 1. Una vez que se sabe que hay JSP, y qué servidor de aplicaciones se está utilizando en concreto, las labores de búsqueda del panel de administración son mucho más sencillas. Tal vez baste con pedir la misma URL por el puerto 8080, tal vez o sea necesario hacer un escaneo de todo el rango de red por el puerto 8080, pero lo que es evidente es que saber la tecnología del servidor te ayuda a tomar el mejor camino.

En los ejemplos he puesto casos con TomCat, pero esto también pasa con el resto de servidores de aplicaciones, como Oracle Application Server, JBOSS (y sus magníficas consolas con passwords por defecto), etc...

Saludos Malignos!

HPP: Http Parameter Pollution

Recientemente hemos visto una vulnerabilidad de HTTP Parameter Pollution afectando al sistema de Blogs de Blogger que permitía convertirse en administrador de cualquier blog. Las tecnicas HPP son mucho más peligrosas de lo que la gente está evaluando, y debido a la poca cantidad de herramientas que las buscan, hoy en día hay muchas aplicaciones web vulnerables ahí fuera.

Carmén Torrano, una investigadora de seguridad española, está trabajando en PAPAS, una aplicación que evalúa online la existencia de vulnerabilidades HPP en aplicaciones web. Ella se comprometió conmigo a hacer un artículo sobre HPP y PAPAS y aquí lo tienes. Gracias Carmen.

Saludos Malignos!

Conceptos previos: Precedencia

En gran parte de las páginas web actuales, cuando un usuario visita una página web, necesita proporcionar datos de entrada a dicha aplicación. Los parámetros de las aplicaciones web permiten traspasar datos de entrada de los usuarios a la aplicación. En algunas ocasiones, el navegador envía una petición en la que un parámetro con el mismo nombre aparece repetido varias veces. Por ejemplo, el caso de una aplicación en la que aparezca un checkbox en el que es posible seleccionar múltiples opciones. Para estos casos, muchos lenguajes de programación proporcionan métodos que devuelven una lista con todos los valores asociados a un parámetro.

Supongamos que un desarrollador espera recibir un solo valor para un parámetro y por tanto, utiliza un método que devuelve un único valor. En el caso de que la petición contenga múltiples valores para el parámetro en cuestión, se pueden dar tres posibilidades:

1. Que el método devuelva el primer valor del parámetro
2. Que devuelva el último
3. O que devuelva una combinación de todos los valores.

No hay un estándar para ello y como se puede ver en la tabla, el resultado depende del lenguaje de programación y del servidor web empleado.



El hecho de que el método devuelva un solo valor no es una vulnerabilidad por sí sola, sin embargo, la presencia de múltiples valores para un parámetro abren la posibilidad de que el método no obtenga el valor esperado para el parámetro.

Si el desarrollador no es consciente del problema, se podrían producir comportamientos anómalos, que podrían ser aprovechados por un atacante. Como se verá más adelante, esto se puede utilizar junto con las vulnerabilidades HPP para sobrescribir el valor de un parámetro.

¿Qué es HTTP Parameter Pollution(HPP)?

Un ataque de polución de parámetros HTTP consiste en la inyección de delimitadores de query string codificados en otros parámetros existentes. Si el parámetro en el que se ha realizado la inyección no se valida correctamente y se utiliza decodificado para generar una URL, el atacante puede insertar uno o más parámetros en dicha URL.

Los ataques de polución de parámetros HTTP son relativamente recientes, fueron presentados por Stefano di Paola y Luca Carettoni en OWASP 2009 y no se han estudiado con demasiada profundidad hasta el momento.

Las consecuencias de este ataque dependen de la lógica de la aplicación y pueden tener desde un leve impacto hasta una gran importancia.
Algunas de estas consecuencias son:

- Sobreescritura de parámetros con codificación fuerte para modificar el comportamiento de la aplicación.

- Salto de los puntos de validación de los datos de entrada.

- Acceso y posible explotación de variables fuera del alcance directo.

Para que la vulnerabilidad sea explotable es necesario que la precedencia sea tal que el método no devuelva el parámetro esperado ante la presencia de parámetros duplicados. Las vulnerabilidades HPP pueden explotarse para realizar tanto ataques del lado del servidor como ataques del lado del cliente.

Respecto a los ataques del lado del servidor, es posible burlar la defensa de los Cortafuegos de Aplicación Web (WAFs) y también pueden influir en la reescritura de la URL.

En el lado del cliente, es posible inyectar parámetros en los enlaces y en los formularios. Típicamente, en este tipo de ataques, el atacante trata de persuadir a la víctima para que visite una URL que explota la vulnerabilidad HPP.

Un ejemplo de HPP en una aplicación

Por ejemplo, consideremos una aplicación web de votaciones que permite a los usuarios participar en diferentes elecciones y votar a su candidato favorito. La aplicación está escrita en JSP. En caso de múltiples instancias de un parámetro, el método Request.getParameter("par") de JSP devuelve el primer valor del parámetro.

La aplicación recibe un parámetro (“eleccion_id”) que es el identificador de la elección concreta en la que está participando el usuario. En función de los valores del parámetro, la aplicación genera una página que contiene un enlace para cada uno de los candidatos de la elección correspondiente.

Por ejemplo, en este fragmento se muestra una página de una elección con dos candidatos en la que el usuario puede votar a su candidato pinchando en el enlace deseado:

Url : http :// servidor / eleccion . jsp ? eleccion_id =4568
Enlace1 : <a href =" votar . jsp? eleccion_id =4568& candidato = white ">
Voto para Mr. White </a>
Enlace2 : <a href =" votar . jsp? eleccion_id =4568& candidato = green ">
Voto para Mrs. Green </a>

Supongamos que Pedro, que es un seguidor de Mrs. Green, quiere modificar el resultado de las elecciones. Analizando la página se da cuenta de que la aplicación no valida correctamente el parámetro “eleccion_id”. Por tanto, utiliza la vulnerabilidad HPP para inyectar el parámetro “candidato” en el parámetro “eleccion_id”, de la siguiente forma:

http://servidor/eleccion.jsp?eleccion_id=4568%26candidato%4Dgreen

Pedro envía esta URL a Alicia. Cuando Alicia pincha en el enlace, es dirigida al sitio original de las elecciones donde puede votar a su candidato para esa elección. Sin embargo, como la aplicación utiliza el parámetro “eleccion_id” para formar los enlaces, cuando Alicia visita la página, el valor inyectado para el candidato se incluye en las URLs:

http :// servidor / eleccion . jsp? eleccion_id =4568%26candidato%3Dgreen
Enlace 1: <a href = votar . jsp ? eleccion_id =4568&candidato=green&candidato =white >
Voto para Mr. White </a>
Enlace 2: <a href = votar . jsp ? eleccion_id =4568&candidato=green& candidato =green >
Voto para Mrs. Green </a>

No importa en qué enlace pinche Alicia, el script “votar.jsp” recibirá dos instancias del parámetro “candidato”. El primer valor del parámetro siempre es “green”. Si el desarrollador de la aplicación utiliza la funcionalidad básica de Java para obtener un solo valor para el parámetro “candidato”, sólo se obtendrá el primer valor del parámetro (es decir, “green”) y el segundo valor (que tiene el voto de Alicia) es descartado.

Como se ha visto en el ejemplo, al ser esta aplicación vulnerable a HPP es posible para un atacante modificar un enlace, que cuando se visita, falsifica el contenido de la página y genera enlaces que fuerzan el voto para Mrs. Green.

Se trata de ataque bastante reciente pero que como se ha mostrado, el ataque HPP puede tener graves consecuencias, por lo que es importante que los desarrolladores sean conozcan este ataque y tomen las contramedidas oportunas.

Nuestra herramienta: ¡Pruébala online!

Hasta donde sabemos, no se han presentado herramientas automáticas hasta la fecha que detecten este tipo de vulnerabilidades en las aplicaciones web. Además, no se ha estudiado cuantitativamente en qué medida afecta la vulnerabilidad HPP en las páginas web.

Por tanto, en la conferencia NDSS (Network and Distributed System Security Symposium) presentamos PAPAS (PArameter Pollution Analysis System), una herramienta que permite detectar automáticamente las vulnerabilidades HPP en aplicaciones web.

Realizamos experimentos en más de los 5000 sitios web más importantes y populares (según Alexa). Los resultados del análisis muestran que casi el 30% de los sitios web contienen al menos una página vulnerable a HPP. Esto significa que la herramienta fue capaz de inyectar automáticamente un parámetro codificado dentro de unos de los parámetros existentes y de verificar que fue incluido decodificado en uno de las URLs (enlaces o formularios) de la página resultante.

Es más, casi el 47% de las vulnerabilidades encontradas (14% del total de sitios web) se pueden explotar por medio de ataques HPP. Nuestros experimentos nos revelaron que la vulnerabilidad HPP afecta a sitios tan conocidos como Microsoft, Google, etcétera.

¿Quieres saber si tu aplicación web es vulnerable a HPP? La herramienta se puede probar online gratuitamente en: http://papas.iseclab.org. ¡Espero que os guste!

Saludos,
Carmen Torrano