IDOR IN JWT AND THE SHORTEST TOKEN YOU WILL EVER SEE {}.{“uid”: “1234567890”}

TL;DR, JWT is in use by many of the big companies but some implementations are not that safe here is a bug that got me 1,500$

Earlier this year i was participating in a bugbounty program on HackerOne, the app allowed customers to order products, it seemed pretty solid, i managed to find some interesting character transformation issue so i spent hours trying to get stored xss but no luck so after a couple of days i was a bit let down. I closed burpsuite started a new project and decided to start over from the beginning.

I typed the address lets say http://example.com and logged in using my girlfriends account (i didn’t want to order anything) upon login i noticed a crossorigin pre-flight request to an api endpoint which looked something like

OPTIONS / HTTP/1.1
Host: customer-order-status.example.net
Content-Type: application/json
Connection: close

Later on using the app my girlfriend ordered a product on this app and she could check the status of her order, the check order request looked something like this

GET /api/v1/order_statuses/{order_id} HTTP/1.1
Host: customer-order-status.example.net
Authorization: Bearer JWT TOKEN
Content-Type: application/json
Connection: close

The JSON response contained personal account information including delivery address, order details, payment method, payment amount… All the juicy stuff

The JWT token had the session id and user id and signed with HS256, pretty good right but no the api did not validate any of that

{“alg”: “HS256”,“typ”: “JWT”}.{“uid”: “1234567890”,“sessionid”: “ALPHANUMERIC ID”}.SIGNATURE

The shorter version i ended up using of the authorization Token looked like

{}.{“uid”: “1234567890”}

So i could query this api endpoint using the above JWT token and the response was valid. This also worked when using past order ids

To exploit this effectively by an attacker some level of brute-forcing was needed to query random users information given the fact that there are two variables the user id and the order id this was a bit hard to exploit, what made this dangerous however is that the server did not implement request limits so it could potentially make the brute-force attack feasible.