HTTP PARAMETER POLLUTION

La contaminación del parámetro HTTP (HPP) es el proceso de manipulacion de cómo un sitio web trata los parámetros que recibe durante las solicitudes HTTP. La vulnerabilidad ocurre cuando un atacante inyecta parámetros adicionales en una solicitud y el sitio web objetivo confía en ellos, lo que lleva a un comportamiento inesperado. Errores de HPP puede suceder en el lado del servidor o en el lado del cliente. Sobre el lado del cliente, que suele ser su navegador, puede ver el efecto de sus pruebas. En muchos casos, las vulnerabilidades de HPP dependen sobre cómo el código del lado del servidor usa valores pasados ​​como parámetros, que están controlados por un atacante. Por esta razón, encontrar estas vulnerabilidades pueden requerir más experimentación que
otros tipos de errores. En este post, comenzaremos explorando las diferencias entre HPP del lado del servidor y HPP del lado del cliente en general. Luego usaremos tres ejemplos relacionados con los canales de redes sociales populares para ilustrar cómo utilizar HPP para inyectar parámetros en sitios web de destino. Específicamente, aprenderemos las diferencias entre HPP del lado del servidor y del lado del cliente, y cómo probar este tipo de vulnerabilidad, y donde los desarrolladores a menudo cometen errores. Como verá, encontrar vulnerabilidades de HPP requiere experimentación y persistencia pero puede valer la pena el esfuerzo.

hpp del lado del servidor

En HPP del lado del servidor, envía a los servidores información en un intento de hacer que el código del lado del servidor regrese resultados inesperados. Cuando realiza una solicitud a un sitio web, los servidores del sitio procesan la solicitud y devuelven una respuesta, como discutido en el post anterior. En algunos casos, los servidores no solo
devuelven una página web sino que también ejecutan código basado en la información que reciben de la URL que se envía. Este codigo se ejecuta solo en los servidores, por lo que es esencialmente invisible para usted: puedes ver la información que envías y los resultados que obtienes atrás, pero el código intermedio no está disponible. Por lo tanto, tu solos puedes inferir lo que está sucediendo. Porque no puedes ver las funciones del código del servidor, HPP del lado del servidor depende de que usted identifiques los parámetros potencialmente vulnerables y experimentes con ellos. Veamos un ejemplo: podría ocurrir una HPP del lado del servidor si su banco inició transferencias a través de su sitio web aceptando parámetros de URL que fueron procesados ​​en sus servidores.
Imagine que pudiera transferir dinero ingresando valores en los tres parámetros de URL desde, hasta y cantidad. Cada parámetro especifica el número de cuenta para transferir dinero, el número de cuenta para transferir, y la cantidad a transferir, en ese orden. Una URL con estos parámetros que transfiere $ 5,000 del número de cuenta 12345 al número de cuenta 67890 pude parecer a esto:

https://www.bank.com/transfer?from=12345&to=67890&amount=5000

Es posible que el banco pueda suponer que solo recibirá uno del parámetro. Pero, ¿qué pasa si envías dos, como en la siguiente URL:

https://www.bank.com/transfer?from=12345&to=67890&amount=5000&from=ABCDEF

Esta URL se estructura inicialmente de la misma manera que la primera, pero agrega un parámetro extra que especifica otra cuenta de envío, ABCDEF. En esta situación, un atacante enviaría el parámetro adicional con la esperanza de que la aplicación validaría la transferencia utilizando el primero de pero retira el dinero con el segundo. Entonces,
un atacante podría ejecutar una transferencia desde una cuenta que no es propietario si el banco confia en el último parámetro recibido. En lugar de transferir $ 5,000 de la cuenta 12345 a 67890, el código del lado del servidor usaría el segundo parámetro y enviaria el dinero desde la cuenta ABCDEF al 67890. Cuando un servidor recibe varios parámetros con el mismo nombre, puede responder de diversas formas. Por ejemplo, PHP y Apache usa la última aparición, Apache Tomcat usa el primera aparición, ASP e IIS utilizan todas las apariciones, y así sucesivamente. Dos investigadores, Luca Carettoni y Stefano di Paolo,
proporcionaron una presentación detallada sobre las muchas diferencias entre tecnologías de servidor en la conferencia AppSec EU 09: esta información está ahora disponible en el sitio web de OWASP en https://www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf

Como resultado, no hay un solo proceso garantizado para el manejo de múltiples parámetros con el mismo nombre y encontrar vulnerabilidades HPP requiere algo de experimentación para confirmar cómo el sitio que estás probando maneja estas incidencias. El ejemplo del banco usa parámetros que son obvios. Pero a veces, las vulnerabilidades de HPP ocurren como resultado de comportamiento del lado del servidor del código que no es directamente visible. Por ejemplo, supongamos que su banco decide revisar la forma en que procesa transferencias y cambia su código de backend para no
incluir un parámetro from en la URL. Esta vez, el banco toma dos parámetros, uno para la cuenta a transferir y el otro por el monto a transferir. La cuenta desde la que transferir
será establecido por el servidor, que es invisible para usted. Por ejemplo, el enlace podría verse así:

https://www.bank.com/transfer?to=67890&amount=5000

Normalmente, el código del lado del servidor sería un misterio para nosotros, pero por el bien de este ejemplo, sabemos que el código Ruby del lado del servidor del banco (abiertamente terrible y redundante) se ve así:

user.account = 12345
def prepare_transfer(params)
params << user.account
transfer_money(params) #user.account (12345) becomes params[2]
end
def transfer_money(params)
to = params[0]
amount = params[1]
from = params[2]
transfer(to,amount,from)
end

Este código crea dos funciones, prepare_transfer y transfer_money.
La función prepare_transfer toma una matriz llamada params que contiene los parámetros to y amount de la URL. La matriz sería [67890,5000], donde los valores de la matriz se intercalan entre corchetes y cada valor está separado por una coma. La primera línea de la función agrega la información de la cuenta de usuario que se definió anteriormente en el código para el final de la matriz. Terminamos con la matriz [67890,5000,12345] en parámetros, y luego params se pasa a transfer_money. Observe que, a diferencia de los parámetros, las matrices no tienen nombres asociados con sus valores, por lo que el código depende en la matriz que siempre contiene cada valor en orden: la cuenta a la que transferir es la primera, la cantidad a transferir es la siguiente y la cuenta a transferir sigue los otros dos valores. En transfer_money, el orden de los valores se hace evidente cuando la función asigna cada valor de matriz a una variable.
Debido a que las ubicaciones de las matrices se numeran a partir de 0, params [0] accede
el valor en la primera ubicación en la matriz, que es 67890 en este caso, y lo asigna a la variable. Los otros valores también se asignan a variables. Luego, los nombres de las variables se pasan a la funcion transfer_money, que no se muestra en este fragmento de código, que toma los valores y transfiere el dinero.
Idealmente, los parámetros de URL siempre tendrían el formato de la forma que espera el código. Sin embargo, un atacante podría cambiar el resultado de esta lógica. pasando un valor from a params, como con la siguiente URL:

https://www.bank.com/transfer?to=67890&amount=5000&from=ABCDEF

En este caso, el parámetro from también se incluye en la matriz params pasado a la función prepare_transfer; por lo tanto, los valores de la matriz [67890,5000, ABCDEF] se agregan a la cuenta de usuario resultando [67890,5000, ABCDEF, 12345]. Como resultado, en la función transfer_money llamada en prepare_transfer, la variable from tomaría el tercer parámetro, esperando el valor de user.account 12345, pero en realidad haría referencia al valor del atacante pasado ABCDEF.

hpp del lado del cliente

Las vulnerabilidades de HPP del lado del cliente permiten a los atacantes inyectar parámetros adicionales en una URL para crear efectos en el extremo del usuario (el lado del cliente es una forma común de referirse a acciones que ocurren en su computadora, a menudo a través del navegador, y no en los servidores del sitio). Luca Carettoni y Stefano di Paola incluyeron un ejemplo de este comportamiento en su presentación utilizando la URL teórica http://host/page.php?par=123%26action=edit y el siguiente código del lado del servidor:

<? $val=htmlspecialchars($_GET['par'],ENT_QUOTES); ?>
<a href="/page.php?action=view&par='..'">View Me!>

Este código genera una nueva URL basada en el valor de par, un parámetro. En este ejemplo, el atacante pasa el valor 123%26acción=edit como el valor de par para generar un parámetro adicional no intencionado. El valor codificado en URL para & es %26, lo que significa que cuando se analiza la URL, el %26 se interpreta como &. Este valor agrega un parámetro adicional al generado href sin hacer explícito el parámetro de acción en la URL.
Si el parámetro hubiera utilizado 123&action=edit en lugar de %26, el & habría sido interpretado como una separación de dos parámetros diferentes, pero como el sitio solo está usando el parámetro par en su código, el parámetro de acción podria ser rechazado.

El valor %26 asegura la accion de separar los parametros. El parametro par es pasado a la funcion htmlspecialchars. Esta funcion convierte los caracteres especiales en sus valores de codigo HTML, donde cara caracter tiene un significado especial. El valor convertido es almacenado en la variable $val. . Por ello, el link generado se convierte en

<a href=»/page.php?action=view&par=123&action=edit»>

Consecuentemente, el atacante gestionara la accion a ejecutar en el parametro action. Los siguientes tres ejemplos muestran vulnerabilidades HPP de tipo cliente y servidor.

Botones de compartir en redes sociales de Hackerone

Una forma de encontrar vulnerabilidades de HPP es buscar enlaces que parezcan contactar con otros servicios. Las publicaciones de blog de HackerOne hacen precisamente eso al incluir enlaces a compartir contenido en sitios de redes sociales populares, como Twitter o Facebook. Cuando se hace clic, estos enlaces de HackerOne generan contenido para el usuario para publicar en las redes sociales. El contenido publicado incluye una referencia URL a la publicación del blog original. Un pirata informático descubrió una vulnerabilidad que le permitía abordar una URL de una publicación de blog de HackerOne. El parámetro de URL agregado se reflejaría en el enlace de la red social compartida de modo que el contenido de la red social generado se vincularía a otro lugar que no era la prevista URL del blog de HackerOne. El ejemplo utilizado en el informe de vulnerabilidad involucró visitar la URL https://hackerone.com/blog/introducing-signal y luego agregando &u=https://vk.com/durov hasta el final. En la página del blog, cuando HackerOne renderizó
un enlace para compartir en Facebook, el enlace se convertia en el siguiente:

https://www.facebook.com/sharer.php?u=https://hackerone.com/blog/introducing
-signal?&u=https://vk.com/durov

Si los visitantes de HackerOne hacían clic en este enlace actualizado maliciosamente mientras intentaban compartir contenido, el último parámetro u tendría prioridad sobre
el primer parámetro u. Posteriormente, la publicación de Facebook usaría el ultimo parametro u. Entonces los usuarios de Facebook que hacian clic en el enlace serían dirigidos a https://vk.com/durov en lugar de HackerOne. Además, al publicar en Twitter, HackerOne incluye un tweet predeterminado que promociona la publicación. Los atacantes también podrían manipular este texto incluyendo &text= en la URL, así:

https://hackerone.com/blog/introducing-signal?&u=https://vk.com/
durov&text=another_site:https://vk.com/durov

Cuando un usuario hace clic en este enlace, aparece un tweet emergente que contiene
el texto «otro_sitio: https://vk.com/durov» en lugar del texto que promociona el
Blog de HackerOne.

notificaciones unsubscribe en twitter

En algunos casos, encontrar con éxito una vulnerabilidad de HPP requiere persistencia. En agosto de 2015, el hacker Mert Tasci notó una URL interesante (que he abreviado aquí) al cancelar la suscripción para recibir notificacione en Twitter:

https://twitter.com/i/u?iid=F6542&uid=1134885524&nid=22+26&sig=647192e86e28fb6
691db2502c5ef6cf3xxx

Observe el parámetro UID. Este UID pasa a ser el ID de usuario de la cuenta de Twitter actualmente registrada. Después de ver el UID, Tasci hizo lo que todo hacker haria: intentó cambiar el UID por el de otro usuario, pero no pasó nada. Twitter acaba de devolver un error.

Decidida a continuar cuando otros podrían haberse rendido, Tasci intentó agregar un segundo parámetro UID para que la URL se vea así (nuevamente, una versión abreviada):

https://twitter.com/i/u?iid=F6542&uid=2321301342&uid=1134885524&nid=22+26&sig=
647192e86e28fb6691db2502c5ef6cf3xxx

¡Éxito! Logró dar de baja a otro usuario de las notificaciones de su correo electrónico. Twitter era vulnerable a la cancelación de la suscripción de usuarios por parte de HPP. La razón por la que esta vulnerabilidad es notable, como me explicó FileDescriptor, se relaciona con el parámetro SIG. Resulta que Twitter genera el valor SIG utilizando el valor de UID. Cuando un usuario hace clic en la URL para darse de baja, Twitter valida que la URL no haya sido manipulada verificando el SIG y el UID. Entonces, en la prueba inicial de Tasci, cambiar el UID para cancelar la suscripción de otro usuario falló porque la firma ya no coincidía con lo que Twitter esperaba. Sin embargo, al agregar un segundo UID, Tasci logró que Twitter valide la firma con el primer parámetro UID pero realice la acción de cancelación de suscripción utilizando el segundo parámetro UID.

intenciones web de twitter

En algunos casos, una vulnerabilidad de HPP puede ser indicativa de otros problemas y puede llevar a encontrar errores adicionales. Esto es lo que pasó en las funciónes de intenciones web. La función proporciona flujos emergentes para trabajar con Tweets, respuestas, retweets, me gusta y seguidores de los usuarios de Twitter en el contexto de
sitios que no son de Twitter. Las intenciones web de Twitter hacen posible que los usuarios interactúen con contenido de Twitter sin salir de la página o tener que autorizar una nueva aplicación solo para la interacción.

Al probar esta función, el hacker Eric Rafaloff descubrió que los cuatro tipos de intenciones (seguir a un usuario, dar me gusta a un tweet, retuitear y twittear) eran vulnerables a HPP. Twitter crearía cada intent a través de una solicitud GET con los parametros siguientes:

https://twitter.com/intent/intentType?parameter_name=parameterValue

Esta URL incluiría intentType y uno o más parametros , por ejemplo, un nombre de usuario de Twitter y un ID de tweet. Twitter usaria estos parámetros para crear la intención emergente para mostrar al usuario si seguir o tuitear o dar me gusta. Rafaloff descubrió un problema cuando creó una URL con dos parámetros de screen_name en lugar del singular esperado screen_name para una intención de seguimiento:

https://twitter.com/intent/follow?screen_name=twitter&screen_name=ericrtest3

Twitter manejaría la solicitud dando prioridad al segundo valor de screen_name, ericrtest3, en lugar del primer valor de Twitter al generar un botón de Seguir. En consecuencia, un usuario que intente seguir a un usuario en Twitter se podría engañar para que siguiera la cuenta de prueba de Rafaloff. Al visitar la URL que creó Rafaloff haria que el código de backend de Twitter generara el siguiente formulario HTML utilizando los dos parámetros de screen_name:

<form class="follow" id="follow_btn_form" action="/intent/follow?screen
_name=ericrtest3" method="post">
<input type="hidden" name="authenticity_token" value="…">
<input type="hidden" name="screen_name" value="twitter">
<input type="hidden" name="profile_id" value="783214">
<button class="button" type="submit">
<b></b><strong>Follow</strong>
</button>
</form>

Twitter usaría la información del primer parámetro screen_name, que está asociado con la cuenta oficial de Twitter. Como resultado, un objetivo vería el perfil correcto del usuario que pretendían seguir porque el primer parámetro de screen_name de la URL se utiliza para completar el código. Pero, después de hacer clic en el botón, el objetivo seguiría a ericrtest3, porque la acción en la etiqueta de formulario usaría en su lugar el valor del segundo parámetro screen_name pasado a la URL original.
De manera similar, al presentar intenciones para los likes, Rafaloff descubrió que podía incluir un parámetro screen_name a pesar de que no tiene relevancia para que le guste el
twit. Por ejemplo, podría crear esta URL:

https://twitter.com/intent/like?tweet_i.d=6616252302978211845&screen
_name=ericrtest3

Una intención similar normal solo necesitaría el parámetro tweet_id; sin embargo, Rafaloff inyectó el parámetro screen_name al final de la URL. Dando like a este tweet daría como resultado que un objetivo se presentara con el propietario correcto para que le guste el tweet. Pero el botón Seguir junto al tweet correcto y el perfil correcto del tweeter sería para el usuario no relacionado ericrtest3.

resumen

El riesgo que plantea HPP depende de las acciones que realice el backend de un sitio.
y dónde se utilizan los parámetros contaminados. Descubrir las vulnerabilidades de HPP requiere pruebas exhaustivas, más aún que para algunas otras vulnerabilidades, porque normalmente no podemos acceder a los servidores de código de los que se ejecutan después de recibir nuestra solicitud HTTP. Esto significa que podemos solo inferir cómo los sitios manejan los parámetros que les pasamos. Mediante prueba y error, puede descubrir situaciones en las que HPP ocurren. Por lo general, los enlaces a las redes sociales son un buen primer lugar para probar para este tipo de vulnerabilidad, pero recuerda seguir investigando y pensar en HPP cuando está probando sustituciones de parámetros, como valores similares a ID.

CROSS-SITE REQUEST FORGERY

Un ataque de falsificación de solicitud entre sitios (CSRF) ocurre cuando un atacante puede hacer que el navegador de un objetivo envíe una solicitud HTTP a otro sitio web. Ese sitio web luego realiza una acción como si la solicitud fuera válida y enviada por el objetivo. Tal ataque generalmente se basa en que el […]

Leer más CROSS-SITE REQUEST FORGERY

SISTEMAS OPERATIVOS CON MINIX (2)

el sistema operativo como una extension del computador Como se mencionó anteriormente, la arquitectura (conjunto de instrucciones, organización de la memoria, E/S y estructura de bus) de la mayoría de las computadoras a nivel de lenguaje máquina es primitiva y difícil de programar, especialmente para la entrada/salida. Para ver este punto más concretamente, veamos brevemente […]

Leer más SISTEMAS OPERATIVOS CON MINIX (2)

OPEN REDIRECT

Comenzaremos el post con las vulnerabilidades de redireccionamiento abierto (open redirect), que ocurren cuando un objetivo visita un sitio web y ese sitio web envía su navegador a una URL diferente, potencialmente en un dominio separado. Las redirecciones abiertas aprovechan la confianza de un determinado dominio para atraer victimas a un sitio web malicioso. Un […]

Leer más OPEN REDIRECT


Deja una respuesta

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Salir /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Salir /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s