Hoy decidimos discutir el tema de la seguridad de la información. Publicamos la traducción del artículo de Kunal pandey, detectamos vulnerabilidades y nos adelantamos a la curva.
Introducción
El robo de datos personales (PII) del usuario se ha convertido en un lugar común para nosotros. Los atacantes encuentran muchas formas de obtener datos personales, por ejemplo, mediante el uso de vulnerabilidades XSS e IDOR, divulgación de puntos finales API y más.
El escenario descrito en este artículo se puede probar simplemente observando el comportamiento del punto final de la API. En el siguiente ejemplo, al llamar a la API, la información personal de cualquier usuario se puede almacenar en otros puntos finales de la API.
Explicación
En uno de los programas privados de la plataforma HackerOne Bug Bounty , donde me invitaron, se propuso probar el portal de la tienda, es decir, la sección para el trabajo del vendedor. Aquí, los empleados de la tienda pueden enviar a cualquier cliente una invitación "Realizar pedido". Para obtener la información que necesitan, el vendedor envía esta solicitud a los clientes por correo electrónico o mediante un código QR.
Después de recibir un enlace con una invitación para realizar un pago, el comprador va a: payment-na.examle.com/0811ebf4-d7d0-ba31-9ce68648a5a9 y completa los datos requeridos.
Al interceptar una solicitud, Burp Suite detecta un punto final de API POST que contiene los datos ingresados.
Solicitud
POST /na/customer/client/v1/session/002420e4-e031-47aa-8d94-6f7c40c248c7 HTTP/1.1
Host: payments-na.example.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/json;charset=utf-8
X-Cdc-Client: 2.15.45
Content-Length: 125
Origin: https://payments-na.example.com
DNT: 1
Connection: close
Referer: https://payments-na.example.com
{"browser_prefilled":[],"customer_details":{"country":"US"..............},"skipped_fields":[],"user_submitted":true,"action":"continueAddressUnverified"}
Responder
Después de completar el formulario, se completa la operación. ¡Hecho!
Durante el método POST a payments-na.example.com/na/customer/client/v1/session/002420e4-e031-47aa-8d94-6f7c40c248c7 , se guarda toda la información, se ha realizado el pago.
Etapa de operación
Los usuarios o atacantes pueden encontrar otra sección del portal donde pueden utilizar la función "Realizar pedido", al igual que en el método descrito anteriormente, y recibir el siguiente enlace para el pago: payment-na.examle.com/fa5daba4-5d50-8f80 –9eb1-ebia3ea6d665 .
En este caso, simplemente complete el formulario, intercepte la solicitud en Burp Suite, reciba una solicitud POST en payment-na.example.com/na/customer/client/v1/session/xxxx , descargue el punto final API generado y descarte otras solicitudes nosotros no los enviamos.
Extremo de API recibido: payment-na.example.com/na/customer/client/v1/session/96afd42f-4281-4529-9b8c-3ba70b0f000b .
Para realizar más pruebas, este punto final también se puede utilizar mediante el método GET en el navegador. A continuación se muestra una captura de pantalla del punto final de la API resultante:
Como podemos ver, aún no se ha agregado información y no se han especificado parámetros.
Ahora recuperaremos este enlace de API y lo enviaremos a otros usuarios que hayan completado los detalles de su pedido. Tan pronto como la víctima haga clic en este enlace de API, todos los datos personales del envío anterior que se almacenaron aquí ( / na / customer / client / v1 / session / 002420e4-e031-47aa-8d94-6f7c40c248c7 ) se copiarán al punto final especificado API: / na / customer / client / v1 / session / 96afd42f-4281–4529–9b8c-3ba70b0f000b .
Después de que la víctima haga clic en el enlace de la API que le enviamos, todos los datos personales del usuario se copiarán en este punto final.
Desde el lado de la víctima: es
suficiente que un atacante simplemente visite este punto final de API en modo incógnito, y habrá datos de la víctima copiados (correo electrónico, dirección, etc.).
Datos personales de la víctima: de
esta manera, los atacantes podrían obtener los datos personales de cualquier cliente simplemente creando un nuevo punto final de API de sesión y enviándolo a otros usuarios.
Trabajar en errores
El equipo de desarrollo del portal eliminó el método GET, lo vinculó al método POST y agregó el encabezado del token de autorización a la solicitud del método POST anterior, donde cada vez se autenticará desde el servidor.
Esto eliminó la posibilidad de repetir el escenario descrito anteriormente: un ataque con la copia de datos personales del usuario a través de la API.
Puntos clave
1. Los escenarios para tales ataques pueden ser diferentes, mi ejemplo es solo uno de ellos. Preste atención a tales vulnerabilidades e intente profundizar más para crear un escenario similar: ¿de qué otra manera podría un atacante atacarlo?
2. En el ejemplo descrito, la API del atacante se autenticó en el punto final de la API de la víctima porque no hubo validación del encabezado del token de autorización. Esto permitió al servidor copiar los datos personales de los clientes a otro punto final de la API.
Curso de los eventos:
22 de julio: informé de la vulnerabilidad al equipo del portal.
23 de julio: el equipo revisó el informe y la gravedad se estableció en Media.
23 de julio: Recibí una recompensa de $ 500.
27 de julio: problema resuelto, informe compilado.